Web Things, by Mark Baker

I missed this one from Micah a few months back. Super. Another term is “principled design”.
(link) [del.icio.us/distobj]

“Build software that bends”. I love the XML Schema advice; that’s often overlooked. In case you needed another reason to avoid the anti-pattern that is WSDL …
(link) [del.icio.us/distobj]

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.

+1 “So far, the evidence from Jini/Javaspaces, Ruple, the XML Spaces open source project, etc. is that there isn’t a sweet spot here that can’t be approximated with existing DB-backed Web frameworks.”
(link) [del.icio.us/distobj]

“I’m interested in using gopher as a protocol for dynamic information exchange in a way similar to XML-RPC and SOAP”. That’s disturbing on so many levels. *shudder*
(link) [del.icio.us/distobj]

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 happens if you serve an SVG document […] as application/xhtml+xml?” What happens is less interesting than what the document means. Stay tuned, I’m working on a related part of the CDF/CDI framework spec.
(link) [del.icio.us/distobj]

(Doh, I lost this one in my queue, hence its tardiness)

It’s too bad his comments are gone, because this “response” to his piece on microformats doesn’t exactly warrant a separate blog entry. But here it is anyway.

Regarding extensibility, I think the “middle name” issue Dave has is really with the vCard format, from whence hCard inherits its descriptive semantics (i.e. vCard has no concept of “middle name”, only “additional names” – hCard has support for this via the *-Name classes, though I admit it’s underspecified). IMO, the microformat approach in general, has a very good extensibility story; extension classes are ignored, while extended content is ignored by automata, but rendered to humans. Plus there’s also a nice hack for cases where machine-processability gets in the way of human-friendliness; “display: none” in CSS.

In fact, thinking about it some more now, I think the bulk of the innovation in (and coolness of) microformats is exactly that it works within the constraints of existing extensibility points in a pervasively deployed format. Anybody can invent a new format, but it takes genius to reuse an existing one.

Tags: microformats, html, css.

A comment from Rob Sayre: “I think WS-Transfer is too hard to use for everyday devs, so I’m developing XML-RPC-WS-Tranfer” 8-)
(link) [del.icio.us/distobj]

“I think that we ought to be pouring resources and investment into tooling and developer support around simple XML/HTTP/REST technologies. You know, the standardized ones that work today.” +1!
(link) [del.icio.us/distobj]