Applying a Pattern Language to Develop Application-level Gateways Douglas C. Schmidt [email protected] http://www.ece.uci.edu/schmidt/ Department of Electrical & Computer Science University of California, Irvine 92607 This paper appeared as a chapter in the book Design Pat- munication software solutions from the details of particular terns in Communications, (Linda Rising, ed.), Cambridge Uni- implementations. Even when software is written using well- versity Press, 2000. An abridged version appeared in the jour- structured object-oriented (OO) frameworks and components, nal Theory and Practice of Object Systems, special issue on it can be hard to identify key roles and relationships. More- Patterns and Pattern Languages, Wiley & Sons, Vol. 2, No. 1, over, operating system (OS) platform features, such as the ab- December 1996.. sence or presence of multi-threading, or application require- ments, such as best-effort vs. fault tolerance error handling, are often different. These differences can mask the underly- Abstract ing architectural commonality among software solutions for Developers of communication applications must address re- different applications in the same domain. curring design challenges related to efficiency, extensibility, Capturing the core commonality of successful communica- and robustness. These challenges are often independent of tion software is important for the following reasons: application-specific requirements. Successful developers re- 1. It preserves important design information for program- solve these challenges by applying appropriate patterns and mers who enhance and maintain existing software. Often, this pattern languages. Traditionally, however, these patterns have information only resides in the heads of the original develop- been locked in the heads of expert developers or buried deep ers. If this design information is not documented explicitly, within complex system source code. The primary contribution therefore, it can be lost over time, which increases software of this paper is to describe a pattern language that underlies entropy and decreases software maintainability and quality. object-oriented communication software. In addition to de- scribing each pattern in this language, the paper illustrates 2. It helps guide the design choices of developers who are how knowledge of the relationships and trade-offs among the building new communication systems. By documenting com- patterns helps guide the construction of reusable communica- mon traps and pitfalls in their domain, patterns can help de- tion frameworks and applications. velopers select suitable architectures, protocols, and platform features without wasting time and effort (re)implementing in- efficient or error-prone solutions. 1 Introduction The goal of this paper is to demonstrate by example an Communication software is the set of services and protocols effective way to capture and convey the essence of success- that makes possible modern distributed systems and applica- ful communication software by describing a pattern language tions, such as web services, distributed objects, collaborative used to build application-level gateways, which route mes- applications, and e-commerce systems [1]. Building, main- sages between peers distributed throughout a communication taining, and enhancing high-quality communication software system. Patterns represent successful solutions to problems is hard, however. Developers must have a deep understand- that arise when building software [2]. When related patterns ing of many complex issues, such as service initialization and are woven together, they form a language that helps to distribution, concurrency control, flow control, error handing, event loop integration, and fault tolerance. Successful com- Define a vocabulary for talking about software develop- munication applications created by experienced software de- ment problems; and velopers must embody effective solutions to these issues. Provide a process for the orderly resolution of these prob- It is non-trivial to separate the essence of successful com- lems. 1 PEERS 2 An OO Software Architecture for PEERS 2: recv_msg() Application-level Gateways 3: route_msg() A gateway is a mediator [2] that decouples cooperating peers 1: send_msg() 4: send_msg() throughout a network and allows them to interact without hav- ing direct dependencies on each other. As shown in Figure 1, GATEWAY messages routed through the gateway contain payloads encap- sulated in routing messages. Figure 2 illustrates the structure, associations, and internal and external dynamics among ob- Figure 1: The Structure and Dynamics of Peers and an Application-level Gateway Consumer Hash Supplier Handler Map Routing Manager Table Handler Message SOCK Queue SOCK Stream Stream Studying and applying patterns and pattern languages helps Reactor developers enhance the quality of their solutions by ad- Consumer dressing fundamental challenges in communication software Supplier Handler Handler Connector Acceptor Message development. These challenges include communication of SOCK Queue SOCK Hash Stream SOCK architectural knowledge among developers; accommodating Stream Map SOCK Connector Manager new design paradigms or architectural styles; resolving non- Acceptor functional forces, such as reusability, portability, and exten- INCOMING OUTGOING sibility; and avoiding development traps and pitfalls that are CONNECTION GATEWAY MESSAGES MESSAGES usually learned only by costly trial and error [3]. REQUEST CONNECTION REQUEST This paper presents the OO architecture and design of an application-level gateway in terms of the pattern language used to guide the construction of reusable and gateway- specific frameworks and components. Application-level gate- Figure 2: The OO gateway Software Architecture ways have stringent requirements for reliability, performance, and extensibility. They are excellent exemplars, therefore, to jects within a software architecture for application-level gate- present the structure, participants, and consequences of key ways. This architecture is based on extensive experience de- patterns that appear in most communication software. veloping gateways for various research and production com- munication systems. After building many gateway applica- The pattern language described in this paper was discov- tions it became clear that their software architectures were ered while building a wide range of communication systems, largely independent of the protocols used to route messages including on-line transaction processing systems, telecommu- to peers. This realization enabled the reuse of components de- nication switch management systems [4], electronic medical picted in Figure 2 for thousands of other communication soft- imaging systems [5], parallel communication subsystems [6], ware projects [1]. The ability to reuse these components so avionics mission computers [7], and real-time CORBA object systematically stems from two factors: request brokers (ORBs) [8]. Although the specific application requirements in these systems were different, the communica- 1. Understanding the actions and interactions of key pat- tion software design challenges were similar. This pattern lan- terns within the domain of communication software. Patterns guage therefore embodies design expertise that can be reused capture the structure and dynamics of participants in a soft- broadly in the domain of communication software, well be- ware architecture at a higher level than source code and OO yond the gateway example described in this paper. design models that focus on individual objects and classes. Some of the communication software patterns described in this The remainder of this paper is organized as follows: Sec- paper have been documented individually [1]. Although indi- tion 1 outlines an OO software architecture for application- vidual pattern descriptions capture valuable design expertise, level gateways; Section 3 examines the patterns in the pat- complex communication software systems embody scores of tern language that forms the basis for reusable communica- patterns. Understanding the relationships among these pat- tion software, using application-level gateways as an example; terns is essential to document, motivate, and resolve difficult Section 4 compares these patterns with other patterns in the challenges that arise when building communication software. literature; and Section 5 presents concluding remarks. Therefore, Section 3 describes the interactions and relation- 2 ships among these patterns in terms of a pattern language for stimuli in an event-driven application through a single demul- communication software. The patterns in this language work tiplexing point. This design permits single-threaded applica- together to solve complex problems within the domain of com- tions to wait on event handles, demultiplex events, and dis- munication software. patch event handlers efficiently. Events indicate that some- thing significant has occurred, e.g., the arrival of a new con- 2. Developing an OO framework that implements these nection or work request. The main source of events in the patterns. Recognizing the patterns that commonly occur in gateway are (1) connection events that indicate requests to es- many communication software systems helped shape the de- tablish connections and (2) data events that indicate routing velopment of reusable framework components. The gateway messages encapsulating various payloads, such as commands, systems this paper is based upon were implemented