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 Mon, 28 Aug 2006 16:40:40 GMT
James Mao wrote:
> Jim Ma 写道:
>   
>> Sorry , I missed something .
>>
>>
>> Hi Dan D,
>>
>> Comments in line.
>>   
>>     
>>> 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 .
>>
>>
>>   
>>     
> I agreed, the support to WSDL2.0 is not need to be considered at moment.
> I don't know if planed to include the wsdl2.0 support in the first ms.
> if not , i would like to keep the current design of the tool.
>   
I'm not saying this needs to happen before M1, but it needs to happen
before our .0 release. WSDL 2.0 is a requirement IMO.
>>> 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.
>>
>>
>>   
>>     
> I didn't see the requirement to support multiple databinding yet. What's
> wrong with jaxb implementation.
>   
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.
>>> 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 .
>>   
>>     
> I've already created a jira task days ago, the re-use of the code in
> tools and rt will not be a trivial task.
>   
I don't think it is that hard. We have the WSDL generation from the
service model working in essence. We can maybe even reuse the generation
code from XFire which uses the service model. I think we should should
start tooling which uses the service model in parallel. We can use it
once it is ready - whether thats at M1 or M2, I don't really care.

- Dan

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


Mime
View raw message