Servers or Composable Architecture Platform servers are each instances of the X Engine or a database server. There are six types of servers: test, production, Multi-Protocol, database, template, and production with forwarder.

Test servers

Test servers are used to validate a rule set before it is deployed into production. Test servers can take and process a data file containing test data extracted from a production server or manually created.

Afterwards, performance data from the test server can be used to validate that a particular rule set performed as planned.

Production servers

Production servers are capable of taking a data feed from any number of sources, such as a Web Service, a HTTP request or a data file placed in a folder. Production servers continue running once started and are continuously waiting for data.

Multi-Protocol servers

Multi-Protocol servers are servers that are capable of intercepting one or more standard network protocols and breaking them down for analysis by the Composable Architecture Platform.

They differ from Production servers in that they can take data directly from the network layer without interpretation and can then pass that data through a set of protocol rules and proxy that same (or altered) data to a protected server.

The response from the protected server follows a similar path (with retained visibility of the original request).

Database servers

Database servers do not have X Engines installed and do not show up as Composable Architecture Platform Servers as such. They can however be defined as servers so that JDBC connections to them can be specified.

Template servers

Template servers are used as "parents" for other servers. This allows settings such as web proxy settings and mail server settings to be inherited by other servers and reduces the maintenance load for large clusters.

Production servers with forwarders

This refers to a group of production servers that have a built in forwarding proxy controlled by Composable Architecture Platform. These servers also have the capability to enable a browser proxy so that the forwarders can be used for testing rules against applications.

Hardware servers versus Composable Architecture Platform servers

It is important not to confuse a Composable Architecture Platform server instance with a hardware server instance. A single hardware server can run many Composable Architecture Platform servers at once.

The rules editor is a graphical design tool for creating and maintaining rule sets. The rules editor is launched as a separate browser window from within the console application.

Projects are collections of tasks that needs to be completed to fully create a solution. Tasks are assigned to users and are listed as To Do items for that user. All tasks result in a work output of some kind.

By using predefined project definitions, it is easy to set up and track all the basic tasks required to complete a full enterprise deployment (such as rule writing, firewall rules, SSL certificate ordering and so on).

The console is used to administer the system. It is a browser-based application that provides the user with a complete view of all installed servers, rules, configurations and so on. The following is a sample view of the console after the user has logged on.

The console has four distinct panes as described below:

Top Banner

The top banner contains simply the logo and the log out button. This banner is visible on all console pages to facilitate easy log out from the product.

Administration tree

The administration tree is used to navigate the console application. To view the properties for a particular function, click the icon or folder in the tree in front of that function. To get back to the main login page, click on Console at the root of the tree. Increase or decrease the vertical space taken up by the tree by dragging the divider left or right.

Action window

Whenever a function is selected in the administration tree, a corresponding page is shown in the Action window.

Server console viewer

When a server is processing data, it has the ability to output information to an internal console. The console for each server is replicated in real time to the administration console and can be viewed in the pane at the bottom.

Case Managers are databases and workflows that contain cases to be investigated and followed up by fraud or security experts. Cases can be inserted into the case manager either manually or through rules. Alongside each case are tasks that need to be completed and task queues that facilitate the workflow.

Tasks

Tasks are connected to cases in the case manager. Each case can have one or more tasks that need to be completed. Once a task is completed, the action of completing that task may result in the case changing status (for example from “Open” to “Closed”) or yet another task being generated for that case.

Queues

Tasks are always contained in a queue. Queues are priorities and when a user picks the next task to perform, the queues assigned to that user will be checked consecutively for the next most urgent task.

Test data can either be in the form of manually created CSV, XLS or XML files, or it can be files captured during the execution of a rule set on a server (TST file).

All production servers allow the download of a set of test data at any time to use for further development of rules on a test server.

Trace data is captured during the execution of a rule set on a server (TRC files). They contain detailed information of the flow of data through a rule set. All servers allow a trace to start at any time for use in debugging rules.

This document refers to rules, the rule catalogue and rule sets throughout. It is important to understand the distinction between them to avoid confusion.

Rule

A rule is a fundamental building block created by a Java programmer. Rules can be dynamically added to the system by downloading them from the TomorrowX website or other sources. In-house programmers can also add them.

Analysts generally do not create rules; they use them to build rule sets.

Examples of rules are: If Condition, History Recorder and Name Splitter.

Rule catalogue

In the rules editor, all of the rules installed are represented in the rule catalogue. It is a tree of all the rules that are available for an analyst to use. Rules are grouped into functional areas.

Protocol rules

There is a different type of rule used to break down elements of a given network protocol. Protocol rules can only be managed by an Administrator. Protocol rules use a different rule catalogue than the standard rules.

A protocol rule is specified against any new supported protocol as well as against the response supplied from a proxied protocol request.

Rule sets

Rule sets are combinations of rules put together to perform a given task or strategy. They are created using the rules editor and are typically a combination of rules and other rule sets. Rule sets created by analysts show up in the rule catalogue in the rule sets section.

When a rule set is completed, it is considered a rule by itself.

Rule set mode

A rule set mode is the rule set being executed when a data set hits the X Engine. By default, there is only one mode, but additional ones can be created to deal with specific situations (such as stand-in, promotion etc.). Modes can be changed without redeploying rules.

Flight recorders are databases containing log records of specific activity. A flight recorder starts recording once a trigger event has happened and will then record for a specific number of records, until a time limit is reached, forever, or until it is manually closed. This can be used to track specific user activity.

Data from flight recorders can be converted to test data at any time.

Data files are files used to assist the X Engine in making decisions.

Examples include CSV files of undesirable individuals, IP geo location databases and blacklists.

Protocols are network specific, low-level interpretations of the data flowing over a network. Examples of protocols include HTTP, SMTP and ISO8583. Composable Architecture Platform has a special X Engine (accessible via administrator privileges) that allows for the definition of protocols.

The Composable Architecture Platform X Engine is highly extensible. New rules are developed regularly. To allow use of them within the rules editor, an extension may need to be installed (manually or via the update server). This will add the new rules to the rules catalogue.

Content files are a structure of files being served up by the X Engine in a manner similar to an HTTP server. The structure mirrors the structure of the files in the protected server and can be used to overlay images and pages on top of an existing application.

There are a number of terms used in the Composable Architecture Platform which the user should be familiar with. This section introduces these terms and the concepts they represent.

Once a rule set has been executed on a server, performance data can be retrieved (in graphical form) to see how rules are performing.

The credential vault provides a central location (only accessible to administrators) for storing user IDs, passwords, access codes and other data that is required to access external services. The information stored in the vault is automatically transferred to the X Engine upon deployment, eliminating the need for rule set writers to know any credentials.

Custom functions are features that can be added to the Composable Architecture Platform console using rules. These same custom functions are subject to the normal Composable Architecture Platform console roles configuration and can be used to add simple maintenance tasks (such as blacklists) directly to the console so that they are accessible to normal console users without needing any other applications.

Users, in the context of Composable Architecture Platform, are the users signing in to the console.

Databases are another fundamental concept of Composable Architecture Platform. In Composable Architecture Platform terminology, a database is anything that can be connected to via a JDBC driver.

JDBC drivers are connectivity modules for the Java language.

The term database refers to a system that is capable of storing data in a structured relational manner.

Alongside databases, there are a couple of terms that are important, which are listed below (Tables through Keys).

Tables

Tables are the name of the individual file within the database where a given set of data is stored. Sample table names are CUSTOMERS and ACCOUNTS. Some Composable Architecture Platform rules have the ability to create tables or read/write data to them.

Schema

A schema is a way to segment a database into multiple entities i.e. there can be two schemas on the same database containing the same table names. For example, there can be a PRODUCTION schema that contains an ACCOUNTS table as well as a TEST schema that contains an ACCOUNTS table.

Rows and columns

Rows and columns refer to the individual elements inside a table. For example, like a spreadsheet where all of the columns have a name.

Keys

Typically, all tables have keys that map to one or more columns in the table. In most cases tables have unique keys, which is enforced at the database level.

Input adaptors define how the X Engine interprets data that is sent to it. A large number of different adaptors such as XML, CSV, TST, HTTP and other data formats are shipped out of the box. New adaptors can be added, if required.

Not all users signing in to the console will have the same roles. It is possible for all non-administrative users to have their access restricted to specific console functions.

Configurations hold the additional information a server needs to be able to execute a rule set. For example, if a server is reading from a CSV file, the configuration will define which column in the CSV file is stored in which variable, before being processed by the rule set.

Input formats, initial variable values, global variables, database information etc., are also all held in configurations.

The internal audit log provides a view of all events relating to administrative objects. Events such as logins, logouts, user profile changes and so on are all logged here.

Composable Architecture Platform is a very network centric product. As such there are a number of network level definitions that can be confusing - especially when it comes to the large number of potential proxies being involved. The following is a list of the terms used for various proxies within and used by the product.

Web proxy

A web proxy is a proxy server that is installed as a performance optimizer or security feature betweenComposable Architecture Platform and the World Wide Web. Typically, this is a corporate proxy that Composable Architecture Platform must traverse to access services such as the update server, MaxMind, SMS services etc.

Composable Architecture Platform built in proxy (forwarder)

The built in Composable Architecture Platform proxy, called Proxy Server in the console, is a forwarding proxy used to protect sites that are unable to take advantage of the inline filter (e.g. all non-J2EE sites). It is also used to test Composable Architecture Platform rules against any site, without performing any installation. The latter is achieved using the built in browser proxy.

Browser proxy

The browser proxy is a feature of the built in forwarding proxy. The browser proxy allows configuration of a proxy within browser settings and have the requests from that browser sent through the Composable Architecture Platform built in proxy. This provides a convenient method for testing rules against sites without installing any additional software.

Access rules can be used to define conditions of user access. Access rules can, for example, restrict a user to only be able to sign in from the local physical system, require a second-factor logon or call out to a single sign-in system for password validation. Access rules are plug-ins and the system can be extended with new rules on demand.

Repositories are collections of configurations, rule sets and data. They work similar to folders in a normal file system to logically separate and control access to important assets. A typical set of repositories for any given system would be Test, Staging and Production – reflecting the lifecycle of the configurations, rule sets and data involved in a deployment.