Active Names: Programmable Location and Transport of Wide-Area Resources

One-line summary: Late binding of names by executing service-specific nameservers in a controlled environment. Addresses some of the thorny naming problems associated with replication/mirroring, transformation, alternates, customized/cookie-ized pages, etc.

Overview/Main Points

• Define a naming scheme based on a namespace concatenated with a name. Each namespace is controlled by a NamespaceProgram that resolves names there via an Eval() method.
• The Eval method also takes as arguments an array of afterMethods to be called after the original resolution completes, and a DataStream representing the result/output state of an evaluation. This allows a pipeline/CPS-like style of composing name evaluations (think distillation pipeline).
• This enables multi-way RPC without multiple roundtrips: client calls NS1 which hands off to NS2,...,NSn via the afterMethods (any intermediate afterMethod can push more afterMethods).
• Security:
  • Goal: avoid having the one-thread-per-resolution NamespaceProgram consume too many resources. Approach: a Java thread metascheduler, but no way to monitor CPU/mem usage.
  • Goal: avoid having unrelated NP's stomp on each other. Approach: run each in a separate meta-VM.
• Implementation: Java class hierarchy; a VM (on top of JVM) in which AN resolvers (NamespacePrograms) run. ANVM uses Wallach and Felten's stack inspection and secure class loader.

Relevance

Flaws

• Besides late binding, a main feature is separation of "canonical names" from "parameters", in the sense that cookie-ized pages or transformed objects might require. This is fine, but important to realize that these problems are solved by fixing the naming scheme in general---not necessarily by making names active.
• Security is treated as a first-order concern, but failure semantics of the multi-way RPC/chaining are not.
• Performance is a concern for high workloads; maybe less so if resolutions are cached (see below), rare, or expected to be done near client with redirects going to faraway servers to do the actual work. Armando sez: How about a hybrid active/passive scheme, where name resolution can be cached as an optimization. The name resolver API could be extended to express "consistency semantics" for resolved names, or one of the other expiration-based consistency schemes could be used. This would avoid the performance hit and still allow AN's to be perfectly adequate for things like replica selection. (Yes, you could build this starting from AN as is, but worth asking whether the abstractions are worth providing as a first class mechanism.)