SOA Web Services - Serial Process Application Pattern

Serial Process Application Pattern

This is an extension of the broker application pattern discussed in the previous section. In this case, a source application initiates an interaction with multiple target applications as in the case of a broker application pattern.

However, the interaction, which is essentially a consumption of a service, now consists of invoking a series of business processes serially in a desired sequence. Basically, it facilitates the orchestration of several business processes for the desired interaction by the source application. This is illustrated in the following figure.

The Serial Process application pattern facilitates the separation of process flow logic from the logic of the individual applications. The flow is controlled by the Serial Process Rules tier. These rules not only define the control and data flow rules, but also define the execution rules for each target application. The intermediate results are stored in a WIP (Work-in-progress) database. The execution rules are stored in a registry.

In the case of an Extended Enterprise domain, the pattern defines the interaction of a source application with the series of target partner applications in a pre-determined sequence.

Guidelines

The Serial Process application pattern fits perfectly in the SOA paradigm. The businesses provide autonomous services. A consumer requires a series of services to be executed in a desired sequence. The orchestration flow may be defined at run time. The consumer requests a certain kind of business service that is decomposed into smaller services and executed sequentially on a set of target applications.

An example of this can be a travel reservation. A traveller desires a hotel and a car reservation besides her air travel reservation. These services are offered, obviously, by different business. Hotel, car, and airlines reservations operate independently of each other. The traveller initiates a reservation request for desired travel dates. The request is split into multiple service requests that are executed sequentially by partner businesses. When all the partner requests are processed, the reservation confirmation or non-availability is communicated to the consumer.

The practical implementation of this pattern is seen in the case of orchestration servers based on BPEL (Business Process Execution Language) discussed in depth in Chapter 5. The reader may also refer to a Packt book on BPEL (Business Process Execution Language for Web Services, Second Edition, ISBN 978-1-904811-81-7).