Distributed Processing,

Client/Server, and Clusters

1
 Agenda

•Client/Server Computing
•Service-Oriented Architecture
•Distributed Message Passing
•Remote Procedure Calls
•Clusters
2
 Client/Server Computing
• Client machines are generally single-user
PCs or workstations that provide a highly
user-friendly interface to the end user
• Each server provides a set of shared
services to the clients.
• The server enables many clients to share
access to the same database and enables
the use of a high-performance computer
system to manage the database.
3
 Client/Server Terminology
• Applications Programming Interface (API)
– A set of function and call programs that allow clients
and servers to intercommunicate
• Client
– A networked information requester, usually a PC or
workstation, that can query database and/or other
information from a server
• Middleware
– A set of drivers, APIs, or other software that improves
connectivity between a client application and a server

4
 Client/Server Terminology
• Relational Database
– A database in which information access is limited to the
selection of rows that satisfy all search criteria
• Server
– A computer, usually a high-powered workstation, a
minicomputer, or a mainframe, that houses information
for manipulation by networked clients
• Structured Query Language (SQL)
– A language developed by IBM and standardized by
ANSI for addressing, creating, updating, or querying
relational databases
5
6
 Client/Server Applications
• The key feature of a client/server architecture
is the allocation of application-level tasks
between clients and servers.

• Basic software is an operating system running

on the hardware platform

• Platforms and the operating systems of client

and server may differ
7
 Client/Server Applications
• These lower-level differences are
irrelevant as long as a client and
server share the same
communications protocols and
support the same applications

8
9
 Client/Server Applications
• Bulk of applications software
executes on the server

• Application logic is located at the

client

• Presentation services in the client

10
 Database Applications
• The server is a database server
• Interaction between client and server
is in the form of transactions
–the client makes a database request
and receives a database response
• Server is responsible for maintaining
the database

11
12
Previous figure suggests that all of the
application logic is on the client side,
while the server is only concerned with
managing the database.

Whether such a configuration is

appropriate depends on the style and
intent of the application.

13
 Classes of Client/Server
Applications
• Host-based processing
– Not true client/server computing
– Traditional mainframe environment

21
 Classes of Client/Server
Applications
• Server-based processing
– Server does all the processing
– Client provides a graphical user interface

22
 Classes of Client/Server
Applications
• Client-based processing
– All application processing done at the
client
– Data validation routines and other
database logic functions are done at the
server

23
 Classes of Client/Server
Applications
• Cooperative processing
– Application processing is performed in an
optimized fashion
– Complex to set up and maintain

24
 Three-Tier Client/Server
Architecture
• Application software distributed
among three types of machines

–User machine
• Thin client

25
 Three-Tier Client/Server
Architecture
–Middle-tier server
• Gateway
• Convert protocols
• Merge/integrate results
from different data sources
–Backend server
26
The interaction between the middle-tier server and
the backend server also follows the client/server
27
model.
 File Cache Consistency
• When a file server is used, performance of
file I/O can be noticeably degraded relative to
local file access because of the delays
imposed by the network.

• File caches hold recently accessed file

records
• Caches are consistent when they contain
exact copies for remote data
• File-locking prevents simultaneous access to
a file 28
29
 The Role of Middleware in Client/Server
Architecture
• Set of tools that provide a uniform
means and style of access to system
resources across all platforms.
• Enable programmers to build
applications that look and feel the
same.
• Enable programmers to use the same
method to access data.
30
The basic purpose of middleware
is to enable an application or user
at a client to access a variety of
services on servers without being
concerned about differences
among servers.

31
32
33
 Agenda
Client/Server Computing
•Service-Oriented Architecture
•Distributed Message Passing
•Remote Procedure Calls
•Clusters
34
 SERVICE-ORIENTED ARCHITECTURE

The service-oriented architecture (SOA) is a

form of client/server architecture that now,
widespread use in enterprise systems.

An SOA organizes business functions into a

modular structure rather than as monolithic
applications for each department.

As a result, common functions can be used

by different departments internally and by
external business partners as well. 35
The more fine-grained the modules, the more
they can be reused.

In general, an SOA consists of a set of

services and a set of client applications that
use these services.

A client request may involve a single service

or may involve two or more services to
coordinating some activity, requiring
communication of services with each other.
36
The services are available through published
and discoverable interfaces.

Standardized interfaces are used to enable

service modules to communicate with one
another and to enable client applications to
communicate with service modules.

The most popular interface is the use of XML

(Extensible Markup Language) over HTTP
(Hypertext Transfer Protocol), known as Web
services .
37
SOAs are also implemented using other
standards, such as CORBA (Common Object
Request Broker Architecture).

At a top level, an SOA contains three types of

architectural elements:

38
39
Service provider: A network node that provides a
service interface for a software asset that manages a
specific set of tasks.

Service requestor: A network node that discovers

and invokes other software services to provide a
business solution.

Service broker: A specific kind of service provider that

acts as a registry and allows for the lookup of service
provider interfaces and service locations.

40
 key characteristics for effective use of
services:
Coarse-grained: Operations on services
are frequently implemented to cover more
functionality and operate on larger data
sets, compared with component-interface
design.

Interface-based design: Services

implement separately defined interfaces.
The benefit of this is that multiple services
can implement a common interface and a
41
service can implement multiple interfaces.
• Discoverable: Services need to be found
at both design time and run time, not only
by unique identity but also by interface identity
and by service kind.

• Single instance: Unlike component-

based development, which instantiates
components as needed, each service is a
single, always running instance that a number
of clients communicate with.
42
•Loosely coupled: Services are
connected to other services and clients
using standard, dependency-reducing,
decoupled message-based methods such as
XML document exchanges.

• Asynchronous: In general, services use

an asynchronous message-passing
approach; however, this is not required. In
fact, many services will use synchronous
43
message passing at times.
 EXAMPLE.

Figure 16.11a shows a common approach to building

applications targeted at specific user categories.

For each specific application, a single self-contained

application module is built.

What ties together the various applications in the

enterprise is an application-independent database
management system that supports a number of
databases.

44
 EXAMPLE.

Multiple applications may have access to a single

database. For example, in this configuration all three
applications require access to a customer information
database.

The advantages of this arrangement are clear.

By separating the data from the applications and

providing a uniform database interface, multiple
applications can be developed and revised
independently from one another.
45
 EXAMPLE.

This typical approach, of a variety of applications using

a common set of databases, has some drawbacks.

The addition of a new feature or user service, such as

ATM, generally requires building a new application
independent of existing applications.

This is despite the fact that much of the necessary logic

has already been implemented in related applications.

46
EXAMPLE.

47
 EXAMPLE.

We can achieve greater efficiency and flexibility by

migrating to an SOA, as shown in Figure 16.11b.

The strategy is to isolate services that may be of

common use to multiple applications and implement
these as separate service modules.

In this particular example of the SOA, there are some

core applications that deal with the functionality of
individual databases issues and with specific business
logic.
.
48
These applications are accessible by
application programming interfaces by service
modules that implement common services.

Finally, the specific applications visible to

users deal primarily with presentation

49
50
 Agenda
Client/Server Computing
Service-Oriented Architecture
•Distributed Message Passing
•Remote Procedure Calls
•Clusters
51
 2. DISTRIBUTED MESSAGE PASSING

• It is usually the case in a distributed

processing systems that the computers do
not share main memory; each is an
isolated computer system.

• Thus, interprocessor communication

techniques that rely on shared memory,
such as semaphores, cannot be used.

• Instead, techniques that rely on message

passing are used. 52
 2. DISTRIBUTED MESSAGE PASSING

In this chapter we look at the two most common

approaches.

• The first is the straightforward application of

messages as they are used in a single system.

• The second is a separate technique that relies on

message passing as a basic function:
the remote procedure call.

53
 2. DISTRIBUTED MESSAGE PASSING

use of message passing to implement

client/server functionality

54
Middleware Mechanisms

55
Middleware Mechanisms

56
Distributed Message Passing
• Message passed used to communicate
among processes
• Send and receive messages as used in
a single system or RPC

• Several design issues are associated

with distributed message passing,

57
Basic Message-Passing
Primitives

58
Design issues

59
 Reliability Versus Unreliability
• Reliable message-passing guarantees
delivery if possible
– Not necessary to let the sending
process know that the message was
delivered
• Send the message out into the
communication network without reporting
success or failure
– Reduces complexity and overhead
60
 Blocking Versus Nonblocking
• Nonblocking
–Process is not suspended as a
result of issuing a Send or Receive
–Efficient and flexible
–Difficult to debug

61
 Blocking Versus Nonblocking
• Blocking
–Send does not return control to the
sending process until the message
has been transmitted
–OR does not return control until an
acknowledgment is received
–Receive does not return until a
message has been placed in the
allocated buffer 62