Re: Question about wsdl.service and SOAP intent
On Thu, Feb 16, 2012 at 4:00 AM, Greg Dritschler greg.dritsch...@gmail.com wrote: For something that seems so simple, this is turning into a quagmire. The web service binding processor is not the best place to test intents because the builder obviously has not yet run and propagated intents down to the binding. It would only be able to test the intent on the binding itself. The other option is to do the selection in the reference binding provider, and actually it does happen that way now. By the point where the provider gets control, the binding's port is null. Axis2ReferenceBindingProvider has code to select the port. Unlike the web service binding provider, it doesn't just pick the first. It gives preference to the first port with a SOAP 1.1 address element, and it can't find one it takes the first SOAP 1.2 port. How is the binding's port null in the provider if the processor previously selected the first port? Well, WSDLServiceGenerator tests if the user WSDL provided a port by calling binding.getPortName(). Since the binding model is still marked unresolved, it returns null (this is wsdl.service so there is no port name). This causes WSDLServiceGenerator to import all the bindings and set the binding's port to null. Why is the binding model still unresolved? Well, the processor's resolve operation never marks it resolved. So, if the provider already has to select the port, why not have it use the SOAP intent to drive a selection? Well, when the binding processor selected the first port, it set the binding uri to that port's address. Then when WSDLServiceGenerator copies the ports over to the wrapper WSDL, it stores the binding uri into the port address. So the address to use is clobbered. Ok, let's change the binding processor to not select a port for wsdl.service since the provider's going to choose it anyway. Well, when I tried this, I got a NoSuchElementException in WebServiceBindingImpl.setIsDocumentStyle(). The binding is null, so it looks for the first WSDL Message in the Definition to determine the document style. In my case the main WSDL document has no Messages of its own but imports them from another file. I suppose this is a problem that could be hit in other ways and I just got unlucky. I guess I can continue to poke away at this, but I'm beginning to wonder if this functionality is worth the effort. On Wed, Feb 15, 2012 at 12:53 PM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: When a web service binding uses wsdl.service, WebServiceBindingProcessor picks the first port. if (model.getPortName() != null) { port = service.getElement().getPort(model.getPortName()); } else { // BWS20006 - no port specified so pick the first one port = (Port)service.getElement().getPorts().values().iterator().next(); } What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a port that uses a matching SOAP binding? The web services binding specification says: 139 If the binding is for an SCA reference, the set of available ports for the reference consists of the 140 ports in the WSDL service that have portTypes which are compatible supersets of the SCA 141 reference as defined in the SCA Assembly Model specification [SCA-Assembly] and satisfy all 142 the policy constraints of the binding. Greg Sounds right to me. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com It sounds like that to get the WSDL gen to work properly the port has to be selected before the provider runs. But it looks like this test can't even be moved to the WebServiceBindingBuilder as that runs before the CompositePolicyBuilder. Tricky. The fix that first comes to mind based on what you've described is to try and correct the WSDL gen piece so that it doesn't mess up the URL so that there is a chance of performing the proper selection in the provider. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Question about wsdl.service and SOAP intent
I was thinking about having the WebServiceBindingBuilder perform the port selection. It calls the WebServiceBinding methods getBinding(), setBinding(), and setGeneratedWSDLDocument() which drive determineWSDLCharacteristics() under the covers. It seems like this should be done consistently with the final port selection. Off the top of my head, I can't see why CompositePolicyBuilder would depend on WSDLServiceGenerator running first. Maybe I should try reversing them. On Fri, Feb 17, 2012 at 9:01 AM, Simon Laws simonsl...@googlemail.comwrote: On Thu, Feb 16, 2012 at 4:00 AM, Greg Dritschler greg.dritsch...@gmail.com wrote: For something that seems so simple, this is turning into a quagmire. The web service binding processor is not the best place to test intents because the builder obviously has not yet run and propagated intents down to the binding. It would only be able to test the intent on the binding itself. The other option is to do the selection in the reference binding provider, and actually it does happen that way now. By the point where the provider gets control, the binding's port is null. Axis2ReferenceBindingProvider has code to select the port. Unlike the web service binding provider, it doesn't just pick the first. It gives preference to the first port with a SOAP 1.1 address element, and it can't find one it takes the first SOAP 1.2 port. How is the binding's port null in the provider if the processor previously selected the first port? Well, WSDLServiceGenerator tests if the user WSDL provided a port by calling binding.getPortName(). Since the binding model is still marked unresolved, it returns null (this is wsdl.service so there is no port name). This causes WSDLServiceGenerator to import all the bindings and set the binding's port to null. Why is the binding model still unresolved? Well, the processor's resolve operation never marks it resolved. So, if the provider already has to select the port, why not have it use the SOAP intent to drive a selection? Well, when the binding processor selected the first port, it set the binding uri to that port's address. Then when WSDLServiceGenerator copies the ports over to the wrapper WSDL, it stores the binding uri into the port address. So the address to use is clobbered. Ok, let's change the binding processor to not select a port for wsdl.service since the provider's going to choose it anyway. Well, when I tried this, I got a NoSuchElementException in WebServiceBindingImpl.setIsDocumentStyle(). The binding is null, so it looks for the first WSDL Message in the Definition to determine the document style. In my case the main WSDL document has no Messages of its own but imports them from another file. I suppose this is a problem that could be hit in other ways and I just got unlucky. I guess I can continue to poke away at this, but I'm beginning to wonder if this functionality is worth the effort. On Wed, Feb 15, 2012 at 12:53 PM, Simon Laws simonsl...@googlemail.com wrote: On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: When a web service binding uses wsdl.service, WebServiceBindingProcessor picks the first port. if (model.getPortName() != null) { port = service.getElement().getPort(model.getPortName()); } else { // BWS20006 - no port specified so pick the first one port = (Port)service.getElement().getPorts().values().iterator().next(); } What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a port that uses a matching SOAP binding? The web services binding specification says: 139 If the binding is for an SCA reference, the set of available ports for the reference consists of the 140 ports in the WSDL service that have portTypes which are compatible supersets of the SCA 141 reference as defined in the SCA Assembly Model specification [SCA-Assembly] and satisfy all 142 the policy constraints of the binding. Greg Sounds right to me. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com It sounds like that to get the WSDL gen to work properly the port has to be selected before the provider runs. But it looks like this test can't even be moved to the WebServiceBindingBuilder as that runs before the CompositePolicyBuilder. Tricky. The fix that first comes to mind based on what you've described is to try and correct the WSDL gen piece so that it doesn't mess up the URL so that there is a chance of performing the proper selection in the provider. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA:
Question about wsdl.service and SOAP intent
When a web service binding uses wsdl.service, WebServiceBindingProcessor picks the first port. if (model.getPortName() != null) { port = service.getElement().getPort(model.getPortName()); } else { // BWS20006 - no port specified so pick the first one port = (Port)service.getElement().getPorts().values().iterator().next(); } What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a port that uses a matching SOAP binding? The web services binding specification says: 139 If the binding is for an SCA reference, the set of available ports for the reference consists of the 140 ports in the WSDL service that have portTypes which are compatible supersets of the SCA 141 reference as defined in the SCA Assembly Model specification [SCA-Assembly] and satisfy all 142 the policy constraints of the binding.
Re: Question about wsdl.service and SOAP intent
On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: When a web service binding uses wsdl.service, WebServiceBindingProcessor picks the first port. if (model.getPortName() != null) { port = service.getElement().getPort(model.getPortName()); } else { // BWS20006 - no port specified so pick the first one port = (Port)service.getElement().getPorts().values().iterator().next(); } What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a port that uses a matching SOAP binding? The web services binding specification says: 139 If the binding is for an SCA reference, the set of available ports for the reference consists of the 140 ports in the WSDL service that have portTypes which are compatible supersets of the SCA 141 reference as defined in the SCA Assembly Model specification [SCA-Assembly] and satisfy all 142 the policy constraints of the binding. Greg Sounds right to me. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Question about wsdl.service and SOAP intent
For something that seems so simple, this is turning into a quagmire. The web service binding processor is not the best place to test intents because the builder obviously has not yet run and propagated intents down to the binding. It would only be able to test the intent on the binding itself. The other option is to do the selection in the reference binding provider, and actually it does happen that way now. By the point where the provider gets control, the binding's port is null. Axis2ReferenceBindingProvider has code to select the port. Unlike the web service binding provider, it doesn't just pick the first. It gives preference to the first port with a SOAP 1.1 address element, and it can't find one it takes the first SOAP 1.2 port. How is the binding's port null in the provider if the processor previously selected the first port? Well, WSDLServiceGenerator tests if the user WSDL provided a port by calling binding.getPortName(). Since the binding model is still marked unresolved, it returns null (this is wsdl.service so there is no port name). This causes WSDLServiceGenerator to import all the bindings and set the binding's port to null. Why is the binding model still unresolved? Well, the processor's resolve operation never marks it resolved. So, if the provider already has to select the port, why not have it use the SOAP intent to drive a selection? Well, when the binding processor selected the first port, it set the binding uri to that port's address. Then when WSDLServiceGenerator copies the ports over to the wrapper WSDL, it stores the binding uri into the port address. So the address to use is clobbered. Ok, let's change the binding processor to not select a port for wsdl.service since the provider's going to choose it anyway. Well, when I tried this, I got a NoSuchElementException in WebServiceBindingImpl.setIsDocumentStyle(). The binding is null, so it looks for the first WSDL Message in the Definition to determine the document style. In my case the main WSDL document has no Messages of its own but imports them from another file. I suppose this is a problem that could be hit in other ways and I just got unlucky. I guess I can continue to poke away at this, but I'm beginning to wonder if this functionality is worth the effort. On Wed, Feb 15, 2012 at 12:53 PM, Simon Laws simonsl...@googlemail.comwrote: On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: When a web service binding uses wsdl.service, WebServiceBindingProcessor picks the first port. if (model.getPortName() != null) { port = service.getElement().getPort(model.getPortName()); } else { // BWS20006 - no port specified so pick the first one port = (Port)service.getElement().getPorts().values().iterator().next(); } What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a port that uses a matching SOAP binding? The web services binding specification says: 139 If the binding is for an SCA reference, the set of available ports for the reference consists of the 140 ports in the WSDL service that have portTypes which are compatible supersets of the SCA 141 reference as defined in the SCA Assembly Model specification [SCA-Assembly] and satisfy all 142 the policy constraints of the binding. Greg Sounds right to me. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com