Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[EMAIL PROTECTED]>
Sent: Thursday, May 22, 2008 9:36 AM
To: "tuscany-dev" <[email protected]>
Subject: Re: Tuscany Java2WSDL and WSDL2Java tools
On Thu, May 22, 2008 at 5:04 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
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.
I've a lot of sympathy with that approach...though it is a bit more work
:)
Great.
WSDL2SEI is what we have right now with tools/wsdl2java as it cuts out
generation of eveything other than the SEI class, but to do that it uses
and
copies code from the Axis2 WSDL2Java tool, is the suggestion to stop using
any Axis2 code and write our own SEI generator?
How complex is the logic to generate a java interface out of a WSDL
portType? What are the main Axis2 code dependencies (is the code fairly
isolated)?
The following is list of items I see:
portType QName --> Java interface name
operation name --> method name
part element/type --> argument/return name and type (following the mapping
rules by the pluggable databinding for XSD type --> Java type,we can use
JAXB as the default)
fault --> exception
The SEI2WSDL tool would be based on the new code we have for runtime WSDL
generation right? Not completely convinced about "SEI" in the name, people
know what Java2WSDL does so does keeping on calling our tool Java2WSDL
really hurt?
I just use "SEI" as an example to differentiate the traditional J2W. I can
live with J2W. If possible, we should leverage the new code for runtime WSDL
generation.
Anyway, so would we be committing to doing this in time for the next
release? If so I can stop looking at upgrading the exsiting tools to work
with Axis2 1.4. Or is this just "something to look at in the furture" and
I
still need to get the existing tools running with Axis2 1.4 in time for
our
next SCA release?
Effort wise, which approach requires more? We need to make a good balance
here. If the migration to 1.4 is an one-day work, then I think it's worth to
migrate it 1st to have a working base.
...ant
