RE: Quick Survey - Use SOAP

To point four below: asynchronous messaging might help address the
ice-unsolicited-* messages, whose purpose was to maintain the
request/response symmetry of ICE.

Have ICE spelled in terms of SOAP may actually help absolve the protocol of
the strict adherence to its HTTP-imposed request/response nature.

	Sami


-----Original Message-----
From: Laird Popkin [mailto:laird@io.com]
Sent: Friday, October 27, 2000 3:08 PM
To: S. Mike Dierken; xml-dist-app@w3.org
Subject: RE: Quick Survey - Use SOAP


In considering mapping the ICE (Information & Content Exchange, see
http://www.icestandard.org) XML-based protocol to SOAP, the priorities (IMO,
of course) are:

I'd say that the only requirements are that SOAP support:

1. Synchronous request/response of XML messages. That is, assuming that the
synchronicity is only within a given message stream, so a given ICE
syndicator/subscriber could have many "synchronous" message streams going on
at the same time, each with a different partner.

2. Other: a means of validating extensions and XML messages passed in SOAP
messages. ICE has several elements that would naturally belong in the header
of a SOAP message, and which should be validatable. And all ICE messages are
XML, validatable by the ICE DTD. While we don't require validation, it's a
requirement that all messages be validatable, at the very least for testing
purposes. I've been told that SOAP can do both of these things, but it's not
clear to me how, so perhaps this isn't an issue with SOAP so much as my
understanding how to tackle this within SOAP. This should be done without
merging the SOAP and ICE DTD's.

The other items fall in the realm of possibly useful:

3. multiple subscribers: if this mapped naturally to multicast, this would
be useful. There are many ICE applications which are naturally multicast
(e.g. stock ticker feeds, etc.).

4. asynchronous messaging: perhaps some of the ICE implementors could speak
to this. It's not clear to me how useful this would be.

5. synchronous RPC: ICE could be mapped into RPC calls, by considering each
XML message to be a string parameter passed to an ICE object's "handle
message" method. I'm not sure how this is a better thing than
request/response of XML messages.

For consistency, here's the list you emailed out:

[1] - synchronous request/response generic XML
[5] - synchronous request/response RPC method calls
[4] - asynchronous message to a queue (single consumer)
[3] - asynchronous message to a topic (multiple subscribers)
[2] - other - describe (validate extensions and contents)

Other folks in the ICE AG are on this list as well. Please feel free to jump
in with your own votes...

- Laird Popkin

Received on Monday, 2 October 2000 14:33:24 UTC