10-16-2006 ECEN 5053, Paradigms & Patterns, Wk 81 Paradigms & Patterns - 3 ECEN 5053 SW Eng of Distributed Systems University of Colorado, Boulder.

Slides:



Advertisements
Similar presentations
MicroKernel Pattern Presented by Sahibzada Sami ud din Kashif Khurshid.
Advertisements

Software Architecture Design Chapter 12 Part of Design Analysis Designing Concurrent, Distributed, and Real-Time Applications with UML Hassan Gomaa (2001)
Windows NT server and workstation Name: Li Shen Course: COCS541 Instructor: Mort Anvari.
Distributed Systems Major Design Issues Presented by: Christopher Hector CS8320 – Advanced Operating Systems Spring 2007 – Section 2.6 Presentation Dr.
Chapter 13 Review Questions
Threads, SMP, and Microkernels Chapter 4. Process Resource ownership - process is allocated a virtual address space to hold the process image Scheduling/execution-
Using DSVM to Implement a Distributed File System Ramon Lawrence Dept. of Computer Science
Broker Pattern Pattern-Oriented Software Architecture (POSA 1)
Definition of a Distributed System (1) A distributed system is: A collection of independent computers that appears to its users as a single coherent system.
Distributed components
Technical Architectures
ECEN5053 SW Eng of Dist Systems, Arch Des Part 3, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 3 ECEN5053 SW.
Software Engineering and Middleware: a Roadmap by Wolfgang Emmerich Ebru Dincel Sahitya Gupta.
ECEN5053 SW Eng of Dist Systems, Arch Des Part 2, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 2 ECEN5053 SW.
Paradigms for Process Interaction ECEN5053 Software Engineering of Distributed Systems University of Colorado, Boulder.
EEC-681/781 Distributed Computing Systems Lecture 3 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
ECEN5053 SW Eng of Dist Systems, Arch Des Part 4, Univ of Colorado, Boulder1 Architectural Design of Distributed Systems, Part 4 ECEN5053 SW.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
1 I/O Management in Representative Operating Systems.
Distributed Systems Architecture Presentation II Presenters Rose Kit & Turgut Tezir.
DISTRIBUTED COMPUTING
Secure Operating System Architectures Patterns
Client/Server Software Architectures Yonglei Tao.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Chapter 2 Architectural Models. Keywords Middleware Interface vs. implementation Client-server models OOP.
Technology Overview. Agenda What’s New and Better in Windows Server 2003? Why Upgrade to Windows Server 2003 ?  From Windows NT 4.0  From Windows 2000.
Introduction to distributed systems Dr. S. Indran 23 January 2004.
Introduction to DISTRIBUTED SYSTEMS Tran, Van Hoai Department of Systems & Networking Faculty of Computer Science & Engineering HCMC University of Technology.
Chapter 6 Operating System Support. This chapter describes how middleware is supported by the operating system facilities at the nodes of a distributed.
B.Ramamurthy9/19/20151 Operating Systems u Bina Ramamurthy CS421.
1 CS590L Distributed Component Architecture Yugi Lee STB #555 (816) * This presentation is designed based.
DCE (distributed computing environment) DCE (distributed computing environment)
Unit – I CLIENT / SERVER ARCHITECTURE. Unit Structure  Evolution of Client/Server Architecture  Client/Server Model  Characteristics of Client/Server.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
Chapter 2: System Models. Objectives To provide students with conceptual models to support their study of distributed systems. To motivate the study of.
Advanced Computer Networks Topic 2: Characterization of Distributed Systems.
Threads, SMP, and Microkernels Chapter 4. Process Resource ownership - process is allocated a virtual address space to hold the process image Scheduling/execution-
Advanced Design and System Patterns The Microkernel Pattern.
Introduction to CORBA University of Mazandran Science & Tecnology By : Esmaill Khanlarpour January
Kyung Hee University 1/41 Introduction Chapter 1.
CE Operating Systems Lecture 3 Overview of OS functions and structure.
SCALABLE EVOLUTION OF HIGHLY AVAILABLE SYSTEMS BY ABHISHEK ASOKAN 8/6/2004.
DISTRIBUTED COMPUTING Introduction Dr. Yingwu Zhu.
Lecture 22: Client-Server Software Engineering
Architectural pattern: Interceptor Source: POSA II pp 109 – 140POSA II Environment: developing frameworks that can be extended transparently Recurring.
NT SECURITY Introduction Security features of an operating system revolve around the principles of “Availability,” “Integrity,” and Confidentiality. For.
Oracle's Distributed Database Bora Yasa. Definition A Distributed Database is a set of databases stored on multiple computers at different locations and.
CSC 480 Software Engineering Lecture 18 Nov 6, 2002.
Distributed Information Systems. Motivation ● To understand the problems that Web services try to solve it is helpful to understand how distributed information.
CORBA1 Distributed Software Systems Any software system can be physically distributed By distributed coupling we get the following:  Improved performance.
SSE3 Hypertext concepts 1. Agenda Pioneers and evolution Hypermedia – Modern hypermedia technology – Structure domains Architectural evolution The project.
Definition of a Distributed System (1) A distributed system is: A collection of independent computers that appears to its users as a single coherent system.
A. Frank - P. Weisberg Operating Systems Structure of Operating Systems.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
COSC573 Instructor: Professor Anvari Student:Shen Zhong ID#: Summer semester,1999 Washington.D.C.
1 Distributed Processing Chapter 1 : Introduction.
Interactive/Adoptable systems
Primitive Concepts of Distributed Systems Chapter 1.
Chapter 14 Software Architecture
1 CS590L Distributed Component Architecture Yugi Lee STB #555 (816) * This presentation is prepared based.
Chapter 1 Characterization of Distributed Systems
Design Patterns-1 7 Hours.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
3. Distributed Systems – Architecture Models Part 1
#01 Client/Server Computing
Ch > 28.4.
Introduction To Distributed Systems
Operating Systems Structure
#01 Client/Server Computing
Presentation transcript:

ECEN 5053, Paradigms & Patterns, Wk 81 Paradigms & Patterns - 3 ECEN 5053 SW Eng of Distributed Systems University of Colorado, Boulder

ECEN 5053, Paradigms & Patterns, Wk 82 Token-Passing Algorithms A token is a special kind of message used to convey information synchronize access to replicated files achieve conflict resolution that is fair determine global states in distributed computations Using two tokens in opposite directions Solve distributed mutual exclusion Can bypass a failed node Can regenerate a lost token

ECEN 5053, Paradigms & Patterns, Wk 83 Benefits of Token- Passing Algorithms Easy to generalize to synchronization solutions Compared to distributed semaphores Decentralized and fair, too Token-passing requires far fewer messages

ECEN 5053, Paradigms & Patterns, Wk 84 Microkernel Pattern Found in POSA 1, pp Also found in Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems, Bruce Powel Douglass, Addison Wesley, The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

ECEN 5053, Paradigms & Patterns, Wk 85 Context & Problem Context: The development of several applications that use similar programming interfaces that build on the same core functionality. Problem: Want to develop software for an application domain that needs to cope with a broad spectrum of similar standards and technologies. Systems like operating systems and GUI’s often have a long life-span. New technologies emerge; old ones change.

ECEN 5053, Paradigms & Patterns, Wk 86 Forces Application platform must cope with continuous hw and sw evolution Application platform should be portable, extensible, and adaptable to allow easy integration of emerging technologies Applications in the domain need to support different but similar application platforms. The applications may be categorized into groups use the same functional core in different ways require the underlying application platform to emulate existing standards. Functional core  separate component with minimal memory size and services that consume as little processing as possible

ECEN 5053, Paradigms & Patterns, Wk 87 Solution Encapsulate fundamental services in a microkernel component. Internal servers contain core functionality that cannot be implemented in the microkernel without causing an unnecessary increase in size or complexity. External servers implement their own view of the underlying microkernel using mechanisms available through the interfaces of the microkernel. Every external server is a separate process that represents an application platform. A microkernel system is an application platform that integrates other application platforms. Clients communicate with ext. servers using comm facilities provided by microkernel

ECEN 5053, Paradigms & Patterns, Wk 88 CRC Cards ClassCollaborators  MicrokernelInternal server Responsibility  Provides core mechanisms  Offers communi- cation facilities  Encapsulates sys- tem dependencies  Manages and controls resources ClassCollaborators  Internal serverMicrokernel Responsibility  Implements additional services  Encapsulates some system depen- dencies Class Collaborators  External server Microkernel Responsibility Provides program- ming interfaces for its clients.

ECEN 5053, Paradigms & Patterns, Wk 89 More CRC cards Class Collaborators  Client Adapter Responsibility  Represents an application Class Collaborators  Adapter External server Microkernel Responsibility Hides system depen- dencies such as communication facilities from the client. Invokes methods of external servers on behalf of clients

ECEN 5053, Paradigms & Patterns, Wk 810 Static Relationships External Server receiveRequest dispatchRequest executeService Microkernel executeMechanism initCommunication findReceiver createHandle sendMessage callInternalServer Adapter createRequest callService Client doTask Internal Server receiveRequest executeService initializes communication sends request calls service

ECEN 5053, Paradigms & Patterns, Wk 811 Scenario I

ECEN 5053, Paradigms & Patterns, Wk 812 Scenario II

ECEN 5053, Paradigms & Patterns, Wk 813 Variant Microkernel System with indirect Client-Server connections. A Client and Server communicate with each other indirectly using the microkernel as a message backbone. All requests pass through the microkernel. Useful when security requirements force the system to control all communication between participants.

ECEN 5053, Paradigms & Patterns, Wk 814 Another Variant – Distributed Microkernel System A microkernel acts as a messaging backbone responsible for sending messages to remote machines or receiving messages from them. Every machine in the distributed system uses its own microkernel implementation. From the user’s viewpoint, the whole system appears as a single Microkernel system – distribution is transparent. A Distributed Microkernel System allows you to distribute servers and clients across a network of machines or microprocessors. The microkernels in a distributed implementation must include additional services for communicating with each other.

ECEN 5053, Paradigms & Patterns, Wk 815 Examples Windows NT and 4 others in POSA Douglass says: an RTOS is common subsystem Core set of services include create and delete a task, allocate and deallocate memory, provide task event & message queues, and schedule/execute a task set. Plus, a developer can link in additional components to provide more services. Common service components for RTOS include bus communications, file services, networking services, and middleware services. Thus an RTOS becomes usable in a much wider set of application problems from tiny, highly memory- constrained systems to systems consisting of sets of high-powered networked CPUs.

ECEN 5053, Paradigms & Patterns, Wk 816 Consequences Benefits portability flexibility and extensibility separation of policy and mechanism scalability reliability transparency Liabilities performance complexity of design and implementation.