Check out the new USENIX Web site. next up previous
Next: Inadequacy of Inheritance Alone. Up: Strategy Pattern in BAST Previous: Strategy Pattern in BAST

Composing Protocols


With protocol objects, managing protocol dependencies is not only possible during the design and implementation phases (between protocol classes), but also at runtime (between protocol objects). This is partly due to the fact that protocol objects can execute more than one protocol at a time. In this context, trying to compose protocols comes down to answering the question ``How are protocol layers assembled and how do they cooperate?''.

Figure 2 (a) presents a runtime snapshot of aCSSObject, some protocol object of class CSSObject which implements an algorithm for solving the distributed consensus problem. The consensus problem is defined on some set tex2html_wrap_inline795 of distributed objects as follows: all correct objects in tex2html_wrap_inline795 propose an initial value and must reach agreement on one of the proposed values (the decision) [3]. Class CSSObject defines operations propose() and decide(), which mark the beginning and the termination of the protocol respectively [2]. Besides consensus, protocol object aCSSObject is also capable of executing any protocol inherited by its class, e.g., reliable point-to-point communications and reliable multicasts, as well as failure detections. In Figure 2 (a), aCSSObject is concurrently managing five different protocol stacks for the application layer, and issuing low-level calls to the transport layer. Focusing on the consensus stack, protocol composition means here to assemble various layers, each being necessary to execute the consensus protocol, into the protocol stack pictured in Figure 2 (b). The assembling occurs at runtime and creates a new stack each time the application invokes operation propose().

Figure 2: Protocol layers and protocol objects

Wed May 14 17:28:46 MET DST 1997