Event Collaboration

Adding a risk tracking component

So far we've looked at the different ways our trader and stock exchange collaborate with these two styles. We can further see the differences by seeing how adding a third component is different in the two styles.

The third component we'll add is a risk management component. It's job is to look at the total volume outstanding across all traders with a particular stock.

class StockRrRiskTester...

  [Test]
  public void ShouldTrackTotalOutstandingVolumeForOrders() {
      RiskTracker tracker = new RiskTracker(null);
      traderA.PlaceOrder("TW", 1000);
      traderA.PlaceOrder("ICMF", 7000);
      Trader traderB = new Trader();
      traderB.PlaceOrder("TW", 500);
      Assert.AreEqual(1500, tracker.TotalExposure("TW"));
  }

Furthermore the risk management system needs to send out an alert message if the total outstanding goes above a preset limit, and cancel alerts should it fall below.

class StockRrRiskTester...

  [Test]
  public void ShouldTrackAlertWhenOverLimitForStock() {
      string symbol = "TW";
      ServiceLocator.RiskTracker.SetLimit(symbol, 2000);
      traderA.PlaceOrder(symbol, 2001);
      Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
  } 

In order for this to work the risk management system needs to be involved in both the placing of orders (which increases exposure) and the execution of orders (which reduces it).

We'll start by looking at the request/response scenario, starting with placement. We've chosen to modify the stock exchange object's submit method to alert the risk manager with each order submission.

class StockExchange...

  public void SubmitOrder(Order order) {
      outstandingOrders.Add(order);
      ServiceLocator.RiskTracker.CheckForAlertsOnOrderPlacement(order.Stock);
  } 

We could make this change on the trader, but we chose the exchange because it will need this dependency anyway for execution, so we're able to avoid making a dependency from the trader to the risk tracker.

In order for the risk tracker to determine the total exposure, it issues a query against the relevant stock exchange.

class RiskTracker...

  public int TotalExposure(string symbol) {
      return ServiceLocator.StockExchangeFor(symbol).OutstandingVolumeForStock(symbol);
  } 

So when told about a new placement, the risk tracker tests the result of this query against the limit that it holds.

class RiskTracker...

  public void CheckForAlertsOnOrderPlacement(String symbol) {
      if (OverLimit(symbol))
          gateway.GenerateAlert(symbol);
      alertedStocks.Add(symbol);
  }

  private bool OverLimit(String symbol) {
      return stockLimit.ContainsKey(symbol) &&
             TotalExposure(symbol) > stockLimit[symbol];
  }

When a trade is executed, again the risk tracker needs to be called by the stock exchange. The tracker again checks to see the current total exposure and determines whether it should cancel the alert.

class StockExchange...

  public void Execute(Order o) {
      outstandingOrders.Remove(o);
      ServiceLocator.RiskTracker.CheckForCancelledAlerts(o.Stock);
  } 

class RiskTracker...

  public void CheckForCancelledAlerts(String symbol) {
      if (alertedStocks.Contains(symbol) && !OverLimit(symbol))
          gateway.CancelAlert(symbol);
  } 

Figure 5: Sequence diagram that shows how placing an order that goes above the risk limits triggers an alert using request/response.

Now let's take a look at the case where we are using Event Collaboration. A key difference is that adding a risk tracker does not require us to make any changes to the existing components. Instead we build the risk tracker to listen to the events that the existing components publish.

class RiskTracker...

  public RiskTracker() {
      stockPosition = new Dictionary<string, int>();
      stockLimit = new Dictionary<string, int>();
      MessageBus.SubscribeToOrders(delegate(Order o) {
                                       handleOrderPlaced(o);
                                   });
      MessageBus.SubscribeToExecutions(delegate(Order o) {
                                           handleExecution(o);
                                       });
  } 

The tracker also needs data structures to keep track of positions, as it won't query the stock exchange in order to determine the exposure.

When a trade is placed, the tracker picks up the event. In response it updates its copy of the positions and checks for going over the limit.

class RiskTracker...

  private void handleOrderPlaced(Order order) {
      if (!stockPosition.ContainsKey(order.Stock))
          stockPosition[order.Stock] =  0;
      stockPosition[order.Stock] += order.Volume;
      checkForOverLimit(order);
  } 

  private void checkForOverLimit(Order order) {
      if (OverLimit(order)) MessageBus.PublishAlertPosted(order);
  }
  private bool OverLimit(Order order) {
      return stockLimit.ContainsKey(order.Stock) &&
             stockPosition[order.Stock] > stockLimit[order.Stock];
  }

To continue to use Event Collaboration, it raises an event when an alert appears. If we then want to send an email in response we can write an email gateway to listen to that event.

On execution events, it again updates its copy of the positions and checks to see if it needs to raise a cancellation.

class RiskTracker...

  private void handleExecution(Order o) {
      bool wasOverLimit = OverLimit(o);
      stockPosition[o.Stock] -= o.Volume;
      if (wasOverLimit && !OverLimit(o))
          MessageBus.PublishAlertCancelled(o);
  } 

Figure 6: Placing an order triggers an alert using events.

This modification brings out some important differences between the two interaction styles.

• We didn't need to modify existing components for Event Collaboration while we did for Request-Response Collaboration. It's worth noting that this was in large part because the existing components broadcast all relevant change information
• We didn't add any dependencies to the new component for Event Collaboration.
• The Event Collaboration risk tracker was able to determine alerts without further communication with other components since it already contained the necessary state. This lowered the amount of inter-component calls - which could be important if the components were in separate processes. You could achieve the same effect with Request-Response Collaboration by passing the current total exposure as part of the call - but this mean the stock exchange object needs to know what data the risk tracker needs to do its work - a further coupling between the two components.
• As we added the risk tracker, we ensured we used events to broadcast it's newly added information so that it could be a good citizen in the general collaboration. (And indeed we used it to trigger the email gateway.) Note that the events published by the risk tracker weren't tied to changes in state of the tracker (as we didn't broadcast the changes to positions) but to the new information that the tracker added to the global knowledge - whether or not the exposure was over the limits.

Many people would consider that these differences are fundamentally about a system with less coupling for Event Collaboration than for Request-Response Collaboration. We're not so sure. In Request-Response Collaboration components are coupled to each other through their interfaces, expressed as a menu of possible requests. But the same basic coupling exists in Event Collaboration, it's just that the interfaces have changed from request calls to events. If I change a component's event, it will still have repercussions on other components.

The crucial difference is that the communication flows between the components are no longer contained inside the components. Using Event Collaboration we don't have to get the stock exchange to tell the risk tracker when it should check its alerts. This behavior occurs implicitly through the evening model.

But this implicit behavior brings with it a dark side. Let's imagine another change to our components. So far we've assumed that orders are executed in total. Let's alter our stock exchange to handle partial execution.

[Test]
public void ShouldCancelAlertIfParitalExecutionTakesBelowLimit() {
    StockExchange exchange = ServiceLocator.StockExchangeFor("TW");
    ServiceLocator.RiskTracker.SetLimit("TW", 2000);
    traderA.PlaceOrder("TW", 3000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
    Order theOrder = exchange.OutstandingOrders[0];
    exchange.Execute(theOrder, 1000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.CancelsSent);           
}
[Test]
public void ShouldNotCancelAlertIfParitalExecutionStillAboveLimit()
{
    StockExchange exchange = ServiceLocator.StockExchangeFor("TW");
    ServiceLocator.RiskTracker.SetLimit("TW", 2000);
    traderA.PlaceOrder("TW", 3000);
    Assert.AreEqual(1, ServiceLocator.AlertGateway.AlertsSent);
    Order theOrder = exchange.OutstandingOrders[0];
    exchange.Execute(theOrder, 999);
    Assert.AreEqual(0, ServiceLocator.AlertGateway.CancelsSent);
}

Now lets look at the modifications we need to make to do this. For Request-Response Collaboration, we need to modify the stock exchange to record a partial execution.

class StockExchange...

  public void Execute(Order o, int volume) {
      o.ExecutedAmount += volume;
      if (o.IsFullyExecuted) outstandingOrders.Remove(o);
      ServiceLocator.RiskTracker.CheckForCancelledAlerts(o.Stock);
  }
  public void Execute(Order o) {
      Execute(o, o.Volume);
  }

class Order...

  public int ExecutedAmount {
      get { return executedVolume; }
      set { executedVolume = value; }
  }
  public bool IsFullyExecuted {
      get { return executedVolume == volume; }
  }
  private int executedVolume; 

Because there's a reference to the risk tracker right there, this helps remind us to consider to modify the risk tracker to take into account the partial execution case. However since the tracker gets the total outstanding by querying the stock exchange, we don't actually have to modify the risk tracker at all.

When we look at the Event Collaboration case, things are a bit more tricky. The basic modification to the stock exchange object is similar.

class StockExchange...

  public void Execute(Order o, int amount) {
      o.ExecutedAmount += amount;
      MessageBus.PublishExecution(o);
      if (o.IsFullyExecuted) outstandingOrders.Remove(o);
  }
  public void Execute(Order o)  {
      Execute(o, o.Volume);
  }

However since there's no indication of the link to the risk tracker, there's nothing to suggest that we should consider modifying it. Since the executed amount is a property of the order, everything will still compile cleanly, even with a statically typed system. But the risk tracker will now start giving out incorrect information, without any more obvious signs of failure, since it isn't properly capturing the data changes.

This, of course, is the inherent weakness of any system with implicit behavior - since you can't see it, you don't see what changes need to be made when you modify it. It can also be hard to debug, again because the flow of logic isn't made explicit in code.

What this shows is that using Event Collaboration makes some changes easier, but others harder. It's not easy to get a fair picture of the trade-offs, since we haven't seen much that really captures experience based on a real understanding of the two different styles.