Core components
The core components of Cloverleaf consist of these concepts:
- All messages passing through
Cloverleaf are stored in queues between any actions that are undergone in the
engine. These queues are backed by an embedded high-performance Raima network-model
recovery database. This ensures message continuity and integrity can be recovered in
the event of an unexpected shutdown by repopulating the queues from the database.
See Introduction to Database Administrator.
Messages that encounter errors are also stored in a similarly designed error database, from where they can be modified and resent to various points in the engine. A third embedded database acts as a cache for message archiving where messages are stored until they are flushed out to an external relational database.
- Routing is the way Cloverleaf determines what messages go where. This is
accomplished by creating routes from inbound protocol threads to outbound protocol
threads. A Transaction ID that is based on the message’s content is defined by the
user. This is used to determine which routes a message takes. Translations can be
configured to occur during these routes. An inter-site routing tool is also
provided. With this tool, Cloverleaf sites on several hosts can route messages to
one another directly using the Interthread Communications Library.
See Route configuration.
- Cloverleaf offers many built-in tools to transform messages through mathematical, logical and iterative operations or lookup tables. The user can define how these tools are used in the IDE’s Translation Configurator and save a particular translation into a translation file. These files can be tested in the testing tool to determine whether they work as designed before deploying in a production environment. When these tools alone are insufficient, the user can write scripts in Tcl or Java to transform messages.
- Scripts that control message flow are run using embedded Tcl interpreters and JVMs. Scripts can also transform message content at various points in the Cloverleaf engine. The user can write these scripts in an external text editor and import them to Cloverleaf, or use the built-in editor.
- In Cloverleaf, inbound and outbound messages are archived to an external database through the ODBC drivers. Support is provided for reading and writing messages directly to and from Oracle and SQL Server databases. This is accomplished by SQL statements and stored procedures through JDBC.
- Cloverleaf security server stores access control lists in an embedded Derby database. Whenever a user attempts to run an action, the host server queries the ACLs through RMI. This determines whether the user has permission to run that particular action. Users can be granted full read/write or read-only access to various areas.
- As the Cloverleaf engine records statistics in shared memory, a separate monitor daemon process accesses shared memory to report these statistics to the user. The user can configure alerts to have the daemon send an email, pop up a window, or run a script when trigger conditions are met. These trigger conditions can be based on system statistics such as CPU and disk usage. They can also be based on Cloverleaf variables such as queue depth and protocol thread status. The monitor daemon communicates with the host server or directly with the Global Monitor through TCP/IP.