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”.