External access to event manager

[objectiser]

Hi

I would like to experiment with using the EventManager for managing the events used by runtime governance.

Is there a suggested/preferred way to access the event manager from outside switchyard?

I see that the SwitchYardAdminService uses a jboss msc specific injected value approach - but was wondering if there could be a more standard approach - e.g. standard CDI injection, or JNDI lookup?

Regards

Gary

[kcbabo]

Hey Gary,

Are you trying to do this in a SY application or an application that's deployed outside of SY?  The latter would likely be solved by JMX support once we add it.  For the former case, the CDI suggestion is an interesting one for sure.  I can see that being used for a number of things actually.

cheers,

keith

[objectiser]

Hi Keith

I think both cases are useful, but for now I think observing events from outside SY would be main focus, so created https://issues.jboss.org/browse/SWITCHYARD-1400.

Regards

Gary

[objectiser]

Actually looking into it more, not sure this is the right way to go - need to directly subscribe to the EventManager, so at the moment would need to be within switchyard (not necessarily within the app).

I think we need to decide how runtime governance events should be collected first (https://issues.jboss.org/browse/SWITCHYARD-1380).

There are two aspects:

(a) Whether runtime governance should be enabled/disabled per switchyard app. Benefit is that if disabled, then events are not unecessarily distributed. Disadvantage is that to change this requires the app to be redeployed.

(b) How the events are captured by the runtime governance module - I think ideally this should be independent of the switchyard app. We maybe just need to have the components (and exchanges) report their activity to the EventManager, and then have a runtime governance module observing the events from here? (I think this is the approach Rob suggested a while back).

Regards

Gary

[kcbabo]

I'm not sure I'm interpreting "outside SY" correctly in your post, but observing SY events from outside a SY application would be possible with the JMX route.

Enabling/disabling per app boils down to how much overhead the collection adds.  The event generation happens right now no matter what, so the expense really depends on how long event listeners take to process the event.  There are a few things we will likely do in the runtime to fine tune this long term (selective publishing, async event notification), but that's not a now thing.

In terms of your aspect (b), exchanges already publish events through the event manager which is how we get metrics today.  Are there other events you have in mind for rtgov?   The integration can take loads of forms.  If you want to get really fancy (and really integrated with AS7), you could have your own deployment processor which selectively attaches to deployments, registers an event listener, and then collects events from there.

Lastly, the EventManager itself is really just an internal registration point for listeners and channel for event publishers.  So I think what we want here is the ability to attach an event listener from outside a SY application.

[objectiser]

Keith Babo wrote:

Enabling/disabling per app boils down to how much overhead the collection adds.  The event generation happens right now no matter what, so the expense really depends on how long event listeners take to process the event.  There are a few things we will likely do in the runtime to fine tune this long term (selective publishing, async event notification), but that's not a now thing.

One issue would be that the activity collection uses information threads reporting the activities, to perform an implicit correlation - so async event notification may cause a problem.

Keith Babo wrote:

In terms of your aspect (b), exchanges already publish events through the event manager which is how we get metrics today.  Are there other events you have in mind for rtgov?   The integration can take loads of forms.  If you want to get really fancy (and really integrated with AS7), you could have your own deployment processor which selectively attaches to deployments, registers an event listener, and then collects events from there.

Using the ExchangeCompletionEvent may be an option, in place of the current Auditor approach, but want to get the overall mechanism sorted first. Don't really want to do anything AS7 specific if I can help it

Keith Babo wrote:

Lastly, the EventManager itself is really just an internal registration point for listeners and channel for event publishers.  So I think what we want here is the ability to attach an event listener from outside a SY application.

Yes that may provide a solution - but how do you see the event listener being registered/deployed?

[objectiser]

Sorry didn't answer your question about the events - as well as exchanges, we will need more details execution events from riftsaw and jbpm among others. Not sure whether it is a good idea to distribution these through the EventManager yet - may be localised interception would be better.

[kcbabo]

I would really like to see as much come through the event support in SY as possible.  It doesn't have to, natch, but it would be nice if it's a fit.  The idea would be to homogenize these events through our event API and anyone can subscribe to them.

In terms of registering the listener, I honestly think the best bet is through AS integration.  That said, I can understand a motivation for keeping it independent of AS as well.

Sync notification could be a probably with JMX.  IIRC, the default JMX notification publisher implementation is asynchronous.  We could avoid using JMX notifications and just call directly into a registered listener MBean.

The CDI idea for observing events inside an application is still really cool (and something the community has asked for in the past).

[objectiser]

One issue with the current EventManager mechanism is the events need to be derived from EventObject. Is there any particular reason for this, as the source objects are accessed via typed getters anyway?

Its just it means I need to create a wrapper class for the events generated by the BPEL engine, so obviously won't be as efficient as if the original events can simply be forwarded.

Regards

Gary

[kcbabo]

The main reason is that EventObject is a pretty common base abstraction Events.  The hook for a source reference is a common attribute for events and creates a uniform way of representing the relationship between the event and the entity producing the event.  EventObject also implements Serializable, which helps weed out events which will be difficult to remote (if required).

[objectiser]

Hi Keith

Agree that it is a common pattern, but was more commenting based on the fact that the three switchyard classes use themselves as the source, and the BPEL events are not currently derived from it (although they are serializable). Not sure if jbpm events are derived from EventObject?

So if you would prefer to stay with EventObject, rather than possibly using Serializable as an alternative, then we can modify the bpel events - but not sure if this would cause other components an issue in the future.

Regards

Gary

[kcbabo]

Are you saying the events use themselves as the source?  My recollection is that the events actually use the entity that the event relates to as the source (e.g. ExchangeCompletionEvent uses Exchange as source).

[objectiser]

Yep, sorry your right

Ok, so I'll upate the bpel events to be derived from EventObject.

Regards

Gary