OMG Event Service

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