SOA and OO contd…


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.


 


 


 


Comments (7)

  1. RebelGeekz says:

    "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"

    Daily tracking of tens of millions of FedEx shipments

    Daily orders and replenishment of Walmart inventory

    I work everyday with this kind of scenarios, millions over millions of transactions, and it will be hard to replace EDI unless there is a better format and XML unfortunately sucks in this area.

    Compare an invoice in EDI with its XML counterpart and you will understand why sending thousands of XML documents per hour would be a great mistake.

    "Wouldn’t it be better that the wire-format can be chosen using policy assertions?"

    NOW we are talking…

    Looks like we’ve finally seen the light at the end of the tunnel.

  2. ramkoth says:

    RebelGeez

    I understand your concerns. It is a typical 80/20 scenario. But, even if you take your case, web services based design should work with out much difficulty.

    Let’s do a little math. Let’s say that you want to process a million transaction over a period of 10 hours (I am not assuming batch processing here). That boils down to processing ~28 requests per second. If you have sufficient network bandwidth, this is not something that sounds imposing. Assuming that the processing is not CPU intensive(which is usually the case), a decent server can handle this load.

    Of course, if you want to process more messages (let’s say 100-150) during peak time, scale-out architecture of web services can be helpful in processing more messages. Only constraint in that case would be network bandwidth.

    It would be great if you can share the summary of your benchmark results.

  3. Rajiv says:

    Design in SOA is pretty much functional decomposition of the architecture. At the lowest level – programming – SOA says very little, and coexists with OO perfectly

  4. Steve Zagrobelny says:

    "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. " What makes up the XML payload that causes performance degradation? My problem is SQL searches that return fast when initially run, then slow as the day goes on. Does the "XML payload" have anything to do with this?