Coral8 just released version 5.3. We asked them for a KDB+ adapter, and they delivered. It was our opinion that KDB+ is used so frequently in capital markets firms that it made perfect sense that the coral8 developer should be able to read data from KDB as easily as they can read data from Oracle or SQL Server. Right now, you still need to write Q queries in Coral8's KDB adapter in order to fetch data from KDB+ .... I was hoping for a way that a developer can write a simple SQL statement and have the KDB adapter translate the query into Q, but that will have to wait for a future version. We ask them to write this stuff and make it available in their core product in the hopes that a lot of people use it, debug it, and ask Coral8 for more enhancements. They did a very basic version, and it will be enhanced per customer demand.
Coral8 also released a Reuters market data adapter, and from what I understand, it will be offered as a separate product that costs a not-too-trivial amount of money. Our internal framework has built-in market data adapters, so we won't be leveraging the Coral8 adapter, especially since it seems like a very vanilla adapter.
It is good that Coral8 has become aware of all of the various adapters needed for firms that do trading. It has been about 6 months since we had to explain what a FIX message was to the Coral8 people, and they have caught on pretty quickly. Coral8 probably had the least amount of captial markets experience of any of the CEP vendors, and they are rapidly catching up.
I read with interest the "exciting announcement" that the banking products side of Aleri were bought by Wall Street Systems. I don't know quite what to make of this. Was this a much-needed infusion of capital? Does Aleri really want to concentrate solely on CEP? Was the banking side of Aleri under-performing? I had lunch yesterday with a vendor of products that are sold into the capital markets space, and the vendor mentioned that the main CEP products that are evaluated are Apama and Streambase, with Coral8 gaining more and more interest. Combined with the difficulty of seeling into capital markets right now, I wonder if this is the first shoe to drop at Aleri.
(A note to PR agencies and Aleri newsletter writers ... you must think that the lives of your readers are pretty drab if you consider the above announcement to be "exciting".... you need to get out of your offices and see what kind of party animals your potential customers are!)
On the plus side, Aleri seems to still be the only company willing to take the STAC challenge. Where are you, Coral8? Apama? Streambase? Esper?
Sprint 2 has completed, and we are starting up Sprint 3. One of the things that is weighing heavily on my mind is the subject of entitlements and Derived Events. Certain users should not see certain derived events at all. Certain users should only see the partial contents of certain derived events.
There is no standard entitlements framework out there. Every IB that I have been with has had multiple custom-built entitlement frameworks. Morgan Stanley had at least 3, and 2 years ago, there was a group that had just been formed in order to build the mother of all entitlement frameworks.
Our entitlements framework needs to work hand-in-hand with our message bus. Most CEP applications are fairly simplistic, and their output goes into a single system, so there is no need for entitlements. Other CEP applications want to publish everything out to everyone ... a surveillance-type CEP application might be crippled if its output is only going to the security guard who is in the middle of a doughnut break. We can't let the prop traders see agency flow, and vice-versa. We can't let certain people on a single desk see what others on the desk are doing ... but the head of the desk should be able to see everything, and if the head of the desk is on vacation, the notifications should be transmitted to a chain of proxies.
It would be great if this kind of feature was built into a CEP engine ... given a derived event and a list of fine-grained entitlements, produce a "recipient list" of what message bus topics we send the derived event to.
©2008 Marc Adler - All Rights Reserved