Whoa....impressive work. When you say "I've connected to it in Java"...exactly how was that done ? Is Apama written in Java ? If not, did you use an API or what ?
I'm pretty sure that Apama is written in C++. They have something called an IAF (Integration Adapter Framework) that is a mix of XML, Java or C++, and their proprietary scripting language MonitorScript which is kind of Pascal-like. It's how events are passed into and out of the Apama "Correlator" (event engine). It's also what they use to provide datafeed connections and FIX connectivity. I have an IAF connecting Apama to my OMS for executions coming back from my DMA provider, and I also wrote one for my prediction engine, which is written in 100% pure Java. Data is processed within Apama, passed to the prediction engine, and the prediction events are injected back into Apama so that any execution strategy running in Apama can make use of them. Apama is single-threaded, so running any sort of complex calculations within it would bog it down. This is why it's a good idea to separate out any multi-threaded or complex apps. I also did it this way so that I could keep security tight around the prediction engine.
What level of support do you get? Also, do they throw in connectivity to a data provider and DMA provider? Do they have a built-in OMS? Esper wasn't even an option when I was looking around. Perhaps it's because I wasn't expecting to build a space shuttle with freeware. Not that there's anything wrong with that...
we grab prices off a message queue and connect to our own OMS. Not sure what is so difficult in writing the connection classes.
It's not that anything is particularly difficult, it's that there isn't enough time to do everything I need to do, and I would rather spend my cycles on strategy generation and modification, rather than on infrastructure. Also, I said something inaccurate about Apama. It is not single threaded, it has a FIFO main event queue (like anything else, otherwise how could you guarantee getting an ACK before a FILL, etc...?).
What Esper doesn't appear to supply is a rudimentary OMS or a simulator. It appears to be just a matching engine. Is this correct? How does the level of complexity it can handle compare to that of Apama? Has anyone used both? How many people are involved in YOUR operation? Do you have someone to code a GUI, a simulator, a finite-state machine, strategies, connectivity, etc...? How much are their salaries? Let's at least do an apples to apples comparison and be completely fair about it. Otherwise, some of the posts are just "drive-by shooting", and aren't very constructive. What sort of moron would buy a Ferrari when he can get a used AMC Pacer for free? Obviously, price is not the only factor.
In software, that is a bad analogy. Many companies run multi million or billion dollar operations on Linux. Solaris, Windows etc are infinitely more expensive by comparison. Mostly, the differences between Open Source and for pay software is support, ease of use, and other intangibles that often are critical, like psychological factors such as MSFT isn't going out of business any time soon. Another example, just about everyone knows how to program using Visual Studio tools from MSFT. If the tools you get don't have trained technicians to put together the software using those tools, then what use is it? Apache runs a huge % of the worlds websites and it doesn't cost a dime, whereas MSFTs IIS has to be run on Windows which isn't free. Same is true for MySQL vs Oracle or SQL Server etc. In this case, I don't know what the bullet points of comparisons are because I don't know anything about Apama. nitro