- From: Kumeda <kumeda@atc.yamatake.co.jp>
- Date: Mon, 22 Oct 2001 19:04:54 +0900
- To: xml-dist-app@w3.org
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