Trecx:ExitStrategy

From Bodington Wiki

Jump to: navigation, search

Back to TReCX Summary of meeting held between Alexis and Adam on 16/Aug/06

We feel that the following work needs to be done before TReCX can be considered to be finished

Contents

Coding

Event publishing

  • write Publisher singleton class for easy construction of events with JAXB classes. This should have optional validation to assist developers in creating events that validate against the XML schema. This would remove the requirement to run the publisher against an accessible validating tracking store. The validating capability would be intended as a developmental convenience and not for production use.
  • use above in JSP fronted test harness.
    • test harness is driven by a properties file of possible events which can be randomly accessed to help build up test messages
    • JSP will accept 'number of events to send' as a parameter, eg, 'send 10,000 events'
    • JSP will accept a timeframe within which to generate events, eg, 'send 10,000 events randomly scattered betweenJune 14th 2004 to August 26th 2005
  • WSDL for RESTian event store. This only implements the PUT method, all other methods will be 'blank'. This needs further investigation to ensure it is sensible.

Reporting / Tracking Store

Demo

We should have an easily installable demo which runs in a single servlet container and which utilizes some kind of embedded / in-memory ( e.g. Derby / HSQLDB). This would be used to get a flavour of the system.

This could comprise of three WAR files:

  • WAR #1: a tracking store with an in-memory database.
  • WAR #2: identical to WAR #1, but running at a different context / URL path.
  • WAR #3: a sample web-application with knowledge of the first two. Using something like JSPs this would enable a user to populate the tracking stores with sample data and then perform queries that collates reports with data gathered from the two.

A user could therefore deploy all 3 to a servlet container and by visiting WAR #3 receive a demonstration via their web-browser.

Documentation

We need a user guide with the folowing sections

  • Overview
  • For sys admins
  • For developers

Overview

  • Executive summary in 'plain english'

For sys admins

  • overview
  • system requirements
    • servlet container
    • database
  • configuration
    • of publishing source
    • of tracking store
  • installation / deployment

For developers

  • system overview
    • written description
    • UML
      • high-level package diagrams (done)
      • class diagrams (auto from eclipse)
      • interaction daiagrams (Alexis to sketch, Adam to draw)
  • getting started with development
    • IDE
    • required software
      • servlet container
      • database
    • Ant tasks
  • list of example events. Look at the functional requirements and specify for a number of the actions what the event list should be. This could be done in a table. Ideally, we should do this for every action on the page.

Back to TReCX