- From: Gaertner, Dietmar <Dietmar.Gaertner@softwareag.com>
- Date: Wed, 6 Mar 2002 21:41:33 +0100
- 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'; 'jacek@systinet.com' Subject: RE: SOAP 1.2 Usage Scenarios David, 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 issue! 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 modifications 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 fallside@us.ibm.com |---------+---------------------------------> | | "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 http://lists.w3.org/Archives/Public/xmlp-comments/2002Mar/0002.html requires to add root attributes all over the place in the examples. - 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