You are hereDefining “Service Oriented Architecture”

Defining “Service Oriented Architecture”


By admin - Posted on 09 April 2009

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.” 1 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 for Service-Oriented ArchitectureL3 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. 2

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 3 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 of that request there are communication between Amazon’s order fulfillment services and UPS’s shipping manifest services.