Introduction

The Process

1. Before March 8: provide us with a 2 page proposal describing the following items:
   • Objective of the project: 1 or 2 sentences.
   • Scope/Requirements: what the proposed project will do.
   • Approach: describe generally how you will go about doing the project, including any technical problems you can foresee.
   • Resources: the resources you expect to need to complete the project: including platform, any middleware, etc.
   Note that you will probably need to iterate with us about the scope of your project, so we encourage you not to wait to the last moment.
2. March 15: be prepared to give a 10 minute class presentation describing your proposed project.
3. April 5: be prepared to give a 30 minute design review of your project discussing requirements, design (including architecture), and implementation status. Note that we expect that this will spill over into the week of April 12, but do not assume you will have an extra week to prepare.
4. April 19, 26: be prepared to give short status reports about your project
5. May 3 (Final regular class): be prepared to give a demo (about 15 minutes) of your project.
6. May 8: turn in a final report about your project. This report should include at least the following.
   • The software in electronic form.
   • A description of the requirements and the features that were proposed for the project.
   • A user manual.
   • A document describing the design and internal architecture in sufficient detail that we can read it and then read and understand the code.

Time Commitment

Collaboration Policy

General Project Topics

• Run-time reconfiguration of component-based systems
  (aka CDS, which stands for Configurable Distributed Systems)
• Preventing and repairing hacker damaging to software systems
  (aka Intrusion Tolerance or Computer Immunology)
• Event-based Internet-scale computation
  (Loosely related to Siena)
• Mobility and mobile agents
  (aka mobility)

Possible Specific Projects

1. Run-time reconfiguration
   • Reconfiguration Scripting:
     We would like to be able to do complex system reconfigurations using a series of primitive actions on a running system. So we need to define some kind of standard reconfiguration interface (we call it the CSI) that is embedded into some reasonable scripting language. Then we need to be able to compile some kind of declarative specification of a desired configuration into a script to carry out the necessary steps. Note that this will also require some kind of representation for the architecture of the currently running system to serve as the starting point for figuring out what has to change.

   • Checkpoint/Restart:
     We need a working implementation of the middleware for reconfiguring a software system on-the-fly. In particular, we need the mechanisms for checkpointing parts of a system, replacing components, and then restarting. Ideally, there would be some cooperation between this project and the one above.

2. Siena-related projects
   • Killer applications for event-based computing:
     We believe that event-based computing will be important in the Internet in the future, but we are still looking for that ``killer application'' for events.

   • Persistence for Siena:
     Siena event clients cannot currently disconnect, later return, and expect to get events generated in their absence. In consultation with Antonio, implement a mechanism for adding some reasonable form of persistence to Siena.

   • Simulation:
     It is difficult to measure, and hence improve, the efficiency of the algorithms used within Siena. Antonio has established a simulation framework, but it needs improvement or replacement.

3. Intrusion tolerance/Computer Immunology/Security
   • Security DSD:
     Currently, there does not seem to exist any way to describe the security properties of component based systems in such a way as to allow them to be composed while maintaining or achieving some set of security properties. The DSD is our notation for describing the structure of component based systems (see http://www.cs.colorado.edu/~serl/cm/dock.html). In our case, we use it for deploying software systems, but we need something like the DSD but including composable security annotations that we can use to reconfigure a system to achieve specified security related capabilities.

   • Information protection:
     We are interested in new approaches to protecting and repairing information.

4. Mobility
   • Killer applications for mobility

   Misc. Topics

   • Internet-scale X:
     We often have referred to Siena as addressing the problem of Internet-scale event notification. We would be interested in other kinds of Internet-scale middleware.
   • Alternatives to Mobile Agents:
     The notion of mobile agents has become an important topic in distributed computing. Are there other interesting computational models that might alleviate some of the problems of mobile agents?
   • Plugin-based Architectures:
     The plugin model is rapidly becoming a ubiquitous approach for constructing extensible web-based and distributed software systems. Is this just another form of mobility? What is a killer app for plugins?
   • Off-line Web Applications:
     Many applications provide a Web-based front end. Unfortunately, it is impossible to operate these applications off-line (i.e., when disconnected from the net). Design and implement a mechanism, probably using Java, that allows applications to download some part of their front-end into a mobile machine, operate and store forms (and other) information, and then upload it at next connection. For an analog, you might look at the many mail readers can connect, read your mail, allow you to answer it off-line, and then send the answers when next connected. In effect, we want to extend this kind of capability to other applications.