Stream Reasoning, Take Two

June 24th, 2009 by Jack Rusher

Our blog publishing system hiccuped, placing a nearly empty draft of my recent literature review of papers from the 1st International Workshop on Stream Reasoning. Here, then, are some notes on a few of my favorite papers from that conference:

Research Chapters in the area of Stream Reasoning
E. Della Valle , S. Ceri , D. Braga, I. Celino , D. Frensel , F. van Harmelen, and G. Unel
A general review and background paper discussing the need for reasoning over streams in addition to the features commonly found in Stream Database Management Systems (SDMS). Use cases include various forms of forecasting and prediction, including mobile applications, public health risk monitoring and several web-based possibilities.

Situation-Aware Mobility: An Application for Stream Reasoning
Marko Luther and Sebastian Böhm
A team from DOCOMO Labs discusses a situation-aware mobile services platform. Streams of events from mobile telephones processed in the context of spatial, temporal, social and environmental factors, which data is then used to author novel mobile applications. This is a quite promising line of research, especially as regards real-time social networking.

Commonsense Spatial Reasoning About Heterogeneous Events in Urban Computing
Matteo Palmonari and Davide Bogni
Describes a system that monitors traffic/mobility in an urban area via a large collection of heterogeneous sensors. This sort of spatial reasoning is an interesting approach to routing traffic in times of congestion. I look forward to the day when Google Maps is able to give directions based on current conditions.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Aleri Reel-Time Interview: Wayne Wagner

June 15th, 2009 by Don DeLoach

In the first video in an ongoing weekly v-log series called “Aleri Reel-Time”, Aleri interviews Wayne Wagner, father of transaction cost analysis.


  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Research Roundup: 1st International Workshop on Stream Reasoning

June 15th, 2009 by Jack Rusher

The 1st International Workshop on Stream Reasoning, held May 31st at Heraklion, Crete, Greece, was a conference at the intersection of Stream Processing and Semantics-aware reasoning technologies.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Liquidity for Aleri

June 5th, 2009 by Tom Groenfeldt: techandfinance.com Journalist

Perhaps having some intelligent business practices linked to software will help prevent a recurrence of massive liquidity risk.

About a year ago I asked Andrew Aziz, EVP for risk solutions at Algorithmics, how the industry got trapped in a liquidity crisis that was a full stage production of the dress rehearsal that had been Long Term Capital Management in 2006. Simple enough, he explained, that was 11 years ago and the people who remembered were gone. Not entirely, of course, but the memory had certainly faded. The lesson from that near collapse should have been pretty easy to remember – risk is plentiful until it’s not, and acting as if it is always going to be amply available is asking for trouble.

At the GARP (Global Association for Risk Professionals) conference in London a few weeks ago, the always articulate Bob Scanlon, a senior risk executive at Standard Chartered, noted that SIVs got into trouble by lending for 30 years and borrowing for three months and assuming this could be done forever. Or at least the life of the loans.

It is encouraging to see a technology company like Aleri offering a solution. Often in finance technology drives the business, and here that could be a decided benefit. I was interested to see that the IAFE at its annual in New York 24 June will have a session on liquidity risk and the role innovations such as securitisation can play.

Fine, but what happens when the innovators look to max out leverage in new programs that assume permanent liquidity. That’s why banking experts now say that risk managers need a direct line to senior managers and to at least one or two board members who understand risk.

Citi’s Robert Rubin told Carol Loomis of Fortune, in an article published in November 2007, that he had never heard of a “liquidity put,” part of the bank’s collateralized debt obligations, until the summer of that year. And it was only in early November that the bank mentioned their existence to investors.

Banks are going to face the challenge of having someone on the receiving end who is paying attention and understands the incoming data. Solutions like the one that Aleri has developed will provide immediate information to the right players and give them the platform they need to manage their liquidity risks in accordance with the risk tolerance levels that the board have mandated them to stick to.

Tom Groenfeldt - Financial Services and Technology Journalist at techandfinance.com

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

What if… you knew your liquidity risk position?

June 2nd, 2009 by PJ Di Giammarino

The video on liquidity risk issues and the FSA’s new regime which we just completed cracks me up every time I watch Don DeLoach. His analogy describing banks’ inability to find their data “Honey, I can’t find my keys but they must be in the house since I drove home…” is spot on.

It’s a simple and clear message from the Aleri CEO – car keys, like data about liquidity information, aren’t much good if you can’t find them when you need them. Take a look at the video – it’s only 12 minutes – to see what a number of experts in the field have to say about monitoring liquidity information in real time and the value that would have provided a bank ahead of Lehman’s collapse.”

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Information-Retrieval vs Knowledge Discovery

May 20th, 2009 by Jack Rusher

I’ve been meaning for weeks to blog about a contributed article in the April issue of the Communications of the ACM — Database and Information-Retrieval Methods for Knowledge Discovery, Gerhard Weikum, Gjergji Kasneci, Maya Ramanath, and Fabian Suchanek — in which the authors advocate the integration of database systems (DB) and information retrieval (IR) methods to address emerging applications in large (especially web-scale) datasets.

The paper outlines the historical domain of each of the two approaches to information managing; DB for accounting, records and transaction processing systems, IR for text understanding, statistical ranking, and so on. In the 40 years of research that has gone into DB and IR there have been a few attempts to bridge between them (Datalog, probabilistic relational-algebra, similarity joins, &c), but none of them has really made the leap from research to production. The authors argue that managing large libraries of semi-structured text marked up with metadata — that is, essentially, Semantic Web-style data management — will be the use case that finally brings DB and IR together.

While reading the article, I couldn’t help but see these two disciplines as the forerunners of what I’ll call the two schools of CEP. There are those who feel that CEP is not CEP unless it uses the tools of IR, and others who feel that reactive streaming DB technologies are also a form of CEP. This post is not an effort to restart that argument, but rather a statement that the future of CEP — like the future of web-scale data management — is likely to involve a rapprochement of these two strands of research.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

TweetGrid: Continuous Queries for Twitter

May 19th, 2009 by Jack Rusher

I’ve been planning to whip up some clever hacks to demonstrate a few applications of CEP to twitter feeds, but in the meantime here’s someone else’s browser-based continuous query tool for twitter, TweetGrid. The interface only always text search queries, and doesn’t provide refinement or filtering of any kind, but it does allow one to run multiple queries at once on the same screen (maybe we can call this a “visual join?”).

Here’s a link that will take you to a page showing three continuously updated streams of tweets for the phrases “complex event processing,” “data visualization,” and “semantic web.”

I like to see things like this in the wild because it demonstrates that there are many persons working on problems for which our technology could be of great assistance, even if they’ve not necessarily heard of CEP.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Why SPLASH?

May 18th, 2009 by Jon Riecke

We often get a question: why did we design our own language SPLASH?  Why did we not use an existing imperative language, like C, C++, Java, or C#? or a scripting language like Perl or Python? or an easily embeddable functional language like Lua?

Two requirements drove us to designing our own language: predictable latency and ease-of-use.

The first requirement comes from the expected applications.  Consider, for example, a trading application that receives streaming quotes.  The application must respond not just quickly, but predictably.  If it takes 1 millisecond to process a quote, it might be fast enough.  If it takes 100 milliseconds to process a quote, we probably need more hardware.  But if it takes between 1 and 100 milliseconds to process a quote, it’s almost impossible to tune the application.  Should you buy more hardware?  How do you test?  What happens if the bad latencies occur during market stress points, as they almost assuredly will?  (For a related argument, see Edward Lee’s fascinating article in the latest issue of the Communications of the ACM.  Lee takes the point further: for real-time applications, “time” should be an explicit part of the computational model.)

In many languages like Java, C#, and Lua, it’s hard to control response time because of the need for garbage collection.  Our language SPLASH doesn’t require full-blown garbage collection.  The language manages memory—the user doesn’t have to, as in C or C++—but the language is designed so that memory can be managed with reference counting (no circular data structures, for instance).  That enables predictability, and doesn’t require tuning a garbage-collection subsystem.

The second requirement is less technical: we wanted our users to be able to code within the CEP environment as much as possible.  With SPLASH, you don’t need expert programmers to write code outside the CEP environment.  Anyone with some background in programming can write SPLASH with its familiar C-like syntax and data structures.  Anyone with a little background can tweak SPLASH code, all within the Studio; you don’t need a compiler, an IDE or shell, and the expertise to use them.  SPLASH thus follows the “little language” tradition in Unix.  Of course, if you want to write complicated algorithms, you still have the flexibility of using external Java or C/C++ libraries.  We expect, though, that most specialized event-processing code can be written in SPLASH.

None of the languages that we examined at the time met the desiderata of predictable latency and ease-of-use, and so we designed our own.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Wall Street Systems enhances FX Trading Platform with Aleri

May 6th, 2009 by Jeff Wootton

Good article in Dealing With Technology (DWT) on how Wall Street Systems is using Aleri CEP technology in their FX trading platform. Aleri CEP delivers enhanced throughput and real-time position management.

(unfortunately the full article is only available to DWT subscribers)

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia

Aleri works with LiRAN in London

April 24th, 2009 by Tom.Aleri

LiRAN (Liquidity Risk Action Network), a working group established by JWG-IT to identify reference industry solutions to the new and emerging requirements to improve the management of liquidity risk.  Aleri is a founding member of the working group and has been active in both identifying the challenges presented by new regulations surrounding liquidity risk management and in describing the requirements for a new information infrastructure to support risk manager and new regulatory reporting requirements such as those recently announced by the FSA in the UK.The discussions have allowed Aleri to identify and test the functional requirements of the Liquidity Risk Manager module of the Liquidity Management System (LMS) application suite.  It has also been an opportunity to discuss with potential partners how the solutions to new requirements can actually be implemented in financial institutions.It is clear from the LiRAN activities that regulators will demand implementation of both new reporting requirements and new operational liquidity management regimes in regulated institutions.  It is equally clear that traditional methods will be both difficult and expensive.  This presents significant opportunities for Aleri’s CEP based products and development technology to provide efficient, cost effective solutions in the liquidity risk management space.

  • Technorati
  • Digg
  • del.icio.us
  • Ma.gnolia