RE: SOAP Binding Framework Concerns

Kumeda,

Firstly, I very much like the way that you have framed the issue, the
diagram and the five types contract. Your framing also, clearly identifies
that it is Contract 4 that is at issue.

> Contract4 is very important for an entire system to operate as desired,
but
> shall be defined by the transport layers. In other words, SOAP needs to
use
> whatever services defined by the lower transport layers. If some functions
are
> not provided by a certain transport layer, such as request-response
bindings,
> they need be defined within the SOAP specifications.

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... this is the approach that
IP (and indeed TCP) uses... and the bindings of IP to some underlying
protocols (eg. X.25) do introduce mechanism in order to support the
semantics of IP's 'contract 4'.

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... then I think
there is very little, if anything, we can say normatively about the
mechanisms of 'Contract 3' (which I think we are agreed are in-scope for the
SOAP spec.) because can say nothing about 'Contract 4'.

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

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

Once again, thanks for the framing, I think it helps to get us to the heart
of the issue.

Best regards

Stuart Williams

> -----Original Message-----
> From: Kumeda [mailto:kumeda@atc.yamatake.co.jp]
> Sent: 22 October 2001 11:05
> To: xml-dist-app@w3.org
> Subject: Re: SOAP Binding Framework Concerns
> 
> 
> Please allow me to post to this mailing list for the first time. My name
is
> Yasuo Kumeda, a communications engineer working for Yamatake Corporation
in
> Japan.
> 
> I am in agreement with Marwan's post on the 19, in which he stated
concerns
> against the binding framework. It seems to me that the TBTF may try to
define
> something outside the scope of transport bindings.
> 
> To transfer SOAP messages from one application to another, there are
couple of
> "contracts" associated with the transactions as shown in the figure below.
I
> believe the SOAP biding framework should only define contract2 and
contract3, as
> explained below:
> 
> +-------------------+               +-------------------+
> | Application       |<--contract1-->|  Application      |
> +-------------------+               +-------------------+
>           ^                                   ^
>            | contract2              contract2 |
>           v                                   v
> +-------------------+                +-------------------+
> |     SOAP          |<-- contract3-->|    SOAP           |
> +-------------------+                +-------------------+
>           ^                                   ^
>           | contract4               contract4 |
>           v                                   v
> +-------------------+                +-------------------+
> | Transport         |<-- contract5-->|  Transport        |
> +-------------------+                +-------------------+
> 
> 
> Contract1 is agreements between applications, i.e., SOAP users.
> Contract2 is agreements between a SOAP user and the SOAP communication
layer.
> Contract3 is agreements between two or more SOAP communication layers.
> Contract4 is agreements between the SOAP communication layer and a
transport
> layer.
> Contract5 is agreements between two or more transport layers.
> 
> According to the communication layering model defined by the OSI,
contract1,
> contract3, and contract5 are "PROTOCOLS" between peer communication
layers,
> whereas contract2 and contract4 are "SERVICES" between adjacent
communication
> layers.
> 
> Also according to the layering model, the protocols  are defined by the
peer
> communication layers, and the services  are defined by a lower layer for
the
> corresponding upper layer to use them.
> 
> With these definitions, it is clear that contract1 and contract5 are
outside the
> scope of the TF, and contract3 shall be defined within the SOAP
specifications.
> 
> Contract4 is very important for an entire system to operate as desired,
but
> shall be defined by the transport layers. In other words, SOAP needs to
use
> whatever services defined by the lower transport layers. If some functions
are
> not provided by a certain transport layer, such as request-response
bindings,
> they need be defined within the SOAP specifications.
> 
> With the same token, contract2 shall be defined by the SOAP specifications
as
> they are services provided by SOAP to applications (SOAP's upper layer).
These
> services, if properly defined, assure interoperability among different
> implementations of SOAP communication layer and SOAP applications.
> 
> To realize scenarios described in [1], this service interface may include
>     a) Fire_and_Forget_Multi-services
>     b) Fire_and_Forget_Single-services
>     c) Request-service
>     d) Response-service
>         and so on,
> for instance.
> 
> Best regards,
>     Yasuo Kumeda
> 
> [1] 
> http://www.w3.org/2000/xp/Group/1/10/18-us/XMLProtocolUsageScenarios
> 
> --
> 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 Monday, 22 October 2001 13:32:53 UTC