+

Search Tips   |   Advanced Search

Prepare a migrated v6.1 WS-Notification configuration for reliable notification

We can gradually introduce JAX-WS based client and provider entities such that a migrated v6.1 WS-Notification configuration is ready to be configured for reliable notification.

This topic assumes that we have an existing server or cluster installation of WebSphere Application Server v7.0 or later, including at least one WS-Notification service, service point, and underlying service integration bus that has been migrated to this version of the product as described in Migrate a v6.1 WS-Notification configuration from WAS v6.1 to v7.0 or later.

For reliable notification, we apply policy sets that include WS-ReliableMessaging to the WS-Notification configuration. We can only use policy sets with Java API for XML-based Web Services (JAX-WS) applications, and with Version 7.0 WS-Notification services and service points.

The WS-Notification implementation in WAS v6.1 uses service integration bus-enabled web services to expose the WS-Notification service endpoint, so that it can be invoked by applications and configured with specific attributes such as WS-Security or JAX-RPC handlers. However, the v6.1 implementation is not compatible with JAX-WS handlers or applications, and it cannot compose with WS-ReliableMessaging.

To prepare a migrated v6.1 WS-Notification configuration for reliable notification, we must recreate our v6.1 WS-Notification services and service points as v7.0 WS-Notification services and service points, and recreate each JAX-RPC client application to which we want to apply a policy set as a JAX-WS application. Note that we can continue to use JAX-RPC applications with v7.0 WS-Notification services and service points, and that we only have to recreate those applications that must work with policy sets.

For information about coding JAX-RPC and JAX-WS client applications to perform specific WS-Notification tasks, see Developing applications that use WS-Notification. We might also find it useful to learn about JAX-WS and the JAX-WS client programming model. This should help you to determine the effort involved in porting client code from JAX-RPC to JAX-WS, or to validate JAX-WS client to JAX-RPC web service interoperability.

To support a phased approach to preparing for reliable notification, and to describe the four main configurations that we might want to achieve, this task is divided into four subtasks:


Tasks


What to do next

When we have completed these subtasks, we have a collection of WS-Notification client and server entities that are prepared for reliable notification, and we are ready to configure WS-Notification for reliable notification.


Related:

  • WS-Notification
  • WS-Notification and policy set configuration
  • WS-ReliableMessaging default policy sets
  • Use WS-Notification for publish and subscribe messaging for web services
  • Secure WS-Notification
  • Configure a v7.0 WS-Notification service with Web service QoS
  • Manage policy sets
  • Add assured delivery to web services through WS-ReliableMessaging
  • WS-Notification troubleshooting tips


    Use JAX-WS clients and web services with migrated service points


    Tasks

    1. Publish notification messages through a migrated Version 6.1 WS-Notification service point, from a JAX-WS client application.

      1. Create a JAX-WS WS-Notification client application using the WSDL of the migrated service point.

        See Example: Publishing a WS-Notification message, Develop a JAX-WS client from a WSDL file and Publishing the WSDL files for a WS-Notification application to a compressed file.

      2. Run the application.
      3. Initiate one or more notification messages.

      The system accepts and publishes the notification messages from the JAX-WS client.

    2. Receive notification messages in a new JAX-WS based WS-Notification consumer application, from a migrated v6.1 WS-Notification service point.

      This validates that our v6.1 WS-Notification service point can deliver notifications to a JAX-WS consumer web service.

      1. Create a new JAX-WS based WS-Notification consumer web service from the standard WS-Notification WSDL.

        See Example: Subscribing a WS-Notification consumer, Implementing web services applications from existing WSDL files with JAX-WS and Publishing the WSDL files for a WS-Notification application to a compressed file.

      2. Create a subscription for the new consumer service through the v6.1 WS-Notification service point.
      3. Prompt the WS-Notification service point to generate notifications (for example using a WS-Notification client application).

      The system transmits the notifications to the new JAX-WS consumer application correctly.


    Use JAX-RPC clients and web services with new v7.0 WS-Notification service points


    Tasks

    1. Create a new Version 7.0 WS-Notification service.

      We can configure a v7.0 WS-Notification service and service points with policy sets to compose with WS-ReliableMessaging for reliable notification.

      The system creates and configures a new v7.0 WS-Notification service. This includes the creation of a v7.0 WS-Notification service point that exposes the service from a particular service integration bus member. v6.1 and v7.0 WS-Notification service points can coexist in WAS v7.0 or later.
    2. Publish notification messages through the new v7.0 WS-Notification service point, from a JAX-RPC client application.

      This validates the behavior of the v7.0 WS-Notification service point.

      1. Create the application using the WSDL of the new v7.0 WS-Notification service point.

        See Example: Publishing a WS-Notification message, Develop client bindings from a WSDL file for a JAX-RPC Web services client and Publishing the WSDL files for a WS-Notification application to a compressed file.

        Instead of creating a new JAX-RPC client application, we might choose to update an existing JAX-RPC client application from the WSDL of the new service point. The WSDL for a v7.0 WS-Notification service point contains a number of minor changes compared to a v6.1 service point, so we must modify our existing JAX-WS client application to take account of these changes. Specifically, we must regenerate the java proxy classes from the WSDL, and update any use of class names and methods that have changed. For example, there might be changes in the generated classes that include a port type or service from the WSDL.

      2. Run the application.
      3. Initiate one or more notification messages.

      The system accepts and publishes the notification messages from the JAX-RPC client.

    3. Receive notification messages in a JAX-RPC based WS-Notification consumer application, from the new v7.0 WS-Notification service point.

      This validates that our v7.0 WS-Notification service point can deliver notifications to a JAX-RPC consumer web service.

      1. Create a new JAX-RPC based WS-Notification consumer web service from the standard WS-Notification WSDL.

        See Example: Subscribing a WS-Notification consumer, Implementing web services applications from existing WSDL files with JAX-WS and Publishing the WSDL files for a WS-Notification application to a compressed file.

        Instead of creating a new JAX-RPC consumer application, we can use an existing JAX-RPC consumer application from (for example) a v6.1 WS-Notification configuration.

      2. Create a subscription for the new consumer service through the new v7.0 WS-Notification service point.
      3. Prompt the WS-Notification service point to generate notifications (for example using a WS-Notification client application).

      The system transmits the notifications to the new JAX-RPC consumer application correctly.


    Use JAX-WS clients and web services with new v7.0 WS-Notification service points


    Before beginning

    Note that with this configuration we can compose with policy sets for reliable notification.


    Tasks

    1. Publish notification messages through the new v7.0 WS-Notification service point, from a JAX-WS client application.

      1. Create a JAX-WS WS-Notification client application using the WSDL of the new v7.0 WS-Notification service point.

        See Example: Publishing a WS-Notification message, Develop a JAX-WS client from a WSDL file and Publishing the WSDL files for a WS-Notification application to a compressed file.

        Instead of creating a new JAX-WS client application, we might choose to update the JAX-WS client application that we created in the subtask Use JAX-WS clients and web services with migrated service points. The WSDL for a v7.0 WS-Notification service point contains a number of minor changes compared to a v6.1 service point, so we must modify our existing JAX-WS client application to take account of these changes. Specifically, we must regenerate the java proxy classes from the WSDL, and update any use of class names and methods that have changed. For example, there might be changes in the generated classes that include a port type or service from the WSDL.

      2. Run the application.
      3. Initiate one or more notification messages.

      The system accepts and publishes the notification messages from the JAX-WS client.

    2. Receive notification messages in a new JAX-WS based WS-Notification consumer application, from a new v7.0 WS-Notification service point.

      This validates that our v7.0 WS-Notification service point can deliver notifications to a JAX-WS consumer web service.

      1. Create a new JAX-WS based WS-Notification consumer web service from the standard WS-Notification WSDL.

        See Example: Subscribing a WS-Notification consumer, Implementing web services applications from existing WSDL files with JAX-WS and Publishing the WSDL files for a WS-Notification application to a compressed file.

        Instead of creating a new JAX-WS consumer application, we might choose to update the JAX-WS consumer application that we created in the subtask Use JAX-WS clients and web services with migrated service points. The WSDL for a v7.0 WS-Notification service point contains a number of minor changes compared to a v6.1 service point, so we must modify our existing JAX-WS client application to take account of these changes. Specifically, we must regenerate the java proxy classes from the WSDL, and update any use of class names and methods that have changed. For example, there might be changes in the generated classes that include a port type or service from the WSDL.

      2. Create a subscription for the new consumer service through the new v7.0 WS-Notification service point.
      3. Prompt the WS-Notification service point to generate notifications (for example using a WS-Notification client application).

      The system transmits the notifications to the new JAX-WS consumer application correctly.


    Sharing notifications between v6.1 and v7.0 WS-Notification service points


    About this task

    We can configure WS-Notification so that notifications received through migrated v6.1 WS-Notification service points are published through the new v7.0 service. We might want to do this so that (for example) we can receive notifications through existing, unreliable connections then publish them through new connections made reliable through WS-ReliableMessaging. To enable this configuration, the new v7.0 WS-Notification service needs to use the same service integration bus topic space as the migrated v6.1 WS-Notification service. We use a permanent topic namespace to statically define the association between a WS-Notification topic namespace URI and a service integration bus topic space destination. We configure a permanent topic namespace as a property of a WS-Notification service.


    Tasks

    1. Discover which bus topic spaces the migrated v6.1 WS-Notification service is using. If none, create a new permanent topic namespace to connect to a bus topic space. See Modifying a v6.1 WS-Notification service.

    2. Create a new permanent topic namespace for the new Version 7.0 WS-Notification service, that connects to the same bus topic space. See Modifying a v7.0 WS-Notification service.


    Results

    Notifications received by either the new or migrated service point are now published to subscriptions made on either WS-Notification service.