RE: Web-friendly SOAP

John,

I didn't say "HTTP is a reliable transport."
I said "HTTP *presumes* a reliable transport," TCP, DECNET, e.g.

Joe Hui
Exodus, a Cable & Wireless service
================================================



> -----Original Message-----
> From: John Ibbotson [mailto:john_ibbotson@uk.ibm.com]
> Sent: Wednesday, June 19, 2002 1:06 PM
> To: Joseph Hui
> Cc: ice-ag@yahoogroups.com; ice-dev@yahoogroups.com; Laird 
> Popkin; Paul
> Prescod; Walden Mathews; xml-dist-app@w3.org;
> xml-dist-app-request@w3.org
> Subject: RE: Web-friendly SOAP
> 
> 
> 
> 
> Joe,
> HTTP is NOT a reliable transport.
> John
> 
> Emerging ebusiness Industry Architecture ,
> XML Technology and Messaging,
> IBM UK Ltd, Hursley Park,
> Winchester, SO21 2JN
> 
> Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
> Fax: +44 (0)1962 816898
> Notes Id: John Ibbotson/UK/IBM
> email: john_ibbotson@uk.ibm.com
> 
> 
> 
>                                                               
>                                                             
>                       "Joseph Hui"                            
>                                                             
>                       <Joseph.Hui@exodu        To:       
> "Walden Mathews" <waldenm@ilx.com>, "Laird Popkin"               
>                       s.net>                    
> <laird@io.com>, "Paul Prescod" <paul@prescod.net>             
>             
>                       Sent by:                 cc:       
> <xml-dist-app@w3.org>, <ice-dev@yahoogroups.com>,                
>                       xml-dist-app-requ         
> <ice-ag@yahoogroups.com>, <ice-dev@yahoogroups.com>           
>             
>                       est@w3.org               Subject:  RE: 
> Web-friendly SOAP                                            
>                                                               
>                                                             
>                                                               
>                                                             
>                       19/06/2002 20:36                        
>                                                             
>                       Please respond to                       
>                                                             
>                       "Joseph Hui"                            
>                                                             
>                                                               
>                                                             
>                                                               
>                                                             
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@ilx.com]
> > Sent: Wednesday, June 19, 2002 7:40 AM
> > To: 'Laird Popkin'; Paul Prescod
> > Cc: xml-dist-app@w3.org; ice-dev@yahoogroups.com;
> > ice-ag@yahoogroups.com; ice-dev@yahoogroups.com
> > Subject: RE: Web-friendly SOAP
> >
> > If SOAP and "web services" represent an evolutionary step from using
> > the web interactively (browser and human user) to the less 
> constrained
> > model including non-human agents, then doesn't this strongly imply
> > a corresponding UDP binding for HTTP?  Is there anything unRESTful
> > about asynchronous or connectionless state transfer?
> 
> > Is HTTP/UDP perhaps a key missing piece?
> 
> No, it can't be.
> HTTP presumes a reliable transport, which UDP can't privide.
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> ===========================================
> 
> > Is there discussion on this that anyone out there could point me to?
> >
> > Walden Mathews
> >
> > > -----Original Message-----
> > > From: Laird Popkin [mailto:laird@io.com]
> > > Sent: Tuesday, June 18, 2002 11:15 PM
> > > To: Paul Prescod
> > > Cc: xml-dist-app@w3.org; ice-dev@yahoogroups.com;
> > > ice-ag@yahoogroups.com; ice-dev@yahoogroups.com
> > > Subject: Re: Web-friendly SOAP
> > >
> > >
> > >
> > > On 6/16/2002 11:57 PM, "Paul Prescod" <paul@prescod.net> wrote:
> > >
> > > >
> > > > Laird Popkin wrote:
> > > >>
> > > >> I certainly hope that the SOAP effort retains the
> > > "transport agnostic" goal.
> > > >> One of the reasons that the ICE 2 effort
> > > (http://www.icestandard.org) is
> > > >> adopting SOAP is that it allows ICE to adopt a single
> > > messaging layer, and
> > > >> gain multiple transport bindings automagically.
> > > >
> > > > When you use SOAP over HTTP you get one set of addressing
> > > mechanisms,
> > > > message exchange patterns and semantics. When you use
> > SOAP over UDP,
> > > > SMTP etc., you will get a totally different set.
> > > >
> > > > If ICE is an XML vocabulary format then it will be simple
> > to send it
> > > > over all of these protocols. If it really intends to be an
> > > *application
> > > > protocol* then it is not realistic to think that you will
> > > get support
> > > > for all of those protocols just by running on top of SOAP.
> > > Really, ICE
> > > > over SOAP over HTTP will be one protocol and ICE over SOAP
> > > over UDP will
> > > > be in many ways a totally different protocol.
> > >
> > > ICE is an application protocol. For example, a subscriber can
> > > send a message
> > > ice-get-catalog to a syndicator and receive back an
> > > ice-catalog message
> > > listing all of the content that is offered for syndication,
> > > or a syndicator
> > > could send an ice-update message (containing a bunch of
> > > content) and get
> > > back a confirmation that the content was properly received.
> > > You can get more
> > > info at http://www.icestandard.org if you're curious.
> > >
> > > Certainly the underlying transport will affect the
> > > application level. ICE
> > > has already been mapped over UDP, SMTP, etc., by various
> > > implementers. You'd
> > > use UDP if you needed performance, and didn't mind
> > occasionally losing
> > > messages, or SMTP if you want very loosely connected
> > > messaging. So we don't
> > > expect a "silver bullet".
> > >
> > > The reason to push those mappings down below SOAP is that the
> > > ICE standard
> > > can then be substantially simplified, and focus on the things
> > > that it cares
> > > about (managing subscription relationships and delivering
> > content) and
> > > leverage the work of a bunch of clever people working on
> > > SOAP. We'll still
> > > need to define some application-level issues in terms of the
> > > capabilities of
> > > the selected transport, but that's much better than 
> having to define
> > > _everything_ about each transport binding.
> > >
> > > As far as addressing mechanisms go, ICE assumes that the
> > > endpoints can be
> > > described by a URL, and all other identifiers are internal
> > to the ICE
> > > protocol. For example, if a syndicator says that their address is
> > > "https://ice.contentcorp.com" or
> > "mailto:ice@contentcorp.com" the ICE
> > > protocol doesn't care. Of course, the implementer cares (e.g.
> > > Does HTTP mean
> > > PUT or POST?), but that's defined by the particular protocol
> > > mappings, which
> > > are a separate layer from the ICE protocol. :-) The only
> > > other external
> > > identifier is the address of where to retrieve content by
> > > reference, which
> > > is also a URL.
> > >
> > > >> ... This is better for everyone
> > > >> than if ICE defines its own bindings to each protocol, as
> > > is required by the
> > > >> pre-SOAP ICE 1.0 standard (1998).
> > > >
> > > > Let's say that ICE has a "getFoo" method that takes a
> > > string and returns
> > > > an integer. How is that going to magically work on SOAP
> > > running over a
> > > > protocol without request-response behaviour? (like the
> > > current binding
> > > > of SOAP to SMTP).
> > > >
> > > > Do we expect every protocol binding to implement every
> > > message exchange
> > > > protocol?
> > >
> > > ICE needs to define its requirements of underlying
> > > transports, and/or the
> > > implications of different transport choices. For example, 
> ICE 1.x is
> > > request/response, which can be layered on top of asynchronous
> > > transports. We
> > > haven't decided whether to loosen the request/response model
> > > in ICE 2 --
> > > it's very powerful making everything asynchronous, but 
> that's not a
> > > programming model that's familiar to most programmers, and
> > > requires more
> > > sophisticated implementations.
> > >
> > > So IMO (and we're still figuring this stuff out within the
> > > Ice community)
> > > the answer will be that ICE says that if you're operating over a
> > > request/reponse transport, the application semantics are X,
> > > and if you're
> > > operating over an asynchronous transport the application
> > > semantics are Y.
> > > For example, perhaps we define a layer of request/reponse over any
> > > asynchronous transport. In fact, ICE messages all indicate
> > > whether they were
> > > sent in response to another message, with unique ID's linking
> > > messages and
> > > responses, so that would drop on top of an asynchronous
> > protocol quite
> > > nicely.
> > >
> > > There would be particular exceptions for a few cases where
> > > the "response" in
> > > ICE is a placeholder that conveys no useful information.
> > >
> > > For example, consider the exchange:
> > >
> > > 1. Syndicator pushes a content update to the subscriber, 
> with a flag
> > > indicating that it wants confirmation of delivery.
> > > 2. Subscriber sends "OK" response, indicating delivery of the
> > > content update
> > > message.
> > > 3. Subscriber processes the content (including retrieving any
> > > content that
> > > was transmitted by reference instead of inline), and stores
> > > the content into
> > > the local content store.
> > > 4. Subscriber sends message confirming complete delivery of
> > > the update.
> > > 5. Syndicator sends "OK" response.
> > >
> > > Messages 2 and 5 are probably gratuitous responses.
> > > Admittedly in either
> > > case there's a tiny percentage case of an error due to a
> > > mal-formed message
> > > or other transmission error or software failure, but those
> > > could be handled
> > > by an exception-driven error message rather than a required
> > response.
> > >
> > > So the exchange could be rewritten asynchronously as:
> > >
> > > 1. Syndicator pushes a content update to the subscriber, 
> with a flag
> > > indicating that it wants confirmation of delivery.
> > > 2. Subscriber processes the content (including retrieving any
> > > content that
> > > was transmitted by reference instead of inline), and stores
> > > the content into
> > > the local content store.
> > > 3. Subscriber sends message confirming complete delivery of
> > > the update.
> > >
> > > With two transport-specific rules:
> > > 1. Over request/reponse transports, requests that do not
> > > return a response
> > > (i.e. No ICE-defined data, error or confirmation) return a
> > placeholder
> > > response. This is the current ICE 1.x behavior over HTTP.
> > > 2. Over asynchronous transports, ICE defines an error message
> > > that can be
> > > sent whenever there is an error condition generated when
> > processing a
> > > message that does not otherwise require a "response" message.
> > >
> > > This is "off the cuff" and probably more detail than you
> > > wanted, but I'm
> > > trying to come up with specific protocol examples to help me
> > > think this
> > > thing through.
> > >
> > > Comments?
> > >
> > > >> Realistically, 99% of the time ICE is used over HTTP, and
> > > I would assume the
> > > >> same for SOAP, so that combination needs to be well 
> defined (for
> > > >> interoperability) and work reasonably well. But it's
> > > important not to always
> > > >> require HTTP, because that would prohibit the use of SOAP
> > > and SOAP-based
> > > >> protocols (e.g. ICE 2) over multicast, UDP, SMTP, etc.,
> > > all of which are
> > > >> quite valuable in certain contexts (e.g. Satellite
> > > broadcast of syndicated
> > > >> data, high-speed local data feeds, loosely coupled asynchronous
> > > >> participants, etc.).
> > > >
> > > > There is no doubt that non-HTTP transports and
> > non-request-response
> > > > models are also important. I just don't think that you can
> > > expect for
> > > > that stuff to *automatically work* just by choosing to
> > > build on SOAP.
> > >
> > > I agree in principle. But since ICE has already been mapped
> > > over a variety
> > > of transports, I think it's a matter of abstracting the
> > > mapping rules (e.g.
> > > The example above) and stripping out everything that SOAP
> > > will have defined
> > > already.
> > >
> > > So I suspect we're in violent agreement. What do you think?
> > >
> > > > Paul Prescod
> > >
> > > --
> > > - Laird Popkin
> > >
> >
> >
> 
> 
> 
> 
>

Received on Wednesday, 19 June 2002 16:41:26 UTC