WSDL - first, CXF JAXRS model - first !

So you're a SOAP developer who prefers starting the development of a new service from creating a WSDL document first. It is a WSDL-first approach that works for you, not a Java-first one. You are also interested in giving it a try and seeing what advantages following the RESTful style can give the users of your application, but would also like to keep a single code base.

If so then please read on this long post...

CXF makes it easy for developers to expose a single Java class as a SOAP and REST service, by sharing a service bean between multiple jaxws and jaxrs endpoints. The problem is, as far as you're concerned, that it requires one to follow a Java-first approach.

One option is for CXF to offer users an option to do a WADL-first development. CXF JAXRS is not quite there just yet but nothing prevents it now from providing a code gen command line utility and a maven plugin. This is an ongoing effort though and some UI tooling support would also be required. So, eventually, one would be able to use WSDL for developing SOAP services and WADL for developing RESTful services. This may or may not become a viable approach for users preferring a document-first style. Working on different documents (WADL and WSDL) might not make much sense, and creating a shared service class will not be possible.

The other advice which you, the SOAP developer, are most likely to hear today is as follows : you'd be better off migrating to REST/JAXRS altogether rather than sticking with SOAP. So the issue of figuring out how to do SOAP and REST the document-first style at the same time would be resolved. Even though there is some evidence that a number of individual and corporate developers may have done just that, I think this advice may not be the most effective option, as far as convincing those who have invested in SOAP and actually liking it no matter what that there could be a better option awaiting them. It is enhancing the runtime for it to be able to do the advanced stuff SOAP developers can do today with respect to the message-level security, multiparts and the document-first development and providing the easy path for SOAP developers to experiment with REST in the live production is what can convince the most conservative developers over time that the other approach (REST) may be adopted, partially at least.

Here is another option CXF could try: implement WSDL2, thus letting users define both SOAP and REST bindings in a single document which can be quite effective from the development point of view. Now, WSDL2 is said to be a better language than WSDL 1.1, but the question is : would an investment into implementing it be cost-effective ? Will it bring new users to CXF? And is it worth investing into it just for the sake of letting users do both SOAP and REST development the document-first way ? It does not seem it can do better that WADL in describing a RESTful application, given that it is more likely WADL can be enhanced even further while WSDL2 will not(not touching here on the interface vs resource centric approaches issue). Finally, as Dan Kulp says, a user demand is just not there, at least at the CXF users list. It can be quite a difficult thing to do, deciding on whether a given feature should be implemented depending on the existing or anticipated demand from users, sometimes expecting the users/customers always indicate to you what should be done next can stifle the innovation, but in case of WSDL2 it seems like the right thing to do.

This post has been long enough but I've tried to do some analysis there...So here is what can be done right now the real cost effective way (thanks to one of CXF users trying this option first) : generate your SOAP and JAXB classes from WSDL and then
'attach' some RESTful behavior to generated interfaces by relying on the annotation-free feature and finally have both jaxws and jaxrs endpoint sharing an implementation bean, with the jaxrs endpoint including the model describing the interface only. Example, imagine that no JAXRS annotations exist in this (generated) source interface. Next, just describe this interface similarly to the way it is done here. Finally add a jaxrs endpoint (see the one with a 'bookservice3' id) referring to the model describing this interface and the bean which implements it and you're done.

It would be mostly about making your code a bit more HTTP aware as opposed to magically turning it into a RESTful application, but it is an easy start and you may want to give it a try. And if it works for you then you might want to ask your friends from the UI team to have a tool generating CXF JAXRS models for you :-)