RE: REST, Conversations and Reliability

Don't disagree here, but a web service hosted by a cell phone with a
peculiar protocol (wap;-) better have a proxy 
with a more generic protocol/encoding for the mere mortal clients to
access them.

> -----Original Message-----
> From: Christopher B Ferris [mailto:[email protected]] 
> Sent: Thursday, August 08, 2002 9:12 AM
> To: Martin Chapman
> Cc: 'Champion, Mike'; [email protected]; [email protected]
> Subject: RE: REST, Conversations and Reliability
> 
> 
> 
> Let's be careful when distinguishing between protocol and 
> serialization form. The two are not the same. One could 
> negotiate a gzipped encoding of an XML1.0 serialized infoset 
> and that is clearly not the same as application/soap+xml.
> 
> Let us also be mindful of the fact that increasingly, "the 
> Web" is being stretched into areas that aren't classically 
> thought of as "the Web"; through gateways to mobile/wireless 
> devices, and coming soon, to a kitchen near you, the toaster 
> and 'fridge:)
> 
> Cheers,
> 
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: [email protected]
> phone: +1 508 234 3624
> 
> 
>                                                               
>                                                                     
>                       "Martin Chapman"                        
>                                                                     
>                       <martin.chapman@o        To:       
> Christopher B Ferris/Waltham/IBM@IBMUS, "'Champion, Mike'"    
>            
>                       racle.com>                
> <[email protected]>                            
>                     
>                       Sent by:                 cc:       
> <[email protected]>, <[email protected]>            
>            
>                       www-ws-arch-reque        Subject:  RE: 
> REST, Conversations and Reliability                                  
>                       [email protected]                               
>                                                                     
>                                                               
>                                                                     
>                                                               
>                                                                     
>                       08/08/2002 11:46                        
>                                                                     
>                       AM                                      
>                                                                     
>                                                               
>                                                                     
>                                                               
>                                                                     
> 
> 
> 
> 
> 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: [email protected] 
> [mailto:[email protected]] 
> > On Behalf Of Christopher B Ferris
> > Sent: Thursday, August 08, 2002 5:28 AM
> > To: Champion, Mike
> > Cc: [email protected]; [email protected]
> > 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: [email protected]
> > phone: +1 508 234 3624
> >
> >
> >
> >
> >
> >                       "Champion, Mike"
> >
> >
> >                       <Mike.Champion@Software        To:
> >  [email protected]
> >
> >                       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:[email protected]]
> > > Sent: Wednesday, August 07, 2002 7:54 PM
> > > To: 'Ugo Corda'; 'Champion, Mike'; [email protected]
> > > 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.
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
>