1. 3. Distributed Systems – Architecture Models Part 1

2. System architecture

3. System Architecture

4. 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

5. Centralized System Architecture

6. Distributed Systems

7. Tightly Coupled and Loosely Coupled Information Systems

8. 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

9. 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

10. 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.

11. Distributed System Architecture

12. What is a Distributed System?

13. What is a Distributed System?
Hostn-1
Hostn
Host2
Host1
Middleware
Network Operating System
Hardware
Component1
Componentn
Network

14. What is a Distributed System?
A distributed system is a collection of autonomous hosts that 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.
perceive - tajuma
We employ the (adapted) definition of Colouris, Dollimore and Kindberg of a distributed system.
It 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. 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.

16. 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

17. Distributed System Requirements

18. Requirements Integration of new, legacy and components off-the-shelf
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

19. 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

20. 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.

21. 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.

22. 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

23. 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.

24. 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

25. Transparency in Distributed Systems

26. 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.

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

28. Possible transparencies in a Distributed System

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

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

31. 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

32. 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

33. 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

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

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

36. 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

37. Local versus Distributed Objects

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

39. 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.

40. 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

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

42. 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)

43. Activation/Deactivation (cont’d)
Tony:Trainer
BvB:Team
bookGoalies
object
activated
object
deactivation

44. 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

45. 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

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

47. 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?

48. 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

49. 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

50. DISTRIBUTED SYSTEM COMMUNICATION PARADIGMS and Architectural Patterns

51. Communications:
The Broker Pattern

52. Summary Description of Broker Pattern
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
Structure distributed sw systems
with decoupled components
that interact by remote service invocations
Responsible for
coordinating communication
transmitting results
transmitting exceptions
University of Colorado, Boulder

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

54. 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

55. Broker Pattern: Problem - 2
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
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.
University of Colorado, Boulder

56. Broker Pattern: Problem - 3
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
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.
University of Colorado, Boulder

57. Broker Pattern: Solution
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
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
University of Colorado, Boulder

58. Broker Pattern: Solution -- 2
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
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.
University of Colorado, Boulder

59. Broker Pattern: Solution -- 3
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
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
University of Colorado, Boulder

60. Broker Pattern: Structure
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
Broker Pattern: Structure
Participating components
Clients
Servers
Brokers
Bridges
Client-side proxies
Server-side proxies
University of Colorado, Boulder

61. Server-side Interaction
ECEN 5053 SW Eng of Distributed Systems
9/19/2006
Server-side Interaction
University of Colorado, Boulder

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