Chapter 10. SOA in Action

This chapter shows how a service can be implemented in the real world to serve the needs of different usage models. You can provide the same service using different protocols and different granularity according to the context in which you use it. As is the case with traditional software, it is impossible to design a service based only on abstract principles. However, you can employ careful planning and refactoring of a service to make an implementation suitable for many different usage scenarios.

To illustrate the different design considerations applicable to different usage models, we employ a passenger check-in scenario. A passenger might check in with a mobile phone or PDA, using an electronic (or physical) ticket at an airline booth. Alternatively, the passenger might be checked in with one airline on behalf of a second airline, perhaps if the second flight leg is operated by a different carrier. In some scenarios, the same service might be accessed using multiple channels at the same time.

In its most generic form, multiple services are at work. At the heart of everything is the check-in service, assigning seats to passengers on airplanes and keeping track of the seat occupation in individual planes. As input, it takes any number of passenger ticket coupons and returns the appropriate number of boarding passes. Usually, other services will also be involved. Prior to performing the check-in, the ticket service can be used to determine which tickets are available for a passenger and to validate the tickets before check-in, in addition to marking the ticket coupons after check-in has been completed.

The customer information service might be contacted to read data regarding the preferences or frequent flyer account of the customer. Preferences for seating can be used in the booking itself. A meal preference can be used with services available from the airline's caterer to prepare only the required amount of special food, thus decreasing the airline's overhead. Personal data regarding the passenger might be forwarded to the customs or immigration office at the passenger's destination. For the time being, this discussion will be limited to the services mentioned previously, although more services might be involved for issues such as baggage handling and airport services.

As a prerequisite, it is worthwhile to determine if the provided services are aggregation-friendly. The ticket service's sole purpose is looking up tickets and checking their validity. These calls can be considered idempotent at the semantic level. If they fail, the caller can reattempt the call and expect the same result as the previous call. Invalidating the coupon is an operation that will change some persistently stored data. The call to this operation is logically tied with the assign seats call of the check-in service itself. The latter is likely to live in a local transaction and can be rolled back upon failure. In this event, there will not be any attempt to change the state of the ticket voucher, even though such changes can be easily reset in a compensating call. Finally, setting the meal preference is an operation that might also be considered idempotent. However, in an operational system, this type of process is more likely to be implemented in an asynchronous manner. In general, it is necessary only to guarantee that the caterer gets the information about meal preferences well before takeoff rather than at some specific point in time.

Throughout this chapter, we will use the same example in a set of different scenarios. In Section 10.1, we discuss a Web application. In Section 10.2, our example takes the form of an EAI integration scenario. We employ a B2B model in Section 10.3. In Section 10.4, we discuss a fat client scenario, and in Section 10.5, we deploy it by using a small mobile device such as a cellular telephone. Finally, in Section 10.6, we discuss the multi-channel scenario.