5 Replies Latest reply on Jul 9, 2008 7:26 AM by marklittle

    SAM kickoff / requirements

    heiko.braun

      SAM (Service Activity Monitoring) is here and it will be big. Mark already wrote an excellent introduction [1] to service activity monitoring and I would like to use that opportunity to kick start the discussion about SAM's building blocks / technical assets.

      [1] http://jboss-overlord.blogspot.com/2008/06/goodbye-bambi-hello-samsi.html

      EventProcessor and streams

      SAM is going to be driven by a CEP engine which allows near real time analysis of event messages as well as inclusion of historical data. Consider it the "brain" behind SAM's BAM/BI capabilities. It basically deals with event message aggregation, filtering and forwarding. Any event processor can be associated with stream inputs and stream outputs. Stream input allows you to feed event messages into the event processor (i.e. JMS event stream input) while stream outputs basically act as a mechanism to forward event streams, either in order to react (on-when-then) or to really forward event streams within EPN's (event processor networks).

      Visualization and monitoring

      Monitoring should enable you to react on changes to your service infrastructure in a timely manner. In order to so, you need to see what's going on now and be able derive the required information which allows you to drive subsequent action. This process is highly dynamic and needs to be done at runtime. We'd expect users to compose views according to their needs, modify the queries at runtime and to drill down to a level of detail that reveals answers to their questions. Because this reaches across enterprise responsibilities (IT, Sales, Management) it gears towards less-technical people which are part of the decision taken process. Thus visualization and it's flexibility is key to monitoring service infrastructures.

      Simulation

      Event pattern recognition and correlation becomes a non trivial task if you think of an emerging complexity of service infrastructures. To derive the adequate fixture it requires thorough testing of the queries you put into place. Thus we consider event processing simulations a main step in overall development cycle.

        • 1. Re: SAM kickoff / requirements
          heiko.braun

          Maybe a word on the overall strategy:

          IMO SAM should gear towards becoming a general purpose solution that can be leveraged by several SOA-P components. Activity monitoring is about correlating event messages that derive from different sources (vertical as well as horizontal). SOA building blocks (Messaging, Rules, BPM, ESB, whatever) are complementary in their nature but still share a common monitoring requirement. SAM should become the umbrella project that adds monitoring capabilities to all these components.

          • 2. Re: SAM kickoff / requirements
            marklittle

            I agree. I'm not sure if it's an umbrella project or something that is used within all of these other projects though. It's definitely a project in its own right, that has hooks into a lot of places/projects (or should, if those projects take notice ;-) The more I think of it, the more I keep seeing the human spine and central nervous system analogy working here. But maybe that's just me ;-)?

            • 3. Re: SAM kickoff / requirements
              maeste

               

              "heiko.braun@jboss.com" wrote:

              Visualization and monitoring


              any ideas of architecture here? Seam base I guess, and what do you plan to use for UI? GWT? As we discussed in DNA GWT could not be the easiest choice for dynamically generated views (at least without this
              http://blog.athico.com/2008/06/google-summer-of-code-project.html)

              More general I can see here and there (dna views) similar problems. Heiko do you already subscribed dna-dev mailing list? Very low traffic and it would be interesting for you for these aspect and also because IMHO some sequencer could became an event source for SAM.

              BTW nice to read you here. Consider me available for contribution, I'm now taking a look to commited code.


              • 4. Re: SAM kickoff / requirements
                heiko.braun

                Currently we are talking about GWT, but didn't touch that part yet.

                For the next steps I would like to add more CEP samples that stress the simulation API and show what's possible. Once that is done I plan to write the first GWT cut through that allows you to maintain statements and bind them to viz components.

                My gut feeling is that I wouldn't go for Seam. Currently I am thinking about a REST interface, because it plays nicely with Ajax frontends and would open SAM towards other use cases as well.

                • 5. Re: SAM kickoff / requirements
                  marklittle

                  I think AtomPub would play well here too.

                  But as for GWT, you can do some pretty amazing things with it. Have a chat with Mike or Mic.