THE DESIGN OF A FLEXIBLY INTERWORKING DISTRIBUTED MESSAGE-BASED FRAMEWORK Bilhanan Silverajan, Ilkka Karvinen, Janne Mäkihonka, Jarmo Harju Department of Information Technology, Tampere University of Technology P.O. Box 553, FIN-33101, Tampere, Finland e-mail: {bilhanan | ik | mhonka | harju}@cs.tut.fi ABSTRACT development in which the need occurs to support emerging applications that require dynamic responses The DOORS (Distributed Object OpeRationS) to asynchronous distributed occurrences. framework attempts to address several issues in With the adoption of such new technologies, however, protocol development, interoperability and distributed one cannot ignore the issue of large amounts of legacy computing for client-server architectures in infrastructure that already exist, and their integration heterogenous networks and telecommunications or interworking with newer technologies with systems. minimum adverse effects. Apart from supporting TCP/IP and UDP/IP socket- Using Ad-Hoc methods such as wrappers to based communication, the DOORS framework offers encapsulate entire systems or applications, tends to be an additional level of interworking with many kinds complex, fragile, and error-prone, often introducing of distributed object models and distributed systems. instability into a previously stable legacy application. It also implements an extremely lightweight ORB Therefore such methods can become maintenance using dynamic interfaces running over IIOP which burdens themselves. conforms to the CORBA architecture. Interworking Thus any framework which attempts to address the with other architectures and frameworks is supported problem of interworking with legacy systems while via interrupt-driven, CORBA, or protocol-level providing enough functionality to develop new approaches. distributed event-based applications needs to fulfill Brief examples of these approaches, together with a the following criteria: description of streaming audio applications developed for use with this framework, are presented. • Implement new object interfaces that conform to a set of widely supported distributed object 1. INTRODUCTION specifications as much as possible Telecommunications networks and devices, as well as • Accomplish data translation and information the Internet are inherently comprised of extensively processing on potentially different levels for distributed network and software-based elements and several uses such as gateways or relays equipment. Owing to recent emerging trends of the • Provide connection protocol management on convergence of communications and computing, different levels architectures and infrastructures in the • Manage the application environment in a telecommunications domain have become lightweight manner. significantly dependent on advances in areas of distributed computing such as CORBA[1], mobile In this paper, we present a practical high-speed agents, object-oriented languages and reusable design framework in active development that fulfills these techniques such as design patterns for improving criteria, codenamed DOORS. The main purpose of quality and scalability. One exciting topic in the area DOORS is to overcome the abovementioned of distributed systems is event-based systems difficulties to flexibly support the implementation of 1 various types of distributed message-based systems Because all these library components are usually and services. DOORS applications can also compiled as separate runtime libraries, a developer noninvasively interwork with existing legacy can flexibly customize the size of his or her event- applications as well as applications and components based application very easily, with the bare minimum that use CORBA or some other distributed model. being an application-level task, a scheduler, an I/O The design of this framework has been heavily Handler and possibly one or more virtual devices for influenced by existing object paradigms and design inter-process communication, services which are all patterns, which enables it to successfully handle directly provided by the classes in the Base occurrences of discrete events asynchronously with Component library without the need for the other two great ease. Section 2 of this paper describes the libraries. Subsections 2.1, 2.2 and 2.3 describe these structure of this framework and its associated libraries in greater detail. libraries, while section 3 explores several interworking scenarios. Section 4 presents a short 2.1. Base Component Library description of test applications developed for use with The Base Component is subdivided into three this framework, while section 5 discusses some of the modules: Utilities, Core and Protocol Support. These design decisions made. interwork together by providing the following functionalities and services: 2. DOORS DISTRIBUTED FRAMEWORK The DOORS (Distributed Object OpeRationS) • Frames, buffers and cells for data storage framework attempts to address several issues in • Loggers protocol development, interoperability and distributed • Event-, Protocol- and timer management task computing for client-server architectures in classes heterogenous networks and telecommunications • Classes that implement Service Access Points systems. (SAPs) and Protocol Data Unit (PDU) encoding DOORS uses a pure message-based model and and decoding derives its C++ code-base from a protocol • Base classes for finite state machine implementation framework, OVOPS, that has been implementations successfully tested and employed to develop medium • Multiplexers to complex protocols widely used in • Base classes for messages telecommunications and the Internet [2]. • Bi-directional ports used by tasks for message The framework has been implemented as three passing flexibly interacting library-level components, which • Inter-task Scheduler are the Base, Protocol and Dynamic CORBA • Virtual device classes that provide object- components repectively. It is presently structured in oriented interfaces to system devices and other such a way as to allow multiple builds of different operating system services, such as sockets, pipes, platforms and compilers to proceed concurrently. file handlers and timers The current development platforms being used for • I/O Handler that manages the virtual devices. DOORS are Solaris and Linux, using Sun C++ as well as GNU C++ compilers. DOORS perceives any event-based application or DOORS reduces any event-based application or protocol as a set of interacting event- and protocol protocol into a set of interacting event- and protocol tasks which exchange messages through their ports. tasks and a round-robin scheduler which allocates Events in the system are represented as messages. execution turns to the tasks. An entire DOORS Ports conceptually form channels for asynchronous system, comprising its event- and protocol-tasks, message transfer via a protocol-based communication scheduling, I/O Handling and CORBA subsystem, is with other tasks. For endpoints that connect to an able to execute as a single user or kernel UNIX external system, virtual device classes implemented as process. wrappers for UNIX pipes, TCP/IP and UDP/IP The driving design principle which has been adhered sockets can also be utilised. to throughout the implementation of these library Tasks, as shown in a simplified form in Figure 1, components is to ensure that only a modular execute incoming messages based on a FIFO order, dependency is enforced among these components. requesting execution turns from a round-robin The Base Component Library provides all the scheduler. Execution turns are non-preemptive, and if services needed by the Protocol Component Library, there are no outstanding requests for task executions, and likewise, the Dynamic CORBA Component the scheduler instead blocks on the I/O Handler until Library is dependent on both the other two outside events monitored by the I/O Handler and the Component Libraries. 2 virtual devices it manages arrive. offered by the Dynamic CORBA Component Library Figure 2 illustrates the basic procedures involved with discussed in section 2.3. Also, because DOORS is message-based communication between two tasks source-code compatible with OVOPS, existing where, on obtaining an execution turn from the production-level protocols developed with OVOPS scheduler, Task A removes the first message from its such as TCAP, HTTP and TCP/IP can be used message queue and depending on its current state, natively as well. executes a sequence of operations that involve the All the classes used to build the protocols within this creation of a message for Task B. Within the same component library are supplied by DOORS. execution turn of Task A, this message is then Implementation of protocols with stateful behaviour transferred to the message queue of Task B via the are supported using the concept of tasks being either ports, which triggers Task B’s request for an Entity or Connection Objects. Each instance of an execution turn from the scheduler. Entity Object may be seen to represent one protocol (sub-)layer, and is responsible for communication with the upper and lower protocol layers within the stack. It also creates, manages and destroys tasks which are Connection Object instances, representing single peer-to-peer connections for that protocol. Figure 3 shows the implementation architecture of IIOP. The basic principle of creating Connection Objects by the Entity Object is supported by the Abstract Factory pattern [3], which inevitably has to be extended to encompass the multiplexing, connection-handling