Scalable and Agile Architectures for EBusiness Community Sports Management System (CSMS)

the CSMS site

CSMS - Short Term Plans


by Ross D. Gardler


This document outlines the plans for the CSMS project in the forseeable future. There is a separate document detailing our Long Term Plans .

0.1 release

Additional Error Checking
An extra step will be inserted into the events generation process in the Fantasy Sports Module, this will enable rules to be encoded to verify the generated scores, for example, total goals scored by a team should be equal to the number of goals identified in the result event.

0.2.x release

Move to a core/module architecture
The core doesn't really exist yet. What we have is a fantasy sports module. This release will see the introduction of the core. Instead of the user selecting a game that they want to see the scores on the core will be aware of all the games due to have been played by that time and calculate them.

0.3.x release

Introduce team management
Now that we have a core system and a sports module we can start thinking about teams and leagues. So in this release we will bring team management into play. We will support substitutions and transfers in this release.

0.4.x release

League Management Facilities
Now that we have the concept of teams we can start to publish league placings.

0.5.x release

Move to a Cocoon Portal based system
Move the user interface to a Cocoon web app. This will remove the need to install any software in order to use the system (although admittedly it will make it more difficult for people to install it for themselves should they want to hence the embedded jetty release after this one).
Make available to players
At this point the application will provide all major team management facilites. Testing at this point can be performed by the players.

0.6.x release

Allow unconfirmed/confirmed event status
Events should have a status flag that enables them to be marked as official or unofficial. There also needs to be a flag to indicate when an event has been queried by someone. Initially all events are unofficial, however, they are used to calculate published (unofficial) results. On a given day and time, all events that have not been queried are converted to official. The queried flag is used to indicate that someone thinks the event may be an error. The league administrator is asked to verify these events before they become confirmed. This is to allow scores to be gathered from "unnoficial" sources which will sometimes be faster than the "official" sources whilst still
Embed Jetty server
By embedding the jetty server in one of the releases we will be able to build a distribution that will run in full client/server mode with only the need to install Java.

0.7.x release

Move to (Xindice?) database
At present all data is stored in XML files, however they are being accesses through a URI. Therefore, we can no leverage Cocoons power to replace these files with a Xindice's XML database without the need to rewrite any code (theoretically at least)

0.8.x release

No new features will be added but the design of the system will be improved.

This release will be the first one that sees an (almost) stable core/module structure and API. It is this releae that we will start to really push to other projects for collaboration. Once this core infrastructure is in place the possible additions to the system are immense and so opportunities for multiple developers start to emerge.

And onwards...

From here we will plan the featureset to include in the 1.0 release by revisiting both our long and short term plans.