Sample financial application

event StockTick {
   string name;
   float price;
}

event Limit {
   integer userID;
   string name;
   float limit;
}

monitor SharePriceTracking {

   // store the user’s specified attributes
   Limit limit;

   // store the initial price (this may be the opening price)
   StockTick initialPrice;

// store the latest price – to give to the user
StockTick latestPrice;

// when a limit event is received spawn; creating a new
// monitor instance for each user’s request
action onload() {
    on all Limit(*,*,>0.0):limit spawn setupNewLimitMonitor();
}

// If an identical request from a user is discovered
// stop this monitor and die
// if a StockTick event is received for the stock the
// user specified, store the price and call setPrice
action setupNewLimitMonitor() {
    on Limit(limit.userID, limit.name, *) die;
    on StockTick(limit.name, *):initialPrice setPrice();
}

// Search for StockTick events of the specified stock name
// whose price is both greater and less than the value
// specified – also converting the value to percentile format
action setPrice() {
    on StockTick(limit.name, > initialPrice.price * (1.0 +
       (limit.limit/100.0))):latestPrice notifyUser();

   on StockTick(limit.name, < initialPrice.price * (1.0 -
      (limit.limit/100.0))):latestPrice notifyUser();
}

// display results to user
action notifyUser() {
    log  "Limit alert. User=" +
      limit.userID.toString() +
      " Stock=" + limit.name +
      " Last Price=" + latestPrice.price.toString() +
      " Limit=" + limit.limit.toString();
    die;
}
}

The important elements of this example lie in the life-cycle of different monitor states. Firstly a monitor instance is spawned on every incoming Limit event where the limit is greater than zero. Within setupNewLimitMonitor, the first on command listens for other Limit events from the same user, upon detection of which the monitor instance is killed. This effectively ensures that there is a unique monitor instance per user per stock. This scheme also allows a user to send in a Limit event with a zero limit to indicate that they actually no longer want to monitor a particular stock. While this will not be caught by the original monitor instance’s event listener and will not cause spawning, it will trigger the event listener in the monitor instance of that user for that stock and cause it to die.

Then a single on command (without an all) sets up an event listener to look for all StockTick events for that stock type for that user. Once a relevant StockTick is detected, new event listeners start seeking a specific price difference for that user. If such a price change is detected it is logged. Note that the log command exploits data from variables used before and after the spawn command (that is, limit and latestPrice, respectively).

This example also demonstrates how mathematical operations may be used within event expressions. Here, two on commands create event listeners that look for StockTicks with prices above and below the calculated price. The calculated price in this case is based on the initial price multiplied by the percentage specified by the user. The first event listener is looking for an increase in the share price to 105% of its original value, while the second is looking for a decrease to 95% of its original value.