Skip to main content

Customizing the WS-Addressing RelatesTo header with Metro 2.1

Please note these forums are being decommissioned and use the new and improved forums at
2 replies [Last post]
Joined: 2008-05-28

Hello all,

We are upgrading from Metro 1.5 to Metro 2.1.

Here's a background on the issue:
With our Metro 1.5 implementation, we were using custom code to populate WS-Addressing headers. Although we use a WSDL-first approach, Metro 1.5 did not complain if we never had a <wsaw:UsingAddressing /> element in our WSDL policies. With Metro 2.1, we observe that this policy if not present on the WSDL, sending a set of WS-Addressing headers in the message (using custom code) does not work any more. The receiver returns a fault as it does not expect WS-Addressing turned on.

If we add the <wsaw:UsingAddressing /> element to our WSDLs to overcome the fault, we get two sets of WS-Addressing headers - one generated from the stack and the other from our custom code. To get over this, we have removed any custom code to create WS-Addressing headers and are now relying on the Metro stack to do the needful. This works in most use cases but a specific set which is the issue I describe below.

Our issue:
We use a custom defined 'deferred' transaction specification. In this specification, an asynchronous web service call is modeled as two synchronous calls, responses for both being acknowledgements for receipt of the message. This specification was developed outside our implementation group. We require doing the following:

As an initiator in deferred transactions:
1. While sending a deferred request, keep a track of dispatched messages with WS-Addressing message IDs sent.
2. On receiving a deferred response, map the UUID from WS-Addressing RelatesTo header to a tracked request message - this is for correlation of the response to the request.

As a responder in deferred transactions:
1. On receiving a deferred request, keep a track of the received message ID.
2. While dispatching the deferred response, add the message ID as received for the request in the WS-Addressing RelatesTo header of the deferred response.

With Metro 1.5, within our custom code, we were creating a UUID for the WS-Addressing message ID and satisfying the above requirements with custom code. With Metro 2.1, we do not have a handle on the WS-Addressing message ID. We do not know of an API that can let us supply a UUID for the WS-Addressing message ID or the WS-Addressing RelatesTo while letting the Metro stack handle the rest.

We are requesting help to identify the best implementation route to resolve this issue. Any help that you could provide is highly appreciated.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-06-01

 (1) If the service does not have WS-Addressing in its policy or AddressingFeature is turned on, it should accept WSA headers just like any oher additional headers that the JAX-WS runtime would not process. What is the fault you are receiving in this scenario? Sending the WSA headers with mustUnderstand attribute will result in to MU fault. If thats the case, you can send the same headers removing the mustUnderstand attribute.

(2) JAX-WS does not currently provide custom configuration of the WSA headers. Either its completely handled by runtime or not at all. If AddressingFeature is enabled on the client either programatically or through wsdl policy, JAX-WS runtime owns adding these headers. You can probably disable the addressing by using new AddressingFeature(false) on the client and the user code handles adding and processing these headers.

I agree providing the ability to the user to set these headers would be useful in some scenarios. Please file a RFE for this feature. It could be done through some addressing properties set in the RequestContext (probably also in the net version of the spec). Setting them directly as outbound headers would be overhead for the JAX-WS runtime to check if a header is already set by the user. 

Couple fo workarounds that might work for you as it stands now.

(1) If you just want control over MessageId, Enable AddressingFeature on client and only add messageId as outbound header. It should be picked up.

(2) If you want control over ReplyTo etc, you can try enabling to set the WSA headers along with AddressingFeature. Please note that this OneWAyFeature is not supported and might be removed in future. 







Joined: 2008-05-28

Hi Rama,

Thanks for your response.

We were getting the MU fault and we need the mustUnderstand attribute as dictated by the NHIN messaging platform spec.

We have filed an RFE for the custom headers and there was a fix made. We are waiting for the fix to get into a JAX-WS build that Metro can then pick up.

I have asked the folks who helped assing/fix this issue about how we could potentially get this included in the next JAX-WS build (and Metro build later). Can you throw some light and provide pointers?