WSDL for Java or Java for WSDL?

Question

I recently selected a project that has a rather nasty build process. Hand-coded XSD schemes are read by JAXB to create a Java model of classes and factories that are used in hand-coded (annotated) Java web service classes, which are then deployed to the server, which is used as the source to read the full WSDL, to create a second model based on Java, which includes classes of service and a factory for the full WSDL that is used in client programs.

It sounds horrible, and I don’t think I need it to be so complicated, so at some point I would like to drop it all and

• Manually creating a WSDL, creating a complete model, and adding utility code.
• Or - Write service classes and models and create WSDL as needed on the server at run time.

In any case, I want to get one source base for the model, which can be used by both the server and clients, and have one “source of truth” for the model, where, as of right now, I feel that I have several.

At the moment, I am inclined to the second option, but what would you choose? And what technology would you use?

Answer 1

In the project I'm working on, we are currently completely redesigning our web services. These services provide server functions to clients through SOAP. From what I learned, looking at all the intricacies of this protocol, which greatly affect the location of WSDL, I would rather not write WSDL myself. There are so many things that you can make mistakes (especially when it comes to things like parameter style and all that). And as soon as your WSDL is there and the clients created from this WSDL happily communicate with your application, you can no longer change it (or you start thinking about a version control strategy, which can also be very painful).

So my strong suggestion is to write the service code in Java and let your library create the WSDL for you. Then you can easily play different binding styles (which, in turn, affects the interaction with other clients). Here you will find very detailed articles describing all of this:

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

In addition, WSDLs are not particularly readable by people, and therefore (at least in my opinion), it is more difficult to maintain people. Java code, on the other hand, is pretty easy to read (or at least you can write it that way), which is an even better reason for Java code to work, rather than WSDL.

Hope this helps in making your decision.

Answer 2

The purest method is to create WSDL manually or using the constructor - and from them generate proxies and stubs.

The logic behind this path is that the WSDL defines a service contract that should be agnostic for implementation. And Java classes are implementation specific - and these implementation details are often passed to WSDL

The exact problems depend on the Java-WSDL converter you are using (or, more importantly, the Java-XSD converter), but they are quite common, especially if you plan to add non-Java servers or clients to your environment.

If you prefer to write services in Java, you should follow some guidelines that minimize implementation blocking, for example:

• manage translation from classes to XSD (I believe that this can be done using annotations
• use only simple types and aggregates of simple types as parameters (do not pass your regular classes as parameters)

Answer 3

I would think that the extraction of wsdls and schemas should be done using a simple HTTP GET process either manually or using a simple code call (ant task, etc.), and not the rather confusing process that you described. Having said that, I usually deal with web services that have a release cycle, and therefore I get, as a rule, getting wsdls and schemas manually.

If you need to re-get wsdls and schemas in each assembly, I would be inclined to put the get process into the assembly as a preliminary step (in maven this will initialize the phase and I would look at using the GET ant task ), followed by the wsdl2java step (in maven I I usually connect the wsdl2java ant task to generate sources ).

Answer 4

I recently watched how to automatically generate Java classes from wsdl. Therefore, I used wsdl2java.bat from the Apache cxf project. http://cxf.apache.org/

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

Answer 5

Once you fix in memory that web services and Java are completely two different things, this approach will make sense.

Given this preamble, the reason XSD is written by hand is to avoid infecting the method parameters with Java types . This pollution problem exists from the very beginning.

The problem is twofold: type determination, language restriction. Types created by web services such as JAX-RPC are not suitable for consumption by many non-Java consumers. The Java team is constantly working on this, and I feel that one of the two issues was mostly bypassed by JAX-WS. An attempt to define web services outside the context of a programming language (XML is a language) is the reason for manually writing data definitions.

Generating WSDL is complicated, as many have pointed out, and is best done using a WSDL tool or development environment — so transport is no longer a concern. This way, the XSD gets into your WSDL, and since you "manually" encode the XSD, you will control your content.

Answer 6

One approach is to use XML Schema (XSD) to define the model. After defining this model, you define service interfaces (WSDLs) that use objects from the model (XSD) as service I / O.

This defines your abstract level of service and model.

Then you can use your favorite tools and technologies to develop specific implementations. You can even use jAXB to determine the java equivalent of the XSD model library and use it in the client and server.

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

Answer 7

I really like Spring-WS. This is the first approach to the contract. Why contract first?

You define your XML schema, and Spring will generate WSDL for you. It hides the technical aspects of WSDL, it is really clean.