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 Tuesday, 18 June 2002 23:47:56 UTC