We are now at the early stages of building the Savara web application. We are aiming to use a 'desktop' style, so the user would have effectively a 'Savara' desktop within their browser.

They would then have a menu (similar to a windows start menu) from which they can select the range of 'applications'. This thread is intended to consider what should be the initial set of these virtual applications that should be implemented.

There may also need to be some navigation between applications - in a similar way to how Eclipse views work, i.e. when a user selects some information in one window, it causes another window to update its content to focus on the same info but displayed in a view specific manner.

The applications will eventually be subject to access control, so that they will only be displayed to users with the appropriate permissions/roles. This could be for security reasons or more likely as a means of targetting applications to the relevant user community.

So here are a possible initial set of apps:

1) Activity event viewer

This application would list the raw activity events, enabling the user to enter filtering criteria to restrict the events displayed. The filtering criteria should include context information. The specific set of context names should be derived from the values stored in the database, allowing the user to build up a query expression based on a combination of the context fields (e.g. Context 'Trader' with value 'Fred Bloggs' AND context 'Counterparty' with value 'Acme Corp').

Should the application support realtime updates? In debug/test situations it would be useful to see the events as they are being logged, however this would only be useful in situations where there is minimal traffic. In production environments it is unlikely that the user would be able to interpret the events quickly enough.

The application would need to atleast provide a refresh button to re-apply the same filter (query) criteria as the underlying information may be changing.

Might be best to decouple the event source (and filtering mechanism) from the display window, so that the viewer is simply used to display a set of activity events, without regard to where they came from - this would enable other applications that derive a set of activity events using different means, to use the same 'application' to display them.

Some activity events represent a warning or error situation - may depend upon particular analysis information - in which case these events should be highlighted based on colour and/or other markers (e.g. icons), to indicate this fact to the user. Detection of the 'status' of an activity event should be configurable, as new types of analysis information could be added to activity events over time.

When a user selects an individual event, they should be able to launch another window to view the event details (see (2) below).

2) Activity event details viewer

(This application should not be selectable from the main menu, and instead launched from other applications with a particular event to display).

This window should display information from the specified activity event based on configurable templates.

This window could be triggered from a number of different applications. We need to consider what behaviour should be supported if multiple events are selected from different windows:

a) should each selected event launch a new event details viewer - could result in many windows cluttering the desktop

b) should a single viewer be used, so selecting the events in the other windows just change the content of the viewer window - might cause problems if user needs to compare two events

c) or should a tabbed approach be used, as in most web browsers, so a new event causes a new tab to be created - possibly enabling tabs to be separated out into new windows, and then enable the tabs to be moved between different windows of the same 'application'

3) Business transactions viewer

As the activity events are reported, they will be correlated based on information contained in the message payload or explicitly provided by the event source. A correlated set of activity events may relate to a particular business process, and encompass events generated by process execution engines and choreography monitoring capabilities.

A particular business transaction may have more than one correlation id - the relationship between these correlation ids may be represented based on a dependency tree (not sure if graph has possible???).

So although the viewer should display a list/table entry for all correlation ids (whether individual or composite), it should also enable parent correlation ids to represent their child correlation ids in a tree. Users should also be able to navigate to a parent correlation id (if available).

Where an error or warning status is associated with a particular event that has been correlated against a particular id, it would be good to be able to reflect that status against the correlation id. Where a correlation id hierarchy is involved, the status should also be reflected up the hierarchy.

Along with the correlation id information, this viewer should show the start time, and current end time (in case no finished) of the events aggregated against the correlation id.

4) Business transaction viewer

Initially this could be a restricted form of the (1) Activity Event Viewer, so displaying the raw list of activity events that comprise the specific correlated business transaction of interest.

Eventually, when selecting a particular correlated business transaction, it would be nice to launch a graphical representation of the business transaction overlaying relevant information about the execution characteristics of the transaction, and where appropriate, any perfomance or SLA issues that may have arisen.

Initially just the event list could be implemented, but when a graphical view is available, these could be defined in separate tabs - showing the graphical view as the main tab, with the event list in a 'source events' tab.

5) Execution path analysis

A similar app to (4), and could possibly be achieved using the same graphical viewer with some flexibility in its use - this app would enable multiple correlated business transactions, over a particular user configurable time period, to be overlaid upon a graphical representation of the execution of the transactions.

This could enable information about:

a) how many transactions took particular paths

b) average execution times at different nodes/links

c) average analysis against SLAs defined on different parts of the transaction

etc

Also should have an 'advice' region which can give some suggestions related to areas of concern.

(This is not necessarily going to be implemented in initial set of apps, but just provides some context for what might be possible)

This just gives an initial idea of what could be provided. Feedback on the functionality is welcome.

These applications are initially all based around the activity event information. However other 'applications' would be required over time, including a UI for integrating with the Guvnor SOA repository to view and potentially edit artifacts in the repository, as well as BAM and analytical apps.