First experiments with Velocity

I played around with Microsoft Velocity this past weekend, and I put together a little Order Cache. This application reads FIX messages off of a Tibco EMS bus, turns the messages into a C# object, and stores the object in the Velocity cache.

The primary key of the Order Cache is the ClOrdId, and this value should be unique for each trading day. Every time we see a FIX message, we check to see if an object with the same ClOrdId is in the cache. If it is, the Order object is updated, and store the object back in the cache. The order and execution state is kept, the quantities are updated, and Cancels and Cancel/Replaces are accounted for.

Admittedly, it is an extremely simple application, but I did it just so I could get familiar with the first CTP of Velocity. One cache holds all order objects. I did not try to alpha-partition the orders by symbols amongst different caches, nor did I experiment with multiple regions yet. Just simple Gets, Puts and Adds. I used Reflector a bit to peer into the Velocity code, and I could see that there is a lot more hidden under the surface of Velocity that has not been exposed yet.

Where can we use an object cache with a Complex Event Processing system?

First, we can use it to support resiliency of the CEP system. Let’s say that our CEP engine crashes in the middle of the day. We want to be able to retrieve the current state of our orders and executions, but we don’t want to have to go back to some sort of FIX repository, and play back each FIX message in order to re-create the state of the CEP engine. We can use the object cache to aid in recovering the state.

Now, most CEP engines have a facility where they can save state. For instance, with Coral8, you can choose to save all windows out to a database every n seconds or minutes. But, there is a certain tension with persistence of a CEP engine that is processing fast streams of real-time data. If you persist too frequently, you can slow down the CEP engine. If you persist infrequently, then you can lose a significant amount of your state if the CEP engine fails.

Most of the CEP engines will use an external database like SleepyCat, BerkeleyDB, and SQL Server to store state. But, depending on the size and shape of your saved data, recovery might be slow. So, why not save to an object cache? Reading and writing to an object cache would be extremely fast, and if the object cache supports asynchronous storage to a back-end database (or Microsoft’s SSDS), then you can have the best of both worlds.

Among the various CEP engines, I have not seen any built-in adapter support for object caches, like Gemfire, Tangasol, GigaSpaces, and Velocity. It would be fairly easy to write one, but it takes time to marshal between a native C# object and something like a Coral8 tuple.

Wish #1: The CEP vendors to explore object caches as a way to do persistence.

Another use of an object cache is to assist with a query façade. CEP engines like Coral8 support the notion of ad-hoc queries of the windows. If the CEP engine is aggregating data like orders and executions inside a publicly queryable window, any application should be able to query the CEP engine for something like “What are the top ten stocks that have open orders between 10:15 and 10:30”.

We don’t want external applications connecting directly to the CEP engine. There are compliance and security issues involved, and we don’t want any application tied to a particular variant of Streaming SQL. (Note: Coral8 has SQLite embedded in it, and that is what you use to query the public windows.) Therefore, we want to provide a “query façade”. All applications have to connect to the query façade in order to do ad-hoc querying of the CEP engine.

There is a cost to performing ad-hoc queries on the CEP engine while it is trying to process tons of streaming data. And, unless you index your public window correctly, the ad-hoc query can be very slow.

So, why not be able to query the object cache instead? If we are storing aggregated orders and execution data inside of Velocity, why can’t we query Velocity to find the top ten stocks that have open orders between 10:15 and 10:30? In other words, querying an object cache should be almost the same as querying an SQL Server database. I don’t care if the query language is SQL 92, Streaming SQL, LINQ, or the LINQ-ish thing that SSDS has…. As long as it’s not Q :-)

Wish #2: Microsoft will get together with the object cache and CEP vendors and come up with a common method to query database, caches, and CEP engines.




©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.

More Velocity

I had quite an interesting conversation the other day with Anil Nori, who is the "Distinguished Engineer" in charge of the Microsoft Velocity effort.

Anil comes to Microsoft from Oracle, so he is not driven by blind devotion to the Church of Microsoft. Anil is on a mission, wants to do what's right, and has a very similar vision that I do ... Velocity as the center of the "data universe".

One of the things that I was concerned about was interoperability in Velocity. It was good to know that this is a topic that Anil has been thinking about. In most investment banks, it's usually the native Java object caches that are installed, and each of the object caches have to find some way to interop with .NET clients. With Velocity, it is the other way around. Anil knows that, in order to be successful in our world, he has to provide interop with Java.

Quite truthfully, I have to say that Velocity has most .NET developers jumping up and down. I was on a call with the ".NET leadership" of my company today, and when I started talking about Velocity, everyone wanted to know how they could start playing with it. I have not seen this reaction caused by any Microsoft product in quite a while. WPF, WCF, and LINQ were greeted by "ho-hums" within my company. But Velocity was a different story.

This shows you how enterprise .NET architects and developers yearn to get the same tools that our Java brethren have had access to for a while. Yes, I know that Tangasol and Gigaspaces and Gemfire have .NET caches now. But, there is a certain glimmer in people's eyes when they hear that one of these enterprise technologies is coming from Microsoft. It's like welcoming home a lost-long relative.

Can we use Velocity to cache an entire day's worth of orders, and easily let a client retrieve any order by ID or a list of orders in a certain time range or a list of orders that use a certain algo?

Welcome home, Microsoft.... now, don't disappoint me!

©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.

SSDS and Velocity

I am talking to the SSDS team later today, but after watching some of their webcasts and looking at some of the code examples, I can see an absolutely perfect fit between SSDS and Velocity.

SSDS claims that they are ideal (right now) for apps that do not require ultra-low latency, mainly do the the transmission rates between the remote data center and the app. Velocity can sit right between the app and SSDS, so all data access goes through the cache.

Now, what we need SSDS to do is to asynchronously push updates to the SSDS containers out to the corresponding Velocity cache. This would hopefully minimize cache misses.

If used this way, then Velocity would need to adopt the SSDS concept of "Authority".

Meanwhile, I was very interested in this use of the Amazon S3 cloud by NASDAQ.


©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.

Microsoft Velocity

I have blogged a number of times about Distributed Object Caches. Almost all large financial firms have investments in object cache products. The three biggies are Gemfire, Tangasol Coherence (now part of Oracle), and GigaSpaces, and traditionally, these companies have targetted the Java and C++ marketplaces.

There have been niche products like NCache and memcache, but I have not seen an incredible amount of use of these out there in Wall Street.

If you have been reading this blog for any length of time, you know that I constantly lament the fact that Microsoft did not have what I refer to as "The Wall Street Stack".

However, last week, Microsoft landed with both big boots on the Wall Street Stack with the introduction of Velocity, their first attempt at a distributed object cache. Velocity, combined with some other efforts that Microsoft is working on (I have been sworn to secrecy on these efforts), dispells my ideas that Microsoft is ignoring enterprise technologies that matter to Wall Street, and especially, the area of trading systems.

I won't go into my thoughts on Distributed Object Caches, as I have blogged about them many times. But, I just want to list of few things that went through my mind as I read the Velocity announcement. I have a call this week with the Velocity team, and I hope to ask them these questions:

1) Will it remain free? I hope so. For the companies who pay lots and lots of money to Gemstone, Tangasol, and GigaSpaces, a free entry into this arena from a major vendor is sure to make the other vendors think about lowering their prices. In these economic times, financial companies will certainly welcome the chance to embrace this technology without having to spend a lot of money.

2) Will it be supported? If so, for how long, and by what product group? Microsoft is well known for coming out with technology that they let languish or deprecate. Right now, it seems like there is a small group in Microsoft that is working on Velocity. Does Microsoft have the appetite to build a support organization to properly support the product?

3) What are the synergies with other Microsoft technologies? LINQ? SQL Server? Gemfire has a SQL query language which you can apply to the data in their cache.

4) The Velocity team already said that they do not have push notifications yet. But, when they do, can we integrate a version of streaming LINQ (CLINQ?) with it? Push notifications is an extremely important feature that Velocity is missing right now, but it seems that a lot of people have told the Velocity team that this is a major shortfall.

5) Support for different messaging systems. Once we are able to get push notifications from Velocity, can we use JMS/Tibco EMS or RV?

6) Interface with Grids. It is no secret that the most prevelant use of object caches on Wall Street is with Grid Computing. How will Velocity interface with Compute Cluster? How about Digipede (if I know John Powers, he probably has support for Velocity already)?

7) Interoperability with non .NET-based systems?

8) What external database systems to they support? Will they support Oracle and Sybase? How about KDB?



©2008 Marc Adler - All Rights Reserved