SOAP Headers supports

It's been a long time since I last posted a technical post. This post will deal with how the current Web Services framework deals with soap headers. More specifically, how does the .Net framework and Glassfish JAX-WS RI (J2EE ->JEE Reference Implementation) deals with those.

As it deals with a new subject in this blog (Web Services), let me first speak about the background before dwelling in the real subject.

Background

Today most Web Services uses the WSDL, UDDI and SOAP over HTTP protocols to work. WSDL is a xml based language to describe what a web services supports, SOAP is an xml based protocol designed to exchange messages, if possible compliant with the WSDL contract.

SOAP messages are composed of a body and header. The W3C recommended use is: data (payload) in the body and metadata (authentication, session ...) in the header.

Defining Soap header

IBM published a very interesting resource on how to define soap headers in the WSDL contracts. To put in a nutshell, there is two ways to define soap headers: either explicit or implicit.

Explicit, the headers are considered to be part of the input message of operations. The difference is made in the binding.

Implicit, the headers are defined in separate messages and are defined to be input of operations in the binding.

Current framework support

I have recently noticed that the support of both WSDL constructions greatly differ between the .Net and JEE RI frameworks.

I have defined two WSDL files, one with explicit soap headers, and the other with implicit header. I used the .Net framework wsdl.exe tool to create both client and server source stub/interface and I used the wsimport.exe tool (JEE RI) to do the same for the java platform.

While the .Net framework can handle both explicit and implicit construction, the JEE RI doesn’t add the headers when the WSDL defines implicitly the headers. Therefore, one has to manually add the headers parameters to every function.

A possible fix

If JEE RI doesn't support implicit construction, a possible fix would be to always add explicit headers.

Saddly, the .Net framework generated WSDL files defines implicit headers. Thus JEE RI won't be able to automatically consume .Net WSDL files.

My Conclusion

Despite all the works on both sides to improve JEE/.Net interoperability (WSIT, project Tango), and despite the WS-I work; consuming Web Services endpoints created in a language in the one might still be problematic when using soap headers.