I just gave an invited presentation on Web Services at School of Computer Science at Manchester University. I covered basic and advanced Web Services, Web 2.0, REST and Semantic Web (cramming to get all of this into an hour). The audience appeared interested and I got some good follow-up questions. But as you might imagine, it was tricky to get everything in to the allocated time slot.

However, one thing that became apparent to me over the past few days as I wrote the presentation was how difficult it is to actually cover *just* Web Services in an hour! I remember giving talks on Web Services back in 2002/2003 when there was really just SOAP, WSDL and a smattering of UDDI: that's an hour, depending on how much detail you want to go into around SOA. In the intervening years we've standardised on more aspects of the WS architecture and complexity has risen. Now don't get me wrong: I'm not saying that we could avoid the complexity or that it's a bad thing. I've worked on a range of distributed systems architectures over the years and there really is no such thing as a free lunch: if you need advanced facilities such as session management, transactions, security and fault-tolerance then you've got to pay for them somewhere, and pushing things "behind the service endpoint" only works to a point.

Web Services started out as simple (often compared to the complexity of CORBA), but have inevitably gotten more complex as we try to do more and more with them. In some ways, the closest analogy I can come up with is Java: it started out as being "better" than C++ because it was so much simpler - none of those waste-of-space features such as multiple inheritance, pass-by-reference or templates and none of the huge libraries that you never needed (I'm joking here, because I always felt the need for such features). But look at it today: we've now got templates and the JDK is 60Meg! A simple Hello World application takes many Meg to execute!

However, one question I posed during my presentation was: Can it be simpler? What about the WWW? Technically it hasn't changed much and yet we're now working in a Web 2.0 world (I don't like the term, but I agree with the categorisation). The REST approach is often mentioned as more natural for services on the Web than Web Services (evolution rather than revolution), so what about that as the foundation on which to build a simpler and better Web service (small 's') architecture? As you may have gathered, I think the answer is no. That's not to say that I don't think some aspects of a pure REST-ful approach wouldn't be simpler (e.g., URI's have been pretty successful for the WWW, so we may not need something like WS-A), but other aspects may be more complicated (e.g., transactions - my first foray into transactions on the Web started out effectively REST-based I think and it was difficult to do in those days so it ended up quite different). However, the approach does intrigue me enough that, should I ever find any spare time, I'd like to flesh out how a REST service architecture might match up to its Web Services cousin. Anyone wanting to help, just drop me a line.

But back to Web Services! The death of Simple Web Services was signaled as soon as we wanted to do more complicated things with it. We shouldn't ignore that fact and continue as though we were still working in 2002. The S in SOA doesn't stand for, or imply, Simplicity. Whether you're talking services, objects or procedures, complex things such as transactions require complex solutions. This shouldn't come as a surprise to anyone who's been working in distributed systems over the past 20+ years.