SAVARA Roadmap for next year

[objectiser]

Just before we all go on Christmas holidays, I wanted to get everyone thinking about the SAVARA roadmap for the next year (or even two).

We are close to releasing the first milestone for version 1.0, which will provide a starting point, but we need to flesh out the remaining milestones for this first release (i.e. Eclipse based), as well as start defining an outline plan for the second version (i.e. web based).

We also ideally need to move to a "time boxed" release schedule, so we should decide on the release intervals. This may partly depend on how much resource can be allocated to the project, as it is no good having releases too often, without much progress between releases.

The other complication is that because SAVARA is in some respects an aggregation project, consuming other internal and external open source projects (e.g. SOA repository, Oryx BPMN2 web editor, etc), synchronizing releases between projects may be an issue. But we can deal with these issues as they arise.

So first step is to start recording required features/enhancements/bugs in jira, and then early next year we can begin allocating them to milestones associated with either Version 1 (Eclipse based) or Version 2 (Web and Eclipse based).

[objectiser]

Steve and I had a quick discussion about SAVARA roadmap this morning. This roadmap included a number of small features, that will be recorded in jira (right Steve ) - but there was a single feature that would require more significant effort, a monitoring GUI to replace the current simple swing based GUI launched from Eclipse.

The problem is that, apart from looking too techie, it only enables conversation instances to be viewed that start during the lifetime that the monitor GUI is running. So it is useful for debugging, but not production use.

Similarly, the monitoring agents currently integrated into JBossESB don't have a persistence mechanism, so are only suitable for short lived conversation instances.

So we discussed having two further milestones (M2 and M3) for SAVARA 1.0. This was primarily due to the time it may take to build the monitoring web-based GUI. However this would still be based on non-persistent monitors in the runtime.

After further thought, and while building some slides for a presention on SAVARA, I realised that runtime monitoring is also used in support of Integration Testing - to ensure that the complete system behaves as expected.

Therefore, one other approach we could take is retain the existing swing based GUI for SAVARA 1.0, as well as the non-persistent monitoring agents. We use them as demonstration of the runtime monitoring capability, but make it clear that for version 1.0, these are only intended for use in helping to debug a distributed system against the expected choreography.

Then version 2.0 will include a proper production quality runtime monitoring capability - which also fits with the additional web based focus of SAVARA version 2.0.

The benefit of this approach is that we only need to do one more milestone to address the remaining features. Version 1.0 would then be primarily focused on the design time capabilities. The other benefit is that it will give time for the SAM project to progress, which is really essential for the monitoring work.