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:06:27 UTC