Using Design Patterns to Develop Reusable Object-Oriented Communication Software

experiences Douglas C. Schmidt Using Design Object Technology Patterns to Develop Reusable Object-Oriented Communication Software Despite dramatic increases in network and host per- Design patterns [7] are a promising technique for formance, it remains difficult to design, implement, achieving widespread reuse of software architectures. and reuse communication software for complex dis- Design patterns capture the static and dynamic struc- tributed systems. Examples of these systems include tures and collaborations of components in successful global personal communication systems, network man- solutions to problems that arise when building soft- agement platforms, enterprise medical imaging sys- ware in domains like business data processing, tems, and real-time market data monitoring and telecommunications, graphical user interfaces, data- analysis systems. In addition, it is often hard to directly bases, and distributed communication software. Pat- reuse existing algorithms, detailed designs, interfaces, terns aid the development of reusable components or implementations in these systems due to the growing and frameworks by expressing the structure and col- heterogeneity of hardware/software architectures and laboration of participants in a software architecture the increasing diversity of operating system platforms. at a level higher than source code or object-oriented COMMUNICATIONS OF THE ACM October 1995/Vol. 38, No. 10 65 design models that focus on individual objects and user interface events generated by Motif. These events classes. Thus, patterns facilitate reuse of software arrive on multiple I/O handles that identify resources architecture, even when other forms of reuse are (such as network connections) managed by an oper- infeasible (e.g., due to fundamental differences in ating system. Input events from peers may arrive operating system features [16]). simultaneously on multiple handles. Therefore, sin- This article describes how design patterns are gle-threaded software must not block indefinitely being applied on a number of large-scale commercial reading from any individual I/O handle. Blocking can distributed systems. Patterns have been used on these significantly delay the response time for handling projects to enable widespread reuse of communica- events from peers associated with other handles. tion software architectures, developer expertise, and object-oriented framework components. These sys- ne way to develop this type of tems include the Motorola Iridium global personal event-driven software is to use communications system [13], a family of network multi-threading. In this monitoring applications for Ericsson telecommunica- approach, a separate thread is tion switches [16], and a system for transporting mul- spawned for every connected timegabyte medical images over high-speed ATM peer. Each thread blocks on a networks [1] being developed at Washington Univer- read system call. A thread sity School of Medicine in conjunction with Kodak. unblocks when it receives an This article also presents ways to avoid common traps event from its associated peer. At this point, the event and pitfalls of applying design patterns in large-scale is processed within the thread. The thread then O read software development processes. reblocks, awaiting subsequent input from . There are several drawbacks to using multi-thread- Example Design Pattern: The Reactor ing for handling events in communication software: The Reactor pattern was identified while developing reusable event-driven communication software at • Threading may require complex concurrency con- Ericsson, Motorola, and Kodak. Portions of the mate- trol schemes. rial appearing in this article were culled from docu- • Threading may lead to poor performance due to mentation used on these projects. context switching, synchronization, and data Design patterns have been described using several movement. formats [3, 5, 7]. The format used in this article is • Threading may not be available on all operating based on the work of Gamma et al. [7]; it contains the system (OS) platforms. following parts: Often, a more convenient and portable way to devel- • The intent of the pattern op event-driven servers is to use the Reactor pattern. The • The design forces that motivate the pattern Reactor pattern manages a single-threaded event loop • The solution to these forces that performs event demultiplexing and event handler • The structure and roles of classes in the solution dispatching in response to events from multiple • The responsibilities and collaborations among sources. The Reactor pattern combines the simplicity classes and efficiency of single-threaded event loops with the • Implementation guidance extensibility offered by object-oriented programming. • Example source code1 • References to related patterns Applicability Use the Reactor pattern when: Intent The Reactor pattern dispatches handlers automatically • One or more events may arrive concurrently from when events occur from multiple sources. This pattern multiple sources, and blocking or continuously simplifies event-driven applications by decoupling event polling for events on any individual source of demultiplexing and event handler dispatching from events is inefficient; application services performed in response to events. • Each individual event handler possesses the following characteristics: Motivation — it exchanges fixed-sized or bounded-sized mes- Communication software must respond to events gen- sages with its peers without requiring blocking I/O; erated from multiple sources. For example, network — it processes each message it receives within a management applications for monitoring and con- relatively short period of time; trolling space vehicles in global personal communica- • Using multi-threading to implement event demul- tion systems may receive traps sent by HP OpenView tiplexing is either: agents, telemetry data sent via CORBA requests, and — infeasible due to lack of multi-threading support on an OS platform; 1 Due to space limitations, the sample code has been omitted from this arti- — undesirable due to poor performance on uni- cle. See [14] for a complete example of the Reactor pattern. processors or due to the need for overly complex 66 October 1995/Vol. 38, No. 10 COMMUNICATIONS OF THE ACM experiences concurrency control schemes; systems, and transaction managers) communicate — redundant due to the use of multi-threading at with the Reactor via Handles. higher levels of an application’s architecture. • Developers subclass Event Handlers to implement application-specific event processing. When Structure an Event Handlers subclass object is registered The structure of the Reactor pattern is illustrated in the with the Reactor, the application indicates the Booch [2] class diagram shown in Figure 1. In Booch type of event(s) (e.g., input event, output event, notation dashed clouds indicate classes, an inscribed signal event) this Event Handlers wants the Reactor “A’’ indicates an abstract class, directed edges indicate to notify it about. Object Technology inheritance relationships between classes, and an undi- • To bind the Reactor with Handles, a subclass rected edge with a small bullet at one end indicates a of Event Handlers must override the composition relation between two classes. get_handle method. Hence, when an Event Handlers subclass object is registered with the Participants Reactor, the object’s Handle is obtained by The participants in the Reactor pattern include the invoking the Event Handler::get_handle following: method. The Reactor then combines this Han- dle with other registered Event Handlers and • Handles, which identify resources (such as net- waits for events to occur on the Handles. work connections, open files, and synchronization • The Reactor triggers Event Handlers meth- objects) that are managed by an operating system. ods in response to events on the Handlers it • Reactor, which defines an interface for registering, monitors. When events occur, the Reactor uses removing, and dispatching Event Handler the Handles activated by the events as keys to objects. An implementation of the Reactor locate and dispatch the appropriate Event Han- interface provides a set of application-independent dlers methods. This collaboration is structured event demultiplexing and dispatching mecha- using the method callbacks depicted in the object- nisms. These mechanisms dispatch application-spe- interaction diagram shown in Figure 2. cific Event Handlers in response to events • The handle_event method is called by the Reac- occurring on one or more Handles. tor to perform application-specific functionality in • Event Handler, which specifies an interface used response to an event. The type of the event that by the Reactor to dispatch callback methods occurred is passed as a parameter to the method. defined by objects that are pre-registered to handle certain types of events (such as input events, Consequences output events, and signals). The Reactor pattern has the following benefits: • Concrete Event Handler, which implements the customized callback method(s) that process events • It improves the modularity, reusability, and config- in an application-specific manner. urability of event-driven application software by decoupling application-independent mechanisms Collaborations Among Participants from application-specific processing policies. • Sources of events (such as network adaptors, file • It improves application portability by allowing its select (handles)

Load more