You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Soumadeep Sen (JIRA)" <ji...@apache.org> on 2006/08/10 20:50:23 UTC
[jira] Created: (SM-534) Business Activity Monitoring Component
Business Activity Monitoring Component
--------------------------------------
Key: SM-534
URL: https://issues.apache.org/activemq/browse/SM-534
Project: ServiceMix
Issue Type: New Feature
Components: servicemix-common
Reporter: Soumadeep Sen
Attachments: servicemix-bam.zip
This Business Activity Monitoring component which works off an xpath expression. The xpath expression acts as a Key performance indicator. Based on the xpath evaluation, actions can be triggered. These actions can be implemented by users by extending the BAMAdaptor interface's execute method which takes an array of BAMActionParameter.
For providing details in terms of Rules,Actions and global parameters, the actions.xml, rules.xml and globalConfig.xml need to be populated. Sample files can be found in the src/test/resources directory and usage details for the BAMComponent can be found in the spring.xml file which is in the same directory.
The relationship between actions and rules is established by id reference where in the rules have actions IDs (no or more). Please refer the respective xml files.
All implemented adaptor classes could be put in the option lib directory of smx so that they can be referenced by the BAM processor. (A sample Adaptor called PrintAdaptor has been provided in the src...samples dir for reference)
Will be putting a wiki page shortly which will have more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Guillaume Nodet <gn...@gmail.com>.
On 8/13/06, soumadeep sen <so...@gmail.com> wrote:
>
> Exactly, that's what I have been thinking too.
Cool :)
Let me work on it a bit more. I was thinking whether to introduce a
> scripting or rules engine support such as Groovy or Drools to handle the
> rules, your thoughts.
Note that spring has built-in support for Groovy.
See
http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html#dynamic-language-beans-groovy
I was also thinking that the BAM component could leverage a rule engine
features such as Drools,
but i have not tought about it more yet.
You can take a look at the Drools lightweight commponent, it may be
helpfull.
Yeah, I agree about the EIP component-wiretap. Let me also utilize it.
Note that if you put a WireTap in front of the BAM component, the NMR will
already process this message asynchronously without delaying the main
exchange processing and the BAM component would not need to have an internal
thread pool to process the exchanges asynchronously (it would only receive
InOnly
exchanges to process).
Though i'm still not sure if this is the best way to go, as you would need
a WireTap endpoint in front of all your BAM endpoints. The other way would
be to include the eip component jar and inherit the WireTap to reuse the
code
as much as possible.
Soumadeep
>
>
> On 8/13/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > If the xml content is a stream, you first need to transform it to a
> > re-readable
> > xml source before any processing can be applied.
> > The EIP component does this and still give a NormalizedMessage
> > (take a look at it: oa.s.eip.support.MessageUtil).
> > You should really take a look at the wire tap implementation, as this is
> > the exact same thing that the BAM component does.
> >
> > If the Rule does not use a simple interface, the component
> > has to handle all your 16 cases internally.
> > I would prefer an extensible design, where the component would
> > first implement the xpath rule on the content and where rules
> > could be written by users for custom things. And as you say,
> > even a test on a property could have lots of different implementations:
> > someone may want to test a string property which will match
> > a regular expression, or an integer > value, ...
> >
> > I think all these cases can not be handled by the component, without
> > leading to a bad xml schema and a code which will be difficult to
> > maintain.
> >
> >
> > On 8/12/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > >
> > > I actually agree with you in all accounts but just trying to decouple
> > the
> > > config sources so that there is minimum dependency if it's fed from
> > > external
> > > sources. But either way the internal dependency will be there.
> > >
> > > One important thing that I need to mention here is that you had
> > commented
> > > about having an interface for what to evaluate, such as
> > properties,content
> > > etc... Let's discuss about this as the scope will broaden a lot:
> > >
> > > The possible sources that one could monitor are:
> > > From the MessageExchange: (These in my opinion are not relevant as
> they
> > > are
> > > more application specific and not content specific)
> > > 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6)
> > Operation
> > > 7)
> > > Pattern
> > > 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13)
> Message
> > >
> > > For (13) Message alone could have
> > > 13.1) Attachment (have to deal with DataHandler)
> > > 13.2) Property (handle Object)
> > > 13.3) SecuritySubject ( subject and principal)
> > > 13.4) Content (xml- being handled now)
> > >
> > > The rule definition will change as each of the above needs to be
> > uniquely
> > > handled. This will get pretty complicated as we may then have to have
> an
> > > interface for the Rule and have different implementations, example ->
> > > XPathRule could be an implementation where we can handle it based on
> > what
> > > we
> > > have, PropertyBasedRule would introduce another story where the
> > evaluation
> > > could be expression based, With attachment it could be anything -
> > depends
> > > on
> > > the DahaHandler...
> > >
> > > So rather than having Object evaluate(NormalizedMessage message) we
> > could
> > > have an interface for the BAMProcessor and pass appropriate values to
> > the
> > > implementation. The other thing is we can't pass the NormalizedMessage
> > > directly to the processor as it's an async operation so we should not
> > wait
> > > for any values to be passed from the processor. It will make it
> > blocking.
> > > (as in the processor we may take the content out so there would be no
> > > content left after delegation to the processor)
> > >
> > >
> > > Your thoughts...
> > >
> > > Soumadeep
> > >
> > > ----- Original Message -----
> > > From: "Guillaume Nodet" <gn...@gmail.com>
> > > To: <se...@geronimo.apache.org>
> > > Sent: Saturday, August 12, 2006 2:36 PM
> > > Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> > > Component
> > >
> > >
> > > > On 8/11/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > > >>
> > > >> Thanks for the reply, my comments are inline...
> > > >>
> > > >> ----- Original Message -----
> > > >> From: "Guillaume Nodet" <gn...@gmail.com>
> > > >> To: <se...@geronimo.apache.org>
> > > >> Sent: Friday, August 11, 2006 3:02 PM
> > > >> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> > > >> Component
> > > >>
> > > >>
> > > >> >A few comments:
> > > >> >
> > > >> > 1) Files should include the Apache standard header
> > > >>
> > > >> Will include them
> > > >>
> > > >> > 2) resources are loaded with xbean in BAMEndpoint.process
> > > >> > they override any definition specified directly with the
> > rules,
> > > >> > actions properties
> > > >> > IMHO, they should be loaded when activate is called (or at
> > > >> > initialization time,
> > > >> > by implementing the spring interface InitializingBean) and
> > only
> > > if
> > > >> the
> > > >> > properties
> > > >> > are not set
> > > >>
> > > >> I had kept both ways to load properties, but going forward I think
> > > >> resource based file loading would be the most appropriate solution
> so
> > > >> will
> > > >> keep that and remove the embedded beans defn. from BAMEndpoint. Let
> > me
> > > >> know
> > > >> if I missing the point.
> > > >
> > > >
> > > > Mmmh, i guess it depend. Having to create 4 xml files instead of 1
> is
> > > not
> > > > always the easiest way ...
> > > >
> > > >> 3) I don't see any use of the BAMGlobalConfig / Params classes
> > > >>
> > > >> This has been kept for future use where global parameters can be
> > > defined
> > > >> and used by adaptors as well as actions and rules
> > > >>
> > > >> > 4) Rules are not extensible. People will need to use to be able
> to
> > > >> check
> > > >> > for
> > > >> > properties, attachments, not only xpath on the content. So it
> > > >> > should
> > > >> be
> > > >> > an interface with
> > > >> > Object evaluate(MessageExchange exchange)
> > > >> > or
> > > >> > Object evaluate(NormalizedMessage message)
> > > >> > or anything like that.
> > > >>
> > > >> This is a good idea, for now let me just implement for content
> based
> > > then
> > > >> we can provide other adaptors later
> > > >>
> > > >> > 5) When using xpath, you need a way to configure the namesapces
> in
> > > use
> > > >> in
> > > >> > the xpath
> > > >> > expression, else you can not use it on xml requests with
> > > namespaces.
> > > >> > Take a look at the XPathPredicate in servicemix-eip
> > > >>
> > > >> Will make sure that it handles namespaces
> > > >>
> > > >> > 6) The configuration could leverage much more of spring/xbean
> > > features
> > > >> and
> > > >> > use a clean POJO model
> > > >> > which will be easily translated into a clean xml schema using
> > > >> > xbean.
> > > >> > They don't need to use id references and class names, as
> spring
> > > >> > will
> > > >> do
> > > >> > that easily.
> > > >> > And instead of using BAMActionParameters, these parameters
> > could
> > > be
> > > >> > easily configured on
> > > >> > the action / adaptor itself.
> > > >> >
> > > >> > So instead of having
> > > >> > <bam:bAMRule description="Email rule1" resultType="Boolean"
> > > >> > ruleName="emailRule1" xpath="/sample[@id='555-3482']">
> > > >> > <bam:actionDetails>
> > > >> > <bam:bAMActionDetail executeOn="true"
> actionID="printer"
> > > >> > active="true"/>
> > > >> > </bam:actionDetails>
> > > >> > </bam:bAMRule>
> > > >> > <bam:bAMAction actionName="printer" adaptorClass="
> > > >> > org.apache.servicemix.bam.sample.PrintAdaptor" description="For
> > > >> emailing">
> > > >> > <bam:params>
> > > >> > <bam:bAMActionParameter name="mobileNumber"
> > > value="405-3785"
> > > >> > type="String"/>
> > > >> > <bam:bAMActionParameter name="address" value="680,
> morse
> > > ave
> > > >> CA"
> > > >> > type="String"/>
> > > >> > </bam:params>
> > > >> > </bam:bAMAction>
> > > >> >
> > > >> > You could simply have
> > > >> > <bam:endpoint ...>
> > > >> > <bam:rule>
> > > >> > <bam:evaluator>
> > > >> > <bam:xpath xpath="/test:sample/@id
> > > " nsContext="#nsContext"
> > > >> />
> > > >> > </bam:evaluator>
> > > >> > <bam:actions>
> > > >> > <bam:action executeOn="554-345"
> adaptor="#printAdaptor"
> > > />
> > > >> > </bam:actions>
> > > >> > </bam:endpoint>
> > > >> >
> > > >> > <bam:print id="printAdaptor" output="stderr"
> > > mobileNumber="405-3785"
> > > >> > address="680, morse ave CA" />
> > > >> >
> > > >> > <bam:namespaceContext id="nsContext">
> > > >> > <bam:namespace prefix="test">http://test</bam:namespace>
> > > >> > </bam:namespaceContext>
> > > >> >
> > > >> > This is only an example to show how to use references, without
> > having
> > > >> > to
> > > >> > define IDs and classNames.
> > > >> > This lead to a much cleaner POJO model.
> > > >>
> > > >> The reason it has been repesented this way is because an action can
> > be
> > > >> referenced by multiple rules. So you can define an action once and
> > then
> > > >> reference it from different rules.This provides separation of
> action
> > > from
> > > >> rules.
> > > >>
> > > >> The relationship is as follows:(haven't included the attributes)
> > > >>
> > > >> BAMAction has one or more BAMActionParameter (bamActionParameter
> has
> > > >> details of the parameters that the action adaptor would use)
> > > >> BAMRule has one or more BAMActionDetail (bamActionDetail has the
> > > >> reference
> > > >> to actions using an ID)
> > > >>
> > > >> So from a user perspective in the rule.xml file they can specify an
> > > >> actionid which is there in the actions.xml . so even if the action
> > > >> implementation changes the rules file doesn't need to be changed.
> > > >>
> > > >> Consider a situation where these files could be coming from an
> > external
> > > >> source so rather than getting a whole bulk of xml we can isolate
> and
> > > deal
> > > >> with specific xmls.
> > > >>
> > > >> From an dev perspective, it's more of a parent child relationship->
> > > later
> > > >> on storage could be easy in a database maybe.
> > > >>
> > > >> I have used BAMActionParameter as well as BAMGlobalParameter ->
> they
> > > both
> > > >> are same so I guess, use one class and name it BAMParameter.
> > > >
> > > >
> > > > I do understand the relationship between the classes. What i meant
> > is
> > > > that
> > > > instead of implemeting the
> > > > wiring inside the BAM component, you could leverage
> > > spring features: you
> > > > can reference beans using their
> > > > ids and share them. The benefit is that you can have beans with
> > > > constructors and you can inject properties
> > > > on them, instead of only relying on a map of strings to do
> that. It'
> > s
> > > > just
> > > > more powerfull, but you could still
> > > > use IDs.
> > > >
> > > > Note that in spring, you can also import other spring files, so you
> > > could
> > > > just have one main spring file (the one containing the endpoint) ,
> > > import
> > > > the other ones and use references on these imported beans.
> > > >
> > > > It' s just about leveraging spring features ;)
> > > >
> > > > My $0.02 :-)
> > > >>
> > > >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
> > > >> >>
> > > >> >> Business Activity Monitoring Component
> > > >> >> --------------------------------------
> > > >> >>
> > > >> >> Key: SM-534
> > > >> >> URL:
> > > https://issues.apache.org/activemq/browse/SM-534
> > > >> >> Project: ServiceMix
> > > >> >> Issue Type: New Feature
> > > >> >> Components: servicemix-common
> > > >> >> Reporter: Soumadeep Sen
> > > >> >> Attachments: servicemix-bam.zip
> > > >> >>
> > > >> >> This Business Activity Monitoring component which works off an
> > xpath
> > > >> >> expression. The xpath expression acts as a Key performance
> > > indicator.
> > > >> Based
> > > >> >> on the xpath evaluation, actions can be triggered. These actions
> > can
> > > >> >> be
> > > >> >> implemented by users by extending the BAMAdaptor interface's
> > execute
> > > >> method
> > > >> >> which takes an array of BAMActionParameter.
> > > >> >>
> > > >> >> For providing details in terms of Rules,Actions and global
> > > parameters,
> > > >> the
> > > >> >> actions.xml, rules.xml and globalConfig.xml need to be
> populated.
> > > >> Sample
> > > >> >> files can be found in the src/test/resources directory and usage
> > > >> details for
> > > >> >> the BAMComponent can be found in the spring.xml file which is in
> > the
> > > >> same
> > > >> >> directory.
> > > >> >>
> > > >> >> The relationship between actions and rules is established by id
> > > >> reference
> > > >> >> where in the rules have actions IDs (no or more). Please refer
> the
> > > >> >> respective xml files.
> > > >> >>
> > > >> >> All implemented adaptor classes could be put in the option lib
> > > >> directory
> > > >> >> of smx so that they can be referenced by the BAM processor. (A
> > > sample
> > > >> >> Adaptor called PrintAdaptor has been provided in the
> src...samples
> > > dir
> > > >> for
> > > >> >> reference)
> > > >> >>
> > > >> >> Will be putting a wiki page shortly which will have more
> details.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> This message is automatically generated by JIRA.
> > > >> >> -
> > > >> >> If you think it was sent incorrectly contact one of the
> > > >> >> administrators:
> > > >> >> https://issues.apache.org/activemq/secure/Administrators.jspa
> > > >> >> -
> > > >> >> For more information on JIRA, see:
> > > >> http://www.atlassian.com/software/jira
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Cheers,
> > > >> > Guillaume Nodet
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
--
Cheers,
Guillaume Nodet
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by soumadeep sen <so...@gmail.com>.
Exactly, that's what I have been thinking too.
Let me work on it a bit more. I was thinking whether to introduce a
scripting or rules engine support such as Groovy or Drools to handle the
rules, your thoughts.
Yeah, I agree about the EIP component-wiretap. Let me also utilize it.
Soumadeep
On 8/13/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> If the xml content is a stream, you first need to transform it to a
> re-readable
> xml source before any processing can be applied.
> The EIP component does this and still give a NormalizedMessage
> (take a look at it: oa.s.eip.support.MessageUtil).
> You should really take a look at the wire tap implementation, as this is
> the exact same thing that the BAM component does.
>
> If the Rule does not use a simple interface, the component
> has to handle all your 16 cases internally.
> I would prefer an extensible design, where the component would
> first implement the xpath rule on the content and where rules
> could be written by users for custom things. And as you say,
> even a test on a property could have lots of different implementations:
> someone may want to test a string property which will match
> a regular expression, or an integer > value, ...
>
> I think all these cases can not be handled by the component, without
> leading to a bad xml schema and a code which will be difficult to
> maintain.
>
>
> On 8/12/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >
> > I actually agree with you in all accounts but just trying to decouple
> the
> > config sources so that there is minimum dependency if it's fed from
> > external
> > sources. But either way the internal dependency will be there.
> >
> > One important thing that I need to mention here is that you had
> commented
> > about having an interface for what to evaluate, such as
> properties,content
> > etc... Let's discuss about this as the scope will broaden a lot:
> >
> > The possible sources that one could monitor are:
> > From the MessageExchange: (These in my opinion are not relevant as they
> > are
> > more application specific and not content specific)
> > 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6)
> Operation
> > 7)
> > Pattern
> > 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message
> >
> > For (13) Message alone could have
> > 13.1) Attachment (have to deal with DataHandler)
> > 13.2) Property (handle Object)
> > 13.3) SecuritySubject ( subject and principal)
> > 13.4) Content (xml- being handled now)
> >
> > The rule definition will change as each of the above needs to be
> uniquely
> > handled. This will get pretty complicated as we may then have to have an
> > interface for the Rule and have different implementations, example ->
> > XPathRule could be an implementation where we can handle it based on
> what
> > we
> > have, PropertyBasedRule would introduce another story where the
> evaluation
> > could be expression based, With attachment it could be anything -
> depends
> > on
> > the DahaHandler...
> >
> > So rather than having Object evaluate(NormalizedMessage message) we
> could
> > have an interface for the BAMProcessor and pass appropriate values to
> the
> > implementation. The other thing is we can't pass the NormalizedMessage
> > directly to the processor as it's an async operation so we should not
> wait
> > for any values to be passed from the processor. It will make it
> blocking.
> > (as in the processor we may take the content out so there would be no
> > content left after delegation to the processor)
> >
> >
> > Your thoughts...
> >
> > Soumadeep
> >
> > ----- Original Message -----
> > From: "Guillaume Nodet" <gn...@gmail.com>
> > To: <se...@geronimo.apache.org>
> > Sent: Saturday, August 12, 2006 2:36 PM
> > Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> > Component
> >
> >
> > > On 8/11/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > >>
> > >> Thanks for the reply, my comments are inline...
> > >>
> > >> ----- Original Message -----
> > >> From: "Guillaume Nodet" <gn...@gmail.com>
> > >> To: <se...@geronimo.apache.org>
> > >> Sent: Friday, August 11, 2006 3:02 PM
> > >> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> > >> Component
> > >>
> > >>
> > >> >A few comments:
> > >> >
> > >> > 1) Files should include the Apache standard header
> > >>
> > >> Will include them
> > >>
> > >> > 2) resources are loaded with xbean in BAMEndpoint.process
> > >> > they override any definition specified directly with the
> rules,
> > >> > actions properties
> > >> > IMHO, they should be loaded when activate is called (or at
> > >> > initialization time,
> > >> > by implementing the spring interface InitializingBean) and
> only
> > if
> > >> the
> > >> > properties
> > >> > are not set
> > >>
> > >> I had kept both ways to load properties, but going forward I think
> > >> resource based file loading would be the most appropriate solution so
> > >> will
> > >> keep that and remove the embedded beans defn. from BAMEndpoint. Let
> me
> > >> know
> > >> if I missing the point.
> > >
> > >
> > > Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is
> > not
> > > always the easiest way ...
> > >
> > >> 3) I don't see any use of the BAMGlobalConfig / Params classes
> > >>
> > >> This has been kept for future use where global parameters can be
> > defined
> > >> and used by adaptors as well as actions and rules
> > >>
> > >> > 4) Rules are not extensible. People will need to use to be able to
> > >> check
> > >> > for
> > >> > properties, attachments, not only xpath on the content. So it
> > >> > should
> > >> be
> > >> > an interface with
> > >> > Object evaluate(MessageExchange exchange)
> > >> > or
> > >> > Object evaluate(NormalizedMessage message)
> > >> > or anything like that.
> > >>
> > >> This is a good idea, for now let me just implement for content based
> > then
> > >> we can provide other adaptors later
> > >>
> > >> > 5) When using xpath, you need a way to configure the namesapces in
> > use
> > >> in
> > >> > the xpath
> > >> > expression, else you can not use it on xml requests with
> > namespaces.
> > >> > Take a look at the XPathPredicate in servicemix-eip
> > >>
> > >> Will make sure that it handles namespaces
> > >>
> > >> > 6) The configuration could leverage much more of spring/xbean
> > features
> > >> and
> > >> > use a clean POJO model
> > >> > which will be easily translated into a clean xml schema using
> > >> > xbean.
> > >> > They don't need to use id references and class names, as spring
> > >> > will
> > >> do
> > >> > that easily.
> > >> > And instead of using BAMActionParameters, these parameters
> could
> > be
> > >> > easily configured on
> > >> > the action / adaptor itself.
> > >> >
> > >> > So instead of having
> > >> > <bam:bAMRule description="Email rule1" resultType="Boolean"
> > >> > ruleName="emailRule1" xpath="/sample[@id='555-3482']">
> > >> > <bam:actionDetails>
> > >> > <bam:bAMActionDetail executeOn="true" actionID="printer"
> > >> > active="true"/>
> > >> > </bam:actionDetails>
> > >> > </bam:bAMRule>
> > >> > <bam:bAMAction actionName="printer" adaptorClass="
> > >> > org.apache.servicemix.bam.sample.PrintAdaptor" description="For
> > >> emailing">
> > >> > <bam:params>
> > >> > <bam:bAMActionParameter name="mobileNumber"
> > value="405-3785"
> > >> > type="String"/>
> > >> > <bam:bAMActionParameter name="address" value="680, morse
> > ave
> > >> CA"
> > >> > type="String"/>
> > >> > </bam:params>
> > >> > </bam:bAMAction>
> > >> >
> > >> > You could simply have
> > >> > <bam:endpoint ...>
> > >> > <bam:rule>
> > >> > <bam:evaluator>
> > >> > <bam:xpath xpath="/test:sample/@id
> > " nsContext="#nsContext"
> > >> />
> > >> > </bam:evaluator>
> > >> > <bam:actions>
> > >> > <bam:action executeOn="554-345" adaptor="#printAdaptor"
> > />
> > >> > </bam:actions>
> > >> > </bam:endpoint>
> > >> >
> > >> > <bam:print id="printAdaptor" output="stderr"
> > mobileNumber="405-3785"
> > >> > address="680, morse ave CA" />
> > >> >
> > >> > <bam:namespaceContext id="nsContext">
> > >> > <bam:namespace prefix="test">http://test</bam:namespace>
> > >> > </bam:namespaceContext>
> > >> >
> > >> > This is only an example to show how to use references, without
> having
> > >> > to
> > >> > define IDs and classNames.
> > >> > This lead to a much cleaner POJO model.
> > >>
> > >> The reason it has been repesented this way is because an action can
> be
> > >> referenced by multiple rules. So you can define an action once and
> then
> > >> reference it from different rules.This provides separation of action
> > from
> > >> rules.
> > >>
> > >> The relationship is as follows:(haven't included the attributes)
> > >>
> > >> BAMAction has one or more BAMActionParameter (bamActionParameter has
> > >> details of the parameters that the action adaptor would use)
> > >> BAMRule has one or more BAMActionDetail (bamActionDetail has the
> > >> reference
> > >> to actions using an ID)
> > >>
> > >> So from a user perspective in the rule.xml file they can specify an
> > >> actionid which is there in the actions.xml . so even if the action
> > >> implementation changes the rules file doesn't need to be changed.
> > >>
> > >> Consider a situation where these files could be coming from an
> external
> > >> source so rather than getting a whole bulk of xml we can isolate and
> > deal
> > >> with specific xmls.
> > >>
> > >> From an dev perspective, it's more of a parent child relationship->
> > later
> > >> on storage could be easy in a database maybe.
> > >>
> > >> I have used BAMActionParameter as well as BAMGlobalParameter -> they
> > both
> > >> are same so I guess, use one class and name it BAMParameter.
> > >
> > >
> > > I do understand the relationship between the classes. What i meant
> is
> > > that
> > > instead of implemeting the
> > > wiring inside the BAM component, you could leverage
> > spring features: you
> > > can reference beans using their
> > > ids and share them. The benefit is that you can have beans with
> > > constructors and you can inject properties
> > > on them, instead of only relying on a map of strings to do that. It'
> s
> > > just
> > > more powerfull, but you could still
> > > use IDs.
> > >
> > > Note that in spring, you can also import other spring files, so you
> > could
> > > just have one main spring file (the one containing the endpoint) ,
> > import
> > > the other ones and use references on these imported beans.
> > >
> > > It' s just about leveraging spring features ;)
> > >
> > > My $0.02 :-)
> > >>
> > >>
> > >> >
> > >> >
> > >> >
> > >> > On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
> > >> >>
> > >> >> Business Activity Monitoring Component
> > >> >> --------------------------------------
> > >> >>
> > >> >> Key: SM-534
> > >> >> URL:
> > https://issues.apache.org/activemq/browse/SM-534
> > >> >> Project: ServiceMix
> > >> >> Issue Type: New Feature
> > >> >> Components: servicemix-common
> > >> >> Reporter: Soumadeep Sen
> > >> >> Attachments: servicemix-bam.zip
> > >> >>
> > >> >> This Business Activity Monitoring component which works off an
> xpath
> > >> >> expression. The xpath expression acts as a Key performance
> > indicator.
> > >> Based
> > >> >> on the xpath evaluation, actions can be triggered. These actions
> can
> > >> >> be
> > >> >> implemented by users by extending the BAMAdaptor interface's
> execute
> > >> method
> > >> >> which takes an array of BAMActionParameter.
> > >> >>
> > >> >> For providing details in terms of Rules,Actions and global
> > parameters,
> > >> the
> > >> >> actions.xml, rules.xml and globalConfig.xml need to be populated.
> > >> Sample
> > >> >> files can be found in the src/test/resources directory and usage
> > >> details for
> > >> >> the BAMComponent can be found in the spring.xml file which is in
> the
> > >> same
> > >> >> directory.
> > >> >>
> > >> >> The relationship between actions and rules is established by id
> > >> reference
> > >> >> where in the rules have actions IDs (no or more). Please refer the
> > >> >> respective xml files.
> > >> >>
> > >> >> All implemented adaptor classes could be put in the option lib
> > >> directory
> > >> >> of smx so that they can be referenced by the BAM processor. (A
> > sample
> > >> >> Adaptor called PrintAdaptor has been provided in the src...samples
> > dir
> > >> for
> > >> >> reference)
> > >> >>
> > >> >> Will be putting a wiki page shortly which will have more details.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> This message is automatically generated by JIRA.
> > >> >> -
> > >> >> If you think it was sent incorrectly contact one of the
> > >> >> administrators:
> > >> >> https://issues.apache.org/activemq/secure/Administrators.jspa
> > >> >> -
> > >> >> For more information on JIRA, see:
> > >> http://www.atlassian.com/software/jira
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > Cheers,
> > >> > Guillaume Nodet
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Guillaume Nodet <gn...@gmail.com>.
If the xml content is a stream, you first need to transform it to a
re-readable
xml source before any processing can be applied.
The EIP component does this and still give a NormalizedMessage
(take a look at it: oa.s.eip.support.MessageUtil).
You should really take a look at the wire tap implementation, as this is
the exact same thing that the BAM component does.
If the Rule does not use a simple interface, the component
has to handle all your 16 cases internally.
I would prefer an extensible design, where the component would
first implement the xpath rule on the content and where rules
could be written by users for custom things. And as you say,
even a test on a property could have lots of different implementations:
someone may want to test a string property which will match
a regular expression, or an integer > value, ...
I think all these cases can not be handled by the component, without
leading to a bad xml schema and a code which will be difficult to maintain.
On 8/12/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> I actually agree with you in all accounts but just trying to decouple the
> config sources so that there is minimum dependency if it's fed from
> external
> sources. But either way the internal dependency will be there.
>
> One important thing that I need to mention here is that you had commented
> about having an interface for what to evaluate, such as properties,content
> etc... Let's discuss about this as the scope will broaden a lot:
>
> The possible sources that one could monitor are:
> From the MessageExchange: (These in my opinion are not relevant as they
> are
> more application specific and not content specific)
> 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation
> 7)
> Pattern
> 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message
>
> For (13) Message alone could have
> 13.1) Attachment (have to deal with DataHandler)
> 13.2) Property (handle Object)
> 13.3) SecuritySubject ( subject and principal)
> 13.4) Content (xml- being handled now)
>
> The rule definition will change as each of the above needs to be uniquely
> handled. This will get pretty complicated as we may then have to have an
> interface for the Rule and have different implementations, example ->
> XPathRule could be an implementation where we can handle it based on what
> we
> have, PropertyBasedRule would introduce another story where the evaluation
> could be expression based, With attachment it could be anything - depends
> on
> the DahaHandler...
>
> So rather than having Object evaluate(NormalizedMessage message) we could
> have an interface for the BAMProcessor and pass appropriate values to the
> implementation. The other thing is we can't pass the NormalizedMessage
> directly to the processor as it's an async operation so we should not wait
> for any values to be passed from the processor. It will make it blocking.
> (as in the processor we may take the content out so there would be no
> content left after delegation to the processor)
>
>
> Your thoughts...
>
> Soumadeep
>
> ----- Original Message -----
> From: "Guillaume Nodet" <gn...@gmail.com>
> To: <se...@geronimo.apache.org>
> Sent: Saturday, August 12, 2006 2:36 PM
> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> Component
>
>
> > On 8/11/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >>
> >> Thanks for the reply, my comments are inline...
> >>
> >> ----- Original Message -----
> >> From: "Guillaume Nodet" <gn...@gmail.com>
> >> To: <se...@geronimo.apache.org>
> >> Sent: Friday, August 11, 2006 3:02 PM
> >> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> >> Component
> >>
> >>
> >> >A few comments:
> >> >
> >> > 1) Files should include the Apache standard header
> >>
> >> Will include them
> >>
> >> > 2) resources are loaded with xbean in BAMEndpoint.process
> >> > they override any definition specified directly with the rules,
> >> > actions properties
> >> > IMHO, they should be loaded when activate is called (or at
> >> > initialization time,
> >> > by implementing the spring interface InitializingBean) and only
> if
> >> the
> >> > properties
> >> > are not set
> >>
> >> I had kept both ways to load properties, but going forward I think
> >> resource based file loading would be the most appropriate solution so
> >> will
> >> keep that and remove the embedded beans defn. from BAMEndpoint. Let me
> >> know
> >> if I missing the point.
> >
> >
> > Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is
> not
> > always the easiest way ...
> >
> >> 3) I don't see any use of the BAMGlobalConfig / Params classes
> >>
> >> This has been kept for future use where global parameters can be
> defined
> >> and used by adaptors as well as actions and rules
> >>
> >> > 4) Rules are not extensible. People will need to use to be able to
> >> check
> >> > for
> >> > properties, attachments, not only xpath on the content. So it
> >> > should
> >> be
> >> > an interface with
> >> > Object evaluate(MessageExchange exchange)
> >> > or
> >> > Object evaluate(NormalizedMessage message)
> >> > or anything like that.
> >>
> >> This is a good idea, for now let me just implement for content based
> then
> >> we can provide other adaptors later
> >>
> >> > 5) When using xpath, you need a way to configure the namesapces in
> use
> >> in
> >> > the xpath
> >> > expression, else you can not use it on xml requests with
> namespaces.
> >> > Take a look at the XPathPredicate in servicemix-eip
> >>
> >> Will make sure that it handles namespaces
> >>
> >> > 6) The configuration could leverage much more of spring/xbean
> features
> >> and
> >> > use a clean POJO model
> >> > which will be easily translated into a clean xml schema using
> >> > xbean.
> >> > They don't need to use id references and class names, as spring
> >> > will
> >> do
> >> > that easily.
> >> > And instead of using BAMActionParameters, these parameters could
> be
> >> > easily configured on
> >> > the action / adaptor itself.
> >> >
> >> > So instead of having
> >> > <bam:bAMRule description="Email rule1" resultType="Boolean"
> >> > ruleName="emailRule1" xpath="/sample[@id='555-3482']">
> >> > <bam:actionDetails>
> >> > <bam:bAMActionDetail executeOn="true" actionID="printer"
> >> > active="true"/>
> >> > </bam:actionDetails>
> >> > </bam:bAMRule>
> >> > <bam:bAMAction actionName="printer" adaptorClass="
> >> > org.apache.servicemix.bam.sample.PrintAdaptor" description="For
> >> emailing">
> >> > <bam:params>
> >> > <bam:bAMActionParameter name="mobileNumber"
> value="405-3785"
> >> > type="String"/>
> >> > <bam:bAMActionParameter name="address" value="680, morse
> ave
> >> CA"
> >> > type="String"/>
> >> > </bam:params>
> >> > </bam:bAMAction>
> >> >
> >> > You could simply have
> >> > <bam:endpoint ...>
> >> > <bam:rule>
> >> > <bam:evaluator>
> >> > <bam:xpath xpath="/test:sample/@id
> " nsContext="#nsContext"
> >> />
> >> > </bam:evaluator>
> >> > <bam:actions>
> >> > <bam:action executeOn="554-345" adaptor="#printAdaptor"
> />
> >> > </bam:actions>
> >> > </bam:endpoint>
> >> >
> >> > <bam:print id="printAdaptor" output="stderr"
> mobileNumber="405-3785"
> >> > address="680, morse ave CA" />
> >> >
> >> > <bam:namespaceContext id="nsContext">
> >> > <bam:namespace prefix="test">http://test</bam:namespace>
> >> > </bam:namespaceContext>
> >> >
> >> > This is only an example to show how to use references, without having
> >> > to
> >> > define IDs and classNames.
> >> > This lead to a much cleaner POJO model.
> >>
> >> The reason it has been repesented this way is because an action can be
> >> referenced by multiple rules. So you can define an action once and then
> >> reference it from different rules.This provides separation of action
> from
> >> rules.
> >>
> >> The relationship is as follows:(haven't included the attributes)
> >>
> >> BAMAction has one or more BAMActionParameter (bamActionParameter has
> >> details of the parameters that the action adaptor would use)
> >> BAMRule has one or more BAMActionDetail (bamActionDetail has the
> >> reference
> >> to actions using an ID)
> >>
> >> So from a user perspective in the rule.xml file they can specify an
> >> actionid which is there in the actions.xml . so even if the action
> >> implementation changes the rules file doesn't need to be changed.
> >>
> >> Consider a situation where these files could be coming from an external
> >> source so rather than getting a whole bulk of xml we can isolate and
> deal
> >> with specific xmls.
> >>
> >> From an dev perspective, it's more of a parent child relationship->
> later
> >> on storage could be easy in a database maybe.
> >>
> >> I have used BAMActionParameter as well as BAMGlobalParameter -> they
> both
> >> are same so I guess, use one class and name it BAMParameter.
> >
> >
> > I do understand the relationship between the classes. What i meant is
> > that
> > instead of implemeting the
> > wiring inside the BAM component, you could leverage
> spring features: you
> > can reference beans using their
> > ids and share them. The benefit is that you can have beans with
> > constructors and you can inject properties
> > on them, instead of only relying on a map of strings to do that. It' s
> > just
> > more powerfull, but you could still
> > use IDs.
> >
> > Note that in spring, you can also import other spring files, so you
> could
> > just have one main spring file (the one containing the endpoint) ,
> import
> > the other ones and use references on these imported beans.
> >
> > It' s just about leveraging spring features ;)
> >
> > My $0.02 :-)
> >>
> >>
> >> >
> >> >
> >> >
> >> > On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
> >> >>
> >> >> Business Activity Monitoring Component
> >> >> --------------------------------------
> >> >>
> >> >> Key: SM-534
> >> >> URL:
> https://issues.apache.org/activemq/browse/SM-534
> >> >> Project: ServiceMix
> >> >> Issue Type: New Feature
> >> >> Components: servicemix-common
> >> >> Reporter: Soumadeep Sen
> >> >> Attachments: servicemix-bam.zip
> >> >>
> >> >> This Business Activity Monitoring component which works off an xpath
> >> >> expression. The xpath expression acts as a Key performance
> indicator.
> >> Based
> >> >> on the xpath evaluation, actions can be triggered. These actions can
> >> >> be
> >> >> implemented by users by extending the BAMAdaptor interface's execute
> >> method
> >> >> which takes an array of BAMActionParameter.
> >> >>
> >> >> For providing details in terms of Rules,Actions and global
> parameters,
> >> the
> >> >> actions.xml, rules.xml and globalConfig.xml need to be populated.
> >> Sample
> >> >> files can be found in the src/test/resources directory and usage
> >> details for
> >> >> the BAMComponent can be found in the spring.xml file which is in the
> >> same
> >> >> directory.
> >> >>
> >> >> The relationship between actions and rules is established by id
> >> reference
> >> >> where in the rules have actions IDs (no or more). Please refer the
> >> >> respective xml files.
> >> >>
> >> >> All implemented adaptor classes could be put in the option lib
> >> directory
> >> >> of smx so that they can be referenced by the BAM processor. (A
> sample
> >> >> Adaptor called PrintAdaptor has been provided in the src...samples
> dir
> >> for
> >> >> reference)
> >> >>
> >> >> Will be putting a wiki page shortly which will have more details.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> This message is automatically generated by JIRA.
> >> >> -
> >> >> If you think it was sent incorrectly contact one of the
> >> >> administrators:
> >> >> https://issues.apache.org/activemq/secure/Administrators.jspa
> >> >> -
> >> >> For more information on JIRA, see:
> >> http://www.atlassian.com/software/jira
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Cheers,
> >> > Guillaume Nodet
> >> >
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
>
>
--
Cheers,
Guillaume Nodet
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
I actually agree with you in all accounts but just trying to decouple the
config sources so that there is minimum dependency if it's fed from external
sources. But either way the internal dependency will be there.
One important thing that I need to mention here is that you had commented
about having an interface for what to evaluate, such as properties,content
etc... Let's discuss about this as the scope will broaden a lot:
The possible sources that one could monitor are:
>From the MessageExchange: (These in my opinion are not relevant as they are
more application specific and not content specific)
1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation 7)
Pattern
8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message
For (13) Message alone could have
13.1) Attachment (have to deal with DataHandler)
13.2) Property (handle Object)
13.3) SecuritySubject ( subject and principal)
13.4) Content (xml- being handled now)
The rule definition will change as each of the above needs to be uniquely
handled. This will get pretty complicated as we may then have to have an
interface for the Rule and have different implementations, example ->
XPathRule could be an implementation where we can handle it based on what we
have, PropertyBasedRule would introduce another story where the evaluation
could be expression based, With attachment it could be anything - depends on
the DahaHandler...
So rather than having Object evaluate(NormalizedMessage message) we could
have an interface for the BAMProcessor and pass appropriate values to the
implementation. The other thing is we can't pass the NormalizedMessage
directly to the processor as it's an async operation so we should not wait
for any values to be passed from the processor. It will make it blocking.
(as in the processor we may take the content out so there would be no
content left after delegation to the processor)
Your thoughts...
Soumadeep
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Saturday, August 12, 2006 2:36 PM
Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component
> On 8/11/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>
>> Thanks for the reply, my comments are inline...
>>
>> ----- Original Message -----
>> From: "Guillaume Nodet" <gn...@gmail.com>
>> To: <se...@geronimo.apache.org>
>> Sent: Friday, August 11, 2006 3:02 PM
>> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
>> Component
>>
>>
>> >A few comments:
>> >
>> > 1) Files should include the Apache standard header
>>
>> Will include them
>>
>> > 2) resources are loaded with xbean in BAMEndpoint.process
>> > they override any definition specified directly with the rules,
>> > actions properties
>> > IMHO, they should be loaded when activate is called (or at
>> > initialization time,
>> > by implementing the spring interface InitializingBean) and only if
>> the
>> > properties
>> > are not set
>>
>> I had kept both ways to load properties, but going forward I think
>> resource based file loading would be the most appropriate solution so
>> will
>> keep that and remove the embedded beans defn. from BAMEndpoint. Let me
>> know
>> if I missing the point.
>
>
> Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not
> always the easiest way ...
>
>> 3) I don't see any use of the BAMGlobalConfig / Params classes
>>
>> This has been kept for future use where global parameters can be defined
>> and used by adaptors as well as actions and rules
>>
>> > 4) Rules are not extensible. People will need to use to be able to
>> check
>> > for
>> > properties, attachments, not only xpath on the content. So it
>> > should
>> be
>> > an interface with
>> > Object evaluate(MessageExchange exchange)
>> > or
>> > Object evaluate(NormalizedMessage message)
>> > or anything like that.
>>
>> This is a good idea, for now let me just implement for content based then
>> we can provide other adaptors later
>>
>> > 5) When using xpath, you need a way to configure the namesapces in use
>> in
>> > the xpath
>> > expression, else you can not use it on xml requests with namespaces.
>> > Take a look at the XPathPredicate in servicemix-eip
>>
>> Will make sure that it handles namespaces
>>
>> > 6) The configuration could leverage much more of spring/xbean features
>> and
>> > use a clean POJO model
>> > which will be easily translated into a clean xml schema using
>> > xbean.
>> > They don't need to use id references and class names, as spring
>> > will
>> do
>> > that easily.
>> > And instead of using BAMActionParameters, these parameters could be
>> > easily configured on
>> > the action / adaptor itself.
>> >
>> > So instead of having
>> > <bam:bAMRule description="Email rule1" resultType="Boolean"
>> > ruleName="emailRule1" xpath="/sample[@id='555-3482']">
>> > <bam:actionDetails>
>> > <bam:bAMActionDetail executeOn="true" actionID="printer"
>> > active="true"/>
>> > </bam:actionDetails>
>> > </bam:bAMRule>
>> > <bam:bAMAction actionName="printer" adaptorClass="
>> > org.apache.servicemix.bam.sample.PrintAdaptor" description="For
>> emailing">
>> > <bam:params>
>> > <bam:bAMActionParameter name="mobileNumber" value="405-3785"
>> > type="String"/>
>> > <bam:bAMActionParameter name="address" value="680, morse ave
>> CA"
>> > type="String"/>
>> > </bam:params>
>> > </bam:bAMAction>
>> >
>> > You could simply have
>> > <bam:endpoint ...>
>> > <bam:rule>
>> > <bam:evaluator>
>> > <bam:xpath xpath="/test:sample/@id" nsContext="#nsContext"
>> />
>> > </bam:evaluator>
>> > <bam:actions>
>> > <bam:action executeOn="554-345" adaptor="#printAdaptor" />
>> > </bam:actions>
>> > </bam:endpoint>
>> >
>> > <bam:print id="printAdaptor" output="stderr" mobileNumber="405-3785"
>> > address="680, morse ave CA" />
>> >
>> > <bam:namespaceContext id="nsContext">
>> > <bam:namespace prefix="test">http://test</bam:namespace>
>> > </bam:namespaceContext>
>> >
>> > This is only an example to show how to use references, without having
>> > to
>> > define IDs and classNames.
>> > This lead to a much cleaner POJO model.
>>
>> The reason it has been repesented this way is because an action can be
>> referenced by multiple rules. So you can define an action once and then
>> reference it from different rules.This provides separation of action from
>> rules.
>>
>> The relationship is as follows:(haven't included the attributes)
>>
>> BAMAction has one or more BAMActionParameter (bamActionParameter has
>> details of the parameters that the action adaptor would use)
>> BAMRule has one or more BAMActionDetail (bamActionDetail has the
>> reference
>> to actions using an ID)
>>
>> So from a user perspective in the rule.xml file they can specify an
>> actionid which is there in the actions.xml . so even if the action
>> implementation changes the rules file doesn't need to be changed.
>>
>> Consider a situation where these files could be coming from an external
>> source so rather than getting a whole bulk of xml we can isolate and deal
>> with specific xmls.
>>
>> From an dev perspective, it's more of a parent child relationship-> later
>> on storage could be easy in a database maybe.
>>
>> I have used BAMActionParameter as well as BAMGlobalParameter -> they both
>> are same so I guess, use one class and name it BAMParameter.
>
>
> I do understand the relationship between the classes. What i meant is
> that
> instead of implemeting the
> wiring inside the BAM component, you could leverage spring features: you
> can reference beans using their
> ids and share them. The benefit is that you can have beans with
> constructors and you can inject properties
> on them, instead of only relying on a map of strings to do that. It' s
> just
> more powerfull, but you could still
> use IDs.
>
> Note that in spring, you can also import other spring files, so you could
> just have one main spring file (the one containing the endpoint) , import
> the other ones and use references on these imported beans.
>
> It' s just about leveraging spring features ;)
>
> My $0.02 :-)
>>
>>
>> >
>> >
>> >
>> > On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
>> >>
>> >> Business Activity Monitoring Component
>> >> --------------------------------------
>> >>
>> >> Key: SM-534
>> >> URL: https://issues.apache.org/activemq/browse/SM-534
>> >> Project: ServiceMix
>> >> Issue Type: New Feature
>> >> Components: servicemix-common
>> >> Reporter: Soumadeep Sen
>> >> Attachments: servicemix-bam.zip
>> >>
>> >> This Business Activity Monitoring component which works off an xpath
>> >> expression. The xpath expression acts as a Key performance indicator.
>> Based
>> >> on the xpath evaluation, actions can be triggered. These actions can
>> >> be
>> >> implemented by users by extending the BAMAdaptor interface's execute
>> method
>> >> which takes an array of BAMActionParameter.
>> >>
>> >> For providing details in terms of Rules,Actions and global parameters,
>> the
>> >> actions.xml, rules.xml and globalConfig.xml need to be populated.
>> Sample
>> >> files can be found in the src/test/resources directory and usage
>> details for
>> >> the BAMComponent can be found in the spring.xml file which is in the
>> same
>> >> directory.
>> >>
>> >> The relationship between actions and rules is established by id
>> reference
>> >> where in the rules have actions IDs (no or more). Please refer the
>> >> respective xml files.
>> >>
>> >> All implemented adaptor classes could be put in the option lib
>> directory
>> >> of smx so that they can be referenced by the BAM processor. (A sample
>> >> Adaptor called PrintAdaptor has been provided in the src...samples dir
>> for
>> >> reference)
>> >>
>> >> Will be putting a wiki page shortly which will have more details.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> This message is automatically generated by JIRA.
>> >> -
>> >> If you think it was sent incorrectly contact one of the
>> >> administrators:
>> >> https://issues.apache.org/activemq/secure/Administrators.jspa
>> >> -
>> >> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
>
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Guillaume Nodet <gn...@gmail.com>.
On 8/11/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> Thanks for the reply, my comments are inline...
>
> ----- Original Message -----
> From: "Guillaume Nodet" <gn...@gmail.com>
> To: <se...@geronimo.apache.org>
> Sent: Friday, August 11, 2006 3:02 PM
> Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring
> Component
>
>
> >A few comments:
> >
> > 1) Files should include the Apache standard header
>
> Will include them
>
> > 2) resources are loaded with xbean in BAMEndpoint.process
> > they override any definition specified directly with the rules,
> > actions properties
> > IMHO, they should be loaded when activate is called (or at
> > initialization time,
> > by implementing the spring interface InitializingBean) and only if
> the
> > properties
> > are not set
>
> I had kept both ways to load properties, but going forward I think
> resource based file loading would be the most appropriate solution so will
> keep that and remove the embedded beans defn. from BAMEndpoint. Let me know
> if I missing the point.
Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not
always the easiest way ...
> 3) I don't see any use of the BAMGlobalConfig / Params classes
>
> This has been kept for future use where global parameters can be defined
> and used by adaptors as well as actions and rules
>
> > 4) Rules are not extensible. People will need to use to be able to
> check
> > for
> > properties, attachments, not only xpath on the content. So it should
> be
> > an interface with
> > Object evaluate(MessageExchange exchange)
> > or
> > Object evaluate(NormalizedMessage message)
> > or anything like that.
>
> This is a good idea, for now let me just implement for content based then
> we can provide other adaptors later
>
> > 5) When using xpath, you need a way to configure the namesapces in use
> in
> > the xpath
> > expression, else you can not use it on xml requests with namespaces.
> > Take a look at the XPathPredicate in servicemix-eip
>
> Will make sure that it handles namespaces
>
> > 6) The configuration could leverage much more of spring/xbean features
> and
> > use a clean POJO model
> > which will be easily translated into a clean xml schema using xbean.
> > They don't need to use id references and class names, as spring will
> do
> > that easily.
> > And instead of using BAMActionParameters, these parameters could be
> > easily configured on
> > the action / adaptor itself.
> >
> > So instead of having
> > <bam:bAMRule description="Email rule1" resultType="Boolean"
> > ruleName="emailRule1" xpath="/sample[@id='555-3482']">
> > <bam:actionDetails>
> > <bam:bAMActionDetail executeOn="true" actionID="printer"
> > active="true"/>
> > </bam:actionDetails>
> > </bam:bAMRule>
> > <bam:bAMAction actionName="printer" adaptorClass="
> > org.apache.servicemix.bam.sample.PrintAdaptor" description="For
> emailing">
> > <bam:params>
> > <bam:bAMActionParameter name="mobileNumber" value="405-3785"
> > type="String"/>
> > <bam:bAMActionParameter name="address" value="680, morse ave
> CA"
> > type="String"/>
> > </bam:params>
> > </bam:bAMAction>
> >
> > You could simply have
> > <bam:endpoint ...>
> > <bam:rule>
> > <bam:evaluator>
> > <bam:xpath xpath="/test:sample/@id" nsContext="#nsContext"
> />
> > </bam:evaluator>
> > <bam:actions>
> > <bam:action executeOn="554-345" adaptor="#printAdaptor" />
> > </bam:actions>
> > </bam:endpoint>
> >
> > <bam:print id="printAdaptor" output="stderr" mobileNumber="405-3785"
> > address="680, morse ave CA" />
> >
> > <bam:namespaceContext id="nsContext">
> > <bam:namespace prefix="test">http://test</bam:namespace>
> > </bam:namespaceContext>
> >
> > This is only an example to show how to use references, without having to
> > define IDs and classNames.
> > This lead to a much cleaner POJO model.
>
> The reason it has been repesented this way is because an action can be
> referenced by multiple rules. So you can define an action once and then
> reference it from different rules.This provides separation of action from
> rules.
>
> The relationship is as follows:(haven't included the attributes)
>
> BAMAction has one or more BAMActionParameter (bamActionParameter has
> details of the parameters that the action adaptor would use)
> BAMRule has one or more BAMActionDetail (bamActionDetail has the reference
> to actions using an ID)
>
> So from a user perspective in the rule.xml file they can specify an
> actionid which is there in the actions.xml . so even if the action
> implementation changes the rules file doesn't need to be changed.
>
> Consider a situation where these files could be coming from an external
> source so rather than getting a whole bulk of xml we can isolate and deal
> with specific xmls.
>
> From an dev perspective, it's more of a parent child relationship-> later
> on storage could be easy in a database maybe.
>
> I have used BAMActionParameter as well as BAMGlobalParameter -> they both
> are same so I guess, use one class and name it BAMParameter.
I do understand the relationship between the classes. What i meant is that
instead of implemeting the
wiring inside the BAM component, you could leverage spring features: you
can reference beans using their
ids and share them. The benefit is that you can have beans with
constructors and you can inject properties
on them, instead of only relying on a map of strings to do that. It' s just
more powerfull, but you could still
use IDs.
Note that in spring, you can also import other spring files, so you could
just have one main spring file (the one containing the endpoint) , import
the other ones and use references on these imported beans.
It' s just about leveraging spring features ;)
My $0.02 :-)
>
>
> >
> >
> >
> > On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
> >>
> >> Business Activity Monitoring Component
> >> --------------------------------------
> >>
> >> Key: SM-534
> >> URL: https://issues.apache.org/activemq/browse/SM-534
> >> Project: ServiceMix
> >> Issue Type: New Feature
> >> Components: servicemix-common
> >> Reporter: Soumadeep Sen
> >> Attachments: servicemix-bam.zip
> >>
> >> This Business Activity Monitoring component which works off an xpath
> >> expression. The xpath expression acts as a Key performance indicator.
> Based
> >> on the xpath evaluation, actions can be triggered. These actions can be
> >> implemented by users by extending the BAMAdaptor interface's execute
> method
> >> which takes an array of BAMActionParameter.
> >>
> >> For providing details in terms of Rules,Actions and global parameters,
> the
> >> actions.xml, rules.xml and globalConfig.xml need to be populated.
> Sample
> >> files can be found in the src/test/resources directory and usage
> details for
> >> the BAMComponent can be found in the spring.xml file which is in the
> same
> >> directory.
> >>
> >> The relationship between actions and rules is established by id
> reference
> >> where in the rules have actions IDs (no or more). Please refer the
> >> respective xml files.
> >>
> >> All implemented adaptor classes could be put in the option lib
> directory
> >> of smx so that they can be referenced by the BAM processor. (A sample
> >> Adaptor called PrintAdaptor has been provided in the src...samples dir
> for
> >> reference)
> >>
> >> Will be putting a wiki page shortly which will have more details.
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> If you think it was sent incorrectly contact one of the administrators:
> >> https://issues.apache.org/activemq/secure/Administrators.jspa
> >> -
> >> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> >>
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
>
--
Cheers,
Guillaume Nodet
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
Thanks for the reply, my comments are inline...
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Friday, August 11, 2006 3:02 PM
Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component
>A few comments:
>
> 1) Files should include the Apache standard header
Will include them
> 2) resources are loaded with xbean in BAMEndpoint.process
> they override any definition specified directly with the rules,
> actions properties
> IMHO, they should be loaded when activate is called (or at
> initialization time,
> by implementing the spring interface InitializingBean) and only if the
> properties
> are not set
I had kept both ways to load properties, but going forward I think resource based file loading would be the most appropriate solution so will keep that and remove the embedded beans defn. from BAMEndpoint. Let me know if I missing the point.
> 3) I don't see any use of the BAMGlobalConfig / Params classes
This has been kept for future use where global parameters can be defined and used by adaptors as well as actions and rules
> 4) Rules are not extensible. People will need to use to be able to check
> for
> properties, attachments, not only xpath on the content. So it should be
> an interface with
> Object evaluate(MessageExchange exchange)
> or
> Object evaluate(NormalizedMessage message)
> or anything like that.
This is a good idea, for now let me just implement for content based then we can provide other adaptors later
> 5) When using xpath, you need a way to configure the namesapces in use in
> the xpath
> expression, else you can not use it on xml requests with namespaces.
> Take a look at the XPathPredicate in servicemix-eip
Will make sure that it handles namespaces
> 6) The configuration could leverage much more of spring/xbean features and
> use a clean POJO model
> which will be easily translated into a clean xml schema using xbean.
> They don't need to use id references and class names, as spring will do
> that easily.
> And instead of using BAMActionParameters, these parameters could be
> easily configured on
> the action / adaptor itself.
>
> So instead of having
> <bam:bAMRule description="Email rule1" resultType="Boolean"
> ruleName="emailRule1" xpath="/sample[@id='555-3482']">
> <bam:actionDetails>
> <bam:bAMActionDetail executeOn="true" actionID="printer"
> active="true"/>
> </bam:actionDetails>
> </bam:bAMRule>
> <bam:bAMAction actionName="printer" adaptorClass="
> org.apache.servicemix.bam.sample.PrintAdaptor" description="For emailing">
> <bam:params>
> <bam:bAMActionParameter name="mobileNumber" value="405-3785"
> type="String"/>
> <bam:bAMActionParameter name="address" value="680, morse ave CA"
> type="String"/>
> </bam:params>
> </bam:bAMAction>
>
> You could simply have
> <bam:endpoint ...>
> <bam:rule>
> <bam:evaluator>
> <bam:xpath xpath="/test:sample/@id" nsContext="#nsContext" />
> </bam:evaluator>
> <bam:actions>
> <bam:action executeOn="554-345" adaptor="#printAdaptor" />
> </bam:actions>
> </bam:endpoint>
>
> <bam:print id="printAdaptor" output="stderr" mobileNumber="405-3785"
> address="680, morse ave CA" />
>
> <bam:namespaceContext id="nsContext">
> <bam:namespace prefix="test">http://test</bam:namespace>
> </bam:namespaceContext>
>
> This is only an example to show how to use references, without having to
> define IDs and classNames.
> This lead to a much cleaner POJO model.
The reason it has been repesented this way is because an action can be referenced by multiple rules. So you can define an action once and then reference it from different rules.This provides separation of action from rules.
The relationship is as follows:(haven't included the attributes)
BAMAction has one or more BAMActionParameter (bamActionParameter has details of the parameters that the action adaptor would use)
BAMRule has one or more BAMActionDetail (bamActionDetail has the reference to actions using an ID)
So from a user perspective in the rule.xml file they can specify an actionid which is there in the actions.xml . so even if the action implementation changes the rules file doesn't need to be changed.
Consider a situation where these files could be coming from an external source so rather than getting a whole bulk of xml we can isolate and deal with specific xmls.
>From an dev perspective, it's more of a parent child relationship-> later on storage could be easy in a database maybe.
I have used BAMActionParameter as well as BAMGlobalParameter -> they both are same so I guess, use one class and name it BAMParameter.
My $0.02 :-)
>
>
>
> On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
>>
>> Business Activity Monitoring Component
>> --------------------------------------
>>
>> Key: SM-534
>> URL: https://issues.apache.org/activemq/browse/SM-534
>> Project: ServiceMix
>> Issue Type: New Feature
>> Components: servicemix-common
>> Reporter: Soumadeep Sen
>> Attachments: servicemix-bam.zip
>>
>> This Business Activity Monitoring component which works off an xpath
>> expression. The xpath expression acts as a Key performance indicator. Based
>> on the xpath evaluation, actions can be triggered. These actions can be
>> implemented by users by extending the BAMAdaptor interface's execute method
>> which takes an array of BAMActionParameter.
>>
>> For providing details in terms of Rules,Actions and global parameters, the
>> actions.xml, rules.xml and globalConfig.xml need to be populated. Sample
>> files can be found in the src/test/resources directory and usage details for
>> the BAMComponent can be found in the spring.xml file which is in the same
>> directory.
>>
>> The relationship between actions and rules is established by id reference
>> where in the rules have actions IDs (no or more). Please refer the
>> respective xml files.
>>
>> All implemented adaptor classes could be put in the option lib directory
>> of smx so that they can be referenced by the BAM processor. (A sample
>> Adaptor called PrintAdaptor has been provided in the src...samples dir for
>> reference)
>>
>> Will be putting a wiki page shortly which will have more details.
>>
>>
>>
>>
>>
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the administrators:
>> https://issues.apache.org/activemq/secure/Administrators.jspa
>> -
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
Posted by Guillaume Nodet <gn...@gmail.com>.
A few comments:
1) Files should include the Apache standard header
2) resources are loaded with xbean in BAMEndpoint.process
they override any definition specified directly with the rules,
actions properties
IMHO, they should be loaded when activate is called (or at
initialization time,
by implementing the spring interface InitializingBean) and only if the
properties
are not set
3) I don't see any use of the BAMGlobalConfig / Params classes
4) Rules are not extensible. People will need to use to be able to check
for
properties, attachments, not only xpath on the content. So it should be
an interface with
Object evaluate(MessageExchange exchange)
or
Object evaluate(NormalizedMessage message)
or anything like that.
5) When using xpath, you need a way to configure the namesapces in use in
the xpath
expression, else you can not use it on xml requests with namespaces.
Take a look at the XPathPredicate in servicemix-eip
6) The configuration could leverage much more of spring/xbean features and
use a clean POJO model
which will be easily translated into a clean xml schema using xbean.
They don't need to use id references and class names, as spring will do
that easily.
And instead of using BAMActionParameters, these parameters could be
easily configured on
the action / adaptor itself.
So instead of having
<bam:bAMRule description="Email rule1" resultType="Boolean"
ruleName="emailRule1" xpath="/sample[@id='555-3482']">
<bam:actionDetails>
<bam:bAMActionDetail executeOn="true" actionID="printer"
active="true"/>
</bam:actionDetails>
</bam:bAMRule>
<bam:bAMAction actionName="printer" adaptorClass="
org.apache.servicemix.bam.sample.PrintAdaptor" description="For emailing">
<bam:params>
<bam:bAMActionParameter name="mobileNumber" value="405-3785"
type="String"/>
<bam:bAMActionParameter name="address" value="680, morse ave CA"
type="String"/>
</bam:params>
</bam:bAMAction>
You could simply have
<bam:endpoint ...>
<bam:rule>
<bam:evaluator>
<bam:xpath xpath="/test:sample/@id" nsContext="#nsContext" />
</bam:evaluator>
<bam:actions>
<bam:action executeOn="554-345" adaptor="#printAdaptor" />
</bam:actions>
</bam:endpoint>
<bam:print id="printAdaptor" output="stderr" mobileNumber="405-3785"
address="680, morse ave CA" />
<bam:namespaceContext id="nsContext">
<bam:namespace prefix="test">http://test</bam:namespace>
</bam:namespaceContext>
This is only an example to show how to use references, without having to
define IDs and classNames.
This lead to a much cleaner POJO model.
On 8/10/06, Soumadeep Sen (JIRA) <ji...@apache.org> wrote:
>
> Business Activity Monitoring Component
> --------------------------------------
>
> Key: SM-534
> URL: https://issues.apache.org/activemq/browse/SM-534
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-common
> Reporter: Soumadeep Sen
> Attachments: servicemix-bam.zip
>
> This Business Activity Monitoring component which works off an xpath
> expression. The xpath expression acts as a Key performance indicator. Based
> on the xpath evaluation, actions can be triggered. These actions can be
> implemented by users by extending the BAMAdaptor interface's execute method
> which takes an array of BAMActionParameter.
>
> For providing details in terms of Rules,Actions and global parameters, the
> actions.xml, rules.xml and globalConfig.xml need to be populated. Sample
> files can be found in the src/test/resources directory and usage details for
> the BAMComponent can be found in the spring.xml file which is in the same
> directory.
>
> The relationship between actions and rules is established by id reference
> where in the rules have actions IDs (no or more). Please refer the
> respective xml files.
>
> All implemented adaptor classes could be put in the option lib directory
> of smx so that they can be referenced by the BAM processor. (A sample
> Adaptor called PrintAdaptor has been provided in the src...samples dir for
> reference)
>
> Will be putting a wiki page shortly which will have more details.
>
>
>
>
>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://issues.apache.org/activemq/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
--
Cheers,
Guillaume Nodet
[jira] Updated: (SM-534) Business Activity Monitoring Component
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-534?page=all ]
Guillaume Nodet updated SM-534:
-------------------------------
Attachment: pom.xml
A working pom :)
> Business Activity Monitoring Component
> --------------------------------------
>
> Key: SM-534
> URL: https://issues.apache.org/activemq/browse/SM-534
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-common
> Reporter: Soumadeep Sen
> Attachments: pom.xml, servicemix-bam-updated.zip, servicemix-bam.zip, servicemix-bam.zip
>
>
> This Business Activity Monitoring component which works off an xpath expression. The xpath expression acts as a Key performance indicator. Based on the xpath evaluation, actions can be triggered. These actions can be implemented by users by extending the BAMAdaptor interface's execute method which takes an array of BAMActionParameter.
> For providing details in terms of Rules,Actions and global parameters, the actions.xml, rules.xml and globalConfig.xml need to be populated. Sample files can be found in the src/test/resources directory and usage details for the BAMComponent can be found in the spring.xml file which is in the same directory.
> The relationship between actions and rules is established by id reference where in the rules have actions IDs (no or more). Please refer the respective xml files.
> All implemented adaptor classes could be put in the option lib directory of smx so that they can be referenced by the BAM processor. (A sample Adaptor called PrintAdaptor has been provided in the src...samples dir for reference)
> Will be putting a wiki page shortly which will have more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-534) Business Activity Monitoring Component
Posted by "Soumadeep Sen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-534?page=all ]
Soumadeep Sen updated SM-534:
-----------------------------
Attachment: servicemix-bam.zip
Updated the BAM component, now the rule is adaptor based and the bam processor takes a NormalizedMessage as an input.
> Business Activity Monitoring Component
> --------------------------------------
>
> Key: SM-534
> URL: https://issues.apache.org/activemq/browse/SM-534
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-common
> Reporter: Soumadeep Sen
> Attachments: servicemix-bam-updated.zip, servicemix-bam.zip, servicemix-bam.zip
>
>
> This Business Activity Monitoring component which works off an xpath expression. The xpath expression acts as a Key performance indicator. Based on the xpath evaluation, actions can be triggered. These actions can be implemented by users by extending the BAMAdaptor interface's execute method which takes an array of BAMActionParameter.
> For providing details in terms of Rules,Actions and global parameters, the actions.xml, rules.xml and globalConfig.xml need to be populated. Sample files can be found in the src/test/resources directory and usage details for the BAMComponent can be found in the spring.xml file which is in the same directory.
> The relationship between actions and rules is established by id reference where in the rules have actions IDs (no or more). Please refer the respective xml files.
> All implemented adaptor classes could be put in the option lib directory of smx so that they can be referenced by the BAM processor. (A sample Adaptor called PrintAdaptor has been provided in the src...samples dir for reference)
> Will be putting a wiki page shortly which will have more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-534) Business Activity Monitoring Component
Posted by "Soumadeep Sen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-534?page=all ]
Soumadeep Sen updated SM-534:
-----------------------------
Attachment: servicemix-bam-updated.zip
Updated the Adaptor interface so that more rule related information can be passed, also changed the sample input xml so that some evaluation happens during testing.
> Business Activity Monitoring Component
> --------------------------------------
>
> Key: SM-534
> URL: https://issues.apache.org/activemq/browse/SM-534
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-common
> Reporter: Soumadeep Sen
> Attachments: servicemix-bam-updated.zip, servicemix-bam.zip
>
>
> This Business Activity Monitoring component which works off an xpath expression. The xpath expression acts as a Key performance indicator. Based on the xpath evaluation, actions can be triggered. These actions can be implemented by users by extending the BAMAdaptor interface's execute method which takes an array of BAMActionParameter.
> For providing details in terms of Rules,Actions and global parameters, the actions.xml, rules.xml and globalConfig.xml need to be populated. Sample files can be found in the src/test/resources directory and usage details for the BAMComponent can be found in the spring.xml file which is in the same directory.
> The relationship between actions and rules is established by id reference where in the rules have actions IDs (no or more). Please refer the respective xml files.
> All implemented adaptor classes could be put in the option lib directory of smx so that they can be referenced by the BAM processor. (A sample Adaptor called PrintAdaptor has been provided in the src...samples dir for reference)
> Will be putting a wiki page shortly which will have more details.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira