As an addendum to the discussion on service interaction based events, we need to consider how this will work within an ESB, such as Switchyard, which is based on SCA.

Potentially all internal communications between the SCA components could be viewed as service invocations, so do we want to record each of these as activity events? Or are we only interested in invocations that only occur between the switchyard app and other external parties (i.e. go through a binding)?

My initial thoughts are that it shouldn't really matter whether these services are internal or external. They represent the invocation on a service interface, and the co-location of services is just really a packaging issue. There will be cases where the communications between 'internal' services are just an implementation detail, and those internal services are not really important, but in these cases it may be possible to filter out those service events at some level.

The next set of events for consideration is related to BPM. As an example, we can look at the events generated by the Apache ODE BPEL engine (http://ode.apache.org/ode-execution-events.html) which is used within the Riftsaw project, and therefore will be part of the Switchyard ESB.

As indicated by the types of event generated by ODE, with BPM there are a few areas of interest:

• Process instance lifecycle - at the outer level, we want to know when a new process instance has been created, and when it completes (whether successfully or unsuccessfully). The process instance id, along with the process definition name, can be used to scan for other events (potentially across other business transactions) that related to this process instance.
• Activity lifecycle - as it will not be possible to know all the types of activity a BPM system will use, having a general understanding of an activity's lifecycle (start, end) with a reference to the activity within the process definition, means that tooling can perform analysis using a combination of the events and the process definition. The start/end markers provide delimiters to understand what other activities were performed within the scope of the task.
• Scope lifecycle - may not be relevant for all types of BPM, but in the case of BPEL it is possible to define inner scopes with their own variable definitions, therefore having the ability to record when these scopes start and end may help with the management of state associated with the process instance
• Expression evaluation - can be useful to know the basis for decisions being made in the process
• Variable manipulation - reading and writing of variables, can be used to keep track of state regarding a process instance
• Correlation - ODE provides information about correlation, which could maybe be used to enhance general support that will be required for correlation in the activity monitoring infrastructure

So for BPM, I think the important information that needs to be represented is an idea of scope (i.e. which BPM task is other activities being performed in), delimiters to be able to derive metrics regarding the tasks, references to the process definition to support analysis against that description and state management, to facilitate a form of remote debugging/diagnostics.

Database related activity events:

• query
• update
• create
• delete

as with other scoped events, we need to be able to determine how long it took to perform these tasks, either having a 'start'/'end' event for each, or somehow having the duration recorded with the event.

Possibly the same types of activity should also relate to JCA resources?

We should also allow for 'custom' activities - which could be used by the service implementation to record milestones, or durations of interest. Not sure what other activities may be relevant to record from within the implementation of a service? Unless general decision results, etc