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?  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 10:40:33 UTC