The current focus of the Mutable Services project is to build a first-level service distribution prototype targeting Sun Microsystem's Java Platform 2, Enterprise Edition (J2EE) applications and container environments (web servers and application servers). We are specifically focusing on the open-source Tomcat (www.apache.org) and JBoss (www.jboss.org) efforts.
The service distribution architecture supports distributed deployment of a J2EE application on an overlay network of container nodes in a fashion such that the application can be dynamically reconfigured on demand. Towards this end, the architecture extends both the J2EE application specification and the functionality embodied in the container environments. The J2EE application specification is extended to include control components, which allow application-specific monitoring of service behavior, detect any violations from the norm (indicative of unfriendly system conditions), and trigger application reconfiguration. The container environments need to be extended to support distributed and replicated deployment of application components (e.g., to support distributed transactions and replica consistency) and support naming and resource management at the granularity of per-client-group access paths.
Our current research is focused on the following areas:
Tools for Application
Deployment and Profiling: Distributed deployment of a J2EE
application requires bundling the application components and deployment
descriptors for each of the participating containers, coordinating naming of
external resources, and scheduling the deployment activities. To automate this
procedure, we are building a tool which parses the deployment descriptors of an
aggregate (non-distributed) application, and based on external input (either
from a user or another program) produces the appropriate bundled archives (the
.war and .ear files), resolves global names, and orchestrates the deployment
across multiple container environments.
Work is also underway to build a profiling tool, which monitors application activities (e.g., number of method calls against a component, sizes of messages) to build a on-the-fly model of normal application usage. The longer term goal is to use this model to define appropriate control components, which detect run-time violations from the norm to trigger service reconfiguration.
We have also been investigating suitable generic design rules and program optimizations to permit component-based applications to execute efficiently in wide-area settings. A forthcoming ICDCS'03 paper reports on our experience with distributing the Java Petstore application.
Service Deployment and
Reconfiguration Algorithms: These algorithms take the application
usage model and network conditions as input and either (i) repartition clients
to active paths, and/or (ii) create new paths, relocate existing paths, or
modify resources allocated for an existing path so as to optimize either a
global or per-client-group metric. Complicating these algorithms is the fact
that they need to consider multiple ways of composing the application from the
given components and must respect node and link capacity constraints.
We currently formulate the underlying mapping problem in terms of finding a type-compatible graph connecting the interface requested by a client to that provided by the application core, which can be mapped efficiently to network resources. For the special case of applications modeled as a chain of components, we have constructed an optimal polynomial-time based on dynamic programming. Additional details can be found in a March 2001 technical report. For more general application graphs and mapping constraints, we have been investigating AI-planning based approaches. Additional details of the algorithms and their evaluation can be found in our IPDPS'03 paper.
Infrastructures: These infrastructures inform a client about the IP
address of the node hosting a service's frontier component(s). Note that because a deployment can involve multiple paths, a
client needs to receive information only about its own path and not be able to
learn anything about other paths.
We are currently pursuing two alternatives for constructing such infrastructures, both based on cryptographic protocols. The first alternative assumes name servers capable of authenticating clients, while the second scheme works with name servers providing client-oblivious encrypted information, which can only be decrypted by a server-specified subset of clients.