Re: SOAP Binding Framework Concerns

Yasuo, Stuart;

Please see comments below.  Thank u both for a productive discussion.

Kumeda wrote:

> Hello Stuart:
>
> Thank you very much for regarding the model I proposed for the starting point of
> our discussion. Let me comment and answer your E-mail.
>
> > One of the reasons that Contract 4 is important is because it effectively
> > defines the semantics of the channel over which SOAP operates. Once you can
> > 'articulate' the nature of a 'Contract 4' then you can work (within SOAP) on
> > the protocol mechanisms (Contract 3) required to support 'Contract 2'.
> > The TBTF is trying to address the issue of Contract 4.
> > We could take an approach that 'normalised' 'Contract 4' ie. regardless of
> > what lies below, all 'Contract 4's are the same...
>
> In my opinion, Contract 4 is provided by an underlying transport layer. In this
> content the "binding" defines how to use available services provided by the
> lower transport layer to realize any of the scenarios,  and not to define any
> new functions between the two layers. Since every transport layer has different
> set of services, I think it is next to impossible to define a common contract
> between the SOAP and an arbitrary transport layer.

I am in Full agreement here!


>
>
> If you agree with the paragraph above, the first thing the TBTF needs to do is
> to pick a transport mechanism, say HTTP, select services it provide, and define
> interfaces for SOAP to embed SOAP messages into HTTP's service data units
> (SDUs).

How about this instead?

If you agree with the paragraph above, the first thing the TBTF needs to do is
to pick a transport mechanism, say HTTP, select services it provide, and define
the on-the-wire representation  of SOAP messages embedded into HTTP's service data
units
(SDUs).  Please Comment!



>
>
> Since these frameworks may vary from one transport to another, and SOAP is not
> intended to map on a particular transport layer, I believe it is more
> appropriate to define them as separate, non-normative annex.

I Agree

>
>
> > Alternatively... we could take a view that every different underlying
> > protocol and binding provides different services into the SOAP layer, in
> > which case, different protocols/protocol+binding have different 'contract
> > 4's. If we then go on to leave that competely open-ended...
>
> I believe this is the approach we should take, but I do not think we would end
> up with very little interoperability. If bindings with a certain transport layer
> is well defined, any two implementations can interoperate perfectly.

I agree

>
>
> > I think that the TBTF is trying to tread a middle path where there is not a
> > single normalised 'Contract 4' but where there is a repetoire of 'component
> > descriptions' that can be matched to the capabilities of particular
> > underlying protocols (and their bindings).
>
> If you mean what I described above, you and I are in agreement. However, if our
> picks of transport layers are, say, UDP and HTTP, how can you find a single
> normalized contract to realize a request-response scenario

>
>
> > I'd like to ask you, if you have no knowledge of 'contract 4' how do you
> > develop the mechanism of 'contract 3' to support 'contract 2'?
>
> The answer is I can't. I do need to know what the underlying layer provides for
> me. My point is, Contract 4 is given to SOAP when we pick "a" transport layer.
> At that time we know the services provided by the layer and then we can define
> "a" binding framework for this particular transport layer, with which all the
> implementations of SOAP should interoperate.
>
> BTW, we need to define services provided by SOAP to its user. Let's discuss this
> later.
>

Yes Yes

>
> Best regards,
>     Yasuo
>
> >
> >>
> >> +-------------------+               +-------------------+
> >> | Application       |<--contract1-->|  Application      |
> >> +-------------------+               +-------------------+
> >>           ^                                   ^
> >>            | contract2              contract2 |
> >>           v                                   v
> >> +-------------------+                +-------------------+
> >> |     SOAP          |<-- contract3-->|    SOAP           |
> >> +-------------------+                +-------------------+
> >>           ^                                   ^
> >>           | contract4               contract4 |
> >>           v                                   v
> >> +-------------------+                +-------------------+
> >> | Transport         |<-- contract5-->|  Transport        |
> >> +-------------------+                +-------------------+
> >>
> >>
>
> --
> Kumeda, Yasuo                          TEL: +81-466-20-2430
>                                        FAX: +81-466-20-2431
> Research and Development Headquarters
> Yamatake Corporation
>
> Fujisawashi Kawana 1-12-2
> Kanagawa, 251-8522 JAPAN

Received on Tuesday, 23 October 2001 09:45:52 UTC