Information Technology Reference
In-Depth Information
A?data
C!req(int)
new scope
A!resume
A!pause
{
C, A
}
!stop
C?timeout
Fig. 6.
Monitor workflow for (1) invitation and (2) in-
conversation messages
Fig. 7.
Nested FSM generated from the
User local protocol
meta data, the conversation runtime (and monitor) is able to compensate for the inher-
ent discrepancies in protocol synchronisation, due to asynchronous interrupts between
distributed endpoints, by safely discarding out-of-scope messages. In our example, the
User runtime discards
data
messages that arrive after
pause
is thrown. To prevent the
loss of such messages in the application logic when the stream is resumed, we could
extend the protocol to simply carry the id of the last received resource in the payload
of the
resume
(in line 21). The API can also make the discarded data available to the
programmer through secondary (non-monitored) operations.
An alternative event-driven implementation using
receive asyc
and callbacks (that
can, however, be safely monitored against the same local protocol) is given in [35].
3.2
Monitoring Architecture
Inline and Outline Monitoring.
In order to guarantee global safety, our monitoring
framework imposes
complete mediation
of communications: no communication action
should have an effect unless the message is mediated by the monitor. This principle
requires that all outgoing messages from a principal before reaching the destination, and
all incoming messages before reaching the principal, are routed through the monitor.
The monitor implementation (and the accompanying theory [7]) is compatible with a
range of monitor configurations. At one end of the spectrum is
inline monitoring
,where
the monitor is embedded into the endpoint code. Then there are various configurations
for
outline monitoring
, where the monitor is positioned externally to its component. In
the OOI project, our focus has been to integrate our framework for inline monitoring
due to the architecture of the OOI message interceptor stack [31].
Monitor Implementation.
Figure 6 depicts the main components and internal work-
flow of our prototype monitor. The lower part relates to conversation initiation. The
invitation
message carries (a reference to) the local protocol for the invitee and the
conversation id (global protocols can also be exchanged if the monitor has the fa-
cility for projection.) The monitor generates the FSM from the local protocol fol-
lowing [13]. Our implementation differs from [13] in the treatment of parallel sub-
protocols (i.e. unordered message sequences), and additionally supports interrupts. For
