Hi,
The SCA spec says that we follow the JAXWS rules to map between remotable
java interfaces and WSDL port types. There are two things involved:
1) WSDL portType <--> Java Interface (JAXWS)
2) XSD <--> Java Types (Databinding specific)
Ideally, the JAXWS WSDL2Java/Java2WSDL tools shouold allow different
databindings to be plugged in to handle the XSD2Java/Java2XSD generations.
Unfortunately, the JAXWS RI wsimport/wsgen tool doesn't have the
pluggability yet to add SDO support.
An alternative is that we develop/use a tool to only generate artifacts for
1 (I don't see an option for the JAXWS wsimport/wsgen tool to disable the
XSD handling either) and use databinding-specific Java/XSD code gen. I think
the only connection between the two tools are the package <--> namespace
mapping rules.
Based on the above, I don't think we should add generateSEI to SDO. Instead,
we should have SEI2WSDL and WSDL2SEI tools in SCA.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2008 2:52 AM
To: "tuscany-dev" <tuscany-dev@ws.apache.org>
Subject: Re: Tuscany Java2WSDL and WSDL2Java tools
On Thu, May 22, 2008 at 9:31 AM, ant elder <[EMAIL PROTECTED]> wrote:
On Wed, May 21, 2008 at 5:03 PM, Scott Kurz <[EMAIL PROTECTED]> wrote:
That 'generate-sdo' only generates the Java types from the schema types,
right?
It's the WSDL2Java which maps portType operations t**o Java methods and
(last I checked) our
W2J is the only tool which knows how to do this with an SDO databinding.
Yes after playing around with the tools i think thats right. It looks
like
the current Tuscany/SCA W2J tool generates just a service interface but
not
the types for the operation arguments, and that interface is annotated
with
the osoa @Service and @Remotable annotataions. So to use that interface
you
must use another tool to generate the Java classes for the types (and
hope
that both tools generate identical names for the types) otherwise the W2J
generated interface wont even compile.
...ant
Given the above what would people think about abandoning our Tuscany/SCA
Axis2 base W2J tool and just updating the SDO tool to support generating
the
SEI class? So for example the helloworld bpel sample where both of these
are
used at at the bottom of the pom.xml [1] would have the
tuscany-maven-wsdl2java plugin removed and an extra parameter added to the
tuscany-sdo-plugin like <generateSEI>true</generateSEI>?
The generateSEI parameter would only be available when the sdo plugin is
using a wsdl document and although the generated interface would have the
SCA @Service and @Remotable annotations as they're just strings it
wouldn't
drag in any sca dependencies to sdo, the sca jar would only be needed when
you actually compile the generated interface.
...ant
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-bpel/pom.xml
