views:

71

answers:

3

Using CXF to create contract-last web services seems like an efficient and effective way to rapidly create either SOAP or REST based web services. However, I'm unclear/unsure of the following and I'd appreciate insight/feedback:

  1. Are there any significant pitfalls of contract-last that I should be aware of?
  2. Are there any significant issues/pitfalls of CXF I should be wary of?
  3. Between REST and SOAP which makes the most sense when using CXF?
A: 
  1. The problem with contract last is that there is a tight coupling between your code and the WSDLs you produce. It means that you are limited by the impedance mismatch between Java and what an XSD supports. The major issue we've faced is around versioning. If you want to support two parallel versions, how do you do that with contract-last? We found a cunning way to do it with XStream and separate wars but the solution is too large for this margin.
  2. CXF works pretty well. We haven't hit any major problems but it's a big project and the variations of what you can do with it are also pretty big.
  3. That depends on the consumers of your API. I'd advocate REST if at all possible because it's simpler, doesn't rely on incompatible SOAP libraries and scales better but some B2B organisations I've worked with prefer SOAP. The argument can be made that there is more tooling for creating SOAP clients automatically vs. REST. That said, most large organisations (Google, Amazon etc.) prefer REST for a reason.
jamie mccrindle
A: 

Contract last web service development is great for prototyping web services. Sometimes WSDL can be a pain to deal with. Where I work we do everything contract first, since most of our web services have to be integrated with potentially many others and so the WSDL is usually created by the architects.

I would also go REST if possible and it won't be hard to generate RESTful services\clients with CXF.

Casey
A: 
Calm Storm