Service Composition

Service composition refers to the process of combining several services to provide a value-added service. In SOC, it is impossible for a single service to accomplish a complex task. One solution is to combine many different services and make them collaborate to finish the complex task. Each service can locate in a wide area and the composition relation between them is a loose coupling. The composite service is usually composed according to the requirements of a customer and its deployment is temporal and prompt. The composition relation can be canceled after tasks are finished. Therefore, service composition is an important way of service reuse, the construction and the deployment of a complex application in a SOC environment.

In the context of SOC, a service participating in a composition process is called a component service. The result of service composition produces acomposite service.

Aservice classis a collection of component services, which have the same functions but different nonfunctional properties (such as QoS). The element in a service class is also called acandidate service. An overview of the approaches for implementing service composition is presented as follows.

3.2.1.1 Manual Composition Versus Automatic Composition

The execution process of manual composition is decided in a manual way. Such a method manually chooses services that can participate in the composition, ana-lyzes functions and interface parameters of each service to decide the dependen-cies of the data flow and the control flow, and uses some modeling languages, such as BPEL4WS [3] and EFLOW [5], to describe services and their dependencies.

Figure 3.1 shows an example describing a process for handing a loan application using BPEL4WS, which is derived from a tutorial on BPEL4WS by IBM [11]. In

<process name="loanApprovalProcess" ... />

<partners>

< container name="request" messageType="loandef:CreditInformationMessage"/>

< container name="approvalInfo" messageType="apns:approvalMessage"/>

< container name="riskAssessment" messageType="asns:AssessMessage"/>

</containers>

<sequence>

< receive name="receive1" partner="customer" portType="apns:loanApprovalPT"

operation ="approve" container="request" createInstance="yes">

< /receive>

< invoke name="invokeassessor" partner="assessor" portType="asns:riskAssessmentPT"

operation ="check" inputContainer="request" outputContainer="riskAssessment">

< /invoke>

...

< invoke name="invokeapprover"partner="approver" portType="apns:loanApprovalPT"

operation ="approve" inputContainer="request" outputContainer="approvalInfo">

< /invoke>

< reply name="reply" partner="customer" portType="apns:loanApprovalPT"

operation ="approve" container="approvalInfo">

< /reply>

</sequence>

</process>

Fig. 3.1 A simplified BPEL4WS document for the loan approval process

this process, the customer and two web services, namely assessor and approver, are all represented as partners. The technical details of each activity are as follows:

• receive: allows the business process to do a blocking wait for a matching message to arrive, e.g., customer.

• invoke: allows the business process to invoke a one-way or request-response op-eration on a portType offered by a partner, e.g., assessor and approver.

• reply: used to send a response to a previous request accepted through a receive activity.

The disadvantage of manual composition is that the professional persons would be required to finish the service composition, which cannot be finished automatically according to the customers requirements. Thus, the efficiency of the manual way is very low in a complex business process.

Automatic composition is automatically generated based on requirements from customers. To increase the automatic degree of service composition, the machine should understand and deal with the information on services. Semantic Web Services, which is a combination of semantic web techniques and web service techniques, can make use of some existing methods in the field of artificial intelligence or log-ical inference to generate a new composite service according to the requirements automatically. In general, semantic web enabled automatic approaches consists of three conceptual phases: specification, matchmaking and generation [16]. The spec-ification phase enables high-level and customized descriptions of the desired com-positions. The specifications of the composers include constructs for the orches-tration and semantic descriptions of composition sub-requests. The matchmaking phase uses the composability model to generate composition plans conforming to

requirements from composers. Because services are described semantically, the ma-chine could understand which services could contribute to the composition and how these participant services could interact with each other. A set of algorithms are developed for checking the composability and matching services to generate composition plans automatically. The generation phase returns detailed composite service descriptions. Such descriptions include the orchestration (composer-defined and system-generated) of participant services.

3.2.1.2 Proactive Composition Versus Reactive Composition

Proactive composition is an offline process that gathers available component ser-vices to constitute a composite service in advance. The composite service is precom-piled and ready to be triggered upon customers requests. In a proactive composition, the component services are usually stable and may be running on the resource-rich platforms. In enterprise computing, the storage resources and the computing resources are sufficient as to guarantee running of participant services. Moreover, enterprise applications are solid. Consequently, such a composition is designed and deployed in advance, and its QoS is stable.

Reactive composition is the process of creating a composite service on-the-fly.

A composite service is devised on a request-basis from customers. Because of the on-the-fly property, a component manager is required and ensures the identification and collaboration of component services. Despite a certain complexity of reactive composition, it has several advantages over proactive composition, for instance, the possibility of tracking the status of the composition process to take correct actions promptly and the possibility of optimizing run-time parameters, such as bandwidth use, data transfer routes, and execution charges. This kind of composition is suitable to a dynamic Internet environment.

3.2.1.3 Mandatory Composite Service Versus Optional Composite Service A mandatory composite service corresponds to the compulsory participation of all the component services in the execution process. Under this situation, the partici-pant has no substitution and no requirements for selecting an appropriate candidate service from a service class. Because it is expected that the component services will be spread over the network, QoS of the execution process of each component service affects the whole QoS of the composite service. Due to no substitution, the QoS of each component service must be guaranteed as much as possible.

An optional composite service does not necessarily involve all of the component services. Some component services can be skipped during the course of execution due to various reasons, such as the possibility of substitution or unavailability. For example, in some high-reliability required situations, such as emergency response applications, some service replicas will be deployed to ensure load balancing, fault-tolerance, etc. A composite service only chooses a “free” and “healthy” replica.