Web Things, by Mark Baker

I caught this “blog” entry of Ray Lane’s via Google News today, and of course the title caught my eye. But I’ve been caught by titles before, and the article normally turns out to say, in effect, Yes, they are the answer.

So this was a nice surprise;

The software industry’s answer to all this is Web services. That’s the next big thing. It’s supposed to solve a lot of problems. When you talk to most of the large suppliers, they spill a bunch of acronyms and say all this will allow you to integrate. But it won’t; it just won’t.

So far so good. He goes on to talk about why he feels it won’t work …

There are standards, and certainly messaging and integration are easier, but we don’t know yet how to handle the semantic differences between industrial messages that are coming from suppliers to OEMs to whatever. XML, Sun ONE, Orion, Longhorn, on-demand computing, yada, yada, yada. There are a lot of solutions, a lot of hammers looking for the nail.

I disagree with the first sentence; what Web services are, does not make messaging and integration easier (though SOAP arguably does, a little – Web services as a whole make it significantly harder). The second part, I completely agree with though; we don’t know how to solve those problems. But we’re trying.

Werner comments on RS-232/SOAP and transport vs. transfer;

But I do think Mark is pushing the limits by suggesting that the reads & writes on the rs232 registers are in reality similar to hidden REST-like HTTP GET & POST verbs.

Well, I was simply suggesting an analogue existed, not what it was. But since he asks … 8-)

Though I fully understand that RS-232 is not, by definition, a transfer protocol, many (most, I would say) uses of it were/are as a transfer protocol. This is because the abstractions exposed by the protocol are often made directly available to applications, rather than being hidden from the application by other layers. This makes this use of RS-232 more than just “move these bits to the other side”; it makes them “submit this data to the application for processing”, i.e. POST

Also, RS-232 has no notion of “GET”; you won’t find anything in the spec that defines how to request data (not just “receive”, as you would with a “read”).

Sigh, I wish I could churn out well written analogies like Sean does. This time, it’s RS-232 and HTTP. Unfortunately, I don’t think this one will register with many Web services folks for one simple reason (that I’ve talked about before); the more general the interface, the harder it is to distinguish transport from transfer.

I expect that he’ll get feedback saying that SOAP is more like RS-232 than HTTP.

Maybe HTTP should have been called “DTP”, the Data Transfer Protocol.

Update; oops, well so much for that theory. The first comment I’ve seen on the article nailed it.

Every day, I get somewhere around 20 hits for the SOAP media type registration draft, referred from an old O’Reilly weblog entry of mine on SOAPAction. It turns out that this article is the first result returned when Googling for “SOAPAction”.

I feel a bit bad about this, because I only recently realized that the behaviour I described in that blog isn’t per any of the specs (obviously I don’t use SOAP at all 8-). I was extrapolating about its semantics based on some investigations into self-description and previous attempts at SOAP-like technologies such as RFC 2774 and PEP (specifically, this part, i.e. the 420 response code).

If SOAPAction/action were to be as I described there – and IMO, this would make it vastly more useful (i.e. make it useful at all 8-) – then the behaviour would have to have been specified to fault if the intent indicated by the value of the SOAPAction field were not understood. Obviously that isn’t the case today.

Sorry for the confusion.

I’ve always considered WS-Routing to be one of the few shining stars of the WS-* spec family. Conversely, I’ve said before that I consider WS-Addressing to be perhaps the biggest waste of time yet developed. So imagine my surprise when Edwin notes this passage from Microsoft’s WSE 2.0;

One of the changes between WSE 1.0 and WSE 2.0 is the support for WS-Addressing. WS-Addressing largely replaces the capabilities of the WS-Routing specification that was supported in WSE 1.0. Instead of focusing on routing paths, WS-Addressing functionally provides a mechanism for adding To and From headers to a SOAP envelope.

WS-Routing uses URIs for endpoint and intermediary identification, whereas WS-Addressing exists because apparently URIs were considered deficient as identifiers. If you buy WS-Addressing’s premise (I don’t, surprise), this makes sense, sort of. But then you’re missing the value-add of WS-Routing and its support for SOAP intermediaries. The WSE 2.0 use of WS-Addressing defines a much less general routing infrastructure, premised upon only ever using gateways (where messages must terminate) rather than both gateways and proxies as WS-Routing supports.

Woot!. Congratulations to everybody involved in its development (including me!).

A very nice piece from Tim on how Web services should look; RESTful.

Dave, Sam, and Don have all responded.

First, to Tim, right on man. It’s about time too. For quite a while, he’s seemed to be on the fence, but this seems to make it quite clear where he stands, and hopefully where he’ll be voting on Decision Day. Perhaps with a name as well respected as his firmly in the REST camp, more people will take notice.

To Sam, a couple of points. First, safety != idempotency. Safety means messages don’t change state (roughly). Idempotency means multiple messages have the same effect as one. All safe operations are idempotent, but not all idempotent operations are safe. For example, PUT is idempotent but not safe. In addition, having the response change for a GET, even in a very short period of time, is perfectly RESTful. What isn’t RESTful is if the result changes because GET was invoked (and the owner cares about the change).

Also, the “take three parameters” analogue misses a major point I believe. In the POST/SOAP/XML-RPC case, sure you get the same info back, but you have no way to refer to that info, or pass references around to other parties. When you marshal data into a http URI, you are creating a token which has associated with it a publicly specified method for dereferencing. That is a vast improvement over the one-time use-and-consume approach of POST for retrievals.

Obviously, Sean just doesn’t get it. You’ve got to be protocol independent, so that you can invent a new application protocol on top (i.e. DocSOAP) upon which you are then allowed to become dependent. Silly wabbit.

Show me a WSDL document, and I’ll show you a poorly designed application protocol.

Sam writes;

Mark Baker is upset because SOAP permits usages which are not, in his and many people’s opinion, well architected. Usages such as RPC. While many of Mark’s arguments resonate with me, he tends to throw the baby out with the bathwater. He might as well say that Python is not a good language for building REST systems because it can also be used for RPC.

I realize my position is far from typical, and appears inconsistent at times, but I thought I’d been pretty clear about it at least. Oh well. Ok, so let me get it all out, and describe what I believe – and what I don’t – about REST and SOAP;

I believe SOAP is a valuable and useful technology.

I believe the Web, and in particular the subset that follows the constraints of the REST architectural style, is a fundamental breakthrough in the evolution of large scale distributed systems, that will continue to effect how most systems, both human and machine-targetted, are built for the foreseeable future.

I believe SOAP can provide value outside the constraints of REST, but I also believe that its predominant value, by far, is when used within the constraints of REST.

I believe that using SOAP within the constraints of REST does not mean that HTTP (or Waka) has to be used.

I believe that using SOAP as a means for extending underlying application protocols, is the most valuable thing it can be used for.

I believe that using SOAP as a framework from which to build new application protocols has some value, so long as those new protocols are built on transport protocols and not tunneled over other application protocols.

I believe SOAP will fail to see significant use on the Internet because the predominant use of SOAP today is to tunnel new application protocols over existing application protocols, and to encourage an explosion in per-service application protocols, not a unification of application protocols as REST does via generalization.

P.S. I’ll believe it when I see it. 8-)

A few people have already commented on Don’s comments about there being enough specs already. FWIW, and not too surprisingly I expect, I saw those comments as a direct jab at BEA, who earlier this week released three more WS-* specs.

It was good to finally see BEA go out on its own, lord knows that’s been long overdue. But those three specs were very disappointing as a first attempt. I mean, they’re ok work (though MessageData seems to be a pretty weak attempt at addressing Roy’s issue about the different types of HTTP headers being all munged together), but are over specified (note to authors, leave some room in the margins for the standardization process 8-), and don’t stand alone very well. They need to be bundled together under some kind of catch-all “SOAP Extension Suite” or something. Or perhaps in WS-I, separating them out as three is the best way to get them into some new-fangled profile, who knows. Ah politics, gotta love ’em.