1 2 Previous Next 22 Replies Latest reply on Jul 10, 2008 10:16 AM by heiko.braun

    Contributing to SAM

    heiko.braun

      CEP
      I think what we require most at the moment are samples that model CEP use cases. While extending the samples I expect the current API to reveal it's weak points and limitations.

      GWT integration
      Another area that requires evaluation is the GWT integration.
      I was thinking about a REST interface towards GWT, because it plays nicely with Ajax frontends and would open SAM towards other use cases as well.

      Current value table (CVT)
      A CVT implementation that fits into GWT. It allows you to browse time windowed data (CEP results) and pick items for visualization and drill down.

        • 1. Re: Contributing to SAM
          marklittle

          CEP: do we need all CEP capabilities, or just a subset? I'm wondering about a CEP abstraction layer to isolate the backend implementation choices. If we had to model all the capabilities of a CEP engine then it'd make such a layer more complex.

          GWT: have you spoken with Mike Brock or Mic Neale?

          CVT: got more details?

          • 2. Re: Contributing to SAM
            objectiser

            General query - GWT versus Flex - which is RedHat's preferred choice?

            Have seen some DNA posts mentioning Flex - what are the pros/cons of each?

            • 3. Re: Contributing to SAM
              marklittle

              Both :-)

              • 4. Re: Contributing to SAM
                heiko.braun

                Adobe Flex? I think you have to payfor the development tools.

                • 5. Re: Contributing to SAM
                  heiko.braun

                   

                  a CEP abstraction layer to isolate the backend implementation choices


                  That's what I am currently trying todo. I think it will be possible for the core CEP concepts, where it get's dificult is the EPL (processing language) and maybe the event type system. Some CEP engine require you to describe event messages in SQL like manner (think CREATE TABLE ...) whereas others rely on other type systems (xsd, java).



                  • 6. Re: Contributing to SAM
                    heiko.braun

                     

                    do we need all CEP capabilities?


                    well, that's hard to tell. What are "all cpabilities"?
                    Do you know what information people try to derive from a monitoring solution? My approach would be to cover the most common CEP use cases (i.e pattern maching, time based matching, aggregation, filtering, etc) to check if the simulation and the core CEP abstraction API do their job, before diving into the UI stuff.



                    • 7. Re: Contributing to SAM
                      maeste

                       

                      "heiko.braun@jboss.com" wrote:
                      Adobe Flex? I think you have to payfor the development tools.


                      Yep, it's correct...if you want to use it.
                      Flex is pure (nice) xml and development tools isn't strictly needed.
                      In a nutshell, Flex pros is it don't needs compilation or deployment using an xml markup and so it could be generated runtime to change/create views on user's choice (IOW we can think views which is an interface to generate views). Cons: it need a plugin on client side
                      GWT pros is mainly it generate pure html +javascript. cons: it needs compilation and it's quite impossible at the moment to change/generates views runtime in the sense I described above (even if this project seems very promising to achieve this goal: http://blog.athico.com/2008/06/google-summer-of-code-project.html )

                      That's more or less a brief resume of what we discussed about on dna-dev ML and dna irc channel. Hoping it could help.

                      • 8. Re: Contributing to SAM
                        heiko.braun

                         

                        Flex is pure (nice) xml and development tools isn't strictly needed.


                        Sounds like the 80's. The thing I like about GWT, is that it's all Java in the first place and the compiler takes care of the rest. You can attach an eclipse debugger to it see what's going on.

                        IMO it's simple: No development tools, no development.

                        • 9. Re: Contributing to SAM
                          heiko.braun

                           

                          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.

                          • 10. Re: Contributing to SAM
                            maeste

                             

                            "heiko.braun@jboss.com" wrote:

                            Sounds like the 80's. The thing I like about GWT, is that it's all Java in the first place and the compiler takes care of the rest. You can attach an eclipse debugger to it see what's going on.


                            of course, I forgot to mention GWT debugger capabilities as pros of GWT

                            "heiko.braun@jboss.com" wrote:

                            IMO it's simple: No development tools, no development.


                            I'm not so drastic, since HTML and markup language had some fortune even without development tools, but I generally agree, GWT is better IMHO.
                            I put here my 2 cents on Flex, because I would point your attention on dynamic UI generation, which may be useful for SAM and have to be considered (not necessary on Flex IMHO, but I just resumed DNA discussions)


                            • 11. Re: Contributing to SAM
                              objectiser

                              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)?

                              • 12. Re: Contributing to SAM
                                maeste

                                Well,

                                GWT alone is quite raw in my opinion too.
                                It's nicer with ext integration, even if flex still be superior, but as said GWT generate pure html+js, flex use plugin and it can do more fireworks than standard browser.
                                Anyway gwt-ext isn't so bad in my humble opinion: http://www.gwt-ext.com/demo/

                                • 13. Re: Contributing to SAM
                                  marklittle

                                   

                                  "heiko.braun@jboss.com" wrote:
                                  a CEP abstraction layer to isolate the backend implementation choices


                                  That's what I am currently trying todo. I think it will be possible for the core CEP concepts, where it get's dificult is the EPL (processing language) and maybe the event type system. Some CEP engine require you to describe event messages in SQL like manner (think CREATE TABLE ...) whereas others rely on other type systems (xsd, java).



                                  I wonder if there's any mileage in us defining our own meta-language specific to SAM and then mapping that down to backend implementations? Again, this would only work if we are having to handle just a sub-set of the languages for mapping, otherwise it becomes difficult to do.

                                  • 14. Re: Contributing to SAM
                                    marklittle

                                     

                                    "heiko.braun@jboss.com" wrote:
                                    do we need all CEP capabilities?


                                    well, that's hard to tell. What are "all cpabilities"?
                                    Do you know what information people try to derive from a monitoring solution? My approach would be to cover the most common CEP use cases (i.e pattern maching, time based matching, aggregation, filtering, etc) to check if the simulation and the core CEP abstraction API do their job, before diving into the UI stuff.


                                    Hey, we're defining a new paradigm here so I have no idea what "all capabilities" are at the moment either ;-)

                                    1 2 Previous Next