Primarily we have been focusing on activities related to interactions between services. These are usually correlated based on some business information within the messages being exchanged, although in some cases the messages may be distributed using technologies that have other approaches to tracking or correlating the messages to a business transaction.

In the activity model we currently have two types of information, the interactions (which are between distributed applications or services) and the activity events which relate to activities undertaken within a particular application or service.

So we need to be able to correlate a business transaction across both of these types of activity event.

Within a particular application, especially an enterprise application, it may be possible to leverage the transaction as a means of identifying activities being performed across different layers of the application (coupled with host details to scope the txn to a particular machine). Alternatively possibly the thread may be adequate in some cases - we basically need some local identifier that can link the different activities being performed for the business transaction.

When it comes to interactions between the services, we need to be able to link the sending of a message with the business txn in the local app doing the sending (e.g. based on txn or thread id). As mentioned, the interaction may be identified by a business correlation key or possible a technical id attributed to the message wrapper. The main point is that the same id used by the sender must be used by the receiving message interceptor. Similar correlation must then be performed between the receiver and the business txn within that receiving application.

Each interceptor, whether for internal application activity or external interactions, will only be reporting its local information - or multiple pieces of information if appropriate - the actual threading together of the links between the different activity events will need to be performed at a later stage. This could be done as part of a post analysis phase and recorded back in the database, or when a particular business transaction is being requested - but that means the query would need to reconstruct the trail, performing multiple queries to retrieve each stage of the transaction. This will be slow and in general we may wish to refer to the 'business transaction' as a whole for many different purposes.

The other aspect to be considered is how best to distribute all of this monitoring information. As this is encapsulated in the ActivityStore implementation used by a particular server, it is possible to initially store directly in the db, but later on find a more efficient means to batch up, compress and deliver to a central location for further processing. This approach is used in JOPR, so its possible we could leverage their infrastructure - but depends whether this dependency is beneficial - or whether this is just one option of many for handling the distribution of the activity monitoring data.