Service Oriented Architectures is all the rage in popular distributed computing circles and is now eclipsing the XML Web Services hype. In trying to decipher what exactly this new buzzphrase means I've come across the following definitions

From Hao He's What is Service-Oriented Architecture?

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners

While in Sayid Hashimi's Service-Oriented Architecture Explained we learn that

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.
2. The service can be dynamically located and invoked.
3. The service is self-contained. That is, the service maintains its own state.

Then there's the quote from the Gartner Group's Service-Oriented Architecture: Mainstream Straight Ahead with the informative summary

Essentially, SOA is a software architecture that builds a topology of interfaces, interface implementations and interface calls. SOA is a relationship of services and service consumers, both software modules large enough to represent a complete business function." So, SOA is about reuse, encapsulation, interfaces and, ultimately, agility

So what exactly does this mean for those that have been have been flying the flag for XML Web Services or like me have been mildly curious about them at least. Well for one it is interesting to note that most discussions of SOA end up talking about XML Web Services technologies like XML, SOAP, HTTP and the like but also tend to them in the same breadth as they mention technologies like CORBA.

For one it seems many people have figured out what was interesting about XML Web Services wasn't the "XML" or the "Web" (more on this later) but the fact that instead of focusing on distributed objects it is more interesting to focus on sending data to end points for processing and retrieving the results. However you don't need XML or the Web to do this, although according to the theory of REpresentational State Transfer (REST) this is also how the Web works.

The way I see it the phrase "XML Web Services" already had the baggage of WSDL, SOAP, UDDI, et al so there a new buzzphrase was needed that highlighted the useful aspects of "XML Web Services" but didn't tie people to one implementation of these ideas but also adopted the stance that approaches such as CORBA or REST make sense as well.

Of the three words in the phrase "XML Web Services" the first two are implementation specific and not in a good way. XML is good thing primarily because it is supported by lots of platforms and lots of vendors not because of any inherrent suitability of the technology for a number of the tasks people utilize it for. However in situations where this interop is not really necessary then XML is not really a good idea. In the past, various distributed computing afficionados have tried to get around this by talking up the The InfoSet which was just a nice way of deprecating the notion of usage of the XML text format everywhere being a good thing. The second word in the phrase is similarly inapllicable in the general case. Most of the people interested in XML Web Services are interested in distributed computing which traditionally and currently is more about the intranet than it is about the internet. The need to justify the Web-like nature of XML Web Services when in truth these technologies probably aren't going to be embraced on the Web in a big way seems to have been a sore point of many discussions in distributed computing circles.

Personally I feel the same way about XML and the W3C, the W3C is about the Web and controls XML yet in truth XML usage is more widespread in local applications and intanets than it is on the World Wide Web, in fact its only major success on the Web has been RSS which isn't even a W3C technology. But I digress...

So where are we now? Well, it seems that XML Web Services are now passe and Service Oriented Architectures are in. To an XML guy like me, this is great because it means that I can now build RESTful XML Web Services and still be buzzword compliant. No more hiding XML behind objects that don't map properly to the data and clunky RPC-encoding schemes for me.

Anyway, I'm off to see Kill Bill:Vol. 1 with some friends. I'll probably write more on this if I get any interested comments and no angry email from fellow b0rg protecting their turf.

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.