Enabling Web Services Addressing support for JAX-WS applications

The Web Services Addressing (WS-Addressing) support provides mechanisms to address Web services and provide addressing information in messages. For JAX-WS applications, you can enable WS-Addressing support in several different ways, such as configuring policy sets or using annotations in code.

About this task

New feature: This release introduces a new way to enable WS-Addressing. You can now use JAX-WS 2.1 annotations and feature classes to enable WS-Addressing from either the server or the client. You also have more control over the behavior of WS-Addressing when using policy sets; you can specify whether WS-Addressing is enabled and whether to use synchronous, asynchronous, or both messaging patterns.newfeat

Perform this task to enable the WS-Addressing support, either as a service provider or as a client of a service provided by another party. This task also describes how to disable the WS-Addressing support, which can improve performance for those applications that do not use WS-Addressing or any protocol that depends on the WS-Addressing support.

For service providers, WS-Addressing support is enabled by default, so you do not have to undertake any actions to enable support. However, you can use the enabling mechanisms to modify other WS-Addressing behavior for the service, such as whether WS-Addressing information is required, and what is included in the generated WSDL document.
  • Modify the behavior of the WS-Addressing support after the application is deployed by attaching a policy set to the application. Within the policy set, you can configure the WS-Addressing policy type to specify whether WS-Addressing information is required in incoming messages, and whether to use synchronous or asynchronous messaging. You can communicate the WS-Addressing policy configuration to other servers and clients that support WS-Policy, by enabling policy sharing on the server, and by applying the provider policy on the client. This method overrides other methods.
  • Modify the behavior of the WS-Addressing support during development of the service by using the Addressing or SubmissionAddressing annotations in the service code. Within each annotation you can specify whether the server requires WS-Addressing information in incoming messages. The presence of the Addressing annotation in the code also adds a UsingAddressing element to any WSDL document that is generated for the service. If you provide your own WSDL document instead of relying on the JAX-WS runtime environment to generate one, you must include the UsingAddressing element yourself, if required.
For service clients, WS-Addressing support is disabled by default. Use one of the following methods to enable WS-Addressing support:
  • Attach a policy set to the client artifact and perform one of the following actions:
    • Specify in the policy that WS-Addressing is mandatory.
    • Apply both client and provider policies. In this situation, WS-Addressing support is enabled on the client only if policy sharing is enabled on the service provider and the policy configuration for the provider specifies that WS-Addressing is mandatory.
    This method overrides other methods.
  • Use addressing features in the client code. Settings set by using this method override those set in the WSDL document for the service.
  • Set the com.ibm.websphere.webservices.use.async.mep property on the client request context.
  • Use any option available to JAX-RPC applications:
    • Specify the UsingAddressing element in the WSDL document for the service. If the service uses the Addressing annotation and you generate the WSDL document from the code, the UsingAddressing element already exists.
      Note: This method does not apply to Dispatch clients.
    • Use the IBM proprietary WS-Addressing SPI to add message-addressing properties to the message request context.

The following tables summarize the behavior of the WS-Addressing support.

Use the following table to determine whether a request message is accepted for client settings that do not involve policy configuration.
Table 1. How client and provider settings interact to determine whether a request message is accepted.
Client settings Provider policy settings Provider WSDL settings (UsingAddressing required attribute)
WS-Addressing is optional WS-Addressing is mandatory1
WS-Addressing support enabled Messaging style Synchronous and asynchronous Synchronous only Asynchronous only Synchronous and asynchronous Synchronous only Asynchronous only false (WS-Addressing is optional) true (WS-Addressing is mandatory1)
Yes (WS-Addressing headers are present) Synchronous Message accepted Message accepted Fault Message accepted Message accepted Fault Message accepted Message accepted
Asynchronous Message accepted Fault Message accepted Message accepted Fault Message accepted Message accepted Message accepted
No (WS-Addressing headers are absent) Synchronous Message accepted Message accepted Message accepted2 Fault Fault Fault Message accepted Fault
Asynchronous3 Fault Fault Fault Fault Fault Fault Fault Fault
Notes:
  1. If WS-Addressing is mandatory, all requests without WS-Addressing headers are rejected.
  2. The messaging style is only enforced if WS-Addressing headers are present in the request.
  3. Asynchronous messaging is not possible without WS-Addressing headers.
Use the following table to determine whether a request message is accepted when the client and provider both have a WS-Addressing policy configuration, the client has provider and client policies applied, and policy sharing is enabled on the server.
Table 2. How client and provider policy settings interact to determine whether a request message is accepted.
Client policy settings Provider policy settings
WS-Addressing is optional WS-Addressing is mandatory
Synchronous and asynchronous Synchronous only Asynchronous only Synchronous and asynchronous Synchronous only Asynchronous only
WS-Addressing is optional Synchronous and asynchronous Message accepted Message accepted Message accepted Message accepted Message accepted Message accepted
Synchronous only Message accepted Message accepted Message accepted1 Message accepted Message accepted Fault
Asynchronous only2 Fault Fault Fault Message accepted Fault Message accepted
WS-Addressing is mandatory Synchronous and asynchronous Message accepted Message accepted Message accepted Message accepted Message accepted Message accepted
Synchronous only Message accepted Message accepted Fault Message accepted Message accepted Fault
Asynchronous only Message accepted Fault Message accepted Message accepted Fault Message accepted
Notes:
  1. The messaging style is only enforced if WS-Addressing headers are present in the request.
  2. Asynchronous messaging is not possible without WS-Addressing headers.
If the provider and client policies are not shared, the client does not send WS-Addressing headers (unless you enable WS-Addressing on the client by another method). In this situation, if the provider policy specifies that WS-Addressing is mandatory, the server generates a fault regardless of the messaging style.

Procedure

Results

WS-Addressing properties are now included in the SOAP message header, and are processed by the server on receipt of the message.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Oct 20, 2010 11:50:58 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-base-iseries&topic=twbs_wsa_dep_jaxws
File name: twbs_wsa_dep_jaxws.html