1

Distributed Processing, Messages, RPC, RMI, CORBA

Chapter 14

”Operating Systems”

W. Stallings

2

Client/Server Terminology• Applications Programming Interface (API)

– A set of function and call programs that allow clients and servers to intercommunicate• Client

– A networked information requester, usually a PC or workstation, that can query database and/or other information from a server

• Middleware– A set of drivers, APIs, or other software that improves connectivity between a client

application and a server• Relational Database

– A database in which information access is limited to the selection of rows that satisfy all search criteria

• Server– A computer, usually a high-powered workstation, a minicomputer, or a mainframe, that

houses information for manipulation by networked clients• Structured Query Language (SQL)

– A language developed by IBM and standardized by ANSI for addressing, creating, updating, or querying relational databases

3

4

5

Client/Server Applications

• Bulk of applications software executes on the server

• Application logic is located at the client

• Presentation services in the client

6

Database Applications

• The server is a database server

• Interaction between client and server is in the form of transactions– the client makes a database request and receives a

database response

• Server is responsible for maintaining the database

7

8

Client/Server Database Usage

9

Client/Server Database Usage

10

Classes of Client/Server Applications

• Host-based processing– Not really client/server computing– Traditional mainframe environment– Client is just a dumb display

11

Classes of Client/Server Applications

• Server-based processing– Server does all the processing– Client provides a graphical user interface– Often called a ”thin client”

12

Classes of Client/Server Applications

• Client-based processing– All processing done at the client, “fat client”

– Data validation routines and other database logic functions are done at the server

– Need more network capacity

13

Classes of Client/Server Applications

• Cooperative processing– Both server and client handle processing

– Use strength of both server and client

– Complex to set up and maintain

14

Three-Tier Client/Server Architecture

• Application software distributed among three types of machines

– User machine• Thin client

– Middle-tier server• Gateway• Convert protocols• Merge/integrate results

from different data sources

– Backend server

15

File Cache Consistency

• File caches hold recently accessed file records to help network performance

• Multiple clients should have the same view of the file (cache consistency)

• Problems if one or more modify it• If one client using file, no problem – client can cache file, send data to

server later• Can lock portions of the file• Can tell other readers not to cache the file, writer sends all updates to

server

• File-locking prevents simultaneous access to a file, but degrades performance

16

Distributed Message Passing

• Messages are passed to communicate among processes.

• Send and receive messages as offered by raw network service

• OR

• remote procedure calls

17

Basic Message-Passing Primitives

18

Basic Message-Passing Primitives

• Used to implement client/server functions

• Send() – Send message– Give contents and destination– Use network protocol (such as TCP/IP) to

send it to the target system

• Receive() – Get a message– Give buffer and (optional) sender

19

Reliability Versus Unreliability

• Reliable: message-passing guarantees delivery if possible– Report to the sending process if message was

delivered or not (after retries)

• Unreliable: send the message into the communication network without reporting success or failure– Reduces complexity and overhead– Problem is left to the application

20

Blocking Versus Nonblocking

• Blocking– Send does not return control to the sending process until the

message has been transmitted (unreliable)– OR does not return control until an acknowledgment is

received (reliable)– Receive does not return until a message has been placed in

the allocated buffer

• Nonblocking– Process is not suspended as a result of issuing a Send or

Receive– Efficient and flexible as process can continue– Difficult to debug

21

Message Passing vs. Middleware

• But: Message passing introduces new problems and skills for an application programmer.– If you want to write distributed programs you must learn to

program network primitives send() and reveive()– Is the message sent? Is the message received? What if…?

• Hard to find programmers that understands both the application (business) and the network manipulation including pitfalls and solutions.– Expensive people

• Isolate application logic from network programming.– Less expensive project

22

Middleware

• Customers tend to focus on what applications they want, not servers

• Helps provide a standard interface to multivendor configurations– Client can decide on a middleware package, see who

supports it

• Helps make portable applications– Also may combine server information

• Adds another layer to the system• Example: SQL for database use

– Many vendors support SQL queries

23

24

25

Middleware Mechanisms

26

Middleware Mechanisms

27

Remote Procedure Calls

• Allow programs on different machines to interact using simple procedure call/return semantics

• Reasons:– Procedure call widely understood– Remote interfaces can be represented as named

operations with designated types – compiler can type-check

– Standardized interface is more portable

• Widely accepted and Standardized– Client and server modules can be moved among

computers and operating systems easily

28

29

Remote Procedure Calls

• Sample Syntax:– Proc_name(Send_Args,Recv_Args)

• Arguments usually passed by value

• Parameter Representation– Number/String formats may differ– Send values across network in a standard

form– Each node converts to/from local form

30

Client/Server Binding

• How does a client locate a server?• Fixed binding

– “hardcode” the server address in the client code

• Inflexible! What if server is moved?• Find and recompile programs! Unpractical.

• Dynamic binding– Introduce a “binder” that will handle

addressing information.

31

Client/Server Binding

• Dynamic binding– Introduce a “binder” that will handle addressing

information.– Client only has to know address of the binder.– Server intitialisation exports the server interface.

Registration: (server name, version, procedures, parameters, handle/address)

– Client stub will contact the binder and ask for the server info, import the info and handle/address.

• Now client can send message to server• Server can change location without problems.

32

Server interface example#include <header.h>

specification of abc_server, version 2.3;

long read(in char name[SIZE], out char[BUF_SIZE],

in long bytes; in long position);

long write(in char name[SIZE], in char[BUF_SIZE],

in long bytes; in long position);

int create(in char[SIZE], in int mode);

int delete(in char[SIZE]);

end;

33

Client/Server Binding

• The Binder interface– Register

• Name, version, handle/address, unique id

– Deregister• Name, version, unique id

– Lookup• Name, version.• Response: handle/address

34

Object-Oriented Mechanisms

• Clients and servers ship messages back and forth between objects

• A client sends a request to an object broker

• The broker calls the appropriate object and passes along any relevant data

• Common Object Request Broker Architecture (CORBA)

• Microsoft’s Component Object Model (COM)

35

Middleware Mechanisms

36

Middleware Mechanisms

37

Middleware Mechanisms

38

Object-Oriented Mechanisms• OMG (Object Mgmt Group) is defining the CORBA

standard. OMG is a group of companies.

• The object interface (methods and parametars) is defined by IDL (Interface Definition Language) specified in the CORBA standard.

• CORBA also defines the protocol of communications between the client, server and broker, the IIOP (Internet Inter-ORB Protocol). Among other things, how to register, deregister, lookup,…

• Java RMI also like to use IIOP.

39

OK, what now?• Coding smaller distributed application that will not be

moved or redesigned much. Sockets and send/receive.

• Coding larger distributed application that may be moved, changed into similar application for next situation. – Use RPC if coding C/C++– Use RMI if using Java

• Coding large distributed systems, that need large flexibitity, location movement, programming language interoperability (Java, C++,Cobol,..), survive system generations.– Select ”good” CORBA tool

40

OK, what now?• More on CORBA

– http://java.sun.com/developer/onlineTraining/corba/corba.html– http://java.sun.com/j2se/1.5.0/docs/guide/idl/index.html

• Java coding examples– See the contact.tar.gz that contains – CORBA server and client in Java– RMI server and client in Java– README.1st contain instructions for usage

• RPC info/examples– http://www.cprogramming.com/tutorial/rpc/remote_procedure_call_start.html– http://www.cprogramming.com/– http://www.codeproject.com/internet/rpcintro1.asp– http://www-128.ibm.com/developerworks/webservices/library/ws-xml-rpc/?ca=dgr-

lnxw03C++4services