Re: Protocol independence

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?

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 11:44:21 UTC