You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/07/31 11:44:34 UTC
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 ?
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) ?
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
for that, else the BAM component would end up lots of BCs code internally
(what about
jms, jabber, etc...).
On 7/31/06, Soumadeep-Infravio <so...@infravio.com> 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="person-name@webmail.org">
> <to address=x@y.com;y@x.com>
> <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
Re: BAM Component
Posted by James Strachan <ja...@gmail.com>.
The URI configuration mechanism does rock - I agree with Guillaume,
it'd be a very useful way to configure an ECA / BAM configuration.
On 7/31/06, Guillaume Nodet <gn...@gmail.com> wrote:
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >
> > I agree... but in a content based routing too the end result is a path to
> > an
> > application or service etc... though the technology used could be the same
> > but from a BAM perspective the utility factor is effectively greater...
>
>
> Agreed. And be sure that I do not underestimate the need for such easier
> configuration,
> though I still think that using endpoint resolution would avoid duplicating
> code, and
> allow using any existing BC that support such feature, while keeping a
> centralized configuration.
>
> Maybe I miss something, i would have thought a BAM component would be more
> about
> monitoring than embedding business logic with rules: see one definition of
> BAM at
> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
> definitions can be argued ;)
>
>
> ----- Original Message -----
> > From: "Guillaume Nodet" <gn...@gmail.com>
> > To: <se...@geronimo.apache.org>
> > Sent: Monday, July 31, 2006 4:41 PM
> > Subject: Re: BAM Component
> >
> >
> > > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > >>
> > >> Thanks Guillaume,
> > >>
> > >> comments inline...
> > >>
> > >> Thanks
> > >> Soumadeep
> > >>
> > >> ----- Original Message -----
> > >> From: "Guillaume Nodet" <gn...@gmail.com>
> > >> To: <se...@geronimo.apache.org>
> > >> Cc: <se...@geronimo.apache.org>
> > >> 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 <so...@infravio.com> 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="person-name@webmail.org">
> > >> >> <to address=x@y.com;y@x.com>
> > >> >> <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
> > >
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: BAM Component
Posted by James Strachan <ja...@gmail.com>.
Looks great to me! :)
On 7/31/06, Guillaume Nodet <gn...@gmail.com> wrote:
> Ok, let me explain or we could use URI or endpoint resolution to avoid
> duplicating
> some code.
> Each component must implement the
> ServiceEndpoint resolveEndpointReference(DocumentFragment epr)
> method provided by the Component interface.
> This method takes a DOM fragment as an argument and returns a
> ServiceEndpoint
> that can be used as a target for a given JBI exchange. Currently, the only
> components
> implementing this method are servicemix-http and servicemix-jms, but future
> BCs will
> certainly implement it also.
> Other components can query for such dynamic endpoints by using
> ComponentContext.resolveEndpointReference.
> The current implementation can recognized a WS-Addressing EPR and returns a
> custom ServiceEndpoint. When an exchange using such an endpoint, the
> servicemix-http
> component will create a dynamic HttpEndpoint and use the uri to configure
> it.
> Hence the http.soap=true parameter on the URI.
> All properties can be configured this way, so the main benefit is that using
> only the JBI api,
> you can eaily leverage all existing BCs.
>
> I think the BAM component should implement an Adaptor, which would use such
> URIs to resolve
> EPRs so that it can send exchange to all known protocols. The endpoint
> reolution mechanism
> could be enhanced, if URIs are not sufficient, to allow other xml fragment
> to be resolved.
>
> Of course, this would not work currently for email, as there is no standard
> JBI BC handling smtp,
> but this should be done in the future. That way, you could have the
> following configuration,
>
> <Adaptor name="org.apache.sm.URISender">
> <uri value="smtp://mail.webmail.org?from=
> person-name@webmail.org&to=x@y.com;y@x.com&message=There is a new quotation
> coming your way!!" />
> </Adaptor>
>
> The URI can be a bit complex in such a case, that' s why the endpoint
> resolution could be enhanced to recognize a specific syntax.
>
> <Adaptor name="org.apache.sm.EPRSender">
> <smtp:epr xmlns:smtp="xxx">
> <smtp:host name="mail.webmail.org">
> <smtp:from address="person-name@webmail.org">
> <smtp:to address=x@y.com;y@x.com>
> <smtp:message value="There is a new quotation coming
> your way!!">
> </smtp>
> </Adaptor>
>
> The main difference with the existing implementation is that all smtp
> related code would be in the SMTP BC.
> It would be given the whole <smtp:epr /> tag to resolve, return a
> ServiceEndpoint which would be used as the
> target of the jbi exchange.
> This way, all SMTP related code remains under the control of the SMTP BC :)
>
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >
> > I guess for now let's stick to the passive mode and delegate the
> > processing,
> > based on an event.
> >
> > Let me know -from a birds eye view if this is OK.
> >
> > 1) we passively sniff data from payloads
> > 2) evaluate the xpath based expression(reuse what is available in SM)
> > 3) delegate the processing to some adaptor (or reuse what is available in
> > SM)
> > 4) provide configuration files for global,rule and actions - or reuse the
> > existing URI based code (do let us know how you want to reuse it)
> >
> > Thanks
> > Soumadeep
> >
> > ----- Original Message -----
> > From: "Soumadeep-Infravio" <so...@infravio.com>
> > To: <se...@geronimo.apache.org>
> > Sent: Monday, July 31, 2006 7:36 PM
> > Subject: Re: BAM Component
> >
> >
> > >I agree...about reusability.
> > >
> > > Regarding the concepts of BAM I guess there has been a lot of debate on
> > > this...
> > >
> > > Here is the trade off - from a use case perspective :
> > > 1) Passive - where we just sniff the data without hindering the process
> > > and delegate the processing depending on an event.
> > > - pure monitoring mode.
> > >
> > > 2) Active - where the evaluation takes place and depending on the
> > > situation the process is terminated because of an evaluation exception.
> > >
> > > Say for example : I set up a rule which says that if the order value is
> > > more than $5000 then switch to async mode because the retailer doesn't
> > > keep stock more than $1000 and can't handle the transaction. In such a
> > > situation the rule would take precedence.
> > >
> > > As far as reasoning goes... we could have this evaluation logic at the
> > > endpoint service but the flip side is we are anyway evaluating a rule at
> > > the intermediary level for monitoring, which would increasing the
> > overall
> > > latency, so why not do it at the intermediary level rather than at the
> > > endpoint service.Further, the BAM solution then shifts to the Service
> > end
> > > and becomes very specific where as the SM BAM way we can generalize it
> > > and make it available for more than one service.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Guillaume Nodet" <gn...@gmail.com>
> > > To: <se...@geronimo.apache.org>
> > > Sent: Monday, July 31, 2006 6:11 PM
> > > Subject: Re: BAM Component
> > >
> > >
> > >> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > >>>
> > >>> I agree... but in a content based routing too the end result is a path
> > >>> to
> > >>> an
> > >>> application or service etc... though the technology used could be the
> > >>> same
> > >>> but from a BAM perspective the utility factor is effectively
> > greater...
> > >>
> > >>
> > >> Agreed. And be sure that I do not underestimate the need for such
> > easier
> > >> configuration,
> > >> though I still think that using endpoint resolution would avoid
> > >> duplicating
> > >> code, and
> > >> allow using any existing BC that support such feature, while keeping a
> > >> centralized configuration.
> > >>
> > >> Maybe I miss something, i would have thought a BAM component would be
> > >> more
> > >> about
> > >> monitoring than embedding business logic with rules: see one definition
> > >> of
> > >> BAM at
> > >> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
> > >> definitions can be argued ;)
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Guillaume Nodet" <gn...@gmail.com>
> > >>> To: <se...@geronimo.apache.org>
> > >>> Sent: Monday, July 31, 2006 4:41 PM
> > >>> Subject: Re: BAM Component
> > >>>
> > >>>
> > >>> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> > >>> >>
> > >>> >> Thanks Guillaume,
> > >>> >>
> > >>> >> comments inline...
> > >>> >>
> > >>> >> Thanks
> > >>> >> Soumadeep
> > >>> >>
> > >>> >> ----- Original Message -----
> > >>> >> From: "Guillaume Nodet" <gn...@gmail.com>
> > >>> >> To: <se...@geronimo.apache.org>
> > >>> >> Cc: <se...@geronimo.apache.org>
> > >>> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
> > >>> >> >> <to address=x@y.com;y@x.com>
> > >>> >> >> <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
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Cheers,
> > >> Guillaume Nodet
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
Let me give it a shot...
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Monday, July 31, 2006 9:35 PM
Subject: Re: BAM Component
> Ok, let me explain or we could use URI or endpoint resolution to avoid
> duplicating
> some code.
> Each component must implement the
> ServiceEndpoint resolveEndpointReference(DocumentFragment epr)
> method provided by the Component interface.
> This method takes a DOM fragment as an argument and returns a
> ServiceEndpoint
> that can be used as a target for a given JBI exchange. Currently, the
> only
> components
> implementing this method are servicemix-http and servicemix-jms, but
> future
> BCs will
> certainly implement it also.
> Other components can query for such dynamic endpoints by using
> ComponentContext.resolveEndpointReference.
> The current implementation can recognized a WS-Addressing EPR and returns
> a
> custom ServiceEndpoint. When an exchange using such an endpoint, the
> servicemix-http
> component will create a dynamic HttpEndpoint and use the uri to configure
> it.
> Hence the http.soap=true parameter on the URI.
> All properties can be configured this way, so the main benefit is that
> using
> only the JBI api,
> you can eaily leverage all existing BCs.
>
> I think the BAM component should implement an Adaptor, which would use
> such
> URIs to resolve
> EPRs so that it can send exchange to all known protocols. The endpoint
> reolution mechanism
> could be enhanced, if URIs are not sufficient, to allow other xml fragment
> to be resolved.
>
> Of course, this would not work currently for email, as there is no
> standard
> JBI BC handling smtp,
> but this should be done in the future. That way, you could have the
> following configuration,
>
> <Adaptor name="org.apache.sm.URISender">
> <uri value="smtp://mail.webmail.org?from=
> person-name@webmail.org&to=x@y.com;y@x.com&message=There is a new
> quotation
> coming your way!!" />
> </Adaptor>
>
> The URI can be a bit complex in such a case, that' s why the endpoint
> resolution could be enhanced to recognize a specific syntax.
>
> <Adaptor name="org.apache.sm.EPRSender">
> <smtp:epr xmlns:smtp="xxx">
> <smtp:host name="mail.webmail.org">
> <smtp:from address="person-name@webmail.org">
> <smtp:to address=x@y.com;y@x.com>
> <smtp:message value="There is a new quotation coming
> your way!!">
> </smtp>
> </Adaptor>
>
> The main difference with the existing implementation is that all smtp
> related code would be in the SMTP BC.
> It would be given the whole <smtp:epr /> tag to resolve, return a
> ServiceEndpoint which would be used as the
> target of the jbi exchange.
> This way, all SMTP related code remains under the control of the SMTP BC
> :)
>
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>
>> I guess for now let's stick to the passive mode and delegate the
>> processing,
>> based on an event.
>>
>> Let me know -from a birds eye view if this is OK.
>>
>> 1) we passively sniff data from payloads
>> 2) evaluate the xpath based expression(reuse what is available in SM)
>> 3) delegate the processing to some adaptor (or reuse what is available in
>> SM)
>> 4) provide configuration files for global,rule and actions - or reuse
>> the
>> existing URI based code (do let us know how you want to reuse it)
>>
>> Thanks
>> Soumadeep
>>
>> ----- Original Message -----
>> From: "Soumadeep-Infravio" <so...@infravio.com>
>> To: <se...@geronimo.apache.org>
>> Sent: Monday, July 31, 2006 7:36 PM
>> Subject: Re: BAM Component
>>
>>
>> >I agree...about reusability.
>> >
>> > Regarding the concepts of BAM I guess there has been a lot of debate on
>> > this...
>> >
>> > Here is the trade off - from a use case perspective :
>> > 1) Passive - where we just sniff the data without hindering the process
>> > and delegate the processing depending on an event.
>> > - pure monitoring mode.
>> >
>> > 2) Active - where the evaluation takes place and depending on the
>> > situation the process is terminated because of an evaluation exception.
>> >
>> > Say for example : I set up a rule which says that if the order value is
>> > more than $5000 then switch to async mode because the retailer doesn't
>> > keep stock more than $1000 and can't handle the transaction. In such a
>> > situation the rule would take precedence.
>> >
>> > As far as reasoning goes... we could have this evaluation logic at the
>> > endpoint service but the flip side is we are anyway evaluating a rule
>> > at
>> > the intermediary level for monitoring, which would increasing the
>> overall
>> > latency, so why not do it at the intermediary level rather than at the
>> > endpoint service.Further, the BAM solution then shifts to the Service
>> end
>> > and becomes very specific where as the SM BAM way we can generalize it
>> > and make it available for more than one service.
>> >
>> >
>> > ----- Original Message -----
>> > From: "Guillaume Nodet" <gn...@gmail.com>
>> > To: <se...@geronimo.apache.org>
>> > Sent: Monday, July 31, 2006 6:11 PM
>> > Subject: Re: BAM Component
>> >
>> >
>> >> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>> >>>
>> >>> I agree... but in a content based routing too the end result is a
>> >>> path
>> >>> to
>> >>> an
>> >>> application or service etc... though the technology used could be the
>> >>> same
>> >>> but from a BAM perspective the utility factor is effectively
>> greater...
>> >>
>> >>
>> >> Agreed. And be sure that I do not underestimate the need for such
>> easier
>> >> configuration,
>> >> though I still think that using endpoint resolution would avoid
>> >> duplicating
>> >> code, and
>> >> allow using any existing BC that support such feature, while keeping a
>> >> centralized configuration.
>> >>
>> >> Maybe I miss something, i would have thought a BAM component would be
>> >> more
>> >> about
>> >> monitoring than embedding business logic with rules: see one
>> >> definition
>> >> of
>> >> BAM at
>> >> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
>> >> definitions can be argued ;)
>> >>
>> >>
>> >> ----- Original Message -----
>> >>> From: "Guillaume Nodet" <gn...@gmail.com>
>> >>> To: <se...@geronimo.apache.org>
>> >>> Sent: Monday, July 31, 2006 4:41 PM
>> >>> Subject: Re: BAM Component
>> >>>
>> >>>
>> >>> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>> >>> >>
>> >>> >> Thanks Guillaume,
>> >>> >>
>> >>> >> comments inline...
>> >>> >>
>> >>> >> Thanks
>> >>> >> Soumadeep
>> >>> >>
>> >>> >> ----- Original Message -----
>> >>> >> From: "Guillaume Nodet" <gn...@gmail.com>
>> >>> >> To: <se...@geronimo.apache.org>
>> >>> >> Cc: <se...@geronimo.apache.org>
>> >>> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
>> >>> >> >> <to address=x@y.com;y@x.com>
>> >>> >> >> <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
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
Re: BAM Component
Posted by Guillaume Nodet <gn...@gmail.com>.
Ok, let me explain or we could use URI or endpoint resolution to avoid
duplicating
some code.
Each component must implement the
ServiceEndpoint resolveEndpointReference(DocumentFragment epr)
method provided by the Component interface.
This method takes a DOM fragment as an argument and returns a
ServiceEndpoint
that can be used as a target for a given JBI exchange. Currently, the only
components
implementing this method are servicemix-http and servicemix-jms, but future
BCs will
certainly implement it also.
Other components can query for such dynamic endpoints by using
ComponentContext.resolveEndpointReference.
The current implementation can recognized a WS-Addressing EPR and returns a
custom ServiceEndpoint. When an exchange using such an endpoint, the
servicemix-http
component will create a dynamic HttpEndpoint and use the uri to configure
it.
Hence the http.soap=true parameter on the URI.
All properties can be configured this way, so the main benefit is that using
only the JBI api,
you can eaily leverage all existing BCs.
I think the BAM component should implement an Adaptor, which would use such
URIs to resolve
EPRs so that it can send exchange to all known protocols. The endpoint
reolution mechanism
could be enhanced, if URIs are not sufficient, to allow other xml fragment
to be resolved.
Of course, this would not work currently for email, as there is no standard
JBI BC handling smtp,
but this should be done in the future. That way, you could have the
following configuration,
<Adaptor name="org.apache.sm.URISender">
<uri value="smtp://mail.webmail.org?from=
person-name@webmail.org&to=x@y.com;y@x.com&message=There is a new quotation
coming your way!!" />
</Adaptor>
The URI can be a bit complex in such a case, that' s why the endpoint
resolution could be enhanced to recognize a specific syntax.
<Adaptor name="org.apache.sm.EPRSender">
<smtp:epr xmlns:smtp="xxx">
<smtp:host name="mail.webmail.org">
<smtp:from address="person-name@webmail.org">
<smtp:to address=x@y.com;y@x.com>
<smtp:message value="There is a new quotation coming
your way!!">
</smtp>
</Adaptor>
The main difference with the existing implementation is that all smtp
related code would be in the SMTP BC.
It would be given the whole <smtp:epr /> tag to resolve, return a
ServiceEndpoint which would be used as the
target of the jbi exchange.
This way, all SMTP related code remains under the control of the SMTP BC :)
On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> I guess for now let's stick to the passive mode and delegate the
> processing,
> based on an event.
>
> Let me know -from a birds eye view if this is OK.
>
> 1) we passively sniff data from payloads
> 2) evaluate the xpath based expression(reuse what is available in SM)
> 3) delegate the processing to some adaptor (or reuse what is available in
> SM)
> 4) provide configuration files for global,rule and actions - or reuse the
> existing URI based code (do let us know how you want to reuse it)
>
> Thanks
> Soumadeep
>
> ----- Original Message -----
> From: "Soumadeep-Infravio" <so...@infravio.com>
> To: <se...@geronimo.apache.org>
> Sent: Monday, July 31, 2006 7:36 PM
> Subject: Re: BAM Component
>
>
> >I agree...about reusability.
> >
> > Regarding the concepts of BAM I guess there has been a lot of debate on
> > this...
> >
> > Here is the trade off - from a use case perspective :
> > 1) Passive - where we just sniff the data without hindering the process
> > and delegate the processing depending on an event.
> > - pure monitoring mode.
> >
> > 2) Active - where the evaluation takes place and depending on the
> > situation the process is terminated because of an evaluation exception.
> >
> > Say for example : I set up a rule which says that if the order value is
> > more than $5000 then switch to async mode because the retailer doesn't
> > keep stock more than $1000 and can't handle the transaction. In such a
> > situation the rule would take precedence.
> >
> > As far as reasoning goes... we could have this evaluation logic at the
> > endpoint service but the flip side is we are anyway evaluating a rule at
> > the intermediary level for monitoring, which would increasing the
> overall
> > latency, so why not do it at the intermediary level rather than at the
> > endpoint service.Further, the BAM solution then shifts to the Service
> end
> > and becomes very specific where as the SM BAM way we can generalize it
> > and make it available for more than one service.
> >
> >
> > ----- Original Message -----
> > From: "Guillaume Nodet" <gn...@gmail.com>
> > To: <se...@geronimo.apache.org>
> > Sent: Monday, July 31, 2006 6:11 PM
> > Subject: Re: BAM Component
> >
> >
> >> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >>>
> >>> I agree... but in a content based routing too the end result is a path
> >>> to
> >>> an
> >>> application or service etc... though the technology used could be the
> >>> same
> >>> but from a BAM perspective the utility factor is effectively
> greater...
> >>
> >>
> >> Agreed. And be sure that I do not underestimate the need for such
> easier
> >> configuration,
> >> though I still think that using endpoint resolution would avoid
> >> duplicating
> >> code, and
> >> allow using any existing BC that support such feature, while keeping a
> >> centralized configuration.
> >>
> >> Maybe I miss something, i would have thought a BAM component would be
> >> more
> >> about
> >> monitoring than embedding business logic with rules: see one definition
> >> of
> >> BAM at
> >> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
> >> definitions can be argued ;)
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Guillaume Nodet" <gn...@gmail.com>
> >>> To: <se...@geronimo.apache.org>
> >>> Sent: Monday, July 31, 2006 4:41 PM
> >>> Subject: Re: BAM Component
> >>>
> >>>
> >>> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >>> >>
> >>> >> Thanks Guillaume,
> >>> >>
> >>> >> comments inline...
> >>> >>
> >>> >> Thanks
> >>> >> Soumadeep
> >>> >>
> >>> >> ----- Original Message -----
> >>> >> From: "Guillaume Nodet" <gn...@gmail.com>
> >>> >> To: <se...@geronimo.apache.org>
> >>> >> Cc: <se...@geronimo.apache.org>
> >>> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
> >>> >> >> <to address=x@y.com;y@x.com>
> >>> >> >> <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
> >>> >
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
> >
> >
>
>
>
--
Cheers,
Guillaume Nodet
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
I guess for now let's stick to the passive mode and delegate the processing,
based on an event.
Let me know -from a birds eye view if this is OK.
1) we passively sniff data from payloads
2) evaluate the xpath based expression(reuse what is available in SM)
3) delegate the processing to some adaptor (or reuse what is available in
SM)
4) provide configuration files for global,rule and actions - or reuse the
existing URI based code (do let us know how you want to reuse it)
Thanks
Soumadeep
----- Original Message -----
From: "Soumadeep-Infravio" <so...@infravio.com>
To: <se...@geronimo.apache.org>
Sent: Monday, July 31, 2006 7:36 PM
Subject: Re: BAM Component
>I agree...about reusability.
>
> Regarding the concepts of BAM I guess there has been a lot of debate on
> this...
>
> Here is the trade off - from a use case perspective :
> 1) Passive - where we just sniff the data without hindering the process
> and delegate the processing depending on an event.
> - pure monitoring mode.
>
> 2) Active - where the evaluation takes place and depending on the
> situation the process is terminated because of an evaluation exception.
>
> Say for example : I set up a rule which says that if the order value is
> more than $5000 then switch to async mode because the retailer doesn't
> keep stock more than $1000 and can't handle the transaction. In such a
> situation the rule would take precedence.
>
> As far as reasoning goes... we could have this evaluation logic at the
> endpoint service but the flip side is we are anyway evaluating a rule at
> the intermediary level for monitoring, which would increasing the overall
> latency, so why not do it at the intermediary level rather than at the
> endpoint service.Further, the BAM solution then shifts to the Service end
> and becomes very specific where as the SM BAM way we can generalize it
> and make it available for more than one service.
>
>
> ----- Original Message -----
> From: "Guillaume Nodet" <gn...@gmail.com>
> To: <se...@geronimo.apache.org>
> Sent: Monday, July 31, 2006 6:11 PM
> Subject: Re: BAM Component
>
>
>> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>>
>>> I agree... but in a content based routing too the end result is a path
>>> to
>>> an
>>> application or service etc... though the technology used could be the
>>> same
>>> but from a BAM perspective the utility factor is effectively greater...
>>
>>
>> Agreed. And be sure that I do not underestimate the need for such easier
>> configuration,
>> though I still think that using endpoint resolution would avoid
>> duplicating
>> code, and
>> allow using any existing BC that support such feature, while keeping a
>> centralized configuration.
>>
>> Maybe I miss something, i would have thought a BAM component would be
>> more
>> about
>> monitoring than embedding business logic with rules: see one definition
>> of
>> BAM at
>> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
>> definitions can be argued ;)
>>
>>
>> ----- Original Message -----
>>> From: "Guillaume Nodet" <gn...@gmail.com>
>>> To: <se...@geronimo.apache.org>
>>> Sent: Monday, July 31, 2006 4:41 PM
>>> Subject: Re: BAM Component
>>>
>>>
>>> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>> >>
>>> >> Thanks Guillaume,
>>> >>
>>> >> comments inline...
>>> >>
>>> >> Thanks
>>> >> Soumadeep
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Guillaume Nodet" <gn...@gmail.com>
>>> >> To: <se...@geronimo.apache.org>
>>> >> Cc: <se...@geronimo.apache.org>
>>> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
>>> >> >> <to address=x@y.com;y@x.com>
>>> >> >> <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
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>>
>
>
>
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
I agree...about reusability.
Regarding the concepts of BAM I guess there has been a lot of debate on
this...
Here is the trade off - from a use case perspective :
1) Passive - where we just sniff the data without hindering the process and
delegate the processing depending on an event.
- pure monitoring mode.
2) Active - where the evaluation takes place and depending on the situation
the process is terminated because of an evaluation exception.
Say for example : I set up a rule which says that if the order value is more
than $5000 then switch to async mode because the retailer doesn't keep stock
more than $1000 and can't handle the transaction. In such a situation the
rule would take precedence.
As far as reasoning goes... we could have this evaluation logic at the
endpoint service but the flip side is we are anyway evaluating a rule at the
intermediary level for monitoring, which would increasing the overall
latency, so why not do it at the intermediary level rather than at the
endpoint service.Further, the BAM solution then shifts to the Service end
and becomes very specific where as the SM BAM way we can generalize it and
make it available for more than one service.
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Monday, July 31, 2006 6:11 PM
Subject: Re: BAM Component
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>
>> I agree... but in a content based routing too the end result is a path to
>> an
>> application or service etc... though the technology used could be the
>> same
>> but from a BAM perspective the utility factor is effectively greater...
>
>
> Agreed. And be sure that I do not underestimate the need for such easier
> configuration,
> though I still think that using endpoint resolution would avoid
> duplicating
> code, and
> allow using any existing BC that support such feature, while keeping a
> centralized configuration.
>
> Maybe I miss something, i would have thought a BAM component would be more
> about
> monitoring than embedding business logic with rules: see one definition of
> BAM at
> http://www.ebizq.net/topics/bam/features/4689.html -- of course all
> definitions can be argued ;)
>
>
> ----- Original Message -----
>> From: "Guillaume Nodet" <gn...@gmail.com>
>> To: <se...@geronimo.apache.org>
>> Sent: Monday, July 31, 2006 4:41 PM
>> Subject: Re: BAM Component
>>
>>
>> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>> >>
>> >> Thanks Guillaume,
>> >>
>> >> comments inline...
>> >>
>> >> Thanks
>> >> Soumadeep
>> >>
>> >> ----- Original Message -----
>> >> From: "Guillaume Nodet" <gn...@gmail.com>
>> >> To: <se...@geronimo.apache.org>
>> >> Cc: <se...@geronimo.apache.org>
>> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
>> >> >> <to address=x@y.com;y@x.com>
>> >> >> <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
>> >
>>
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
>
Re: BAM Component
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> I agree... but in a content based routing too the end result is a path to
> an
> application or service etc... though the technology used could be the same
> but from a BAM perspective the utility factor is effectively greater...
Agreed. And be sure that I do not underestimate the need for such easier
configuration,
though I still think that using endpoint resolution would avoid duplicating
code, and
allow using any existing BC that support such feature, while keeping a
centralized configuration.
Maybe I miss something, i would have thought a BAM component would be more
about
monitoring than embedding business logic with rules: see one definition of
BAM at
http://www.ebizq.net/topics/bam/features/4689.html -- of course all
definitions can be argued ;)
----- Original Message -----
> From: "Guillaume Nodet" <gn...@gmail.com>
> To: <se...@geronimo.apache.org>
> Sent: Monday, July 31, 2006 4:41 PM
> Subject: Re: BAM Component
>
>
> > On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >>
> >> Thanks Guillaume,
> >>
> >> comments inline...
> >>
> >> Thanks
> >> Soumadeep
> >>
> >> ----- Original Message -----
> >> From: "Guillaume Nodet" <gn...@gmail.com>
> >> To: <se...@geronimo.apache.org>
> >> Cc: <se...@geronimo.apache.org>
> >> 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 <so...@infravio.com> 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="person-name@webmail.org">
> >> >> <to address=x@y.com;y@x.com>
> >> >> <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
> >
>
>
>
--
Cheers,
Guillaume Nodet
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
I agree... but in a content based routing too the end result is a path to an
application or service etc... though the technology used could be the same
but from a BAM perspective the utility factor is effectively greater...
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Monday, July 31, 2006 4:41 PM
Subject: Re: BAM Component
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>>
>> Thanks Guillaume,
>>
>> comments inline...
>>
>> Thanks
>> Soumadeep
>>
>> ----- Original Message -----
>> From: "Guillaume Nodet" <gn...@gmail.com>
>> To: <se...@geronimo.apache.org>
>> Cc: <se...@geronimo.apache.org>
>> 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 <so...@infravio.com> 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="person-name@webmail.org">
>> >> <to address=x@y.com;y@x.com>
>> >> <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
>
Re: BAM Component
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/31/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> Thanks Guillaume,
>
> comments inline...
>
> Thanks
> Soumadeep
>
> ----- Original Message -----
> From: "Guillaume Nodet" <gn...@gmail.com>
> To: <se...@geronimo.apache.org>
> Cc: <se...@geronimo.apache.org>
> 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 <so...@infravio.com> 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="person-name@webmail.org">
> >> <to address=x@y.com;y@x.com>
> >> <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
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
Thanks Guillaume,
comments inline...
Thanks
Soumadeep
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Cc: <se...@geronimo.apache.org>
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.
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
>
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> 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="person-name@webmail.org">
>> <to address=x@y.com;y@x.com>
>> <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
>
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
Thanks Guillaume,
comments inline...
Thanks
Soumadeep
----- Original Message -----
From: "Guillaume Nodet" <gn...@gmail.com>
To: <se...@geronimo.apache.org>
Cc: <se...@geronimo.apache.org>
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.
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
>
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> 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="person-name@webmail.org">
>> <to address=x@y.com;y@x.com>
>> <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
>
Re: BAM Component
Posted by Soumadeep-Infravio <so...@infravio.com>.
Thanks James,
The positioning is the most important thing... I completely agree with you.
And specially when some of the utility pieces are already there in SM and
the concept of BAM in my opinion fits well in the ESB Space.
Let's hope users will find it worth while...
Best regards
Soumadeep
----- Original Message -----
From: "James Strachan" <ja...@gmail.com>
To: <se...@geronimo.apache.org>
Sent: Monday, July 31, 2006 3:35 PM
Subject: Re: BAM Component
> Interesting stuff. I've pondered before on whether we should create a
> kind of 'Event-Condition-Action' (ECA) type component where we can
> register conditions (typically XPath predicates) on 'events' (or maybe
> endpoints is a more JBI term to use) and fire arbitrary actions when
> they are matched.
>
> In terms of low level implementation we can kinda do similar things
> today such as via the xpath router or drools component - but I'm
> thinking it would make lots of sense to provide this 'high level
> concept' to an end user - such as the XML example given below.
>
> I think the ECA approach can make things simpler for users to understand.
>
> Under the ECA approach I'm sure we could plugin the various
> capabilities we already have in ServiceMix such as the pluggable
> Expressions (XPath, Groovy etc).
>
> http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/expression/package-summary.html
>
> along with reusing many of the existing components as the actions etc.
>
> Incidentally the ECA approach lends itself nicely to great IDE tooling :)
>
> On 7/31/06, Guillaume Nodet <gn...@gmail.com> wrote:
>> 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 ?
>> 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) ?
>> 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
>> for that, else the BAM component would end up lots of BCs code internally
>> (what about
>> jms, jabber, etc...).
>>
>> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> 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="person-name@webmail.org">
>> > <to address=x@y.com;y@x.com>
>> > <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
>>
>>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: BAM Component
Posted by James Strachan <ja...@gmail.com>.
Interesting stuff. I've pondered before on whether we should create a
kind of 'Event-Condition-Action' (ECA) type component where we can
register conditions (typically XPath predicates) on 'events' (or maybe
endpoints is a more JBI term to use) and fire arbitrary actions when
they are matched.
In terms of low level implementation we can kinda do similar things
today such as via the xpath router or drools component - but I'm
thinking it would make lots of sense to provide this 'high level
concept' to an end user - such as the XML example given below.
I think the ECA approach can make things simpler for users to understand.
Under the ECA approach I'm sure we could plugin the various
capabilities we already have in ServiceMix such as the pluggable
Expressions (XPath, Groovy etc).
http://incubator.apache.org/servicemix/maven/servicemix-core/apidocs/org/apache/servicemix/expression/package-summary.html
along with reusing many of the existing components as the actions etc.
Incidentally the ECA approach lends itself nicely to great IDE tooling :)
On 7/31/06, Guillaume Nodet <gn...@gmail.com> wrote:
> 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 ?
> 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) ?
> 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
> for that, else the BAM component would end up lots of BCs code internally
> (what about
> jms, jabber, etc...).
>
> On 7/31/06, Soumadeep-Infravio <so...@infravio.com> 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="person-name@webmail.org">
> > <to address=x@y.com;y@x.com>
> > <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
>
>
--
James
-------
http://radio.weblogs.com/0112098/