![BEA BEA Tuxedo Release [Release Number]](../images/top.gif)
|
|
|
|
|
|
Overview
This topic includes the following sections:
Introduction
The Notification Service provides an event service for the BEA Tuxedo CORBA environment. It is not meant to be a standalone product, but rather a layered product on BEA Tuxedo.
The Notification Service offers similar capabilities to those of the BEA 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 BEA Tuxedo EventBroker.
The Notification Service is a BEA Tuxedo subsystem that receives event posting messages, filters them, and distributes them to subscribers. A poster is a BEA Tuxedo CORBA application that detects when an event of interest has occurred and reports (posts) it to the Notification Service. A subscriber is a BEA 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 BEA 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 BEA Simple Events interface (a BEA 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 BEA Simple Events interface and vice versa.
Functional Overview
The Notification Service system comprises three basic components (see Figure 1-1):
The supplier is the producer of events. It creates events and posts them to the Notification Service.
The Notification Service processes events.
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 BEA 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 BEA Tuxedo CORBA Notification Service supports the following:
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.
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|