What Is SOA Anyway?: Part I, Ambiguity

Service-Oriented Architecture (or SOA) has been with us for quite a while.

Yefim V. Natiz, a Gartner analyst, first Service-Oriented Ambiguity. Martin says that the question "what is SOA?" is impossible to answer because SOA means different things to different people. While it is true that the term has been overly used, at least few of these "definitions" are plainly wrong. Let's take for example the definition that says SOA is exposing methods through Web services.

A common misconception about SOA is that using web-services technology makes whatever you are using SOA. The core reason for that is the poor naming choice for methods that are exposed through http which were named web-services. For example, one of the popular books on SOA "Service-Oriented Technologies: A Field Guide to Integrating XML and Web-Services" by Thomas Earl gives the impression that SOA equals WS* (even though that buried in the book, there's an explanation hat WS* is not the only possible technology for SOA). There are many other sources that give the same impression.

Nevertheless, Just a bunch of web-services (JBOWS as Joe McKinderik named them) does not an SOA make. In fact that's not really making anything new. Using http and WS* protocols to expose a method isn't really different from Remote Procedure Calls (RPC) using any other technology be that CORBA, DCOM or anything else. The way I see it saying that SOA is using Web services is just plainly wrong and not away to define SOA.

Another definition Martin mentions is that another widely used definition for SOA is "EAI without all the expensive EAI vendors locking you in". EAI emerged as an attempt to solve the Enterprise integration spaghetti. While it managed to solve the problem of connecting applications and transferring data between them through a semi-standard way. I agree with Sandeep Arora who said that basically EAI failed to deliver its promise as it is.

• Ddata centric and not process centric.
• Can't keep up with business process change.
• Does not address the business process.
• And that EAI solutions are technically very complex, need specialized skills and are very expensive to maintain.

Whether Arora is right or even if EAI is the best thing since sliced bread, if we do EAI using Web-service technology to get "EAI without the expensive EAI vendors locking you in" (which I also have een called SOI, or Service-Oriented Integration) we are again not doing anything new, we are just using a new technology to achieve an existing way of thinking or architectural appraoch.

Martin claims that the SOA acronym is beyond saving and that the (sometimes) good ideas that are all called SOA need to have their own name and independent life. However the way I see it the examples Martin provides are "just" misuses of the term. I think that the fact that someone uses a term wrongly does not invalidate the correct term. Nevertheless, SOA troubles do not end here, since there is the hype also lures behind the corner to dilute the SOA term as well. I'll talk about that in the next installment.

Posted by Arnon Rotem-Gal-Oz at 04:01 PM  Permalink