RVPF Components

Revised: 2010-03-10.


Table of Contents

Clock Service
Container Service
Database Service
Document Version Control
Forwarder Service
Input Modules
Pull Notifier
SOM Receiver
SOM Subscriber
Streamed Messages Files
Streamed Messages Port
Output Modules
SOM Publisher
SOM Sender
Messages Filters
Class Filter
Point Value Filter
Processor Filter
Store Filter
HTTP Server
Alert Module
Metadata Server Module
Notice Module
Query Module
RPN Module
Update Module
Logger Service
Processor Service
Receptionist
Engine
Clone Engine
Control Engine
Local Executor Engine
Null Engine
Remote Executor Engine
Replicator Engine
Resynchronizer Engine
RPN Engine
Rules Engine
Step Filter Engine
Summarizer Engine
Script Service
SOM Server
SOM Queue
SOM Topic
Store Service
C Store
My Store
Null Store
Proxy Store
Sink Store
Null Sink
Pipe Sink
Rules Sink
Script Sink

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.

Clock Service

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 ).

Container Service

This component can be used as a light weight container for other framework components.

Database Service

This is a convenience service to hold a database engine instance. It currently supports Derby, H2 and HSQL.

Document Version Control

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.

Forwarder Service

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.

Input Modules

The input modules accept messages (usually PointValues) from a specified input.

Pull Notifier

Pulls notices from a Store..

SOM Receiver

Receives messages from a SOM Queue.

SOM Subscriber

Receives messages from a SOM Topic.

Streamed Messages Files

Receives streamed messages from files in a specified directory.

Streamed Messages Port

Receives streamed messages from a specified TCP port.

Output Modules

The output modules submit messages (usually PointValues) to specified output.

SOM Publisher

Sends messages to a SOM Topic.

SOM Sender

Sends messages to a SOM Queue.

Messages Filters

The messages filters can be applied to input and output modules.

Class Filter

Only allows or blocks messages which are instance of specified classes.

Point Value Filter

Accepts only messages which are values for known points. Also reformats the values.

Processor Filter

Accepts only point values which can act as notices for a specified Processor.

Store Filter

Accepts only point values which are held at a specified Store.

HTTP Server

This component can host multiple modules supplying HTTP services

Alert Module

Receives queries for Events and components status and sends Signals.

Metadata Server Module

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.

Notice Module

Sends notices (PointValues).

Query Module

Responds to PointInfos and PointValues queries.

RPN Module

Executes RPN formulas on supplied data.

Update Module

Sends updates (PointValues).

Logger Service

Provides remote logging.

Processor Service

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.

Receptionist

The Processor uses an interface (Receptionist) to receive notices from a replaceable module (JMSReceptionist).

Engine

The Processor uses an interface (Engine) to produce results from inputs.

Clone Engine

Clones PointValues.

Control Engine

Controls some aspects of the framework thru special PointValues.

Local Executor Engine

Allows computation of result values by class implementing a simplified API: EngineExecutor.

Pipe Engine Executor

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.

Script Engine Executor

Allows the use of a script process to perform the computation of result values.

Null Engine

Does nothing.

Remote Executor Engine

Allows computation of result values on an other machine.

Replicator Engine

Replicates PointValues.

Resynchronizer Engine

Resynchronizes PointValues.

RPN Engine

A simple stack engine using a Forth like syntax to generate Transforms.

Rules Engine

Uses a rules engine to produce PointValues.

This Engine is provided by the Rules child project.

Step Filter Engine

Filters PointValues based on minimum step requirements.

Summarizer Engine

Extends the RPN Engine to allow operations on series of values of a Point within an interval formed by the occurrence of two values of a triggering Point.

Script Service

This is a convenience service to hold a script engine.

SOM Server

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.

SOM Queue

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.

SOM Topic

A SOM topic allows any number of readers (subscribers) and of writers (publishers). it is non transactional and non persistent. A subscriber must be connected at the time of publication to receive a message.

Store Service

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.

C Store

Implements a Store using a driver written in the C language to the API of a data historian.

My Store

Implements a Store using a JDBC driver. Its supports cloning, allowing updates on any clone.

Null Store

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.

Proxy Store

Relays queries and updates to the appropriate Store.

Sink Store

Responds negatively to any request but is expected to process updates. The processing is done by a contained module.

Null Sink

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.

Pipe Sink

Supplies the update values to an external process. The communication with this process is made thru the standard input, output and error streams.

Rules Sink

Supplies the update values to a rules engine.

This SinkStore is provided by the Rules child project.

Script Sink

Supplies the update values to a script process.