Web Things, by Mark Baker

• Simon Fell – Its just code – Reach
  “If you’re going to expose your service through multiple protocols then I really think that should it should be done in such as way as to take full advantage of the features of each protocol.”
  (tags: rest webservices protocol)

Everybody’s favourite WS-Whipping-Boy, is now a Rec. Yay! 8-(

Let’s just hope that if you’re using it, you’re making the same undocumented assumption as those who developed the spec. Unlike Henry Thompson.

I’m also reminded, unfortunately, of something from the W3C Process document;

W3C recommends the wide deployment of its Recommendations.

Sigh. The W3C needs the equivalent of an IETF “Experimental” label, me thinks. Or perhaps a whole new track, perhaps called “Stuff that Members want to work on because they don’t understand the Web”. 8-)

Update; Micah also sighs. And Anne likes my track idea.

Tags: soap, enterprisey, webservices.

In response to Tim Bray’s piece calling bullshit on SOA, Loek Bakker responded with some comments that get right to the heart of the matter, IMO;

WS-* services and REST services are not competing, they are complementary. Web Style serves another purpose than SOA. Consumer-facing services have other QoS requirements than high-volume, cross-platform A2A transaction services.

That’s really interesting from my POV because it shows that after many years of a debate, that we – the Web folks – still haven’t successfully gotten our message across.

That message? That these services are competitive.

It’s as Sean says (channeling some unnamed prophet);

A complex system that works invariably can be traced back to a simple system that worked

Meaning, in this context, that if you want to build something suitable for “high-volume, cross-platform A2A transactions”, start with the Web and build up. Web services don’t do that; they strayed from that the moment they confused transfer with transport.

Tags: soap, soa, rest, web, webservices.

Mark asks, what’s the point of trying to get SOAP proponents to make better use of HTTP?

I hold out no hope for SOAP, but I do hold out hope that its promoters will eventually understand and embrace HTTP as an application protocol, and in doing so, the Web as a first class distributed computing infrastructure. And I figure the best way to facilitate that is to participate constructively (as best I can, given my not-quite-thick-enough-for-the-job skin 8-).

Most importantly perhaps, for me personally, these past six+ years of explaining this stuff has forced me to work out a lot of kinks in my own understanding of the Web (in combination with actually building the systems I was describing, of course).

Who was it that said that the best way to learn something is to explain it to somebody else?

Tags: soap, http, rest, web, webservices.

It’s good to see Chris coming around to the “SOAP envelope != SOAP message” view of the world;

After we discussed this issue on the call today, it became clear that I may have been mis-reading ‘response message’ for ‘response envelope’.

DaveO and I were discussing our respective positions on this and I believe that we are in agreement that the reference to “other information structures” includes things like the HTTP status code and other goop.

Woot! But I could have sworn I said that 8-)

So, now that that’s out of the way, and the chameleon view of SOAP is finally getting some respect, can we revisit some the previously discussed implications?

Most importantly perhaps, can we revisit the need for parts (read; wsa:To) of WS-Addressing now that we appreciate that HTTP already provides ultimate destination targetting at the application layer?

Tags: soap, http, web.

What I wish, is that despite the well-meaning intentions of folks like Sanjiva and Clemens (and even Marc Hadley, from a couple of months ago), that they’d step back and look at what they’re proposing from a developer POV.

Developers want a library that assumes the same things they assume. Forcing them to be explicit about those assumptions is the quickest way to turn them off, IME.

Consider: java.net’s support for HTTP and URIs, for all its problems, is still able to turn a URI into data – the most magical of Webish incantations – in about three lines of code. If your solution can’t match (or beat!) that, I’d be heading back to the drawing board.

And +1 to what Stefan said.

Tags: soap, soa, rest, webservices.