cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Tooling, Code First Approach & Service Model
Date Wed, 30 Aug 2006 15:51:50 GMT
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:

http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/SchemaSupport.java?r=1756
http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/jaxb/JAXBSchemaSupport.java?r=1836
http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/xmlbeans/XmlBeansSchemaSupport.java?r=1756

> 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:


http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/PluginProfile.java?r=988
http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/jsr181/Jsr181Profile.java?r=1756

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
http://envoisolutions.com
http://netzooid.com/blog



Mime
View raw message