James Mao wrote:
About ServiceModel, I think it should also be an independent module,
and for tools or rt, i think it'll be great if we have an plug-able
api, so the tools and rt are not directly reference ServiceModel,
and if you want to replace the ServiceModel with other Model(Wooden)
will be possible.
For the builder which build servicemodel should stay in
servicemodel, just like Wsdl4j, they provider a model and also
provide a builder.
That misses the whole point of the service model. The point of the
service model is that wsdl 1.1, wsdl 2, and classes all get converted
into the service model and then artifacts are generated from that.
- Dan
No, You missed my point, my point is that the ServiceModel
should/could also be an independent module, we should have a decoupled
design in our mind,
Currently it's tightly coupled with rt, which i don't think it's a
good design. To support wsdl1.1, wsdl2, classes all get converted into
the ServiceModel , doesn't mean it have to stay in RT, if there are
some dependence, we could/should also move that part out of rt.
Ideally you have builder api like that:
ServiceModel build(URL url) // Use default profile JAX-WS
ServiceModel build(Class cls)
ServiceModel build(Definition def) // wsdl 1.1
ServiceModel build(Definition??? def) // wsdl 1.2
ServiceModel build(URL url, Profile profile)
...
The whole module could be shared by both the Tools and RT
So overall, my point is we could split the ServiceModel from RT.
Then, we have ServiceModel and Tools above the TestUtils/API/RT/..., i
think all the problems solved.
While you can split out the service model from the run time, you'll
still need the factories which are part of the core and the jaxws
module. For instance:
org.apache.cxf.wsdl11.WSDLServiceBuilder - for building a basic model
from wsdl
org.apache.cxf.jaxws.JaxWsServiceFactoryBean - for building a model from
a class
org.apache.cxf.soap.SoapBindingFactory - for building a soap binding
model from a wsdl
I hope this makes clear that splitting out the service model from the
runtime makes no sense as you still need all these auxillary classes.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
