W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

RE: REST, Conversations and Reliability

From: Martin Chapman <martin.chapman@oracle.com>
Date: Thu, 8 Aug 2002 08:46:31 -0700
To: "'Christopher B Ferris'" <chrisfer@us.ibm.com>, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>
Cc: <www-ws-arch@w3.org>, <www-ws-arch-request@w3.org>
Message-ID: <001101c23ef2$c6759e80$358e1990@us.oracle.com>

CORBA went down this route: every object must be able to speak IIOP, but
you may use that to negotiate another protocol.
This was only practical in very specialised and localised environments
(embedded/real-time), and most (if not all) larger scale corba
deployments used only IIOP (once it was available). So while it is good
in theory and useful in small places, the approach doesnt come close to
ubiquity needed to desrve the web title. The other problem of cousre is
when you get into a one to many communication (e.g. mutlicast of stock
quotes); its very impratical to negotiate with each party.
 
Martin.

> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Christopher B Ferris
> Sent: Thursday, August 08, 2002 5:28 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org; www-ws-arch-request@w3.org
> Subject: RE: REST, Conversations and Reliability
> 
> 
> 
> 
> Architecturally, the point that WSA should be focused on is 
> how two nodes can determine which wire format is most 
> suitable for exchange of the infoset between the two adjacent 
> nodes. Having a baseline default serialization that MUST or 
> SHOULD be supported would go a long ways towards ensuring the 
> broadest level of interoperability. I would tend to lean 
> towards SHOULD because MUST might be impractical in all environments.
> 
> Architecturally speaking, this could be abstracted to "how 
> can two nodes determine, and negotiate(?), QoS parameters" 
> since serialization encoding is but one possible facet to be 
> agreed upon.
> 
> As to infoset serialization, I thought that this was already 
> covered by XML1.0 and Infoset specs. I could be wrong, but I 
> don't see a need for any new WG to define infoset 
> serialization for pointy brackets.
> 
> Cheers,
> 
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
> 
> 
>                                                               
>                                                               
>             
>                       "Champion, Mike"                        
>                                                               
>             
>                       <Mike.Champion@Software        To:      
>  www-ws-arch@w3.org                                           
>             
>                       AG-USA.com>                    cc:      
>                                                               
>             
>                       Sent by:                       Subject: 
>  RE: REST, Conversations and Reliability                      
>             
>                       www-ws-arch-request@w3.                 
>                                                               
>             
>                       org                                     
>                                                               
>             
>                                                               
>                                                               
>             
>                                                               
>                                                               
>             
>                       08/07/2002 08:51 PM                     
>                                                               
>             
>                                                               
>                                                               
>             
>                                                               
>                                                               
>             
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Martin Chapman [mailto:martin.chapman@oracle.com]
> > Sent: Wednesday, August 07, 2002 7:54 PM
> > To: 'Ugo Corda'; 'Champion, Mike'; www-ws-arch@w3.org
> > Subject: RE: REST, Conversations and Reliability
> >
> >
> > Do we really want this in Web Service-land; is there any 
> point without 
> > a wire format?
> 
> Are you suggesting that WSA ask SOAP to re-think its 
> defininition on top of the infoset rather than XML syntax?  
> Or maybe suggesting that web services SHOULD use XML pointy 
> brackets rather than some alternative syntax?
> 
> I think we ought to say that to maximize interoperability, 
> the XML syntax is clearly best practice.  Still, there are 
> other considerations besides interoperability [he says, 
> awaiting the thunderbolts from the RESTifarians <grin>].  As 
> far as my MQSeries - Web via intermediary scenario goes, I 
> don't think it matters to the WSA what some internal 
> implementation of SOAP does for a wire format so long as they 
> preserve the infoset representation. More plausibly, would 
> anyone insist that the "wire" format of wireless web services 
> use pointy brackets, namespace URIs in all their bloated 
> glory, etc.  if they can compress/tokenize/whatever that 
> stuff away?  We can say that's bad practice for 
> interoperability, but they may point out that 
> interoperability of services that are too slow to be 
> economically viable is not really an issue worth debating.
> 
> Or to put it another way, the WSA might recommend XML syntax 
> as a wire format for interoperability reasons, but must not 
> build higher layers or dependent modules on the assumption of 
> XML syntax, only that whatever the wire format is, it can be 
> mapped to the SOAP infoset representation. Would anyone 
> disagree?  I think we're asking for a fight with the XMLP and 
> TAG folks if we suggest backtracking on the infoset basis for 
> the formal specs.
> 
> 
> 
> 
> 
> 
> 
Received on Thursday, 8 August 2002 11:47:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:04 GMT