Concepts:
Distribution Patterns
Topics
Processors and Devices are common stereotypes of Node. The distinction
between the two may seem difficult to assess, as many devices now contain their
own CPUs. However, the distinction between processors and devices lies in the
type of software that executes on them. Processors execute programs/software
that were explicitly written for the system being developed. Processors are
general-purpose computing devices which have computing capacity, memory, and
execution capability.
Devices execute software written that controls the functionality of the
device itself. Devices are typically attached to a processor that controls the
device. They typically execute embedded software and are incapable of running
general-purpose programs. Their functionality is typically controlled by
device-driver software.
There are a number of typical patterns of distribution in systems, depending
on the functionality of the system and the type of application. In many cases,
the distribution pattern is informally used to describe the 'architecture' of
the system, though the full architecture encompasses this but also many more
things. For example, many times a system will be described as having a
'client-server architecture', although this is only the distribution aspect of
the architecture. This serves to highlight the importance of the distribution
aspects of the system and the extent to which they influence other architectural
decisions.
The distribution patterns described below imply certain system
characteristics, performance characteristics, and process architectures. Each
solves certain problems but also poses unique challenges.
In so-called "client/server architectures", there are specialized
network processor nodes called clients, and nodes called servers.
Clients are consumers of services provided by a server. A client often services
a single user and often handles end-user presentation services (GUI's), while
the server usually provides services to several clients simultaneously; the
services provided are typically database, security or print services. The
"application logic", or the business logic, in these systems is
typically distributed among both the client and the server. Distribution of the
business logic is called application partitioning.
In the following figure, Client A shows an example of a 2-tier architecture,
with most application logic located in the server. Client B shows a typical
3-tier architecture, with Business Services implemented in a Business Object
Server. Client C shows a typical web-based application.
Variations of Client-Server Architectures
In traditional client/server systems, most of the business logic is
implemented on clients; but some functionality is better suited to be located on
the server, for example functionality that often access data stored on the
server. By doing this, one can decrease the network traffic, which in most cases
is quite expensive (it is an order of magnitude or two slower than inter-process
communication).
Some characteristics:
- A system can consist of several different types of clients, examples of
which include:
- User workstations
- Network computers
- Clients and servers communicate by using various technologies, such as
CORBA/IDL, or RPC (remote-procedure call) technologies.
- A system can consist of several different types of servers, examples of
which include:
- Database servers, handling database machines such as
Sybase, Ingres, Oracle, Informix;
- Print servers, handling the driver logic (queuing
etc.) for a specific printer;
- Communication servers (TCP/IP, ISDN, X.25),
- Window Manager servers (X)
- File servers (NFS under UNIX).
The '3-tier Architecture' is a special case of the 'Client/Server
Architecture' in which functionality in the system is divided into 3 logical
partitions: application services, business services, and data services. The
'logical partitions' may in fact map to 3 or more physical nodes.
Example of a 3-tier Architecture
The logical partitioning into these three 'tiers' reflects an observation
about how functionality in typical office applications tends to be implemented,
and how it changes. Application services, primarily dealing with GUI
presentation issues, tends to execute on a dedicated desktop workstation with a
graphical, windowing operating environment. Changes in functionality tends to be
dictated often by ease of use or aesthetic considerations, essentially human
factors issues.
Data services tend to be implemented using database server technology, which
tends to execute on one or more high-performance, high-bandwidth nodes that
serve hundreds or thousands of users, connected over a network. Data services
tend to change when the representation and relationships between stored
information changes.
Business services reflect encoded knowledge of business processes. They
manipulate and synthesize information obtained from the data services, and
provide it to the application services. Business services are typically used by
many users in common, so they tend to be located on specialized servers as well,
though the may reside on the same nodes as the data services.
Partitioning functionality along these lines provides a relatively reliable
pattern for scalability: by adding servers and re-balancing processing across
data and business servers, a greater degree of scalability is achieved.
The client is "Fat" since nearly everything runs on it (except in a
variation, called the '2-tier architecture', in which the data services are
located on a separate node). Application Services, Business Services and Data
Services all reside on client machine; the database server will be usually on
another machine.
Traditional 2-tier or "Fat Client" Architecture
'Fat Clients' are relatively simple to design and build, but more difficult
to distribute (they tend to be large and monolithic) and maintain. Because the
client machines tend to cache data locally for performance, local cache
coherency and consistency tend to be issues and areas warranting particular
attention. Changes to shared objects located in multiple local caches are
difficult and expensive to coordinate, involving as they do network broadcast of
changes.
At the other end of the spectrum from the 'Fat Client' is the 'Fat Server' or
'Anorexic Client'. A typical example is the web-browser application running a
set of HTML pages, there is very little application in the client at all. Nearly
all work takes place on one or more web servers and data servers.
Web Application
Web applications are easy to distribute, easy to change. They are relatively
inexpensive to develop and support (since much of the application infrastructure
is provided by the browser and the web server). They may however not provide the
desired degree of control over the application, and they tend to saturate the
network quickly if not well-designed (and sometimes despite being
well-designed).
In this architecture, the application, business and data services reside on
different nodes, potentially with specialization of servers in the business
services and data services tiers. A full realization of a 3-tier architecture.
In the peer-to-peer architecture, any process or node in the system may be
both client and server. Distribution of functionality is
achieved by grouping inter-related services together to minimize network traffic
while maximizing throughput and system utilization. Such systems tend to be
complex, and there is a greater need to be aware of issues such as dead-lock,
starvation between processes, and fault handling.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Disciplines >
Analysis & Design >
Concepts >
