Hi Jason,
if you are planning to create a webservice for several other projects I
would recommend doing contract first. If you share your actual java
classes between several projects you will get into trouble sooner or
later. We have tried this aproach in a SOA project and had problems with
this aproach.
You should always keep in mind that the soap xml that the service
framework creates from the same set of java classes may differ between
frameworks and beween different versions of the same framework. We had
the problem when we changed from xfire to cxf. The same classes produced
slighty different xml on the wire. So we could neither introduce cxf on
the clients nor on the server spearately. We would have to exchange the
version on all servers and clients at the same time. As you can imagine
this is not prossible in any larger setup.
To answer your question. I think you can live without annotations when
you use the simple front end together with the aegis binding. But the
problems I described above will sooner or later hit you.
There is only one use case where I favour true code first: If you are
simply doing remoting betwen a client and a server that belong to the
same release unit. In this case you can make sure that when you roll out
a release you will do so on client and server at the same time.
I have written an article on how to do contract first and still keep
much of the advantages of code first:
http://cwiki.apache.org/CXF20DOC/defining-contract-first-webservices-with-wsdl-generation-from-java.html
Greetings
Christian
[EMAIL PROTECTED] schrieb:
Hi, I am using java 1.6 in a mule 2.x project, and need soap support.
I'd like to use cxf, but it seems that its an 'annotations only' technology -
(is this true?)
The classes I am using are shared amongst other projects and I do not want to
annotate them unnecessarily, I'd MUCH prefer to simply configure with an
external xml config file if its an option. I'd also like not to have to create
annotated facades just to support cxf.
is this possible?
Thanks
Jason
--
Christian Schneider
---
http://www.liquid-reality.de
