Sending events to other monitors

After you inject a monitor into the correlator, it can communicate with other injected monitors under the following conditions:

If the source monitor instance and the target monitor instance are in the same context, the source monitor instance can route an event that the target monitor instance is listening for. A routed event goes to the front of the context's input queue. The correlator processes all routed events before it processes the next non-routed event on the context's input queue. If the processing of a routed event routes another event, that event goes to the front of the input queue and the correlator processes it before it processes any other routed events on the queue. See Event processing order for monitors.

If the source monitor instance and the target monitor instance are in different contexts, the source monitor instance must have a reference to the context that contains the target monitor instance. The source monitor instance can then send an event to the context that contains the target monitor instance. The target monitor instance must be listening for the sent event or the context that contains the target monitor instance must be subscribed to the channel that the event is sent on. See Sending an event to a particular context and Subscribing to channels.

Within a context, an application can use routed events and completion event listeners to initiate and complete a service request inline, that is, prior to processing any subsequent events on the input queue. See Specifying completion event listeners.

monitor Client {
...
   listener_1:= on EventA() { route RequestB(...) }
   listener_5:= on ResponseForB () { doWork(); }
   listener_6:= on completed EventA() { doMoreWork(); }
...
}

monitor Service1{
...
   listener_2:= on RequestB(...)
   route RequestC();
   listener_4:= on ResponseForC{
   route ResponseForB ();
   }
...
}

monitor Service1a{
...
   listener_3:= on RequestC (...)
   route ResponseForC();
}