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.
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
