RE: proposal for changing binding for WSDL 1.2

Hi Sanjiva,

Overall, I like your proposal. In particular, I like the following ideas:
1.  being  able to define "reusable bindings not necessarily constrained to a specific serviceType, porType etc";
2.  the sort of "inheritance" mechanism defined in section 3.1.

IMHO,  one disadvantage of the proposal is that it still sticks to the idea that binding details have to be specified separately for all abstract definition constructs, including <serviceType>s, <portType>s, <operation>s, <input>s, <output>s or <fault>s. as suggested in 3.1(copied below)

 1 <binding name="ncname">
 2   <serviceType name="qname"?>
 3     <!-- binding details -->
 4     <portType name="qname"?>*
 5       <!-- binding details -->
 6       <operation name="ncname"?>*
 7         <!-- binding details -->
 8         <input>
 9           <!-- binding details -->
10         </input>
11         <output>
12           <!-- binding details -->
13         </output>
14         <fault name="qname"?>
15           <!-- binding details -->
16         </fault>
17       </operation>
18     </portType> 
19   </serviceType>
20 </binding>

If we want to move to the direction of "reusable binding", we may take one step further by introducing something like a  <bindingType> element which specifies binding info and can be reused by various level binding definitions.  Expressed in a WSDL grammar style, it can be:

<definition...>
...

<bindingType name = "NCname">*
	<!-- binding details -->
</bindingType>

<binding>*
	<serviceType name = .. bindingType = "qname"?..>*
		<portType name = .. bindingType = "qname"?..>*
			<operation name = .. bindingType = "qname"?..>*
				<input name = .. bindingType = "qname"?..>*
					<parts name= "nmtokens" bindingType = "qname"?...> * 
						<!--parts@name is a list of parts here. It allows to group parts which share same binding types-->
				...
...				


</definition>

The same "inheritance" rule as in your section 3.1 applies: if you omit the  operation@bindingType, the value defined for its parent portType@bindingType applies, so on. 

For an oversimplified example,  instead of repeating binding extension data all the places as in the following

<binding name="eg2">
  <serviceType name="st1">
    <portType name="pt1">
      <soap:body transport="http" style="document"/>
    </portType>
    <portType name="pt2">
      <soap:body transport="http" style="document"/>
    </portType>
   <portType name="pt3">
      <soap:body transport="http" style="rpc"/>
    </portType>
    <portType name="pt4">
      <soap:body transport="http" style="rpc"/>
    </portType>
	...
  </serviceType>
	...
</binding>
 
We can put the binding info in a separate "module", and reuse it:

<bindingType name = "demo1">
     <soap:body transport="http" style="document"/>
</bindingType>

<bindingType name = "demo2">
     <soap:body transport="http" style="rpc"/>
</bindingType>

<binding name="eg2">
  <serviceType name="st1" bindingType = "demo1" >
    <portType name="pt1" />
    <portType name="pt2" />
    <portType name="pt1" bindingType = "demo2"/>
    <portType name="pt2" bindingType = "demo2" />
  </serviceType>
</binding>

IMO, this approach is more modular, and more reusable. The benefit will be more obvious for cases where you have to repeat same binding info in more places.  Even better, this approach also allows <bindingType>s be defined in a separate file, and reused by multiple applications via the import mechanism.

Does it make sense? Of course, it's still preliminary thoughts and I am sure we need to refine it if the group agree that it's a direction we should explore.

Best Regards,
Kevin

> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Wednesday, July 24, 2002 11:14 AM
> To: WS-Desc WG (Public)
> Subject: proposal for changing binding for WSDL 1.2
> 
> 
> I'd like to propose some radical changes to <binding> stuff. The
> main motivation is to better support and exploit the service type
> abtraction. 
> 
> The proposal is attached. Comments please!
> 
> Sanjiva.
>

Received on Tuesday, 20 August 2002 21:21:08 UTC