3 Distributed Systems Architecture Models Part 1 SYSTEM

3. Distributed Systems – Architecture Models Part 1

SYSTEM ARCHITECTURE 2

System Architecture 3

Centralized System Architecture Centralized systems: Data, Process and Interface components of an information system are central. Users interact with the system via terminals or terminal emulators. – A single computer with one ore more CPUs processes all incoming request – Problems with cost, reliability – Specification and implementation are defined within a single system

Centralized System Architecture

DISTRIBUTED SYSTEMS 6

Tightly Coupled and Loosely Coupled Information Systems 7

Based on Level of Coupling : Tightly Coupled Systems Processors share a common memory Run on a single OS Communicate very frequently Usually connected through high speed connection methods • Also called parallel computing • • 8

Based on Level of Coupling : Loosely Coupled Systems Each processor has its own memory Runs its own OS Do not communicate frequently Can be placed in geographically separate regions • Also called distributed computing • • 9

Distributed System Architecture Distributed System: Data, Process, and Interface components of an information system are distributed to multiple locations in a computer network. Accordingly, the processing workload is distributed across the network. – Set of separate computers that are capable of autonomous operation, link by a computer network. – Enable individual computers (different location) to share resources in the network – Server implementation for the same interface located in different servers.

Distributed System Architecture

What is a Distributed System?

What is a Distributed System? Component 1 Componentn Middleware Network Operating System Hardware Hostn-1 Host 2 Component 1 Componentn Middleware Network Operating System Hardware Host 1 Network Component 1 Componentn Middleware Network Operating System Hardware Hostn 13

What is a Distributed System? • A distributed system is a collection of autonomous hosts that are connected through a computer network. • Each host executes components and operates a distribution middleware, which enables the components to coordinate their activities in such a way that users perceive the system as a single, integrated computing facility. 14

Distributed System • Distributed system - requires autonomous computers to be interconnected through a network. • Each computer has to be equipped with distributed operating system software, which enables the computers to coordinate activities and to share resources in a controlled way. • We also require transparency of distribution for the computer users. – They shall not have to be aware of the fact that the system is distributed. 15

Advantages of DSA • Companies are preferring their system decentralized and distributed, because Distributed System allows companies to have better customer services. – Shareability: Allows systems to use each other’s resources – Expandability: Permits new systems to be added as members of the overall system – Local Autonomy: Manage local resources – Improved performance: Resource replication. Combined processing power of multiple computers provides much more processing power than a centralised system with multiple CPUs – Improved reliability and availability: Disruption would not stop the whole system from providing its services as resources spread across multiple computers – Potential cost reductions

Distributed System Requirements

Requirements • Integration of new, legacy and components off-theshelf – Legacy components might not need to be re-engineered – COTS cannot be modified • Heterogeneity of – – hardware platforms operating systems networks programming languages • Construction of distributed systems 18

Common Requirements • What are we trying to achieve when we construct a distributed system? • Certain requirements are common to many distributed systems – – – Resource Sharing Openness Concurrency Scalability Fault Tolerance Transparency 19

Resource Sharing • Ability to use any hardware, software or data anywhere in the system. • Resource manager controls access, provides naming scheme and controls concurrency. • Resource sharing model (e. g. client/ server or object -based) describing how – resources are provided, – they are used and – provider and user interact with each other. 20

Openness • Openness is concerned with extensions and improvements of distributed systems. • Detailed interfaces of components need to be published. • New components have to be integrated with existing components. • Differences in data representation of interface types on different processors (of different vendors) have to be resolved. 21

Concurrency • Components in distributed systems are executed in concurrent processes. • Components access and update shared resources (e. g. variables, databases, device drivers). • Integrity of the system may be violated if concurrent updates are not coordinated. – Lost updates – Inconsistent analysis 22

Scalability • Adaption of distributed systems to – accomodate more users – respond faster • Usually done by adding more and/or faster processors. • Components should not need to be changed when scale of a system increases. 23

Fault Tolerance • Hardware, software and networks fail • Distributed systems must maintain availability even at low levels of hardware/software/network reliability. • Fault tolerance is achieved by – recovery – redundancy 24

Transparency in Distributed Systems

Transparency • Distributed systems should be perceived by users and application programmers as a whole rather than as a collection of cooperating components. • Transparency has different dimensions that were identified by ANSA. • These represent various properties that distributed systems should have. 26

Distribution Transparency Scalability Transparency Performance Transparency Failure Transparency Migration Transparency Replication Transparency Concurrency Transparency Access Transparency Location Transparency 27

Possible transparencies in a Distributed System 28

Access Transparency • Enables local and remote information objects to be accessed using identical operations. • Example: SQL Queries 29

Location Transparency • Enables information objects to be accessed without knowledge of their location. • Example: Pages in the Web • Example: Tables in distributed databases 30

Concurrency Transparency • Enables serveral processes to operate concurrently using shared information objects without interference between them. • Example: Automatic teller machine network • Example: Database management system 31

Replication Transparency • Enables multiple instances of information objects to be used to increase reliability and performance without knowledge of the replicas by users or application programs • Example: Distributed DBMS 32

Failure Transparency • Enables the concealment of faults • Allows users and applications to complete their tasks despite the failure of other components. • Example: Database Management System 33

Migration Transparency • Allows the movement of information objects within a system without affecting the operations of users or application programs • Example: Web Pages 34

Performance Transparency • Allows the system to be reconfigured to improve performance as loads vary. • Example: Load balancing. 35

Scaling Transparency • Allows the system and applications to expand in scale without change to the system structure or the application algortithms. • Example: World-Wide-Web • Example: Distributed Database 36

Local versus Distributed Objects

Local vs. Distributed Objects • • References Activation/Deactivation Migration Persistence Latency of Requests Concurrency Communication Security 38

Object Lifecycle • Objects reside in one virtual machine. • Distributed objects might be created on a different machine. • Distributed objects might be copied or moved (migrated) from one machine to another. • Lifecycle needs attention during the design of distributed objects. 39

Object References • References to objects are usually pointers to memory addresses – sometimes pointers can be turned into references (C++) – sometimes they cannot (Smalltalk, Java) • References to distributed objects are more complex – Location information – Security information – References to object types è References to distributed objects are bigger 40

Latency of Requests • Performing a local method call requires a couple of hundred nanoseconds. • An object request requires between 0. 1 and 10 milliseconds. q Interfaces of distributed objects need to be designed in a way that – operations perform coarse-grained tasks – do not have to be requested frequently 41

Activation/Deactivation • Objects are in virtual memory between creation and destruction. • This might be inappropriate for distributed objects – objects might not be used for a long time – some hosts might have to be shut down without stopping all applications • Distributed object implementations are – brought into main memory (activation) – discarded from main memory (deactivation) 42

Activation/Deactivation (cont’d) Tony: Trainer Bv. B: Team book. Goalies object activated object deactivation 43

Activation/Deactivation (cont’d) • Several questions arise – – – Repository for implementations Association between objects and processes Explicit vs. implicit activation When to deactivate objects How to treat concurrent requests • Who decides answers to these questions? – Designer – Programmer – Administrator 44

Persistence • Stateless vs. statefull objects • Statefull objects have to save their state between – object deactivation and – object activation onto persistent storage • Can be achieved by – externalization into file system – mapping to relational database – object database • To be considered during object design 45

Parallelism • Execution of objects is often – sequential – concurrent (with multi-threading) • Distributed objects execute in parallel • Can be used to accelerate computations 46

Communication • Method invocations of objects are synchronous • Alternatives for distributed objects: – synchronous requests – asynchronous requests • Who decides on request – Designer of server? – Designer of client? 47

Failures • Distributed object requests are more likely to fail than local method calls • Different request reliabilities are available for distributed objects • Clients have an obligation to validate that servers have executed request 48

Security • Objects do not have to be written in a particular way. • For distributed objects: – Who is requesting an operation execution? – How can we know that subject is who it claims to be? – How do we decide whether or not to grant that subject the right to execute the service? – How can we prove that we have delivered a service so as to make the requester pay 49

DISTRIBUTED SYSTEM COMMUNICATION PARADIGMS AND ARCHITECTURAL PATTERNS

Communications: The Broker Pattern 51

Summary Description of Broker Pattern • Structure distributed sw systems – with decoupled components – that interact by remote service invocations • Responsible for – coordinating communication – transmitting results – transmitting exceptions 52

Broker Pattern: Context “Your environment is a distributed and possibly heterogeneous system with independent cooperating components. ” 53

Broker Pattern: Problem • Build a complex sw system as a set of decoupled, interoperating components rather than a monolith. – Greater flexibility, maintainability, changeability – Partitioning into independent components makes system distributable and scalable. • Require a means of inter-process communication – If components themselves handle communication, result has several dependencies and limitations • System depends on which comm mechanism used • Clients need to know location of servers 54

Broker Pattern: Problem - 2 • Need services for adding, removing, exchanging, activating, and locating components – Must not depend on system-specific details to guarantee portability and interoperability • An object that uses an object should only see the interface offered by the object – know nothing about implementation. 55

Broker Pattern: Problem - 3 Broker pattern balances the following forces • Components access others’ services via remote, location-transparent service invocations. • Need to exchange, add, or remove components at run-time • Architecture should hide system-specific and implementation-specific details from users of components and services. 56

Broker Pattern: Solution • Introduce a broker component to achieve better decoupling of clients and servers – Servers: register themselves with the broker and make their services available to clients through method interfaces. – Clients: access the functionality of servers by sending requests via the broker • A broker’s tasks: – Locating the appropriate server and forwarding a request to that server – Transmitting results and exceptions back to the client 57

Broker Pattern: Solution -- 2 • Reduces the complexity involved in developing distributed applications. – Introduces object model where distributed services are encapsulated within objects. • Broker systems offer a path to the integration of two core technologies: – Distribution – Object technology • Extend object models from single applications to dist’d applications made of decoupled components that can – run on heterogeneous machines and – written in different programming languages. 58

Broker Pattern: Solution -- 3 • Application accesses distributed services by sending message calls to the appropriate object. – Does not need to focus on low-level inter-process communication. • Broker architecture is flexible – Allows dynamic change, addition, deletion, and relocation 59

Broker Pattern: Structure • Participating components – Clients – Servers – Brokers – Bridges – Client-side proxies – Server-side proxies 60

Server-side Interaction 61

Client. Server Interaction via Broker 9/19/2006 62