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."
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
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.
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.