Re: SOAP Binding Framework Concerns

Please see comments below.
Marc Hadley wrote:

> Marwan Sabbouh wrote:
> >
> > 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.
> >
> ...and the specification of xxRTP which in my view can equally be in the
> binding spec as in a separate spec.



>
>
> The key thing here is that the binding can say "I support a specific
> flavour of request response" (where a specific flavour of request
> response is identified by a URI and is an instance of a message exchange
> pattern - one or more of which we may define in the spec, leaving others
> to define additional ones as required) and the SOAP layer knows that
> what that binding means by request response is the same as any other
> binding. That way I can write my SOAP application in blissfull ignorance
> of which underlying protocol is being used rather than tying it to a
> particular underlying protocol and it's details. This, I think, is what
> the binding framework is trying to set the foundations for.
>

Your assertion:  if the binding support a specific
flavour of request response ( where a specific flavour of request
response is identified by a URI and is an instance of a message exchange
pattern... , then we "can write my SOAP application in blissfull ignorance of which
underlying protocol is being used rather than tying it to a particular underlying protocol
and it's details"

Please explain that?

 it is unclear to me how the above assertion hold true or what  the real value is. It seems
to me that the SOAP application programmer still needs ( and wants) to specify the protocol
he needs to use.  It is true that he does not need ( want) to deal with the details of the
protocol, but this is possible whether or not you specify those MEPs and is done by the SOAP
vendor.

Thanks;
Marwan

>
> > Case 2: Someone would like to provide reliability and correlation at a higher layer.
>
> Agree with what you wrote here. We provide the module framework (i.e.
> the SOAP envelope and processing rules) rather than every conceivable
> module. The binding framework is trying to do the same thing below SOAP.
>
> Regards,
> Marc.
> --
> Marc Hadley <marc.hadley@sun.com>
> XML Technology Centre, Sun Microsystems.

Received on Wednesday, 24 October 2001 16:43:01 UTC