cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Ma" <>
Subject RE: Tooling, Code First Approach & Service Model
Date Mon, 28 Aug 2006 08:21:25 GMT
Sorry , I missed something .

Hi Dan D,

Comments in line.

> -----Original Message-----
> From: Dan Diephouse []
> Sent: Saturday, August 26, 2006 12:42 AM
> To:
> 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



View raw message