RE: Web-friendly SOAP

> -----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 15:35:26 UTC