[Arch] Apache CXF and "Code First" Webservices

Dana Gardner has an interesting interview in his Briefings Direct podcast (transcript) talking about the Apache CXF project. Apache CXF is one of the leading "Open Source Service Framework", supporting a series of service protocols like SOAP, XML/HTTP, RESTful HTTP, or CORBA. Additionally CXF plays in the concert with Apache Camel, ServiceMix and ActiveMQ.

I believe, that CXF is a great project and as I said a leading webservice framework. I also perfectly agree on their statement, that Open Source frameworks in the middleware/SOA field will more or less take over the market (I would probably not buy shares from Oracle/Bea *g*). But I feel a quite a bit uncomfortable about two fundamental concepts that were stressed several times in the interview:

1. Code First approach and slightly connected:
   
2. Abstracting too much from Webservice protocols like WSDL: "So, a lot of these more junior level developers can pick up and start working with Web services very quickly and very easily, without having to learn a lot of these more technical details.", Kulp
   

I personally believe that this is not the right way to go. I think we have to take the criticism of the REST folks (among others) seriously here, and the question we have to ask ourselves is: why in the first place do we want to use SOAP webservicess?

Because it is an easy remoting approach that a junior level engineer can click together with a wizard due to excellent frameworks and UI components? Sure not! First: a remote methode call is something fundamental different compared to a local method call; it probably should be treated as such. But even more important: Services on the basis of SOAP have some underlying assumptions:

• platform independence is needed
• Services on a rather coarse granularity are exposed
• interoperability over system/company borders are imperative, i.e., the service interface is in the center and should be considered properly and not change any minute
• remote service calls are rather the exception (coarse granularity, aggregated functionality),
• strong formalisation is needed (XML schema, service description, security...)
  
• i.e. performance losses due to XML (un-) marshalling are acceptable considering the advantages gained by this "neutral" approach
  

and probably some more. The point however is, that SOAP services are not just an ordinary remoting approach they are to expose Services under specific conditions. (For other remoting problems probably other technologies like RMI or REST are better suited.) In the cases where SOAP is a good architectural choice I would suggest that the platform neutral service description i.e. WSDL should stand in the center of attention. The idea is, that different parties can express a neutral and platform independent service description plus data-description in W3C schema as a foundation for cooperation.

The next step, not the first step is to implement the service. So my feeling about code-first approaches are that they can lead developers and architects into a dangerously wrong direction (just two annotations and the webservice is done, so we are made to believe). What we would really need are not code-first webservice frameworks, but easy to use WSDL editors/modeling tools.

Additionally a Webservice infrastructure is by definition a complex beast. Trying to abstract all underlying protocols from the developers easily gives them a wrong idea about the actual complexity of their undertaking. When (e.g. interoperability, security) problems occur, they probably have no idea about the reason and the means to fix them. So give us good Service modeling tools, but no code-first approaches. This leads us into the wrong direction.

Just my two cents.