« What SOA can learn from Web2.0 Part 1-productivity matters | Main | A selection of SOA chat: On REST vs Web Services, Cape Clear selling their ESB to ... the ESB, and the surprising appearance of SOA 2.0 »

I was genuinely surprised by the interview with Sun’s Tim Bray in SearchWebServices. I am always careful about reading too much into such a piece as editing and the shortness of the format often hides the real intention of the speaker. However, in this case Tim makes some pretty sweeping comments that gave me the impression that Sun’s Web Services and SOA strategy is at best deeply confusing if not actually deeply confused.

First off, Tim Bray doesn’t like the term SOA because he “can't explain what the difference is between SOA and Web services and I'm not sure I've met anybody who actually can without going into paragraphs and paragraphs prose”. In response, I will quote wikipedia.org’s definition of SOA :

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (e.g., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

80 odd words nail what SOA means and how they are distinct from Web Services (pick many other sources with similarly short descriptions) – although it is interesting to note that it includes REST within the definition of Web Services which is less common. The difference is SOA is a general architecture, Web Services a specific technology: you can implement SOA without Web Services – using Plain Old XML or REST or something else to create a Service Oriented Architecture.

“Web-style” is Tim’s preferred term to SOA because “it really means something”. Unfortunately in this article, he doesn’t say what it means beyond a comment that it focuses on “exchange patterns” which sounds a little like an Event Driven approach – which is certainly a well established and effective style of integration architecture.

However, Tim is also unsure about Web Services saying on the one-hand “The importance of Web services is being underestimated” and on the other “A lot of us are not sure that WS-* is the future”. His objection is that the set of standards are becoming “unreasonably big, unreasonably complex and few of the core low-level elements of the stack seem ugly and awkward and difficult”.

I certainly agree that too much complexity is building in the WS-* stack – it is getting more and more baffling to the beginner but many of these standards will be invisible to the programmer – buried in the stack implementations. However, it is important that the standards bodies now vigorously weed out the standards which are not ‘working’ and focus on those that are being used.

Furthermore Tim states (correctly to my mind) that POX and REST are both simple and good alternatives and “We observe that people are putting out lightweight distributed applications using good old XML and HTTP and getting them done in days and they work great”. That is of course true for some applications where HTTP is sufficient. However, there will be others where guaranteed message delivery is required and others where SOAP based communication meets the need.

The point is that all of this can fit within SOA (hence the importance of the distinction between SOA and Web Services) and as with any IT project it is important to bring the right firepower to bear to solve each problem: If HTTP is sufficient that is the right choice, but that does not mean that it is sufficient for every project. Equally, don’t deploy a complex middleware stack to solve a web-style communication problem.

Posted by rbradley in Market trends • SOA concepts |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/281