Thursday, February 05, 2009

Follow-ups to Some Comments

Marco says:
>> What do you mean by "Entitlements on output events"?

I have blogged about this here before. When our CEP engine generates alerts, we do not want everyone to see them. There might be very few people who can see alerts on orders. Prop traders should not see many of the the alerts that sales traders see. One trading desk might not be able to receive the alerts that another trading desk should see.

We have the concept of coarse-grained and fine-grained alerts. A coarse-grained alert might be filtered out by role. For example, a particular alert should only be seen by a North American Cash Trader, and not by derivative traders. In the case of fine-grained entitlements, we might have to filter by certain data that is within the alert's payload. For example, someone might not be able to see an alert if the symbol is IBM and the volume is greater that 1000 shares.

There is also the matter of entitlements on real-time aggregations, but that is another long topic.

Charlie Skelton from KX says:
>> "don't make us code in Q" Please can you elaborate?

Charlie, I have written ad nauseum here about Kdb and Q. I actually started to learn Q a few months ago in order to be able to read some of the code that was thrown our way. I have a greater appreciation of Q than I did a few months ago, but I would not want to ask all of my developers to learn Q.

My opinion is that, if you have a facade (input adapter) to a database, then you should be able to code in some database-agnostic way and leave the db-specific language access to the drivers. Look what you can do with O/R frameworks like Hibernate and iBatis.

Hans asked about Unit Testing

When we first started to use Coral8, we actually wrote a C# application that did the exact same thing as our Coral8 application and we did reconciliations between the two. We had found an issue or two with Coral8, which they were able to fix fairly rapidly. We also found some issues with our Coral8 coding, which helped us learn Coral8 better.

Unit testing is still something that is not mature in our Coral8 processing, although we do have unit tests for our internal framework. We have fabricated data in flat files that we can pump into our C8 engine, and we can do regression testing against a known set of outputs. However, we know that we can do a better job.

I would like to hear more about Streambase's unit testing capabilities.

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


aRman aRtuc said...

Don't you think you can utilize the entitlements of the Middleware that's going to deliver the data as opposed to it being enforced by the CEP?
Tervela and other Middleware will provide you topic based entitlements.

marc said...


The thing is that we have many different kinds of notification methods, of which Tibco EMS is only one. We can send alerts out through email, through sockets, through various chat programs, etc. We want a common coarse and fine grained entitlements mechanism, so it is best to implement it ourselves.

Eddie said...

Hello Marc, Eddie here - co-founder of StreamBase from the Aurora research days...

Since you asked, I'd like to answer: on the unit testing front, StreamBase unit tests are:
- a specification of input data (using our feed simulator tool, thus giving us everything we do there; generated data, data file or even jdbc, with configurable rates and other options)
- an expected output definition (flat-file based), including things like out-of-order tolerance and wildcard-support (for field values that are not deterministic)
- all wrapped up into our Eclipse-based Studio, emitting results through the JUnit test framework (so we use their runner and we get Eclipse's front-end to display results).

It's not perfect and we have been improving it based on feedback; Suites, more flexibility on output matching -- a variety of features we get requests for, or those we discover as we run application tests in our own nightly test runs.

marc said...

Thanks Eddie ... you have something that we wish that our current CEP vendor would add. Good work.

Marco said...

Thanks for the explanation. The whole problem sounds like something one could build a complete outbound event distribution system around. For me the EAI guy, this sounds like a content based event routing problem based on role info. I'll put this into our idea box for new products ;)