Download Component Reliability Extensions for Fractal component model

New features developed within this project
the subsequent events observable on the interfaces of the faulty components. The default behavior is
to log and report the error (including the execution trace so far collected for the component, and also
the current stack trace); optionally, a runtime exception (ProtocolViolationException) may
be thrown to inform the application that the attempted call is not permitted by the protocol. Here,
please note that raising the exception prevents the method call from actually occurring when the erroneous event detected is a request event, but obviously cannot prevent the call in the case of a response
event. The error handling policy can be configured via JVM properties, described in the following
section.
4.4.4. Technical notes
The runtimecheck subsystem may be configured via the following JVM properties:
fractal.protocols.rtcheck.recorderrors (values:
true or false; default: true)
sets whether the runtime check controller should record all erroneous events.
sets how many recent events should be kept to aid with locating
fractal.protocols.rtcheck.recordtrace (values: - the source of an error. Special values: -1 (unlimited storage)
1, 0 or a positive integer; default: -1) and 0 (no events recorded).
fractal.protocols.rtcheck.stoponerror (values:
true or false; default: true)
sets whether runtime-checking should stop for a component
when a violation of the component's protocol is detected. If
false, the erroneous event is ignored and checking resumes from
the current position in the state-space.
fractal.protocols.rtcheck.throwerrors (values:
true or false; default: false)
sets whether an exception should be thrown when a protocol
violation is detected.
fractal.protocols.rtcheck.verbosity (values: 0, 1,
2 or 3; default: 1)
sets the level of output on stderr produced by the
runtimecheck subsystem. (0: no output, 1: only protocol violations, 2: report on controller initialization and successful completion, 3: report on event processing.)
4.5. Extensions to protocols
4.5.1. Multiple bindings
In Fractal, any interface can participate in more than one binding (if this is the case, we say that the
interface has multiple bindings). As behavior protocols were originally developed for a component
model, where every interface can have at most one binding, this alternative did not come into question
when the algorithm for architecture protocol construction was designed. Therefore, the algorithm had
to be revisited for Fractal.
Let C be a component whose subcomponents S1, ..., Sn have the frame protocols F1, ..., Fn. The
classical construction of C's architecture protocol (not considering multiple bindings) is done in two
steps. In the first step, the interface names in the frame protocols F1, ..., Fn are replaced by the binding
names (names of unbound interfaces remain unmodified). In the second step, the protocols are composed
using the consent operator.
The purpose of the first step of the algorithm is to ensure that the emission and absorption of any event
(specified in different frame protocols) is denoted by tokens which differ only in the prefix (? or !).
If this was not the case, the consent operator would not work correctly.
To guarantee proper functionality of the consent operator also in the presence of multiple bindings,
the first step of the algorithm has to be modified. The idea behind the modification is the following:
If a provided interface has multiple bindings and the protocol of its component denotes acceptance of
25