Web Services
Here’s a gem on a little-used mailing list:
A couple of interesting things have happened recently; first, Jonathan Marsh has a new job;
Everyone seems to be gushing about Microsoft’s Open Specification Promise. While any headway is good in the horrible landscape that is Intellectual Property, my initial reaction is that it — like most such vendor promises — is too little, too late.
When I joined Yahoo, one of the biggest adjustments I had to make was to their use of “Web Services”. There, that phrase means any kind of machine-to-machine communication using HTTP; SOAP isn’t assumed (or preferred).
Yaron publicly says what he’s doing at Microsoft (scroll down);
Anne-Thomas Manes extolls the virtues of WS-*;
A friend in the trenches put me on to the funniest thing I’ve seen in a long time.
It’s become axiomatic in some circles — especially in WS-* land, as well as in many other uses of XML — that the preferred (or only) means of offering extensibility is through URI-based namespaces, along with a flag to tell consumers when an extension needs to be understood (a.k.a. mustUnderstand).
I’m a little confused by Mark Baker’s stance regarding SOAP; he seems to encourage the Web services world to use SOAP on top of HTTP in a fashion compatible with HTTP.
True to form, Don’s using his witty charm and good looks (such as they are ;) to shape discussion of a topic… in this case, REST, where he splits the RESTifarian world into two; “hi” and “lo.”
Microsoft and friends (of the keep your enemy closer variety, I suspect) have submitted WS-Transfer to the W3C. I found the Team comment interesting; e.g.,
More and more people are getting turned on to the advantages of using REST as a higher-level abstraction for networked applications, often comparing it favourably to SOAP and Web services.
Some folks at IONA have written a paper entitled Where HTTP Fails SOAP. I had a chance to look at this before I got it published, and their conclusions make a lot of sense — if you accept the premise that SOAP (and Web services) is about integration with existing applications.
You can describe just about anything with sufficient precision in plain English, given enough words. In practice, this doesn’t happen; specialised fields — whether science, finance or art — develop specialised jargon as a shorthand for concepts that are well-understood in that field. It gives greater precision, easier flow of ideas, and yes, it raises the bar to entry for newcomers.
I don’t talk much about it here, but I’m honoured to be the Chair of the W3C Web Services Addressing Working Group. This is something of an experiment for the W3C, so I gave an update on its progress as part of a panel discussion at the Advisory Committee meeting a few weeks ago. I’d like to share some of what I presented there.
Werner makes an excellent point;
There are MEPs in SOAP and MEPs in WSDL; both describe patterns of messages, but at potentially different layers.
Since the W3C Web Services Addressing Working Group is visiting my (sort of) home town in a couple of weeks, I’ve updated the Opinionated Guide to Melbourne that I sometimes give to people by e-mail and put it on the Web.
In a recent post, Don gave his take on the enlightening nature of WS-Transfer:
As I’m sure many others were, I was intrigued to see that Microsoft published their idea of an Introduction to the Web Services Architecture and Its Specifications the other week.
I was very interested to see the reaction to WS-Transfer [PDF] over the last few days. While the SOAP Resource Representation Header had opprobrium heaped upon it (see previous discussion), Transfer passed by with nothing more than a few nodding heads and people saying “aha.”
(Another instalment in “XML Heresies.”)
The W3C Workshop on Constraints and Capabilities for Web Services promises to be a quiet, calm, tightly-scoped discussion of a well-understood topic, lacking any controversy whatsoever.
Way back when the XML Protocol Working Group started kicking around, Henrik and I had a long-running, low-level “discusssion” about whether SOAP was a protocol or a format.
To help inform discussion of XOP (and to save Sam the trouble ;), I’ve put together a quick-and-dirty (we’re talking two hours) XOP parser in Python. It isn’t particularly efficient, nor is it well-tested or robust; it’s only to demonstrate how a XOP parser might behave.
Way back when in the XML Protocol Working Group, one of the concerns that came up was the processing model for SOAP headers. In particular, while SOAP 1.2 does a good job of specifying how that model operates, a key peice of information is missing; how to order the steps in processing a message.
To use WSDL to describe RESTful interactions, you need some way of accommodating generative resource identifiers. In a nutshell, this means some part of the URI is dynamic. For example, with HTTP I might describe an address book where someone named “Jones” has a corresponding entry URI;
I’ve talked before about describing RESTful Web resources, going as far as prototyping a new format. That work was predicated on the assumption that WSDL wasn’t adequate.
The XML Protocol Working Group (of which I’m a member) has released a first draft of XOP, XML-binary Optimised Packaging, and a revised draft of MTOM, the Message Transmission Optimisation Mechanism, that leverages XOP.
‘cause Gudge says so, and as we all know, Gudge is always right.
If you’re lost in a sea of specs, pundits and opinions, might I suggest two very well-written, thoughtful papers:
We finally did it. More than two years ago, I went to North Carolina almost by accident; at the last minute I asked David Fallside if I could come to the first meeting because it sounded “interesting.”
I know at least one person who will think that this is a good idea. Anybody else? I’d looove to do this work…
