Mike "Wolf" Gilbert, tries to answer the question - "What is the point of SOA; what are we trying to achieve with it?" and comes with insightful answers. Excerpts with edits:
The traditional answer of lines of better interoperability as the need for SOA may not be fully correct. SOA is a new thing and the Web Services are absolutely fundamental requirements for it. Perhaps the prevalence of this point of view is what leads to the belief that it is all about interoperability. If you subscribe to this point of view, in an IT shop that is entirely Microsoft or entirely a specific flavor of Unix and does no electronic business with other companies, there may be no need for interoperability!! but still there could be benefits of SOA.
SOA is a paradigm, a way of thinking about the interaction between component parts of a system, in the same manner as OO but with a completely different perspective. Instead of imagining discrete bundles of both data and operations as “Objects” that know how to do things to themselves, we are breaking the solution down as a set of “Services” that know how to understand “Messages” and do something useful with them. The separation of data from the operations performed on that data is key here.
Let’s explore for a moment the “Four Tenets of SOA” as proposed by well accepted views of Don Box:
1. Boundaries are Explicit
2. Services are Autonomous
3. Services share Schema and Contract, not Class
4. Compatibility is based upon Policy
- The first Tenet states that the author of the each service defines exactly what messages it will and will not react to and the only interfaces available to send or receive these messages are those defined by the author.
- The second explains that these services are not subservient to other code, this is to say that a service reacts to a message – how that message was created and what will happen to any response the service creates is immaterial to the action that this service will take.
- The third Tenet states simply only messages pass from service to service, code does not and that these messages are not random but a sequence of one or more that have been agreed upon. Note that Schema mentioned in this Tenet does not necessarily imply XML Schema, merely that the message format is explicitly defined.
-The fourth is interesting; we are saying that each Service has a set of Policies that it expects to operate under and it is not prepared to operate unless these Policies are satisfied (a policy might be: I will except messages from any source, but if the message is not from my subnet then it must be signed and the only signature I will accept is X509). Of course this has always been true because systems are always designed such that individual parts work together under a set of policies, but usually these policies are implicit - Tenet 4 implies, although doesn’t actually state, that this should be explicit and further more if it is both explicit and machine readable then truly great things can come of it.
Many of us have built systems that comply with all of the above Tenets long before XML and Web Services where ever thought of so very clearly this is not a new thing. All that said, Web Services, XML Data, XML Schema and the WS-* protocols bring an ideal environment in which SOA may flourish. For whatever reason, XML has become the de facto standard for sharing data across system boundaries, XML Schema allows these “Messages” to be described in a language independent manner and the WS-* protocols provide an excellent opportunity to make Policy both explicit and machine readable - this is the driving force behind the resurgence of SOA. The actual goal of SOA - isn’t interop; if that is all you want then sprinkle a few Web Service interfaces on your existing design and you will have opened up your application to all platforms - but you will not necessarily have benefited from SOA. The whole reason for doing this is to be able to Manage Complexity. A well designed Service Oriented system may well be more complex than it might otherwise be, but what it will be is manageable. Because of the Autonomous nature of the Services, because of their Explicit Boundaries and because the Message Flow is defined by Schema and Contract, component parts can be moved, augmented or even replaced as the needs of the organization change. If the Policy is explicit then the impact of these changes can be readily assessed and indeed if it is machine readable then a toolset can be develop to ensure it is done consistently and correctly.
|
