CODEWITHSUNDEEP
javaweb-servicesjakarta-eewsdlsoa
drekka
drekka

Reputation: 21893

WSDL to Java or Java to WSDL?

I've recently picked up a project which has a rather nasty build process. Hand coded XSD schemas are read by JAXB to generate a Java model of classes and factories, which is used in hand coded Java web service classes (annotated), which are then deployed to a server, which is used as a source to read the complete WSDLs from in order to generate a second Java based model which includes the service and factory classes for the complete WSDL, which is used in client programs.

This sounds aweful and I don't think I need it to be so complicated so at some stage I'd like to chuck all this away and either

Either way I want to end up with one source base for the model which both the server and clients can use and have one "source of truth" for what the model should be, where as at the moment I feel like I have several.

At the moment I'm leaning towards the second option, but which would you choose? And which technologies would you use?

Upvotes: 8

Views: 10258

Answers (7)

CMR
CMR

Reputation: 985

Once you commit to memory that web services and Java are entirely two different things, this approach will make some sense.

Given this preamble, the reason XSDs are hand written is to avoid contamination of method parameters by Java types. This problem of contamination has existed since the very beginning.

The problem is two-fold: type definition, limitation of a language. The types generated by JAX-RPC type web services were not suitable for consumption by many non-Java consumers. The Java group is constantly working at this, and I feel one of the two problems has largely been circumvented with JAX-WS. The attempt of defining web services outside the context of a programming language (XML is a language) is the reason for hand writing data definitions.

WSDL generation is hard, as many have pointed out, and is best done with a tool, or an IDE that generates WSDL - this way, transport is not a concern anymore. This way the XSDs get included into your WSDL, and as you "hand-coded" the XSDs you will have control over your content.

Upvotes: 2

bdurand
bdurand

Reputation: 406

I really like Spring-WS. It's a contract first approach. Why contract first

You define your XML Schema and Spring will generate the WSDL for you. It Hide the technicals aspects of the WSDL, it's really clean.

Upvotes: 1

Sarat Buddhiraju
Sarat Buddhiraju

Reputation: 166

One approach is to use XML Schema (XSD) to define a model. Once this model if defined you define service interfaces (WSDL) which use the objects from the model (XSD) as inputs / outputs of the services.

This defines your abstract service and model layers.

You can then use your favorite tools and technologies to development concrete implementations. You can even use jAXB to define a java equivalent of the XSD model library and use it in the client and server.

http://buddhiraju.wordpress.com - blog on SOA, XML, integration and related topics

Upvotes: 2

RobertB
RobertB

Reputation: 516

In the project I'm working on, we're currently redoing our web services completely. These services offer server functionalities to clients via SOAP. From what I've learned looking at all the intricacies of that protocol, which highly affect the layout of the WSDL, I'd rather not write a WSDL myself. There are so many things you can get wrong (especially when it comes to things like parameter style and all that). And once your WSDL "is out there" and clients generated from that WSDL are happily communicating with your application you can no longer change it again (or you start thinking about a versioning strategy, which can turn out to be quite painful as well).

So my strong suggestion is to write your service code in Java and let your library generate a WSDL for you. You can then very easily play around with different binding styles (which in turn affect interoperability with other clients). A very thorough article describing all of that can be found here:

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

Additionally, WSDLs are not particularly readable for humans and therefore (at least in my view) harder to maintain by humans. Java code on the other hand is fairly easy to read (or at least you can write it that way) which is a even better reason to handcraft the Java code and not the WSDL.

Hope that helps in making your decision.

Upvotes: 8

monty
monty

Reputation: 8755

Recently I followed the way to automatically generate the Java classes from the wsdl. Therefor I used the wsdl2java.bat out of the Apache cxf project. http://cxf.apache.org/

I had to make some minor changes (XmlElementWrapper) for the collections and some fixes of the namespace but everything else was fine.

Upvotes: 2

Ophir Yoktan
Ophir Yoktan

Reputation: 8449

The cleanest method is to generate the WSDL manually or using a designer - and from them generate the proxies and stubs.

The logic behind this way, is that the WSDL defines the service contract, which should be implementation agnostic - And the Java classes are implementation specific - and those implementation details are often transfered to the WSDL

The exact problems depends on the Java to WSDL convertor you use (or more importantly, the Java to XSD converter) - but they are pretty common, especially if you plan to add non Java servers or clients in you environment.

If you prefer writing the services in Java, you should follow some guidelines that will minimize implementation lock in, like:

  • control the translation from classes to XSD (I believe this can be done using annotations
  • use only simple types and aggregates of simple types as parameters (don't pass your regular classes as parameters)

Upvotes: 5

Michael Rutherfurd
Michael Rutherfurd

Reputation: 14065

I would have thought that retrieval of the wsdls and schemas should be doable using a simple HTTP GET process either manually or via a simple code call (ant task etc) rather than that rather convoluted process you described. Having said that I usually deal with web services that have a release cycle and therefore I get usually get given the wsdls and schemas manually.

If you have to re-get the wsdls and schemas on every build I would be inclined to put the get process into the build as a preliminary step (in maven it would be the initialize phase and I would look at using the GET ant task) followed by the wsdl2java step (in maven I usually hook the wsdl2java ant task to the generate-sources phase).

Upvotes: 4

Related Questions