Issue with binding message references in the abstract component model

Following the WG's decision to rename the "name" attribute of the
wsdl:input and wsdl:output elements to "messageReference", and
correspondingly to rename the {name} property of the message
reference component to {messageReference}, we ended up with a
mismatch between the interface-level message reference components
and the binding-level ones.

At the interface level, we have a message reference component with
a {messageReference} property and a fault reference component with
a {name} property. Although the latter needs more work to bring it
into the new brave message-free world, I assume we won't modify its
{name} property; unlike the old message reference component's {name},
the {name} of a fault reference component is indeed arbitrarily
chosen by the WSDL author and it doesn't depend on the MEP in use.

But at the binding level, we have just one component, the binding
message reference component. Since it has a {name} property,
you can readily see that there is a mismatch between it and its
interface-level equivalents.

Here are some visuals:

<interface>
   <operation>
     <input messageReference="A" body="ns:foo"/>
     <output messageReference="B" body="ns:bar"/>
     <outfault name="MyFault" messages="ns:fault1 ns:fault2"/>
   </operation>
</interface>

<binding>
   <operation>
     <input name="A"/>
     <output name="B"/>
     <outfault name="MyFault"/>
   </operation>
</binding>

In order to fix this, I think that we should add a binding fault
reference component (pretty much identical to the existing binding
message reference component), and rename the {name} property of
the binding message reference component to {messageReference}, so
as to match the interface. Then the sample binding would become:

<binding>
   <operation>
     <input messageReference="A"/>
     <output messageReference="B"/>
     <outfault name="MyFault"/>
   </operation>
</binding>

I'd also expect the messageReference attribute on the binding input
element to be optional, just like for an interface operation's input.

Roberto

-- 
Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.
roberto.chinnici@sun.com

Received on Monday, 15 September 2003 18:47:25 UTC