Composing REST services and collaborative workflows

Bite offers a language for composing REST services.

REST composition enables some sort of data flow composition model (similar to Yahoo Pipes)

Human interactions happen by forms, instant messaging, linked email exchange, etc.

Collaborative services such as Lotus support unstructured interactions between ad-hoc communities linked via common business goals. Complex collaborative applications.

Design Goals for Bite

• Atom life-cycle
• Lightweight process model
• Scripting Approach
• Language extensibility
• Web and human integration

It allows for extensibility of the language and it supports parsing the scripts for the languages. also GUI elements can be easily connected to the bite script and their states can get updated by sending reploes to their interfaces.

Semantic-based Contxt-aware Dynamic Service Composition

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

Contributions

1. Not only system designers but also end users to specify rules on how to compose context-aware applications
2. It supports both rule-based and learning-based context-aware service composition
3. It utilizes semantic similarities among components to improve its adaptability in a dynamic environment
4. supports seamless service migration which autonomously composes a new application and migrates onto it when user context changes
   

Componetn Service Model with Semantics (CoSMoS)

There is a UML meta model for CoSMoS wichi helps with Defining

• Functional Informaiton
• Semantic Information
  
• Contextual Information
• User specific rules

Component Runtime Environment

CoRE consists of the following pieces

• Dscovery Manager
• Execution Manager
• User Manager

Three methods for context acquisition

1. metadata of the components: context information is embedded in the components metadata
   
2. context-aware discovery or user submodule: acquiring context information through existing context aware technologies
   
3. inference: infer context based on a set of facts

Semantic Graph-based Service Composition (SeGSeC)

two approaches are used

1. Rule-based
2. Learning-based

Problem in creating the workflow is that, semantic correctness of the workflow gets checked at the end of its execution, wherease it can be included in the process of execution so that the semantically valid components get discovered first before actually having to deal with the composition and orchestration of components

The learning algorithm for selecting a component
Pi = max (SSi,j x (CMDj + const)) 1 <= j <= n SS i,j = semantic similarity between two components CMDj = context matching degree. (how well the component matches the context it is used in based on the previous experiments in using this component in this context). To decide about context matching conditioins a C4.5 DT algorithm is used collecting information about a composed workflow. context aware dynamic service composition systems have problems for the following reasons:

1. predefined rules usually cannot be modified once they are deployed
2. it is difficult to define a generic rule that is applicable to every user
   
3. some users preferences may be too complex to define as a set of rules

interesting evaluations for dynamic composition of context-aware services. I skipped the experiments but they might be worth reading.

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.

Evolving Services from a Contractual Perspective

Vasilios Andrikopoulos, Tilburg University, Netherlands
Salima Benbernou, University Lyon1, France
Mike Papazoglou, Tilburg University, Netherlands
http://infolab.uvt.nl/pub/andrikopoulosv-2009-124.pdf

-------------------------------------

two views are introduced

exposition vs expectation
required vs provided

A contract records the benefits and the obligations
the contract describes what is the acceptable results and contributions for a task described

The client formulates the contract, instructing the provider on what functionalities are going to be used.

Shallow Changes are divided into two categories

• contractual invariance changes: a simple mediation would do the trick
  
• contractual evolving changes: changes that require revisiting the contract but do not require changes in the other party

a multi-agent system for the reliable execution of automaticall composed ad-hoc processes

http://www.springerlink.com/content/q7684735gl420772/

Scenario

• the user states his pereference > comedy movie, restaurant with french cuisine
• ad hoc composition is required when the user is roaming
• location based composition for nomadic users

Approach

Components AND Services: a marriage of reason

http://www.i3s.unice.fr/~mh/RR/2007/RR-07.17-P.COLLET.pdf

The article provides a comparative study and positioning of components and services with the overall objective of arguing that the two approaches can be seen as much more complementary than competitors.

components

• black, white, grey boxes
• arbitrary granularity
• state
• reflection
• composition
• structural composition: binding between components needs to be controlled. or the connections between components and sub-components.

services in SOA

• black bozes
• coarse granularity
• loose coupling
• statelessness
• discovery
• orchestration

CBSE is more favored in middleware and embedded systems which exhibit strong NF constraints

SOA is typically preferred in e-business applications which necessitate to chain calls to online services provided by distinct companies.

Applicatoin to Dynamic Communities System

Amui is a messaging server for dynamically and automatically grouping users according to their common interests. the users are filtered based on their topics of interests and are redirected to chat rooms associated to user defined set of keywords. Users will receive ads and can also include some plugin-like applications to carry more content to the users, e.g., videos, etc.

Amui Server is composed of three subcomponents:

• AmiFacade
• The Core
• manage users
• manage groups: group creation/administration
  
• match user keywords to group topics (UGManager) : implements the main functionality
  
• Advertisement Proxy

Fractal WS is a toolkit to make compatible any Fractal component with the technology of Web Services. It uses generative programming and statically typed stubs are generated.

Fractal SCAproposes bidirectional bridge between Fractal and the SCA. From Fractal to SCA components are enhanced so that they are able to create SOAP bindings. On the other hand, SOAP communication service is provided to handle communications from SCA to Fractal.

Enhancing Residential Gateways: OSGi Service Composition

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4140904

Scenario

Home Security Service:

Fire

• ringing alarm
• unlocks the doors
• calls the fire station
• informs John using the most appropriate device

Intrusion

• locks the doors
• calls the police
• informs John

They propose a BPEL like description for providing a composition contract where a virtual bundle gets loaded to the OSGi ServiceRegistry with the BPEL specification for the service, registers itself with the BPEL engine and enables the engine to use the loaded BPEL. The BPEL is then used by the system to do an orchestration of services in the OSGi ServiceRegistry.

OWL-OS/OSGi is used as a semantically enabled OSGi framework in order to provide semantic enhancements to OSGi. The partner link is expanded with some more elements to incorporate semantic information for the partners providing the desired methods or porttypes.

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

a distributed service-oriented mediation tool

devices do not use the same data representation and alignment transformations are needed.

mediation: to aggregate disparate information sources in a timely fashion which enables interoperability and integration of services.

mediation also helps with adding new quality of service concerns without modifying the code at the client side.

four categories of mediation

1. control mediation -> routing, filtering, aggregation
   
2. transformation -> matching types
   
3. QoS mediation
4. SLA enforcement -> transcoders

Some open source solutions for ESB providing open solutions based on Java Business Integration (JBI)

1. Apache ServiceMix
2. ObjectWeb Petals
3. Codehaus Mule

The model for mediation can be changed from reactive to proactive. in the current reactive model, there is a mediation service which gets hit by the information that needs to be mediated. This is mainly true in case of transformation mediation, control, and maybe SLA. However, the QoS mediation is still a proactive mediation mechanism as it needs close coupling with the service itself. To bring security, e.g., it is not possible to send data to a third party service in the hope of receiving the encrypted service back.

each mediation application is defined as a set of connected components and each component implements a single mediation operation.

three ways for generating mediators

1. search for pre-existing mediators
2. to use generation code tool that generates the code of a skeleton of mediators with methods to read and write on ports
3. specialized mediators such as the ones for generating Web service clients and service bridges

the nodes for mediation are built over OSGi which provide facilities to load and update Java code dynamically. two modules are required on top of each node

1. the MOM bridge
2. the administration module

administration console manages the relations between administration modules in a centralized mannger. The console take care of monitoring different adminstration modules spanned over several nodes.

a mediator registers a mediator factory taking care of all meatiors installed in the system. also it installs mediators.

MOM in the mediator enables connecting the in ports to the out ports

in -> represents a subscriber to a channel
out -> represents the publisher to a channel.

The publisher to a channel receives messages which then get forwarded to other mediators connected in the other nodes and subscribed to the same channel.

JORAM is a JSM used in the MOM module
a DHT-based algorithm such as Scribe can be a more scalable solution. What is scribe?!

failure detector based on two-ring algorithm which supports new node arrivals and failures in nodes. Does it have anything to do with the mediators on the nodes and detecting whether they stay up or go down?