This content has been marked as final.
Show 22 replies
-
15. Re: Contributing to SAM
marklittle Jul 10, 2008 7:29 AM (in response to heiko.braun)"heiko.braun@jboss.com" wrote:
CVT: got more details?
In CEP events arrive asynchronously and from different sources. They are quickly received and processed. The problem is that events from different sources pop up at different times, but it becomes important to correlate them anyway.
The CVT keeps them in memory and allows you to correlate events across sources that otherwise have been processed already. It would at least store the last indexed data from each source and can be extended to show a larger of event entries going back in time.
However preventing overflows and dealing with large sets of data, makes it somewhat complex to implement.
What about a disk-based backup to the in-memory store? Think "paging" and you may see what I'm thinking about: as the time extends, we flush the in-memory to backing store (or maybe replicated in-memory servers: that's another back-end implementation choice). -
16. Re: Contributing to SAM
marklittle Jul 10, 2008 7:30 AM (in response to heiko.braun)"objectiser" wrote:
Thanks for the feedback on GWT vs Flex - I now understand the basic differences, and understand that GWT may have developer benefits in respect of debugging.
However what about the user experience? From what I have seen, Flex seems far superior - do you have any example GWT sites that you would consider demonstrates its potential (from a usage perspective)?
Take a look at what the Drools team have done around the BRMS. It's all GWT based and looks excellent! -
17. Re: Contributing to SAM
heiko.braun Jul 10, 2008 9:36 AM (in response to heiko.braun)a disk-based backup to the in-memory store?
I think I would go to jboss cache and see what they got on stock right away. JBoss cache will probably deliver most of the complex stuff, we shouldn't implement on our own. -
18. Re: Contributing to SAM
heiko.braun Jul 10, 2008 9:39 AM (in response to heiko.braun)our own meta-language
yes, with unlimited resources we could probably do that ;)
But what more close to reality IMO, is working closely with the CEP academia out there and reach for standardization. I heard you are pretty good at that? -
19. Re: Contributing to SAM
heiko.braun Jul 10, 2008 9:41 AM (in response to heiko.braun)Honestly, superior or not. Flex is proprietary and will never make into OSS. We shouldn't consider it.
-
20. Re: Contributing to SAM
marklittle Jul 10, 2008 10:00 AM (in response to heiko.braun)"heiko.braun@jboss.com" wrote:
a disk-based backup to the in-memory store?
I think I would go to jboss cache and see what they got on stock right away. JBoss cache will probably deliver most of the complex stuff, we shouldn't implement on our own.
Yeah, that's kind of what I had in mind when I suggested "maybe replicated in-memory servers". It doesn't need to be fault tolerant: just available enough for our needs. -
21. Re: Contributing to SAM
marklittle Jul 10, 2008 10:02 AM (in response to heiko.braun)"heiko.braun@jboss.com" wrote:
our own meta-language
yes, with unlimited resources we could probably do that ;)
But what more close to reality IMO, is working closely with the CEP academia out there and reach for standardization. I heard you are pretty good at that?
Yes, I'd much prefer a standard around this too. I think that there are probably very few places that are trying to support multiple CEP implementations, so we have a good view on what is common and what could be standardised. -
22. Re: Contributing to SAM
heiko.braun Jul 10, 2008 10:16 AM (in response to heiko.braun)Not support for multiple implementations, but people already consider a common CEP language:
http://epthinking.blogspot.com/2007/09/event-processing-and-babylon-tower.html