Moving from auditor to event listener

[objectiser]

Hi

The runtime governance project currently intercepts exchanges (to derive activity information) using an auditor. The downside to this is that it requires the switchyard app to currently be packaged as a war with the auditor implementation included as a dependency.

Recently I've been experimenting with the event listener as a more general approach to accessing a wider range of events, e.g. BPEL process execution events, and found that the camel ExchangeCreatedEvent and ExchangeCompletedEvent were also published through this mechanism - so now have listeners for all these events. The benefit of this approach, is obviously that intercepting all types of execution event is now independent of the individual apps, so can be administered separately.

There are currently two issues that I wanted to discuss:

1) No provider information available

When I originally started using the auditor mechanism I had the same problem, and just needed to insert the auditor at a particular point in the processing to ensure the info is available. However it looks like the point at which camel publishes these events is before the provider information is stored as a property on the exchange.

Is there any way to bring the initialization of the provider property forward, so that it is available as part of this event?

2) Blocking the service invocation

In the recent release I included the ability to define event processors that can, if necessary, abort the invocation e.g. if a cusotmer has been suspended.

It appears that the exception being generated by the rules, which are now based on the events received from the listener instead of the auditor, is being swallowed and does not prevent the invocation from proceeding. I haven't currently located where this is occurring, but want to check whether in principle this behaviour could be supported (i.e. have an event listener interrupt the invocation)?

Regards

Gary

[goc]

1) No provider information available

The provider information is determined in the addressing phase. This is the first element in the handler chain (org.switchyard.internal.LocalExchangeBus).

As far as I know, there is now event published, when the provider information is set in the message exchange.

[kcbabo]

Hey Gary,

1) Is there a reason you are not using the SY ExchangeCompletion event instead?  We use this to collect metrics in our own admin service via SwitchYardBuilder.

2) Events will not have the ability to interrupt exchanges.  Auditors are used for this purpose.

cheers,

keith

[objectiser]

Hi Keith

1) When I started experimenting with the new event listener being registered via JMX, I tried establishing an observer for ExchangeCompletionEvent, but didn't receive any. So I debugged the Event Manager and noticed the camel Exchange created and completed events. As I need to be informed when the exchange starts, as well as completes, I thought it would be useful to subscribe for these events instead. I need start and completed events, to identify the scope in which other activities occur.

So if the switchyard ExchangeCompletionEvent is available (I might need to try this out again), and an equivalent ExchangeCreatedEvent can also be emitted (including the Provider information), then that would be ideal. Should I raise a jira for this? in the meantime continuing to use the camel events?

2) A pity - I guess the decision making can still be done using the existing mechanism (i.e. rules triggered from the intercepted activity events), but the effect of the decision (i.e. blocking the invocation) would need to be made by an auditor, so it is a two phase process, with the user having to install something into their app to make it work.

Regards

Gary

[kcbabo]

For #1, there was an oversight in the Camel bus refactor that left out exchange completion events.  There's a pull request in the queue to fix it, so should be in within the next 24 hours.

I'm not a fan of an exchange creation event as I don't think it represents a meaningful state of execution in SwitchYard.  We could add an ExchangeInitiatedEvent, which is fired at the time an in message is sent on an exchange.  The reason I don't like ExchangeCreation as an event is that there is processing that happens before and after an exchange is created and then you don't have a boundary for measuring that time.  If a gateway provided a time a message was received, for example, then you could combine the elapsed time between exchange initiated and completed to determine the service invocation time.  If you add a gateway complete timestamp (i.e. when a message has been returned to the consumer), then you can measure the execution time of the gateway using received/initiated and completed/returned.

For #2, it's crossing concerns to allow the event listeners to control flow.  For example, does this apply to all types of events (e.g. deployment rollback) or just a subset?  Also, it prevents us from moving to async notification of event listeners if we choose to do so. 

[objectiser]

1) An ExchangeInitiatedEvent sounds fine to me - and I guess by that point it would have the provider info. Created jira: https://issues.jboss.org/browse/SWITCHYARD-1466

2) Totally understand - it just complicates this particular usecase.

Regards

Gary