The Worldwide Web Consortium (W3C) Web Services Addressing (WS-Addressing) specification explicitly defines the WS-Addressing core properties for the message exchange patterns (MEPs) that are defined by WSDL 1.0. These MEPs are summarized in this topic, illustrating the mandatory WS-Addressing properties for each pattern.
<operation name="myOperation"> <input message="tns:myInputMessage"/> </operation>
Abstract WS-Addressing MAP name, using the notational convention of the W3C XML Information Set | Default value for a one-way input message |
---|---|
[action] | The WS-Addressing action that is generated in accordance with the version of the WS-Addressing specification that is in use. |
[reply endpoint] | The WS-Addressing reply endpoint indicating that no replies are expected to this input message. The value of this MAP depends on the version of the WS-Addressing specification that is in use. |
[message id] | A uniquely generated message identifier. Although not mandated by the specification, the WebSphere® Application Server run time automatically sets this value. |
Although the WSDL operation for this message exchange does not specify any responses, related messages can be sent as part of other message exchanges. In particular, applications can use the WS-Addressing reply endpoint or fault endpoint MAPs to indicate to the target of a one-way message where to send related messages. To propagate a reply endpoint or fault endpoint, associate the appropriate property with the request context for the JAX-WS BindingProvider object, or with the JAX-RPC Stub or Call object, as described in Specifying and acquiring message-addressing properties by using the IBM proprietary Web Services Addressing SPIs, to override the defaults.
<operation name="myOperation"> <input message="tns:myInputMessage"/> <output message="tns:myOutputMessage"/> <fault="tns:myFaultMessage"/> </operation>
<operation name="myOperation"> <input message="tns:myInputMessage"/> <output message="tns:myOutputMessage"/> </operation>
<operation name="myOperation"> <input message="tns:myInputMessage"/> <fault="tns:myFaultMessage"/> </operation>
Abstract WS-Addressing MAP name, using the notational convention of the W3C XML Information Set | Default value for the input message of a request-response operation |
---|---|
[action] | The WS-Addressing action that is generated in accordance with the version of the WS-Addressing specification that is in use. |
[message id] | A uniquely generated message identifier. |
Abstract WS-Addressing MAP name, using the notational convention of the W3C XML Information Set | Default value for the input message of a request-response operation |
---|---|
[action] | The WS-Addressing action that is generated in accordance with the version of the WS-Addressing specification that is in use. |
[relationship]* | A relationship set containing a reply relationship to the message id that is passed in the request message. |
[message id] | A uniquely generated message identifier; although not mandated by the specification, the application server run time automatically sets this property. |
For JAX-WS synchronous invocations, if you set the reply endpoint or the fault endpoint, the endpoint reference that you set must use the anonymous URI. If the endpoint reference does not use the anonymous URI, a javax.xml.ws.WebServiceException exception is thrown. Although the endpoint reference uses the anonymous URI, you can use reference parameters within the endpoint reference to target the reply or fault endpoint.
The JAX-RPC 1.0 programming model does not allow for asynchronous replies or faults to a two-way request-response operation.
For JAX-WS asynchronous invocations, the reply endpoint is generated automatically for use by the JAX-WS implementation. If you attempt to set either a reply endpoint or a fault endpoint , a javax.xml.ws.WebServiceException exception is thrown.
For JAX-WS applications, you can specify an asynchronous message exchange pattern by applying and configuring a WS-Addressing policy type. This exchange pattern is particularly useful if a JAX-WS endpoint has a long-running invocation time. Client and server resources are used to keep the connection open, but this use of resource might be impractical if the service takes a long time to respond. You can ensure that clients are aware of the requirement for asynchronous messaging by enabling WS-Policy.