On 8/11/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:
Thanks for the reply, my comments are inline...
----- Original Message -----
From: "Guillaume Nodet" <[EMAIL PROTECTED]>
To: <servicemix-dev@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="/[EMAIL PROTECTED]'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) <[EMAIL PROTECTED]> 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
