ARE THERE MORE THAN ONE TYPE OF EVENT SERVICE?
The Event
Service specification supports two types of event reception. One is push and
one is pull. The push model allows consumers to receive ongoing events by just connecting.
The pull model requires that the consumer poll for all events sent to the
channel since the last pull. The Event service also allow
the events to be either typed or in typed. In the typed model, the Event
service ensures that the channel support a specific IDL datatypes.
In the untyped model the Chnnel
distributes events as an ANY. In this case, it is up to the consumer to enforce
type safety.
WHAT
IS THE QUALITY OF SERVICE PROVIDED BY THE EVENT SERVICE?
The Event
Service specification does not require a specific quality of service. It is up
to the implementor of the event service to determine
what the provided level is. For example, an event service implentation
may ensure that events are deliver even if some piece
to the event service fails. An event service could also support transactional
events using OTS. An event service could also provide deliver via a non IIOP
transport such as UDP broadcast or multicast. This could, of course, limit
interoperability. An event service could also ensure that connections to a
channel are persistent. This would mean that consumers would not have to
re-connect if the server failed and then came back online.
WHAT
IS NOTIFICATION SERVICE?
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.
HOW
DOES THE NOTIFICATION SERVICE WORK?
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.
HOW
DOES THE NOTIFICATION SERVICE EXTEND THE EVENT SERVICE?
The
Notification Service extends the Event Service in two areas:
Event
Filtering - Event filtering allows that Notification channel to deliver only
certain types of events to interested consumers. In the much simpler Event
Service model all events are sent to all consumers.
Quality of
Service - Quality of Service (QoS) allows an
applications to change some of the elements defined in the Notification
Channel, such as event delivery.
WHAT
DOES THE QUALITY OF SERVICE GIVE ME?
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:
• Reliability
• Priority
• Expiery
Time
• Earliest delivery time
• Order policy
• Discard policy
• Maximum batch size
• Pacing interal
• Proxy push supplier properties
• These properties can be applied at
cartain levels of the Notification service:
• Notification Channel
• Supplier or Consumer admin objects
• Proxy suppliers and consumers
• Individual event messages
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.
No comments:
Post a Comment