This paper describes the Active Object pattern, which decouples method execution from method invocation in order to simplify synchronized access to an object that resides in its own thread of control. The Active Object pattern allows one or more independent threads of execution to interleave their access to data modeled as a single object. A broad class of producer/consumer and reader/writer applications are wellsuited to this model of concurrency. This pattern is commonly used in distributed systems requiring multi-threaded servers. In addition, client applications, such as windowing systems and network browsers, employ active objects to simplify concurrent, asynchronous network operations.

The ADAPTIVE Communication Environment (ACE) is an object-oriented toolkit that implements strategic and tactical design patterns to simplify the development of concurrent, event-driven communication software. ACE provides a rich set of reusable C++ wrappers, class categories, and frameworks that perform common communication software tasks across a range of operating system platforms. The communication software tasks provided by ACE include event demultiplexing, event handler dispatching, connection establishment, interprocess communication, shared memory management, message routing, dynamic (re)configuration of network services, multi-threading, and concurrency control. ACE is targeted for developers of high-performance concurrent network applications and services. The primary goal of ACE is to simplify the development of concurrent OO communication software that utilizes interprocess communication, event demultiplexing, explicit dynamic linking, and concurrency. In addition, ACE auto...

Many real-time application domains can benefit from flexible and open distributed architectures, such as those defined by the CORBA specification. CORBA is an architecture for distributed object computing being standardized by the OMG. Although CORBA is well-suited for conventional request/response applications, CORBA implementations are not yet suited for real-time applications due to the lack of key quality of service (QoS) features and performance optimizations. This paper makes three contributions to the design of realtime CORBA systems. First, the paper describes the design of TAO, which is our high-performance, real-time CORBAcompliant implementation that runs on a range of OS platforms with real-time features including VxWorks, Chorus, Solaris 2.x, and Windows NT. Second, it presents TAO’s realtime scheduling service that can provide QoS guarantees for deterministic real-time CORBA applications. Finally, the paper presents performance measurements that demonstrate the effects of priority inversion and non-determinism in conventional CORBA implementations and how these hazards are avoided in TAO. 1

Distributed object computing forms the basis for nextgeneration application middleware. At the heart of distributed object computing are Object Request Brokers (ORBs), which automate many tedious and error-prone distributed programming tasks. This article presents a case study of key design patterns needed to develop ORBs that can be dynamically configured and evolved for specific application requirements and system characteristics.

This paper describes the design and performance of an object-oriented communication framework being developed by the Health Imaging division of Eastman Kodak and the Electronic Radiology Laboratory at Washington University School of Medicine. The framework is designed to meet the demands of next-generation electronic medical imaging systems, which must transfer extremely large quantities of data efficiently and flexibly in a distributed environment. A novel aspect of this framework is its seamless integration of flexible high-level CORBA distributed object computing middleware with efficient low-level socket network programming mechanisms. In the paper, we outline the design goals and software architecture of our framework, describe how we resolved design challenges, and illustrate the performance of the framework over high-speed ATM networks. 1 Introduction The demand for distributed electronic medical imaging systems (EMISs) is pushed by technological advances and pulled by economic...

Factory, Builder, and Service Configurator) the ACE framework components facilitate the development of communication software that may be updated and extended without modifying, recompiling, relinking, or even restarting running systems [6]. 3.1.4 Self-contained Distributed Service Components ACE provides a standard library of distributed services that are packaged as self-contained components. Although these service components are not strictly part of the ACE framework, they play two important roles: Factoring out reusable distributed application building blocks: These service components provide reusable implementations of common distributed application tasks such as naming, event routing, logging, time synchronization, and network locking; Demonstrating common use-cases of ACE: These distributed services also demonstrate how ACE components (such as Reactors, Service Configurators, Acceptors and Connectors, Active Objects, and IPC wrappers) can be used effectively to develop flexi...

This paper describes the Half-Sync/Half-Async pattern, which integrates synchronous and asynchronous I/O models to support both programming simplicity and execution efficiency in complex concurrent software systems. In this pattern, higher-level tasks use a synchronous I/O model, which simplifies concurrent programming. In contrast, lower-level tasks use an asynchronous I/O model, which enhances execution efficiency. This pattern is widely used in operating systems such as UNIX, Mach, WindowsNT, and VMS, as well as other complex concurrent systems. 1 Intent The Half-Sync/Half-Async pattern decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent programming effort without degrading execution efficiency. 2 Motivation To illustrate the Half-Sync/Half-Async pattern, consider the software architecture of the BSD UNIX [1] networking subsystem shown in Figure 1. The BSD UNIX kernel coordinates I/O between asynchronous communication devices (such as network adapter...

Abstract not found

Developers of communication software face many challenges. Communication software contains both inherent complexities, such as fault detection and recovery, and accidental complexities, such as the continuous re-rediscovery and re-invention of key concepts and components. Meeting these challenges requires a thorough understanding of object-oriented application frameworks and patterns. This paper illustrates how we have applied frameworks and patterns for communication software to develop a high-performance Web server called JAWS. JAWS is an object-oriented framework that supports the configuration of various Web server strategies, such as a Thread Pool concurrency model with asynchronous I/O and LRU caching vs.. a Thread-per-Request concurrency model with synchronous I/O and LFU caching. Because JAWS is a framework, these strategies can be customized systematically and measured both independently and collaboratively to determine the best strategy profiles. Using these profiles, JAWS can statically and dynamically adapt its behavior to deploy the most effective strategies for a given software/hardware platform and workload. JAWS ’ adaptive software features make it a powerful application framework for constructing highperformance Web servers. 1

There is increasing demand to extend Object Request Broker (ORB) middleware to support distributed applications with stringent real-time requirements. However, lack of proper OS support can yield substantial inefficiency and unpredictability for ORB middleware. This paper provides two contributions to the study of OS support for real-time ORBs. First, we empirically compare and evaluate the suitability of real-time operating systems, VxWorks and LynxOS, and general-purpose operating systems with real-time extensions, Windows NT, Solaris, and Linux, for real-time ORB middleware. While holding the hardware and ORB constant, we vary the operating system and measure platform-specific variations, such as latency, jitter, operation throughput, and CPU processing overhead. Second, we describe key areas where these operating systems must improve to support predictable, efficient, and scalable ORBs. Our findings illustrate that general-purpose operating systems like Windows NT and Solaris are...