Re: Web-friendly SOAP

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

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

- Laird Popkin
  Chair, ICE Authoring Group
  laird@io.com

P.S. Anyone interested in the ICE 2 effort (moving ICE to SOAP/WSDL/UDDI,
formalizing protocol modularity) is invited to join the ice-dev mailing list
on Yahoo Groups.

On 6/16/2002 6:44 PM, "Paul Prescod" <paul@prescod.net> wrote:

> 
> Eric Newcomer wrote:
>> 
>> ...
>> 
>> My big concern with the move toward HTTP specific binding for SOAP is losing
>> the ability to easily map to JMS, MQ Series, CORBA, J2EE, etc.
> 
> If there is an HTTP binding then I think it has to follow the Web's
> rules of how to use HTTP. The W3C cannot produce recommendations and
> findings that disagree with each other.
> 
>> ... I know Mark
>> Baker says we can do it anyway, and perhaps we can, but to me one of the big
>> questions is whether or not we are thinking about just sending the entire
>> message over the transport, and letting the "endpoints" decide what to do
>> with it, and how to interpret it.
> 
> I agree with you that there is a tension between SOAP being a good
> player on top of HTTP and SOAP being "transport agnostic." If I were
> more involved in SOAP I would strongly argue that SOAP should choose one
> or the other because doing both creates an increasingly
> difficult-to-understand specification. But years ago it was decided to
> do both. I don't think that that is going to change now.
> 
> I'll go further and say that I think that there is a tension between
> being a *web* protocol and being transport agnostic. Web protocols will
> naturally put URIs at the center of their design. That's tricky to do
> running over protocols that have no notion of URI.
> 
> Paul Prescod
> 

--

Received on Sunday, 16 June 2002 21:38:43 UTC