Re: JBI Profiling Tool

[rotgier <ro...@gmail.com>]

Dear Andrea, Gnodet,

I have taken look at Spagic. It seems to be a great integration solution
which could aid the complexity of ESB configuration. As far as I understood
first You are building some abstracion of integration process which in
further step can be mapped to example BPEL or SMix JBI (probably by other
people who specilize for example in SMix). Spagic is something a lot more
advanced than the JBI monitoring tool that we are trying to propose.
I was interesed in the monitoring aspect of Spagic so I took a dive into the
code :>. It seems to me that You are using the mechanism of
ExchangeListeners which is provided by ServiceMix, but Unfortunately It is
very ServiceMix specific. The JBI specification says nothing about such
Listeners. As long as I understood from the code of 2.1.0 version the
interceptor class is AuditingExchangeASyncListener which listens for
MessageExchanges and send them by JMS to MonitorStandardConsumerProcessor
for further analysis. So it is just absolutely enough ...but only for SMix.
You could not use it for example in OpenESB ??? Or am I wrong here ?
Another thing that bothers me is that You are relying on ServiceMix's
CorrelationId property which is provided by every component of ServiceMix.
Do You use this mechanism to correlation MessageExchanges flying between
various components ? If so It is also unfortunately very specific to
ServiceMix (I belive that SENDER_ENDPOINT is also used by You)


As gnodet said the key aim of our project is to be generally JBI compliant.
So we came up with the idea of intercepting MessageExchanges using AOP.
However this mechanism is not perfect ... It is a kind of heuristic
algorithm which try to correlation the MessageExchanges on the basis of some
assumptions. As gnodet quickly noticed, there are some components that do
not fulfil our assumptions and hence we are unable to correlate MEs in those
components. (actually we were trying hard to overcome this ApacheOde
approach and use some additional logic to correlate MEs but we failed in the
mesh of unrelated threads, persistance layer and mapping JBI
MessageExchanges to some Ode's equivalents :]. It turned out that the reason
of this is a Jacob framework on top which Ode is build :]).

Ours current heuristic looks like this:
(ME = Message Exchange, NM = Normalized Message, JC = JBI Component)
1. InOut ME1 with InNM1 and OutNM1 set are Recieved by JC1
2. JC1 processes the ME2 in some of its threads reading its OutNM1
3. JC1 creates ME2 which will be filled (with NM) on the basis of data
provided in ME1. So what we want to achieve is to correlate ME1 with ME2
3. At same point in a Thread X JC1 invokes some methods of OutNM1 to read
its contents
4. At same point in a Thread X JC1 on the basis of the contents of OutNM1
JC1 creates a InNM2
5. At same point in a Thread X JC1 sets contents of InNM2
6. JC1 processes the ME2 in some of its threads setting the InNM2 to the ME2
7. JC1 sends out the ME2

So our assumption is that there exist some Thread X in which a compontent
touches both OutNM1 and InNM2. On the basis of this relation we are able to
correlate ME1 and ME2 and set a correlationId to them !!

I will stress it again that this is not the perfect mechanism but It seem to
work on both ServiceMix and OpenESB and it is exactly what we want to
achieve.

As I said before we had problem with correlation of MessageExchanges in Ode.
When I analyzed Spagic I found a OdeListener which traces the variables
operations in Bpel. But I am not sure If its purpose is to maintain the
correlationId between MEs. I figured that If You use the CorrelationId from
ServiceMix You also have problem In Ode which does not support it. How did
You overcome this issue ?

So what do You think about such a heurisitic ? Is it worth to contruct
solution based on such heuristic ? How is it likely that ServiceMix
implementation will change so much that such above assumption will not be
true ?


Thanks in advance for any response,


Kind Regards,


Marek Psiuk


gnodet wrote:
> 
> Yeah, I think the point was to not be specific to ServiceMix, but only
> use the JBI api.
> However, even using AOP, I'm not sure that this is possible because
> you'd have to make
> assumptions on the component thread management, which may prove to be
> false
> on certain components (Apache ODE for example).
> 
> On Tue, Apr 29, 2008 at 9:40 AM, Andrea Zoppello <zo...@tiscali.it>
> wrote:
>> Hi,
>>
>>  In spagic project ( http://spagic.org ) we've just done something about
>> what byou want you achieve.
>>
>>  We're able to get all exchange from servicemix and to build a sort of
>> process management around servicemix
>>  esb.
>>
>>  Andrea
>>  rotgier ha scritto:
>>
>>
>>
>> > Dear ServiceMix Developers,
>> >
>> >
>> > Together with my friend I'm working on a subject of monitoring a JBI
>> > compliant ESB. It is actually a subject of out Master Thesis :>. So we
>> were
>> > focusing on ServiceMix and OpenESB implementations. At the beginning we
>> were
>> > total noobs ;) (maybe we still are) but we cracked through the JBI
>> > specification and analyzed how things look in ServiceMix and OpenESB.
>> > After some time of research we have decided to create a solution that
>> would
>> > be 100% (or close to that :>) JBI compliant and would not assume
>> anything
>> > about specific mechanisms (either SMix or OpenESB) [Unfortunately that
>> was
>> > not truly possible :|. For example SMix has this not JBI compliant
>> > 'processInbound' method which is often used in DeliveryChannelImpl]. We
>> > decided to go AOP way. We created an sniffy aspect which intercepts
>> > everything that goes through JBI's DeliveryChannel implementations. It
>> > turned out that it was quite easy. We went a step further and provided
>> a
>> > mechanism of correlation MessageExchanges that are related - in fact it
>> is
>> > very similiar to ServiceMix's correlationId (we examined ThreadLocal's
>> > oriented implementaion of it).
>> > So at the end of the day we have a mechanism that without a slight code
>> > modification of JBI Container itself is able to intercept all
>> > MessageExchanges flying through the components. At the beginning of our
>> work
>> > the assumption was that our solution should be inline with the idea of
>> > Application Response Measurement (http://www.opengroup.org/arm). We
>> studied
>> > the ARM specification and decided that it is far to complicated for our
>> > purposes but we can use the concepts invented there !! An Idea of
>> profiling
>> > tool for JBI came up !!
>> > We were wondering how the JBI profiling session could look like and
>> what
>> > would be most useful ?? We thought that it would be interesting if at
>> the
>> > end our GUI would be able to draw something like Sequence Diagram
>> > (http://upload.wikimedia.org/wikipedia/en/3/32/CheckEmail.png). The
>> entities
>> > that would be on such diagrams could be specific endpoints in
>> componets(BC
>> > and SE). Each arrow would be connected with some ME exchange and would
>> be
>> > described by the time that elapsed and maybe some other information (we
>> are
>> > still working on it).
>> >
>> >
>> > So why I am telling You all this things. We decided that in scope of
>> our
>> > MasterT we want to make same useful tool that could be really handy for
>> both
>> > Developers and Users of JBI Containers. My question is: Could such JBI
>> > Profiling Tool be useful ?
>> >
>> > I am aware of ServiceMix's visualizations: dotViewEndpointListener and
>> > dotViewFlowListener (they are based on MessageExchangeListeners). Those
>> were
>> > not an options for us because we wanted JBI compliance. But I am aware
>> that
>> > functionalities of our mechanism would overlap with those
>> dotViewThingies
>> >
>> >
>> > So what do You think about it ?
>> >
>> >
>> > Thanks in advace,
>> >
>> >
>> > Kind Regards,
>> >
>> > Marek Psiuk
>> >
>> >
>>
>>
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> 
> 

-- 
View this message in context: http://www.nabble.com/JBI-Profiling-Tool-tp16908206p17293632.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.