Every now and then there arises a need to carry out-of-band information alongside the business payload but without disturbing or modifying it. Message Envelope Pattern is the Enterprise Integration Pattern label that is typically applied to solutions that address this issue. How the issue is addressed in practice varies depending on the technology in use. For JMS, for example, JMS Message Properties could be used to carry out-of-band information while the payload would be carried as the JMS payload. Web Services, typically using SOAP over HTTP, can address this requirement through the SOAP Header Extension Mechanism, whereby custom headers can be added to the SOAP Header while the payload is carried in the SOAP Body.
This document discusses construction of a WSDL that supports custom SOAP Header element and BPEL processes that are used to set and get custom header values in JBI and in eInsight. This mechanism is known to work in Java CAPS 5.x, Java CAPS 6 Classic and OpenESB / GlassFish ESB.
It is assumed that the reader is sufficiently familiar with the GlassFish ESB / OpenESB BPEL Service Engine and the SOAP/HTTP Binding Component, and / or Java CAPS Classic eInsight Business Process Manager and eDesigner IDE to be able to build projects without a step-by-step pictorial document.
The document is available here: 01_Handling_SOAP_Headers_in_BPEL_.pdf
The companion archive, containing WSDLs and projects, is available here: 01_Handling_SOAP_Headers_in_BPEL.zip
While the method discussed in this entry is still valid there is now a different treatment of the topic, using NM Properties, “GlassFish ESB v2.x – Reading and Writing arbitrary SOAP Headers in BPEL 2.0 using NMProperties“.
This is a nice description!
I tried something similar some months ago, but in our case, it didn’t work.
We wanted to get a header element (an Axis 1 session id) from a login operation to be able to pass it as header element to subsequent operation calls of the service.
Unfortunately, the response of the login operation in the original WSDL doesn’t have any message parts, the only data is the session id returned in the header.
We could not bind the only message part of the modified WSDL to the header element, because the <body> element is mandatory. When its parts attribute is omitted, all message parts are bound to the body and thus cannot be bound to the header. When supplying a parts attribute, it must contain at least one message part name, which must be the newly added part that we intended to bind to the session id header element. As it is now bound to the body, it cannot be bound to the header.
🙁
We worked around this by copying the complete header from the login response to the requests of the subsequent operation calls, using the sun extension for the SOAP header (NMProperties).
Thanks for the good word, Dirk.
Alas, SOAP is fairly strict about the message structure. SOAP Header with no SOAP Body sounds like ebXML 🙂 I am glad, though, that you worked through the issue and got a solution to it.
Regards
Michael