RE :Tooling, Code First Approach & Service Model

[Jim Ma <ji...@iona.com>]

Hi Dan D,

Comments in line.

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Saturday, August 26, 2006 12:42 AM
> To: cxf-dev@incubator.apache.org
> Subject: Tooling, Code First Approach & Service Model
>
>
> There have been some rumblings of discussions about our tooling going on
> lately. It started from this question which was set forth:
>
> /When we build a JAX-WS service, should we build a WSDL from the
> annotations, and then build a service model from the WSDL? Or should we
> build a service model, and build a WSDL from the service./
>
> This directly affects our tooling as we should use the same model in
> both. This gives us the advantage that we only verify that the JAX-WS
> model in one location, and only introspect annotations in one location.
>

Wsdl2java and java2wsdl tools in the follow way to generate code or wsdl :

(1) sei implementor /interface class -> wsdl model-> wsdl

(2) wsdl file -> wsdl model -> class

Tool only concerns this model can represent all the information that the
wsdl and class provided and whether this model can be serialized and
deserialized.   If service model could provide the reading ,creating  and
manipulating wsdl (What ever 1.0 or 2.0 wsdl)  , I think we can replace the
wsdl model with service model. I dislike the path : class -> service
model -> wsdl model -> wsdl file. From tools view , it need only one model
that can manipulate wsdl .   The ideal and simple way is class ->service
model->wsdl .

> I am of the mindset that we should build directly to the service model,
> and then use that to generate things - like tooling or wsdl. The primary
> reason for this is that we need something that is WSDL version agnostic.
> The whole point of the service model is to provide a structure that
> encapsulates everything we need to know about WSDL 1.1 docs, WSDL 2.0
> docs, and services built from classes.
>

If woden project will provide the same api to manipulate WSDL1.1 and
WSDL2.0, I think the woden object model is the better choice .


> There has been some argument that we should build a WSDL from a JAX-WS
> class, and then build a Service from that. I think the primary
> reasons are:
> 1. so the tooling doesn't have to change
> 2. so the JAXWS module can reuse the existing WSDL model verifier.
> 3. so we can depend on the tooling in the jaxws module and not the other
> way around
>

> Regarding #1 - I'm not a fan of the way the tooling is written now
> anyway. The main problems are that it doesn't handle multiple
> databindings and it is tied to JAX-WS.
>

I think handling multiple databindings does not depends on whether we use
service model , it depends on whether we use multiple xml mapping tool to
marshal or unmarshal.  Now tools use JAXB_RI to handler jaxb binding , we
also can add castor or xmlbeans databinding to handle more databinding.


> Also, I think 3 is a weak argument, because we can have a tooling module
> which depends on the core, and then the JAX-WS module can provide its
> plugins for the tooling. XFire provides a good example of how to do this
> in its JAX-WS module. It has the concept of Profiles and
> GenerationPlugins. The JAX-WS module just has its own profile with its
> own set of generation plugins. After src/main is built, we use the
> generator to generate stuff for src/test.
>

> So to recap I think we need to:
> 1. Convert the tooling to reuse the service model and make JAX-WS
> a plugin.

> 2. Build up the Service model from JAX-WS classes directly
>

If service model can be reused in runtime and tools , we can place it in
common module .In there , it make sense .

> Thoughts?
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
>


Regards

Jim

Re: RE :Tooling, Code First Approach & Service Model

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

Jim Ma wrote:
> Hi Dan D,
>
> Comments in line.
>
>   
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>> Sent: Saturday, August 26, 2006 12:42 AM
>> To: cxf-dev@incubator.apache.org
>> Subject: Tooling, Code First Approach & Service Model
>>
>>
>> There have been some rumblings of discussions about our tooling going on
>> lately. It started from this question which was set forth:
>>
>> /When we build a JAX-WS service, should we build a WSDL from the
>> annotations, and then build a service model from the WSDL? Or should we
>> build a service model, and build a WSDL from the service./
>>
>> This directly affects our tooling as we should use the same model in
>> both. This gives us the advantage that we only verify that the JAX-WS
>> model in one location, and only introspect annotations in one location.
>>
>>     
>
> Wsdl2java and java2wsdl tools in the follow way to generate code or wsdl :
>
> (1) sei implementor /interface class -> wsdl model-> wsdl
>
> (2) wsdl file -> wsdl model -> class
>
> Tool only concerns this model can represent all the information that the
> wsdl and class provided and whether this model can be serialized and
> deserialized.   If service model could provide the reading ,creating  and
> manipulating wsdl (What ever 1.0 or 2.0 wsdl)  , I think we can replace the
> wsdl model with service model. I dislike the path : class -> service
> model -> wsdl model -> wsdl file. From tools view , it need only one model
> that can manipulate wsdl .   The ideal and simple way is class ->service
> model->wsdl .
>
>   
Yes, the core will have tools to build wsdl 1.1/2.0 from the service 
model and vis a versa. I agree, the service model should be that one 
model for our tools :-)
>> I am of the mindset that we should build directly to the service model,
>> and then use that to generate things - like tooling or wsdl. The primary
>> reason for this is that we need something that is WSDL version agnostic.
>> The whole point of the service model is to provide a structure that
>> encapsulates everything we need to know about WSDL 1.1 docs, WSDL 2.0
>> docs, and services built from classes.
>>
>>     
>
> If woden project will provide the same api to manipulate WSDL1.1 and
> WSDL2.0, I think the woden object model is the better choice .
>
>   
I don't think thats a goal of Woden, so I think we should continue to 
use our own service model.
>   
>> There has been some argument that we should build a WSDL from a JAX-WS
>> class, and then build a Service from that. I think the primary
>> reasons are:
>> 1. so the tooling doesn't have to change
>> 2. so the JAXWS module can reuse the existing WSDL model verifier.
>> 3. so we can depend on the tooling in the jaxws module and not the other
>> way around
>>
>>     
>
>   
>> Regarding #1 - I'm not a fan of the way the tooling is written now
>> anyway. The main problems are that it doesn't handle multiple
>> databindings and it is tied to JAX-WS.
>>
>>     
>
> I think handling multiple databindings does not depends on whether we use
> service model , it depends on whether we use multiple xml mapping tool to
> marshal or unmarshal.  Now tools use JAXB_RI to handler jaxb binding , we
> also can add castor or xmlbeans databinding to handle more databinding.
>
>   
Sure, but I was making the point that we're going to have to change a 
bit of stuff in the tooling anyway.
>   
>> Also, I think 3 is a weak argument, because we can have a tooling module
>> which depends on the core, and then the JAX-WS module can provide its
>> plugins for the tooling. XFire provides a good example of how to do this
>> in its JAX-WS module. It has the concept of Profiles and
>> GenerationPlugins. The JAX-WS module just has its own profile with its
>> own set of generation plugins. After src/main is built, we use the
>> generator to generate stuff for src/test.
>>
>>     
>
>   
>> So to recap I think we need to:
>> 1. Convert the tooling to reuse the service model and make JAX-WS
>> a plugin.
>>     
>
>   
>> 2. Build up the Service model from JAX-WS classes directly
>>
>>     
>
> If service model can be reused in runtime and tools , we can place it in
> common module .In there , it make sense .
Putting it in common isn't going to make any difference, because we 
still need to use the other classes which use the service model. For 
instance, the JaxWsServiceFactoryBean which builds the Service from 
classes. So the Jaxws tooling would still need to be in the jaxws module.

Cheers,
- Dan

-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog