You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Anthony Elder <an...@uk.ibm.com> on 2002/10/01 09:59:21 UTC
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
ant.elder@uk.ibm.com
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 axis-dev@xml.apache.org
To: axis-dev@xml.apache.org
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
ant.elder@uk.ibm.com
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Jeff Greif" <jg...@alumni.princeton.edu> on 27/09/2002 18:41:44
Please respond to axis-dev@xml.apache.org
To: <ax...@xml.apache.org>
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" <OW...@uk.ibm.com>
To: <ax...@xml.apache.org>
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
> owenb@apache.org
>
>
>
> |---------+---------------------------->
> | | Anthony |
> | | Elder/UK/IBM@IBMG|
> | | B |
> | | |
> | | 27/09/2002 11:58 |
> | | Please respond to|
> | | axis-dev |
> | | |
> |---------+---------------------------->
>
>
---------------------------------------------------------------------------
-----------------------------------------------------------------------|
> |
|
> | To: axis-dev@xml.apache.org
|
> | cc: "Jeff Greif" <jg...@alumni.princeton.edu>
|
> | 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
> ant.elder@uk.ibm.com
> Web Services Development
> IBM UK Laboratories, Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
>
>
>
>
>