W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

FW: SOAP 1.2 Usage Scenarios

From: Gaertner, Dietmar <Dietmar.Gaertner@softwareag.com>
Date: Wed, 6 Mar 2002 21:41:33 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E621060163BEBC@daemsg02.software-ag.de>
To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

-----Original Message-----
From: Gaertner, Dietmar [mailto:Dietmar.Gaertner@softwareag.com]
Sent: Mittwoch, 6. Marz 2002 18:57
To: 'David Fallside'
Cc: w3c-xml-protocol-wg@w3.org; 'john_ibbotson@uk.ibm.com';
Subject: RE: SOAP 1.2 Usage Scenarios


yes, I came to the conclusion that the scenarios
can be realised with SOAP 1.2. However, I've re-checked
and worked out some additional explanatory text notably
for those cases for which there may be doubts whether
they really can be realised.

Regards, Dietmar.


SOAP 1.2 Usage Scenarios - realizable with SOAP 1.2?

S1   Fire-and-forget to single receiver			OK
S2   Fire-and-forget to multiple receivers		OK, but possible
Note: This can be implemented by repeatedly doing
fire-and forget to a single receiver as suggested
in the scenario description as second method.
The first suggested method "multicast" seems a bit
more problematic. The SOAP spec talk about
"an ultimate receiver". This does not seem to cover
multiple receivers. On the other hand fire and
*forget* avoids the potential problem with
synchronising multiple responses or faults.
Discussion required! 

S3   Request/Response						OK

S4   Remote Procedure Call (RPC)				OK

S5   Request with acknowledgement				OK

S6   Request with encrypted payload				OK

S7   Third party intermediary (marketplace)		OK
Note: While this requires substantial intelligence
at the intermediary - it needs to unterstand the
initial sender's order to be able to contact
the appropriate sellers for offers and chose the
best - the task could be fulfilled even by a
forwarding intermediary. However, this is probably
a good scenario for an active intermediary. The
marketplace may need to transform the byers oder
format into something the selected seller understands
and stuff like that.

S8   Conversational message exchange			OK

S10  Message header and payload encryption		OK
S11  Communication via multiple intermediaries		OK

DS17 Asynchronous messaging					OK

S19  Sending non-XML data					OK ?
Note: This usage scenario is based on SOAP with
attachments. Will SOAP with Attachments still work
with SOAP 1.2?

S20  Multiple asynchronous responses			OK
S21  Incremental parsing/processing of SOAP messages	OK

S23  Event notification						OK

DS24 Caching							OK
Note: the cacheing intermediary sometimes acts as an
intermediary and sometimes as a final SOAP node.
The spec does not explicitely mention this case,
but in my interpretation it is covered too.
S805 Routing							OK

S807 Tracking							OK, with
Note: In the example message, the "Via" elements
from the intermediaries along the way are gathered
in one "Tracking Header" which does not contain a
role attribute (which means that the header is
targetted at the final recipient). This conflicts
with the 7th F2F resolution for issue 137 whereby
forwarding intermediaries must relay all SOAP header
blocks not targeted to them.
Proposed resolution: add a next role attribute.

S809 Caching with expiration					OK
Note: Similar to DS24
S810 Quality of service						OK
Note: The description of the scenario is quite heavy
and there is no example SOAP message. But I believe
the QoS can be realized with SOAP intermediaries
and SOAP header blocks.

-----Original Message-----
From: David Fallside [mailto:fallside@us.ibm.com]
Sent: Mittwoch, 6. Marz 2002 02:11
To: Gaertner, Dietmar
Cc: w3c-xml-protocol-wg@w3.org
Subject: Re: SOAP 1.2 Usage Scenarios

Dietmar, thanks for the review. The original motivation for the review was
to determine whether the scenarios can be realised with SOAP 1.2. Do you
think this is the case?

David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665

|         |           "Gaertner, Dietmar"   |
|         |           <Dietmar.Gaertner@soft|
|         |           wareag.com>           |
|         |           Sent by:              |
|         |           xml-dist-app-request@w|
|         |           3.org                 |
|         |                                 |
|         |                                 |
|         |           03/05/2002 08:44 AM   |
|         |                                 |
  |       To:       John Ibbotson/UK/IBM@IBMGB
  |       cc:       "'jacek@systinet.com'" <jacek@systinet.com>,
"'xml-dist-app@w3.org'" <xml-dist-app@w3.org>           |
  |       Subject:  SOAP 1.2 Usage Scenarios

Hi John,

at the F2F in Mandelieu Jacek an I (replacing DavidF) took an action item
to review the Usage Scenarios. Following is my review summary; Jacek
will provide his in a later reply.

Regards, Dietmar.


- title "XML Protocol Usage Scenarios" --> "SOAP 1.2 Usage Scenarios" ?

- The described usage scenarios are very good and cover a lot of
  reasonable application scenarios.

- There are a few other usage scenarios which I could imagine would
  fit well into the list. My favorites are scenarios with intelligent
  intermediaries which are capable of doing transformations of the
  message content and/or do content based routing.

- the numbering scheme for the senarios is not consistent (or else
  it is not clear what the scheme is):
  S1-S8, S10, S11, S19-S21, S23, S805, S807, S810, DS17, DS24.

- many of the figures are indented too much or are too large,
  such that they get cut off when printed in portrait format

- section 2.3.2 text:
  "... the processing application would generate the *a* document..."

- section 2.5.2 text:
  "... A Status Handler *on* registered..." - remove
  "... and places it *in* the response..."  - add

- section 2.6.2 Example: encrypted SOAP message:
  old SOAP-ENV prefix and schema used
  mustUndestand="1" - change to "true"
  EDNOTE there. Still required?

- root attribute: I guess that the F2F resolution of issue 78
  requires to add root attributes all over the place in the

- section 2.16.1 text:
  "SOAP module" term not defined in the spec
  "... >Cacheability..." - remove ">"

- section 2.21.2 text:
  "actor" --> role
  "QoS" and "QOS" - make consistent, e.g. always "QoS"
Received on Wednesday, 6 March 2002 15:41:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:47 UTC