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: [email protected]
>
> 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
>
> >
>
> >
>
> >
>
> >
>
>
> 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 of node endpoints work for other types of bindings
also but it's not well tested yet. I'm currently filling out more of the
domain functions and this is one of the parts of the jigsaw which I'm
circling back round to complete.
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....
<component name="MyClientComponent">
<implementation.java class="org.apache.tuscany.SomeImpl"/>
<reference name="myService" target="MyServiceComponent/MyService">
<binding.ws wsdlElement="
http://tuscany.apache.org#wsdl.binding(MyServiceSOAP11Binding)"/>
</reference>
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.
As you identified your alternative I'm afraid at the moment is to go with
the default binding.
Regards
Simon
