« February 2009 | Main | April 2009 »

March 2009

Tuesday, March 31, 2009

CEP in Transport and Logistics

Posted by David Olson

Now maybe I’m biased since my focus is CEP outside of capital markets but, the announcement of Royal Dirkzwager’s (Koninklijke Dirkzwager  if you’re keeping score in Dutch) use of Apama sets an important tone for CEP. Working with the team that pulled Royal Dirkzwager’s project together, it was easy to see that the business need was there to harness the value of their free-flowing events.

Transport and Logistics (T&L) has a vast fabric of events that range from all the management “systems” to supply chain events and telematics. Without CEP, analysis of those events is either siloed (with spotty real-time abilities) or aggregated a day late and a dollar short. The T&L industry is being squeezed for efficiency and chasing new revenue opportunities is challenging. In the case of Royal Dirkzwager, it didn’t take long for them to survey their domain and recognize that real-time visibility and analysis of events in their fabric could significantly enhance customer satisfaction and the bottom line. Royal Dirkzwager also appreciates that CEP projects aren’t protracted lifetime engagements. They’re looking forward to rapid results.

Royal Dirkzwager’s use of GPS, GIS events as well as information from Automatic Identification Systems (AIS) and Long Range Identification and Tracking (LRIT) systems, when correlated with their other infrastructure events, is where the magic is. Yes, they had all those events before but CEP pulls them together and makes them much more meaningful. They’re also going to leverage their Sonic ESB as a convenient on- and off-ramp for many of their events. And while Royal Dirkzwager’s a maritime logistics provider, it’s not a far stretch to see how other land- or sea-based LSPs can put themselves in a similar position. Whether they own, manage or contribute to the supply chain, the events are there – harnessing them should be an imperative. Royal Dirkzwager’s not our first in this space and it won’t be the last.

I think we’ve done the right thing by having a laser beam focus on capital markets. Truly, a demanding environment when it comes to performance and usability. All that experience gives us the ability to jump into other event-oriented markets with the tools and experience to take on any challenge.

To Royal Dirkzwager, thank you for making my day. Who’s next?

-DO

Monday, March 23, 2009

We're going on Twitter

Posted by Giles Nelson

Louis Lovas and myself, Giles Nelson, have started using Twitter to comment and respond to exciting things happening in the world of CEP (and perhaps beyond occasionally!).

The intent is to complement this blog. We'll be using Twitter to, perhaps, more impulsively report our thinking. We see Twitter as another good way to communicate thoughts and ideas.

We would be delighted if you chose to follow our "twitterings" (to use the lingo), and we'll be happy to follow you too.

Click here to follow Louis and here to follow Giles (you'll need to signup for a Twitter account).

Wednesday, March 18, 2009

Scalable Performance - a sneak preview of what's ahead for Apama

Posted by Louis Lovas

Engaging the Transmission - Scalable Performance When it Matters Most
We will soon be formally announcing the next major version of the Apama product, but I thought I would give a bit of a sneak preview here. We've added a number of significant enhancements to the product, one in particular I want to highlight is a new parallel execution model. Our CEP engine's new parallelism allows massive vertical scalability on multi-core hardware. We can leverage 8-way, 16-way even 32-way processors with ease.  We've enabled this capability by extending the Apama EPL with four new keywords. To explain requires a bit of background ...

In the Apama EPL, we have the notion of a “sub-monitor”, which can be thought of as a separate parameterized “instance” of a set of business logic that encompasses a scenario, a trading strategy for example. Each sub-monitor can load and maintain its own data (e.g. consider a sub-monitor as corresponding to a different occurence, with different timeouts, key indicators, client data, etc.) and can set up its own listeners to key into a (different or overlapping) subset of the event stream. This allows us to easily model factory like behavior, with each sub-monitor maintaining it's own state and possibly listening for different (sequences of) events – but applying the same basic logic including the actions to take when an event condition becomes true.  We call this our micro threading or mThread architecture.

In the latest Apama release, v4.1 we extended this and introduced the notion of contexts. These are silos of execution which take the factory model to the next level. ”context" is a reserved word in Apama 4.1 – it defines a collection of sub-monitors which can inter-operate in a protected address space, with strong semantics for inter-context communication (via event passing) similar in concept to the Erlang message passing programming model. Most importantly, it is also the unit of parallelization – allowing the same CEP engine to spawn multiple “contexts” which key into the event flow but execute in parallel on multi-core architectures. 

Contexts in Apama's EPL adhere to our language's basic event paradigm, providing a safe semantic for concurrency yet avoiding the typical race conditions common in multi-threaded programming in other languages (i.e. java) which require the use of mutexes, semaphores, etc.

"The world IS concurrent. It IS parallel. Things happen all over the place at the same time. I could not drive my car on the highway if I did not intuitively understand the notion of concurrency; pure message-passing concurrency is what we do all the time."

A great quote, one that we've taken to heart in the design of the parallelism now available in our EPL. Our approach is based on a deep understanding of the types of applications being built with the Apama platform. Our broad customer base provided us that advantage. For example, we took our Smart Order Router Solution Accelerator, enhanced it to use the context model and did a performance benchmark and achieved a 6.5 times increase in overall capacity on an 8-core server while holding to a steady low-latency threshold (notice we also improved overall performance in the v4.1version over previous versions as well).

This is a graph that compares the Capacity (number of concurrent open orders that can be processed in a specific timescale) of the Equities Smart Order Router for an increasing number of symbols. The comparison was on three versions of the Apama product. In the parallel version we have modified the SOR to partition symbols across contexts (each context goes on a processor core). The machine used for the experiment was an 8-core Intel Server. 

Apama's new enhanced parallel execution model is a reflection of how our customers use CEP technology to build out real world applications. The competitive landscape of CEP dwells on performance with wild claims of speed often without substance. It reminds me of a teenager revving their car's engine at a traffic light. You can see the needle on the tachometer race up, the engine makes a lot of noise, but to what purpose? With the new release of the Apama CEP platform it shows that we know how and when to engage the transmission.

Friday, March 13, 2009

An(other) industry award for Apama

Posted by Giles Nelson

I’m very pleased to announce that Apama has won the 2009 Technical Analyst award for “Best Automated Trading product”. The awards ceremony took place last night at the Sheraton Park Lane Hotel in London.

The judges not only considered the product itself and the way it was being used in electronic trading but also considered the customers who were using it too, so this is a really fantastic validation of Apama.

Here are some of the key attributes of Apama that were considered by the judges:

  • Apama is (of course) a CEP platform – one thing that that provides is flexibility. Once deployed to run an application such as FX aggregation, Apama can be applied equally well to algorithmically trade equity futures or any other type of asset.
  • Connectivity to a vast range of general software and trading specific systems.
  • Availability of Solution Accelerators for FX aggregation, order routing, algorithmic trading and others providing 90% of an end-user application.
  • Backtesting of trading strategies and ongoing strategy evolution.

For the record, the other finalists were Alphacet, Berkeley Futures (IQ Trader), Patsystems (Pro-Mark), QuantHouse (QuantFACTORY) and TradeStation.

Now, from a CEP technology perspective, this is the significant thing for me. Apama was up against, in quite a focussed industry category, a number of other vendors who do nothing else except build their products for use in capital markets. And yet, Apama won, thus demonstrating the fact that a general purpose CEP platform provides the first-class choice for organisations who want to flexibly deploy a whole range of event-driven applications. That’s great news for all CEP aficionados.

Now, where’s the rest of that bottle of bubbly?

Tuesday, March 10, 2009

The instance design pattern in the Apama EPL

Posted by Louis Lovas

<p>Instance design pattern in the Apama EPL</p>


In this my third installment on a series devoted to the Apama Event Processing Language (EPL), I'll continue where I left off last time in which I described the basic design of event passing for a consumer/producer model.  For this revision I've extended the model to support multiple consumers.  This introduces the instance management feature of the Apama EPL.  Instances or 'sub-monitors' as they're often referred to define a discrete unit of work. The unit of work can be very small (an analytic calculation) or very large (a whole trading algo). Each instance gets spawned with it's own parameter set, listens for it's own event streams and operates in a very singleton manner. To which I mean, within the semantics of the application an instance need only be concerned about managing itself not other instances. Overall, it is a  factory behavioral model extended to include an execution model.  This is a key aspect of the Apama EPL, making a common application requirement simple to implement, robust in design, and highly performant in the CEP model.

The Apama CEP engine manages the execution of these sub-monitors (also known as mThreads internally). In a typical production deployment, there would be 100's or 1000's of sub-monitors running. The spawn operator is the single statement in the language that accomplishes this unique feature. Spawn is basically a self-replicating scheme with certain behavioral rules. The main rule: the cloned instance does not get the active listeners (i.e. on all someEvent...) of the parent. It must establish it's own. Actually it's the perfect model for that factory-like behavior.  The clone does not want it's parents listeners, but would create it's own based on the parameters passed such as the symbol name in a trading algo or the subscriberId in our Producer example below. Speaking of our example ...

For the sake of brevity, I've just listed the extended Producer side of my consumer/producer example below. For the complete example, you can download it here.

The (extended) Item Producer.
package com.apamax.sample;

monitor ItemService {
   
    event ClearUserID {
        integer id;
    }
   
    UnsubscribeFromItems u;
        
    integer count := 0;
    float price := 0.0;
    listener l;
   
    action onload {
        // list of subscriber (user) identifiers
        sequence<integer> ids := [];
       
        SubscribeToItems s;
        on all SubscribeToItems():s {
            if ids.indexOf(s.subscriberId) = -1 then {
                ids.append(s.subscriberId);           
                 spawn startSubscriptions(s.subscriberId, s.item_name);      
            }
        }
       
        ClearUserID c;
        on all ClearUserID():c {
            log "in " + c.toString();   
            integer index := ids.indexOf(u.subscriberId);
                if index != -1 then {
                    ids.remove(index);
                }
        }
    }

    action startSubscriptions(integer this_subscriberId, string name) {
        log "in startSubscriptions";
       
        l := on all wait(0.1) {
            route Item(this_subscriberId, name, count, price);
            count := count + 1;
            price := price + 0.1;
        }

        on UnsubscribeFromItems(subscriberId = this_subscriberId):u {
            stopSubscriptions(u.subscriberId, u.item_name);
        }       
    }
   
    action stopSubscriptions(integer subscriberId, string name) {
        // do something to stop routing events
        log "in stopSubscriptions";
        l.quit();
        route ClearUserID(subscriberId);
    }
}

           


To get a general sense of what this bit of code is intended to do, I suggest a quick scan of my previous installment where I introduced this example.

The extended Item Producer is expected to manage multiple uniquely identified consumers. For that it must maintain a list of identifiers, one for each consumer.  It does that by appending and removing entries from an array (sequence<integer> ids).  his is a common idiom for tracking identifiers, syntactically it's similar in many imperative languages.

This example uses a single-cast event passing scheme where the Producer routes Item events uniquely tagged to the consumer (route Item(this_subscriberId, name, count, price)).

 On the consumer side, Item events are listened for based on a subscriberId (on all Item(subscriberId = myId)). It's the uniqueness of subscriberId (one per consumer) that defines this as a single-cast design. A common twist to this a multi-cast event passed scheme (not be be confused with the UDP multicast) where multiple consumers might be requesting the same information (i.e. the item_name in our example).  A well understood example of this would be a market data adapter providing trade data for the same symbol to multiple consumers.  The Item Producer would change very little to support a multi-cast event passing scheme.

In the listener "on all SubscribeToItems()", we spawn to the action startSubscriptions when we receive a  SubscribeToItems event from a consumer. We pass the parameters of  the consumer's identifier (s.subscriberId) and the item (s.item_name) to instantiate the new sub-monitor.  A new mThread of execution is created for the sub-monitor and it begins executing producing Item events. The parent monitor continues waiting (listening) for another SubscribeToItems event.

 You'll also notice the use of a private event ClearUserID, the purpose behind this is to communicate between the spawned sub-monitor(s) and main (parent) Monitor when an UnsubscribeFromItems request is received.  This is necesssary since the parent monitor manages the id's of connected consumers. A spawned sub-monitor uses this event to simply inform of termination.

The event paradigm in the Apama EPL extends far beyond the notion of processing data events. In one sense you could categorized events as data and control. Data events are consumed and processed by the CEP application. Control events direct the semantics of the application. 




 

This example is designed to illustrate a few powerful yet easy to use features of the Apama EPL:

  1. To highlight that the notion that managing multiple consumers (clients) becomes a simple and safe programming task in the Apama EPL. Instance management is an intrinsic design pattern based on the commonly understood factory model. We did not reinvent the wheel, we simply refined it and made it approachable in the CEP paradigm.
  2. Events are not just application data to be processes by monitors. They provide semantic control of an application as well.

Here's the complete example with the consumers, interface and producer

Once again thanks for reading,
Louie