Tuscany-WSDL2Java

[Pradeep Fernando <pr...@gmail.com>]

Hi devs,

I went through(debugged) the WSDL2Java codegen engine of Apache CXF. seems
like this tool suits our requirements.
It generates

 JAX-WS compliant artifacts.
supports new databindings as plugins.
It currently supporting JAXB & xmlbeans databindings.

let me explain the process of code generation in brief,

first it parse the command line options and store them in the tool context.
Then it builds up the javaModel of the given WSDL.
As I understood this model is independent of the CXF core.(In Axis2 , they
are using AxisService, which is a part of Axis2
 kernel to store the information).Then according to the user requested
frontend the code generation happens.(default being the JAX-WS frontend). In
front end there is set of generators that responsible for generating
atrtifacts. for an example SEIgenerator is
responsible for genrating SEI. I find this approach quite good over the
Axis2 Approach of one large client stub flled with everything.

then again for code generation CXF tool uses Apache velocity. The tool
injects the values stored in the JavaModel in to the velocity
engine and the velocity do the rest according to the given template. In
Axis2 they use intermediate XML & XSLT to achieve this.

As my understanding since we want modifications such as generating artifacts
from WSDLs that contains only portType(interface)
CXF tool provides much more flexibility over Axis2 one.To do this we can
take out some binding related generators from the frontend & some
modifications to the velocity templates,(there can be other changes too)

but there are some few areas we have to look at, the CXF WSDL2Java tool,

does not support WSDL2 (i saw it as a TODO)
we have to add databinding support for SDO,ADB(axiom),


Im yet to explore the object model that tuscany uses to represent the info
in WSDL & expecting few tips on this regard. But right now i feel that the
CXF model is  good enough.(not sure).

Any thoughts ,suggetions anything you might think that is useful is warmely
welcome.

-- 
Pradeep Fernando.

Re: Tuscany-WSDL2Java

[Raymond Feng <en...@gmail.com>]

Hi, Pradeep.

I hereby bring the conversation to the Tuscany mailing list. 

Please see my comments below.

Thanks,
Raymond


From: Pradeep Fernando 
Sent: Saturday, May 09, 2009 7:52 AM
To: Raymond Feng 
Subject: Re: Tuscany-WSDL2Java


hi raymond,
comments inline.


  I assume you only have to plug in the databinding parts into the CXF code. If so, we can reference the CXF code as external maven dependencies.

i thought its better to have tuscany specific codegen tools based on CXF one. i mean there can be tuscany specific requirements such as wsdl s having only  portType. may be we will be able to make a lightweight tool by removing some CXF specific requirements in the tool(still cant give you a concrete example.) 
anyway you knw the tuscany requirements better than i do. so lets do it in the way you suggested.

<rfeng>

1) We need to have the right balance here such as:
a. Keep the CXF dependencies to a minimal set
b. Avoid duplicating the CXF code 

2) The Tuscany wsdl2java requirements are two parts:
a. Generate java interfaces (not implementation classes) from the WSDL (it may only contain the portType, or portType + binding, or portType+binding+service/port. IIRC, the CXF tool supports all cases).
b. Generate parameter/return/fault types using pluggable databindings in addition to JAXB. At this point, SDO databinding is desired to have.

I think you should really focus on adding the databinding support as CXF probably has covered a. 
</rfeng>


   Are you familiar with maven? I was asking you to create a maven project which contains the JUNIT test case to show the programmatic way to generate java code out of a WSDL document.

i'm not a guru.But can do  work after bit of googling.
I created a maven module requested by you. I wrote it as a independent module.got the dependecy list by running the mvn dependency:tree  in the CXF module. then added some more databinding & frontend related dependencies. Think this is what you asked.

you may want this as a module in tuscany code so we can check in as the first step (by supplying a patch). if it is the case i can modify this. please suggest name for the module if it is the case since i found wsdltojava module in tuscany code base.

for the time being i have hosted the code in google-code. note that this is not the code to be check in.(no apache license headers.)

<rfeng>I STRONGLY recommend you work with Tuscany code base directly. Having a 3rd party repo only adds one more layer of complexity. If you want to keep local changes, you should try a tool like GIT.<rfeng>

svn co http://tuscany-wsdl2java-soc2009.googlecode.com/svn/trunk/mavenModule

plz give your suggestions & coments on the code,

<rfeng>The module looks like a good starting point. Maybe we should use a test-driven approach here. basically, add a few WSDLs with different styles and have the test case to run the wsdl2java tool.<rfeng> 

that sand box thing is great. I was looking for that sort of thing. So can  i check in code to that sand box area?

<rfeng>You cannot check in code until you gain the committer status from the project. Please start to contribute what you have done as patches. Typically, you check out the tuscany code from svn, making changes, and then run svn diff to create a patch. You should run svn add command to add new files under version control before creating the patch.</rfeng>


 thanks.

Re: Tuscany-WSDL2Java

[Pradeep Fernando <pr...@gmail.com>]

Hi Raymond,

comments inline.

put together a maven module with a test case that uses the CXF tool
> (programmatically) to generate the JAX-WS/JAXB interface from WSDLs.  This
> will help us understand the dependencies on CXF.
>

great, ill work on that.

start with the dynamic SDO databinding.
>

yes i should start with databindings.

Re: Tuscany-WSDL2Java

[Raymond Feng <en...@gmail.com>]

Hi, Pradeep.

Thanks for the update. The CXF wsdl2java seems to be a good base for our 
project.

As the first step, would you please try to put together a maven module with 
a test case that uses the CXF tool (programmatically) to generate the 
JAX-WS/JAXB interface from WSDLs.  This will help us understand the 
dependencies on CXF.

Meanwhile, I suggest that start with the dynamic SDO databinding. It would 
be fairly simple, because it always use commonj.sdo.DataObject to represent 
complex types. For example:

@WebService(name = "CreditCardPayment", targetNamespace = 
"http://www.example.org/CreditCardPayment/")

public interface CreditCardPayment {
    @WebMethod(action = 
"http://www.example.org/CreditCardPayment/authorize")
    @WebResult(name = "Status", targetNamespace = "")

    @RequestWrapper(localName = "authorize", targetNamespace = 
"http://www.example.org/CreditCardPayment/", className = 
"commonj.sdo.DataObject")
    @ResponseWrapper(localName = "authorizeResponse", targetNamespace = 
"http://www.example.org/CreditCardPayment/", className = 
"commonj.sdo.DataObject")

    public String authorize(
        @WebParam(name = "CreditCard", targetNamespace = "")
        DataObject creditCard,
        @WebParam(name = "Amount", targetNamespace = "")
        float amount);
}

Thanks,
Raymond

From: Pradeep Fernando
Sent: Monday, April 27, 2009 9:51 AM
To: tuscany-dev
Subject: Tuscany-WSDL2Java


Hi devs,

I went through(debugged) the WSDL2Java codegen engine of Apache CXF. seems 
like this tool suits our requirements.
It generates

 JAX-WS compliant artifacts.
supports new databindings as plugins.
It currently supporting JAXB & xmlbeans databindings.

let me explain the process of code generation in brief,

first it parse the command line options and store them in the tool context. 
Then it builds up the javaModel of the given WSDL.
As I understood this model is independent of the CXF core.(In Axis2 , they 
are using AxisService, which is a part of Axis2
 kernel to store the information).Then according to the user requested 
frontend the code generation happens.(default being the JAX-WS frontend). In 
front end there is set of generators that responsible for generating 
atrtifacts. for an example SEIgenerator is
responsible for genrating SEI. I find this approach quite good over the 
Axis2 Approach of one large client stub flled with everything.

then again for code generation CXF tool uses Apache velocity. The tool 
injects the values stored in the JavaModel in to the velocity
engine and the velocity do the rest according to the given template. In 
Axis2 they use intermediate XML & XSLT to achieve this.

As my understanding since we want modifications such as generating artifacts 
from WSDLs that contains only portType(interface)
CXF tool provides much more flexibility over Axis2 one.To do this we can 
take out some binding related generators from the frontend & some 
modifications to the velocity templates,(there can be other changes too)

but there are some few areas we have to look at, the CXF WSDL2Java tool,

does not support WSDL2 (i saw it as a TODO)
we have to add databinding support for SDO,ADB(axiom),


Im yet to explore the object model that tuscany uses to represent the info 
in WSDL & expecting few tips on this regard. But right now i feel that the 
CXF model is  good enough.(not sure).

Any thoughts ,suggetions anything you might think that is useful is warmely 
welcome.

-- 
Pradeep Fernando.