Development Work Breakdown Structure

Our emphasis for the first phases of the project, while the UI team is working on design in parallel, is getting the underpinnings in place and maybe getting Stanford's Fall '06 goal delivered.

We currently have dependencies for more info from Stanford on their needs. Otherwise, we should be able to move forward on the understanding that plenty of iteration and re-thinking are in store.

The top-level goals which can lead to semi-parallel assigned tasks are:

• Views of enterprise data and implementations of those views.
  • Finalize CM API design, based on comments from the community. Currently, there are no comments. That makes this task easy!
  • Write Java interfaces for the CM API
  • Write a hibernate implementation for the CM API, and possibly some scripts to load the data from the enterprise
  • Design and write a provider-esque implementation of the CM API to demonstrate an example of a more service-oriented approach to enterprise integration. I can foresee some problems we'll run into:
    • If we decide to do event listeners, this could be difficult. JMS might provide some relief, but it could be difficult to add a JMS server to a clustered sakai. But I digress.
    • This could be time consuming to demonstrate and to test
  • Write a simple CM-browser GUI. This could be something as simple as a single page with a JSF tree view component and a table for the selected node's metadata. A GUI is usually a useful way to explore what's missing in an API, and it's also a useful "integration test"
• Ways to change the LMS data.
  • Write a service that keeps track of sakai-entity to cm-entity relationships (this would be very simple in hibernate... just a single table/object: a string id to string id map). Let's call it the LmsMappingService for now. This service should be capable of creating LMS entities as well as associating existing LMS entities with CM entities.
• Connecting the two. (C does depend on A + B, obviously, but it can also be started with fairly primitive versions of both.)
  • Write a legacy group provider implementation that can be used to associate different CM objects with a site. This item will almost certainly need its own work breakdown structure, since it will be a complex system. I'm thinking the main sub tasks might look like this:
    • Write a legacy group provider implementation that consults the LmsMappingService and returns memberships, etc based on CM memberships and enrollments.
    • Somewhere along the line, we need to add information about what provider is responsible for an individual's membership in an azg to the legacy membership interface (org.sakaiproject.service.legacy.authzGroup.Member). This interface currently tells us whether a member is provided, and that might be enough for our first iteration.