Organizing behavior into monitors
Typically, an Apama application consists of several monitors each doing a specific task. For example, a simple algorithmic trading system might consist of the following monitors:
A monitor that manages order processing by spawning a monitor instance for each order.
One or more market data monitors. Each monitor listens for a different type of market data (such as tick data, market depth) required to process orders. Each of these monitors typically spawns a monitor instance for each stock you want to observe.
A more complex application might organize its orders into portfolios or split sets of orders into smaller orders for wave trading or some other purpose.
In an Apama application, each monitor can usually be categorized as a core processing monitor or a service monitor. A core processing monitor performs the tasks you want to accomplish. A service monitor provides data needed by the core processing monitors. Typically, the core processing monitors spawn multiple monitor instances. These monitor instances will consume data from the same service monitors. For example, all monitor instances that manage the individual orders for a given stock would obtain tick data from the same instance of a service monitor. The ordinality of the solution elements (for example,
N order processors that require data from
1 tick data provider) often dictates how the solution code should be organized into separate monitors. See also
About service monitors.
The ordinality of the solution elements often dictates how the solution code should be organized into separate monitors. For example, there is an N:1 relationship between the N order processor monitor instances that require market data for a given stock and the 1 market data service monitor instance that supplies it.