chapter 2 architectural models. keywords middleware interface vs. implementation client-server...

27
Chapter 2 Architectural Models

Upload: hugo-dennis

Post on 25-Dec-2015

221 views

Category:

Documents


0 download

TRANSCRIPT

Chapter 2

Architectural Models

Keywords Middleware

Interface vs. implementation Client-server models OOP

Process Classification in DS Classified by responsibilities Server processes

E.g. SQL server, Web server Client processes

Web browser, SQL query analyzer Peer processes

chat

Software layers

Applications, services

Computer and network hardware

Platform

Operating system

Middleware

Platform Lowest-level hardware and

software E.g. Intel X86, Sun SPARC E.g. Windows, SunOS

Q: which one is better: multiple standards or single standard?

Middleware Mask heterogeneity/implementation Transparency Provide convenient programming

model Commonly implemented over

internet protocols TCP/IP Examples: JVM, CORBA, DCOM, RMI

Middleware Services Communication facilities Naming Distributed transactions Persistent storage

Stores persistent objects (in marshaled form), which live between activations by servers

Persistent Java, CORBA persistent object service.

Security

Middleware And Openness Protocols used by each middleware layer

should be same; Similarly for interfaces they offer to applications.

Middleware Limitations Platform independence Middleware

dependence “Some communication-related functions

can be completely and reliably implemented only with the knowledge and help of the application standing at the end points of the communication system” [Saltzer, Reed and Clarke, 1984]

Examples Transferring large files

TCP not enough Irrigating farm-land Rule: requiring help from higher-

level Q: Can mankind comprehend

itself?

Client-Server Model

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

Relationship Client/server is a process. M-to-M Servers may in turn be clients of

other servers. E.g. web server, search engines

Improvements/Variations Multiple servers

Partition jobs Maintain replicated copies

Caches Peer processes

Reduce the delay of access Eliminate the bottleneck Group communication

Mobile code, like web applets

Multiple-threads Server Warm-up: threads vs. processes Usually a server (which is a

process) has multiple threads for concurrency reason. E.g. web server

Same principle applies to client. E.g. web browser

OO Implementation Object-oriented programming

class and instance encapsulation (information hiding), inheritance

(with overriding) and polymorphism OO approach

Everything is an object Not true in C++

Modular Interaction by messages

OO benefits Encapsulation

Protection by controlled access (values and synchronization)

Information hiding (internal operations can be modified as long as interface is kept same)

Inheritance Overriding (can also add new methods and

variables) Efficient software development

Polymorphism

Method-overloading Different methods in the same class can have

same name, provided number and/or types of arguments are different for each method. Why do we need it?

class Example {public static int doubleIt (int x) {return 2*x;}public static String doubleIt (String x) {

return x + x;}}

Polymorphism Same method name means different

things, depending on object’s position in hierarchy. In Java, objects implementing same interface or extending same superclass can override method to do different things.

Separation of interface and implementation

Example: Device Driver Define interface with generic methods,

e.g., read and write. Individual device drivers override those abstract methods.

Same message sent to variety of objects would then take on different forms.

OO benefits --- Really? Difficult to achieve all the goals

Careful design, future prediction, code reuse

Design patterns, refactoring techniques Managers tend to overlook them.

Does it improve coding efficiency? Said by a survey: not much compared to

memory-management-hiding techniques

Fundamental Models of DS Interaction model Failure model Security model

Interaction Model Multiple processes

Rate and timing of message passing cannot in general be predicted.

Two significant factors Communication channel

Latency, bandwidth, jitter Computer clocks and timing events

Clock drift

Two Variants Synchronous: There is upper-bound T (sec)

on time from sending request till receiving reply On timeout one can conclude there is failure.

Asynchronous: No finite upper-bound, but guaranteed to be finite under no failure (e.g., Internet) cannot tell if network is being slow or has failed.

Comparisons.

Event Ordering User X sends a message with the

subject Meeting Users Y and Z reply with the

subject Re: MeetingItem From Subject

23 Z Re: Meeting

24 X Meeting

25 Y Re: Meeting

Seen by user A

Failure Model Omission failures

Fail to perform actions Arbitrary failures Timing failures How to mask failures?

Re-transmit message Checksum: Hamming code

Security Model Protect objects

Access rights Protect processes and their

interactions Threats to servers, clients

Communication channel

Copy of m

Process p Process qm

The enemym’

Defeating Threats Cryptograph and shared secrets

Using large numbers as secret keys Authentication

User names passwords Secure channels