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.
I'm not exactly sure what your goals are, but you might give Eclipse's TPTP project's "common base event" specification a quick read. Even if you're not looking at using TPTP as a base for a monitoring tool, the concepts in the event specification may be useful to you. It's been a while since I've looked at it, but it presents a model for correlating monitoring events across a distributed application.
Also, and I'm probably stating the obvious here, you may want to look at the models presented by your primary choice of monitoring application. For example, TPTP provides its own server/agent framework for collecting/publishing monitoring events.
Hope that helps,
The link to the CBE specification: http://www.eclipse.org/tptp/platform/documents/resources/cbe101spec/CommonBaseEvent_SituationData_V1.0.1.pdf
Just as I was starting to think this could be the answer, I found this: http://www.eclipse.org/tptp/home/project_info/devplans/EclipseTPTPProjectPlan2010.htm
The project is being archived, "After many successful releases of TPTP, the project has evolved and matured. However, participation in the project has dwindled over time.". So there is no Indigo version.
Might still be worth investigating, or potentially using the event format, but the lack of future support would be an issue.
Thanks for the pointer though.
Looks like there may still be some life (for some TPTP sub-projects) http://dev.eclipse.org/mhonarc/lists/tptp-platform-dev/msg02992.html - a company called Verit are interested in taking over some aspects of the project. So we'll have to wait and see ......
That's moderately good news. Always sad to see a project archived.
One thing to keep in mind is that TPTP provides it's own server for collecting events generated by agents. If you're looking at using JON/Jopr for the backend, you might want to just focus on the event model provided by TPTP.
TPTP does provide some nice tooling features, e.g. the ability to scan event logs looking for common problems (although you have to do the programming for that). I always thought that could be very useful helping customers find/debug common errors. That said, it's been a while since I've done anything with it and that was some simple log scraping agents.
Best of luck,