I just read the article linked above and I have to tell you I am never surprised at how often I hear old ideas repackaged as new ones and then marketed aggressively like they were some kind of handed down wisdom. The truth is, SOA adds very little but a buzz word. Grady Booch was talking about loose coupling being imperative for programming in the large, as he put it, back in 1994. Back in 2000 the buzz was “Component” architectures and further back it was “Object-Oriented”. The problem is not with the technologies, it is with the people.
The people doing these service oriented architectures or object oriented architectures or component oriented architectures are the ones that break the loose coupling it is not the architectures. The article mentions that OO programming looks at a CD as if it should come with a playing mechanism. If that is what the author thought OO was about, then he missed the point. I never looked at it that way and I have written thousands of lines of OO code. Why do people break the loose coupling? Because they need to meet a deadline and there is no time to “get it right” so they cut corners.
The people selling these development products and deployment platforms are also to blame. How else are they going to generate more sales if they don’t change what we should be doing every few years. BEA was all about J2EE architecture back when WebLogic was first getting off the ground. Then it was Web Services, now it is SOA ( Web services with a fancy new buzz word ).
So what is new in SOA. Nothing, I just put that in to be funny. In this article Werner Vogels tries to dispel some of the misconceptions about web services and SOA.
From Mr. Vogels’ article:
RPC provides a network abstraction for the remote execution of procedure calls in a programming language. It provides mechanisms for identifying a remote procedure, for deciding which arguments to the procedure are in arguments and as such need to be provide to the remote procedure at invocation time, and which arguments are out arguments and need to be presented to the caller at completion time. It also includes extensive mechanisms for handling errors both at the runtime and the programming level. Web services in their basic form provide only a networking abstraction for the transfer of XML documents, and the processing of these documents by a remote service entity. Web services have a notion of actor or role that identifies the service that should consume the document, but there are no predefined semantics associated with the content of the XML document sent to the service.
This is true. But it is also true that when a software engineer sits down and writes the code to send a particular XML document to a particular Web Services he or she expects a particular result to occur. How is this really any different then a call to a J2EE stateless session bean, for instance?
When I lookup the stateless session bean the JNDI provides a mechanism by which the deployer could configure the application to use an alternative implementation. Just as with a web service.
I encode the data being sent to the session bean in a manner consistent with its defined external interface. In a web service, if I send an XML document that does not conform to it’s expected format, I will not get the result I expected. J2EE has the advantage of compile time checking for this. XML is a more expressive format than Java objects. However, XML is also very expensive to parse, especially if a validating parser is used which, I would expect, is a requirement for a robust Web Service.
The truth is, loose coupling can be accomplished in any system. In C it was with function pointers and RPC. In C++ it was with virtual base classes that defined only interface. In Java it is interfaces. With CORBA and COM it was IDL. Now with Web Services it is SOAP and REST. None of these mechanisms will prevent engineers in a pinch from circumventing them. And that is where the problem lies.