IT Transformation with SOA

Back in the XIX century (that’s the 19^th century for all you X-geners!), there was a composer who didn’t know how to play the piano. In fact, nor did he know how to play the violin, the flute, the trombone, or any other instrument for that matter. Yet, the man managed to compose symphonies that to this day are considered musical masterpieces. The composer’s name was Louis Hector Berlioz, and he achieved this feat by directing the orchestra through each step of his arrangement and composition. His most recognized work is called “Symphonie Fantastique” and, according to Wikipedia, the symphony is scored for an orchestra consisting of 2 flutes(2nd doubling piccolo), 2 oboes (2nd doubling English horn), 2 clarinets (1st doubling E-flat clarinet), 4 bassoons, 4 horns, 2 trumpets, 2 cornets, 3 trombones, 2 ophicleides (what the heck is an ophecleide? A forerunner of the euphonium, I found out. What the heck is a euphonium? Well, check it out in Wiki!), 2 pairs of timpani, snare drum, cymbals, bass drum, bells in C and G, 2 harps, and strings.

By now, you probably get the idea. Mr. Berlioz fully exemplifies the ultimate back-end composite services element: The Orchestrator. Berlioz composed some pretty cool stuff by knowing a) what he wanted to express, b) what specific set of instruments should be used at a particular point in time, and c) how to communicate the notes of his composition to the orchestra.

Every SOA-based system needs its Berliozes.

There are several dimensions involved in defining the role of an orchestrator for SOA. First, as discussed earlier, most orchestrator roles will be provided within the context of an application; not as a part of a service. That is, the orchestration is what defines an application and makes one application different from another. The orchestration is the brain of the application, and it is the entity that decides the manner and SOA services calling flow.

In some instances, you might even be able to reuse orchestration patterns and apply them across multiple applications. Better still, you can build orchestration patterns by utilizing the emerging Business Process Modeling technologies (BPM). BPM simplifies the work of creating orchestration logic by providing a visual and modular way of assembling orchestration flows. A small commentary of mine is this: BPM is not SOA, but BPM requires SOA to work properly.

An apropos question is to ask how much orchestration should be automated in the SOA system as opposed to letting the user manually orchestrate his or her own interactions. To answer this question it is best to remember the complexity rule I stated earlier:  the simpler the user interaction; the more complex the system, and vice-versa. 

Then again, there are limits to the complexity of an orchestration. A full-fledged Artificial Intelligence system could become the ultimate orchestration engine but, unfortunately, such a machine remains in the realm of science fiction.  Cost-Benefit compromises must be made.

Say we have a travel oriented system and need to find the coolest vacation spots for the month of September. Should we let the user manually orchestrate the various steps needed to reach a conclusion? Each step would indirectly generate the appropriate service calls for searching destinations, filtering unwanted responses, obtaining additional descriptions, getting prices, initiating the booking, and so forth. Or we could consider developing a sophisticated orchestration function that’s able to take care of those details and do the hard work on behalf of the prospective traveler. But should we do it?

The answer lies in the size of “the market” for a particular need. Clearly, there is a need for a travel orchestration capability that can take care of all the details mentioned. After all, isn’t this why Travel Agencies emerged in the first place? If the orchestration is need by only a few users, then it is best not to spend money and effort attempting to automate something that is too unique. On the other hand, if the request becomes common, then it is preferable to create an automated orchestration function that organizes and integrates the use of SOA services.

The orchestrators design should always accommodate the transparency tenets in order to allow horizontal scalability. In other words, if you provide the orchestration via servers located in the system membrane, you will need to design the solution in such a way that you can always add more front end servers to accommodate increased workloads, without disrupting the orchestration processes in existing servers. Because orchestration usually requires the server to maintain some form of state, at least for the duration of a transaction, you will need to incorporate some form of session-stickiness in the orchestration logic. Later on, I will write more about why I recommend that this is the one and only area where a “session state” between the user and the orchestration should exist, even as I still advice to keep backend services discrete and sessionless.

Before I present a sample view of services as applied to a hypothetical airline reservation flow, I would like to cover yet other dimensions to the categorization of services: the manner of the service delivery and its disposition.

In SOA, as in life, for any given service request you will be deciding between these three service delivery patterns:

Asynchronous: The service request is posted by the client with the expectation that the action will take place at the server’s leisure and that the client will not expect a related response from the service call. As the client is not waiting for an immediate response, he/she can continue to do whatever it is that clients do. The service is posted asynchronously and possibly queued up in a wait area until the system (the server) is able to process it. Any response resulting from processing the asynchronous request will also be sent back asynchronously to the client.  The service interface designer is responsible for defining and filling-in a correlation identifier, if there is a need to match a request with its response. An example of asynchronous exchanges is a request for support from a vendor via email, with the expectation (but not certainty!) of a reply sometime later. Implicit in the way asynchronous services are handled is the idea that a queuing system of some sort must exist in the system infrastructure to properly handle the various aspects related to this pattern: How do we ensure delivery of the request? How do we prioritize the handling of the service? In the email example, the mail server takes care of all these details.

Query/Reply: This is the predominant service pattern for transactional systems. Here, a service request is made with the expectation that a response to the request will be given immediately. The fact that the client actually waits for a response gives this pattern very definite sensitivities as far as performance is concerned. If email exchanges are a representative example of asynchronous exchanges, you can think of chat or even telephone exchanges as an example of Query/Reply. Instead of sending an email, you establish a two-way real-time dialogue between yourself and the service provider.

Event Driven. This pattern is also known as Pub/Sub because it relies on the Publish/Subscribe idea. In this pattern the service request is for an asynchronous response that will take place upon the satisfaction of the event criteria. This pattern is typically used in a manner similar to the synchronous pattern in that the calling client need not wait for a response, but on occasion, a design may call for the client issuing the subscription request to sit idly by until a response occurs.

With that covered, let me now display a sample generic service flow, orchestrated from a putative airline reservation application with a client requesting via a natural language interface, all available flights to a chosen destination. The example shows a number of service types interacting to construct the appropriate response. 

Hopefully most of the diagram is self-explanatory. The services shown to the left of the vertical line are meant to indicate those that can be accessed by the outside world and are thus considered to be Access Services. The Natural Language Parse, for example, could well be an external service provided by another company on a SaaS basis. The Update Customer profile could be available to external B2B partners to update the profile as per commercial agreements.  Clearly, the Find Best Fare service could also be made available externally if desired, but the example here depicts a Best Fare Service that is applying internal rules that we do not wish to expose to the world.  The various services could be classified as follows:

Understanding the attributes of each service will enable you to apply predefined standards for their use. For example, Access services will be expected to provide public interfaces and will be hardened for public use. Access services are also cases where you may have to keep state across multiple service calls. Such state information may have to be kept in non-volatile storage (disk, or replicated cache). Composite services will be allowed to keep some state, but only for the duration of the service call. Atomic services will have highly streamlined execution paths, including avoidance of state.

Ideally, everything would follow an asynchronous pattern in the sense that not having to wait for a response is the most flexible way to optimize system resources and meet service level agreements. However, the reality is that you may need to adjust the overall solution against this ideal. Designing a system to do asynchronous messaging whenever possible may be seen as a desired goal, but fact of the matter is that you will need to use the Query/Reply patterns more often than not, particularly in transactional environments, to ensure prompt responses. Alas, I have witnessed actual designs that attempt to force asynchronous patterns in transactional systems (making everything flow through queues); resulting in very odd behaviors and unsatisfactory performance.

Finally, there is another category of “services” I have not yet defined. These are the services needed to facilitate or simplify the workings of SOA. I refer to these services as meta-services, and they are usually called upon to perform a specific SOA activity such as ensuring transaction integrity, forking the delivery of a service request, routing a service request to an alternate location, and other tasks.  In fact, there are various patterns identified for these types of services, but the most interesting aspect is that a portfolio of meta-services is being bundled and it comprises a large portion of what is rapidly evolving to be a separate SOA middleware enabling layer: The Enterprise Service Bus. 

If you recall the SOA taxonomy that I presented earlier, I will include these Enterprise Service Bus elements as part of the Service Fabric, to be discussed at a later date.