HP NonStop G-Series - Manual (Page 87)

{
e.printStackTrace();
System.err.println(e);
}
}
}
Event Subscription and Notifications
Programmers developing client applications using Jolt can receive event notifications from either TUXEDO Services or other TUXEDO
clients. The Jolt Class Library contains classes that support the following types of TUXEDO notifications for handling event-based
communication:
Unsolicited Event Notifications. These are notifications that a Jolt client receives as a result of a TUXEDO client or service issuing
a broadcast using either a tpbroadcast() or a directly targeted message via a tpnotify() ATMI call. ●
Brokered Event Notifications. These notifications are received by a Jolt client via the TUXEDO Event Broker. The notifications
are only received when both the Jolt client subscribes to an event and any TUXEDO client or server issues system posted event or a
tppost() call. ●
API for Event Subscription
The Jolt Class Library provides four classes that implement the asynchronous notification mechanism for Jolt client applications. These
classes are:
JoltSession. The JoltSession class includes an onReply() method for receiving notifications and notification messages. ●
JoltReply. The JoltReply class gives the client application access to any messages received with an event or notification. ●
JoltMessage. The JoltMessage class provides get methods for obtaining information about the notification or event. ●
JoltUserEvent. The JoltUserEvent class supports subscription to of both unsolicited and event notification types. ●
For more information about these classes refer to Section 7, Jolt Class Library Reference .
Notification Event Handler
For both unsolicited notifications and a brokered event notification, the Jolt client application requires an event handler routine that is
invoked upon receipt of a notification. The Jolt 1.1 release only supports a single handler per session. In current TUXEDO versions, it is
not possible to determine which event generated a notification. Thus it is not possible to invoke an event-specific handler based on a
particular event.
The client application must provide a single handler (by overriding the onReply() method) per session that will be invoked for all
notifications received by that client for that session. The single handler call-back function is used for both unsolicited and event
notification types. It is up to the (user supplied) handler routine to determine what event caused the handler invocation and take
appropriate action. If the user does not override the session handler, then notification messages are silently discarded by the default
handler.
The Jolt client provides the call back function by subclassing the JoltSession class and overriding the onReply() method with a
user-defined onReply() method.
In TUXEDO/ATMI clients, processing in the handler call-back function is limited to a subset of ATMI calls. This restriction does not
apply to Jolt clients. Separate threads are used to monitor notifications and run the event handler method. A Jolt client will be able to
perform all Jolt-supported functionality from within the handler. All the rules that apply to a normal Jolt client program apply to the
handler, such as a single transaction per session at any time.
Each invocation of the handler method takes place in a separate thread. The application developer should ensure that the onReply()
method is either synchronized or written thread-safe, since separate threads could be executing the method simultaneously.
Subscribing to Event Notifications Enables Unsolicited Notifications
Jolt uses an implicit model for enabling the handler routing. When a client subscribes to an event, Jolt will internally enables the handler
for that client, thus enabling unsolicited notifications as well. A Jolt client cannot subscribe to event notifications without also receiving
unsolicited notifications. In addition, a single onReply() method is invoked for both types of notifications.