When JAX-WS Passes And Returns NULL
When a JAX-WS SOAP service ignores all parameters (sends null) and only returns null-values, there is problem with JAXB-mappings and/or WSDL-settings.
If you see the payload (you have to activate the debug-setting:
-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true), but always get a null-result, compare your WSDL with @WebMethod, @WebParam and @WebService annotations. You can also activate JAXB-output with
@Adam "Disclaimer: I do not consider JAX-WS as a best practice in Java EE 6..."
Although it is a disclaimer with no warranty I do not completely agree (-: JAX-WS is a mature technology for building SOAP- and REST-based web services. The REST part of JAX-WS is not comfortable enough for web service developer, therefore JAX-RS was borne which is easier to use even with more functionality. But this is not the point!
The point is that JAX-WS (SOAP part) and JAX-RS are both legal depending on use cases. The real benefit of SOAP-based web services is the WSDL which defines the web service interface. The top-down approach (WSDL2Java) is still a best practice to solve interoperability problems. WSDL interfaces are clear and (quasi) normed by using the WS-I basic profile as a guide for web service development. The WSDL is the important artifact from which the generation of Java artifacts is easy by tooling. The power of WSDL is important in Enterprise Service Bus (ESB) environments and Java Business Integration (JBI) components, which are described by WSDL. My opinion is that REST is not the big player in ESB environments. I think you need a definition (for SOAP services the WSDL) to handle parameter types and encodings, protocol transformations, routings and mediation. Therefore I see REST rather as the lightweight and maybe agile gate to portal backend systems to build single processes (no orchestration necessary).
I fully agree that JAX-RS makes coding funny and I like to write RESTful web services rather to write a complex WSDL file (although Eclipse support is available). The lightweight approach of REST is nice, but has a danger. The input line of the browser (you need no scripting to call the service) is the direct gateway to the database for a not properly secured REST service. To secure the REST service is still effort, including configuration and programming tasks.
Posted by Jörg Rückert on June 07, 2011 at 10:23 PM CEST #
"The point is that JAX-WS (SOAP part) and JAX-RS are both legal depending on use cases"
Given a freedom of choice: which use cases can be easier (=more maintainable) or cheaper (=more productive) solved with JAX-WS comparing it to JAX-RS?
thanks for manifesting your opinion!,
Posted by Adam Bien on June 08, 2011 at 02:05 AM CEST #
@Adam Given a freedom of choice: which use cases can be easier (=more maintainable) or cheaper (=more productive) solved with JAX-WS comparing it to JAX-RS?
The simplest use case is the usage of an existing session facade. The publication of the facade as web service is easy by adding an annotation (@WebService). More fine granular by using annotations on the facade methods (@WebMethod). This use case is not really a strong point, but doing the same with REST is more coding and design effort for the simple goal to use the legacy software as web service.
A stronger point is that with JAX-WS the developer defines domain specific interfaces (domain specific verbs) which are self-describing by the WSDL. The REST interface instead is generic (set of defined verbs) leaving the domain specific subjects in the addressed resources. This is essential! JAX-WS (SOAP-part) is therefore primarily activity-oriented and REST is strongly resource-oriented. The architecture of REST is based on the generic interface for mainly CRUD operations. You see it also in the Response and Fault codes. SOAP faults are domain specific. REST faults are Http specific error codes. To use the response for the domain specific fault message in association with Http state 200 (OK) is a poor decision. This leads to a possible use case were domain specific faults has to be traced and processed (JAX-WS - SOAP fault has a benefit!).
Developer can build complex interactions with REST. Even multipart messages are possible with JAX-RS. The argument that REST is inherently stateless and SOAP has the possibility to define stateful services can be moderated by defining a stateless architecture not holding any state on the server side. On the other side, I see some bricks to lay out use cases.
When we come to ESBs the strong points occur. SOAP services can be bound to different protocols. ESBs work internally with JMS to cover the requirements of the pipeline architecture. Without the possibility to bound SOAP to different protocols this architecture which is a key point for SOA wouldn’t as it is today. The SOAP extensibility model is the key, defining SOAP nodes processing the header of the SOAP envelope for routing and mediation issues. We do not have such functions for REST. REST is easy but tightly coupled with the Http protocol. I do not actually see the orchestration and workflow requirements covered by REST where human tasks are involved and the reply is minutes, sometimes hours or days away from the primary request.
Posted by Jörg Rückert on June 08, 2011 at 04:16 PM CEST #
As far as i know, there are couples of methods to invoke web service implementation.
1. Stubs code
3. JAX-WS Dispatch API
What is the difference between all these ? How does this relate to the web service architecture ?
Which is the best approach to use with JAXB. Currently i have used DISPATCH<Object>.
But one thing i face when i use DISPATCH<Object> is that when i send JAXBObjects, how the marshalling and unmarshalling will happen
Posted by umesh on October 20, 2011 at 11:31 PM CEST #
One can look at the generated package-info.java to gain some insight. In my case the problem was due to namespaces.
Posted by Michael Krause on November 25, 2013 at 12:11 PM CET #