W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: SOAP Binding Framework Concerns

From: Kumeda <kumeda@atc.yamatake.co.jp>
Date: Tue, 23 Oct 2001 14:19:44 +0900
Message-Id: <200110230543.OAA78379@ATCGATE.atc.yamatake.co.jp>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: xml-dist-app@w3.org
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.

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

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.

> 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 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

Best regards,

>> +-------------------+               +-------------------+
>> | 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 01:23:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC