Table of Contents
RVPF has multiple components that have been
designed to work together. These components can be executed by
themselves or under a JMX container. One of the components
(Container) may also be used as a container for
other components. The components can run in the same or different
JVMs, on the same or different host
computers.
The following sections contain short descriptions, diagrams and notes on the principal components.
This service generates time events which may trigger computations. It has to be able to generate past events scheduled to occur while the service was not running. The event generation must always be in chronological order.
Interaction between a Clock and
the Store holding some of its
Points.
The values generation must be assisted by the
Points Content. The
CrontabContent provides such assistance by following a UNIX style specification
(
crontab
).
This component can be used as a light weight container for other framework components.
This is a convenience service to host a database engine instance. It currently supports Derby, H2 and HSQL.
Interfaces with version control software to refresh the
Metadata document. Upon receiving the
UpdateDocument
Signal, this component updates the configured
workspace; it then broadcast a DocumentUpdated
Event. If it sees a BadDocument
Event, it will try to restore the previous revision
of the document.
The ForwarderService is a generic component
for the handling of messages queues and topics. It can accept multiple
input modules and multiple output modules. Messages filters can be
attached to any module.
While other services from the framework will react to a communication failure with an attempt to restart themselves, forwarder modules are expected to resist such failure by closing the communication channel and keep trying to open it again.
The input modules accept messages (usually
PointValues) from a specified input.
The output modules submit messages (usually
PointValues) to specified output.
The messages filters can be applied to input and output modules.
Accepts only messages which are values for known points. Also reformats the values.
This component can host multiple modules supplying HTTP services
Serves Metadata filtered according to a
client's request.
An important use is the distribution of up to date, validated and condensed metadata to other components.
This is the heart of the system. Using relationships specified in the metadata, incoming notices trigger computations and updates. It is able to handle cascading events. It can be configured to support customized point behavior and content.
A number of PointValues are received by the
Receptionist and collected in a
Batch. Each PointValue may
request the computation of some other PointValues.
The inputs of the values to be produced are then collected and the
appropriate computations are performed. The results are then sent to the
appropriate Stores. The processing of the received
values is then confirmed (committed) by the
Receptionist.
Processor.
The Processor uses an interface
(Receptionist) to receive notices from a
replaceable module (JMSReceptionist).
The Processor uses an interface
(Engine) to produce results from
inputs.
Allows computation of result values by class implementing a
simplified API: EngineExecutor.
Allows the use of an external process to perform the computation of result values. The communication with this process is made thru the standard input, output and error streams.
This component can host multiple queues and/or topics. These messaging facilities can be hosted by most components needing them, but this service can be used when some of them need some independence.
A SOM queue allows one reader (receiver) and any number of writers (senders). It is always transactional and persistent. A transaction is stored in a file as an XML fragment. The name of the transaction file is the ISO-8601 date and time format for the moment (UCT) of the start of that transaction. The name of the directory holding the transactions is the name of the queue.
A Store is responsible for the storage and
retrieval of the point values.
Interaction between a Processor
and a Store in a one to one
configuration.
This component has to be implemented to enable the support of a specific Historian System.
Implements a Store using a
JDBC driver. Its supports cloning,
allowing updates on any clone.
Responds negatively to any query and ignore any update. Although this component appears ludicrous, it is actually useful in some situations.
A particularity of this store: it exists only on the client side.
Responds negatively to any request but is expected to process updates. The processing is done by a contained module.
Ignores the update values. Although the effect of using a
SinkStore with this module seems equivalent to
using the NullStore, there is one important
difference aside the additional communication overhead: the
SinkStore container can generate a notice for
the update value.
Supplies the update values to an external process. The communication with this process is made thru the standard input, output and error streams.