Trecx:Workpackages

From Bodington Wiki

Jump to: navigation, search

Back to TReCX

Contents

Workpackages from original bid document

The tasks should be attenmpted in the following order

  1. WP 1
  2. WP 2
  3. WP 3
  4. WP 4
  5. WP 5
  6. WP 6
  7. WP 8 and 10 (together)

The following can be deferred until the end of the project. The demo can include two (or more) instances of the tracking data which can be inflated using pseudo random event data.

  1. WP 7
  2. WP 9

WP 1 Use Cases

Deliverables:

  1. use cases document

We will assemble use cases from the following e-learning contexts: Forum, Wiki, PDP, image database (CLIC), repository (ASK), VLE, assessment (& questionnaire) and e-portfolio. There appears to be much interest in a tracking service so we will use CETIS and JISC networks to tender for requirements / use cases from non-project members.

WP 2 Requirements

  1. System requirements

We will look at what kind of tracking is needed, what kind of queries must a service support? Are there security, data protection issues?

WP 3 Survey of Existing Practice

Deliverables:

  1. Short report into useful technologies

We will look into existing software, standards and practice in this area and investigate other existing non-SOA applications that operate in this domain.

WP 4. Initial Design Documentation

Deliverables:

  1. UML Architecture Diagrams.
  2. Design Documentation.
  3. Preliminary WSDL Interfaces.
  4. Tracking Event Design.

We will begin to examine how a WS service should be used to transport this data. We will look at how security will be implemented in this system. Discussions about levels of granularity and minimum level of details will be covered as well as initial suggestions regarding data security and privacy.

It is expected that the WSDL interface should support both single and bulk transfers of information to prevent the Web Services becoming too big a bottleneck.

WP 5 Remote Store Design and Development - Store and Tracking Service

Here we will develop the remote tracking store. This will consist of a data store (database) into which tracking events are placed. These events are received from a WS call and passed through to the data store. Both the external (WSDL) and internal (Java) interfaces of this toolkit will be documented so that the toolkit can be connected to a different data store without a large amount of re-engineering.

This remote store will be a small independent application that can be deployed in a web server. It will be written in Java and developed for deployment in Tomcat but should be deployable in any J2EE compliant servlet container.

The toolkit will consist of a implementation of a service provider for the tracking WSDL which pushes the events through a Java API. This component of the development should be reusable by other systems wishing to implement their own tracking event store. The toolkit will be cleanly separated from the example remote store.

Breakdown of Tasks

Documentation should be prepared at all times!

Points in italics can be left until later

  1. enumerate all different event types (see design issues document)
  2. Design schema for event messages (see design issues document) Use oXygen editor or maybe JAXB to do this. (See example implementation)
  3. Get databases up and running: PostgresSQL and Hypersonic or Derby.
  4. generate JAXB classes from schema
  5. use hyperJAXB2 to interface with database (See tracking store design?) If this approach doesnt work then:
    1. Create database structure (using DdlUtils)
    2. Interface the tracking service to database (ie, Application), use SQLMaps or equivalent
    3. Implement tracking service (with JUnit tests) and test - see configuring tracking store, messaging format and validation of messages.
    4. Design tracking store database (see possible database design).
  6. Write schema for tracking store configuration file (DONE)
  7. use JAXB to create class for tracking store config (maybe use apache commons config)
  8. use config file to control validation by JAXB classes and to halt messages from unauthorised IP addresses
  9. Produce ant tasks to build deployable quickstart
  10. Produce WSDL for service
  11. Use eclipse to produce UML class diagrams
  12. Produce UML component diagrams
  13. Document message format and include examples (in wiki)
  14. Document internal database format
  15. Document how to install
    1. quickstart
    2. 'proper' service

Deliverables

  1. Data Store Design Document.
  2. Java Implementation of the Remote Store.
  3. Web Service acting as a sink for tracking events.
  4. Documentation of external WS API and JavaDoc of internal API.

WP 6. Tracking Toolkit

This tracking toolkit will be developed to connect back to the tracking Web Service exposed by the remote store and send tracking events to it. This toolkit will have a well documented Java API to allow it to be attached to existing Java application. At this point real world tests should being to be possible as we should have both the client and the server for sending tracking events. The Web Service interface on the tracking toolkit should conform to the appropriate WSDL.

It is expected that the tracking toolkit will need internal queuing for tracking events to prevent the process of collecting the tracking information to impact on the real-time response of the application.

Breakdown of Tasks

Document throughout!

Points in italics can be left until later

  1. design configuration file format (see configuring the trackees), use oXygen to design schema. (DONE)
  2. configuration helper - use JAXB to create classes which hold configuration (part of toolkit)
  3. use JAXB to create classes for events (this probably done in previous workpackage) (part of toolkit)
  4. write message construction Factory - helper to make creating messages easier (part of toolkit) - this will generate an event (java) object which will be passed along to the message dispatcher
  5. message dispatcher - a utility which can be fed individual messages and will fire the messages off as dictated by the configuration file.
  6. create command line application to generate pseudo-random list of events - use HTTPClient
  7. ant script to run test harness etc
  8. demo of test harness invocation and messages appearing in the database
  9. use eclipse to produce UML class diagrams of tracking client toolkit
  10. produce UML component diagrams of toolkit
  11. instructions on how to use library (2-3 sides)

Deliverables

  1. Java implementation of a tracking toolkit.
  2. Web Service client that connects to a remote store Web Service.
  3. Documentation of internal Java API.

WP. 7 Tracking Toolkit Glue: {Defer until later}

Here we will be attempting to take the tracking toolkit and do a simple demonstration integration with a web based forum application. We intend to use AOP (using AspectJ) to perform the integration so as not to have to modify the forum code base. Using AOP means that the changes can be made after a forum binary has been built and should allow changes in the forum code base to not affect the glue code.

Breakdown of tasks

Document throuought!

  1. get MVNForum running (would it be worth doing this on 'perch' as we may have to demo off-site at some point)
  2. 'simply' (!) use AOP to intrerface with tracking toolkit
  3. short report on AOP (2-3 side max.)

Deliverables

  1. forum with integrated tracking toolkit.
  2. Integration report on how the development was done.

WP 8. Search Toolkit Design and Development.

Here we will develop a searching interface that services requests for searching a store of tracking events. This will be a toolkit that can be integrated onto any store of tracking information and then be queried via a Web Service.

Breakdown of Tasks

Points in italics can be left until later

  1. Finalise Level I search API. (See database searching.)
  2. Write Java search API interface based on above
  3. Construct stream of queries (use HTTPClient)
  4. Create Tracking Store configuration schema (see configuring tracking application (DONE)
  5. Create instance of schema
  6. write servlet filter which rejects messages which arent from the reporting application *(could be same as done before)
  7. put above in web.xml
  8. Implement search interface (noting optional validation step and other configuration parameters).
    1. If we are not using HyperJAXB2 then create table VIEW (using DdlUtils)
    2. Design mapping of queries to SQL statements (using SQLMaps or the like).
  9. unmarshalling DB result set
  10. Update ant tasks to build deployable quickstart (if necessary)
  11. Produce WSDL for service
  12. Use eclipse to produce UML class diagrams
  13. Produce UML component diagrams
  14. Document message format and include examples as produced by HTTPUnit
  15. Update document how to install
    1. quickstart
    2. 'proper' service

Deliverables

  1. Web Service Search WSDL.
  2. Java implementation of WSDL server and internal API.
  3. Documentation on WSDL and JavaDoc of internal API.

WP 9. Search Toolkit Glue: {Defer until later}

Here we will be taking the search toolkit and integrating it with two systems. Firstly integration will be performed with the tracking events that are stored in Bodington to expose the information as a Web Service. Secondly the search toolkit will be integrated into the remote store to expose the collected tracking information to clients.

Q: can we use ioMorph to interface the glue with the search API? ioMorph is discussed on the Trecx:Notes page.

Breakdown of Tasks

  1. Glue between bodington and query interface implementation
  2. Report (short) with section on general issues and section on Bodington specific issues.

Deliverables

  1. Bodington with the search toolkit integrated.
  2. Remote Store with the search toolkit integrated.
  3. integration report on how toolkit integration works.

WP 10. Reporting Application

This will be a demonstration of how a reporting application can use the searching Web Service to collect tracking events and present them in a more meaningful way. In this proof of concept we will allow users to search for tracking information and then return it to them in iCal / xHTML / CSV format that allows them to use standard tools for displaying this information.

Breakdown of Tasks

  1. write XML schema for reporting application configuration file
  2. use JAXB to generate classes to parse the reporting application configuration file
  3. code to 'marshall' queries and send to all tracking stores in network
  4. Mock up of Query screen (JSP) using above.
  5. Logic behind page to take user selections and forumlate queries to tracking store and e-learning applications, this page will also have a an option to select results format (ie, CVS or plain text)
  6. servlet fileter to reject messages not coming from registered tracking store (same as before?)
  7. classes to receive the result of the query - these are same JAXB classes as before as we are using same event schema, validate / dont validate dependent on configuration options
  8. reporting application logic to interleave results from tracking store and e-learning applications. Can use Java collections and sort on date field.
  9. transformation module to take results and display as string
  10. transformation module to take results and 'display' as CSV
  11. Produce ant tasks to build deployable quickstart
  12. Use eclipse to produce UML class diagrams
  13. Produce UML component diagrams
  14. Document query and response format and include examples as produced by HTTPUnit
  15. Document how to install
    1. quickstart
    2. 'proper' service

Deliverables

  1. Simple reporting application.
  2. Documentation on writing a reporting application.

WP 11. Publication / Implementors Documentation

Deliverables:

  1. Publishing of outputs from this project on Website.
  2. Report outlining how another tool would go about integrating our toolkit.

Once the development has concluded we will release the the software through our project website.

WP 12. Management

Deliverables:

  1. Final report

We will use an open management policy delivered through the open source dotProject management application.



Back to TReCX