Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jim.ma@iona.com designates
 63.65.132.112 as permitted sender)
From: "Jim Ma" <jim.ma@iona.com>
To: <cxf-dev@incubator.apache.org>
Subject: RE :Tooling, Code First Approach & Service Model
Date: Mon, 28 Aug 2006 16:14:23 +0800
Message-ID: <NJEGKBFJCOPBPCAHACGLMEPCCJAA.jim.ma@iona.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

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