Re: [ice-dev] Re: Web-friendly SOAP

I agree with Laird's thoughts. From ICE perspective (and I assume from the
perspective of many other application level protocols which are dependent
upon SOAP) it is important that SOAP provides the freedom to use different
transports. This becomes even more critical as ICE starts syndicating Web
Services (See ICE 2.0 requirements for details).

I sincerely hope that SOAP community will keep this in mind as they move
forward with their current specification efforts.

Thanks,

Alok Srivastava
(alok.z.srivastava@oracle.com)

----- Original Message -----
From: "Laird Popkin" <laird@io.com>
To: "Paul Prescod" <paul@prescod.net>; <eric.newcomer@iona.com>;
<xml-dist-app@w3.org>
Cc: "'Jacek Kopecky'" <jacek@systinet.com>; "'Mark Baker'"
<distobj@acm.org>; <ice-dev@yahoogroups.com>; <ice-ag@yahoogroups.com>
Sent: Sunday, June 16, 2002 9:38 PM
Subject: [ice-dev] 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
| >
|
| --
|
|
|
| ------------------------ Yahoo! Groups Sponsor ---------------------~-->
| Free $5 Love Reading
| Risk Free!
| http://us.click.yahoo.com/3PCXaC/PfREAA/Ey.GAA/W6uqlB/TM
| ---------------------------------------------------------------------~->
|
| To unsubscribe from this group, send an email to:
| ice-dev-unsubscribe@yahoogroups.com
|
|
|
| Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|
|
|

Received on Monday, 17 June 2002 11:08:05 UTC