OMG Event Service

1. OMG Event Service Distributed Object Systems and Technology COMP4111

2. Presenters • Dean Adamson • Håvard Frøiland • Simon Pett

3. 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

4. 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

5. 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

6. Different Event Service Models • There are four different Event Service Models • Canonical Push • Canonical Pull • Hybrid Push/Pull • Hybrid Pull/Push

7. push push push push push Direction of Event Canonical 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 Consumer Supplier Event Channel Consumer Supplier Consumer

8. pull pull pull pull pull 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 Consumer Supplier Event Channel Consumer Supplier Consumer

9. pull push pull push 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 Consumer Supplier Event Channel Consumer Supplier Consumer

10. push pull push pull push 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 Consumer Supplier Event Channel Consumer Supplier Consumer

11. push push pull pull 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 Consumer Supplier Event Channel Consumer Supplier Consumer

12. Event Service Interface • The event channel • Push model interface • Pull model interface

13. The Event Channel • The event channel presents itself as a consumer to suppliers and as a supplier to consumers • Proxy interface • Decoupled communications

14. 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 (1)

15. 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 (2)

16. 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(); }; //... }; Interfaces for the Push Model (3)

17. 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

18. 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 (1)

19. 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 (2)

20. 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(); }; //... }; Interfaces for the Pull Model (3)

21. 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.

22. 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.

23. 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.

24. (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 (1)

25. (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 (2)

26. 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; //… }; Interfaces for the Event Channel (3)

27. Forging ahead • Choosing an Event Channel Model • Event Channel Federation • Limitations • Code practices and Alternative CORBA Services • Summary and Wind up.

28. 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

29. Consumer and Supplier Numbers • Buffering and Queueing efficiencies • Not just network connections

30. Event channels support the consumer and supplier interfaces for Push and Pull Models Supplier push Consumer push Supplier Event Channel push Consumer Event Channel pull pull Supplier Consumer push push pull Consumer Consumer Consumer Event Channel Federation

31. 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

32. 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

33. 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

34. 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

35. Portability • The spec has problems • Factory template method for channel creation • Queue limits • Timeout limits • Consumer Supplier registration

36. Asynchronous Communications • Is NOT provided by the Event Service • It only decouples • Callback or heartbeat poll needed • Messaging Service • Time independent • Throttle

37. 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

38. Event Channel Summary • Channel has two models of delivery: • Push • Pull • Combinations of which form: • Hybrid • Mixed

39. 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

40. 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

41. 4th Assignment • There is a ORBacus demo • Setting up the basics is simple • Choosing the right model will require some thought

42. 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