Web Things, by Mark Baker

Just posted a new blog at my O’Reilly weblog about SOAPAction.

James Strachan sums it all up when he says;

[…]Whatever happens in this whole web services thing, I do think alot of good has come from it already. Its forced people to think alot about distributed systems and why the web works and scales – there’s a lot of great lessons there. Its also brought together lots of diverse communities from the web side of things, from MOM folks and distributed objects folks. If nothing else its made us look again at distributed object technologies like DCOM, CORBA, EJB and ask lots of questions – I think its also taught us what a leaky abstraction the traditional view of distributed objects are.

This is exactly my view. Once this is all resolved – and I hope for the industry’s sake that it is soon – a lot more people will be appreciative of the extent of the gift that TimBL gave to the world, and the principled design that Roy laid out for us.

What doesn’t kill you, makes you stronger.

And FWIW, I’ve maintained my “distobj” email address for a reason; the Web is a distributed object infrastructure, with the critical innovation that all objects implement the same interface (have I said that enough yet? 8-).

Dave made the following suggestion for a SOAP definition;

It’s a simple way to call procedures running on other machines, on other OSes, written in other languages, using different economic systems, without being forced to pay a tax to Microsoft, IBM, Apple, Sun or the W3C.

SOAP isn’t that at all. That’s XML-RPC. Dave’s a bright guy who writes great software, but when it comes to distributed systems, there’s a lot he doesn’t understand.

The SOAP 1.2 spec defines SOAP as;

SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.

Which is a pretty decent definition, though not very detailed as to how one actually might use it. For a better definition, I look to SOAP’s brethren, PEP. It’s defined as;

The Protocol Extension Protocol (PEP) is an extension mechanism designed to accommodate dynamic extension of HTTP applications by software components; and to address the tension between private agreement and public specification.

Of course, SOAP isn’t tied to HTTP, but PEP didn’t really need to be either. It could also be patched to be an extension protocol for non-HTTP protocols, as SOAP 1.1 was “patched” in the form of SOAP 1.2.

Please, if SOAP has any chance of success, let’s try to distance it from RPC.

A couple of recent blogs and messages I’ve seen prompted me to write this. They both suggest that a “SOAP message” is necessarily a “message”. I disagree.

When bound to an application protocol, a SOAP message/envelope is not a message because it doesn’t contain the necessary information with which to understand what it means. For example, a SOAP envelope which included a HR-XML resume is not a message, because it doesn’t say what is to be done with the resume; is it to be forwarded on to somebody else? Submitted as part of a job application? Meant to update an existing resume? This is where the envelope of the underlying protocol, such as HTTP comes in; the HTTP request line (method, URI, version), headers, and the body which includes the SOAP envelope, forms the entire message.

If HTTP were a transport protocol, then a SOAP envelope/message sent over HTTP would always be a message. But it isn’t, it’s an application protocol. And please don’t think this is nitpicking. Far from it, I believe it’s the single biggest misunderstanding that has lead us to where we are at with Web services (i.e. a mess). If people knew what an application protocol was, I think many more (not all, of course) would have thought twice about proceeding with Web services.

Peter Drayton writes that some folks have had “RESTian awakenings” as a result of his presentation, which is just awesome. While reading up on one of his references though, I found this in Alexis Smirnov’s blog which suggests that at least some people still have a ways to go;

After his talk, Peter, Tim and Sam talked about a need to get a WSDL from a SOAP URI.

My response to that is, no, there is no need for WSDL. The fundamental advancement of the Web over previous distributed object systems is that it doesn’t need an interface language because all components expose a uniform interface.

An analogy; if you’re a Java programmer, think of it as working with all your objects after they’ve been downcast to java.lang.Object. Obviously java.lang.Object will only define methods which are common to all objects, so you wouldn’t expect it to have a method such as “buyBook” because not all objects are books. This is what REST’s uniform interface constraint is all about.

Peter Drayton posted the slides (PPT) from a presentation he gave at the WS DevCon. It’s very well done. Too bad I couldn’t have been there to hear it presented.

It’s good to see Edwin agreeing with Steve Vinoski about how distributed systems are not as simple as just exposing object APIs through SOAP.

I especially like this bit; “We should think of it as email for business applications”. Yes! But email is fairly limited; we can do better than just “add this message to that mailbox”. What if we extended email with the ability to retrieve messages, replace existing messages, plus other operations on messages and mailboxes? If you squint a little, that’s what the Web is.

I should probably have done this long ago for the record, but there’s no better time than the present. This was prompted by a couple of comments I’ve seen recently saying “Web services are here to stay!”. Bzzt!

Web services will be considered an utter failure by the industry by the end of 2004.

The end game will be interesting to watch, that’s for sure. Some companies will emerge as the real thought leaders, and others will likely be left insisting that Web services are the right way to do things. Then again, it’s possible that Microsoft and IBM spin doctors may just absorb REST; “We’ve been saying that all along!”. Either way, none of the specs associated with Web services will be in use on the Internet by then, except perhaps SOAP, DIME, and WS-Routing. But I’d have to bet against those too, unfortunately, because they’re going to get caught up in the backlash.

There are two kinds of people; those that believe that XML-RPC was SOAP‘s predecessor, and those that believe that PEP was.

Just noticed Simon’s reference to his SOAP SMTP binding spec. Section 6, “Security Considerations” says “This should introduce no new security considerations.”. Bzzt! 8-)

Consider that by requiring the SOAP response in a new email, rather than using the SMTP response as the response, you’re requiring that any deployed implementation of software conforming to this specification, include an automated responder where none was previously. That is, what was once a safe “input only” protocol (SMTP), has been turned into a request/response protocol. There’s oodles of new security considerations to consider because of that.