OMG Event Service Distributed Object Systems and Technology COMP4111
Jan 15, 2016
OMG Event Service
Distributed Object Systems and Technology COMP4111
Presenters
Dean Adamson Håvard Frøiland Simon Pett
Introduction
Monitoring Problems with Client/Server– Client either blocks or polls the server– Increase overhead from the server– Polling creates increased traffic– Client and Server tightly Coupled– Reduces Scalability
What is the Event Service?
It is a service which:– Decouples Clients from Servers by the use of a
Event Channel– Clients are regard as Consumers and Servers as
Suppliers
It provides:– Suppliers a means of sending messages to one or
more consumers with a single call without needing a reference to the consumer. It does this by sending a message through the Event Channel
Event Channel
Supplier produce events Consumers receives events The Event Channel conveys events from the
supplier to the consumer. Thus the Supplier doesn’t need to know anything about the Consumer
Suppliers and Consumers must register to the Event Channel to send or receive events
Different Event Service Models
There are four different Event Service Models– Canonical Push– Canonical Pull– Hybrid Push/Pull– Hybrid Pull/Push
Canonical Push
ConsumerConsumer
SupplierSupplier
Event ChannelEvent ChannelConsumerConsumer
ConsumerConsumer
SupplierSupplierpush
push
push
push
push
• Supplier pushes events to the event channel• Event Channel then Pushes the Event to the consumer• The Supplier is the active initiator and the consumer is the passive receiver• The Event channel plays the role of the notifier
Direction of Event
Canonical Pull Model
• The Consumer pulls events from the Event channel• The Event Channel then pulls the events from the Supplier• Consumers are the active initiators• Suppliers are the passive senders• The Event Channel plays the role of the procurer
ConsumerConsumer
SupplierSupplier
Event ChannelEvent ChannelConsumerConsumer
ConsumerConsumer
SupplierSupplierpull
pull
pull
pull
pull
Direction of Event
Hybrid Push/Pull
• The Supplier pushes the events to the Event Channel• Consumers pull the events from the Event Channel• Both Suppliers and Consumers are active • The Event Channel acts as a queue
ConsumerConsumer
SupplierSupplier
Event ChannelEvent ChannelConsumerConsumer
ConsumerConsumer
SupplierSupplierpush
push
pull
pull
pull
Direction of Event
Hybrid Pull/Push
• The Event Channel pulls events from the Supplier • The Event Channel then pushes the event to the Consumer• Both the Supplier and the Consumer are passive• The Event Channel acts as the event controller, i.e. controls the movement of the events
ConsumerConsumer
SupplierSupplier
Event ChannelEvent ChannelConsumerConsumer
ConsumerConsumer
SupplierSupplierpull
pull
push
push
push
Direction of Event
Mixing Event Models
• The four model can be mixed in any combination• An Event Channel can support all four models simultaneously i.e. Each Supplier Consumer pair may chose different model through the one Event Channel• Consumers and Supplier are decoupled because none of them need to know whether the other is pushing or pulling
ConsumerConsumer
SupplierSupplier
Event ChannelEvent ChannelConsumerConsumer
ConsumerConsumer
SupplierSupplierpush
pull
push
pull
push
Direction of Event
Event Service Interface
The event channel Push model interface Pull model interface
The Event Channel
The event channel presents itself as a consumer to suppliers and as a supplier to consumers
Proxy interface Decoupled communications
Interfaces for the Push Model (1)
How to push data?module CosEventComm{
exception Disconnected{};interface PushConsumer{
void push(in any data)
raises(Disconnected);void
disconnedct_push_consumer(); }; interface PushSupplier{
void disconnect_push_supplier();};//...
};
Interfaces for the Push Model (2)
Supplier and consumer can disconnect from an event channel
module CosEventComm{exception Disconnected{};interface PushConsumer{
void push(in any data)
raises(Disconnected);void
disconnedct_push_consumer(); }; interface PushSupplier{
void disconnect_push_supplier();};//...
};
Interfaces for the Push Model (3)
Exception if supplier push on a disconnected consumer
module CosEventComm{exception Disconnected{};interface PushConsumer{
void push(in any data)
raises(Disconnected);void
disconnedct_push_consumer(); }; interface PushSupplier{
void disconnect_push_supplier();};//...
};
Sending data
Data is sent in form of an any Consumer either knows what type to expect in
the any or check it dynamically using the DynAny interface
Interfaces for the Pull Model (1)
Pull() will block until the supplier wants to deliver something
module CosEventComm{interface PullSupplier{
any pull() raises(Disconnected);
any try_pull(out boolean has_event) raises(Disconnected);void
disconnect_pull_supplier();};interface PushConsumer{
void disconnect_pull_consumer();};//...
};
Interfaces for the Pull Model (2)
We can instead of the blocking method pull use try_pull
module CosEventComm{interface PullSupplier{
any pull() raises(Disconnected);
any try_pull(out boolean has_event) raises(Disconnected);void
disconnect_pull_supplier();};interface PushConsumer{
void disconnect_pull_consumer();};//...
};
Interfaces for the Pull Model (3)
Exceptions
Disconnect
This is similar to the push model
module CosEventComm{interface PullSupplier{
any pull() raises(Disconnected);
any try_pull(out boolean has_event) raises(Disconnected);void
disconnect_pull_supplier();};interface PushConsumer{
void disconnect_pull_consumer();};//...
};
The Event Channel Interface
1. Implement a servant for your push consumer or pull supplier. Both push suppliers and pull consumers are clients, so you do not need to implement servants for those cases.
2. Obtain a reference to the event channel.
The Event Channel Interface
3. Get a ConsumerAdmin reference from the EventChannel if you want to register a consumer, or get a SupplierAdmin reference if you want to register a supplier.
The Event Channel Interface
4. Obtain the proxy object reference. The type of proxy object will depend on what event model you want to use.
5. Invoke the appropriate connection operation on the proxy object.
Interfaces for the Event Channel (1)
(3) Get a ConsumerAdmin or a SupplierAdmin reference from the event channel
interface EventChannel{ConsumerAdmin for_consumers();SupplierAdmin for_suppliers();void destroy();
};
Interfaces for the Event Channel (2)
(4) When we have a “Admin” reference we can obtain the “proxy type” we want
interface SupplierAdmin{ProxyPushConsumer obtain_push_consumer();ProxyPullConsumer obtain_pull_consumer();
}; interface ConsumerAdmin{
ProxyPushSupplier obtain_push_supplier();ProxyPullSupplier obtain_pull_supplier();
};
Interfaces for the Event Channel (3)
An event channel can act as
(5) So we invoke the appropriate interface according to our model
module CosEventChannelAdmin{interface ProxyPushSupplier;interface ProxyPullSupplier;interface ProxyPushConsumer;interface ProxyPullConsumer;
//…};
Forging ahead
Choosing an Event Channel Model Event Channel Federation Limitations Code practices and Alternative CORBA
Services Summary and Wind up.
Choosing An Event Model
Characterisitcs of each model Your system Event Channel implementation
– OMG does not define many of the key characteristics so shop around for the best Channel
– Throughput is dependant on the Channel efficiecy– ORBs marshaling and unmarshaling of the any type
Consumer and Supplier Numbers
Buffering and Queueing efficiencies Not just network connections
Event Channel Federation
Event channels support the consumer and supplier interfaces for Push and Pull Models
Supplier EventChannel
Supplier
Supplier
Consumer
Consumer EventChannel
push
push
push
pull
Consumer
Consumer
Consumer
Consumer
push
pushpull
pull
Is the Event Service everyone’s cup of tea ?
Everything in life is a trade off Multiple Suppliers Lack of Filtering Lack of Reliability Portability Asynchronous Messaging
Multiple Suppliers
Consumers receive all events Client can filter via extraction using any Type
– This can be a waste of resources
Multiple Event Channels per Type– Also a waste of resources and defeats aims of
Event Service
Limit suppliers per Event Channel– unreasonable request on developers
Filtering
In fact problem exists even if Event Channel has one supplier
Event service should be able to filter the Events Allows designer to make tradeoff as to where
resources are used– Client, Network– Event Service
Notification Service
Reliability
Event flooding Difficult to guarantee end-to-end delivery of
service without a throttle on suppliers A client has no guarantee of receiving events
Portability
The spec has problems Factory template method for channel creation Queue limits Timeout limits Consumer Supplier registration
Asynchronous Communications
Is NOT provided by the Event Service It only decouples Callback or heartbeat poll needed Messaging Service
– Time independent– Throttle
What have we learnt ?
Synchronous requests can be too restrictive Event Service simply handles event delivery Acts as a Mediator Decoupling suppliers from
consumers Based upon concept of Event Channels
Event Channel Summary
Channel has two models of delivery:– Push– Pull
Combinations of which form:– Hybrid– Mixed
How does it work ?
Implement a servant if using a push Consumer or pull Supplier
Obtain a reference from an event channel Get ConsumerAdmin or SupplierAdmin to
register Obtain proxy object to reference model Invoke the appropriate connection operation
There are Drawbacks to Consider
No filtering No specification as to persistent storage of
Registration Queue and timeout limits A real time event-based system is difficult
4th Assignment
There is a ORBacus demo Setting up the basics is simple Choosing the right model will require some
thought
Bibliography
Michi Henning & Steve Vinoski (1999). Advanced CORBA Programming with C++. Addison-Wesly
ORBacus (2000). ORBacus for C++ and Java Ian Gorton (2000). Entiprise Transaction
Processing Systems. Addison-Wesly