I'm inclined to go with the lenient code I suggested below which allows the
binding input/output names to not match if there's only one binding
operation matching the portType operation name.
The WSDL spec seems a bit ambiguous on whether the binding operation
input/output names must match, but going by where the spec is clear, then
it should be legal to have a portType without input/output names, and a
binding specifying input/output names that match the default names
described in section 2.4.5. But, WSDL4J doesn't yet implement these
defaults, so if WSIF enforced the rule that if the binding operation
input/output does have names then they must match the portType operation
input/output names, then the WSDL would be rejected.
To fix that WSIF would have to implement the default names described in
2.4.5 - check the String returned from the WSDL4J Input/Output getName()
method for null or "", find the operation style, and implement the
algorithm in 2.4.5. I don't think WSIF should be doing this.
It seems better for now to let some rare cases of slightly invalid WSDL
through as valid, than to have strictly correct WSDL be rejected.
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Jeff Greif" <[EMAIL PROTECTED]> on 01/10/2002 18:19:22
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation
confusion about message names
I think you were right the first time. The point about the default value
of
portType/operation/input@name is telling.
Jeff
----- Original Message -----
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 01, 2002 9:34 AM
Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation
confusion about message names
> OK, this is an edge case. Nirmal's right probably in terms
> of how the spec is today, but it really should be that if
> the user does give a name in one place, then it must be
> that that matches with the name in the other place (whether
> it was auto-gen'ed or manually-gen'ed).
>
> BTW, the W3C WSDL WG has decided to remove operation overloading
> from WSDL 1.2. Phew.
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Nirmal Mukhi" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, October 01, 2002 8:56 PM
> Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation
> confusion about message names
>
>
> >
> >
> >
> >
> >
> > Hi,
> >
> > If the operation name is unique (i.e. the operation is not overloaded)
my
> > reading of the spec tells me that it doesn't matter if the input/output
> > names don't match (the binding operation matches with the abstract one
> > irrespective of that). IMO the binding operation's input and output
names
> > don't matter (for the purposes of matching with an abstract operation)
> > unless there is a need to resolve operation overloading.
> >
> > Nirmal.
> >
> >
> >
> > "Owen D
> > Burroughs" To:
> [EMAIL PROTECTED]
> > <[EMAIL PROTECTED] cc:
> > > Subject: Re: [wsif] Bug
> 13038 - WSIF's dynamic port/operation creation confusion
> > about message names
> > 10/01/2002 06:48
>
> > AM
> > Please respond to
> > axis-dev
> >
> >
> >
> >
> >
> > Ant,
> >
> > I think there is a scenario that your proposed fix allows that possibly
it
> > shouldn't:
> >
> > If there is one operation in the port type with the name "op1" and one
> > operation in the binding with the same name, your code matches the two
> > operations regardless of what the input and output names are. I believe
> > that this would be incorrect when the input (output) name is set on
both
> > operations but with a different value, for example in the port type,
> > operation "op1" has an input name of "in1" but in the binding the
> operation
> > "op1" has an input name on "in2". The WSDL spec makes the input/output
> > names on port type and binding operations optional, but does state that
> for
> > overloaded operations the names should match. Can this be interpreted
> > further to mean that if these names are specified in both the port type
> and
> > the binding then they should match?
> >
> > I would ask, if the input/output names are specified in both the port
type
> > operation and the binding operation, but don't match, is this valid
wsdl?
> >
> > What does anyone else think?
> >
> > Owen
> >
> >
> >
> > |---------+---------------------------->
> > | | Anthony |
> > | | Elder/UK/IBM@IBMG|
> > | | B |
> > | | |
> > | | 01/10/2002 08:59 |
> > | | Please respond to|
> > | | axis-dev |
> > | | |
> > |---------+---------------------------->
> > >
>
>
--------------------------------------------------------------------------
> ------------------------------------------------------------------------|
> >
> > |
> > |
> > | To: [EMAIL PROTECTED]
> > |
> > | cc:
> > |
> > | Subject: Re: [wsif] Bug 13038 - WSIF's dynamic
port/operation
> > creation confusion about message names
> > |
> > |
> > |
> > |
> > |
> > >
>
>
--------------------------------------------------------------------------
> ------------------------------------------------------------------------|
> >
> >
> >
> >
> >
> > So Jeff can get past the problem, if I don't hear otherwise from anyone
> > I'll commit this later today and change the AXIS provider to use it.
> >
> > ...ant
> >
> > Anthony Elder
> > [EMAIL PROTECTED]
> > Web Services Development
> > IBM UK Laboratories, Hursley Park
> > (+44) 01962 818320, x248320, MP208.
> >
> >
> > Anthony Elder/UK/IBM@IBMGB on 30/09/2002 09:46:17
> >
> > Please respond to [EMAIL PROTECTED]
> >
> > To: [EMAIL PROTECTED]
> > cc:
> > Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation
creation
> > confusion about message names
> >
> >
> >
> >
> > I think I agree with Jeff. If there is only one binding operation that
> > matches the portType operation then WSIF should use it regardless of
the
> > input/output message names.
> >
> > How about adding the something like the following code to WSIFUtils and
> > changing the providers to use it instead of the WSDL4J
> > BindingImpl.getBindingOperation method? This code doesn't take into
> account
> > the default portType names described in the 2.4.5 in the WSDL spec, I
> think
> > WSDL4J should really be doing that in the javax.wsdl.Input/Output
classes.
> >
> >
> > public static BindingOperation getBindingOperation(
> > Binding binding,
> > String opName,
> > String inName,
> > String outName) throws WSIFException {
> >
> > BindingOperation bo = null;
> > if (binding != null && opName != null) {
> > ArrayList matchingOps = new ArrayList();
> > List bops = binding.getBindingOperations();
> > if (bops != null) {
> > for (Iterator i = bops.iterator(); i.hasNext();) {
> > BindingOperation bop = (BindingOperation) i.next();
> > if ( opName.equals(bop.getName()) ) {
> > matchingOps.add(bop);
> > }
> > }
> > if (matchingOps.size() == 1) {
> > bo = (BindingOperation) matchingOps.get(0);
> > } else if (matchingOps.size() > 1) {
> > bo = chooseBindingOperation(matchingOps, inName,
outName);
> > }
> > }
> > }
> > return bo;
> > }
> >
> > private static BindingOperation chooseBindingOperation(
> > ArrayList bindingOps,
> > String inName,
> > String outName) throws WSIFException {
> >
> > BindingOperation choosenOp = null;
> > for (Iterator i = bindingOps.iterator(); i.hasNext(); ) {
> > BindingOperation bop = (BindingOperation) i.next();
> > String binName = (bop.getBindingInput() == null) ?
> > null :
> > bop.getBindingInput().getName();
> > String boutName = (bop.getBindingOutput() == null) ?
> > null :
> > bop.getBindingOutput().getName();
> > if ((inName == null) ? binName == null :
inName.equals(binName))
> {
> > if ((outName == null)
> > ? boutName == null
> > : outName.equals(boutName)) {
> > if ( choosenOp == null ) {
> > choosenOp = bop;
> > } else {
> > throw new WSIFException(
> > "duplicate operation in binding: " +
> > bop.getName() +
> > ":" + inName +
> > ":" + outName );
> > }
> > }
> > }
> > }
> > return choosenOp;
> > }
> >
> >
> > ...ant
> >
> > Anthony Elder
> > [EMAIL PROTECTED]
> > Web Services Development
> > IBM UK Laboratories, Hursley Park
> > (+44) 01962 818320, x248320, MP208.
> >
> >
> > "Jeff Greif" <[EMAIL PROTECTED]> on 27/09/2002 18:41:44
> >
> > Please respond to [EMAIL PROTECTED]
> >
> > To: <[EMAIL PROTECTED]>
> > cc:
> > Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation
creation
> > confusion about message names
> >
> >
> >
> > I believe the following to be a correct reading of the spec:
> >
> > 1. The portType/operation and binding/operation elements each have
name
> > attributes which are required and must match.
> > 2. The portType/operation/{input, output} elements have message
> > attributes which are required and must match the message element names.
> > 3. The portType/operation/{input, output} elements have name
attributes
> > which are optional according to the grammar but default to values given
by
> > an algorithm in section 2.4.5 if not provided.
> > 4. The binding/operation/{input, output} elements do *not* have name
> > attributes, according to the schema in the appendix, but are allowed to
> > have
> > names according to section 2.5. However, the improved schema for wsdl
> > currrently at the xmlsoap.org site *does* have optional name attributes
on
> > these messages.
> > 5. The spec does not explicitly say in section 2.5 that
> > binding/operation/input@name must match portType/operation/input@name
(and
> > similarly for output) if an ambiguity needs to be resolved where there
are
> > two or more possible operations on the same portType with the same
name,
> > but
> > clearly, this is the only possible way to do it with the given
> information.
> >
> > Using that improved schema, the change A. Elder suggested to the
> XEMBL.wsdl
> > mentioned in the bug report (providing name attributes to the
> > binding/operation/{input,output} elements, preserves its validity.
> Against
> > the schema in the appendix to the spec, I think the change would be
> > invalid.
> > Forcing rewrites of wsdl descriptors already in use for a considerable
> time
> > seems like a bad idea, given that in this case, there are no
ambiguities.
> > The correct operation can be determined from the operation name alone,
so
> > failing to determine is probably not acceptable, and newly requiring
> values
> > of attributes which are supposed to be optional except when needed to
> > resolve ambiguity should probably not be acceptable either.
> >
> > The question raised by O. Burroughs, as to whether it's legal to
specify
> > the
> > portType/operation/input@name but not the binding/operation/input@name
> > seems
> > to me to have a definite answer. The latter attributes are optional,
but
> > the former attributes are optional but have a default value according
to
> > 2.4.5, hence always exist implicitly at least. Thus, if the latter
> > attributes must be allowed to be unspecified as long as there is no
> > amibiguity.
> >
> > Thus, the getBindingOperation code must be prepared to find an
operation
> > without the help of binding/operation/input and output message names,
> > unless
> > an ambiguity has to be resolved.
> >
> > Jeff
> > ----- Original Message -----
> > From: "Owen D Burroughs" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Friday, September 27, 2002 4:36 AM
> > Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation
> > confusion about message names
> >
> >
> > >
> > > Ant,
> > >
> > > You misquoted me slightly :-)
> > >
> > > Here's a slightly more detailed version of my proposed "wsif-only"
fix:
> > >
> > > Try to find the bindingOperation using the input/output names given.
> Then
> > > if no match is found, try using null for the input/output names. If a
> > match
> > > is then found we know that only one operation exists in the binding
with
> > > the same name as the operation we're looking for (for more details
see
> > the
> > > com.ibm.wsdl.BindingImpl.getBindingOperation method in wsdl4j). Now
> check
> > > the input/output names of the "matched" bindingOperation object. If
they
> > > are null then we accept it as a match. If they are not null then we
> > > consider it to be a different operation.
> > >
> > > One downside to this is that you inspect/iterate over the binding
> > > operations twice. It's also still up for debate as to whether
specifying
> > > input/output names in a port type operation and not specifying them
in
> > the
> > > corresponding binding operation is valid. The spec suggests it isn't
for
> > > overloaded operations, which makes sense, but seems to allow any
> > > combination of port type/binding, input/output names for
non-overloaded
> > > operations.
> > >
> > > Owen
> > >
> > > Owen Burroughs
> > > [EMAIL PROTECTED]
> > >
> > >
> > >
> > > |---------+---------------------------->
> > > | | Anthony |
> > > | | Elder/UK/IBM@IBMG|
> > > | | B |
> > > | | |
> > > | | 27/09/2002 11:58 |
> > > | | Please respond to|
> > > | | axis-dev |
> > > | | |
> > > |---------+---------------------------->
> > >
> > >
>
>
--------------------------------------------------------------------------
> -
> >
-----------------------------------------------------------------------|
> > > |
> > |
> > > | To: [EMAIL PROTECTED]
> > |
> > > | cc: "Jeff Greif" <[EMAIL PROTECTED]>
> > |
> > > | Subject: [wsif] Bug 13038 - WSIF's dynamic port/operation
> > creation confusion about message names
> > |
> > > |
> > |
> > > |
> > |
> > >
> > >
>
>
--------------------------------------------------------------------------
> -
> >
-----------------------------------------------------------------------|
> > >
> > >
> > >
> > > There's a bugzilla bug raised for wsif,
> > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13038, to do with
wsif
> > > not correctly finding an operation.
> > >
> > > The problem is because the wsdl,
http://www.ebi.ac.uk/xembl/XEMBL.wsdl,
> > > specifies an input name on the operation in the portType, but does
not
> > > specify a name on the input in the binding. This causes the wsdl4j
> method
> > > getBindingOperation in com.ibm.wsdl.BindingImpl to return null when
wsif
> > > calls it with the operation, input, and output names from the
portType.
> > >
> > > Reading the wsdl spec it not clear to me if it is valid wsdl to leave
> out
> > > the names on the binding when they're specified in the portType.
> > >
> > > If it is valid is this a wsdl4j bug or should wsif work around it?
> > >
> > > We could fix it in wsif by doing something like (thanks Owen) trying
to
> > > find the bindingOperation using the input/output names given, then if
no
> > > match is found try using null for the input/output names, and then if
> > still
> > > no match is then found check to see if the binding input/output names
> for
> > > the matched operation are null. If they are then use that
> > bindingOperation.
> > > If not then return null since it is not a "match".
> > >
> > > What does anyone think?
> > >
> > > ...ant
> > >
> > > Anthony Elder
> > > [EMAIL PROTECTED]
> > > Web Services Development
> > > IBM UK Laboratories, Hursley Park
> > > (+44) 01962 818320, x248320, MP208.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
