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.
2006/03/30
I was in need of a good enterprisey example, but rather than looking for one, I figured it was probably simplest just to sit back and wait for it to come to me. That didn’t take long;
We do need to address such challenges, but won’t get anywhere by quickly cobbling together yet more geeky mashups. We need tools with a proper process foundation that not only support the work but allow it to be managed, and such tools will be based on an in-depth understanding of human collaboration and its management rather than some current techie fad.
Tags: enterprisey, soa, web.
2006/03/29
Ok, that last one was a cheap potshot at Annrai’s latest, but the article offers some interesting wisdom, this bit in particular;
The Wiki metaphor (and its implementation) is the perfect vehicle for sharing and managing SOA artifacts across an organization. Then if anyone makes a change to a service that you are interested in, RSS should be able to inform you when that happens and you can make any necessary changes.
It sounds like he’s describing more of a management interface, but hey, it’s a start. It’s a short step from there to realizing that all services can spit out RSS notifications upon a change of state, not just ones monitoring other services.
Tags: soa, rest, webservices.