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 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 06:05:12 UTC