- From: Marwan Sabbouh <ms@mitre.org>
- Date: Mon, 22 Oct 2001 11:14:03 -0400
- 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 UTC