I have just started to look into Service Oriented Architectures (SOA). As of yet, I have not really formed any crystal clear understanding of the concept - but from my investigation so far, I gather it is prudent to distinguish between SOA and Web Services (WS). I probably better come clean and reveal up front that this post it not really about SOA or WS, but about how people explain the concept of services. I have been looking around for introductions to and discussions of services, and after reading a few, I noticed something funny: People often refer to object oriented (OO) programming when explaining services, but there appears to be quite a bit of confusion about the object oriented paradigm.
To be real blunt about what follows, I am not out to defend OO in the face of SOA. As mentioned, I know pratically nothing about SOA and I have no idea how SOA compares to OO. I am just puzzled when someone tries to explain a concept by relating to another concept without a real clear understanding of this other understanding.
If you google for 'SOA', you will find an article by Hao He at webservices.xml.com among the first few search results. In this popular introduction, the SOA concept is explained through a Compact Disc (CD) example, illustrated in both SOA and OO terms. Thus, the article contains the following description:
"So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems."
I am not sure I follow the article's line of argument, but why would an OO CD need to come with its own player? Maybe the author arrives at the above conclusion because of encapsulation (an OO entity should encapsulate its data; the data of a CD are tracks and track information and CD tracks are accessed when a CD is played, so an OO representation of a CD should provide a play() operation) or semantics (being played is what happens to a CD, so an OO representation should provide a play() operation)? I am not sure, but the above description is misconceived. If we consider the real life phenomenon (always a good starting point for OO design), a CD does not come with its own player and a CD does not know how to be played. So why whould the OO representation? In real life, a CD player uses a laser beam to read the tracks and track information (from the physical properties) of a CD. So perhaps the OO representation of a CD should provide an interface that enabled clients to read track and track information? E.g. through getTrackInformation(), read(), read(int track) or readNext() operations?
Another claim held against OO is that OO is not sophisticated enough. In his blog, Simon Guest, explains how services help remove the intimacy from distributed computing. Simon does so by referring to an example of two entities, A and B, where A wants to borrow $5 from B. The interaction concerning the loan is both illustrated if A and B were objects, and if they were services. In the case of OO, the loan transaction must be carried out in a single and very simple operation invocation, where A basically snatches the money from B's pocket (as in B.getMoney(int amount)). In the case of A and B being services, the loan transaction is allowed to span multiple interactions - A requests the loan, B determines if A is eligible, based on the state of A and prior interaction between the two and B finally accepts the proposal.
Why is that? Why are concepts, such as conditional request, validation based on previous interaction, return enquiry of requestor and proposal accept not allowed to be represented in the case of OO? SOA might provide shortcuts to representing these specific concepts, but I do not see what prevents me from designing the exact same, rich interaction, using OO representations?
Finally, I have come across ramkoth, who in his blog claims that the OO paradigm provides the wrong set of abstractions. Ramkoth describes how different abstrations suit different technologies and concludes that OO does not provides 'first class' (ramkoth's term, meaning 'most suitable') abstractions for building business applications. Since OO does not readily provide representations of such concepts as customer, employee, business rules, business process, business workflow, OO is more suitable at lower levels of abstraction. I think it is the other way around: OO provide a more general set of abstractions. There is nothing to stop you from representing such concepts as 'customer' or 'business process' using OO (and ramkoth does not say so), but there is no intrinsic support for these concepts, you have to define them yourself.
If you enjoyed this post, make sure you subscribe to my RSS feed!
