System Models

How systems are partitioned, structured

and organized
Introduction to System Model
 Difficulties for and threats to Distributed System

 Widely varying modes of use

 Parts of system / pages uses more and some not
 Wide range of system environment
 Heterogeneous N/W , H/W
 Internal Parts
 Non-Synchronized clock, conflicting data update
 External threats
 Attack of data integrity ,DDoS (Distributed Denial of
Services)
Architectural Models
 In complex systems, it is necessary to
organize the complexity by partitioning.
Architectural models are ways to organize the
parts and structure the relationships between
them.
 Two fundamental architectural models are the
Client/Server model and the Peer-to-Peer
model
The Client/Server Model
 The client/server model is organized around
clients that request services and servers that
provide services. Services might include
information (such as the current weather) or
computational services (such as complex
calculations).
 There may be intermediate layers between
the client and server that perform a portion of
the task of locating and providing services.
Client/Server Performance
 Performance, scalability and mobility of the
client/server model can be improved by
 Partitioning or replicating data on servers
 Caching data at proxy servers or clients
 Using mobile code and mobile agents
 Adding and removing mobile devices
The Peer-to-Peer Model
 In peer-to-peer models, each node of a
distributed system is capable of requesting
and providing services. Most of the services
available are available from several or even
many nodes. Nodes tend to come and go
from the network frequently, but redundancy
tends to keep most services available.
Communications
 Probably the key concern of a distributed system is
the communication between nodes of the system.
 It can be argued that computers are improperly
named. While they can and do provide computations,
their dominant use is to provide information, so
communicator might be a more accurate description
than computer.
 Unintended Consequences
 The fact that computers are primarily used as communicators
is an example of the law of unintended consequences.
Quite often, the utility of a new technology is not understood at
the time of it’s introduction. Computers were originally used
during World War 2 to compute ballistic tables for the Navy
and perform calculations to design the atomic bomb.
Computer was then an accurate name.
 No one in the movie industry then could have anticipated that
by today, people would spend more money on computer
games than movie tickets!
 Another example
 Most of the wealth created by the automobile industry did
not go to car and truck makers and their suppliers. It went
to investors in and developers of suburban real estate, as
mobility increased the value of land within commuting
distance of cities.
 The most valuable employees in any industry are not the
technicians who know how to use a technology, but the
people who can see new possibilities in new capabilities of
that technology.
Fundamental Models
 Fundamental models describe properties common to
all architectural models often focusing on
communications between nodes
 The interaction model manages performance
and time limits
 The failure model specifies faults and defines
reliable communication
 The security model describes threats to
processes and communication channels
Problems for distributed systems
 Distributed systems can be used in many different
ways by persons or systems with different objectives.
 Distributed systems can include a wide variety of
hardware, operating systems, networks and
applications.
 Many types of internal system problems are possible.
 There are many external threats that may affect a
system,
What is the Architecture Analogy?
 Just as we need many views to construct a house,
(site plan, floor plans, wiring and plumbing diagrams,
etc.) software development benefits from a similar
approach
 Time tested designs, methods, and approaches
improve quality and performance (Center Hall
Colonial, keeping plumbing together, etc.)
 Architecture helps us understand the system,
organize development, foster reuse, and evolve the
system
Architectural Modeling
 Architecture details a system by the
organization of its components.
 The components might be nodes on a
network, layers of software, collections of
services, or other ways of partitioning the
system.
 For example, one way of partitioning a
system is to classify processes as client
processes, server processes or peer
processes.
 Architectural Views
System Architecture
Application Architecture

Business Architecture
Presentation
Layer
Business
Application
Layer Product

Information Service
Layer

Resource

Support

Physical Architecture
Operations Architecture
 Some Client/Server
Architectural Patterns
Thin-Client model: All application processing and
data management by server only.
Fat-Client model : Server only responsible for data
management. The client machine implements
application logic and interactions with user.
Three-tier client-server: There is a layer between
client and server that may provide data and/or
application processing.
Client/Server Configurations
 Client-Server configurations are generally
categorized in two types:
 Two-tier Configurations: consisting of a client
and a server.

Client
(e.g. User Server
Interface) (e.g. Data)
Client/Server Configurations (cont’d)
 Three-tier Configurations: includes another
server that offloads certain functions from
either the client and/or the server. Since there
can be many intermediate servers, this may
also be called n-tier.

Client Mid-tier
(e.g. User Server
for processing (e.g. Data)
Interface)
 Client/Server Configurations (cont’d)

 N-Tier Configurations: a type of three-tier set up

that includes multiple intermediate servers.
Mid-tier
Client
Server
Mid-tier (e.g. Data)
Client
Mid-tier
 Processing and data storage can occur on any node, as shown on
the next page (using a three-tier configuration).
 User Processing
Interface Data

User Processing Processing

Interface
Data
Processing
User
Interface Processing Data

Processing Data Data

User Processing
Interface Processing

Data
Fat vs. Thin Clients
 Thin Client: In a client/server model, a client is called
a “thin client” when the client contains a small amount
of processing. Most of the processing is with the
middle tier (in a three-tier setup) or the server.

User Processing
Processing
Interface
Processing Data
 Fat vs. Thin Clients (cont’d)
 Fat Client: A “fat client” is a client that
contains a great deal of processing (which
may include business logic), usually more
than the server.

Processing Data
User
Processing Processing
Interface
Data
 More Architectural Patterns for
Distributed Software Systems
Multiprocessor: Common for large real-time systems
and critical systems to improve performance and
resilience of the system.
Distributed Object: Removes the distinction between
client and server. The fundamental system
components are objects that provide interface to a set
of services. Other objects call these services with no
logical distinction between the provider and receiver.
Peer-to-Peer: Similar to distributed objects, except
that components are systems, not objects.
Typical Layers in a Distributed
System

Applications and Services

Middleware

Operating System

Computer and Network Hardware

Typical Corporate Application
(multi-tier client-server)
Presentation
Data Application
management processing

Client
(browser)
Client

Client
HTTP

Web Server(s)
CGI Intranet
Database ASP Internet
Server ODBC CF
WS

HTTP
Client
ODBC-Open Database Connectivity
CGI – Common Gateway Interface
Client
ASP –Active server pages (Microsoft)
Fire Wall
CF - Cold Fusion (Allaire Corp.)
(security) Client (browser)
Web Sphere – (IBM Corp.)
 What is Middleware?
 Middleware is the software between your
application and the operating system and
networking on a computer. It is the layer above the
operating system but below the application program
that provides a common programming abstraction
across a distributed system.
 It can be called the / in Client/Server.
 The classical definition of an operating system is
“software that makes hardware useable”. Similarly,
Middleware can be considered to be the software
that makes a distributed system programmable.
What is Middleware?
 Layer between Application and OS/Network
 Provides distribution transparency
 communication infrastructure
 registration and lookup of remote service
 Resolves heterogeneity of
 Hardware/OS
 Networks
 Programming languages
 ISO: forms of transparency

 Access – hide differences in data representation

and how a resource is accessed
 Location – hide where a resource is located
 Migration – hide that a resource may move to
another location
 Relocation – hide that a resource may move while
in use
 Replication – hide that a resource is replicated
 ISO: transparency continued

 Concurrency – hide that a resource may be

shared by several competitive users
 Failure – hide the failure and recovery of a
resource
 Persistence – hide whether a software resource is
in memory or on disk
Pros and Cons of Middleware
 Pros:
 Reduce number of interfaces.
 Clients see only one system i.e. the middleware.
 Centralizes control.
 Functionality widely available to all clients.
 It allows to implement functionality that otherwise
would be very difficult to provide.
 Cons
 Complex software.
 Development platform (API) not complete system.
 Functionality is hard to understand.
Standard Interfaces
 Middleware provides a comprehensive set of
higher-level distributed computing capabilities
and a set of standards-based interfaces.
 These interfaces allow applications to be
distributed more easily and to take advantage
of other services provided over the network.
Building Blocks
 Application developers and system
integrators can use middleware services as
building blocks to construct enterprise-wide
information systems that use distributed
computing resources effectively.
Position of Middleware in OSI
Model

Application
Presentation Complex data conversion
Session Operation and Objects
Transport Communication
Network
Data Link
Physical
 Examples of Middleware
 Distributed Computing Environment from OSF
based on RPC and IDL
 CORBA from OMG
 based on objects and IDL interface
 objects locate each other through ORB
 defines Internet Inter-ORB protocol (IIOP)
 DCOM from Microsoft
 builds ORPC on top of DCE RPC
 supports integration of binary components from
different languages (e.g. VB, Java, C++)
Examples of Middleware(cont.)

 Remote Method Invocation (RMI)

 based on a single language (Java)
 CORBA IDL used for defining interfaces
 Jini from Sun
 based on RMI
 proposed for network-aware appliances
High-Level Services
 Many middleware services are high-level
services
 Example: a single request of the data access
service can retrieve many rows of information
from one or more remote SQL relational
databases (less coding effort)
Evolving Middleware for
Application Distributability
 The burden of distributing the application’s
functions across nodes in a network fell
largely on the application programmer.
 The transport interface code is divided into
transport-independent and transport-
dependent parts.
 Middleware provides transparency of the
transport interface code.
Structure of Traditional Distributed
Applications
 The application includes the application logic and two
types of networking code:
 Application protocol support code. Example: The X
protocol for transmitting graphical images.
 Transport Interface Code makes the appropriate
network calls to send and receive the messages that
make up the the application protocol over a specific
network transport.
Traditional Distributed Applications

Node 1 Node 2
Appl. Program 1 Appl. Program 2
Appl. Protocol Appl. Protocol
Support Code Support Code

Transport Transport
Interface Code Interface Code

Appl. Protocol

Transport Protocol
Distributed System Variations
 Multiple servers: Services with large
demands, such as search engines, may have
many servers dedicated to a particular task.
 Proxy servers and Caches: Data likely to be
needed again may be stored in memory or on
local for fast retrieval.
 Mobile code: Code may be retrieved from a
server for execution on a client system. A
common example of this is a Java Applet.
Variations, continued
 Mobile Agents: A running program including
code and data may run on remote systems.
This may be a security problem, as such
agents include worms, viruses, and web
crawlers.
 Network Computers: All code and data may
be stored on a server and moved to a local
thin client temporarily for execution. Only the
code necessary to retrieve the programs and
data is stored on the network appliance.
Variations, continued
 Thin Clients: Most of the processing may be
done on a remote server, with little more than
a client interface, most commonly a Web
Browser, running on the client.
 Mobile clients and spontaneous
interoperation: Transient mobile devices such
as laptop computers, cell phones and PDAs
may connect to the network using
technologies such as GSM, 3G, WiFi, and
Bluetooth.
Design Requirements
 There are many challenges in designing
computer systems. Some of those challenges
include:
 Performance
 Quality
of service
 Caching and Replication
 Dependability
 Performance issues
 Responsiveness: Users want both speed and
consistency.
 Throughput: IT systems are expensive, and are
often sold on the basis of their ability to perform the
most work for the least money.
 Load balancing: High potential throughput can be
defeated if the work is not distributed to make
maximum use of potential because some of the
system is idle.
Quality of Service

 Performance is one aspect of quality of service.

Others include:
 Reliability: this includes availability (“uptime”) and
freedom from errors.
 Security: this is protection from compromise or loss
of information or investment.
 Time Criticality: some information must be available
in the right place at the right time. This is a major
concern in designing networks.
 Caching and Replication
 One tool for increasing throughput, availability and time
critical sensitivity is storing extra copies of data in
memory (caching) or on a local disk (replication).
 Data stored can be small (translated web addresses) or
large (multiple copies of corporate databases).
 There are many challenges in managing data that can be
changed in one place while having copies in other places.
 Dependability Issues
 Correctness is ensuring that data is current and
accurate.
 Fault tolerance is ensuring that when something
goes wrong, the system can recover or bypass
the fault rapidly without loss of information.
 Security includes identifying users, determining
privileges and protection of systems and data.
 Fundamental Models

 Modeling is based on abstraction. We ignore some parts

of a system to concentrate on others. For example, you
cannot build a house from plans that only describe the
plumbing. But the plumbing diagram contains all the
information that the plumber needs to install the
plumbing. You may also have a wiring diagram for the
electrician, a framing diagram for the carpenters and an
excavation plan for the bulldozer and backhoe operators.
Questions for a model
 What are the main entities in a system?
 How do those entities interact with each
other?
 What characteristics affect the individual and
collective behavior of those entities?
Purpose of a Model
 Make explicit all of the relevant *
assumptions about a system.
 Make generalizations about what is possible
or impossible to accomplish based on those
assumptions.
*Note that it is a real challenge to include everything that
matters while excluding everything that does not matter!
Fundamental Models for
Distributed Systems
 Interaction Model: describes the communications
between the system and external actors and the
communication between components of the system.
 Failure Model: defines and classifies potential faults for
analysis in order to design a fault tolerant system.
 Security Model: identifies potential threats to a system so
that countermeasures can be developed.
Interaction Model Concerns
 Performance of communication channels
 Computer clocks and timing events
 Synchronous distributed systems
 Asynchronous distributed systems
 Event ordering
Failure Model Concerns
 Process omission failures
 Communication omission failures
 Arbitrary failures
 Timing failures
 Masking failures
 Communication Reliability
 Validity
 Integrity
 Security Model Concerns
 Protecting objects
 Securing processes and their communications
 Defeating security threats
 Cryptography and shared secrets
 Authentication and Authorization
 Secure channels
 Denial of service
 Mobile code
Classroom Team Exercise
 Create an architectural diagram of the
systems you have used so far for this class.
Include only one wired and one wireless
connection from a student computer. Use a
cloud to represent the Internet and circles for
the AFS and PC networks at NJIT,
connecting hosts with links to the circles.
 Some Review questions

 What are the parts of a typical client/server system

for corporate transaction processing?
 How can a search engine coordinate searching for
current data with constant updates from web crawlers
on data that is replicated many times?
 What is the difference between a buffer and a cache?
 What applications are best for mobile code?
 Can you think of other technological examples of the
law of unintended consequences?
References
 George Coularis, Jean Dollimore and Tim Kindberg,
Distributed Systems, Concepts and Design, Addison
Wesley, Fourth Edition, 2005
 J. Colonna-Romano & P. Srite, The Middleware
Source Book,Digital Press
 Byte Magazine, April 1996, pp. 65-78
 P. Bernstein, Middleware: A Model for Distributed
System Services, Communications of ACM, Feb.
1996, pp. 86-98