On 9/1/10 12:07 PM, Ruwan Linton wrote:
On 9/1/10 8:58 AM, Sumedha Rubasinghe wrote:
On Tue, Aug 31, 2010 at 10:41 PM, Samisa Abeysinghe <[email protected]
<mailto:[email protected]>> wrote:
Sumedha and I had a chat on the right way of doing XPath tracing
for BAM.
If we look at router mediator in ESB where XPath is used, it
looks like all messages that pass through are evaluated for XPath
in the header (is that correct?)
Right and wrong, When you have the filter mediator in a certain path
it evaluates all the messages on that path to see whether this xpath
is matched, since it has two simple options, whether it matches or not
to decide the next mediation, so from the ESB point of view yes all
messages are required to go through this filter.
ESB filter mediator can look for message header, body, transport
headers and even message properties in the xpath evaluation.
In case of BAM, we mostly need to evaluate the Body and sometimes
even the Header in SOAP message.
Now if we are to evaluate this using a handler, we need to
evaluate each and every message for the given XPath. When there
are multiple XPaths to be evaluated,
+ large number of in coming messages.
/sumedha
then the evaluation cost can be high.
In oder to make it more efficient, we can make the XPath relate
to a service's operation, so that we can evaluate the XPath if
and only if, that is the operation that we are interested in.
However, then, it needs to be after dispatching that the XPath is
evaluated, as we have no idea of the operation prior to that.
Hence, it becomes an affair that cannot be handled by a handler,
but the dispatcher needs to kick in and evaluate and fire BAM
events.
There is no logic in stopping you putting a handler after all the
dispatchers, :-) IIRC there is a phase called PostDispatch,
Sorry I guess it is "OperationInFlow" not PostDispatch Phase, even you
could add a handler to the Dispatch phase specifying the phase rule as
phase last.
Ruwan
so you could add a handler to that phase and do operation based
filtering by looking at a BAM policy and then evaluate the XPath if
that works.
Thanks,
Ruwan
Thoughts please...
On Wed, Aug 4, 2010 at 9:45 AM, Samisa Abeysinghe
<[email protected] <mailto:[email protected]>> wrote:
OK then we will first look at the AXIOM option.
On Wed, Aug 4, 2010 at 9:43 AM, Ruwan Linton <[email protected]
<mailto:[email protected]>> wrote:
Sumedha Rubasinghe wrote:
> On Wed, Aug 4, 2010 at 6:20 AM, Samisa Abeysinghe
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> We are planning to provide XPath based BAM data
collection to users.
>
> For e.g., if the payload is supposed to have a PO,
the user can
> specify the path to PO ID in payload and collect a
count of POs
> that pass through.
>
> The question is...
> Do we have an XPath component, or a handler or
something like that
> we can reuse to facilitate this?
> Also, how to do this for WSAS vs ESB. I think WSAS
case is tivial,
> in that we can evaluate the XPath in a handler.
What about the ESB?
> Note that, in case of ESB, we do not collect our
own data, rather
> we bank on the stat data provided by the ESB itself.
>
> I know that we have XPath used in ESB etc, but the
idea is to use
> minimal dependencies here for BAM
>
> Generally speaking, reusing things from ESB comes with
considerable
> number of dependencies & size in MBs.
Synapse/ESB has a set of Xpath extension functions which
shouldn't be
required outside of Synapse runtime, so the ideal should
be to use the
Jaxen Xpath implementation which is there in AXIOM.
Ruwan
> /sumedha
>
> Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
>
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected] <mailto:[email protected]>
> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
--
Ruwan Linton
Software Architect & Product Manager, WSO2 ESB;
http://wso2.org/esb
WSO2 Inc.; http://wso2.com
Lean . Enterprise . Middleware
phone: +1 408 754 7388 ext 51789
email: [email protected] <mailto:[email protected]>; cell: +94
77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
tweet: http://twitter.com/ruwanlinton
_______________________________________________
Carbon-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
Thanks,
Samisa...
Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
_______________________________________________
Carbon-dev mailing list
[email protected] <mailto:[email protected]>
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
_______________________________________________
Carbon-dev mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
--
Ruwan Linton
Software Architect& Product Manager, WSO2 ESB;http://wso2.org/esb
WSO2 Inc.;http://wso2.com
Lean . Enterprise . Middleware
phone: +1 408 754 7388 ext 51789
email:[email protected]; cell: +94 77 341 3097
blog:http://blog.ruwan.org
linkedin:http://www.linkedin.com/in/ruwanlinton
tweet:http://twitter.com/ruwanlinton
--
Ruwan Linton
Software Architect& Product Manager, WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.com
Lean . Enterprise . Middleware
phone: +1 408 754 7388 ext 51789
email: [email protected]; cell: +94 77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
tweet: http://twitter.com/ruwanlinton
_______________________________________________
Carbon-dev mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
