Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Lecture 2: Architectural System Models Part 1 – Architectural Models: An architectural model defines each component of a system and describes how the components work. It also specifies how the components interact with one another, and how they fit together to produce the system. We will be studying “fundamental models” in our next class. At this point, we will use an analogy to illustrate the nature of each of these models and then relate the notion of an architectural model to the concept of distributed computing. Fundamental models versus Architectural models Analogy: A description of a motor We will consider these two models applied to to different kinds of motors: Electric Motor Gas Engine Fundamental models: A fundamental model describes in abstraction the characteristics and behavior of the system • the device consumes some source of energy • the device converts energy into mechanical motion • the efficiency of the device is the ratio between the energy consumed and the mechanical energy produced These fundamental characteristics hold for both motors. Architectural models: An architectural model describes what parts comprise the motor and how each part works and how the parts work together The architectural model for a Gas Engine Parts: • fuel tank • pistons • cylinders • crankshaft • sparkplugs Fuel tank: • a metal container • holds fuel (energy source) • supplies fuel to engine Sparkplugs: • ceramic object with conductive core and threaded end • has spark gap electrodes • creates spark to ignite gasoline in cylinder Cylinders: • cylindrical metal guide • contain explosion of gas • guides pistons as they move under explosion Crankshaft: • hardened shaped metal shaft • forced to rotate under pressure from pistons The architectural model of an Electric Motor Parts: • Battery • Rotor • Stator • Windings Battery: • Made of liquid chemicals and plastics • Holds electrical energy and supplies to motor Windings: • Long copper wire wound circularly with many turns • Wound around stator and rotor • Electrical current passes through windings • Windings produce a magnetic field Stator: • Heavy iron frame with windings • Creates magnetic field Rotor: • Heavy iron core with windings wound around it • Experiences magnetic pressure from windings • Forced to rotate under magnetic pressure • The parts differ • The principles of operation differ BUT • The basic input requirements and output results don’t. For these two things, the architectural models differ, but the fundamental model remains the same. Part 2 – Layered Approach: The software and hardware that exists in a distributed operating system is typically divided up into three layers. The lowest layer is where the hardware exists. This includes a particular type of computer and a particular type of network. Together, in combination with the lowest software layer, the operating system, these layers form what is known as the “platform” layer. The platform is then a compound layer. At the highest layer, we find the distributed application or service in question. A “middleware” layer sits between the highest layer and the platform, and represents a platform and application independent interface via which the two may communicate. We will discuss a diagram that depicts this relationship, and elaborate on the function of the middleware layer. Software/Hardware Layers Application/Service Middleware Operating System Hardware (Computer and Network) “platform” Application/Service Middleware Operating System Hardware (Computer and Network) Middleware: •Standard collection of procedures •Not tied to a particular OS •Independent of a particular network •Not tied to a particular application or service ? How can this be? It has to interact between the layer above and below! The “middle” of the middleware layer is where the independency exists. Middleware then defines the form of communication between the platform and application layers. It can’t define the interaction between middleware and each layer since that’s application/service specific here and platform dependent here Application/Service Middleware Operating System Hardware “platform” But what goes on “inside” of the layer to get from here to here can be independent of the “junction between layers” An analogy: Suppose we wish to communicate an idea between two people: • Service: an idea to be conveyed (perhaps a greeting) • Middleware: the English Language • Operating System: the way the brain functions to process ideas, to move muscles and process incoming sounds • Hardware: • Computing agent: brain • Network: - Hardware: lips, tongue, lungs - Media: air - Signaling method: sound waves In a way, Middleware is not really software, but rather a philosophy or protocol or paradigm for distributed computing. The software occurs in the junctions between middleware and the layer above and below. For example, if CORBA is used, the platform will have a piece of software to support it, and the application or service will have a piece of software to support it. With these two pieces of software, the two layers can communicate using CORBA as middleware. Examples of Middleware: • CORBA: Common Object Request Broker Architecture • Sun RPC: Remote Procedure Call • Java RMI: Remote Method Invocation • RM-ODP: Reference Model for Open Distributed Processing • DCOM: soft’s Distributed Common Object Module Part 3 – System Architectures: We will now discuss a number of different models for the system architecture of a distributed system. Specifically, we will look at nine different architectures used for distributed computing and discuss the issues of significance for each of these models. Architectural models of distributed computing capture the interactions between processes that request services (clients, client processes) and processes that provide services (servers, server processes) Messages are passed between server and client to orchestrate this, namely: A message from client to server i) “requests” or “invocations” and ii) “replies” or “results” A message from server to client Client-Server model: Client invocation result invocation Server result Client Key: Process: Computer: • most typical model • a server process could be a client process as viewed from another server process Server Services via Multiple Servers: Server Client Service Server Client Server “replication” • improves performance • provides fault tolerance Proxy Servers and Caches: Web server Client Proxy server Client Web server • Makes requests on behalf of its clients • Looks like a client to the server • Looks like a server to its client • Caches or stores results obtained from servers (replies) • If other clients make same request, it replies on behalf of the server!!! SO: A caching proxy not only acts as a proxy for its clients, but may sometimes act as a proxy for the servers they wish to access. Peer Processes: Application Whiteboard Coordination code Application Whiteboard Coordination code Application Whiteboard Coordination code Client and server become blurred, acting in both roles as equal participants. In this whiteboard example, all activity from any participant must be passed on to all other participants. Mobile Code: i) client request results in the downloading of applet code Client Applet code Web server ii) client interacts with the applet Client Applet Web server In this example of a “Java Applet,” executable code sent to client from server is executed on the client. In this case, it has the interesting property that it is not tied to any OS/Hardware (i.e. platform) Mobile Agents: Running code that migrates from computer to computer • How can we ensure platform transparency? Use java (java virtual machine) otherwise would be platform specific • Code plus data (including all variables) • Current state of process (including current activation record and current point of execution) • Possibly state of any resources in use?? (would need to do this in new client) Networked computers: • Most traditional model • Might also be a diskless client • Disk (if present) will hold a minimum of software • Data and possibly code, will be loaded from a remote file server • Allows central maintenance of programs and data (on file server) • Ex: network boot ROM of floppy boot, or small hard drive • All applications run on the local client Thin Clients: Compute server Network computer or PC Thin Client network Application Process Supports a windows based interface which runs on the local client the actual applications run on a remote server (compute server) • X11 is a good traditional example • Windows based versions are more typically associated with the term Mobile Devices and Spontaneous Networking: • From watches to washing machines • Informal “come & go” approach to participating in a network • A “discovery” service to announces available services to clients • Probably wireless or wired by power chord • Complicated by intermittent nature of wireless computing • Security and privacy issues arise • Requirement to “register” services that the client can offer (these will be registered in the discovery service) Mobile Devices and Spontaneous Networking: Music service gateway Alarm service Internet Hotel wireless Network Discovery service Camera TV/PC Laptop PDA Guests devices Part 4 – Objects and Interfaces: The term “interface” describes the collection of procedures available to deal with a service. In the context of object oriented programming, services may be treated as objects and the interface procedures are then viewed as methods of the object. In many paradigms for dealing with distributed computing, object oriented programming becomes important. We will elaborate on this further in class. Objects and Interfaces: • Networking resources may be thought of as “objects” with methods that may be invoked to initiate different operations and send requests and receive replies. RMI-Remote Method Invocation Ex: FileServer MyFileServer; … MyFileServer.Connect(“Eagle”); MyFileServer.Login(MyUsername,MyPass); … MyFileServer.Logout(); Part 5 – Applications: The material we have studied will now be reviewed in by discussing it in the context of some applications and by comparing and contrasting some of the concepts presented above. Exercise: Consider the client-server architecture involved in web browsing. HTTP DNS Server DNS Web Server Browser Proxy Server DNS Server DNS Browser HTTP Proxy Server HTTP Web Server • Browsers are clients of Web servers (HTTP) • Browsers are also clients of DNS servers (DNS) • Proxy servers on server side provide security and distribute the load • Proxy servers on client side reduce delays and traffic • DNS servers and clients are generally always involved Question: In the above, how do the servers cooperate in providing web content? Answer: • Web Servers and Proxy Servers cooperate with each other • This minimizes network traffic • Latency for the clients is reduced as a result • Throughput also increases for the client • Proxy Servers take responsibility for ensuring current content Question: What are some applications of the Peer Process model, and what level of consistency do these applications demand? Answer: Cooperative work applications (Groupware), like those below, all require that the processes participating in their use cooperate as peer to peer process. • Whiteboards • Chat utilities These demand high levels of consistency i.e. each instance of the application must remain current and in synchonization with the others. • Shared document editing facilities This application demands less consistency. For example, one user might “lock” part of a document while editing making it inaccessible until the edits are completed. Question: What sorts of security risks exist when an untrusted program is downloaded from a remote machine and run locally? Answer: • Files and Directories can be read, written, created, modified, or deleted using the rights of the local user and without their knowledge. • The program can create and use network sockets. • Printers can be accessed that the outside user shouldn’t access. • The local user might be impersonated in various ways such as sending email on their behalf without their knowledge.