On 7/31/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:

Thanks Guillaume,

comments inline...

Thanks
Soumadeep

----- Original Message -----
From: "Guillaume Nodet" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Monday, July 31, 2006 3:14 PM
Subject: Re: BAM Component


> Great, thx a lot !
> CCing servicemix-dev, as I think this is the place where this discussion
> should take place.
>
> Do you have any plan / ideas of future features for this component ?

Well, to start with we can have
1) Marshaler for various input sources
2) integration with GUI based monitoring applications
3) integration with OpenOffice, where you can directly feed data to a
spread
sheet template
4) have an intelligence module to monitor usage/evaluation patterns and
predict or forcast based on those patterns
... possibilities are infinite...

> Currently, it seems this that the component is a router with actions.
> How will it differ from existing content based routers (xpath router,
> drools
> component) ?

Traditionally, routing is more in terms of providing options for failover,
parallel, load balancing etc...techniques not for monitoring and for
taking
corrective actions it's again restricted to finding a path to a
service/app
etc nothing more than that.


I was talking about content-based routing ;)
I also agree with James that we could leverage ServiceMix expressions.

But I do agree we can factor out the existing SM Samples code base and use
it

> Another point I am wondering about, is the fact that the component
embeds
> the
> email code inside an action: i think it would be better to reuse the
> existing components

Yes, our intension is to factor out the common parameters and use a global
configuration file which can be referenced.

> for that, else the BAM component would end up lots of BCs code
internally
> (what about
> jms, jabber, etc...).

You are right as a feature extension we will certainly use all possible
ways
of communication/transport , my idea was to provide adaptors for it ->
actions


That was exactly what was worrying me. Having duplicate code will lead to a
more
difficult maintenance.  Maybe we could use URIs (
http://servicemix.goopen.org/site/uris.html),
or more generally endpoint resolution.  This would allow configuring
endpoints in the BAM
component, while putting the code in the respective BCs.


> On 7/31/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:
>>
>> Hi Guillaume/All,
>>
>> We feel that a Business Activity Monitoring Component would be a good
>> addition to ServiceMix's existing samples. We have worked on a
prototype
>> for
>> such a component and would like to contribute it.
>>
>> We have phased it out and depending on the feedback we will add other
>> features as required.
>>
>> Please send us your feedback...
>>
>> Best regards
>> Soumadeep
>>
>> Details of the component
>> ==================
>>
>> Phase 1
>> This is a Business Activity Monitoring Component which would work only
>> for
>> Web services message payload in phase 1. An XPath expression could be
>> provided in a config file which will be used to evaluate the incoming
>> message. Depending on the evaluation result it will allow one or more
>> actions to be taken. These actions again could be made available in a
>> config
>> files as below.
>>
>> Config file:
>> =======
>>
>> <SM-WS-BAM>
>>     <Service url=http://www.xmethod.com/getVersion>
>>         <Rule name="sendEmailWhenGetQuoteInvoked">
>>             <expression value/Envelope/Body/GetQuote">
>>             <Action name="emailer"/>
>>             <Action name="..."/>
>>         </Rule>
>>         <Rule name=.../>
>>     </Service>
>> </SM-WS-BAM>
>>
>> <Actions>
>>             <Action name="emailer">
>>                 <Description/>
>>                 <Adaptor name="org.apache.sm.Emailer">
>>                     <smtp-host name="mail.webmail.org">
>>                     <from address="[EMAIL PROTECTED]">
>>                     <to [EMAIL PROTECTED];[EMAIL PROTECTED]>
>>                     <message value="There is a new quotation coming
your
>> way!!">
>>                 </Adaptor>
>>             </Action>
>> </Actions>
>>
>> Flow (inside the BAM component)
>> ===
>> note: The usual MEP will be followed to pass the payload to the next
>> component in line.
>>
>> 1) Fetch the Source from the Normalized Message
>> 2) Fetch the rule to evaluate depending on the endpoint-request URL
>> 3) Check for condition and get the evaluation result (using
>> java1.5xpath's evaluate method)
>> 4) Get the adaptor to invoke and invoke it. (Adaptor instances will be
>> cached ) - from the action definition.
>>
>>
>> Phase 2
>> The component would be extended to monitor any payload. This will be
>> achieved using appropriate marshalers, which will convert the payload
to
>> xml. The marshaler to use could be indicated as a property value in the
>> MessageExchange. The rest will be per phase 1.
>>
>> Possible use:
>> ==========
>>
>> Servicemix 3.0 currently is distributed with several samples, one of
them
>> being the http-binding, which internally uses a saaj binding to
redirect
>> the
>> message to a soap endpoint. The BAM component could be used in-between
>> which
>> would enable the user to monitor the payload and take action.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>





--
Cheers,
Guillaume Nodet

Reply via email to