System Models

System Models
How systems are partitioned, structured and organized
NJIT
1
5/4/2012 Leon Jololian/George Blank
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-toPeer 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
5/4/2012
Leon Jololian/George Blank
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.
5/4/2012
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 its 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,
10
What is the Architecture Analogy?
11
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.
12
5/4/2012
Architectural Views
System Architecture Application Architecture Business Architecture
Presentation Layer Application Layer
Business
Product
Information Layer
Service Resource
Support
Physical Architecture
13
Operations Architecture
5/4/2012
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.
14
5/4/2012
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 Interface)
Server (e.g. Data)
15
5/4/2012
Client/Server Configurations (contd)
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.
Mid-tier for processing
Client (e.g. User Interface)
Server (e.g. Data)
16
5/4/2012
Client/Server Configurations (contd)
N-Tier Configurations: a type of three-tier set up that includes multiple intermediate servers.
Mid-tier Mid-tier
Client
Server (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).
17
User Interface
Processing
Data
User Interface
Processing User Interface
Processing
Processing
Data
Processing Data Processing
Data Data Processing
Processing User Interface Data

18
5/4/2012
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 Interface
Processing
Processing
Processing
Data
19
5/4/2012
Fat vs. Thin Clients (contd)
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.
User Interface
Processing
Processing
Data
Processing
Data
20
5/4/2012
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.
21
Typical Layers in a Distributed System

Applications and Services
Middleware
Operating System Computer and Network Hardware
22
5/4/2012
Typical Corporate Application

(multi-tier client-server)
Presentation Data management Application processing
Client
Client Client
(browser)
HTTP
Web Server(s)
Database Server
CGI ASP
Intranet Internet
ODBC
CF WS
HTTP
Client
ODBC-Open Database Connectivity CGI Common Gateway Interface ASP Active server pages (Microsoft) CF - Cold Fusion (Allaire Corp.)
Client Fire Wall (security)
23
Web Sphere (IBM Corp.)
5/4/2012
(browser) Leon Jololian/George Blank
Client
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.
24
What is Middleware?

Layer between Application and OS/Network Provides distribution transparency

communication infrastructure registration and lookup of remote service Hardware/OS Networks Programming languages
Resolves heterogeneity of
25
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
26
5/4/2012
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
27
5/4/2012
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.
28
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.
29
Building Blocks
Application developers and system integrators can use middleware services as building blocks to construct enterprisewide information systems that use distributed computing resources effectively.
30
5/4/2012
Position of Middleware in OSI Model

Application Presentation Session Transport Network Data Link Physical
31
Complex data conversion
Operation and Objects
Communication
5/4/2012
Examples of Middleware

Distributed Computing Environment from OSF

based on RPC and IDL based on objects and IDL interface objects locate each other through ORB defines Internet Inter-ORB protocol (IIOP) builds ORPC on top of DCE RPC
CORBA from OMG
DCOM from Microsoft
supports integration of binary components from different languages (e.g. VB, Java, C++)
32
Examples of Middleware(cont.)
Remote Method Invocation (RMI)
based on a single language (Java)

CORBA IDL used for defining interfaces based on RMI proposed for network-aware appliances
Jini from Sun

33
5/4/2012
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)
34
5/4/2012
Evolving Middleware for Application Distributability
The burden of distributing the applications functions across nodes in a network fell largely on the application programmer. The transport interface code is divided into transport-independent and transportdependent parts. Middleware provides transparency of the transport interface code.
35
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.
36
5/4/2012
Traditional Distributed Applications
Node 1 Appl. Program 1

Appl. Protocol Support Code
Transport Interface Code
Node 2 Appl. Program 2

Appl. Protocol Support Code
Transport Interface Code
Appl. Protocol Transport Protocol
37
5/4/2012
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.
38
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.
39
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.
40
Design Requirements
There are many challenges in designing computer systems. Some of those challenges include: Performance Quality of service Caching and Replication Dependability
41
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.
42
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.
43
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.
44
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.
45
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.
46
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?
47
5/4/2012
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!
48
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.
49
Interaction Model Concerns
Performance of communication channels Computer clocks and timing events
Synchronous distributed systems Asynchronous distributed systems
Event ordering
50
5/4/2012
Failure Model Concerns
Process omission failures Communication omission failures Arbitrary failures Timing failures Masking failures Communication Reliability Validity Integrity
51
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
52
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.
53
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?
54
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
55

System Models

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

System Models

Caricato da

Copyright:

Formati disponibili

System Models

How systems are partitioned, structured and organized

The Client/Server Model

Leon Jololian/George Blank

The Peer-to-Peer Model

Leon Jololian/George Blank

Problems for distributed systems

What is the Architecture Analogy?

Leon Jololian/George Blank

Leon Jololian/George Blank

Some Client/Server Architectural Patterns

Leon Jololian/George Blank

Client-Server configurations are generally categorized in two types:

Two-tier Configurations: consisting of a client and a server.

Server (e.g. Data)

Leon Jololian/George Blank

Client/Server Configurations (contd)

Client (e.g. User Interface)

Server (e.g. Data)

Leon Jololian/George Blank

Client/Server Configurations (contd)

Server (e.g. Data)

Processing Data Processing

Data Data Processing

Processing User Interface Data

Leon Jololian/George Blank

Fat vs. Thin Clients

Leon Jololian/George Blank

Fat vs. Thin Clients (contd)

Leon Jololian/George Blank

More Architectural Patterns for Distributed Software Systems

Typical Layers in a Distributed System

Operating System Computer and Network Hardware

Leon Jololian/George Blank

Typical Corporate Application

Client Fire Wall (security)

Web Sphere (IBM Corp.)

(browser) Leon Jololian/George Blank

Layer between Application and OS/Network Provides distribution transparency

ISO: forms of transparency

Leon Jololian/George Blank

ISO: transparency continued

Leon Jololian/George Blank

Pros and Cons of Middleware

Leon Jololian/George Blank

Position of Middleware in OSI Model

Complex data conversion

Operation and Objects

Leon Jololian/George Blank

Distributed Computing Environment from OSF

CORBA from OMG

DCOM from Microsoft

Remote Method Invocation (RMI)

based on a single language (Java)

Jini from Sun

Leon Jololian/George Blank

Leon Jololian/George Blank

Evolving Middleware for Application Distributability

Structure of Traditional Distributed Applications

Leon Jololian/George Blank

Traditional Distributed Applications

Node 1 Appl. Program 1

Node 2 Appl. Program 2