About polling: we use a Token Bucket algorithm to minimize query latency. If a site allows 600 requests in 10 minutes, we actually will make up to 600 requests in the first instant, then wait for the 10-minute window to expire before issuing the next 600 requests. This approach gives much lower data latency than a simple rate like "1 per second." We still need to do some work here to space out redundant queries.
Also, the event architecture allows us to share tick data with any number of strategies, so the polling process only happens once no matter how many strategies are active. The model here is to accumulate real time data, not to poll for conditions. Instead of saying "fetch some data then analyze it", you write a strategy to accept new data and incrementally update its signals. Then it can react as soon as new data is received, instead of being on a polling timer. There are a couple markets now providing streaming data (finally) so again, writing your strategy to work incrementally will pay dividends as the data providers get more sophisticated and start to implement push feeds.
I also like antlr and could definitely see the usefulness of a DSL once we have the baseline system working.
@TimOlson: I got the same problem, too. I can execute drools rule sets with included java to access a depth, or so. But I'd like to get rid of this java for several reasons. The syntax (especially for the BigDecimal based prices and amounts) is ugly. I wanted use (and started just a bit) an antlr grammar for a trading language. I thought the advantage would be, that it's not just a definition of a language, but you can use it immediately to create your own compiler just by adding statements to the production to create code for esper or drools. I have to admit, that I've not heard about esper before your posting, so I cannot really comment yet how good it is for this purpose.
@benjyz: in my solution this class is a TradeSite
https://github.com/ReAzem/cryptocoin-tradelib/blob/master/core/src/de/andreas_rueckert/trade/site/TradeSite.javabut: you should never access a trade site directly! Most of them have strict rules how often you are allowed to make requests per second/minute/. Problem is, that you might have x bots running and you don't know what bot requests which data at which time. That's why I have a central ChartProvider class (not complete though), that controls those requests and also caches the results, so 2 bots requesting the depth for pair ab might actually only trigger 1 request to the actual exchange.
I also have situations in which a strategy applies to x exchanges or loops over all the exchanges to check for a certain condition.