Contract first is not the right approach. As the author notes a Java developers core competency and expertise is with, well, Java. Not with XML or WSDL or XSD, etc.
A simple set of Java interfaces, "code first" can be the "contract".
The reasons the author notes as drawbacks to "code first" are also easily refuted.
"Less control" I simply disagree with. The interfaces, once agreed upon, should not change and need not be "generated", the resulting WSDL and or schema can be generated but the interface does not have to be. If the interface does need to change then any "contract" would also need to change under the very same circumstances.
Coupling to "frameworks" can be an issue, agreed, but it is easily avoided. You can create a very simple set of web service interfaces to be used as a "core" with any web service project in your organization which then is easily implemented in a "plugin" style architechture. This way each actual web service project is only tied to the "core" and is NOT coupled to a particular underlying "web service" framework such as Axis or Xfire. Using such simple OO programming techniques (which we all should be using anyway, decoupling things where possible) the "issue" of "maintain a single interface across versions" evaporates, it is a single version. (Using this approach you can literally switch from Axis to JAX-WS or Xfire to comeCommercialSOAPImpl, etc, without the interface OR the "code first" code that makes up your service being affected AT ALL.)
Contract first is not smart, unless your expertise is Schema and WSDL. On the contrary, if your expertise is a programming language, Java or anything else, then you should utilize that expertise and this article has not presented any compelling reason not to. |
java.net RSS Feeds
