Defining "Service Oriented Architecture" by Analogy

This post is the first in a series over the next few days that in total will attempt to lay the groundwork for a discussion of applying the Service Oriented Architecture (or SOA) software design pattern to systems and solutions in the library space. It starts with comparing the SOA concept with a multi-modal transportation network. Subsequent posts will outline use cases and describe how SOA can be applied to libraries.

An Analogy: Transportation

Imagine for a moment that you have a goal to get from your house in Cleveland, Ohio, to a hotel in Denver, Colorado. How might you accomplish this? Perhaps you will drive in your car to off-site parking near an airport. You'll park your car and ride a shuttle bus to the airport where (if you successfully get through security) you board an airplane for Denver. When you get off, you walk to the taxi stand and take a taxi to the hotel.

Each of these modes of transportation -- your car, the shuttle bus, the airplane, and the taxi -- came together as you needed them. Or, said another way, when you set out from your home in Cleveland, you had not specified the entire transportation network from exactly which shuttle bus you would take to exactly which taxi you would use. In addition, at the intersection of each of these transportation modes -- where one mode stopped and you were not yet at your goal -- there is likely more than one option you can use that will take you a step closer to your destination. For example, you could have started from your house with a walk to a light rail station that took you directly into the airport terminal, thus eliminating the car ride and the shuttle bus.

In this analogy, one could call the transportation modes "services." A service can be defined as "the capability to perform work for another, the specification of the work offered for another, and the offer to perform work for another." OASIS Reference Model for Service-Oriented Architecture, Committee Specification 1, dated 2 Aug 2006, lines 169-171. The document was retrieved from http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf on 18-Sep-2006. The car, airplane, bus, taxi, and light rail are all services used to reach the end goal.

Definition

In the same way that the airplane, bus, taxi, and/or light rail came together to form a transportation conglomerate, we can combine units of software applications in new ways to reach goals. This pattern of combining pieces to reach a whole is called "Service Oriented Architecture." For a formal definition, one can turn to the OASIS Reference Model for Service-Oriented Architecture which says

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. A product of the OASIS Service Oriented Architecture Reference Model Technical Committee (abbreviated as OASIS SOA-RM TC), Committee Specification 1, dated 2 Aug 2006, lines 128-129. The document was retrieved from http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf on 18-Sep-2006.

But what of another alternative to our transportation analogy -- you could have driven your car the entire way from Cleveland to Denver, right? That is a single service that would certainly allow you to reach your end goal. Is it the most efficient way, though? The cheapest, fastest, safest? To continue the analogy into SOA, reaching your goal in this way is like "hard coding" an application to do only one thing. By making this choice to structure the solution as a single path, options that may be cheaper and more efficient over some portion of the solution are eliminated.

There are several key aspects to pull out of the OASIS OASIS is the Organization for the Advancement of Structured Information Standards -- a not-for-profit, international consortium that sponsors the development and adoption of standards for security, e-business, and for public sector and application-specific markets. definition that distinguish a multi-modal system from a single tool solution. First is "distributed capabilities" -- the concept that the solution's components are not collocated. In the transportation analogy, the car, bus, airplane, and taxi are spread across the continent. In a system based on the SOA concepts, services are spread across the network. A corollary to the "distributed capabilities" concept is that the components are found and brought together on an ad hoc basis. Just as the how the shuttle bus, airplane, and taxi were brought together in the right sequence of time and space, components of of an SOA system can be discovered and linked at the time of the request of service. In a static system, as with the car-only analogy, the components are pre-defined to run in a single pattern within a closed system.

The second distinguishing characteristic is arguably more important than the first: the distributed components of the SOA system "may be under the control of different ownership domains." Back to the analogy -- there isn't one entity that owns the car, the bus, the airplane and the taxi. Yet these components, in spite of different business rules and schedules, come together in a solution to transport you from here to there. The same is true in SOA systems; in an e-commerce transaction that results in the shipping of a Bose QuietComfort 2 Noise-Canceling Headset from Amazon.com to your home, you can bet that as part of the execution of that request there are communication between Amazon's order fulfillment services and UPS's shipping manifest services.

Next up...

The next posting in this series will look at a few use cases and begin to describe the granularity of the term "service" in an SOA.