01/20/08 :: [SOA] Understanding SOA [permalink]
It seems to me that somewhere in all these discussions we have lost the understanding of SOA. You read the different SOA columnists every week and you don't get a sense of people having a clear understanding about SOA, everything and anything seems to be said about SOA, good or bad, for or against it, SOA is this or that... Things like EDA or ROA have simply added to the confusion.
Ok, I acknowledge that the SOA technology stack is not the cleanest, and I don't want to go there to explain my understanding of SOA. I don't think looking at the OASIS SOA Reference Model is going to help you either because this work was done from a "service" perspective, not a a Service Oriented Architecture perspective. The SOA RM is rather a Service RM (at best). It is a collection of facts about services coming from different specifications rather than a deep understanding of what is a Service Oriented Architecture is and where it may apply. It is an a posteriori justification of some spec work.
So, what's the problem we are trying to solve?
Up until the emergence of the Web technologies, there was no capabilities to construct solutions from components running across wide area network boundaries, often across company boundaries (the WAN was not really there either). Let's take an example. In 1999, I designed and built for NEC System Labs a procurement solution that would let you browse catalogs running at different suppliers (off premise) and drag an drop items in a shopping cart running on your own servers (on premise). I used IE's new drag and drop capabilities, the wonders of HTML in terms of presentation aggregation and some XML product descriptions. The procurement PO (after being accepted) was then processed and dispatched to all individual suppliers using a standard called OBI (Open Buying on the Internet). These were the days and small standardization groups were forming such as the ECO framework and small startups such as Veo Systems.
The bottom line is that without these technologies, procurement solutions required complex catalog aggregations and constant updates to run the who stack and product catalog on premise.
In another context, in 2001, Amazon realized that it could not scale with a monolithic application model. Different pieces of their "application" had widely different scalability, availability and security requirements, maintenance cycles... So what did they do? they broke it up in lots of pieces assembled again at the presentation layer.
This is all great, but in the case of my procurement solution (and probably in most cases for Amazon -though this is pure supposition) there was no server-to-server communication. All interactions were mediated by the user drag-and-drop action in the browser.
At the end of the day, SOA is an architecture where elements of the business logic are factored in autonomous software agents which can interact. The picture below represent a basic reference model for service oriented solutions.
The solution is assembled as a series of units of work (activities) from a series of software agents of three basic types:
- human tasks
- services
- coordinators
A coordinator is a software agents that supports the interactions of other software agents (a directory, a transaction coordinator, a pub/sub engine, an activity lifecycle service, various security services, a choreography context service... are all coordinators).
Services can be Resource Lifecycle services,, decision services, master data services...
Typically services, human tasks, and sometimes coordinators run in a container. WCF is a service container, and ESB is another one. A task engine is a human task container. It manages task lists, and tasks lifecycles. From a service perspective, a human task looks like any other service.
It is perfectly ok to build your own service container and even have more than one container in your SOA (not too many though because they share common infrastructure and operations technical services). Different service containers offer different capabilities. For instance WCF originally did not offer any back-end integration. It made WCF good for writing services in .Net languages but not really well suited to front-end legacy applications. It is actually fairly rare to think you will re-implement your services entirely. If your legacy application supports it (in terms of scalability, availability and security) you may want to invoke application components as part of your service implementation. Legacy applications become "systems of record" and manage the content of "resources" such as Purchase Orders, Invoices... Resource representations are exchanged during service and human tasks interactions as work is performed to advance their state and populate their content.
I think today, Amazon is one of the best examples of Service Oriented Architecture on the planet from front to back. I don't think the picture I represented above would be news to anybody there.
Now I had promised Subbu a long time ago to explain how "choreography" fit in the picture. More recently I had discussions with Francois Leygues, a French Architect, who is building RESTful solutions. I think our discussion has been very constructive and we ended up talking about choreography and assemblies. Stu Charlton also suggested to use choreographies to describe the interactions of the resources.
I worked on the concept of "choreography" for 6 years. I worked with a bunch of great people: Dale Moberg, Monica Martin, John Yunker (from Amazon), Bob Haugen, Sally St-Ammand... and many others (sorry I don't recall all the names). There were a fee dark characters too, they ended up giving up because of our passion. They all quitted, one after the other, sometimes after we uncovered their little scheme (yes, this is what happens in standards group, so don't be surprised at what comes out).
I told Francois that even though I worked so much on Choreography, I did not think this was an appropriate technology to model service interactions in the enterprise. "Choreography" is a concept that makes sense for B2B.
The reason is quite simple. In B2B when you have hundreds or thousands of business partners you need to tell them how you expect the interaction to happen. They can use it at design time, and also at run time to validate that a message is not going to violate the expected sequence of messages. Imagine if dozens of business partners start sending you out-of-sequence or erroneous messages. Since a lot of these message exchanges involve a "business transaction" with transfer of value, they are not trivial to compensate in an ad hoc fashion.
In the enterprise when a service is reused in different solutions, the choreography is going to change (slightly) because the solutions will be different, assembling different services. Creating a choreography for a single unit of work is lots of work. You are much better off creating an assembly. A choreography is actually quite a strong coupling too, at least it is going to be of no help to diminish the coupling between components. It works well in B2B because you want to lower the cost of bringing new partners in, and choreography are the best way to do that. In the enterprise SCA gives you a very powerful assembly mechanism that allows a single service to participate in different solutions (even with different configuration parameters). IMHO, SCA is bound to take off over the next couple of years as the keystone of SOA. It is unfortunate that one more time, the politics behind vendors and some individuals are preventing that to happen faster -we all loose because of a handful of egotistic people- but it will happen, you can trust me, like I think you have trusted me for the last 7 years when I talked about BPEL as a programming language or the architecture of business process engines as being decentralized, or yet again when I talked about an emerging service oriented, process centric, model driven programming model.
For the record, in the OASIS bBP group we have nothing to sell, only our passion and knowledge to share. You'll never catch any of us making recommendations that we don't believe in or that we have not verified. This is the culture that we have successfully grown into our group, and I have been really proud to be part of this group. All I ever learned on SOA and B2B, I learned it in that group.
Voila, I don't think SOA is that complicated, there are tons of solutions which value can be augmented by leveraging off premise software agents and there are tons of solutions that can offer some value to other solutions should the technology that allow them to do so exist (and they do exist). This is what SOA is about, it is not about REST, WS-*, SCA or BPEL. There are many ways that lead to Rome, I have to pick one, I can show you which one I pick, I can explain why I picked this one, but this is your choice and your choice only. I don't want to sway you behind be, I might even follow you at some point!
SOA is exciting, it is the way forward, because reuse makes sense and contrary to what people tell you reuse works provided you know how to factor what needs to be reused and leverage the right composition technologies. SOA is also exciting because for the first time we have a programming model aligned with business processes. The next ten years are going to be fascinating.
Have fun !