Ponder2 Proximity Event Bus
Ponder2 has an unusual graph-directed event mechanism. A normal event bus can be described as a distributed computer system in which a plurality of applications are connected to an event bus through an adapter interface. Messages exchanged between applications are transmitted on the event bus and are processed according to rules stored in a rules repository. This type of event bus distributes all events to all objects/processes that have registered to receive it. In our case, events are distributed to policies that have specified that they want to receive that particular event type. However, it is not always useful for all policies to be activated by the same event so extra processing is required to determine if it is required or not. This results in extra complexity for the policy or a proliferation of event types to give a finer graduation of events.
Ponder2 solves this problem by the use of a Proximity Event Bus which allows policies to pick up events generated only by certain managed objects. Essentially, instead of “attaching” policies to the event bus when they are activated, they may explicitly be attached to managed objects within the domain hierarchy. That is they subscribe to an event type via a managed object rather than via the global event bus. An event is always produced by a managed object somewhere within the system. Instead of the event being offered to all the policies in the system that are dependent on that event, the event propagates up the domain hierarchy. As it is propagated it is offered to any policies attached to any domain on the path up to the root as long as the event type is expected by those policies. In this way, a policy can be set up that will only respond to events created by a limited set of managed objects.
The more traditional Event Bus can be emulated simply by attaching all policies to the root domain meaning that all events are offered to all policies.
As can be seen in the above figure there are two identical bed stations, each with a heart rate monitor which will produce a “heart rate” event should the heart rate cause concern. The bed policies and the ward policy have all subscribed to the heart rate event. With a traditional event bus, the bed policies would have to check where the event came from before proceeding. With the Proximity Event Bus the bed policies will only see events generated from managed objects within their bed domains and the ward policy would see all events. The bed policies’ actions could involve just local managed objects and therefore they don’t need any special knowledge about which bed they are monitoring. This allows more bed systems to be introduced within the ward without configuration and creating minimum impact on the rest of the system.
The Proximity Event Bus becomes even more relevant when applied to distributed systems allowing local policies to deal with the local events while maintaining the ability to have higher-level policies reacting to the same event from many places.
Note: Objects creating event must be held in the domain structure otherwise the event will not be propagated.