Re: Tooling, Code First Approach & Service Model

[Dan Diephouse <da...@envoisolutions.com>]

Liu, Jervis wrote:

>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 SchemaSupport.java to CXF. 
>
>  
>
Great. Let me know if you have any questions.

>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.
>
Presume I am a tuscany user. I've already had to download a boat load of
jars. Whats a few more going to matter?

> Should not we have a lightweight wsdltojava tool that can be distributed very easily? 
>
I don't believe the benefits are there.

>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.
>
>  
>
Well I personally always use the axis the jar sitting on my computer.
But this is a completely different thing in my opinion. If TCPMon
integrated with the Axis service model, provided validation, and tooling
to invoke services (kind of like soapscope/soapui), would you complain
if the whole axis jar was there? I don't think so.

>Cheers,
>Jervis 
>
>  
>
>>-----Original Message-----
>>From: Dan Diephouse [mailto:dan@envoisolutions.com]
>>Sent: Wednesday, August 30, 2006 11:52 PM
>>To: cxf-dev@incubator.apache.org
>>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:
>>
>>http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-g
>>    
>>
>enerator/src/main/org/codehaus/xfire/gen/SchemaSupp> ort.java?r=1756
>  
>
>>http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-g
>>    
>>
>enerator/src/main/org/codehaus/xfire/gen/jaxb/JAXBS> chemaSupport.java?r=1836
>  
>
>>http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-g
>>    
>>
>enerator/src/main/org/codehaus/xfire/gen/xmlbeans/X> mlBeansSchemaSupport.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-g
>>    
>>
>enerator/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
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com