Currently the main purpose of the activity monitoring framework is to capture interaction based information, analyse it against predefined choreographies (to ensure the protocols are being followed correctly), and then log this analyse with the activity event.

In the past, the result of this analysis has been discussed in the context of a 'error' view, but just wondering whether we should have a more generic approach that takes the logged analysis information, and then applies some decision making (possibly rules/cep) to determine how/if this information should be presented to a user.

So essentially we have the raw analysis information logged in the db, we have some general form of output displayable to a user, and then in the middle we have some mechanism that determines how to bridge the gap (i.e. when and what to display) - which will also take into account the subset of information visible (or of interest to) each user.

This middle component could also be used to disseminate information to other channels associated with the user - e.g. email, text, twitter, etc. If this was done, then would need to consider how best to deal with active updates, vs passive pulls of information from the UI - i.e. when the user logs in they would need to be presented with the summary of analysis information that may have occurred in the past while they were logged out, and sent via their active channels (e.g. twitter).

So the middle component needs to support a passive initial pull, to colate a summary of the user's recent relevant analysis history, and then send active updates to their UI, as well as their other channels.

This may be a useful approach, but also requires an understanding of users and their areas of responsibility/interest (i.e. to filter what information they should see). As a short term step towards this goal, we could start with a user-independent version that does not filter information on a per user basis, or send it to user specific channels - so primarily used to display the general results on a UI (i.e. initial passive pull followed by active updates).

In terms of the UI, it would be good to have a fixed format of the entries displayed - so the middle component would present the raw analysis information as a relevant human readable message, with an appropriate severity/priority. This can be used to display the entry in appropriate colours (etc).

It should also be possible to tag the entry with 'associated actions' that a user may want to do, regarding the record. This may be to launch another view based on information in the record, or perform some other action 'plugged' into the infrastructure (via an extension point).

Some records may also require an acknowledgement, which (when user specific information is held) can be used to determine what entries a user still needs to acknowledge, and record details of when they were acknowledged. Some entries may be distributed to a set of users, and require one of the users to take ownership of the record - i.e. to take responsibility for investigating and fixing the issue.

We should also be considering how this will interface with other external systems - for example when a certain issue occurs, it should maybe create an issue in an issue tracking system. When a user takes responsibiity for the issue, the issue tracking system should be informed to update the issue with the owner, etc.

The details of what functionality should be provided are less important at this stage. The main purpose of this post is to start us thinking about what may be required in the future, so that we design the system appropriately now.