JAX-WS as Java's standard API for web services comes with a close integration of JAXB as XML binding framework. More precisely JAXB is actually the only binding technology directly supported by JAX-WS. As JAXB basically does its job pretty well, that's nothing bad per se.
Nevertheless there might be situations where you would like to integrate JAX-WS with other XML binding solutions such as Apache XmlBeans.
For instance you might have used another web service stack and binding framework in the past and now want to migrate your services to JAX-WS. Depending on the number of services, changing your XML binding framework can create quite a lot of work, as you have to rewrite the mapping code which converts between the types generated by the binding framework and your domain objects.
Provider-based endpoints
The key idea for integrating JAX-WS with another binding framework is to create a Provider based endpoint for your web service. Contrary to standard SEI (service endpoint interface) implementations, which solely operate on JAXB generated classes, a provider endpoint has access to the raw XML of incoming and outgoing messages.
That way you can take care of XML marshalling yourself, e.g. by converting incoming XML messages into their corresponding XmlBeans types and the other way around.
In the following a web service for a video rental store shall be built. The service has a single operation, getMovieById, with request and response types in an accompanying XML schema (the service's WSDL and all other sources for this post can be found in my Git repository):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="http://www.gunnarmorling.de/moapa/videorental/types" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:videorental="http://www.gunnarmorling.de/moapa/videorental/types"> <element name="GetMovieByIdRequest" type="videorental:GetMovieByIdRequest" /> <element name="GetMovieByIdResponse" type="videorental:GetMovieByIdResponse" /> <complexType name="GetMovieByIdRequest"> <sequence> <element name="Id" type="long" /> </sequence> </complexType> <complexType name="GetMovieByIdResponse"> <sequence> <element type="videorental:Movie" name="Movie" minOccurs="0" /> </sequence> </complexType> <complexType name="Movie"> <sequence> <element name="Id" type="long" /> <element name="Title" type="string" /> <element name="RunTime" type="int" /> </sequence> </complexType> </schema> |
XmlBeans will generate two document types for the elements (GetMovieByIdRequestDocument, GetMovieByIdResponseDocument) as well as types for each of the complex types.
For the service implementation I recommend to work only with the classes representing the complex types (instead of the document types). An interface representing the service's port type and its implementation therefore might look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
public interface VideoRentalPortType { public GetMovieByIdResponse getMovieById(GetMovieByIdRequest request); } ... public class VideoRentalPort implements VideoRentalPortType { private MovieRepository movieRepository = new MovieRepositoryMockImpl(); public GetMovieByIdResponse getMovieById(GetMovieByIdRequest request) { GetMovieByIdResponse response = GetMovieByIdResponse.Factory.newInstance(); de.gmorling.moapa.videorental.domain.Movie movie = movieRepository.getMovieById(request.getId()); if(movie != null) { response.setMovie(convert(movie)); } return response; } private Movie convert(de.gmorling.moapa.videorental.domain.Movie movie) { Movie theValue = Movie.Factory.newInstance(); theValue.setId(movie.getId()); theValue.setTitle(movie.getTitle()); theValue.setRunTime(movie.getRunTime()); return theValue; } } |
This looks pretty similar to a typical SEI-based implementation. The only difference is, that the types in use are generated by XmlBeans instead of JAXB. The implementation is straight forward. It takes the movie id from the incoming request, invokes some backend business service and creates a GetMovieByIdResponse from the result.
Next we need to create the actual Provider implementation which will be called by the JAX-WS runtime, whenever the service is invoked:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
@WebServiceProvider @ServiceMode(value=Mode.MESSAGE) public class VideoRentalProvider implements Provider<SOAPMessage> { private VideoRentalPortType videoRentalPort = new VideoRentalPort(); public SOAPMessage invoke(SOAPMessage request) { try { Node root = request.getSOAPBody().getFirstChild(); if(root.getNodeName().contains(GetMovieByIdRequest.class.getSimpleName())) { GetMovieByIdRequestDocument requestDocument = GetMovieByIdRequestDocument.Factory.parse(root); GetMovieByIdResponseDocument responseDocument = GetMovieByIdResponseDocument.Factory.newInstance(); responseDocument.setGetMovieByIdResponse(videoRentalPort.getMovieById(requestDocument.getGetMovieByIdRequest())); return createSOAPMessage(responseDocument); } else { throw new UnsupportedOperationException(); } } catch(Exception e) { throw new RuntimeException(e); } } private SOAPMessage createSOAPMessage(XmlObject responseDocument) { try { SOAPMessage message = MessageFactory.newInstance().createMessage(); Node node = message.getSOAPBody().getOwnerDocument().importNode(responseDocument.getDomNode().getFirstChild(), true); message.getSOAPBody().appendChild(node); return message; } catch(Exception e) { throw new RuntimeException(e); } } } |
A provider implementation must be annotated with @WebServiceProvider. By binding the type parameter to SOAPMessage (a comparison with the alternatives Source and DataSource can be found here) and specifying Mode.MESSAGE within the @ServiceMode annotation we achieve, that we can access complete SOAP messages within the implementation.
The Provider interface defines only one method, invoke(). This method is called whenever any of the service's operations is invoked. Therefore we first have to determine the currently invoked operation, which can be done by peeking at the node name of the first body element.
In case of the getMovieById operation then a GetMovieByIdRequestDocument instance representing the contents of the message body is created using a XmlBeans-generated factory class. From that document we retrieve the actual request element and pass it to the port implementation.
The result is put into a new GetMovieByIdResponseDocument instance, which itself is finally wrapped into a SOAPMessage by importing the root DOM node into the message body.
Conclusion
Creating Provider-based endpoints makes it possible to use JAX-WS together with binding frameworks other than JAXB. Whether it should be done depends as always on the specific circumstances.
For new projects working with SEI endpoints and therefore JAXB should be preferred. The JAX-WS tooling will smoothly generate JAXB binding classes as well as port type interfaces, making the creation of new web services pretty simple.
In migration scenarios things can be different though. Re-writing a whole lot of mapping code originally created for another binding framework such as XmlBeans can be quite a time-consuming and error-prone task. In that case implementing Provider-based services can be an interesting alternative.
When pursuing that approach some performance tests should be executed first. A short load test on my machine didn't show significant execution time differences between JAXB/XmlBeans for the video rental service. But things might look different for larger message types due to the involved DOM manipulations.
Posts
