In order to get some perspective on the design considerations for high-performance distributed applications, you may find it useful to contrast them with earlier client/server architectures.
In earlier client/server architectures, the database did all the work, insulating developers from most data access coding. Databases performed tasks related to connectivity, security, directory, transaction, and recovery processing. In addition, database routing software on the client handled all communications. As a result, the databases freed developers to concentrate on the business aspects of the application.
Databases also gave these applications performance and scalability. The number of users that an application could support was essentially a function of the database. The application code might run on client platforms with limited resources, thus limiting performance and scalability, but improving performance and scalability was strictly database-related.
With distributed applications, performance and scalability become key aspects of the design process. Distributed applications require that you consider the application's components and infrastructure, including logical packaging, physical deployment modeling, remote server computer workload analysis, and evaluation of the available network bandwidth.
Ideally, to address performance requirements, each client request should be serviced on demand. On-demand delivery of requested application services to an ever-increasing number of client requests imposes certain scalability requirements. Application servers must be available to provide services whenever clients request them. When an application server is down, so is the business that it supports.
Servers can be unavailable for many reasons, including:
In distributed applications, the code for the distributed components must be bulletproof. Component reliability must approach that of the operating system on which it runs. Obviously, distributed components must be thoroughly tested.
When failures do occur, application servers must have the capability to quickly recover from those failures and to restart themselves. Recovery should recapture as much user work as possible, and data must be left in a consistent state as well. If a server platform will be down for an extended period of time, the application server might be restarted on a different platform.
Transactions represent another kind of processing that was handled by the database in simple client/server architectures. In distributed application architectures, a transaction monitor (such as Microsoft Transaction Server) is required to extend transaction management to multiple, distributed databases.