Fwd: Protocol independence

Forwarded to www-ws-arch to reach a wider audience, and edited to
reflect some of Mark Baker's comments. (Thanks, Mike.)

I'd like to keep the discussion of protocol independence to the realms 
of
the probable rather than the outer reaches of the possible....
For starters, let's recast this as "message transport independence", 
since
protocols occur at many levels.

When I think of message transport independence in the context of WSA,
I'm concerned about what happens when we move from HTTP
to BXXP to SMTP to WAP-compressed-XML-over-GSSM/USSD
to MOM. All of these support the transmission of XML messages
and are (presumably) compatible with SOAP 1.2 and WSDL 1.x.
However they have quite different performance and reliability
characteristics. Further, some of them offer interesting
features which are not available with others. How should
a WSA address this diversity? Should we adopt a "lowest common
denominator" approach, ignoring added value features? This seems
likely to be unpopular, to put it mildly. Should we focus on
abstractions which can be realized in different ways over
different transports, in some cases using "native" features of the
transport and in others using mechanisms layered on top of the
transport? If so, who gets to define the mechanisms?

Indeed, is independence really desirable? Mark suggested that
> BEEP has no method for "get me data", while HTTP does.  You can't
> expect that bits sent with one can have the same meaning when sent
> with the other; bits sent with BEEP necessarily has to include a
> method, whereas bits sent with HTTP does not.
and
> sometimes you shouldn't send a
> message using a particular application protocol.  For example, SMTP
> should not be used to retrieve things.
I'm not persuaded by either of these arguments. It seems to me that the
proven strength of the Internet is that we can innovate freely at
different layers in the stack, holding one layer (TCP) constant.
What is the equivalent constant for web services? It seems to me that
it can be either HTTP (RESTfully) or SOAP, but not (logically)
both. If we decide that SOAP is the centre of gravity for web services,
we should certainly feel free to innovate around that, inventing new 
ways
of conveying SOAP in either plain XML or some infoset-equivalent.
I don't see how you can have it both ways.

In order to make sense of this lot, we need use cases for
various audiences: for service developers, for web service platform
developers, for those responsible for deploying and configuring
transport infrastructure and services. For example: do we care about
concatenations of dissimilar transport infrastructure? If so, what
do the gateways look like, and how are entities in the different
domains identified? What is the relationship between a transport gateway
and a SOAP processor? Etc. Etc. The concept of "end to end" gets very
murky here. (And don't even get me started on security.....)

Note that all of this falls strictly in the conventional SOA realm;
I'm not venturing into esoterica such as the relationships between
SOA and tuplespaces. We should not let red herrings distract us
from ordinary everyday trout.

Let me propose that at this stage all WSAWG should do is to
create a glossary entry for "message transport independence".
It needs to be sufficiently detailed to indicate that we're
aware of the complexity and importance of the issue.
I wouldn't disrupt the present document process to accommodate
any more substantial treatment at this time (unless the current
draft were to include language which was substantially in conflict
with what I've discussed above). At some point down the road
(once we've fixed our "heartbeat" problem), we should
consider creating a chapter which discusses the messaging,
description, security, and choreography issues of transport
independence and how they interact.

Geoff

Received on Friday, 4 April 2003 13:20:25 UTC