Progress Apama
I finally got my promised briefing with Progress Apama. Unfortunately, nobody particularly technical was able to attend, but I came away with a better understanding even so.
Unlike StreamBase or Truviso, Apama has a rules-based architecture. In essence, the rules engine maintains state of various kinds, and matches that state against desired patterns, called “scenarios.” They can handle 100s or possibly even 1000s of scenarios at once.
Progress fondly believes the rules-based architecture makes development easier for the kinds of apps people actually want to use the technology for, because the rules make it easier to launch actions once you have the results of filtering observations. This is fairly credible, because rules engines typically are great for developing apps – unless and until you want to do something outside their paradigm, at which point you wish you had something more flexible. What’s more, rules engines are a lot more flexible today than the brittle and limited expert system shells I overrated in the 1980s. On the other hand, I don’t notice anything going on with rules engines anywhere else in Progress.
Apama also introduced glitzy dashboard tools last year. Like other dashboards, this gets a lot of love in demos, and limited use after the sale. However, every single new customer is using dashboarding to at least some extent.
Here are some other highlights.
- They’re trying to push a whole technology stack, rather than focusing on feeds-and-speeds. While they made no claim of being wholly speed-competitive with StreamBase or Truviso, they did assert sub-millisecond latency. In any case, they clearly have a bunch of financial trading customers who think they’re plenty fast enough.
- They have historically been focused on the financial trading market, something that’s reinforced by their whole-product approach to it. However, they do have a casino customer and a retail/RFID customer.
- In the financial market, they claim that competitive products can’t handle multiple event streams and hence can’t correlate multiple asset classes. They further claim that they have developed adapters for many more specific financial information feeds than StreamBase has. (Apparently, these tend to be developed in response to the request of specific customers, as part of the initial engagement.) They also claim that this is a key competitive differentiator, which seems odd if it’s just a matter of doing a bit of consulting work. Unfortunately, StreamBase hasn’t gotten around to responding to my request for comment on that claim.
- They of course have a persistent data store for the (sole?) purpose of capturing information for backtesting, etc. This capture is done after the pattern detection/event processing has happened. (Presumably, this capture has only a trivial impact on performance.)
- The basic Apama in-memory data store is Progress’ own object-oriented product ObjectStore. This makes sense; rules and OO go well together.
Keep getting great research about data management and related technologies. Get a FREE subscription by RSS/Atom or e-mail!
Technorati Tags: Apama, StreamBase, Truviso, event processing, stream processing, algorithmic trading
Comments
One Response to “Progress Apama”
Leave a Reply
[...] dropped by Progress a couple of weeks ago for back-to-back briefings on Apama and EasyAsk. EasyAsk is Larry Harris’ second try at natural language query, after the [...]