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
Overriding remotable
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld remotable=true/
binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
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:
Re: Overriding remotable
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws simonsl...@googlemail.com wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld remotable=true/
binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld looks
like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
AUTO: Rahul Gupta is out of office (returning 02/21/2012)
I am out of the office until 02/21/2012. I will be out of office starting Friday (02/18) through Monday (02/20), returning to work on Monday (05/09). During this absence, I may not have network connectivity. For those items that cannot wait until my return, please contact the following : Manan Lihala ( Manan Lihala/India/IBM ) - WAS, Portal and Geronimo Anantha Sreenivasan ( Anantha S Sreenivasan/India/IBM) - WMQ and WMB Lijo Mathew ( Lijo Mathew1/India/IBM ) - Z/OS ( WAS and WMQ ) For Management escalations please contact the following: Henry Aguillon ( Henry Aguillon/Dallas/IBM ) Regina Manuel ( Regina Manuel/Greensboro/IBM ) Note: This is an automated response to your message Re: Question about wsdl.service and SOAP intent sent on 17/2/12 19:31:00. This is the only notification you will receive while this person is away.
