Meddling with Middleware
Date Last Changed: March 1, 2000 2:00 PM
As we indicated at the beginning of the semester, you will
be required to choose, describe, implement, demonstrate,
and document a class project
involving some aspects of middleware.
This means the project either does
something interesting using one or more middleware sub-systems,
or it builds a interesting kind of middleware sub-system.
There is a multi-step process you must follow
in order to properly choose, implement, and document
- Before March 8: provide us with a 2 page proposal
describing the following items:
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.
- 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.
- March 15: be prepared to give a 10 minute class presentation
describing your proposed project.
- 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.
- April 19, 26: be prepared to give short status reports about your
- May 3 (Final regular class): be prepared to give a demo
(about 15 minutes) of your project.
- 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.
We estimate that you should expect to spend about 80 hours
on all phases of the project.
We will allow no more than two people to collaborate on any one project,
but we will expect substantially more out of such 2 person projects.
General Project Topics
We are open to a wide variety of projects.
We do have certain biases based on the research
directions we are currently pursuing:
- 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
Possible Specific Projects
The following list is derived from our interests, plus
a few other ideas. They all need to be made specific.
Alternatively, they might give you an idea for some other, related
- 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.
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.
- 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.
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.
- 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
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
- Killer applications for mobility
- 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.