# WS-Addressing

## WS-Addressing in &jax-ws.product.name.short;

Web Services Addressing provides transport-neutral mechanisms to address Web services and messages. JAX-WS 2.2 specification requires support for W3C Core, SOAP Binding and Addressing 1.0 - Metadata specifications and defines standard API to enable/disable W3C WS-Addressing on the client and service endpoint. In addition to that, &jax-ws.product.name.short; also supports Member Submission version of WS-Addressing. The member submission version is supported in an implementation specific way. For compatility with JAX-WS 2.1 behavior, &jax-ws.product.name; also supports wsdls conforming to WSDL Binding specification. The subsequent sections describe how the two WS-Addressing versions can be enabled/disabled on client and server side .

## Why WS-Addressing?

The subsequent sections explain the different use cases served by WS-Addressing.

### Transport Neutrality

This section describes how a message can be sent to a Web service endpoint in transport neutral manner.

SOAP 1.2 message, without WS-Addressing, sent over HTTP

    POST /fabrikam/Purchasing HTTP 1.1/POST
    Host: example.com
    SOAPAction: http://example.com/fabrikam/SubmitPO

    <S:Envelope
            xmlns:S="http://www.w3.org/2003/05/soap-envelope"
            xmlns:wombat="http://wombat.org/">
        <S:Header>
            <wombat:MessageID>
                uuid:e197db59-0982-4c9c-9702-4234d204f7f4
            </wombat:MessageID>
        </S:Header>
        <S:Body>
            ...
        </S:Body>
    </S:Envelope>

HTTP transport headers.

SOAP message in HTTP body.

The host (`example.com`), the dispatch method (`POST`) and the URL to dispatch to (`/fabrikam/Purchasing`) are in the HTTP transport headers. The actual message and implied meaning (for example payload's `QName` or `SOAPAction`) is defined by the messaging system (`SOAP`) or transport protocol (`HTTP`). If the message is to be sent over an alternate transport, such as SMTP, then the information conveyed in HTTP transport headers need to be mapped to SMTP specific headers. On the server side, to dispatch successfully, a Web service stack has to gather the information from the SMTP (as opposed to HTTP) headers and the SOAP message.

Also in the above message, there is no standard header to establish the identity of a message. In this case, `MessageID` header defined in the namespace URI bound to `wombat` prefix is used but is application specific and is thus not re-usable.

WS-Addressing introduce Message Addressing Properties that collectively augment a message to normalize this information.

SOAP 1.2 message, with WS-Addressing, sent over HTTP

    POST /fabrikam/Purchasing HTTP 1.1/POST
    Host: example.com
    SOAPAction: http://example.com/fabrikam/SubmitPO

    <S:Envelope
            xmlns:S="http://www.w3.org/2003/05/soap-envelope"
            xmlns:wsa="http://www.w3.org/2005/08/addressing/">
        <S:Header>
            <wsa:MessageID>
                uuid:e197db59-0982-4c9c-9702-4234d204f7f4
            </wsa:MessageID>
            <wsa:To>
                http://example.com/fabrikam/Purchasing
            </wsa:To>
            <wsa:Action>
                http://example.com/fabrikam/SubmitPO
            </wsa:Action>
        </S:Header>
        <S:Body>
            ...
        </S:Body>
    </S:Envelope>

HTTP transport headers.

SOAP message in HTTP body.

Binding of Message Addressing Properties to SOAP 1.2 message.

For example, `wsa:MessageID` is a binding of an abstract property that defines an absolute URI that uniquely identifies the message, `wsa:To` is binding of an abstract absolute URI representing the address of the intended receiver of this message and `wsa:Action` is binding of an abstract absolute IRI that uniquely identifies the semantics implied by this message. All the information earlier shared between transport protocols and messaging systems is now normalized into a uniform format that can be processed independent of transport or application.

If the exactly same message is to be sent/received using a different transport, for example asynchronously over SMTP, then the value of `wsa:To` header could be changed to `mailto:purchasing@example.com`. The updated `wsa:To` header looks like:

    <wsa:To>
        mailto:purchasing@example.com
    </wsa:To>

On the server side, Web services stack can gather all the information from the SOAP message and then dispatch it correctly.

### Stateful Web service

Web services are usually stateless, i.e. the service endpoint receives a request and responds back without saving any processing state in between different requests. However making Web services stateful enables to share multiple instances of service endpoints. For example, consider a stateful Bank Web service. The client (say bank customer) can obtain a bank EPR, with relevant state information stored as reference parameters, and invoke a method on that EPR to do a series of banking operations. On the service endpoint, whenever a request is received, the reference parameters from the EPR are available as first-class SOAP headers allowing the endpoint to restore the state.

&jax-ws.product.name; enables stateful Web services to be annotated with `com.sun.xml.ws.developer.Stateful` annotation.

### Simple and Complex MEPs

WS-Addressing defines standard Message Addressing Properties (MAPs) to support simple and complex message patterns. The SOAP Binding defines a mapping of these MAPs to SOAP headers and convey end-to-end message characteristics including addressing for source and destination endpoints as well as message identity. For example `destination` MAP represents an absolute IRI representing the address of the intended receiver of the message and is mapped to a SOAP header with `wsa:To` element name. `reply endpoint` represents an endpoint reference for the intended receiver for replies to this message and is mapped to a SOAP header with `wsa:ReplyTo` element name. In addition, WSDL Binding, also defines requirement on the presence of these MAPs for standard Message Exchange Patterns (MEPs) such as request/response and one-way.

Using these MAPs, complex MEPs can be created. For example:

1. Asynchronous MEP: Using `reply endpoint` MAP, an asynchronous transport may be specified for a synchronous request. For example, a client application might send a request over HTTP and ask to receive the response through SMTP.

2. Conversation MEP: Using `relationship` MAP, that defines the relationship between two messages, a conversational MEP can be defined by correlating multiple request/response MEPs. For example a client sending a request to service endpoint receives a response with `wsa:RelatesTo` MAP. The service endpoint may optionally include `wsa:MessageID` in the response. This MAP can then be included by the client in `wsa:RelatesTo` MAP in next request to the service endpoint there by starting a conversation.

3. Distributed MEP: Using `reply endpoint` and `fault endpoint` MAP, a different transport/address can be specified for receiving normal and fault responses respectively.

### Composability with other WS-* specifications

There are several Web services specification (commonly known as WS-* specs) that make use of the abstract properties defined by WS-Addressing. For example WS-Metadata Exchange define a bootstrap mechanism for retrieving metadata before the business message exchange can take place. This mechanism involve sending a WS-Transfer request for the retrieval of a resource's representation. A typical request message looks like:

    <s11:Envelope
            xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
            xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <s11:Header>
            <wsa:Action>
                http://schemas.xmlsoap.org/ws/2004/09/transfer/Get
            </wsa:Action>
            <wsa:To>http://example.org/metadata</wsa10:To>
            <wsa:ReplyTo>
                <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous
                </wsa10:Address>
            </wsa:ReplyTo>
            <wsa:MessageID>
                uuid: 68da6b24-7fa1-4da2-8a06-e615bfa3d2d0
            </wsa:MessageID>
        </s11:Header>
        <s11:Body/>
    </s11:Envelope>

SOAP request message to retrieve metadata about a Web service endpoint.

WS-Addressing namespace URI bound to "`wsa`" prefix.

The standard WS-Addressing MAPs used to convey the semantics (`wsa:Action`), receiver (`wsa:To`) of the message, intended receiver of reply (`wsa:ReplyTo`) message and identity (`wsa:MessageID`) information of the message

This message has an empty SOAP Body and relies completely upon standard MAPs to convey all the information. Similarly, a WS-Metadata Exchange response message with metadata looks like:

    <s11:Envelope
            xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
            xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <s11:Header>
            <wsa:Action>
                http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse
            </wsa:Action>
            <wsa:RelatesTo>
                uuid: 68da6b24-7fa1-4da2-8a06-e615bfa3d2d0
            </wsa:RelatesTo>
        </s11:Header>
        <s11:Body/>
        ...
        <s11:Body/>
    </s11:Envelope>

The standard WS-Addressing MAPs used to convey the semantics (`wsa:Action`) of the response message and relationship (`wsa:RelatesTo`) to the request message.

Abbreviated SOAP Body for simplicity which otherwise would contain the MEX response.

WS-Reliable Messaging describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system or network failures. This specification defines protocol messages that must be exchanged between client and service endpoint, before the business message exchange, in order to deliver the messages reliably. For example, RM Source sends `<CreateSequence>` request message to RM Destination to create an outbound sequence. The message looks like:

    <s11:Envelope
            xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
            xmlns:wsa=" http://www.w3.org/2005/08/addressing"
            xmlns:wsrm=" http://schemas.xmlsoap.org/ws/2005/02/rm">
        <s11:Body>
            <wsrm:CreateSequence>
                <wsrm:AcksTo>
                    <wsa:Address>
                        http://www.w3.org/2005/08/addressing/anonymous
                    </wsa:Address>
                </wsrm:AcksTo>
            </wsrm:CreateSequence>
        </s11:Body>
    </s11:Envelope>

SOAP Body of the request message.

The Body contains an element, `wsrm:AcksTo` (of the type Endpoint Reference), that specifies the endpoint reference to which `<SequenceAcknowledgement>` messages and faults related to sequence creation are sent.

WS-Secure Conversation, WS-Trust, WS-Policy and other similar specifications use the constructs defined by WS-Addressing as building blocks.

## WS-Addressing Versions

There are two prominent versions of WS-Addressing that are commonly used:

- W3C WS-Addressing

- Member Submission WS-Addressing

Sun, IBM, BEA, Microsoft and SAP co-authored and submitted a WS-Addressing specification to W3C in August 2004. W3C chartered a new Working Group with a mission to produce a W3C Recommendation for WS-Addressing by refining the submitted specification. The original specification submitted to W3C is referred as "Member Submission WS-Addressing" or "Submission WS-Addressing". The term Member Submission is defined by W3C.

The WG was chartered to deliver a W3C Recommendation for WS-Addressing Core, SOAP Binding (mapping abstract properties defined in Core to SOAP 1.1 and 1.2) and WSDL Binding (mechanisms to define property values in WSDL 1.1 and WSDL 2.0 service descriptions) specification. This separate between Core/Bindings is common methodology where Core is relevant to application developers and Binding (both SOAP and WSDL) is relevant for Web service stack implementers. This collective set of specifications is referred as "W3C WS-Addressing".

&jax-ws.product.name.short; supports both versions out-of-the-box. Check below on how to enable either of the versions on a service endpoint starting from Java or starting from WSDL.

## Describing WS-Addressing in WSDL

WS Addressing 1.0- Metadata defines standard ways to describe message addressing properties like Action, Destination in wsdl and also indicate the use of Addressing in wsdl. WS-Addressing Metadata specification replaces the previous Web Services Addressing 1.0 - WSDL Binding specification in candidate recommendation earlier. If you are still using wsdls conforming to WS Addressing 1.0 - WSDL Binding specification, skip to the next section. Still you may want to update your wsdls to use in standard ways defined by the W3C recommended Addressing 1.0 - Metadata specification for better interoperability. Also, There is no standard mechanism to describe Member Submission version support in the WSDL and some implementaions have used WS-Policy to indicate the support of member submission version and &jax-ws.product.name.short; understands such assertion.

### WS-Addressing 1.0 - Metadata

Addressing 1.0 - Metadata specification uses Web Services Policy Framework (WS Policy 1.5) and Web Services Policy - Attachment [ WS Policy 1.5 - Attachment] specifications to express the support of Web Services Addressing 1.0. A new policy assertion `<wsam:Addressing>` is defined to express the support of Addressing. The `wsam:Addressing` policy assertion applies to the endpoint policy subject and may be attached to `wsdl11:port` or `wsdl11:binding`.

Indicating the requirement of WS-Addressing: When

    <wsam:Addressing>

is present in a Policy alternative, one is required to use WS-Addressing to communicate with the subject.

Indicating the support of WS-Addressing:

    <wsam:Addressing wsp:Optional="true">

can be used to indicate support for WS-Addressing but does not require the use of it. In these cases, there are no restrictions about the use of WS-Adressing.

In certain cases, the endpoint can lay some restrictions to indicate the messages it can accept with WS-Addressing. Nested asertions can be used to restrict the use of response endpoint inside the `<wsam:Addressing>` assertion.

Requiring the use of Non-Anonymous response endpoints:

    <wsam:Addressing>
        <wsp:Policy>
            <wsam:NonAnonymousResponses/>
        </wsp:Policy>
    </wsam:Addressing>

can be used to indicate that the subject requires WS-Addressing and requires the use of non-anonymous response EPRs. In this case, the response endpoint in the request messages will have to use something other than the anonymous URI as the value of address. This is typically used when the response needs to be sent to a third entity other than the client and service and the response is sent to the non-anonyous URI through a new connection Requiring the use of Anonymous response endpoints:

    <wsam:Addressing>
        <wsp:Policy>
            <wsam:AnonymousResponses/>
        </wsp:Policy>
    </wsam:Addressing>

can be used to indicate that the subject requires WS-Addressing and requires the use of anonymous responses. In this case, the endpoint requires request messages to use response endpoint EPRs that contain the anonymous URI ("`http://www.w3.org/2005/08/addressing/anonymous`") or None URI ("`http://www.w3.org/2005/08/addressing/none`") as the value of address.

### WS-Addressing WSDL Binding

W3C WS-Addressing WSDL Binding defines an extensibility element, wsaw:UsingAddressing, that can be used to indicate that an endpoint conforms to the WS-Addressing specification. &jax-ws.product.name.short; generates this extension element in the WSDL if W3C WS-Addressing is enabled on the server-side. On the client side, the RI recognizes this extension element and enforce the rules defined by the W3C specification. This extensibility element may be augmented with `wsdl:required` attribute to indicate whether WS-Addressing is required (true) or not (false).

W3C WS-Addressing WSDL Binding defines `wsaw:Anonymous` element which when used in conjunction with `wsaw:UsingAddressing` define assertions regarding a requirement or a constraint in the use of anonymous URI in EPRs sent to the endpoint. The WSDL Binding defines three distinct values: `optional`, `required` and `prohibited` to express the assertion. The default value of `wsaw:Anonymous` (equivalent to not present) is `optional`. An operation with `required` `wsaw:Anonymous` value is shown below:

    <wsaw:UsingAddressing wsdl:required="true"/>
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
            style="document"/>
    <operation name="addNumbers">
        <soap:operation soapAction=""/>

        ...

        <wsaw:Anonymous>required</wsaw:Anonymous>
    </operation>
    <soap:binding>

In this case, a message received at the endpoint, for this operation, with a non-anonymous ReplyTo or FaultTo EPR will result in a fault message returned back to the client with `wsa:OnlyAnonymousAddressSupported` fault code. There is no such equivalent feature in Member Submission WS-Addressing.

## Configuring Addressing on Endpoint

This section describes how W3C and Member Submission WS-Addressing can be enabled/disabled on the server-side.

### Starting from WSDL

Starting from WSDL, If the wsdl contains the above described metadata to indicate use addressing at endpoint scope, Addressing is enabled on the server-side. See section for more details.

### Starting from Java

This section describes how WS-Addressing can be enabled/disabled if you develop an endpoint starting from a Java SEI.

By default, WS-Addressing is disabled on an endpoint starting from Java. If that is the expected behavior, then nothing else needs to be done. In that case any WS-Addressing headers received at the endpoint are treated like SOAP headers targeted for the appliaction and are ignored.

#### Addressing annotations

If WS-Addressing support needs to be enabled on an endpoint, then along with `javax.jws.WebService` annotation, `javax.xml.ws.soap.Addressing` annotation need to be specified for enabling W3C WS-Addressing. If Member Submission WS-Addressing needs to be enabled then `com.sun.xml.ws.developer.MemberSubmissionAddressing` annotation needs to be specified on the service endpoint. For example, the service endpoint in `fromjava-wsaddressing` sample looks like:

    @javax.xml.ws.soap.Addressing
    @javax.jws.WebService
    public class AddNumbersImpl {

        // ...

    }

To enable, Member Submission WS-Addressing, the SEI definition needs to be changed to:

    @com.sun.xml.ws.developer.MemberSubmissionAddressing
    @javax.jws.WebService
    public class AddNumbersImpl {

        // ...

    }

Once WS-Addressing support is enabled on a service endpoint, then:

- In the generated WSDL, corresponding metadata as described in section Describing Addressing in WSDL is generated.

- All WS-Addressing headers are understood, i.e. if any WS-Addressing header is received with a `mustUnderstand="1"`, then a mustUnderstand fault is not thrown back.

- All WS-Addressing headers received at the endpoint are checked for correct syntax, for example an error is returned back if `wsa:ReplyTo` header does not match the infoset defined in the corresponding specification.

- If any WS-Addressing header received at the endpoint is not of correct cardinality, then an error is returned back to the client.

- If `wsa:Action` header value does not match with that expected for that operation, then an error is returned back to the client.

- Any response message sent back to the client contains the required WS-Addressing headers.

#### Is Addressing Optional or Required ?

Both `javax.xml.ws.soap.Addressing` and `com.sun.xml.ws.developer.MemberSubmissionAddressing` annotations take two optional Boolean parameters, `enabled` (default true) and `required` (default false). If `required` is specified true, then WS-Addressing rules are enforced. Otherwise the inbound message is inspected to find out if WS-A is engaged and then the rules are enforced. See section for more details on enforcement during runtime.

For example, to enforce Member Submission WS-Addressing rules on the server side, the above code sample will change to:

    @com.sun.xml.ws.developer.MemberSubmissionAddressing(enabled = true,
            required = true)
    @javax.jws.WebServicepublic
    class AddNumbersImpl {

        // ...

    }

## On the client side

This section describes how WS-Addressing can be enabled/disabled on the client-side. &jax-ws.product.name.short; follows the standard extensibility elements in WSDL to enable WS-Addressing support on the client side. In addition, it also allows the client to instruct &jax-ws.product.name.short; to disable WS-Addressing processing. The assumption is that in this case the client has it's own WS-Addressing processing module. For example, a Dispatch-based client in MESSAGE mode may be used to perform non-anonymous ReplyTo/FaultTo processing.

### Implicit behavior

As defined in , If the WSDL contains metadata about the support or requirement of WS-Addressing, &jax-ws.product.name.short; runtime enables Addressing feature on the client-side.

- Generates `Action`, `To`, `MessageID` and anonymous `ReplyTo` headers on the outbound request.

- Any WS-Addressing headers received on the client are processed.

There is no standard extensibility element for Member Submission WS-Addressing and so there is no implicit behavior defined. It can only be explicitly enabled as described in the next section.

### Explicit enabling

If a WSDL does not contain WS-Addressing standard extensibility element, then either W3C WS-Addressing or Member Submission WS-Addressing can be explicitly enabled using `createDispatch` and `getPort` methods on `javax.xml.ws.Service`. The following new APIs are added in JAX-WS 2.1:

-     <T> Dispatch<T> createDispatch(javax.xml.namespace.QName portName, java.lang.Class<T> type, Service.Mode mode, WebServiceFeature... features)

-     Dispatch<java.lang.Object> createDispatch(javax.xml.namespace.QName portName, javax.xml.bind.JAXBContext context, Service.Mode mode, WebServiceFeature... features)

-     <T> T getPort(java.lang.Class<T> serviceEndpointInterface, WebServiceFeature... features)

-     <T> T getPort(javax.xml.namespace.QName portName, java.lang.Class<T> serviceEndpointInterface, WebServiceFeature... features)

Each method is a variation of an already existing method in JAX-WS 2.0. The only addition is an extra var-arg `javax.xml.ws.WebServiceFeature` parameter. A `WebServiceFeature` is a new class introduced in JAX-WS 2.1 specification used to represent a feature that can be enabled or disabled for a Web service.

The JAX-WS 2.1 specification defines `javax.xml.ws.soap.AddressingFeature` to enable W3C WS-Addressing on the client side. In addition, the &jax-ws.product.name.short; also defines `com.sun.xml.ws.developer.MemberSubmissionAddressingFeature` to enable Member Submission WS-Addressing on the client side.

For example in `fromjava-wsaddressing` example, in order to enable W3C WS-Addressing on a proxy, `wsimport` is used to generate the `AddNumbersImplService` class. Then a port can be obtained using the `getAddNumbersImplPort` method and passing an instance of `javax.xml.ws.AddressingFeature`. The code looks like:

    new AddNumbersImplService().getAddNumbersImplPort(new javax.xml.ws.AddressingFeature());

Similarly, a `Dispatch` instance with Member Submission WS-Addressing can be created as:

    new AddNumbersImplService().createDispatch(
            new QName("http://server.fromjava_wsaddressing/",
                    "AddNumbersImplPort"),
            SOAPMessage.class,
            Service.Mode.MESSAGE,
            new com.sun.xml.ws.developer.MemberSubmissionAddressingFeature());

Feature Parameters

Both `javax.xml.ws.soap.AddressingFeature` and `com.sun.xml.ws.developer.MemberSubmissionAddressingFeature` take two optional Boolean parameters, `enabled` (default true) and `required` (default false). If enabled, all WS-Addressing headers are generated for an outbound message. If `required` is specified true, then WS-Addressing rules are enforced for inbound message. Otherwise the inbound message is inspected to find out if WS-A is engaged and then the rules are enforced.

For example, to enforce Member Submission WS-Addressing rules on the client side, the above code sample will change to:

    new AddNumbersImplService().getAddNumbersImplPort(new com.sun.xml
            .ws.developer.MemberSubmissionAddressingFeature(true, true));

### Explicit disabling

A client may like to instruct &jax-ws.product.name.short; to disable WS-Addressing processing. The assumption is that in this case the client has it's own WS-Addressing processing module. For example, a Dispatch-based client in MESSAGE mode may be used to perform non-anonymous ReplyTo/FaultTo processing.

WS-Addressing processing can be explicitly disabled using one of new methods added to JAX-WS 2.1 specification as defined in Section 3.2. For example, W3C WS-Addressing processing can be disabled using the following code:

    new AddNumbersImplService().getAddNumbersImplPort(new javax.xml.ws.AddressingFeature(false));

## When is WS-Addressing engaged?

W3C WS-Addressing SOAP Binding defines that if a receiver processes a message containing a `wsa:Action` header, then SOAP Binding is engaged, and the rules of the specification are enforced. In &jax-ws.product.name.short;, if WS-Addressing is explicitly disabled then the RI does not follow the rules of engagement. However if WS-Addressing is either implicitly or explicitly enabled then &jax-ws.product.name.short; engages WS-Addressing based upon the presence of `wsa:Action` header. &jax-ws.product.name.short; follows same rule for Member Submission version as well.

In effect, if an endpoint advertises WS-Addressing is required in the WSDL and a client does not send any WS-Addressing header then no WS-Addressing fault is returned back to the client. However if the client send `wsa:Action` header then the endpoint will enforce all the rules of the specification. For example, if the `wsa:MessageID` header is missing for a request/response MEP then a fault with appropriate code and sub-code is thrown back to the client.

## Associating Action with an operation

### Implicit Action

In most common cases, an implicit Action association, as defined by W3C WS-Addressing 1.0 - Metadata and Member Submission, will be sufficient. For such cases, only using the correct annotation to enable Addressing is required. The client looking at such a WSDL will send the implicit `wsa:Action` header. If only Addressing is enabled by using the appropriate annotation at the SEI,

### Explicit Action

This section describes how an explicit Action Message Addressing Property can be associated with an operation in the SEI.

W3C WS-Addressing W3C WS-Addressing 1.0 - Metadata and Member Submission WS-Addressing define mechanisms to associate Action Message Addressing Property with an operation. JAX-WS 2.1 defines `javax.xml.ws.Action` and `javax.xml.ws.FaultAction` annotations to explicitly associate an Action with `input`, `output`, and `fault` messages of the mapped WSDL operation. For example, one of the methods in the `fromjava-wsaddressing` sample looks like:

    @Action(input = "http://example.com/input3", output = "http://example.com/output3",
            fault = {@FaultAction(className = AddNumbersException.class,
            value = "http://example.com/fault3")})
    public int addNumbers3(int number1, int number2) throws AddNumbersException {

        // ...

    }

The generated WSDL fragment looks like:

    <operation name="addNumbers3">
        <input wsam:Action="http://example.com/input3"
                message="tns:addNumbers3"/>
        <output wsam:Action="http://example.com/output3"
                message="tns:addNumbers3Response"/>
        <fault message="tns:AddNumbersException" name="AddNumbersException"
                wsam:Action="http://example.com/fault3"/>
    </operation>

where `wsam` is bound to W3C WS-Addressing 1.0 - Metadata namespace or Member Submission namespace depending upon the annotation used to enable Addressing.