I love stuff like this; a list of grand challenges for IT in the next 20 years. Too bad some reward money wasn’t allocated! 8-)

Here’s one up my alley;

Scalable ubiquitous computing systems: Not only do we want our devices to interact predictably and reliably, we also want them to interact with every other conceivable device — but the complexity of many systems grows much faster than the number of nodes in the system. Computing engineers need scalable design principles: developing and applying them is the goal of this challenge

Hmm, I dunno, that sounds pretty tough. And in only 20 years? Systems whose integration complexity scales O(N) or better? They’re talking nonsense. I bet ya that’s nigh impossible. sigh

Ouch! Who wrote that one?! It must be a Web services proponent, because folks familiar with Internet scale development know that we’ve had that problem licked for (at least) the past 40 years. “Scalable design principles”? I give you interface constraints.

With the publication of this trio of specs, I expect the WG is now finished. Phew!

Pay close attention to their work, in particular SOAP, MTOM, and XOP (RRSHB can safely be ignored). If anything remains of Web services in five years, this’ll be it.

The specification formerly known as RFC 2396bis is now known as RFC 3986, aka STD 66.

“David Fallside rocks.”. Amen to that. He was supposed to leave the WG in 2002 IIRC, yet stuck it out for the 4+ years. He’s the Steven Pemberton of XML messaging. 8-)
(link) [del.icio.us/distobj]
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”.