Section 6.4. Process-Enabled SOA

6.4. Process-Enabled SOA

The third expansion stage is the fully leveraged SOA. The key feature of the process-enabled SOA is the maintenance of process state in process-centric services.

Similar to intermediary services, a process-centric service is both client and server in an SOA. The major difference between these service types is the fact that process-centric services are stateful. This is a crucial difference because handling state is a critical issue for server-side software. There are several possible reasons for introducing a process-centric service:

• Encapsulating the complexity of processes

• Sharing state between multiple clients

• Handling long-living processes

Encapsulating process state in a process-centric service enables application frontends to be simple and lightweight and at the same time very user-friendly with an elaborate handling of the user session.

Figure 6-11 extends the booking example first introduced in Figure 6-5. A new service "Booking process" encapsulates the business process "Booking." The Booking process utilizes the BookAndBill service and the Customer service. Although most of the work is carried out by the Booking service, the application frontend has access to all layers of the SOA.

Figure 6-11. A fully developed process-enabled SOA has four layers.

The scenario in Figure 6-11 is the straightforward evolutionary step arising from the scenario in Figure 6-5. However, a green-field design would be different. In our example, the BookAndBill façade could become part of the process-centric service. Omitting the BookAndBill service (see Figure 6-12) reduces our scenario to three layers. Because one of the primary goals of SOAs is simplicity, this is a desirable step. Furthermore, reducing the number of tiers between the application frontend and basic layer reduces the system's latency and the number of elements that can potentially fail.

Figure 6-12. The Booking process encapsulates all functionality necessary to book flights. It also maintains the session state.

But there are also possible scenarios where our BookAndBill service can be beneficial. Assume that several clients, such as a Web site, a B2B gateway, and a mobile application, are running simultaneously (see Figure 6-13). Typically, these applications require a distinct process-centric service. Factoring out the BookAndBill functionality becomes a reasonable design decision in this case.

Figure 6-13. Several processes can utilize the BookAndBill service at the same time.

However, as depicted in Figure 6-14, an alternative design exists that factors out common booking process functionality to a process-centric service that can incorporate the BookAndBill functionality. The shared process-centric service both maintains a channel-independent process state and shields the channel-specific process-centric services from backend complexity.

Figure 6-14. In general, every channel of a multichannel architecture requires channel-specific process logic. Nevertheless, different channels also share behavior.

Finally, process-centric services can handle long-living processesin particular if user interaction or asynchronous backend services are involved. Obviously, one requires a location that maintains the state of a process for the duration of its execution.

Assume that the booking process supports waiting lists. This means that a customer can register a seat in a fully booked flight. If cancellations occur, the customer is notified using email or SMS (mobile phone text messages), or he can retrieve the status of his registration in a later session at the Web site. This kind of functionality implies that the booking process is long-living. External events (here, cancellations of other customers) change the state of the process.

A possible implementation scenario would assume that the cancellation process is another client of the booking process, as depicted in Figure 6-15. If a cancellation is made for a flight for which the waiting list is not empty, the cancellation process starts the appropriate booking process. The booking process notifies the waiting customer and converts the entry in the waiting list into a proper booking.

Figure 6-15. The booking process is asynchronously coupled with the waiting list service.

A process-enabled SOA represents the endpoint of the evolution we have described in this chapter. A process-enabled SOA

• Enables lightweight application frontends that "only" need to worry about user interaction

• Encapsulates complexity of business processes and handles their state

• Encapsulates complexity of backend systems in intermediary services and process-centric services

• Enables the process logic located in the process layer to be clearly separated from other types of code including dialog control that is located in the application frontends and the basic services' core business logic

• Represents the most sophisticated expansion stage and is therefore more difficult to implement than other expansion stages

• Is required for integration of highly independent organizations and the implementation of complex processes. However, it is not as cost effective in well-controlled environments such as intra-departmental integration scenarios.