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

Re: SOAP Binding Framework Concerns

From: Marwan Sabbouh <ms@mitre.org>
Date: Mon, 22 Oct 2001 11:14:03 -0400
Message-ID: <3BD437BB.48BBE8FF@mitre.org>
To: Kumeda <kumeda@atc.yamatake.co.jp>
CC: xml-dist-app@w3.org
Hi Kumeda;

I am in agreement with everything you said with one minor exception:

You wrote:
If some functions are
not provided by a certain transport layer, such as request-response bindings,
they need be defined within the SOAP specifications.

I will add:

.....  defined within the SOAP specifications, or at a higher layer.  An example of
this layer would be a SOAP application or a SOAP module.

Do you agree?
Marwan

Kumeda wrote:

> 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 contract1and 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 11:15:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT