- From: Kumeda <kumeda@atc.yamatake.co.jp>
- Date: Tue, 23 Oct 2001 14:19:44 +0900
- 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
(SDUs).
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
later.
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 01:23:48 UTC