cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Tooling, Code First Approach & Service Model
Date Wed, 30 Aug 2006 02:33:44 GMT
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. 

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.

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.

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.

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.


Any thoughts?

Cheers,
Jervis 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Tuesday, August 29, 2006 12:10 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Tooling, Code First Approach & Service Model
> 
> 
> James Mao wrote:
> 
> >Dan Diephouse 写道:
> >  
> >
> >>James Mao wrote:
> >>
> >>  
> >>    
> >>
> >>>Hi Dan,
> >>> 
> >>>
> >>>    
> >>>      
> >>>
> >>>>Its a requirement. XFire supports it and we need a 
> migration path for
> >>>>users using XMLBeans. XMLBeans provides access to the DOM 
> underneath,
> >>>>which a lot of people like. Or take JiBX. It is about 2x 
> faster than
> >>>>JAXB. There are a lot of pros and cons to the different 
> databinding
> >>>>toolkits. Which one you use really depends on your situation.
> >>>> 
> >>>>   
> >>>>
> >>>>      
> >>>>        
> >>>>
> >>>I mean the tools works fine with jaxb, and currently i 
> don't think that
> >>>we need to support all the databindings.
> >>>There are tons of databinding implementation out there[1], 
> and there
> >>>will have more new databindings emerging .
> >>>Are we going to support all of those databindings? and Why 
> the user need
> >>>to care which databinding they are using?
> >>>
> >>>Maybe it's true for rt, but for the tools i think we just keep the
> >>>current design.
> >>>
> >>>I agreed that there are some duplicate code in the rt and 
> tools, and we
> >>>can reuse some of the code and put it into common module.
> >>>So, i mean what we need is just refactoring to use the 
> common code, not
> >>>re-design to support the multiple databindings.
> >>>
> >>>Agree?
> >>>
> >>>
> >>> 
> >>>
> >>>    
> >>>      
> >>>
> >>No, I strongly disagree. Have you ever used the other 
> databindings? Each
> >>one hsa its own ups and downs. Did you see how in the bindmark
> >>benchmarks JiBX was twice as fast? And what happens if you need to
> >>access the XML infoset during parsing? Will JAXB cut it? No. But
> >>XMLBeans will.
> >>
> >>Yes, there are tons of databinding implementations out 
> there, and this
> >>is exactly the reason we should have hooks to support them.
> >>
> >>- Dan
> >>  
> >>    
> >>
> >Hi Dan,
> >
> >I agreed that for the RT, the performance is important, but it's not
> >true for the tools,
> >Tools work fine with JAXB, i didn't see any performance 
> issues with JAXB
> >in tools, and users also didn't report any performance issues so far.
> >Have u met the performance issue with Celtixfire tools?
> >
> >  
> >
> 
> The point is that a user should be able to generate a service 
> from WSDL
> and use another databinding in the service class. So instead of jaxb
> generated beans, the generated service will use XMLBeans. Or whatever
> toolkit they want. They can't reuse the generated JAXB benas. Each
> toolkit has to generate its own beans. To do this, wsdl2java needs to
> support the plugable databindings, and the logical way to do 
> that is to
> reuse the Databinding support classes we've written. So yes, if a user
> generates a service using wsdl2java using the JAXB toolkit, 
> it won't be
> as fast as if they generated it using the JiBX toolkit. And if we
> generate a service using JAXB, that means they won't have 
> access to the
> xml infoset, like they would if it was generated with XMLBeans.
> 
> - Dan
> 
> -- 
> Dan Diephouse
> (616) 971-2053
> Envoi Solutions LLC
> http://netzooid.com
> 
> 

Mime
View raw message