Combining Quality of Service and Social Information for Ranking Services

Qinyi Wu, Arun Iyengar, Revathi Subramanian, Isabelle Rouvellou, Ignacio Silva-Lepe, Thomas Mikalsen
http://www.research.ibm.com/people/i/iyengar/ICSOC2009.pdf

FROM BEFORE

The authors propose ServiceRank as a method to rank services based on the opinion of those using a service as well as local behavior of services, mainly response time and response failure.

Problems:

1. what is the proper answer response from a service? Does it have to match a value expected by the client or can it be just any response? How does the client know of the proper value for a computation prior to using a service? Does it then require to have knowledge about the service?
   
2. How does data from all services is collected? is there a single repository where the services publish the results their experiments with the services?

ServiceRank as a ranking algorithm to bring opinion of the community about using a service into consideration when deciding on the quality of service

Problems:

1. It is not clear how requesting services decide about the correctness of the returned data? is a response rated as correct when only a response is received, or when the correct response is returned. In the first case, how would the service be guaranteed as the proper service, and in the second case how are we going to know what is the returned value for the request?
2. How the cumulative data about the experience of other services gets collected? There are monitoring services that keep the record of all services. There are going to be multiple monitor services associated with the applications connected to the SOAlive. This is not a real case for the real world applications.
   

The paper also contains a set of experiments to demonstrate how a composition can be affected by quality of service and how the cumulative study for service composition.

The approach can be used as a method to provide cumulative study on service composition within a composition chain.

Dynamic Service Composition using Semantic Information

http://portal.acm.org/citation.cfm?id=1035174

Static Service Composition (proactive)

• workflow or state chart is designed to describe the interaction pattern
• BPEL, WSCI
  

Dynamic Service Composition (reactive)

• autonomous application composition
• eFlow[4], SWORD[13]
• dynamic service composition is useful for ubiquitous and end user applications

Scenaio

1. get address for restaurant and home
2. invoke the direction generator web service
3. print out the result image

four domains are introduced

1. data types
2. semantics (Concept)
3. logics
4. components

Comparing CoSMoS with SCA

• data types in CoSMoS are equivalent to DSO in SCA
• semantics are not supported in SCA
• logics is somewhat meaningless for CoSMoS
• components have equivalents in SCA
• composites are not defined in CoSMoS

CoSMoS is a new component model CoRE converts the metadata for the discovered components into CoSMoS and CORE has a pluggable architecture.

Semantic Graph Based Service Composition (SeGSec)

Request Analyzer <-> ServiceComposer <-> Reasoner <-> ServicePerformer

"ServiceComposer genrates the execution path by connecting operations of components", How?? This is not something trivial. Matching the operations for different interfaces for services is quite difficult. I am not sure how it is done. How do they perform this matching of operations at the high level? Reasoning and semantic resolution should be performed before the ServiceComposer module generates the path.

for other systems, there should be a template implementing the requested service. so a B2B template matching is required in this case.

Towards a Programming Model for Service-Oriented Computing

composition model is built on top of component models. We look for a customization without source code modification.

Composition

• behavioral
• adaptation -> point of variability
  
• structural
• mediation -> message processing

Dynamic Binding

• dependency injection -> automatic dependency resolution
• Mediation Model -> dynamic mediation -> dynamic binding

IMPORTANT DEFINITION: a service is a visible access point to a component. A component can offer multiple services or reference multiple services

service specification -> access channel

• interface -> WSDL
  
• policies
• behavioral description -> BPEL

service component implementation (similar to the SCA model in which we have comonent, composite, reference, services, properties)

• service spec: characteristics of a service
• required services
• service properties
• container directives
• implementation artefacts

service component

• Name
• implementation
• values for properties
• specification + resolution for services
• wires + queries + QoS policies

directives for service composition could be instructed using either Pragmas or Control files

• Control Files: BPEL or other workflow descriptions
• Pragmas: Annotations within the code

Structural Composition (Mediation)

• wiring: wires represent the flow of messages
• Bundle -> a collection of services
• Event-Driven Composition
• Mediation
• Content-based Routing
• Transformation -> transform and map messages
• Augmentation -> adding additional information to the message
• Side Effect -> extra operation on the messages
  

Behavioral Composition - Process Oriented (Adaptation)

• workflow oriented
• state machine
• UML state diagram
• BPEL -> DAG activity nodes
• short running
• long running
• has one or more interfaces
• different implementations for canceling

SDO (Service Data Object) = a uniform way of representing service data + the abstract tree is used to access data irrespective of how it is provided

IMPORTANT

SOA component model improves over CORBA/J2EE/COM

• control language
• XSD & WSDL are more tolerant of interface evaluation
• call/return + one way messaging
• rich contracts
• QoS
• behavioral description
• mediation + intermediaries

SCA -> abstraction of implementation concerns
Web Services -> abstraction for interoperability concerns