Defining your application's message exchange protocol
Monitors use events to communicate with each other. Consequently, an EPL application will have a well-defined message exchange protocol. A message exchange protocol defines the following:
Types and structure of events that function as messages between monitor instances.
Relationships among these events.
Sequence and flow of events — which events are sent in response to receiving particular events.
Which monitors need to be able to handle which events, and conversely, which monitors should not receive which events.
Which channels these events are sent to, or whether they are sent directly between contexts.
When you define your application's message exchange protocol, keep in mind that any event that the correlator processes is potentially available to all loaded monitors. Consequently, you want to follow conventions that prevent the inadvertent matching of events with event listeners. These conventions are:
Use packages to restrict the scope of event names (for example,
MyPackage,
YourPackage).
Use duplicate event definitions with different event names (for example,
MyStartEvent,
YourStartEvent).
Use discriminating/addressing information in the event (for example,
Request{integer senderId;...},
Response { integer toSender;...}).
While event definitions provide partial support for a robust message exchange protocol, they lack the ability to specify event patterns, request-response associations, and so on. You should insert structured comments in your event definition files to define this part of the message exchange protocol. The comments that describe the relationships among the events define the contract that the participating monitors must adhere to. It is up to you to document the expected flows and patterns and to ensure that your monitors comply with the contract.
Some common message exchange patterns are:
Request/response
Publish/subscribe/unsubscribe
Start/stop
To identify the event types that a core monitor needs to support, consider the following:
What actions do you want to perform on the object that the monitor represents? You might want to define an event that is dedicated to each action. For example, for an order processing monitor, you might define an event type for each of the following actions:
Place an order
Change an order
Cancel an order
Suspend trading
Resume trading
What initialization and termination events are needed? Keep in mind that a core monitor is typically a factory that creates monitor instances that each represent a single entity. You probably want to define at least one event type for initialization and one event type for termination.
Do you need other control events? For example, in the order processing example, do you need a control event that suspends all trading and applies to all orders? See
Using events to control processing.
Do you need to add any events to observe what is happening in the monitor? For example, each order processing monitor could support a request/response protocol to inquire of its state or it could simply send an
OrderProcessingState event each time there is a significant state change.