Transcript No Slide Title

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.