Coding for the Composable Architecture Platform X Engine requires the understanding of a number of concepts exposed by the framework. We will cover the key concepts in this section.
Within each new extension you can have one or more rules. Rules are the building blocks of any Composable Architecture Platform configuration.
Every rule within Composable Architecture Platform has a lifecycle. The lifecycle consists of an initialization phase, an execution phase and a clean-up phase. It is important that new resources used by each rule are properly allocated and subsequently cleaned up to avoid memory and resource leaks.
As part of understanding the rule lifecycle, it is important to know that only one instance of any given rule is created at any one time. This means that class variables are shared across threads and static class variables are shared across all instances of the same rule. For this reason, care must be taken to ensure the thread safety of each rule.
Whilst each rule has a single-entry point, you can have multiple exit points. These are known as chain points. Some rules allow for additional chain points to be added by the user as well. It is the responsibility of the rule programmer to determine which chain points the rule enters.
Note that there is a lot of framework logic around each chain event. It is possible for a rule further down the chain to terminate any further chain point processing (Set Completed). Chain points are also set to automatically collect performance statistics.
Some rules rely on external resources (such as data files). Rules that are able to dynamically load these resources should be "change aware". The rules framework provides a notification method to alert rules that a file has changed and should be reloaded.
Data moves through the X Engine on the back of a Variable Attribute Object (VAO). For each request to the X Engine, a VAO is created and handed to the first rule in the rule set. Each rule can add, alter and remove variables and objects to/from the VAO. The VAO also, in some instances, can contain an alternative data wrapper that provides a binding to the original request object. For example, for HTTP based rules, the data wrapper will contain an object with the application server's request and response objects as well as the filter chain.
At the X Engine level, the framework maintains variables that are shared between all threads and rule set instances. These are referred to as Global variables and can be obtained through the X Engine interface.
Input adaptors are the glue between the data being intercepted by the X Engine and the rules themselves. It is the job of the input adaptor to break the data into VAOs and hand them to the X Engine as such. This normally means converting any part of the data into Strings that are useful for the rule writer. New Input adaptors can be installed via extensions the same way as rules.
Each extension has the ability to incorporate JAR files and other specific classes that may be required to run a particular rule. It is important to understand that the X Engine is loading classes outside the scope of any application or process that it is protecting. Hence you cannot load classes from the application, and the application cannot load classes from the X Engine. This approach was implemented to protect the application from accidental conflicts with different versions of JAR files that may be used by either the X Engine or the application.
Composable Architecture Platform is designed to be backwards compatible with JDK 6.0 or later. For that reason, we recommend that you attempt to follow the same approach. This will ensure that your rule will be able to be redistributed to other Composable Architecture Platform users. If, however you are building a rule for internal use only, and you know for sure which JDK version you will be using, you can make your own compatibility choices.