1 / 49

SYSTEM MODELS

SYSTEM MODELS. INTRODUCTION. Physical Model Describe a System Architectural Model Computational and Communication Aspects Fundamental Models Individual aspects Interaction Models Failure Models Security Models. Difficulties and Threats. Widely varying modes of use

benny
Download Presentation

SYSTEM MODELS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SYSTEM MODELS

  2. INTRODUCTION • Physical Model • Describe a System • Architectural Model • Computational and Communication Aspects • Fundamental Models • Individual aspects • Interaction Models • Failure Models • Security Models

  3. Difficulties and Threats • Widely varying modes of use • Variation of workloads • Wide range of system environments • Heterogeneity • Internal Problems • Clocks, data updates, component failures • External Threats • Integrity, Confidentiality, DOS

  4. PHYSICAL MODELS Three generations • Early Distributed Systems • 1970, 80 • 10 to 100 nodes • Small range of services • Largely homogeneous • Quality of Service was infancy

  5. PHYSICAL MODELS • Internet-Scale Distributed Systems • 1990 • Internet • Truly Global • Largely Heterogeneous • Open Standards • Quality of Service (End to End)

  6. PHYSICAL MODELS • Contemporary Distributed Systems • Above are relatively static • Discrete systems • Autonomous • Mobile Computing • Service discovery, spontaneous interoperation • Ubiquitous Computing • Cloud Computing • Distributed System of Systems

  7. PHYSICAL MODELS

  8. ARCHITECTURAL MODELS • Components and their interrelationships • Goal to meet present and likely future demands • Major concerns are to make the system reliable, manageable, adaptable and cost-effective. Three-Stage Approach • Architectural elements • Architectural patterns • Middleware platforms

  9. Architectural elements Four key Issues • Communicating Entities • What are the entities that are communicating in the distributed system? • Communication Paradigm • How do they communicate • Roles and Responsibilities • Placement • How are they mapped on to the physical distributed infrastructure

  10. Architectural elements Communicating entities • System-oriented and a problem-oriented perspective • System perspective • Processes • Nodes in Primitive environments like sensor networks • processes are supplemented by threads in most distributed systems

  11. Architectural elements Communicating entities • Programming perspective – Problem Oriented Abstraction • Objects • OOD and OOP • Interacting Objects • Objects accessible via interfaces IDL • Components • Resemble Objects • Make all dependencies explicit and provide complete contract for system construction.

  12. Architectural elements Communicating entities • Web services • Web standards • www - Web services • A software application identified by a URL, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A web service supports direct interaction with other software agents using XML-based message exchanges via internet-based protocols.

  13. Architectural elements Communicating Paradigms • Inter-process communication • Remote invocation • Indirect communication • Inter process communication • Low level support for communication in ds • Socket programming • Support for multicast communication

  14. Architectural elements Communicating Paradigms • Remote invocation • Most common in ds • Request – reply protocols • Client server computing • Most used in embedded systems • Remote procedure calls • Remote procedures as if they are in local address space • Provides access and location transparency • Service interface for clients to call

  15. Architectural elements Communicating Paradigms • Indirect communication • Space uncoupling • Time uncoupling • Group communication • Set of recipients • Abstraction of group by group identifier • Maintaining membership and deal with failure of group members • Publish – subscribe systems • Large publishers or producers – distribute items of interest and large number of subscribers • Distributed event based system • Ensures information reach subscribers

  16. Architectural elements Communicating Paradigms • Message queues • Offers point to point • Producer to a specified queue – consumer receive from queue • Notification of new message • Tuple space • Persistent Tuple space • Processes place tuples in tuple space • Other processes either read or remove by specifying patterns of interest • Known generative communication for parallel programming

  17. Architectural elements Roles and responsibilities • Client- server • Client interact with individual server • Access shared resources • Servers may be clients of other system • Webserver – dns • Search engines – web crawlers

  18. Architectural elements Roles and responsibilities • Peer–to–peer • No distinction • Offer same set of interfaces to each other • Aim is to exploit resources in large number of computers for fulfillment of task • Large no of data objects are shared. • A individual holds only a small part and distributed across. • More complex than client server

  19. Architectural elements Placement • Patterns of comm, reliability of machines, load, quality. • Needs strong application knowledge • Strategies • Mapping of services to multiple servers • Caching • Mobile code • Mobile agents

  20. Architectural elements Placement • Mapping of services to multiple servers • Several servers on multiple machines • May replica complete service • Partition and distribute • Caching • Recently used • Client or close to client • Browsers, proxies

  21. Architectural elements Placement • Mobile code • Applets • Good interactive response • Push service • Security threat • Mobile agents • Running program travels from one system to another to carry out task. • Xerox PARC 1982 • Threat as well as vulnerable

  22. Architectural Patterns Architectural patterns build on the more primitive architectural elements Layering • Partitioning of Complex system • Offers a software abstraction • In DIS this equates to a vertical organization of services into service layers. • Platform and Middleware

  23. Architectural Patterns Tiered architecture Functional decomposition of an application • The Presentation logic • The Application logic/Business Logic • The Data logic • Two-tier Solution • the three aspects must be partitioned into two processes, the client and the server by splitting the application logic, with some in the client and the remainder in the server

  24. Architectural Patterns Tiered architecture • Two-tier Solution • Advantage • low latency in terms of interaction, with only one exchange of messages • Disadvantage • splitting of application logic across a process boundary, with the consequent restriction on which parts of the logic can be directly invoked from which other part

  25. Architectural Patterns

  26. Architectural Patterns • Three-tier Solution • one-to-one mapping from logical elements to physical servers • Each tier has a well-defined role. • Disadvantage • Added complexity of managing three servers and also the added network traffic and latency associated with each operation.

  27. Architectural Patterns

  28. Architectural Patterns • Standard web style of interaction • Javascript, a cross-platform and cross-browser programming language • AJAX (Asynchronous Javascript And XML) • XmlHttpRequest object • Ajax.Request • Two-tier application • Score • Three-tier application • Google Maps application

  29. Architectural Patterns • Thin Clients • a software layer that supports a window-based user interface • virtual network computing (VNC). • VNC client (or viewer) interacts with a VNC server through a VNC protocol • RealVNC • Adventiq • Transmission of keyboard, video and mouse events over IP.

  30. Architectural Patterns • Other commonly occurring patterns • Proxy • a proxy is created in the local address space to represent the remote object • brokerage in web services • trio of service provider, service requester and service broker

  31. Associated Middleware Solutions

  32. Fundamental Models • Formal description of the properties that are common in all of the architectural models. • All architectural models are 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: • 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 • Security Model – discusses possible threats to processes and communication channels.

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

  34. Interaction Model: Performance of Communication Channel • The communication channel in our model is 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 reception 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 bandwidth. • Jitter • The variation in the time taken to deliver a series of messages. It is very relevant to multimedia data.

  35. 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 can associate timestamp with their events. • However, even if two processes read their clocks at the same time, their local clocks may supply different time. • This is because computer clock drifts 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 correct 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.

  36. 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 taken to execute a step of a process has known 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.

  37. 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 other 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.

  38. Real-time ordering of events

  39. Inbox of User A looks like: • 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.

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

  41. Processes and channels • Communication channel produces 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 a lack of buffer space at the receiver or at gateway or by a network transmission error.

  42. 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-omission Process A message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may (Byzantine) channel send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. Omission and arbitrary failures

  43. 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. Timing failures

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

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

  46. Protecting Objects: Objects and principals • Use “access rights” that define who is allowed to perform operation on a object. • The server 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.

  47. m Copy of The enemy m’ p m Process q Process Communication channel The enemy • 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.

  48. Defeating security threats: Secure channels • 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. B Principal A Principal p Process Secure channel Process q

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

More Related