My most recent O'Reilly blog, "Web Services and the Eight Fallacies".

The "theory monster" rears its ugly head again. Clemens Vasters writes "Hence, the "I love HTTP" discussion (aka REST) is solely academic and of very little relevance for complex real-world designs now and even less moving forward -- methinks.". REST is the furthest thing from theory in existence; it is 100% practice. It is what you get when you closely study how the Web works today. In contrast, "Web services architecture" is almost entirely theory in the context in which it's being used (the Internet). It, and its implicit resemblance to the OMA, has never been deployed at a scale even approaching the Web. Perhaps it's worth repeating; The Web is a giant leap forward in distributed computing architectures. Ignore it at your peril.

For many years, people have talked about how normal ACID/2PC transaction semantics are unsuitable for use on the Internet. That is still the case. We need to rethink what a transaction is on the Web, and I can guarantee you that when we do, it will be implementable as an HTTP extension.

Sam Ruby responds, "Note: I've said nothing about behavior... only about syntax. Where is the disconnect?". As long as no behaviour is requested, then there is absolutely no disconnect. Excellent!

I think we still have some terminology issues though. For example you said that WSDL is for specifying protocols. I don't consider specifying the structure of expected content as a protocol. Protocols define contracts, and in this case, the contract is that if I POST something that you consider invalid - whether or not I've seen your WSDL (heh, that sounds rude 8-) - then you'll tell me so with a 4xx response (e.g. 400 or 415). Does that make sense? So this boils WSDL down to how I always saw it being used in the long run; as HTML forms are used ... that is, until RDF absorbs it. 8-)

Sam and I are still disconnected, but we appear to have narrowed it done to this one key point. Must .. find .. way .... to explain.

Time for an example.

POST /some-uri/ HTTP/1.1

Host: example.org

Content-Type: text/plain

[blank line]

795

This is a client POSTing the data "795" to http://example.org/some-uri/. I consider this more hormone-like, because what the code bound to that URI does with the number "795", is completely up to it. And without additional information, the sender of that HTTP message has no idea what to expect will happen when he does. How this works in HTTP, is that the client (in HTML's case, a user) forms an expectation by believing the assertions in the HTML that they previously got, that if you submit some text, we'll send it to an LED flasher in our office (or will dial a phone number, or hunt down and kill the person with that SIN, or whatever). So different behaviours are negotiated out of band, not requested in band.

That should hopefully highlight the difference. Does it? It wasn't intended to compare the approaches. I'll leave that as an exercise to the reader. 8-)

Sam Ruby, "I still do, however, see value in perfectly clear protocol specifications, a role that WSDL fulfills".

Here's how I see it. HTTP is the protocol, and no other protocols are required in order to get stuff done. I agree that WSDL does define protocols - application protocols in fact - but why is it required? I'm not sure how best to describe the difference, but Sam's own neurotransmitters essay might be a start; "In the second mechanism, the receiver determines the action to be taken. The request matches a receptacle on the membrane and the cell uses this information to trigger biological processes.". That is, the the "server" determines what is done, not the client. Using WSDL as a protocol definition mechanism (as practically all Web services use it), the client is asking that some action be taken by invoking some operation on the server. This is not the hormone/membrane, it's the virus. For the hormone approach, the protocol data unit is simply "handed off" to the recipient without any specific request for action other than "hand off". This is what POST means.

I'm a few days late, but Sam Ruby posted his excellent REST+SOAP essay last week. I was surprised to see it not get more fanfare. I commented to Sam that I was concerned about this bit;

Now add high level methods which take care of all composite

create, update, and delete operations.

Sam suggested to me off-line that he was thinking about it in terms of just passing data over a wall/membrane, to which I responded that this is exactly how POST works; that the operation that occurs is determined solely by the server. So we may be in synch, but given previous things I've heard him say, and his work on SOAP and WSDL, I wonder if we really are. But here's hoping!!

Thanks for the heads up Sam, it looks like a 404. Had to republish the Blogger archives. Bizarre, but you get what you pay for.

An interesting discussion on xml-dist-app about implicit versus explicit use of the Web Method Specification Feature of SOAP 1.2. I guess I just have a hard time understanding why you'd want to hide the method, either by defining a default, or deriving it from the MEP in use. I mean, how else do you accomplish something without knowing what method you're invoking?

I'm glad Sam Ruby is contributing to the SOAP/REST discussion. As a leader in the Web services space, his word goes a long way. I'm looking forward to reading his article.

As for "bad advocacy", I don't believe that I'm an advocate for REST, at least in the REST/SOAP discussions. I see myself as more of a soothsayer, trying to warn people that the current approach to Web services cannot do what people hope it can do; namely, work on the Internet. But my hope is that the industry understands this soon, because I'd prefer to see it put resources into more fruitful endeavours rather than spending them repeating past mistakes. But if they don't, then they'll just have to learn the hard way.

Curmudgeonly yours. 8-)

O'Reilly invited me to join their list of weblogs, so I've done that. I'll use this Blogger one for day-to-day snippets, and the O'Reilly one for more article-style blogging.