Download ch14kmDistributedProcessing

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database model wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Clusterpoint wikipedia , lookup

Btrieve wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Team Foundation Server wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Transcript
Distributed Processing,
Messages, RPC, RMI, CORBA
Chapter 14
”Operating Systems”
W. Stallings
1
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
2
3
4
Client/Server Applications
• Bulk of applications software executes on the
server
• Application logic is located at the client
• Presentation services in the client
5
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
6
7
Client/Server Database Usage
8
Client/Server Database Usage
9
Classes of Client/Server
Applications
• Host-based processing
– Not really client/server computing
– Traditional mainframe environment
– Client is just a dumb display
10
Classes of Client/Server
Applications
• Server-based processing
– Server does all the processing
– Client provides a graphical user interface
– Often called a ”thin client”
11
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
12
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
13
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
14
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
15
Distributed Message Passing
• Messages are passed to communicate
among processes.
• Send and receive messages as offered
by raw network service
• OR
• remote procedure calls
16
Basic Message-Passing Primitives
17
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
18
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
19
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
20
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
21
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
22
23
24
Middleware Mechanisms
25
Middleware Mechanisms
26
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 typecheck
– Standardized interface is more portable
• Widely accepted and Standardized
– Client and server modules can be moved among
computers and operating systems easily
27
28
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
29
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.
30
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.
31
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;
32
Client/Server Binding
• The Binder interface
– Register
• Name, version, handle/address, unique id
– Deregister
• Name, version, unique id
– Lookup
• Name, version.
• Response: handle/address
33
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)
34
Middleware Mechanisms
35
Middleware Mechanisms
36
Middleware Mechanisms
37
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.
38
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
39
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=dgrlnxw03C++4services
40