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.
