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.

    See Introduction to Translation Configurator.

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

    See Introduction to the Script 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.

    See ODBC command reference overview.

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

    See Introduction to advanced security.

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