- From: Marwan Sabbouh <ms@mitre.org>
- Date: Wed, 24 Oct 2001 10:31:03 -0400
- To: Marc Hadley <marc.hadley@sun.com>
- CC: Kumeda <kumeda@atc.yamatake.co.jp>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org
Welcome to the discussion Marc;
Let us take your example one step further and say someone wants reliable delivery of
SOAP messages over UDP. There are two ways of doing it
Case 1: Since UDP is unreliable, that person uses a reliable delivery protocol that
works on top of UDP. We Call it xxRTP. The protocol stack then looks like this:
+-------------------+ +-------------------+
| Application |<--contract1-->| Application |
+-------------------+ +-------------------+
^ ^
| contract2 contract2 |
v v
+-------------------+ +-------------------+
| SOAP |<-- contract3-->| SOAP |
+-------------------+ +-------------------+
^ ^
| contract4 contract4 |
v v
+-------------------+ +-------------------+
| xxRTP |<-- contract5-->| xxRTP |
+-------------------+ +-------------------+
in this case, xxRTP provides the reliability and correlation of requests and replies.
I conclude that all is needed is a mapping that shows how SOAP messages are carried in
xxRTP's PDUs.
Case 2: Someone would like to provide reliability and correlation at a higher layer.
He might do it this way:
+-------------------+ +-------------------+
| Application |<--contract1-->| Application |
+-------------------+ +-------------------+
+-------------------+ +-------------------+
| Reliability/correlation Reliability/correlation
+-------------------+ +-------------------+ ||
^ ^
contract2 contract2 v
^
^ v
+-------------------+ +-------------------+
| SOAP |<-- contract3-->| SOAP |
+-------------------+ +-------------------+
^ ^
| contract4 contract4 |
v v
+-------------------+ +-------------------+
|UDP |<-- contract5-->| UDP |
+-------------------+ +-------------------+
In the above scenario, the reliability and correlation must be defined in terms of
SOAP header blocks. In my opinion, it is not our task to define those header blocks
that implements this functionality. Rather, our task should be to define a mechanism
by which a SOAP processor imports this functionality and makes it available for
interested applications. The file that defines those header blocks can be called a
module. This module can be formally specified by another WG or a standard body and it
MUST use SOAP.
Note that you need to specify how SOAP messages are carried in UDP's PDUs. Also note
that the SOAP processor did not change in both cases.
Best regards;
Marwan
Marc Hadley wrote:
> Kumeda wrote:
> >
> > Section 5 may be misleading: the text may suggest that there exists a binding
> > layer that provides certain functionality. However in 5.1.4 Sample Mappings
> > section, the tables show exactly what I modeled as Contract 4, i.e., use service
> > primitives provided by the underlying transport layer and use them to carry SOAP
> > messages.
> >
> PMFJI, but I'm a bit confused about the problem here. What's to stop me
> writing a binding spec that provides e.g. reliable request-response over
> an unreliable one way transport like UDP ? I.e. where the "binding layer
> provides certain functionality" like correlating requests and responses
> and adding reliability.
>
> I agree that the binding spec has to show how to carry SOAP messages in
> undelying PDUs but that is only part of the job. Am I missing something ?
>
> Regards,
> Marc.
>
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Centre, Sun Microsystems.
Received on Wednesday, 24 October 2001 10:36:07 UTC