2006/04/06
Add your comment
2006/04/05
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?
Yup. “For the vast majority of uses, I’ll argue that WOA is the most interoperable, easiest to implement, and most highly scalable technique for building great, open Web services that anyone can use.”
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2006/04/03
2006/04/02
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.