Overview

This topic includes the following sections:

•	Introduction

•	Functional Overview

•	Product Components

Introduction

The Notification Service provides an event service for the Oracle Tuxedo CORBA environment. It is not meant to be a standalone product, but rather a layered product on Oracle Tuxedo.

The Notification Service offers similar capabilities to those of the Oracle Tuxedo EventBroker, but with a programming model and interface that is natural for CORBA users. A side effect of this approach is that the majority of the CORBA-based Notification Service is not supported since it is either incompatible with, or provides capabilities well beyond that of the Oracle Tuxedo EventBroker.

The Notification Service is an Oracle Tuxedo subsystem that receives event posting messages, filters them, and distributes them to subscribers. A poster is an Oracle Tuxedo CORBA application that detects when an event of interest has occurred and reports (posts) it to the Notification Service. A subscriber is an Oracle Tuxedo CORBA application that requests that some notification action be taken when an event of interest is posted.

The concept of an “anonymous” service—the Notification Service—that receives and distributes messages provides another client-server communication paradigm to Oracle Tuxedo CORBA environment. Instead of a one-to-one relationship between a requester and a provider, an arbitrary number of posters can post a message for an arbitrary number of subscribers. The posters simply post events, without knowing who receives the information or what is done about it. The subscribers can receive whatever information they are interested in from the Notification Service, without knowing who posted it, and subscribers can be notified and take action in a variety of ways.

Typically, Notification Service applications are designed to handle exception events. The application designer has to decide what events in the application need to be monitored. In a banking application, for example, an event might be posted for an unusually large withdrawal transaction; but it would not be particularly useful to post an event for every withdrawal transaction. And not all users would need to subscribe to that event; perhaps just the branch manager, would need to be notified.

The programming model for the Notification Service is based on the CORBA programming model. There are two sets of interfaces: one is a minimal subset of the CORBA-based Notification Service interface (referred to in this document as the CosNotification Service interface), and the other is the Oracle Simple Events interface (an Oracle proprietary interface) designed to be easy to use. Both interfaces pass standard, structured events, as defined by the CORBA-based Notification Service specification.

The two interfaces are compatible with each other; that is, events posted using the CosNotification Service interface can be subscribed to by the Oracle Simple Events interface and vice versa.

Functional Overview

The Notification Service system comprises three basic components (see Figure 1‑1):

•	The event poster, or supplier.

The supplier is the producer of events. It creates events and posts them to the Notification Service.

•	The Notification Service, also known as the event channel.

The Notification Service processes events.

•	The event subscriber, or consumer.

The consumer is the recipient of the events. It connects to the Notification Service and subscribes to some set of events.

When the Notification Service receives an event that matches a consumer’s subscription, it attempts to deliver the event to that consumer. There can be many suppliers and consumers. Logically, there is only one Notification Service, even though the Notification Service can be replicated.

Figure 1‑1 Notification Service Model

 

According to the CORBA-based Notification Service specification, event posters always use the push model. Thus, event posters push events to the Notification Service by invoking an operation. The Notification Service takes responsibility for filtering and delivering the event. There is no direct association between event posters and event subscribers. At any point in time there may be zero, one, or many event posters or event subscribers.

Also, according to the CORBA-based Notification Service specification, subscribers can select one of two event delivery models, push or pull. Only the push model is supported in this release of Oracle Tuxedo. Thus, the Notification Service pushes events to the consumer by invoking an operation on the consumer. Depending on the Quality of Service (QoS) of the matching subscription, the event might be stored durably, pending delivery to the consumer.

Product Components

The Oracle Tuxedo CORBA Notification Service supports the following:

•	An Oracle Simple Events application programming interface (API) for ease-of-use.

•	A minimal set of operations defined by the CosNotification Service API.

•	Two Qualities of Service (QoS) for subscriptions: transient and persistent.

For transient subscriptions, the Notification Service makes only one attempt to deliver the event to a subscriber. If that attempt fails, the event is discarded and if the Notification Service determines that the subscriber is shutdown or otherwise not available, the subscription is cancelled.

For persistent subscriptions, if the first delivery attempt fails, the Notification Service holds the event and keeps attempting to deliver the subscription until the configurable retry limit is reached. After the retry limit is reached, the Notification Service moves the event to an error queue, where it is held for disposition by the system administrator. The system administrator either removes the event from the error queue, which in effect discards it, or moves it back to the pending queue so that further attempts to deliver it can be made.

•	Using the UBBCONFIG file for initial configuration of the system, event queues, and server processes.

•	Using the Oracle Tuxedo style FML field tables. Through the use of FML field tables, the Notification Service can support:

•	Event data filtering between event posters and event subscribers.

•	Interoperability with Oracle Tuxedo EventBroker such that events posted by the Notification Service can be consumed by the Tuxedo EventBroker and vice versa.

•	Using the following Oracle Tuxedo Notification Service servers to process events:

•

TMNTS

•	TMNTSFWD_P

•	TMNTSFWD_T

•	Using the following Oracle Tuxedo system servers to process events:

•

TMSYSEVT

•

TMUSREVT

•

TMQUEUE

•	TMQFORWARD

•	Using the Oracle Tuxedo ntsadmin administrative utility to manage event queues.

•	Using the Oracle Tuxedo qmadmin administrative utility to configure and manage event queues.

•	Using the Oracle Tuxedo tmadmin administrative utility to configure and manage transaction logs.