WebSphere brand IBM WebSphere Telecom Web Services Server, Version 7.1

PX Notification component Web service

The PX Notification component Web service provides facilities for notification delivery to the requester endpoint directly or through the Access Gateway.

This component also provides an asynchronous model for invocation, in which an application can send a notification, continue its processing without blocking, and then receive a delivery confirmation. This feature is not configurable from the end user standpoint, and is only configurable from the Web service point of view. It supports all services having notification operations.

For more information about the PX Notification component Web service, refer to the topic Planning for notification in this information center.

Retry mechanism

A retry mechanism has been added to the notification delivery of several Parlay X services that retries the endpoint for a configurable number of times, before logging a failure. Generally, retry occurs when the HTTP code returned for the endpoint is 404 or 503. Specifically, retry happens under the following scenarios:
  • In the absence of an ESB endpoint, when the requester's endpoint is down.
  • In the presence of an ESB endpoint, if the endpoint is valid and is down.
The following are possible valid endpoints:
  • An ESB endpoint of the same application. For example, if you are using an SMS application, it may be the SMS application's ESB endpoint.
  • An ESB endpoint of other applications. For example, if you are using an MMS application, it may be the ESB endpoint of the TL application.
  • Any other URI where some service must be present at the specified location and port (except the endpoint of a service implementation component).
The retry is done at the PXNotification component scope and is done as long as the endpoint URI is not accessible and the retry count is not exhausted. A retry delay is also configurable for the pause time between the retries. However, the retry is not persistent. If the database, application, or cluster node goes down, the retry state will not be saved and continued from where it left. Instead, it will start again from the beginning.
Note: The retry does not apply to faults within the ESB notification flow. Such faults will be logged.

Delivery mode options

Three delivery mode options indicate how the notification needs to be conveyed to the requester endpoint. This is usually set by the Web service implementations and can be overridden at the PX Notification component level.

The following are the delivery mode options:
  • Inline: A single thread of execution from the service implementation to the endpoint (ESB or requester).
  • Asynchronous: The service implementation hands over the request to the PX Notification component, which in turn places the request in a JMS queue. The service implementation is not blocked for a response from the endpoint. Delivery confirmation can be obtained using the Delivery Confirmation Callback interface.
  • Mode set by the service implementation: This is the default option. The delivery mode is usually set by the Web service implementation and can be overridden at the PX Notification component level. Therefore, whatever delivery mode (Inline or Asynchronous) is chosen by the service implementation is used by the PX Notification component.
Table 1. Delivery modes used by the services
Parlay X service implementations Delivery mode used for notification delivery through PX Notification
Terminal Location/Parlay Inline
Terminal Status/Parlay Asynchronous
Call Notification/Parlay Inline
SMS/Parlay and SMS/SMPP Inline
Call Notification/SIP Asynchronous
Presence/SIP Asynchronous
Terminal Status/SIP Asynchronous
MMS/MM7 Inline
Terminal Location/MLP Inline



Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.