Customizing the WS-Addressing RelatesTo header with Metro 2.1
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.
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.