cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <>
Subject RE: Tooling, Code First Approach & Service Model
Date Thu, 31 Aug 2006 10:27:52 GMT
Hi Dan, 

Thanks for pointing out these XFire APIs, they are exactly what I am looking for. I just done
a commit for wsdltojava, which is using PluginProfile to support a plugable code gen mechanism,
which allows the generation of client, server and service stub codes for different profiles,
such as JAXWS and SCA.  I will work with Jim Ma later on to add the support for multiple databindings
by porting to CXF. 

Regarding the service model, I have not got time to look into further: Whether or not we should
reuse service Model for tools, and how to do it properly. But to be honest, I do worry about
the size of tools if I use cxf tools from a third party product. Presume I am a Tuscany user,
I am very likely to be pissed off if I have to download a whole bunch of cxf runtime/core
jars of a total size of tens megabit while all I want is simply using cxf wsdltojava to help
me to generation SCA style client and server stub code. Should not we have a lightweight wsdltojava
tool that can be distributed very easily? One example is the tcpmon tool from axis. I do not
use axis, but I do use the tcpmon from axis.jar quite a lot, I found its very handy to be
able to use tcpmon from one single and relative small jar.


> -----Original Message-----
> From: Dan Diephouse []
> Sent: Wednesday, August 30, 2006 11:52 PM
> To:
> Subject: Re: Tooling, Code First Approach & Service Model
> Liu, Jervis wrote:
> > Hi Dan,
> >
> > I definitely agree we need wsdltojava be able to work with 
> multiple data bindings. To my knowledge, there is no such a 
> tool yet in the open source space can generate JAX-WS 
> compliant code for multiple data bindings, including data 
> binding type classes, service impl class, server code, client 
> code etc, which essentially everything a user need as a 
> default starting point when they work from a wsdl-first 
> approach. For example, I have been involved in Tuscany 
> development, I found it is a real pain to write service impl 
> class, client/server manually and it is even more painful to 
> make sure the codes actually conform to the wsdl. I believe 
> Tuscany developers will be very excited if they are provided 
> with a tool to generate client and server side codes from 
> wsdl that can be used to start server and client instantly 
> after generation. Of course the requirement would be this 
> tool needs support all data bindings supported in Tuscany, to 
> name a few, SDO, JAXB, xmlbean etc. 
> >
> >   
> XFire can do both JAXB and XMLBeans currently for JAX-WS.
> > I have had a quick offline chat with Jim, we figured out 
> that the current tool's implementation shall allow different 
> data bindings being used easily (or as you named, pluggable 
> data bindings). Essentially, the wsdltojava tool is in charge 
> of the generation of client side code, server impl, service 
> impl etc by using Velocity template with the info from from 
> WSDL model. The generation of data binding type classes is 
> delegated to the specific data binding gen tools, such as 
> JAXB code gen tool. With some minor refactors, wsdltojava 
> should be able to delegate the data binding type classes 
> generation to any third party tools, wsdltojava only needs to 
> make sure it can access (and sometimes control, for example, 
> to resolve name conflictions according to JAX-WS)  data 
> binding gen info, such as packaging name etc.
> >   
> > To make this happen, I think we need to take following action items:
> >
> > 1. Refactor the data binding type classes generation part, 
> so that this part can be delegated to different data binding 
> gen tools based on configuration of input parameters. 
> Standard APIs to plug in different data bindings need to be 
> published, so that developers can contribute more data 
> binding supports.
> >
> >   
> I would recommend checking out the existing XFire APIs which do this:
> > 2. For the service classes, server/client code gen part, we 
> need to refactor tool to use serviceModel that is used by 
> runtime. This is not an absolute requirement, but it does 
> give us a lot of benefits in terms of code reuse. However, in 
> the interest of reuse cxf tool by other projects (such as 
> Tuscany, Yoko), we need to design the tool module's 
> dependencies carefully. We want to publish the cxf tool 
> distribution in a minimal package. Put this requirement in 
> mind, I think it makes sense to move ServiceModel to be a top 
> level module, then tools can depend on serviceModel. The last 
> thing we want to see is the tool depends on the whole cxf runtime.
> >   
> That doesn't make any sense at all. As I outlined in my 
> previous email,
> you're still going to need to depend on both the core and 
> whatever your
> frontend module. This is because the frontend (i.e. JAXWS) module is
> responsible for building the service model, and the frontend will be
> dependent on the core. You'll also need a module for each binding. I
> don't see why this is that big of a deal. Maven will manage 
> all this for
> you, and if you're using Tuscany, you certainly aren't 
> worried about jar
> size.
> > Another to do list related to this is that we need to 
> refactor serviceModel. The current serviceModel does not have 
> all info required by tool generation.
> >   
> What is missing?
> > 3. Refactor the server/client generation part as well, we 
> need to make this part be able to be customized very easily. 
> This allows other projects to generate none-JAXWS style 
> server and client stub code. One use case would be the 
> generation of sca style server bootstrapping code for Tuscany.
> >
> >   
> I'd be a fan of moving to a profile type generation strategy. In XFire
> we have different profiles which provide plugins. For instance:

It'd be really easy to add another plugin which generated SCA bits.

I can help get a framework in place to start building some new tooling
around if you want. We can just hack away in parallel with the current
tooling until its ready.
- Dan

Dan Diephouse
Envoi Solutions

View raw message