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

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

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: Meeting ItemFromSubject 23ZRe: Meeting 24XMeeting 25YRe: 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 q m The enemy m’

Defeating Threats Cryptograph and shared secrets Using large numbers as secret keys Authentication User names passwords Secure channels