Re: Fwd: Protocol independence

+1

arkin

Geoff Arnold wrote:

>
> 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 18:09:33 UTC