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=
[EMAIL PROTECTED]&[EMAIL PROTECTED];[EMAIL PROTECTED]&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="[EMAIL PROTECTED]">
<smtp:to [EMAIL PROTECTED];[EMAIL PROTECTED]>
<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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> To: <[email protected]>
> 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" <[EMAIL PROTECTED]>
> > To: <[email protected]>
> > Sent: Monday, July 31, 2006 6:11 PM
> > Subject: Re: BAM Component
> >
> >
> >> On 7/31/06, Soumadeep-Infravio <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> >>> To: <[email protected]>
> >>> Sent: Monday, July 31, 2006 4:41 PM
> >>> Subject: Re: BAM Component
> >>>
> >>>
> >>> > On 7/31/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:
> >>> >>
> >>> >> Thanks Guillaume,
> >>> >>
> >>> >> comments inline...
> >>> >>
> >>> >> Thanks
> >>> >> Soumadeep
> >>> >>
> >>> >> ----- Original Message -----
> >>> >> From: "Guillaume Nodet" <[EMAIL PROTECTED]>
> >>> >> To: <[email protected]>
> >>> >> Cc: <[email protected]>
> >>> >> Sent: Monday, July 31, 2006 3:14 PM
> >>> >> Subject: Re: BAM Component
> >>> >>
> >>> >>
> >>> >> > Great, thx a lot !
> >>> >> > CCing servicemix-dev, as I think this is the place where this
> >>> >> > discussion
> >>> >> > should take place.
> >>> >> >
> >>> >> > Do you have any plan / ideas of future features for this
> component
> >>> >> > ?
> >>> >>
> >>> >> Well, to start with we can have
> >>> >> 1) Marshaler for various input sources
> >>> >> 2) integration with GUI based monitoring applications
> >>> >> 3) integration with OpenOffice, where you can directly feed data to
> a
> >>> >> spread
> >>> >> sheet template
> >>> >> 4) have an intelligence module to monitor usage/evaluation patterns
> >>> >> and
> >>> >> predict or forcast based on those patterns
> >>> >> ... possibilities are infinite...
> >>> >>
> >>> >> > Currently, it seems this that the component is a router with
> >>> >> > actions.
> >>> >> > How will it differ from existing content based routers (xpath
> >>> >> > router,
> >>> >> > drools
> >>> >> > component) ?
> >>> >>
> >>> >> Traditionally, routing is more in terms of providing options for
> >>> >> failover,
> >>> >> parallel, load balancing etc...techniques not for monitoring and
> for
> >>> >> taking
> >>> >> corrective actions it's again restricted to finding a path to a
> >>> >> service/app
> >>> >> etc nothing more than that.
> >>> >
> >>> >
> >>> > I was talking about content-based routing ;)
> >>> > I also agree with James that we could leverage ServiceMix
> expressions.
> >>> >
> >>> > But I do agree we can factor out the existing SM Samples code base
> and
> >>> use
> >>> >> it
> >>> >>
> >>> >> > Another point I am wondering about, is the fact that the
> component
> >>> >> embeds
> >>> >> > the
> >>> >> > email code inside an action: i think it would be better to reuse
> >>> >> > the
> >>> >> > existing components
> >>> >>
> >>> >> Yes, our intension is to factor out the common parameters and use a
> >>> >> global
> >>> >> configuration file which can be referenced.
> >>> >>
> >>> >> > for that, else the BAM component would end up lots of BCs code
> >>> >> internally
> >>> >> > (what about
> >>> >> > jms, jabber, etc...).
> >>> >>
> >>> >> You are right as a feature extension we will certainly use all
> >>> >> possible
> >>> >> ways
> >>> >> of communication/transport , my idea was to provide adaptors for
> >>> >> it ->
> >>> >> actions
> >>> >
> >>> >
> >>> > That was exactly what was worrying me. Having duplicate code will
> lead
> >>> to
> >>> > a
> >>> > more
> >>> > difficult maintenance. Maybe we could use URIs (
> >>> > http://servicemix.goopen.org/site/uris.html),
> >>> > or more generally endpoint resolution. This would allow configuring
> >>> > endpoints in the BAM
> >>> > component, while putting the code in the respective BCs.
> >>> >
> >>> >>
> >>> >> > On 7/31/06, Soumadeep-Infravio <[EMAIL PROTECTED]> wrote:
> >>> >> >>
> >>> >> >> Hi Guillaume/All,
> >>> >> >>
> >>> >> >> We feel that a Business Activity Monitoring Component would be a
> >>> good
> >>> >> >> addition to ServiceMix's existing samples. We have worked on a
> >>> >> prototype
> >>> >> >> for
> >>> >> >> such a component and would like to contribute it.
> >>> >> >>
> >>> >> >> We have phased it out and depending on the feedback we will add
> >>> other
> >>> >> >> features as required.
> >>> >> >>
> >>> >> >> Please send us your feedback...
> >>> >> >>
> >>> >> >> Best regards
> >>> >> >> Soumadeep
> >>> >> >>
> >>> >> >> Details of the component
> >>> >> >> ==================
> >>> >> >>
> >>> >> >> Phase 1
> >>> >> >> This is a Business Activity Monitoring Component which would
> work
> >>> only
> >>> >> >> for
> >>> >> >> Web services message payload in phase 1. An XPath expression
> could
> >>> be
> >>> >> >> provided in a config file which will be used to evaluate the
> >>> incoming
> >>> >> >> message. Depending on the evaluation result it will allow one or
> >>> more
> >>> >> >> actions to be taken. These actions again could be made available
> >>> >> >> in
> >>> a
> >>> >> >> config
> >>> >> >> files as below.
> >>> >> >>
> >>> >> >> Config file:
> >>> >> >> =======
> >>> >> >>
> >>> >> >> <SM-WS-BAM>
> >>> >> >> <Service url=http://www.xmethod.com/getVersion>
> >>> >> >> <Rule name="sendEmailWhenGetQuoteInvoked">
> >>> >> >> <expression value/Envelope/Body/GetQuote">
> >>> >> >> <Action name="emailer"/>
> >>> >> >> <Action name="..."/>
> >>> >> >> </Rule>
> >>> >> >> <Rule name=.../>
> >>> >> >> </Service>
> >>> >> >> </SM-WS-BAM>
> >>> >> >>
> >>> >> >> <Actions>
> >>> >> >> <Action name="emailer">
> >>> >> >> <Description/>
> >>> >> >> <Adaptor name="org.apache.sm.Emailer">
> >>> >> >> <smtp-host name="mail.webmail.org">
> >>> >> >> <from address="[EMAIL PROTECTED]">
> >>> >> >> <to [EMAIL PROTECTED];[EMAIL PROTECTED]>
> >>> >> >> <message value="There is a new quotation
> >>> >> >> coming
> >>> >> your
> >>> >> >> way!!">
> >>> >> >> </Adaptor>
> >>> >> >> </Action>
> >>> >> >> </Actions>
> >>> >> >>
> >>> >> >> Flow (inside the BAM component)
> >>> >> >> ===
> >>> >> >> note: The usual MEP will be followed to pass the payload to the
> >>> >> >> next
> >>> >> >> component in line.
> >>> >> >>
> >>> >> >> 1) Fetch the Source from the Normalized Message
> >>> >> >> 2) Fetch the rule to evaluate depending on the endpoint-request
> >>> >> >> URL
> >>> >> >> 3) Check for condition and get the evaluation result (using
> >>> >> >> java1.5xpath's evaluate method)
> >>> >> >> 4) Get the adaptor to invoke and invoke it. (Adaptor instances
> >>> >> >> will
> >>> be
> >>> >> >> cached ) - from the action definition.
> >>> >> >>
> >>> >> >>
> >>> >> >> Phase 2
> >>> >> >> The component would be extended to monitor any payload. This
> will
> >>> >> >> be
> >>> >> >> achieved using appropriate marshalers, which will convert the
> >>> payload
> >>> >> to
> >>> >> >> xml. The marshaler to use could be indicated as a property value
> >>> >> >> in
> >>> >> >> the
> >>> >> >> MessageExchange. The rest will be per phase 1.
> >>> >> >>
> >>> >> >> Possible use:
> >>> >> >> ==========
> >>> >> >>
> >>> >> >> Servicemix 3.0 currently is distributed with several samples,
> one
> >>> >> >> of
> >>> >> them
> >>> >> >> being the http-binding, which internally uses a saaj binding to
> >>> >> redirect
> >>> >> >> the
> >>> >> >> message to a soap endpoint. The BAM component could be used
> >>> in-between
> >>> >> >> which
> >>> >> >> would enable the user to monitor the payload and take action.
> >>> >> >>
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Cheers,
> >>> >> > Guillaume Nodet
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Cheers,
> >>> > Guillaume Nodet
> >>> >
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >>
> >
> >
> >
>
>
>
--
Cheers,
Guillaume Nodet
