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 >
