 |
|||||||||
|
|||||||||
|
|
Lately there has been a huge buzz about SOA. Ever since Web Services started gaining more and more traction and momentum, the big buzz has been all about how some of the most amazing things in the software world can be accomplished using Service Oriented Architecture. There are a lot of really good things about SOA, and there are some drawbacks that make it far less of the panacea many people are claiming it to be.
First, the problem is that the concept of what defines SOA is actually pretty vague. If you know where to look, you can get some pretty concrete definitions. The problem is : the right people are looking in the wrong place. For example, I once interviewed for a position where the manager asked me what SOA was. I gave him my full and complete definition of the concepts revolving around loose coupling and Real and Artificial Dependencies. The manager's eyes glazed over. I didn't get the job. Later, he told me "I can't believe that someone with your credentials didn't even know that SOA meant Service Oriented Architecture".
The problem with buzz-words is just that: They are buzz-words; meaningless contrivances designed to make largely technical concepts boiled down into cute little bite-size candies that can be swallowed by even the dimmest of upper management's representatives. When management tells you to use a technology because they saw it on G4TV or because they read about it on someone's blog, and there's no more information other than that <insert buzzword here> is the newest, coolest, thing: run for the hills, and if you look back you will be turned into a pillar of salt.
So what is SOA? Well, the core of Service Oriented Architecture is the accomplishment of loose coupling through the dramatic reduction of what is called Artificial Dependency. A Real Dependency is where one system depends on the features and functionality provided by another system. This type of dependency is omnipresent, and cannot be mitigated, nor would you want to. The dependency is there for a reason. An Artificial Depedency is a constraint placed on a consumer by a provider that has little or nothing to do with the actual features and functionality of the provider. For example, DCOM places network constraints on consumers. Some services require a specific version of Java to be the only legitimate client consumer. The meaningless and often random injection of code that satisfies buzzword compliance by upper management is also an Artificial Dependency.
When you have removed the Artificial Dependencies (or as many of them as are practical), then you have achieved loose coupling. You have reduced your distributed system to its purest components: a provider of a discrete, re-usable service compatible with all consumers that utilize the same information schema and a consumer of a service that can consume any service of that type and is not bound by artificial constraints.
Sometimes a real-world scenario makes SOA easier to understand. Take something that is near and dear to my heart and many others: My Xbox. This device is a service provider. It provides an entertainment service to the consumer, you. You provide input in the form of games to that provider. The provider then processes (plays) the input information (games), and outputs the desired result (massive killing action, high scores, death to your opponents, and bragging rights). What separates SOA from traditional OOP thinking is the idea of loose coupling. Your Xbox isn't required to only play games that you purchased. Anyone (assuming they had your house key) could approach your Xbox, insert an Xbox game (information that complies to a well-known schema), and get their frag on. Conversely, games that you own can be used in other people's Xboxes. You, as the service consumer, can consume any Xbox service and any Xbox can accept input from any consumer. This is what makes that system, and SOA systems like it, truly service-oriented.
How does this type of architecture help people in the real world? Once you start thinking in an SOA mindset, its hard to go back. Everything is a service, and you start seeing SOA models in everyday life that you can then relate to your own software engineering efforts. For example, picture a hypothetical parent company that has aquired several child companies. Each of these child companies provides a unique product, and manages its own inventory and pricing. The parent company wants to create several unified storefronts, each branded to a particular style and logo, that consolidate all of the product catalogs into a single location. Without SOA, this type of development effort would be extremely difficult, and the end result would be both rigid and brittle - the antithesis of SOA. So, the hypothetical company decides to create a Product Catalog service that will be hosted by each of its child companies. The unified storefront can then consume the product catalog service from each of the identified product suppliers through a central dispatching service. Credit card purchases and package shipment can be dealt with using additional services. This architecture allows additional child companies to be aquired, additional purchase models to be implemented, and even additional shipping vendors to be added without dramatically impacting the system or requiring heavy amounts of refactoring.
The picture here illustrates how SOA implemented in this fashion can create a system that is loosely coupled, designed to scale, insulated from change, and just plain powerful.
And, in the words of Forrest Gump: That's all I've got to say about that.
