Service composition strategies


The current challenge is to use Web Service composition across company boundaries. Here are the benefits of the automatization of cross-organizational business transactions:

  • Improvements of cost-performance ratio of IT
  • Extending market reach
  • Saving time
  • Cutting costs
  • Responding to customer demands more agilely.

The main troubles faced by the companies to adopt this kind of architecture:

  • Different standards and standardization approaches prevent from a common understanding of business processes and data
  • High costs and complexity of existing approaches

There is different strategies and architectures to achieve Web Service composition:

  • Orchestration
    • Represents the relation between one central service and different other ones called according to a pre-defined sequence
    • Adequate to describe exchange patterns of one individual service
    • Can be conducted with the help of languages such as BPEL
    • Executable on respective engines
  • Choreography
    • Message exchange described from the perspective of an observer who is able to see all interaction of the participants of a choreography
    • Languages, e.g. WS-CDL, BPSS
    • Not executable, used for modelling and monitoring

There is 3 kinds of service orchestration:

  • Centralized Service Orchestration
    • Pro:
      • Efficient monitoring
      • Fault handling
      • Maintenance
      • Less local complexity
    • Con:
      • Invocation policies (not all services might be called by one single hub)
      • Lack of trust
      • Single point of failure
  • Decentral Service Orchestration with Hub Support
    • Pro:
      • Message exchange independent from server
      • Overall choreography can still be used for monitoring and fault handling support
    • Con:
      • Fault handling more complex
      • Users must be able to handle an execution engine
      • Increased complexity
  • Decentral Orchestration without Hub
    • Pro:
      • Robustness against partial errors
      • Higher scalability
    • Con:
      • Permanent synchronization of the local repositories
      • Complicated fault handling
      • Highest complexity on client side


The most promising approach seems to be the hybrid one.

Posted in SOA |

Thoughs on “An Architecture for a Service OrientedPeer-to-Peer System (SOPPS)”

I’ll just give some interesting excerpts related to P2P service discovery.


“It is based on p2p structures and offers a generic support of services as well as supply mechanisms to enable market management of those services offered”

“The SOPPS architecture needs to support completely different services, including management of content and other resources. Hence, mechanisms such as service fusion, i.e. the combination of existing services to create new, value-added services, and service description are required.”

“Peers are defined as nodes connected to a network, running the respective SOPPS software. SOPPS consists of peers communicating over a network in order to provide or use services.”

SOPPS architecture is based on 3 models:

  • Use model: a service is the provisioning of resources or the execution of tasks of one or more (temporarily provider) peers on behalf of one or more (temporarily user) peers. On the corresponding peer, it invokes functionality to discover an appropriate service and to determine and contact one or more provider peers offering that particular service.
  • Network model: abstracts the Internet into a overlay model
  • Peer model: Each peer has a number of local resources available at the bottom layer. These resources consist of hardware and software resources and can be used either for providing services to other peers or for support of the Core Functionality.

In order to access a service, the following steps need to be performed:

  • Service search phase: user creates a service description describing the content and his peer sends out a service request containing this description to other peers. This request is forwarded by the peers according to a search protocol.
  • Service negotiation phase: After a user has found one or several possible services he enters a negotiation with their providers to define the exact terms of service usage. This includes the fixing of parameters, e.g., the format the content will be encoded in, the data rate for sending the content, the price the user might have to pay for the service.
  • Service usage phase: the user can start using the service. Especially, this includes the remote invocation of methods offered by services during an initialization phase.
  • Application of rules: Throughout all the processes described above the rules management component watches over the fulfillment of previously defined rules.


Interesting high level view on the architecture. No technical details or solutions are given in the paper.

Paper [pdf]