- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 04 Apr 2003 15:08:19 -0800
- To: Geoff Arnold <Geoff.Arnold@Sun.COM>
- CC: www-ws-arch@w3.org
+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