Skip to main content

Java-first or WSDL-first?

6 replies [Last post]
mshaffer55
Offline
Joined: 2007-02-07

In my organization we are debating the relative merits of Java-first vs. WSDL-first web service development. So far we have experimented only with the latter. The major pain points for us seem to be:

1) The generated JAXB classes are really not very useful as native application classes. Unless they are modified post-generation (which we would not do), they don't include such basic behavior as equals(...), hashCode(), clone(), or toString(), for example. You can subclass them to add behavior but then you quickly encounter multiple inheritance problems in any object model that isn't a toy.

2) Because of #1, we must provide a layer of code that converts between the generated classes and the native classes that the application actually wants to use. This is an additional hit in terms of development effort and run-time performance that we don't care for.

What are the pain points people experiencing using Java-first development in non-trivial applications? One thing I can see right off the bat is that it is going to be difficult to support more than one schema for a given set of native JAXB-enabled classes. That appears to require the addition of otherwise superfluous interfaces, and adapter classes containing the kind of conversion code we already know we don't want. Anything major besides that?

Thanks in advance for any/all responses...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
CraigJ
Offline
Joined: 2011-08-03

We are having the same debate.

The main argument for the java-first approach is that the code is more maintainable for us knucklehead java developers. There are no actual WSDLs or XSDs to maintain, just java interfaces with JAX-WS and JAXB annotations.

The authorities on the matter (Apache CXF and Spring) seem to favor the WSDL first approach because it emphasizes the importance of the "contract." Here's some links to the "authorites'" opinions:

I think the WSDL-first approach _might_ make versioning less of a headache, but I'm not sure about that yet.

I think, for now, we are going to go with the java-first approach because of the code is easier to maintain and probably quicker to develop. Also, to the original poster's point, will have to have adapter classes that turn our business objects into service-friendly objects.

Oh and one more point: if you are going with the WSDL first approach simply because you have complex schema definition needs, Aegis is an annotation-enabled data binding similar to JAXB that has annotations for more complex xml schema rules. It's packaged as part of CXF.

mcekovic
Offline
Joined: 2004-03-04

My opinion is that you should use WSDL-first thinking (design) and Java-first coding (implementation), except if you cannot express WSDL constructs with Java/JAX-WS. That way you get the best from both: ease of development of Java-first approach and interoperability of WSDL-first approach.

mcekovic
Offline
Joined: 2004-03-04

You will need wrapper classes with either approach in more complex applications. This is normal as your wrapper classes are domain classes which have to be isolated from any dependency from either persistence, distribution or service layers. Having JAX-B generate helper classes is just a convenience for us (save us from dealing with SOAP and XML), they should not be your domain classes. The 'pain' you have is not caused by JAX-WS, JAX-B nor by your approach, but by the nature of your application (i.e. distributed, service oriented...).

zellster
Offline
Joined: 2005-05-20
jzacker
Offline
Joined: 2004-12-06

We had the same choice to make. We chose WSDL first because we needed to define some types with minInclusive and maxInclusive limits on the values, which JAXB does not support. We ended up writing wrapper classes to the generated object to do things like equal() hashCode() and other functions.

mshaffer55
Offline
Joined: 2007-02-07

We thought of wrappers as well, but it breaks down in the face of any containment relationships amongst the schema types. You could have a parallel containment model amongst the wrappers, but that would still require a conversion layer that navigates the wrapper object graph and pulls out the wrapped JAXB objects and builds the corresponding JAXB object graph.