Design and implementation of composite service

Most of the current article books on SOA focus on the definition and implementation of individual business services. Building an enterprise solution usually requires a combination of multiple existing enterprise services. These composite services can again be combined with other services to become more advanced solutions. The recursive composition of this business service is one of the most important features of SOA, enabling us to quickly build new solutions on the basis of existing business services. As the number of business services (and their composites) grows, it becomes easier to implement new enterprise solutions.

As defined in the toward a pattern language for service-oriented architecture and integration, the main drivers for generating composite services come from the following:

Simplified use. When several business services are used by multiple consumers at the same time, it is more complex for consumers to disclose information about each of these services and the rules for collaboration between them. When creating composite services, encapsulating the services involved in them and enforcing their invocation rules can significantly simplify the complexity of the usage.

Promote reusability. New schemes that were not originally planned are often assembled with existing services. Even though these services are designed to construct specific scenarios, we can still use these business services in a different combination to achieve previously unexpected scenarios. Moreover, the services available on hand will prompt us to think of new and unprecedented solutions. These new programs can often be generated by a relatively small amount of service development or enhancement, both low-cost and fast.

Distribution, visibility, control, and change management of the scheme. Composite services can be considered as a distribution mechanism for the overall scheme. Similar to the local and remote interface of EJBS, the introduction of composite services and the exposure of only some interfaces to external users allows us to control what is visible to consumers. This enables the underlying software architecture (the composite Service implementation) to respond quickly to changes in demand, and whenever the requirements change, the underlying software architecture adjusts the implementation of its next-level services and their interrelationships, without or only a slight impact on the consumer.

Composite services have two aspects (according to the Tools for composite Web services:a short Overview): Composite design, focusing on integrated specifications to determine how to coordinate Component Services (Component Service) to meet the customer's request, the implementation of the composite, that is, how to implement the specifications generated by the composite design, in order to actually achieve the coordination between the services.

In this article, we will discuss the main ways of composite services from both design and implementation.

Composite design

Composite design is about how to design a solution based on a set of existing services. What it does is determine which services are used in the composite design, how they interact with each other, and the composite topology.

Interaction of services

According to the service–oriented composition in BPEL4WS, there are two main ways to design complex interactions:

Layered composite

Session Comp

For layered composites, the implementation of a composite service is completely opaque to the consumer of the Service (black box). The consumer that invokes the service waits until execution completes, and then (directly or indirectly) uses the output of the execution (Figure 1).

Figure 1 Tiered Service Comp

This kind of compound method is very natural for implementing the system of layered decomposition. Each level is implemented as a separate composite service and coordinates the execution of the lower tier (compliant) service. This is also a common modeling method for high-level scenarios in a workflow system-a combination of a range of activities, each of which can correspond to a low-level business process, or a task performed by a person or program. Although any composite service can be used to monitor and interrupt external systems, the composite service does not interact with any other functional interaction with the consumer of the service, except for the initial invocation 1.

While black box compounding (layered composite) is a powerful tool for dealing with complexity, in some cases consumers still need to control the execution of the composite service based on the immediate results of execution. Session comps can accomplish this function. In a session-composite scenario, the implementation of a composite service is still completely opaque to the consumer of the service, but specific immediate execution results can be exposed to the consumer (gray box).

This is done by supporting explicit session state (see [4] for the difference between session state and execution state)--the composite service then exposes multiple interfaces to the consumer: one is used as the original service invocation, and the other is used to obtain immediate results and to control the execution of the service (Figure 2).

Figure 2 Session Service Comp