"CEP is a method of aggregating large amounts of information in a database that uses Event Query Language (EQL) to sift through the data for meaningful information." This is a quote from David Luckham, he was of the originating researchers of CEP at Stanford and was cofounders of Rapide, the spinoff company of that research. I'm not biased. I've done my homework. My conclusions match those who pioneered the field. If you want to contune to argue with someone, argue with him. email: dcl at anna dot stanford dot edu. http://www.rfidjournal.com/article/articleview/1196/1/82/definitions_off
I know David Luckham very well. The notion in the marketing article you mention does not represent David's technical views. David's views are represented here: http://complexevents.com/?p=103 Where is says, in his direct quote: If you had done your homework you would not be picking out a quote from a collaboration with a marketing guy from ESP vendor Apama. More from the quote, which clearly shows that ESP is from the "database query" side of the house and CEP is more from real time messaging analytics: Have you read Dr. Luckhams original paper on CEP? Would you like a copy?
Attached (hope it works!) is a copy of David Luckham's original paper on CEP. You will note the opening quote in the original paper: Also, there is a guy who has put together a survey of papers that quote the original paper. You can see easily that CEP is not a database related technology from the referencing research papers. REF: http://www.timbass.info/index.php?title=CEPinDS Have you reviewed the CEP literature, or simply read a few marketing releases? The literature is clear on CEP. The database, data streaming vendors has created the confusion, which, unfortunately, has confused many in the market! Cheers!
99% agree Here is a man who uses experience plus logic... To filter out the silly NOISE all around him. One can view the "black boxes"... As a SEPARATE Zero Sum Game played ONLY amongst themselves... With the usual result... 10% of the boxes win all the money 90% of the boxes lose... While having negligible impact on the rest of the market. Back in the real world... A lot of money is still being made... Applying CLASSIC arb and market making techniques... Where execution is everything... and nobody talks. And there is nothing more pathetic... Than grown men who believe they can buy off-the-shelf "winning systems"... Not matter how sexy the con.
You don't know David. If you did, you wouldn't be writing all this bullshit. If you do know him "very well", it wouldn't take much to end this by asking him to email me from the address I gave and have him tell me why I'm wrong. PM me for my address. I'm calling 100% bullshit on this one. Nothing you wrote, nor any of David's articles/papers disproves anything I've said. If so, please show me with concrete coding examples, or using coding terminology as I have done. How the hell do you think a "real-time messaging analytic" engine works? I'll tell you how: in-memory db. I've given a couple different examples of how they work technically. You haven't showed shit except some links and quotes which disprove nothing. You don't know dick about programming, becuase if you did, you wouldn't be arguing. Get over yourself.
I'VE DONE MY F*CKIN' RESEARCH, TOO!!! IN TECHNICAL TERMS, ONELOT IS RIGHT, DIPSH*TS! EVERYTIME A SOCKET RECIEVES A MESSAGE IT GOES TO THE MEMORY, D*MB ASSES!!! WOULD I CALL IT F*CKIN' IN-MEMORY DB??? HELL NO!!! ANYWAYS, IT'LL BE HELLA FASTER IF I JUST STICK AN G*D DAMN ANALYTIC CODE IN THE MESSAGE CRACKER!!!! THAN CEP/ESP, FOOLS!!! ... or am I still missing things on this one...
You're still missing a bit, but you get the basic gist of it: processing data. They're not talking about solving the problem of handling singular messages. If they were, sticking code in the message parser would solve that problem though, you're right. What they're talking about is message streams. So, an example of an ESP stream would be time and sales for a given stock. If you just had the "ANALYTIC CODE IN THE MESSAGE CRACKER" (hehe), then you'd have no access to all the other prints that came before it. ESP processes and stores all the past events for x amount of time or x amount of prints or however it's being organized. The key here, is that it's being organized and stored. If it's going to be realtime, it's going to be done in-memory. I used the term "in-memory db" to generalize the concept of using hased arrays, tuples, or trees as in-memory storage containers and I don't think that was a poor term for it. CEP is the same thing, except instead of just one stream you're now using multiple streams. So arbing one stock against its index, you might want to calculate some sort of fair value for the stock which you would analyze against the stock stream. The FV is now itself a stream composed of multiple streams, making it a CEP stream. In-order for real-time processing of the stream, it must be orgainized the same way as the ESP stream using some sort of in-memory processor. Does that clarify things?
btw snaggy, every paper I read that you linked to, mentions using some sort of in-memory container for the cep implementation. the very first one mentions using tuples. if you read them, you didn't understand them.
YOU CALLIN ME A F*CKIN' CRACKA!!! ... wait... I'm not white (I keep forgetting... ) Anyways, I'll bite (agree mostly)... Here's a very excerpt of a simple Socket (.NET) code that handles messages: OK... the socket recieves a message, then turns it to a string. Then that data goes to another class method for whatever analysis you want to do... That said, from my understanding, CEP/ESP is worthless. someAnalysis can be dealing with the data however it wants whether it's multiple symbols or sources...