- From: Paul Prescod <paul@prescod.net>
- Date: Sun, 16 Jun 2002 20:57:25 -0700
- To: Laird Popkin <laird@io.com>
- CC: xml-dist-app@w3.org, "ice-dev@yahoogroups.com" <ice-dev@yahoogroups.com>, "ice-ag@yahoogroups.com" <ice-ag@yahoogroups.com>
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. > ... 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? > 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