Section 13.3. APPLIED ILITIES

13.3. APPLIED ILITIES

Our work has been driven by demonstrating these ideas in a pair of prototypical applications. DisDev [2] implements a distributed repository and illustrates the use of injectors to achieve reliability through replication. Vendoom implements a simulation of a distributed, competitive network management application. It uses injectors to achieve quality of service (such as real-time performance), manageability, and security [8]. We review the lessons learned in pursuing these ilities in our framework.

13.3.1. Reliability

Our primary experiments in supporting reliability have centered on injecting replication algorithms into DisDev, a document management application. Replication algorithms typically send copies of messages to replicants. That is, if operation f is invoked on x and y, (and f mutates the application state), all replicants need to be aware of this action. Our work suggests this is more easily supported if x and y are symbolic, rather than pointers into a replicant's memory space.

Other reliability injectors we have demonstrated include the retry injector, which repeats attempts that time out or otherwise fail, and the rebind injector, which seeks alternative servers under the recognized failure of one.

Transactions are a reliability mechanism that illustrates the limits of this approach. Transactions require application objects that can start and end transactions and rollback on failure. If the application objects have these interfaces, injectors can be used to coordinate their invocation. For example, transaction identity is a straightforward application of request annotations. Sadly, however, transactions cannot be transparently achieved by injection to objects that lack them.

13.3.2. Quality of Service

By quality of service, we include a variety of requirements for getting things done within time constraints. The real-time community recognizes two varieties of real-time systems, hard real-time and soft real-time. A correct hard real-time system must complete all tasks by their deadlines. Soft real-time systems seek to allocate resources to more important tasks. Hard real-time requires cooperation throughout the processing chain (for example, in the underlying network), since the promise of particular service can be abrogated in too many places. (Doug Schmidt's work on real-time CORBA ORBs [11] illustrates this point: commercial CORBA ORBs, built without constant real-time mindfulness, conceal FIFO queues and exhibit anti-real-time behavior.)

Soft real-time is amenable to several communication control tactics. These include using queue control to identify the most worthwhile thing to do next [8], calling the underlying system's quality of service primitives, using side-door mechanisms to efficiently transport large quantities of data, and choosing among multiple problem solving approaches. We have demonstrated the first of these tactics in Vendoom. All except the last are easily done with injectors. If the application supplies the alternative problem solving methods (either by replicating the problem solving sites, allowing load balancing, or providing genuinely different algorithms), the communication control mechanism can apply the most effective problem solvers. Injectors, as stateful objects, can determine the best message target using tactics such as learning from historical experience and consulting traffic-reporting agencies.

13.3.3. Manageability

We take a network control perspective on manageability, dividing manageability into five elements: performance measurement, accounting, failure analysis, intrusion detection, and configuration management. The first four are amenable to generating events in relevant circumstances and directing those events to the appropriate recipients. For example, in Vendoom we have used injectors to publish events to update graphic displays, report payment data, and debug the application. In general, to the extent that the semantics of interesting events are tied to communication acts, such as when a micro-payment is processed each time a service is called, or the trace of inter-component messages is sent to a system's debugger, the events can be realized through external communication controls. This technique is inadequate when the interesting actions happen completely within the application components. Examples of such internal activity include when payment is directly proportional to the number of records accessed by a database service, or debugging occurs wholly within a component.

We have also designed a configuration management injector that dynamically tests for incompatible versions and automatically updates stale configurations. Such management can be done only for clients and servers that provide the appropriate interfaces.

13.3.4. Security

Security, at least in a software sense, is primarily a combination of access control, intrusion detection, authentication, and encryption. Controlling the communication process allows us to encrypt communications, reliably send user authentication from client to server (and pass it along to dependent requests), and check the access rights of requests. All this is independent of the actual application code. (However, we may only be able to encrypt the message data, not its headers. Similarly, encrypting object references may confuse the marshaling code. In general, encryption is better done after marshaling.) Watching communications provides a locus for detecting intrusion events [5], although not, of course, specifying the actual algorithms for recognizing an intrusion. We have illustrated security in Vendoom with injectors that perform access control and, (by checking the user's Java ring), authentication.

Can such mechanisms yield security? Somewhat. Such mechanisms reflect common notions of security, but cannot prevent hazards such as subverting a system's personnel, tapping communication lines, brute-force cracking of encryption codes, or components that cheat. Magic has its limits.