Architectural Models

Similar documents
Chapter 2 System Models

2. System Models Page 1. University of Freiburg, Germany Department of Computer Science. Distributed Systems. Chapter 2 System Models

System Models. 2.1 Introduction 2.2 Architectural Models 2.3 Fundamental Models. Nicola Dragoni Embedded Systems Engineering DTU Informatics

Announcements. me your survey: See the Announcements page. Today. Reading. Take a break around 10:15am. Ack: Some figures are from Coulouris

02 - Distributed Systems

02 - Distributed Systems

System Models for Distributed Systems

Middleware and Distributed Systems. System Models. Dr. Martin v. Löwis

System models for distributed systems

Architecture of distributed systems

Architecture of distributed systems

Distributed Systems: Models and Design

Chapter 1: Distributed Systems: What is a distributed system? Fall 2013

DISTRIBUTED SYSTEMS UNIT I

Introduction to Distributed Systems

Distributed Systems (5DV147)

System Models 2. Lecture - System Models 2 1. Areas for Discussion. Introduction. Introduction. System Models. The Modelling Process - General

DISTRIBUTED SYSTEMS. Second Edition. Andrew S. Tanenbaum Maarten Van Steen. Vrije Universiteit Amsterdam, 7'he Netherlands PEARSON.

MODELS OF DISTRIBUTED SYSTEMS

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 1. Introduction

Distributed Objects and Remote Invocation. Programming Models for Distributed Applications

3C05 - Advanced Software Engineering Thursday, April 29, 2004

DS 2009: middleware. David Evans

Communication. Distributed Systems Santa Clara University 2016

Distributed Systems COMP 212. Lecture 15 Othon Michail

Fundamental Issues. System Models and Networking Chapter 2,3. System Models. Architectural Model. Middleware. Bina Ramamurthy

Introduction to Distributed Systems. INF5040/9040 Autumn 2018 Lecturer: Eli Gjørven (ifi/uio)

DISTRIBUTED COMPUTER SYSTEMS ARCHITECTURES

Introduction to Distributed Systems (DS)

Last Class: RPCs and RMI. Today: Communication Issues

Verteilte Systeme (Distributed Systems)

Distributed Systems Question Bank UNIT 1 Chapter 1 1. Define distributed systems. What are the significant issues of the distributed systems?

Introduction to Distributed Systems (DS)

Modulo II Introdução Sistemas Distribuídos

Assignment 5. Georgia Koloniari

C 1. Recap. CSE 486/586 Distributed Systems Failure Detectors. Today s Question. Two Different System Models. Why, What, and How.

Advanced Distributed Systems

Introduction. Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve

Application Servers in E-Commerce Applications

CAS 703 Software Design

Appendix A - Glossary(of OO software term s)

Chapter 4 Communication

Indirect Communication

Introduction. Distributed Systems IT332

(9A05803) WEB SERVICES (ELECTIVE - III)

CA464 Distributed Programming

Distributed Algorithms Models

Chapter 18 Distributed Systems and Web Services

MODELS OF DISTRIBUTED SYSTEMS

Chapter Outline. Chapter 2 Distributed Information Systems Architecture. Distributed transactions (quick refresh) Layers of an information system

Chapter 2 Architectures. Software Architectures

SAI/ST course Distributed Systems

Distributed Systems Principles and Paradigms. Chapter 01: Introduction. Contents. Distributed System: Definition.

Distributed Systems

CSE 486/586 Distributed Systems

Module 1 - Distributed System Architectures & Models

Distributed Systems. Bina Ramamurthy. 6/13/2005 B.Ramamurthy 1

Software Architecture Patterns

Communication Paradigms

Distributed Systems Principles and Paradigms. Chapter 01: Introduction

Distribution and Integration Technologies

Indirect Communication

Chapter Outline. Chapter 2 Distributed Information Systems Architecture. Layers of an information system. Design strategies.

Client Server & Distributed System. A Basic Introduction

Patterns Architectural Styles Archetypes

Notes. Submit homework on Blackboard The first homework deadline is the end of Sunday, Feb 11 th. Final slides have 'Spring 2018' in chapter title

CS555: Distributed Systems [Fall 2017] Dept. Of Computer Science, Colorado State University

Today CSCI Remote Method Invocation (RMI) Distributed Objects

Distributed Systems. Characteristics of Distributed Systems. Lecture Notes 1 Basic Concepts. Operating Systems. Anand Tripathi

Distributed Systems. Characteristics of Distributed Systems. Characteristics of Distributed Systems. Goals in Distributed System Designs

presentation DAD Distributed Applications Development Cristian Toma

Distributed Information Processing

PART B UNIT II COMMUNICATION IN DISTRIBUTED SYSTEM PART A

Distributed Object-Based Systems The WWW Architecture Web Services Handout 11 Part(a) EECS 591 Farnam Jahanian University of Michigan.

Introduction to Distributed Computing

Client/Server-Architecture

Advanced Topics in Operating Systems

Dr Markus Hagenbuchner CSCI319 SIM. Distributed Systems Chapter 4 - Communication

Overview. System architectures Software layers Architectural models. Design requirements. client-server, peer processes, mobile code, agents,...

Distributed Systems. To do. q Distributed systems q This class q Models and architectures q Next: A brief introduction to Go

Unit 7: RPC and Indirect Communication

Distributed Systems Principles and Paradigms

COMMUNICATION IN DISTRIBUTED SYSTEMS

MOM MESSAGE ORIENTED MIDDLEWARE OVERVIEW OF MESSAGE ORIENTED MIDDLEWARE TECHNOLOGIES AND CONCEPTS. MOM Message Oriented Middleware

Concepts of Distributed Systems 2006/2007

Outline. Definition of a Distributed System Goals of a Distributed System Types of Distributed Systems

Grid Computing Systems: A Survey and Taxonomy

CHAPTER 2. Introduction to Middleware Technologies

WebSphere 4.0 General Introduction

Software Paradigms (Lesson 10) Selected Topics in Software Architecture

Chapter 2 Distributed Information Systems Architecture

Today: Distributed Objects. Distributed Objects

Data Management in Application Servers. Dean Jacobs BEA Systems

Peer-to-Peer Architectures and the Magi Open-Source Infrastructure

Advanced Topics in Distributed Systems. Dr. Ayman A. Abdel-Hamid. Computer Science Department Virginia Tech

Distributed Systems. The main method of distributed object communication is with remote method invocation

C 1. Today s Question. CSE 486/586 Distributed Systems Failure Detectors. Two Different System Models. Failure Model. Why, What, and How

Multimedia Database Architecture!

Trading Services for Distributed Enterprise Communications. Dr. Jean-Claude Franchitti. Presentation Agenda

Communication. Overview

Transcription:

Architectural Models Dr. Gannouni Sofien Most concepts are drawn from Chapter 2 Pearson Education Some ideas from Chapter 1 Pearson Education

Presentation Outline Introduction Architectural Models Software Layers System Architectures Client-Server Clients and a Single Sever, Multiple Servers, Proxy Servers with Cachers, Peer Model Alternative Client-Sever models driven by: Mobile code, mobile agents, network computers, thin clients, mobile devices and spontaneous networking Design Challenges/Requirements Fundamental Models formal description Interaction, failure, and Security models. Summary 2

Lecture Overview (I) An Architectural model of a distributed system is concerned with the placement of its parts and relationship between them. Examples: Client-Server (CS) and peer process models. CS can be modified by: The partitioning of data/replication at cooperative servers The caching of data by proxy servers or clients The use of mobile code and mobile agents The requirements to add or remove mobile devices. 3

Lecture Overview (II) Fundamental Models are concerned with a formal description of the properties that are common in all of the architectural models. Models addressing time synchronization, message delays, failures, security issues are addressed are: Interaction Model deals with performance and the difficulty of setting of time limits in a distributed system. Failure Model specification of the faults that can be exhibited by processes Secure Model discusses possible threats to processes and communication channels. 4

Architectural Models Software Layers System Architectures Interfaces and Objects Design Requirements

Architectural Models Intro [1] The architecture of a system is its structure in terms of separately specified components. Its goal is to meet present and likely future demands. Major concerns are make the system reliable, manageable, adaptable, and cost-effective. Architectural Model: Simplifies and abstracts the functions of individual components The placement of the components across a network of computers define patterns for the distribution of data and workloads The interrelationship between the components ie., functional roles and the patterns of communication between them. 6

Architectural Models Intro [2] Architectural Model - simplifies and abstracts the functions of individual components: An initial simplification is achieved by classifying processes as: Server processes Client processes Peer processes Cooperate and communicate in a symmetric manner to perform a task. 7

Software Architecture and Layers The term software architecture refereed: Originally to the structure of software as layers or modules in a single computer. More recently in terms of services offered and requested between processes in the same or different computers. Breaking up the complexity of systems by designing them through layers and services Layer: a group of related functional components Service: functionality provided to the next layer. Layer N Layer 2 Layer 1 (services offered to above layer) 8

Software and hardware service layers in distributed systems Applications, services Middleware Operating system Computer and network hardware Platform 9

Platform The lowest hardware and software layers are often referred to as a platform for distributed systems and applications. These low-level layers provide services to the layers above them, which are implemented independently in each computer. Major Examples Intel x86/windows Intel x86/linux Intel x86/solaris SPARC/SunOS PowePC/MacOS 10

Middleware A layer of software whose purpose is to mask heterogeneity present in distributed systems and to provide a convenient programming model to application developers. Major Examples: Sun RPC (Remote Procedure Calls) OMG CORBA (Common Request Broker Architecture) Microsoft D-COM (Distributed Components Object Model) Sun Java RMI Modern Middleware: Melbourne Gridbus for Grid computing ANL Globus a Grid toolkit IBM WebSphere Microsoft.NET Sun J2EE 11

System Architecture The most evident aspect of DS design is the division of responsibilities between system components (applications, servers, and other processes) and the placement of the components on computers in the network. It has major implication for: Performance, reliability, and security of the resulting system. 12

System Architecture Models Client / Server Architecture Models Meta-Computing model Global Computing Model Grid Computing P2P Model 13

Client Server Basic Model: Clients invoke individual servers Client invocation invocation Server result Server result Client Key: Process: Computer: 14 Client process interact with individual server processes in a separate computer in order to access data or resource. The server in turn may use services of other servers. Example: A Web Server is often a client of file server. Browser search engine -> crawlers other web servers.

Clients and Servers 15 The Server is a process that perform tasks on demand by exchanging messages with the clients. The Server is a resource manager and as such they provide: Encapsulation: Provide a useful service interface (a set of operations) to the resources that meet the client s needs Concurrent processing: Achieving concurrency transparency. Protection: Resources require protection from illegitimate accesses. Read, Write and Execution Permissions.

Clients and Servers General interaction between a client and a server. 16

Client/Server Communications: Interaction schemes A client/server system relies on communication, generally involving: Publisher/Subscriber Message passing RPC/RMI Shared spaces Message queuing 17

Publish/Subscribe Paradigm Publish/Subscribe (pub/sub): a powerful abstraction for building distributed applications Message-based, anonymous communication Participants are decoupled Good solution for highly dynamic, decentralized systems (e.g., wired environments with huge numbers of publishers and subscribers, Mobile networks, P2P etc) Many research issues, involving several research areas (e.g., systems, software eng., databases etc) 18

Publish/Subscribe Interactions Eugster, P.T., et al., The Many Faces of Publish/Subscribe. ACM Computing Surveys, 2003. 35(2). 19

Basic Interaction Model publishers IBM: -3,75 notification service IBM: -3,75 IBM: +2,51 S1 subscribers IBM ACME: +0,15 S1: IBM S2: ACME S3: ACME ACME: +0,15 S2 ACME IBM: +2,51 ACME: +0,15 S3 ACME event notification subscription 20

Why decoupling? Decouple producers and consumers Remove explicit dependencies Reduced coordination & synchronization between different entities Increase scalability of distributed systems Create highly dynamic, decentralized systems Decouple in three dimensions Space Time Synchronization (flow) 21

Space decoupling no need to hold references or even know each other 22

Time decoupling no need to be available at the same time 23

Synchronization decoupling Control flow is not blocked by the interaction 24

Message Passing The producer sends messages asynchronously through a communication channel (previously set up for that purpose). The consumer receives messages by listening synchronously on that channel. Coupled in space, time and sync (consumer side) 25

RPC/RMI The consumer performs a synchronous call, which is processed asynchronously by the producer. Coupled in space, time and sync (consumer side) 26

Shared Spaces producers insert data asynchronously into the shared space, while consumers read data synchronously. Coupled in sync (consumer side) 27

Message Queuing (Pull) Messages are stored in a FIFO queue. Producers append messages asynchronously at the end of the queue, Consumers dequeue them synchronously at the front of the queue. Coupled in sync (consumer side) 28

Generations Of C/S First Generation: frontal processing Second Generation: collaborative processing Third Generation: distributed data & processing Internet: to a universal C/S 29

Frontal Processing Presentation C/S The Logic of the user s interface is implemented on the client Revamping Presentation Application DBMS DB Presentation Presentation Application DBMS DB 30 Presentation C/S Revamping C/S

Collaborative Processing Stored Procedure The application is spread over the client and the server. Remote Data Management Presentation Presentation Application Application RPC/RMI RDA Application DBMS DBMS DBMS DB DB DB Stored Procedure C/S Remote DM C/S 31

Multilevel collaborative processing Each server performs a special task. A server may request a specific task from an other server. Presentation Presentation Application Application The First Tier The n Tier Application Application Application DBMS Application DB Level 2 Level x 32

A service provided by multiple servers Service Client Server Server Client Server Services may be implemented as several server processes in separate host computers. Example: Cluster based Web servers and apps such as Google, parallel databases Oracle 33

Distributed Data & Processing No machine has complete information on the state of the system Failure of one machine does not ruin the system. Machines make decisions based only on local available information. No assumption of the existence of a global clock. Symmetric processing Presentation Application DBMS DB Presentation Application DBMS DB Interface Application DBMS DB 34

Internet & New C/S Architectures HTML XML HTML XML HTML XML Web Server Web Server Web Server HTML/ XML Servlets HTML/ XML Servlets HTML/ XML Servlets Servlets Servlets Servlets JSP, Servlets ASP JSP, Servlets ASP JDBC, ADO ODBC OLE DB, JSP, Servlets ASP Application Server Corba, RMI, COM/DCOM, RPC JDBC, ADO, ODBC, OLE DB, 35 DBMS DBMS 1-Tier 2-Tiers 3-Tiers

Internet: Universal C/S HTML XML Web Server HTML/ XML Servlets Servlets JSP, Servlets ASP Corba, RMI, COM/DCOM, RPC JavaMail JDBC, ADO ODBC OLE DB, JMS Application Server Mail Server DBMS Message Server JNDI Directory service 36

Proxy servers (replication transparency) and caches: Web proxy server Client Proxy server Web server Client Web server A cache is a store of recently used data. 37

Variants of Client Sever Model: Mobile code and Web applets a) client request results in the downloading of applet code Client Applet code Web server b) client interacts with the applet Client Applet Web server Applets downloaded to clients give good interactive response Mobile codes such as Applets are potential security threat, so the browser gives applets limited access to local resources (e.g. NO access to local/user file system). 38

Variants of Client Sever Model: Mobile Agents A running program (code and data) that travels from one computer to another in a network carrying out of an autonomous task, usually on behalf of some other process advantages: flexibility, savings in communications cost virtual markets, software maintain on the computers within an organization. Potential security threat to the resources in computers they visit. The environment receiving agent should decide which of the local resource to allow. (e.g., crawlers and web servers). Agents themselves can be vulnerable they may not be able to complete task if they are refused access. 39

Thin clients and compute servers Network computer or PC Compute server Thin Client network Application Process Network computer: download OS and applications from the network and run on a desktop (solve up-gradation problem) at runtime. Thin clients: Windows-based UI on the user machine and application execution on a remote computer. E.g, X-11 system. 40

Mobile devices and spontaneous networking The world is increasingly populated by small and portal computing devices. W-LAN need to handle constantly changing heterogamous, roaming devices Need to provide discovery services: (1) registration service to enable servers to publish their services and (2) look up service to allow clients to discover services that meet their requirements. 41

Peer Processes: A distributed application based on peer processes Peer 2 Peer 1 Application Application Sharable objects Peer 3 Application Peer 4 Application Peers 5... N 42 All of the processes play similar roles, interacting cooperatively as peers to perform a distributed activities or computations without distinction between clients and servers. E.g., music sharing systems Gnutella, Napster, Kaza, etc. Distributed white board users on several computers to view and interactively modify a picture between them.

Interfaces and Objects The use of CS has impact on the software architecture followed: Distribution of responsibilities Synchronization mechanisms between client and server Admissible types of requests/responses Basic CS model, responsibility is statically allocated. File server is responsible for file, not for web pages. Peer process model, responsibility is dynamically allocated: In fully decentralized music file sharing system, search process may be delegated to different peers at runtime. 43

Design Requirements/Challenges of Distributed Systems Performance Issues Responsiveness Support interactive clients Use caching and replication Throughput Load balancing and timeliness Quality of Service: Reliability Security Adaptive performance. Dependability issues: Correctness, security, and fault tolerance Dependable applications continue to work in the presence of faults in hardware, software, and networks. 44

Presentation Outline Introduction Architectural Models Software Layers System Architectures Client-Server Clients and a Single Sever, Multiple Servers, Proxy Servers with Cachers, Peer Model Alternative Client-Sever models driven by: Mobile code, mobile agents, network computers, thin clients, mobile devices and spontaneous networking Design Challenges/Requirements Fundamental Models formal description Interaction, Failure, and Security models. Summary 45

Lecture Overview (II) Fundamental Models are concerned with a formal description of the properties that are common in all of the architectural models. All architectural models composed of processes that communicate with each other by sending messages over a computer networks. Models addressing time synchronization, message delays, failures, security issues are addressed are: Interaction Model deals with performance and the difficulty of setting of time limits in a distributed system. Failure Model specification of the faults that can be exhibited by processes Secure Model discusses possible threats to processes and communication channels. 46

Interaction Model Computation occurs within processes; The processes interact by passing messages, resulting in: Communication (information flow) Coordination (synchronization and ordering of activities) between processes. Two significant factors affecting interacting processes in a distributed system are: Communication performance is often a limiting characteristic. It is impossible to maintain a single global notion of time. 47

Interaction Model: Performance of Communication Channel The communication channel in our model are realised in a variety of ways in DSs. E.g., by implementation of: Streams Simple message passing over a network. Communication over a computer network has performance characteristics: Latency: A delay between the start of a message s transmission from one process to the beginning of receipt by another. Bandwidth: the total amount of information that can be transmitted over in a given time. Communication channels using the same network, have to share the available bandwith. Jitter The variation in the time taken to deliver a series of messages. It is vary relevant to multimedia data. 48

Interaction Model: Computer clocks and timing events Each computer in a DS has its own internal clock, which can be used by local processes to obtain the value of the current time. Therefore, two processes running on different computers cam associate timestamp with their events. However, even if two processes read their clock at the same time, their local clocks may supply different time. This is because computer clock drift from perfect time and their drift rates differ from one another. Even if the clocks on all the computers in a DS are set to the same time initially, their clocks would eventually vary quite significantly unless corrections are applied. There are several techniques to correcting time on computer clocks. For example, computers may use radio receivers to get readings from GPS (Global Positioning System) with an accuracy about 1 microsecond. 49

Interaction Model: Two variants of the interaction model In a DS it is hard to set time limits on the time taken for process execution, message delivery or clock drift. Synchronous DS hard to achieve: The time take to execute a step of a process has know lower and upper bounds. Each message transmitted over a channel is received within a known bounded time. Each process has a local clock whose drift rate from real time has known bound. Asynchronous DS: There is NO bounds on: Process execution speeds Message transmission delays Clock drift rates. 50

Interaction Model: Event Ordering In many DS applications we are interested in knowing whether an event occurred before, after, or concurrently with another event at another processes. The execution of a system can be described in terms of events and their ordering despite the lack of accurate clocks. Consider a mailing list with users X, Y, Z, and A. 51

Real-time ordering of events X send 1 m 1 receive 4 receive Y 2 receive send 3 m 2 receive Physical time Z receive receive send A m 3 m 1 m 2 receive receive receive t 1 t 2 t 3 52

Inbox of User A looks like: Item From Subject 23 Z Re: Meeting 24 X Meeting 26 Y Re: Meeting Due to independent delivery in message delivery, message may be delivered in different order. If messages m1, m2, m3 carry their time t1, t2, t3, then they can be displayed to users accordingly to their time ordering. 53

Failure Model In a DS, both processes and communication channels may fail i.e., they may depart from what is considered to be correct or desirable behavior. Types of failures: Omission Failure Arbitrary Failure Timing Failure 54

Processes and channels process p send m process q receive Outgoing message buffer Communication channel Incoming message buffe Communication channel proceduces an omission failure if it does not transport a message from p s outgoing message buffer to q s incoming message buffer. This is known as dropping messages and is generally caused by lack of buffer space at the receiver or at gateway or by a network transmission error. 55

Omission and arbitrary failures Class of failure Affects Description Fail-stop Process Process halts and remains halted. Other processes may detect this state. Crash Process Process halts and remains halted. Other processes may not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end s incoming message buffer. Send-omission Process A process completes a send,but the message is not put in its outgoing message buffer. Receive-omissionProcess A message is put in a process s incoming message Arbitrary (Byzantine) Process or channel buffer, but that process does not receive it. Process/channel exhibits arbitrary behaviour: it may send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. 56

Timing failures Class of Failure Affects Description Clock Process Process s local clock exceeds the bounds on its rate of drift from real time. Performance Process Process exceeds the bounds on the interval between two steps. Performance Channel A message s transmission takes longer than the stated bound. 57

Masking Failures It is possible to construct reliable services from components that exhibit failures. For example, multiple servers that hold replicas of data can continue to provide a service when one of them crashes. A knowledge of failure characteristics of a component can enable a new service to be designed to mask the failure of the components on which it depends: Checksums are used to mask corrupted messages. 58

Security Model The security of a DS can be achieved by securing the processes and the channels used in their interactions and by protecting the objects that they encapsulate against unauthorized access. 59

Protecting Objects: Objects and principals invocation Access rights Object Client result Server Principal (user) Network Principal (server) 60 Use access rights that define who is allowed to perform operation on a object. The sever should verify the identity of the principal (user) behind each operation and checking that they have sufficient access rights to perform the requested operation on the particular object, rejecting those who do not.

The enemy Copy of m Process p m The enemy m Communication channel Process q 61 To model security threats, we postulate an enemy that is capable of sending any process or reading/copying message between a pair of processes Threats form a potential enemy: threats to processes, threats to communication channels, and denial of service.

Defeating security threats: Secure channels Principal A Principal B Process p Secure channel Process q Encryption and authentication are use to build secure channels. Each of the processes knows the identity of the principal on whose behalf the other process is executing and can check their access rights before performing an operation. 62

Summary Most DSs are arranged accordingly to one of a variety of architectural models: Client-Server Clients and a Single Sever, Multiple Servers, Proxy Servers with Cache, Peer Model Alternative Client-Sever models driven by: Mobile code, mobile agents, network computers, thin clients, mobile devices and spontaneous networking Fundamental Models formal description Interaction, failure, and Security models. The concepts discussed in the module play an important role while architecting DS and apps. 63