The following paper was originally published in the Proceedings of the Third USENIX Conference on Object-Oriented Technologies and Systems Portland, Oregon, June 1997 Using the Strategy Design Pattern to Compose Reliable Distributed Protocols Benoit Garbinato, Rachid Guerraoui Laboratoire de Systemes d'Exploitation Departement d'Informatique Ecole Polytechnique Federale de Lausanne, Suisse For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org Using the Strategy Design Pattern to Compose Reliable Distributed Protocols BenoÃõt Garbinato Rachid Guerraoui Laboratoire de SystemesÁ d'Exploitation Departement d'Informatique Ecole Polytechnique Fed erale de Lausanne, Suisse e-mail: [email protected]¯.ch Abstract tems respectively. In [7], we also show how BAST allows distributed applications to be made fault- Reliable distributed systems involve many complex tolerant, by application programmers who are not protocols. In this context, protocol composition is necessarily skilled in reliability issues. a central concept, because it allows the reuse of robust protocol implementations. In this paper, we describe how the Strategy pattern has been recur- The BAST Framework sively used to support protocol composition in the Building reliable distributed systems is a chal- BAST framework. We also discuss design alterna- lenging task, as one has to deal with many com- tives that have been applied in other existing frame- plex issues, e.g., reliable communications, failure works. detections2, distributed consensus,replication man- agement, transactions management, etc. Each of these issues corresponds to some distributed proto- 1 Introduction col and there are many. In such a protocol ªjun- gleº, programmers have to choose the right proto- This paper presents how the Strategy pattern has col for the right need. Besides, when more than been used to build BAST1, an extensible object- one protocol is necessary, the problem of their in- oriented framework for programming reliable dis- teractions arises, which further complicates pro- tributed systems. Protocol composition plays a cen- grammers' task. The BAST framework aims at tral role in BAST and relies on the notion of protocol structuring reliable distributed systems by allow- class. In this paper, we focus on the recursive use of ing complex distributed protocols to be composed the Strategy pattern to overcome the limitations of in a ¯exible manner. For example, by adequately inheritance, when trying to ¯exibly compose proto- composing reliable multicast protocols with trans- cols. In a companion paper [6], we have presented actional protocols, BAST makes it possible to trans- how generic agreement protocol classes can be cus- parently support transactions on groups of repli- tomized to solve atomic commitment [10] and total cated objects. It relies heavily on the Strategy pat- order multicast [20], which are central problems tern, which is recursively used to get around the in transactional systems and to group-oriented sys- limitations of inheritance as far as protocol compo- Partially supported by OFES under contract num- sition goes. Our ®rst prototype is written in Small- ber 95.0830, as part of the ESPRIT BROADCAST-WG (num- talk [8] and is fully operational. It is currently being ber 22455) 1We named BAST after the cat-goddess of the Egyptian 2A failure detector is a high-level abstraction that hides the mythology: cats are known to survive several ªcrashesº. timeouts commonly used in distributed systems [2]. Protobject abstract superclass unreliable message passing unreliable UMPObject message passing best-effort BMPObject message passing reliable reliable message passing RMPObject message passing fifo FMPObject message passing reliable RMCObject reliable multicast multicast failure detection FDTObject failure detection uniform consensus CSSObject consensus dynamic dynamic terminating multicast DTMObject terminating multicast (a) protocol dependencies (b) protocol class hierarchy Figure 1: Protocols and Protocol Classes in BAST used for teaching reliable distributed systems and marizes the contribution of this paper, as well as for prototyping new fault-tolerant distributed pro- some future developments in the BAST framework. tocols. Adding more and more protocol classes will help us to further test our approach. BAST has also been recently ported to the Java [9] programming 2 Protocol Objects environment. Performance is not yet good enough for practical application development, but we are The BAST framework was designed to help pro- currently working on performance evaluations and grammers in building reliable distributed systems, code optimization [7]. and is based on protocols as basic structuring com- ponents. With BAST, a distributed system is com- Overview of the Paper posed of protocol objects that have the ability to remotely designate each other and to participate in Section 2 introduces the concept of protocol object various protocols. A distributed protocol is a set as de®ned in BAST, and how it helps to structure dis- of interactions between protocol objects that aim at tributed systems and to deal with failures. Section 3 solvingdistributedproblem .Weusea Object discusses why inheritance alone is limited in sup- to name a protocol object capable of participating porting ¯exible protocol composition and presents in protocol , and we say that Object is its how we applied the Strategy pattern to break these protocol class. Each Object provides a set of limitations. We also show how the Strategy pattern operations that implement interface protocol , i.e., is transparently used in a recursive manner, and these operations act as entry points to the protocol. we present what steps have to be performed in or- Abstract class Protobject is the root of the pro- der to extend BAST through protocol composition. tocol class hierarchy. Section 4 discusses various design alternatives, and With such broad de®nitions, any interaction be- compares our approach with other research works tween objects located on distinct network nodes is described in the literature. Finally, Section 5 sum- a distributed protocol, even a mere point-to-point communication. For example, class RMPObject 3 Strategy Pattern in BAST implements a reliable point-to-point communica- tion protocol and provides operations rSend() Composing Protocols and rDeliver() that enable to reliable sending With protocol objects, managing protocol depen- and receiving, respectively, of any object3; callback dencies is not only possible during the design and operation rDeliver() is rede®nable and is said implementation phases (between protocol classes), to be triggered by the protocol. Note that such a ho- but also at runtime (between protocol objects). This mogeneous view of what distributed protocols are is partly due to the fact that protocol objects can ex- does not contradict the fact that some protocols are ecute more than one protocol at a time. In this more basic than others. Communication protocols, context, trying to compose protocols comes down for example, are fundamental to almost any other to answering the question ªHow are protocol layers distributed protocol. assembled and how do they cooperate?º. Figure 2 (a) presents a runtime snapshot of aCSSObject, some protocol object of class CSSObject that implements an algorithm for solving the distributed consensus problem. The Dealing with Failures. Because failures are part consensus problem is de®ned on some set of dis- of the real world, there is the need for reliable dis- tributed objects as follows: all correct objects in tributed protocols, e.g., consensus, atomic commit- propose an initial value and must reach agree- ment, total order multicast. Reliable distributed ment on one of the proposed values (the deci- protocols are challenging to implement because sion) [3]. Class CSSObject de®nes operations they imply complex relationships with other un- propose() and decide(), which mark the be- derlying protocols. For example, both the atomic ginning and the termination of the protocol re- commitment and the total order multicast rely on spectively [2]. Besides consensus, protocol ob- consensus, while the latter is itself based on failure ject aCSSObject is also capable of executing detections, on reliable point-to-point communica- any protocol inherited by its class, e.g., reliable tions, and on reliable multicasts. In turn, reliable point-to-point communications and reliable multi- multicasts can be built on top of reliable point-to- casts, as well as failure detections. In Figure 2 (a), point communications. Figure 1 (a) presents an aCSSObject is concurrently managing ®ve dif- overview of some distributed protocol dependen- ferent protocol stacks for the application layer, and cies. issuing low-level calls to the transport layer. Focus- ing on the consensus stack, protocol composition In BAST, protocol classes are organized into a means here to assemble various layers, each being single inheritance hierarchy which follows protocol necessary to execute the consensus protocol, into dependencies, as pictured in Figure 1 (b). Each the protocol stack pictured in Figure 2 (b). The protocol class implements only one protocol, but assembling occurs at runtime and creates a new instances of some Object class can execute any stack each time the application invokes operation protocol inherited from Object's superclasses. propose(). Protocol objects are able to