Friday, October 16, 2009

The SOA Framework

Early Ford Model Ts were the most successful automobile for a good portion of the twentieth century. Millions of Model Ts roamed the roads of America, and if you had opened the hood of one of them, you would have found a very basic machine design consisting of an engine, a magneto (similar to an alternator) and perhaps a battery.
In contrast, when looking under the hood of a modern car, it’s easy to be bewildered by its complexity.  With their fuel-injection systems, anti-lock brakes, intelligent steering systems, safety mechanism, and many other features, a modern car can better be described as a computerized mobility machine. About the only thing Model Ts have in common with modern cars is the fact that they both move.
Trying to explain the workings of a new a vehicle in terms of 1920’s terminology is almost impossible. Such an explanation requires the use of a new language. The same is true for SOA. The traditional computing paradigm of centralized mainframe-based processing represents the Model T of computing, and designing and explaining SOA, even if only to represent another computer environment, requires a new language.
This new language would have more in common with, say, the language used to describe a Broadway play or the workings of  interacting organisms in biology than with the language used to describe the original computing paradigms (a “computer”, after all, was a term originally used for the female staff in charge of manually performing census calculations). In this new language you have actors playing the roles of specific services, a script to define the storyline and the orchestrators to execute it.  SOA is a play; not a monologue.
Still, regardless of the internal workings, a new car still requires the existence of a command console, an engine, and wheels and chassis.  SOA can be defined by the Presentation, Processing, and Data Layers. The Presentation occurs in the Access space, and the interface could be viewed as a “membrane” enclosing the system. The Processing layer provides the orchestration of services and the Data represents the stuff that makes it all worthwhile.
Remember, the SOA meshed diagram I showed you earlier?

The diagram gives a somewhat chaotic and anarchic representation of the manner in which a truly distributed service oriented environment operates. It behooves us to impose some order and structure so that the actual SOA system is something we can implement and operate appropriately.  I refer to this structure as “The Framework”; the following are its elements:
·         The Access.  No matter the system, the objective is to ultimately interface with humans. I spoke early on about possible interface technologies in the future, from 3D Virtual Telepresence to technologies that can be implanted in our bodies to extend our senses in a seamless way. We are already living in a time where the access mechanism is becoming irrelevant to the engagement experience. You can check out your Facebook wall from a PC, a cell phone, an iPod, or a game console.
·         The Membrane. If we can envision a world in which we utilize a variety of access devices, we can also envision their touch points as a membrane. The advent of cloud computing already provides the cloud as a metaphor, but the cloud metaphor serves best in depicting the manner in which virtualized computer systems are integrated as a whole working unit. The membrane represents the interface to the information services.
·         The Orchestrator. This is what I like to call “The Wizard of Oz Booth”. The magic behind the curtain is represented by the process rules, information gathering decisions, and alternative workflows evaluated and chosen by the orchestrator.
·         The Fabric. There is no civilization without infrastructure. Indeed, many could argue that civilization is infrastructure.  And what’s infrastructure? Anything that we can bury beneath the ground, that is not dead, and that provides a service in as transparent a fashion as possible is infrastructure. However, I chose the term Fabric because this term better conveys the dynamic nature of the supporting infrastructure. Fabric has two connotations, one as an entity producing goods, and the other as the material substance that forms SOA.
·         The Data Keeper. In a proper SOA environment, even data should be abstracted to be accessed as a service. Similar to the role of your high school librarian, you need a formalized Data Keeper responsible for abstracting the access and maintenance of data to ensure no one has to worry about such details as to whether data is being stored in old Phoenician tablets, Egyptian papyrus, Monastic scriptures, ferromagnetic storage, or any of the modern or future ways data is to be stored.
In the future everything will be virtual, an abstraction. Enabling this capability is the role of the SOA Framework. Next I will describe in detail each of the previous SOA Framework elements.