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 <[EMAIL PROTECTED]> 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/
