This chapter describes the paradigm shift that occurs when transitioning from stand-alone application architectures to networked application architectures. This shift yields new challenges in two categories: those in the problem space that are oriented to software architecture and design and those in the solution space that are related to software tools and techniques used to implement networked applications. This chapter first presents a domain analysis of design dimensions affecting the former category, and the middleware that is motivated by and applied to the latter category. The chapter then introduces the ACE toolkit and the example networked application that's used to illustrate the solutions throughout this book.
0.1 Challenges of Networked Applications
Most software developers are familiar with stand-alone application architectures, in which a single computer contains all the software components related to the graphical user interface (GUI), application service processing, and persistent data resources. For example, the stand-alone application architecture illustrated in Figure 0.1 consolidates the GUI, service processing, and persistent data resources within a single computer, with all peripherals attached directly. The flow of control in a stand-alone application resides solely on the computer where execution begins.
Figure 0.1: A Stand-alone Application Architecture
In contrast, networked application architectures divide the application system into services that can be shared and reused by multiple applications. To maximize effectiveness and usefulness, services are distributed among multiple computing devices connected by a network, as shown in Figure 0.2. Common network services provided to clients in such environments include distributed naming, network file systems, routing table management, logging, printing, e-mail, remote login, file transfer, Web-based e-commerce services, payment processing, customer relationship management, help desk systems, MP3 exchange, streaming media, instant messaging, and community chat rooms.
The networked application architecture shown in Figure 0.2 partitions the interactive GUI, instruction processing, and persistent data resources among a number of independent hosts in a network. At run time, the flow of control in a networked application resides on one or more of the hosts. All the system components communicate cooperatively, transferring data and execution control between them as needed. Interoperabil-ity between separate components can be achieved as long as compatible communication protocols are used, even if the underlying networks, operating systems, hardware, and programming languages are heterogeneous [HV99]. This delegation of networked application service responsibilities across multiple hosts can yield the following benefits:
Figure 0.2: A Common Networked Application Environment 3
Enhanced connectivity and collaboration disseminates information rapidly to more potential users. This connectivity avoids the need for manual information transfer and duplicate entry.
Improved performance and scalability allows system configurations to be changed readily and robustly to align computing resources with current and forecasted system demand.
Reduced costs by allowing users and applications to share expensive peripherals and software, such as sophisticated database management systems.
Your job as a developer of networked applications is to understand the services that your applications will provide and the environment(s) available to provide them, and then
Design mechanisms that services will use to communicate, both between themselves and with clients.
Decide which architectures and service arrangements will make the most effective use of available environments.
Implement these solutions using techniques and tools that eliminate complexity and yield correct, extensible, high-performance, low-maintenance software to achieve your business's goals.
This book provides the information and tools you need to excel at these tasks.
Your job will not be easy. Networked applications are often much harder to design, implement, debug, optimize, and monitor than their stand-alone counterparts. You must learn how to resolve the inherent and accidental complexities [Bro87] associated with developing and configuring networked applications. Inherent complexities arise from key domain challenges that complicate networked application development, including
Selecting suitable communication mechanisms and designing protocols to use them effectively
Designing network services that utilize the available computing resources efficiently and reduce future maintenance costs
Using concurrency effectively to achieve predictable, reliable, high performance in your system
Arranging and configuring services to maximize system availability and flexibility.
Dealing with inherent complexity requires experience and a thorough understanding of the domain itself. There are many design tradeoffs related to these inherent complexity issues that we will investigate in Chapters 1 and 5.
Accidental complexities arise from limitations with tools and techniques used to develop networked application software, including
The lack of type-safe, portable, and extensible native OS APIs
The widespread use of algorithmic decomposition, which makes it unnecessarily hard to maintain and extend networked applications
The continual rediscovery and reinvention of core networked application concepts and capabilities, which keeps software life-cycle costs unnecessarily high
Networked application developers must understand these challenges and apply techniques to deal with them effectively. Throughout this book we illustrate by example how ACE uses object-oriented techniques and C++ language features to address the accidental complexities outlined above.