WAS v8.5 > Reference > Developer best practices

WS-ReliableMessaging: supported specifications and standards

WebSphere Application Server provides support for two levels of the WS-ReliableMessaging specification. This gives compatibility with vendors that provide WS-ReliableMessaging support at the February 2005 level, as well as meeting the requirements of the current OASIS specification. This implementation of WS-ReliableMessaging also composes with many other web services standards.

Details of the supported WS-ReliableMessaging specifications are available at the following web addresses:

Support for the WS-ReliableMessaging standard was first introduced as part of the IBM WAS v6.1 Feature Pack for Web Services. At that time, the Reliable Asynchronous Messaging Profile (RAMP) v1.0 specification used WS-ReliableMessaging to ensure the reliable delivery of messages, and the Feature Pack for Web Services in WAS v6.1 included default policy sets that support this specification. We can migrate WAS v6.1 WS-ReliableMessaging configurations that use RAMP-based policy sets to the current version of the product.

Following on from the RAMP v1.0 specification, the Web Services Interoperability organization (WS-I) Reliable Secure Profile working group has developed v1.0 of an interoperability profile dealing with secure, reliable messaging capabilities for web services. This profile is similar to RAMP v1.0, except that it is updated to use WS-ReliableMessaging v1.1 with the OASIS WS-SecureConversation v1.3 specification. The WS-I RSP default policy sets provided in this version of WAS are an implementation of the Reliable Secure Profile v1.0 specification.

The extent to which WS-ReliableMessaging composes with other web services standards is described in the following sections:


WS-Addressing

The WS-ReliableMessaging specification uses WS-Addressing, and the implementation fully supports the asynchronous request and reply model given in the WS-Addressing specification.

WS-ReliableMessaging v1.1 messaging requires WS-Addressing to be mandatory. If we use a policy set that includes WS-ReliableMessaging and WS-Addressing policies, and the WS-Addressing policy is configured as optional, then WAS overrides the WS-Addressing setting and automatically enables WS-Addressing.


WS-AtomicTransactions

WS-ReliableMessaging transactions do not use the WS-AtomicTransactions protocol. The relationship between these two protocols is as follows:

For more information about WS-AtomicTransactions, see Transaction support in WAS. For more information about using WS-ReliableMessaging transactions, see Providing transactional recoverable messaging through WS-ReliableMessaging.


WS-MakeConnection

WS-ReliableMessaging v1.1 uses the WS-MakeConnection protocol to enable synchronous message exchange. For more information about this protocol, see the WS-MakeConnection specification v1.1, February 28 2008.

WS-MakeConnection uses information contained in WS-Addressing message headers, so for any application that uses reliable synchronous message exchange you must include both WS-ReliableMessaging and WS-Addressing policy in the policy set.


WS-Notification

If you create JAX-WS based WS-Notification services, we can apply WS-ReliableMessaging policies to them to make your WS-Notification services reliable. For more information, see Configure WS-Notification for reliable notification.

In this release, there are two types of WS-Notification service:


WS-Policy

The WS-Policy implementation in WAS supports Web Services Reliable Messaging Policy Assertion v1.0 and Web Services Reliable Messaging Policy Assertion v1.1.

We can use the WS-Policy protocol to exchange policies in standard format. We can communicate the policy configuration to any other client, service registry or service that supports the WS-Policy specification, including non-WAS products in a heterogeneous environment. For a service provider, the policy configuration can be shared in published WSDL. For a client, the client can obtain the policy of the service provider in the standard WS-PolicyAttachments format and use this information to establish a configuration that is acceptable to both the client and the service provider. In other words, the client can be configured dynamically, based on the policies supported by its service provider.

At any stage - that is, before or after we have built your reliable web service application, or configured your policy sets - we can set a property that configures endpoints to only support clients that use reliable messaging. This setting is reflected by WS-Policy if engaged.


WS-SecureConversation

WS-ReliableMessaging is designed to work with WS-SecureConversation. A secure conversation context is established and this is used to secure the application messages and the WS-ReliableMessaging protocol messages.

To use WS-SecureConversation, create or apply a policy set that includes both WS-ReliableMessaging and WS-SecureConversation. For example, either of the WS-I RSP default policy sets.


WS-Security

WS-ReliableMessaging composes with WS-Security. The WS-ReliableMessaging headers appended to application messages are signed if required. The WS-ReliableMessaging protocol messages are signed and encrypted if required.

Security processing is done close to the transport: after WS-ReliableMessaging processing at the web service requester and before WS-ReliableMessaging processing at the web service provider. This means the messages held in the WS-ReliableMessaging store are not signed and encrypted, so the emphasis is on the administrator to secure the store, if the store being used is the messaging engine in a service integration bus.

If possible, use WS-SecureConversation rather than WS-Security because the WS-SecureConversation protocol is less susceptible to security attacks.


Related


Configure endpoints to only support clients that use WS-ReliableMessaging
Add assured delivery to web services through WS-ReliableMessaging
Detecting and fixing problems with WS-ReliableMessaging


+

Search Tips   |   Advanced Search