Mark Baker has written about WS-Eventing (try the first link if you see an empty page). It seems to me that the whole REST/WS debate comes down to the discussion whether SOAP should take advantage of the underlying transport/transfer protocol. In fact, it’s probably all about whether it is a transport or transfer protocol. For Mark, it’s stupid that the SOAP/WS-* specs ignore what HTTP has to offer from a transfer protocol side. The reason, of course, is that SOAP aims to work equally well over different protocols. While this might be achieved by exploiting the features of each different protocol to the largest degree possible, I can understand that one might view this as not worth the resulting confusion — the benefit of the current approach is that things look very similar, regardless of whether you’re using HTTP, SMTP, JMS, or some sort of proprietary transport (like TIBCO).
It’s interesting to note, though, that Mark also attests that WS-Eventing does a lot ofsome things the right way.
Comments
On January 19, 2004 7:57 PM, Stefan Tilkov
said:
I’ve updated the entry accordingly ;-) While I can relate to a lot of your arguments regarding the applicability of WS-* style Web services on an Internet scale, I wonder whether you can see any value in it at all? How do you adress the need to use other transports than HTTP? Or don’t you see such a need at all? I have a feeling I know the answer ;-)
On January 19, 2004 8:49 PM, Mark Baker
said:
I see some value in some specs, but not most of them. Some specs (at least of the beefier ones) I think could have a future include WS-Security, WS-Routing, the SOAP attachment work, and SOAP itself of course. My rule of thumb is generally that if the spec itself prevents me building RESTful ly, then it’s probably no good. But it also matters which of the constraints it disregards; e.g. one which assumed a stateful interaction would stand a better chance of success than one which assumed component-specific interfaces.
For other, ahem, transfer protocols 8-), my requirement is that each be used as if it were sitting behind a HTTP proxy. So SMTP DATA -> [email protected] should be handled as HTTP POST -> mailto:[email protected], and FTP RETR host.example.org /foo/bar/baz.zip should be handled as HTTP GET on http://host.example.org/foo/bar/baz.zip, etc..
Maybe not “a lot of things” the right way. 8-) What it does get right, IMO, are some things that don’t matter much to WS-Eventing itself, but show some progress towards a more RESTful architectural style.
So while I don’t see much hope for WS-Eventing itself, I’m hopefully that subsequent attempts (at pub/sub, or anything else) may stand a better chance at success.