SOA

The Burton Group's Anne Thomas Manes wrote a provocative post yesterday declaring that SOA (as a term at least) is dead. It will, of course, be replaced by...(drum roll, please)...SERVICES! Hmm...isn't that what the "S" in SOA stands for? To quote Manes:

Once thought to be the savior of IT, SOA has instead turned into a great failed experiment—at least for most organizations. In the beginning, the forecast for SOA was to reduce costs and increase agility on a large scale, but except in rare situations, SOA has not delivered those promised benefits.

But, take solace, consultants everywhere! For all is not lost...

SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.

Ah, I knew there had to be a silver lining to that cloud (*sniff*).

Cheekiness aside, the reality is that many organizations haven't really had a clue as to what SOA really is or how to do it. They, led by all too eager vendors and the general vagueness of the term itself, naively equated "SOA" with tacking on web services to their existing applications or building an ESB like a "field of dreams"--which many did, and dutifully waited for the magic transformation to come. It never did, mostly because many organizations were already too mired in years (indeed decades) of creating siloed applications. True service-orientation, however, required a re-thinking of traditional methods of doing IT, a shift that met silent but stiff resistance in many organizations. SOA demanded a revolution in thinking, something most organizations were simply not ready for.

So the term "SOA" must die, and give rise to equally vague (but much trendier) and equivalent terms. Silently and slowly, though, an evolution will happen: out of necessity, if nothing else. For services are an economy of form in an inter-connected world.

Part 1 of this series talks about SOAP vs. REST. In this installment I'll discuss the reasons for defining the web service contract between client and server, the existing methods for doing it, and the important concepts of each.

Defining the Contract

An important part of any web service is the contract (or interface) which it defines between the service and any clients that might use it. This is important for a number of reasons: visualization with tools, interaction with other specifications (e.g., web service choreography), code generation, and enforcing a high-level agreement between the client and service provided (that still gives the service freedom to change the underlying implementation). Taken together, they give pretty compelling use cases for having web services contracts, although advocates of minimalism may disagree.

When IBM, Microsoft, and Ariba submitted WSDL 1.1 to the W3C in 2001 as a language for describing web services in conjunction with SOAP 1.1, HTTP POST and GET, and MIME, it quickly became a standard used by every SOAP toolkit. This happened in spite of the fact that it never progressed beyond being a W3C Note (which, according to W3C, is a document available for "discussion" and not officially endorsed by the W3C). In fact, though there is both a WSDL 1.1 and 1.2, WSDL 2.0 is the only version of the specification officially endorsed by the W3C.

With the rise in popularity of RESTful web services, there also became a need to describe contracts for these types of web services as well. Although WSDL 2.0 attempts to fill the gap by providing support for HTTP binding, another specification fills this need in an arguably better way: WADL , a specification developed at Sun by Marc Hadley. Though it has not been submitted to any official standards body (OASIS, W3C, etc.), WADL is promising because of its more comprehensive support for REST-style services.