RE: proposal for changing binding for WSDL 1.2

 (I sent this to Kevin days ago, but forgot to include the WS-Desc list)

 Kevin,
 I'm afraid that while being more modular and more reusable, your
proposal is also more complex to grasp. The meaning of specifying
soap:body on wsdl:service/@bindingType is simple - the element will
apply wherever among the descendants of the service where it is
recognized. 
 But there is the IMHO non-obvious expectation that one extensibility
element QName has one global meaning and won't be confused in some WSDL
contexts. Even if machine would not be confused, users might.
 Furthermore, WSDL hierarchy is quite simple and not meant to be
extended. Therefore I think Sanjiva's proposal is simpler than yours and
suitable for almost as many cases. The rare cases where your proposal
would really bring benefits are not worth the additional conceptual
complexity, IMHO.
 Anyway, I think both proposals are very much a 2.0 material, not
necessary for 1.2.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Wed, 2002-08-21 at 03:20, Liu, Kevin wrote:
> 
> 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
>

Received on Tuesday, 10 September 2002 09:28:23 UTC