Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 37039 invoked by uid 500); 1 Oct 2002 14:56:18 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 37029 invoked from network); 1 Oct 2002 14:56:16 -0000 Subject: Re: [wsif] Bug 13038 - WSIF's dynamic port/operation creation confusion about message names To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Nirmal Mukhi" Date: Tue, 1 Oct 2002 10:56:13 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.10 |March 22, 2002) at 10/01/2002 10:56:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: axis-dev@xml.apache.org 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: axis-dev@xml.apache.org | | 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 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" on 27/09/2002 18:41:44 Please respond to axis-dev@xml.apache.org To: 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" To: 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" | > | 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. > > > > > > >