The initial tasks would be:

1) As part of the business/service activity work being carried out in existing jboss.org projects, a model of activity events will be developed. The student working on this task will help to define the requirements for this model, to ensure that the required information is available to achieve this task.

2) The inputs into this task will comprise:

a) A set of activity events representing the execution of a business transaction across multple interacting services within a SOA.

b) A BPMN2 choreography model defining the business process spanning across the SOA

c) One BPMN2 process model per service, defining the internal logic of each service (where available) or as a minimum the externally observable communication behaviour

3) The goal of the UI will be to enable a user to start from a top level view of the business transaction, where activities span across services. This view will use the visual representation of the BPMN2 choreography as a means to overlay summary details regarding the activity events that relate to the communications between services - e.g. latency, time spent within a service, etc.

4) Users should be able to drill down into individual 'participants' (BPMN2 choreography term) to view the activity associated with the individual services. Each service will have an associated BPMN2 process model that will define the detailed or abstract behaviour, depending upon the level of information available. As with the choreography model in (3), various metrics derived from the activity details associated with the internal tasks, can be displayed on the visual representation.

5) Users should finally be able to drill into further details related to a particular task, which at this stage will show a representation of the activity events within the scope of the task selected.

6) Provide replay functionality to allow the sequence of activity events to be dynamically highlighted on the visual representations, with the user being able to "step in" and "step out" where appropriate, in the same style as traditional debugging. If variables and scopes are defined as part of the activity information, then it should enable the values in scope to be displayed as appropriate.

Various approaches can be considered for defining the visual representation, including GWT, JavaScript, SVG, etc.

Further enhancements that can be considered for extensions to this work:

a) When models do not necessarily exist, a dynamic representation of the choreography and/or process models can be derived and used as the basis for the visual representation. This can be useful for monitoring legacy environments where models do not necessarily exist. The disadvantage is that the user does not get to see the path taken by a particular business transaction instance in the context of the overall business process - whereas using a pre-defined chorepgraphy and process model(s), allows the user to see the various paths available, and which one was actually taken by the specific business transaction instance.

b) Allow multiple business transaction instances to be represented in the graphical representations - main focus of this would be to show average/min/max values for metrics related to performance/latency, and also the count for the number of instances that take different paths in the process, when there is divergence.

c) Service deployment top level view - as an alternative to the choreography view, showing the set of services and the communication paths between them - giving another opportunity to display metrics related to communications between service pairs (e.g. min/avg/max latency, response times, etc).

Other suggestions for extensions to the work are appreciated. Whether they are in scope for the initial work or not, it is useful to understand future directions when undertaking the initial design and implementation work.

Hi Shasha

The Eclipse BPMN2 editor may be used to create the choreography and process models, and therefore if any additional information needs to be included in those models for later analysis, this editor may become relevant. The project lead for this editor works for Red Hat, so it should be easy enough to arrange discussions around how to enhance the editor if required.

However for this particular task the main aim is to have a web based visualisation. This can either be developed from scratch, or borrow some code from a web based BPMN2 editor (such as the one used in jBPM), However the main point is that this is not intended to be a BPMN2 editor - only a tool for visualising activity and analysis results in a familar notation.

The Savara project does include a jaxb based BPMN2 model, which should be used in preference to the Eclipse BPMN2 model project, to avoid any unnecessary Eclipse dependencies within the web app.

All of the information (activity events) will be (eventually) obtained from monitoring the execution of services in the SOA. So the relevant timestamps of different tasks/activities will be available to support these calculations. However this information will be supplied to this web app, so it is not in the scope of this task to manage the collection etc of the activity information.

If you are interested in taking on this task, then as we get into further discussions, we can work out the natural boundary between this work and the wider framework in which it would be used.

Hope that helps clarify things.

Regards

Gary

That looks fine to me - although just to check, I assume the 'reply' in view (e) is a typo and should be 'replay'?

Although BPMN2 is definitely the current focus for the project, as mentioned in the task writeup - I am just wondering whether we should actually think about it as a pluggable graphical style. So at the top level we just consider it to be an end-to-end architecture behavioural model (i.e. choreography), second level being the service behavioural model and then finally into the individual tasks.

So internally within the implementation you just deal with generic/abstract models/graphs, which can be derived from potentially any business model, and rendered in any supported graphical style, as long as the appropriate information is carried.

Sorry to start changing the requirements, but if we were to look at it from this more generic point of view, it may provide greater flexibility in the future - but as previously mentioned, the initial target for the work would be using BPMN2 choreography and process models as the source, and therefore rendering the information using a BPMN2 style.

Thoughts?

Regards

Gary

Some work has now started on the BAM infrastructure, which can be found here: https://github.com/savara/savara-bam

Based on having a better understanding of how information is collected (i.e. as ActivityUnits which are a grouping of activities that occur within a scope/transaction), I think there are a few options for how the model will be created for display using the web app:

1) Displaying a business transaction instance - the choreography view

a) This could be achieved by obtaining a graph of inter-related ActivityUnits, linked by 'conversation id' correlation, and translating them into nodes in the JSON model. The benefit of this approach is that the ActivityUnit id can be stored in the JSON model, and used to retrieve the list of actual activities that occurred - as the ActivityUnit represents the activities that occurred within a particular transaction for a service/process.

b) The other approach would be to use a protocol monitor that would interpret the communication events to determine the path and current location within the choreography.

c) If a BPMN2 choreography is available, this can pre-initiaize the JSON model with all possible paths, and (a) or (b) can then apply their information to show the actual path taken. This also means we need to be able to reflect in the graphical representation which paths have been taken - so possibly the paths that have not been executed needs to be greyed out (i.e. faint).

2) Displaying a service instance - the process view

1 (a) and (c) also apply for the process view, with the exception that ActivityUnits would be obtained (and linked) based on correlation related to a process id, or linking message request/response ids.

3) Updating a business transaction or service instance

It would be possible to continue to monitor the business transaction or service instance (if not completed) and update the JSON model, pushing the updated version to the UI (depending upon the technology being used).

4) Aggregated view

For both business transaction and process views, it will be possible to aggregate the information from multiple instances to present an overview of how the business transaction or individual service is operating.

As there is a few ways that the JSON model could be created, this task should start with:

- defining the JSON model as a simplified representation, that is capable of representing BPMN2 choreography and process models, but without much of the unnecessary information. Layout information (which can be optional) should be defined on the nodes themselves rather than as a separate part of the model. The model should also support 'annotations' that can be used to define value added information for display on nodes and/or links, along with the ability to set the priority/importance of the information, which can be reflected in different colours

- providing a simple test REST service that can be used to retrieve example JSON models and display them

This should then enable the task to focus more on the capabilities required in the UI.

As the BAM infrastructure work progresses, we can then discuss various ways to integrate and build the initial JSON models from live data.

Just to clarify the point about optional layout information - if a BPMN2 chore/process model is not available, and the JSON model is built up dynamically, then layout information may not be available. So it would be useful if the UI can provide a dynamic layout algorithm to cope with missing explicit layout info.

The problem is that although ideally choreography/process models will be available for all important business processes being monitored, when the technology is initially used it may be to monitor existing applications where no models exist. So it would be good if the system could cope with that situation.

This could probably be achieved on either the client or server side, so we just need to consider where best to handle this?