When I looked back at my last blog on SOA and OO, I figured out I digressed a little bit from the topic that I wanted to address. It was late in the evening and my mind was as quiescent as the little stormy weather that we were encountering in Redmond. In that post, I talked about first class abstractions required to build business applications or services and how OO fits into scheme of things. Simon Guest also has an interesting post on this topic.
In this post, I want to stick to the original topic of SOA and OO. SOA’s basic premises are
· Business systems are autonomous. They evolve independently of each other. They protect their internal state. For example, most enterprises use Siebel for CRM, Peoplesoft for HRMS and SAP for others.
· Corollary 1- Heterogeneity is the reality.
· Corollary 2 – Loose coupling is necessary for interaction between these systems. Otherwise, a change in one system (like upgrade) will have serious consequence on other systems.
· This one is little bit controversial. Business systems don’t trust each other and hence doesn’t support Atomic transactions.
When you are building a system that automates certain business capability, it is better to expose them as services as at some point of time, this system needs to be integrated with other systems. SOA talks about variety of design elements such as Service contracts, granularity of the service request, service agents, business process that span services, messages as a means to carry the request, canonization of schema as lingua-franca between services etc. You can read all about that in this primer.
OO for service implementation
Consensus among various people I talked to is that OO can be used for implementing the service. I have seen approaches that uses a service facade which then internally uses business components to fulfill the service request.
But, you still have to think about the top level abstractions that are listed in my previous post.
I have been asked if SOA can be realized using Distributed objects technology. Yes, it is theoretically possible to build SOA based apps based on ORB technologies like COM or CORBA(yeah, yeah, i know CORBA is a 'standard' - a standard not followed by too many people). But, what you lose is loose coupling - which will come back to bite you after a while. You are better off sticking to a standard such as SOAP/XML/WS-* specs.
Another frequently asked question is: Isn't it the case that the usage of web services impede performance due to XML payload crap? Wouldn't it be better that the wire-format can be chosen using policy assertions? Well, Indigo will definitely help you there. But to start off with, i don't think that the performance degradation due to XML payload is really significant for most business applications, unless ofcourse you are building a real-time system that has to handle thousands of messages/sec.