- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Thu, 8 Aug 2002 09:22:28 -0700
- To: "'Christopher B Ferris'" <chrisfer@us.ibm.com>
- Cc: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>, <www-ws-arch-request@w3.org>
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:chrisfer@us.ibm.com] > Sent: Thursday, August 08, 2002 9:12 AM > To: Martin Chapman > Cc: 'Champion, Mike'; www-ws-arch@w3.org; www-ws-arch-request@w3.org > 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: chrisfer@us.ibm.com > phone: +1 508 234 3624 > > > > > "Martin Chapman" > > <martin.chapman@o To: > Christopher B Ferris/Waltham/IBM@IBMUS, "'Champion, Mike'" > > racle.com> > <Mike.Champion@SoftwareAG-USA.com> > > Sent by: cc: > <www-ws-arch@w3.org>, <www-ws-arch-request@w3.org> > > www-ws-arch-reque Subject: RE: > REST, Conversations and Reliability > st@w3.org > > > > > > 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: 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 12:23:10 UTC