(Part of the CORBA FAQ, Copyright © 1996-99)
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The Notification Service extends the Event Service and adds several new kinds of functionality.
CORBA has defined the Notification Service model that allows applications to send messages to objects in other applications without any knowledge of that receiving objects. The Notification model is an extension to the CORBA Event Service model. Applications that are providing messages to other applications are called suppliers and applications receiving the messages supplied are called consumers.
The suppliers and consumers are completely decoupled thus having no knowledge of their location. In addition, suppliers have no idea of how many consumers are listening to the messages being supplied.
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The Notification model uses an architectural element called an event channel which allows messages to be transfered between suppliers and consumers.
Consumers register with the event channel and express an interest of certain events. The channel receives events from suppliers and forwards the events to the interested consumers for that event. Suppliers and Consumers connect to the event channel and not directly to each other.
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The Notification Service extends the Event Service in two areas:
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The Quality of Service, or QoS, allows you to set and tune your service to the demands of your business. Notification defines the following QoS properties:
These properties can be applied at cartain levels of the Notification service:
The QoS is a very powerful extension that allows you to modify the service according to your requirements both from an administrative and an application requirement perspective.
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
It depends on what your business requirements dictate. We can see a need for Notification in a scenario where you are interested in receiving certain information which another source owns.
The example that always comes to mind is the stock market. Information about stocks flows rapidly, and frequently. This information can be supplied through a Notification channel to which many consumers can register their interest in certain stocks. As new information about the stocks is collected, a supplier can push that information to the Notification channel which will pass this information to all the interested consumers on that channel.
There are many more examples but the bottom line here is that it can be used in a variety of scenarios and they will have to be analyzed to see where Notification fits in.
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
Notification events are defined using standard IDL. There are two types of events:
Structured events provide a well-defined data structure into which messages can be inserted and sent to interested consumers. Messages can be defined using standard IDL structs and provide, both consumers and suppliers, with a much strongly typed event. In addition, a sequence of these events can be transmitted between suppliers and consumers that can increase the efficiency of communications between them. With the sequence you can batch any number of events and trasmit them all at once.
Structured Events can constain all IDL types that are defined in the standard IDL. Here’s an example:
struct Message
{
long messageType;
string messageBody;
};
typedef sequence<Message> MessageSeq;
Suppliers would fill the contents of this messages and supply them to interested consumers that have registered with the notification channel.
The untyped event is simply a CORBA::any into which the event is inserted and sent to consumers. So the above example can be inserted into the CORBA::Any type and sent to any consumers on the channel.
[ Top | Bottom | Previous section | Next section ]
[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]
Yes. You will have to do this within your program but the concept becomes clear once you have done it. The way you do the federation is to create two channels and essentially connect them together logically. The consumer proxy of one channel, channel A, is supplied to the supplier proxy of the other channel, channel B. The reverse is done with the supplier proxy of channel B where it’s exchanged with channel A and voila we are now federated.
So essentially what you have is a channel that becomes a consumer and which will forward the events to its consumers.
[ Top | Bottom | Previous section | Next section ]
E-mail us