Web Things, by Mark Baker

Oh come on! Why not the more obviously garish “Smell-ML”?! 8-)
(link) [del.icio.us/distobj]

Gudge chimes in on the WS-A issue;

The WS-Addressing spec doesn’t say that you *can’t* put the content of wsa:Address into ‘the “RCPT TO” command on the SMTP protocol’. It just says you MUST put it into the wsa:To SOAP header. I wonder why Mark thought the two were mutually exclusive…

I can understand the confusion, but my concern was simply that the spec didn’t require that the address go in the appropriate place in the application protocol. That’s required in order to cleanly integrate with the architecture of the Internet (not just the Web). Otherwise the Internet is being treated as a big bit pipe, rather than as a set of distributed applications (oh, wait, nevermind 8-).

In the one Endpoint Reference, multiple protocols case, it’s fairly obvious ( to me at least ) that the value of the wsa:Address ( and corresponding wsa:To ) cannot be used as address information for all of the underlying transports ( although it might, by happy accident, work for one of them ).

Hmm, what can I say to that? Baked in to that statement is the implicit assumption that application protocols are to be treated equivalently to transport protocols. Please, please, please Gudge, take some time out to carefully consider that application protocols are very very different beasts than transport protocols. URIs, even http ones, are application layer identifiers, intended to identify anything, including customers, invoices, receipts, etc.., not just “network endpoints”, or “transport addresses”. If you’ve come from an RPC background (which I believe you have), there is simply no analogue for an application protocol in RPC architectures. But, simply because they share a name with a layer in the RPC stack, they get treated as it would in the RPC stack.

The third interesting point in completely non-technical, but rather a socio-political one. Mark raised his issue with the WS-Addressing WG who considered his request, thought about at least some of the things mentioned above and in Steve’s post and declined to take up his issue. Not being willing (able?) to take ‘No’ for an answer, Mark then raised his issue with a higher authority, the TAG, hoping, I guess, that they will make the WS-Addressing WG see the error of its ways…

Right. That’s how it works. I’m just following the process (see the Issue Resolution section). And as I mentioned to Steve, I think the acceptance of the issue is, for me, the only win I’m interested in. I don’t really care how it’s resolved.

I saw these things – or something just like them – in Dusseldorf. Too bad I was in a taxi so didn’t have time to snap a picture. Funky!
(link) [del.icio.us/distobj]

Steve takes issue with the issue. 8-) He starts with a paragraph which very accurately summarizes the issue, and then goes on to explain why he believes that it would be a mistake for the TAG to “make a short-sighted decision in the direction that Mark is proposing”. First though, a quick response to that point; I don’t recall proposing a solution (though it’s possible I have on the list), but I think the damage that Steve’s worried about has already happened, as they’ve agreed that the use of wsa:To I described is a problem (update; in fact, they’ve just agreed that they need to investigate it, though the comments in the minutes clearly indicate they all grok the problem).

He writes;

To me, this issue is really about the central notion of “transport address”: Can the URI that identifies my service be different than the URI that identifies the thing that takes the bits off the network and hands them to my service?

Again, an http URI is not a “transport address” (btw, is an IP address a transport address??). It’s an application layer identifier – a string – and it can serve its identifying-purpose completely outside of the context of a network. If you have one which identifies your service and can also be used to send messages to that service, what value is there in another one? HTTP is not a transport protocol, it’s an application protocol! Its clear to me that Steve (and every other Web service proponent for that matter) has yet to fully absorb the implications of that. Remember, we’re talking about very different stacks that use the same word (protocol) to refer to very different parts of that stack; in the Web services stack a “protocol” is inconsequential, while in any Internet/Web based stack, the protocol is the fundamental building block of interoperability, the exact opposite of “inconsequential”.

Issue accepted.

As usual, Roy nailed it;

seems the direction of all ws specs is to be binding neutral, but no statement that a given binding is required so entirely separate architectures all described as web services

A Web services developers gives REST a try
(link) [del.icio.us/distobj]

“But the low overhead also means that REST doesn’t include built-in security and reliability, so it’s not well-suited for enterprise use, particularly between business partners or for e-commerce.”. Sigh.
(link) [del.icio.us/distobj]

Bill deHora comments on Mnot’s latest, saying this about something he heard somebody say;

He has a nice comment near the end on how having less options can be a good thing.

I didn’t hear the interview, but yah, absolutely. It’s arguably the fundamental theorem of design (all design, not just software design). But we should be careful to clarify that it’s “less options” of form, not function. That is, by constraining form we’re only limiting how solutions are developed, not what those solutions are capable of doing. I think that if the point was better understood by Web services proponents, we would have made progress towards decisions like this one – which constrains form by virtue of requiring all identifying information in a single data element, without constraining function – a long time ago (and arguably never have bothered with Web services at all).

I’ve been heard to explain my transition from being a CORBA proponent to a Web proponent in these same terms; that I in a gestalt moment in 1998, I realized that the Web was, more or less, “distributed objects” (“identifiable things on a network that you can chuck messages at”) with some additional constraints on form.

And that’s the good news! 8-)
(link) [del.icio.us/distobj]

Good question. Most WS proponents want to distance themselves from CORBA, yet the architectures are eerily similar.
(link) [del.icio.us/distobj]