Re: SCA & WS Binding Wrapper Style
Jean-Sebastien Delfino wrote: Simon Laws wrote: [snip] The assumption I'm making from the info you gave is that you want to have two SCA components communicate with the same domain but be able to specify the WSDL that the web services binding uses. I guess what you would need to be able to do is specify a binding something like target="MyServiceComponent/MyService"> http://tuscany.apache.org#wsdl.binding(MyServiceSOAP11Binding)"/> etc.. Where you are referencing a WSDL binding but not providing a service location with a view to having the domain sort this out for you. A similar thing would appear on the service end also. This all sounds plausible but I just took a look at the SCA WebServices binding specification and it says that when the #wsdl.binding form is used the endpoint address URI must be provided via the URI attribute on the binding which makes it a little difficult for the domain logic to help you out. There is a possibility that this is a fault in the spec in this case but let me try a few experiments and think about it a little before we call it out. If others know the answer now feel free to jump in. My understanding is that wiring is not limited to the SCA binding. It's probably a bug in the WS binding spec, which should allow the WS endpoint address to be determined through wiring in the domain. In other words the above XML snippet should be made to work. +1. I have raised a spec issue with the SCA bindings TC for this. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA & WS Binding Wrapper Style
Simon Nash wrote: I have been looking at the JAX-WS and JAXB specs and I think it should be possible to pass nulls when using the default Java to XML mapping. Can you open a JIRA and attach a test case that shows the problem you are having with this? Simon One more comment: Tuscany's current JavaBean<->XML transformers are not consistent yet with the JAXB spec. They should be fixed, or should just be replaced by the JAXB-based transformers that we already have. We are currently discussing this on the tuscany-dev list there [1]. [1] http://marc.info/?l=tuscany-dev&m=119611568803375 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA & WS Binding Wrapper Style
Either the original class name would have to be passed on the wire by the sender, or the receiver would have to tell the Tuscany databinding framework what class to use for each interface type that's received. The former isn't very interoperable (e.g., if talking to a non-Java environment), and the latter couldn't cope with multiple classes being passed through the same interface. I am sure JAXB has some solution to this, but it wasn't revealed by a casual glance through the spec. I'll try harder to find this information. Can anyone else provde a pointer? Simon Bentley Johnson wrote: I found another modification that will have to be done, unless there is alternative, however, this may be related to Javabeans being used for object serialization. In many instances, the parameters or return types of our service methods are java interfaces and there are implementations of these interfaces being created and used. When the XML is created for sending over the binding, it attempts to use the interface as the java class that must be created on the receiving end. The reflection being used can of course not create an instance of the interface and it throws an exception. Is there any way to specific for it to use the actual class implementation when converted to and from XML? Thanks, Bentley -Original Message- From: Simon Nash <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Mon, 26 Nov 2007 21:56:55 + Subject: Re: SCA & WS Binding Wrapper Style Bentley, What modifications are needed to your code to make it conform to the doc/lit/wrapped standard? Is this just the removal of overloaded nethod names, or something else? Simon Bentley Johnson wrote: Hello, thanks for the response and input. One thing I realized was that I didn't make clear in my original post was that I am working with the distributed domain/node system which seems to use only the SCA binding by default with the Remotable annotation. This does not allow me to use the WSDL configurations. This assumption is based on the sample distributed code and testing I have attempted. Using the default SCA binding of that configuration seems to always use the wrapper (document/literal) mode. This is not a large issue, as my code can be modified to conform to its standards. If there is some other way to have the services register within the domain that I have not seen, that information would be appreciated. Thanks Bentley -Original Message- From: "Simon Laws" <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Thu, 22 Nov 2007 11:28:24 + Subject: Re: SCA & WS Binding Wrapper Style Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: It seems that both the default SCA binding for Remotable Interfaces and the basic WS binding are being restricted to the services following the wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. style. This is being set within the org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the createWSDLInterfaceContract method. From my understanding, this implies that all methods in the service must have a return type that is not void and that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]] ) overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? Is there a way to set it to not use the wrapper style or is it just the standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. where the remote version of the SCA binding is in use, choose the doc/lit/wrapped style and stick with that. If alternative styles are required then this would be configured using a separately/manually autho
Re: SCA & WS Binding Wrapper Style
I have been looking at the JAX-WS and JAXB specs and I think it should be possible to pass nulls when using the default Java to XML mapping. Can you open a JIRA and attach a test case that shows the problem you are having with this? Simon Bentley Johnson wrote: Simon, Yes, it requires the removal of overloaded methods and I also have to change any java objects to be in a javabean format. Although, this would have to be done either way. Our system had some code which was not conformed to javabean style and since we are now converting to use Tuscany, it must be updated for the java object creation by tuscany. I had thought that the non-void return type was an issue, but I tried the sample mentioned in the previous response and think it should work just fine. There is also a different issue that I have discovered and was going to post about, but I was trying to check the old mailing lists first. I did not find it mentioned there. It seems that the the Transformer classes for converting to and from XML for both simple and javabean styled objects does not handle the inclusion of null values. This includes both passing in a null as a parameter or returning null from a method. Is this a desired/required situation that nulls can not be used? or is it a flaw in the conversion. The one exception where null values do process correctly are null Strings. If this is a requirement, then I would also have to change logic in my system to work around not being able to use null values. This may be problematic. Thanks, Bentley -Original Message- From: Simon Nash <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Mon, 26 Nov 2007 21:56:55 + Subject: Re: SCA & WS Binding Wrapper Style Bentley, What modifications are needed to your code to make it conform to the doc/lit/wrapped standard? Is this just the removal of overloaded nethod names, or something else? Simon Bentley Johnson wrote: Hello, thanks for the response and input. One thing I realized was that I didn't make clear in my original post was that I am working with the distributed domain/node system which seems to use only the SCA binding by default with the Remotable annotation. This does not allow me to use the WSDL configurations. This assumption is based on the sample distributed code and testing I have attempted. Using the default SCA binding of that configuration seems to always use the wrapper (document/literal) mode. This is not a large issue, as my code can be modified to conform to its standards. If there is some other way to have the services register within the domain that I have not seen, that information would be appreciated. Thanks Bentley -Original Message- From: "Simon Laws" <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Thu, 22 Nov 2007 11:28:24 +0000 Subject: Re: SCA & WS Binding Wrapper Style Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: It seems that both the default SCA binding for Remotable Interfaces and the basic WS binding are being restricted to the services following the wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. style. This is being set within the org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the createWSDLInterfaceContract method. From my understanding, this implies that all methods in the service must have a return type that is not void and that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]] ) overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? Is there a way to set it to not use the wrapper style or is it just the standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. wher
Re: SCA & WS Binding Wrapper Style
Simon Laws wrote: [snip] The assumption I'm making from the info you gave is that you want to have two SCA components communicate with the same domain but be able to specify the WSDL that the web services binding uses. I guess what you would need to be able to do is specify a binding something like http://tuscany.apache.org#wsdl.binding(MyServiceSOAP11Binding)"/> etc.. Where you are referencing a WSDL binding but not providing a service location with a view to having the domain sort this out for you. A similar thing would appear on the service end also. This all sounds plausible but I just took a look at the SCA WebServices binding specification and it says that when the #wsdl.binding form is used the endpoint address URI must be provided via the URI attribute on the binding which makes it a little difficult for the domain logic to help you out. There is a possibility that this is a fault in the spec in this case but let me try a few experiments and think about it a little before we call it out. If others know the answer now feel free to jump in. My understanding is that wiring is not limited to the SCA binding. It's probably a bug in the WS binding spec, which should allow the WS endpoint address to be determined through wiring in the domain. In other words the above XML snippet should be made to work. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA & WS Binding Wrapper Style
I found another modification that will have to be done, unless there is alternative, however, this may be related to Javabeans being used for object serialization. In many instances, the parameters or return types of our service methods are java interfaces and there are implementations of these interfaces being created and used. When the XML is created for sending over the binding, it attempts to use the interface as the java class that must be created on the receiving end. The reflection being used can of course not create an instance of the interface and it throws an exception. Is there any way to specific for it to use the actual class implementation when converted to and from XML? Thanks, Bentley -Original Message- From: Simon Nash <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Mon, 26 Nov 2007 21:56:55 + Subject: Re: SCA & WS Binding Wrapper Style Bentley, What modifications are needed to your code to make it conform to the doc/lit/wrapped standard? Is this just the removal of overloaded nethod names, or something else? Simon Bentley Johnson wrote: > Hello, thanks for the response and input. > > One thing I realized was that I didn't make clear in my original post was > that I am working with the distributed domain/node system which seems to use > only the SCA binding by default with the Remotable annotation. This does not > allow me to use the WSDL configurations. This assumption is based on the > sample distributed code and testing I have attempted. > > Using the default SCA binding of that configuration seems to always use the > wrapper (document/literal) mode. This is not a large issue, as my code can > be modified to conform to its standards. If there is some other way to have > the services register within the domain that I have not seen, that > information would be appreciated. > > Thanks > > Bentley > > -Original Message- > > From: "Simon Laws" <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Date: Thu, 22 Nov 2007 11:28:24 + > > Subject: Re: SCA & WS Binding Wrapper Style > > > > > Hi Bentley > > > > Some comments/questions below > > > > Regards > > > > Simon > > > > On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: > > > > >>It seems that both the default SCA binding for Remotable Interfaces and > > >>the > > >>basic WS binding are being restricted to the services following the > > >>wrapper > > > > > It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany > > Java2WSDL will use this style. The SCA WebService spec says that, when the > > web services binding points to separately authored WSDL files, it allows > > anything that is valid in the WSDL binding. I can't guarantee that this > > actually works at the moment as I would need to try it but the > > specifications intention is that it is supported. > > > > > >>style. This is being set within the > > >>org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the > > >>createWSDLInterfaceContract method. From my understanding, this implies > > >>that > > >>all methods in the service must have a return type that is not void and > > >>that > > > > > You should be able to have a void return type. There is an itest that shows > > an example ( > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] > [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]] > > ) > > > > > >>overloaded methods are not allowed. > > > > > Do you mean WSDL operations with the same name but with different > > parameters? > > > > > >>Is there a way to set it to not use the wrapper style or is it just the > > >>standard that is used by the SCA binding and must be followed? > > > > > I think the intention is that any web services communications that go on > > under Tuscany's control, e.g. where the remote version of the SCA binding is > > in use, choose the doc/lit/wrapped style and stick with that. If alternative > > styles are require
Re: SCA & WS Binding Wrapper Style
Simon, Yes, it requires the removal of overloaded methods and I also have to change any java objects to be in a javabean format. Although, this would have to be done either way. Our system had some code which was not conformed to javabean style and since we are now converting to use Tuscany, it must be updated for the java object creation by tuscany. I had thought that the non-void return type was an issue, but I tried the sample mentioned in the previous response and think it should work just fine. There is also a different issue that I have discovered and was going to post about, but I was trying to check the old mailing lists first. I did not find it mentioned there. It seems that the the Transformer classes for converting to and from XML for both simple and javabean styled objects does not handle the inclusion of null values. This includes both passing in a null as a parameter or returning null from a method. Is this a desired/required situation that nulls can not be used? or is it a flaw in the conversion. The one exception where null values do process correctly are null Strings. If this is a requirement, then I would also have to change logic in my system to work around not being able to use null values. This may be problematic. Thanks, Bentley -Original Message- From: Simon Nash <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Mon, 26 Nov 2007 21:56:55 + Subject: Re: SCA & WS Binding Wrapper Style Bentley, What modifications are needed to your code to make it conform to the doc/lit/wrapped standard? Is this just the removal of overloaded nethod names, or something else? Simon Bentley Johnson wrote: > Hello, thanks for the response and input. > > One thing I realized was that I didn't make clear in my original post was > that I am working with the distributed domain/node system which seems to use > only the SCA binding by default with the Remotable annotation. This does not > allow me to use the WSDL configurations. This assumption is based on the > sample distributed code and testing I have attempted. > > Using the default SCA binding of that configuration seems to always use the > wrapper (document/literal) mode. This is not a large issue, as my code can > be modified to conform to its standards. If there is some other way to have > the services register within the domain that I have not seen, that > information would be appreciated. > > Thanks > > Bentley > > -Original Message- > > From: "Simon Laws" <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Date: Thu, 22 Nov 2007 11:28:24 + > > Subject: Re: SCA & WS Binding Wrapper Style > > > > > Hi Bentley > > > > Some comments/questions below > > > > Regards > > > > Simon > > > > On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: > > > > >>It seems that both the default SCA binding for Remotable Interfaces and > > >>the > > >>basic WS binding are being restricted to the services following the > > >>wrapper > > > > > It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany > > Java2WSDL will use this style. The SCA WebService spec says that, when the > > web services binding points to separately authored WSDL files, it allows > > anything that is valid in the WSDL binding. I can't guarantee that this > > actually works at the moment as I would need to try it but the > > specifications intention is that it is supported. > > > > > >>style. This is being set within the > > >>org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the > > >>createWSDLInterfaceContract method. From my understanding, this implies > > >>that > > >>all methods in the service must have a return type that is not void and > > >>that > > > > > You should be able to have a void return type. There is an itest that shows > > an example ( > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] > [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/]] > > ) > > > > > >>overloaded methods are not allowed. > > > > > Do you mean WSDL operations with the same name
Re: SCA & WS Binding Wrapper Style
Bentley, What modifications are needed to your code to make it conform to the doc/lit/wrapped standard? Is this just the removal of overloaded nethod names, or something else? Simon Bentley Johnson wrote: Hello, thanks for the response and input. One thing I realized was that I didn't make clear in my original post was that I am working with the distributed domain/node system which seems to use only the SCA binding by default with the Remotable annotation. This does not allow me to use the WSDL configurations. This assumption is based on the sample distributed code and testing I have attempted. Using the default SCA binding of that configuration seems to always use the wrapper (document/literal) mode. This is not a large issue, as my code can be modified to conform to its standards. If there is some other way to have the services register within the domain that I have not seen, that information would be appreciated. Thanks Bentley -Original Message- From: "Simon Laws" <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Thu, 22 Nov 2007 11:28:24 +0000 Subject: Re: SCA & WS Binding Wrapper Style Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: It seems that both the default SCA binding for Remotable Interfaces and the basic WS binding are being restricted to the services following the wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. style. This is being set within the org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the createWSDLInterfaceContract method. From my understanding, this implies that all methods in the service must have a return type that is not void and that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] ) overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? Is there a way to set it to not use the wrapper style or is it just the standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. where the remote version of the SCA binding is in use, choose the doc/lit/wrapped style and stick with that. If alternative styles are required then this would be configured using a separately/manually authored WSDL to describe what style is required. I would imagine this would very likely to be the case if SCA is configured to talk to web services that are provided by other, non-SCA, systems. Here you would expect to be able to get the WSDL from the service provided. Do you have a scenario that requires the use of something other than the doc/lit/wrapped style in the case that one SCA component is talking to another SCA component with the same domain? Thanks -Bentley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA & WS Binding Wrapper Style
On Nov 26, 2007 8:58 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: > Hello, thanks for the response and input. > > One thing I realized was that I didn't make clear in my original post was > that I am working with the distributed domain/node system which seems to > use > only the SCA binding by default with the Remotable annotation. This does > not > allow me to use the WSDL configurations. This assumption is based on the > sample distributed code and testing I have attempted. > > Using the default SCA binding of that configuration seems to always use > the > wrapper (document/literal) mode. This is not a large issue, as my code can > be modified to conform to its standards. If there is some other way to > have > the services register within the domain that I have not seen, that > information would be appreciated. > > Thanks > > Bentley > > -Original Message- > > From: "Simon Laws" <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Date: Thu, 22 Nov 2007 11:28:24 + > > Subject: Re: SCA & WS Binding Wrapper Style > > > > > Hi Bentley > > > > Some comments/questions below > > > > Regards > > > > Simon > > > > On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> > wrote: > > > > > It seems that both the default SCA binding for Remotable Interfaces and > > > the > > > basic WS binding are being restricted to the services following the > > > wrapper > > > > It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany > > Java2WSDL will use this style. The SCA WebService spec says that, when > the > > web services binding points to separately authored WSDL files, it allows > > anything that is valid in the WSDL binding. I can't guarantee that this > > actually works at the moment as I would need to try it but the > > specifications intention is that it is supported. > > > > > > > > style. This is being set within the > > > org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the > > > createWSDLInterfaceContract method. From my understanding, this implies > > > that > > > all methods in the service must have a return type that is not void and > > > that > > > > You should be able to have a void return type. There is an itest that > shows > > an example ( > > > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ > [ > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ > ] > > ) > > > > > > > > overloaded methods are not allowed. > > > > Do you mean WSDL operations with the same name but with different > > parameters? > > > > > > > > Is there a way to set it to not use the wrapper style or is it just the > > > standard that is used by the SCA binding and must be followed? > > > > I think the intention is that any web services communications that go on > > under Tuscany's control, e.g. where the remote version of the SCA binding > is > > in use, choose the doc/lit/wrapped style and stick with that. If > alternative > > styles are required then this would be configured using a > > separately/manually authored WSDL to describe what style is required. I > > would imagine this would very likely to be the case if SCA is configured > to > > talk to web services that are provided by other, non-SCA, systems. Here > you > > would expect to be able to get the WSDL from the service provided. Do you > > have a scenario that requires the use of something other than the > > doc/lit/wrapped style in the case that one SCA component is talking to > > another SCA component with the same domain? > > > > > > > > > > > Thanks > > > > > > -Bentley > > > > > > > > > > > > > > > Hi Bentley Yes, you are right. The mechanism for automatically locating services in a domain and providing the correct wiring endpoints for release 1.0 does rely on using the default SCA binding. When used remotely the default SCA binding relies on web services and generates, on the fly, all the necessary information to make the end to end connections work. This of course involves making some assumptions, one of which is the use of the doc/literal/wrapped style. When you are talking to web services outside of SCA you can of course use binding.ws and specify the WSDL of your choice. Recently I added some code to the node implementation in subversion trunk to make the automatic lookup
Re: SCA & WS Binding Wrapper Style
Hello, thanks for the response and input. One thing I realized was that I didn't make clear in my original post was that I am working with the distributed domain/node system which seems to use only the SCA binding by default with the Remotable annotation. This does not allow me to use the WSDL configurations. This assumption is based on the sample distributed code and testing I have attempted. Using the default SCA binding of that configuration seems to always use the wrapper (document/literal) mode. This is not a large issue, as my code can be modified to conform to its standards. If there is some other way to have the services register within the domain that I have not seen, that information would be appreciated. Thanks Bentley -Original Message- From: "Simon Laws" <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Date: Thu, 22 Nov 2007 11:28:24 +0000 Subject: Re: SCA & WS Binding Wrapper Style Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: > It seems that both the default SCA binding for Remotable Interfaces and > the > basic WS binding are being restricted to the services following the > wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. > > style. This is being set within the > org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the > createWSDLInterfaceContract method. From my understanding, this implies > that > all methods in the service must have a return type that is not void and > that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ [http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/] ) > > overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? > > Is there a way to set it to not use the wrapper style or is it just the > standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. where the remote version of the SCA binding is in use, choose the doc/lit/wrapped style and stick with that. If alternative styles are required then this would be configured using a separately/manually authored WSDL to describe what style is required. I would imagine this would very likely to be the case if SCA is configured to talk to web services that are provided by other, non-SCA, systems. Here you would expect to be able to get the WSDL from the service provided. Do you have a scenario that requires the use of something other than the doc/lit/wrapped style in the case that one SCA component is talking to another SCA component with the same domain? > > > Thanks > > -Bentley > > > >
Re: SCA & WS Binding Wrapper Style
Simon Laws wrote: Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: It seems that both the default SCA binding for Remotable Interfaces and the basic WS binding are being restricted to the services following the wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. style. This is being set within the org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the createWSDLInterfaceContract method. From my understanding, this implies that all methods in the service must have a return type that is not void and that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ ) overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? Is there a way to set it to not use the wrapper style or is it just the standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. where the remote version of the SCA binding is in use, choose the doc/lit/wrapped style and stick with that. If alternative styles are required then this would be configured using a separately/manually authored WSDL to describe what style is required. I would imagine this would very likely to be the case if SCA is configured to talk to web services that are provided by other, non-SCA, systems. Here you would expect to be able to get the WSDL from the service provided. Do you have a scenario that requires the use of something other than the doc/lit/wrapped style in the case that one SCA component is talking to another SCA component with the same domain? I checked the SCA specs to see what they say about this. The Web Service binding spec says that generated Java interfaces are document/literal. The Java Annotations and APIs spec says that Java interfaces are mapped to WSDL using JAX-WS rules. The JAX-WS spec says that Java to WSDL mappings can be document literal, document bare, or RPC. Putting all these together, the valid options for an SCA implementation mapping Java to WSDL over the Web Service binding are document literal and document bare. The document bare mapping of JAX-WS has the following limitations: In order to qualify for use of bare mapping mode a Java method must fulfill all of the following criteria: 1. It must have at most one in or in/out non-header parameter. 2. If it has a return type other than void it must have no in/out or out non-header parameters. 3. If it has a return type of void it must have at most one in/out or out non-header parameter. Tuscany currently only supports document literal for the automatic Java to WSDL mapping. Since document bare mapping has more limitations than document literal mapping, I'm not sure why it would make sense to add this as an option. If there is a use case that requires document bare as an automatic mapping, Tuscany could support the javax.jws.SOAPBinding annotation to allow this to be specified. Regarding method overloading, the JAX-WS spec requires implementations to support the use of the javax.jws.WebMethod annotation to disambiguate overloaded Java method names when mapped to WSDL. I am not sure whether Tuscany currently supports this annotation for the automatic Java to WSDL mapping. If it doesn't, this support should be added. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA & WS Binding Wrapper Style
Hi Bentley Some comments/questions below Regards Simon On Nov 21, 2007 7:04 PM, Bentley Johnson <[EMAIL PROTECTED]> wrote: > It seems that both the default SCA binding for Remotable Interfaces and > the > basic WS binding are being restricted to the services following the > wrapper It certainly use doc/lit/wrapped by default and WSDL generated by Tuscany Java2WSDL will use this style. The SCA WebService spec says that, when the web services binding points to separately authored WSDL files, it allows anything that is valid in the WSDL binding. I can't guarantee that this actually works at the moment as I would need to try it but the specifications intention is that it is supported. > > style. This is being set within the > org.apache.tuscany.sca.binding.ws.axis2.Java2WSDLHelper class in the > createWSDLInterfaceContract method. From my understanding, this implies > that > all methods in the service must have a return type that is not void and > that You should be able to have a void return type. There is an itest that shows an example ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/ws-void-args-return/ ) > > overloaded methods are not allowed. Do you mean WSDL operations with the same name but with different parameters? > > Is there a way to set it to not use the wrapper style or is it just the > standard that is used by the SCA binding and must be followed? I think the intention is that any web services communications that go on under Tuscany's control, e.g. where the remote version of the SCA binding is in use, choose the doc/lit/wrapped style and stick with that. If alternative styles are required then this would be configured using a separately/manually authored WSDL to describe what style is required. I would imagine this would very likely to be the case if SCA is configured to talk to web services that are provided by other, non-SCA, systems. Here you would expect to be able to get the WSDL from the service provided. Do you have a scenario that requires the use of something other than the doc/lit/wrapped style in the case that one SCA component is talking to another SCA component with the same domain? > > > Thanks > > -Bentley > > > >
