Re: Web-friendly SOAP

Laird Popkin wrote:
> I certainly hope that the SOAP effort retains the "transport agnostic" goal.
> One of the reasons that the ICE 2 effort ( 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.

> ... 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

> 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.

 Paul Prescod

Received on Sunday, 16 June 2002 23:57:39 UTC