View
225
Download
1
Category
Preview:
Citation preview
OUTLINE
1. Conceptual Framework
2. RPCs
3. CORBA Object Model
4. CORBA Remote Invocation
5. Comparison
6. Summary
2
1 CONCEPTUAL FRAMEWORK
Architecture.
Accessing components from programming languages.
Interfaces to lower layers.
Component identification (to achieve location transparency).
Service invocation styles.
Handling of failures.
3
2 REMOTE PROCEDURE CALLS
Overview of RPC architecture.
Generation of client/server stubs.
RPC interface.
Binding.
Handling of remote procedures.
Failures of RPCs.
5
2.1 RPC ARCHITECTURE
Client Server
Network
Local Call
ClientStub
RPCInterface
RPCInterface
ServerStub
RemoteProcedure
send receive send receive
6
2.2 THE RPC LANGUAGE Definition of types (similar to C). Component is described as a PROGRAM. PROGRAM has an identification and a version number. PROGRAM exports procedures
Procedures have a result type and a parameter list, Procedure can be called from remote components, Call can be defined statically or dynamically.
7
2.2 THE RPC LANGUAGE (EXAMPLE)/* person.x */const NL=64;enum sex_type { FEMALE = 1,MALE = 2 };struct Person { string first_name<NL>; string last_name<NL>; sex_type sex; string city<NL>; };
program PERSONPROG { version PERSONVERS { void PRINT(Person)=0; int STORE(Person)=1; Person LOAD(int)=2; } = 0;} = 105040;
8
2.2 GENERATION OF STUBS
rpcgen
person.x
client.c server.c
C Compiler, Linker C Compiler, Linker
person.h
person_clnt.c person_svc.c
person_xdr.c
Client Serverincludesgeneratesreads
librpc.a
9
2.2 IMPLEMENTATION OF SERVER
/* server.c */void * print_0(Person *argp, struct svc_req * rqstp){ static char * result; printf("%s %s\n%s\n\n", argp->first_name, argp->last_name, argp->city); return((void *) &result);}
10
2.2 USE OF STUBS
/* client.c */
print_person(char * host, Person * pers) {
...
if (print_0(pers, clnt)==NULL)
/* call failed /*
...
}
11
2.3 RPC INTERFACE
Used by client or server directly: Locating servers. Choosing a transport protocol. Authentication and security. Invoking RPCs dynamically.
Used by stubs for: Generating unique message IDs. Sending messages. Maintaining message history.
12
2.3 RPC INTERFACEprint_person(char * host, Person * pers) { CLIENT *clnt; clnt = clnt_create(host, PERSONPROG, PERSONVERS, "udp"); if (clnt == (CLIENT *) NULL) { exit(1); } if (print_0(pers, clnt)==NULL) clnt_perror(clnt, "call failed"); clnt_destroy(clnt);}
13
2.4 BINDING
How to locate an RPC server that can execute a given procedure in a network?
Can be done statically (i.e. at compile-time) or dynamically (i.e. at run-time).
Dynamic binding is supported by portmap daemons.
14
2.5 HANDLING OF REMOTE PROCEDURES
Call handled synchronously by server.
Concurrent RPCs: serial or concurrently.
Server availability: continuous or on-demand.
15
2.6 FAILURES OF RPCS
Machines or networks can fail at any time.
At most once semantics.
RPC return value indicates success.
Up to the client to avoid maybe semantics!
16
3 THE CORBA OBJECT MODEL
Components objects. Visible component state object attributes. Usable component services object operations. Component interactions operation execution
requests. Component service failures exceptions.
18
3 THE OMG INTERFACE DEFINITION LANGUAGE
OMG/IDL is a language for expressing all concepts of the CORBA object model.
OMG/IDL is programming-language independent, orientated towards C++, and not computationally complete.
Different programming language bindings are available.
19
3.1 TYPES OF DISTRIBUTED OBJECTS
Attributes, operations and exceptions are properties objects may export to other objects.
Multiple objects may export the same properties.
Only define the properties once!
Attributes and operations, and exceptions are defined in object types.
21
3.1 TYPES
A type is one of the following: Atomic types
(void, boolean, short, long, float, char, string), Object types (interface), Constructed types:
Records (struct), Variants (union), and Lists (sequence), or
Named types (typedef).
22
3.1 TYPES (EXAMPLES)
struct Requester {
int PIN;
string AccountNo;
string Bank; };
typedef sequence<ATM> ATMList;
23
3.2 ATTRIBUTES
Attributes are declared uniquely within an interface.
Attributes have a name and a type. Type can be an object type or a non-object
type. Attributes are readable by other components. Attributes may or may not be modifyable by
other components. Attributes correspond to one or two operations
(set/get). Attributes can be declared as read-only. 24
3.3 EXCEPTIONS
Service requests in a distributed system may not be properly executed. Exceptions are used to explain reason of failure to requester of operation execution.
Operation execution failures may be generic or specific.
Specific failures may be explained in specific exceptions.
Exceptions have a unique name. Exceptions may declare additional data
structures.26
3.3 EXCEPTIONS (EXAMPLE)
exception InvalidPIN;
exception InvalidATM;
exception NotEnoughMoneyInAccount {
short available;
};
27
3.4 OPERATIONS
Operations have a unique identifier.
Operations have a parameter list. parameters are in, out or inout, parameter identifiers are unique within the list, and parameter types have been declared.
Operations have a result type.
Operations declare exceptions they may raise.
28
3.4 OPERATIONS (EXAMPLES)
void accept_request(in Requester req,
in short amount)
raises(InvalidPIN,
NotEnoughMoneyInAccount);
short money_in_dispenser(in ATM dispenser)
raises(InvalidATM);
29
3.5 INTERFACES
Attributes, exceptions and operations are defined in interfaces.
Interfaces have an identifier, which denotes the object type associated with the interface.
Interfaces must be declared before they can be used.
Interfaces can be declared forward.
30
3.5 INTERFACES (EXAMPLE)interface ATM;
interface TellerCtrl {
typedef sequence<ATM> ATMList;
exception InvalidPIN;
exception NotEnoughMoneyInAccount {...};
readonly attribute ATMList ATMs;
readonly attribute BankList banks;
void accept_request(in Requester req,
in short amount)
raises(InvalidPIN,NotEnoughMoneyInAccount);
}; 31
3.6 MODULES
A global name space for identifiers is unreasonable.
IDL includes Modules to restrict visibility of identifiers.
Access to identifiers from other modules by qualification with module identifier.
32
3.6 MODULES (EXAMPLE)
module Bank {
interface AccountDB {};
};
module ATMNetwork {
typedef sequence<Bank::AccountDB> BankList;
exception InvalidPIN;
interface ATM;
interface TellerCtrl {...};
};33
3.7 INHERITANCE
Properties shared by several types should be defined only once.
Object types are organized in a type hierarchy. Subtypes inherit attributes, operations and
exceptions from their supertypes. Subtypes can add more specific properties. Subtypes can redefine inherited properties.
34
3.7 INHERITANCE (EXAMPLES)
interface Controllee;
interface Ctrl {
typedef sequence<Controllee> CtrleeList;
readonly attribute CtrleeList controls;
void add(in Controllee new_controllee);
void discard(in Controllee old_controllee);
};
interface ATM : Controllee {...};
interface TellerCtrl : Ctrl {...};35
3.7 INHERITANCE (MULTIPLE)
Multiple Inheritance May cause name clashes if different super-types
export the same identifier. Example: interface Set {
void add(in Element new_elem);
};
interface TellerCtrl:Set, Ctrl { ... }; Name clashes are not allowed!
36
4.1 OBJECT MANAGEMENT ARCHITECTURE
ApplicationObjects
CORBAfacilities
CORBAservices
Object Request Broker
38
One standardized interface
One interface per object operation
ORB-dependent interfaceOne interface per object adapter
DynamicInvocation DynamicInvocation
ClientStubsClientStubs
ORBInterface ORBInterface
Implementation SkeletonsImplementation Skeletons
ClientClient Object ImplementationObject Implementation
ORB CoreORB Core
ObjectAdapter ObjectAdapter
4.2 ACCESSING REMOTE OBJECTS
39
4.2 STUB/SKELETON GENERATION (FOR C++)
IDL-Compiler
Person.idl
Client.cc Server.cc
C++ Compiler, Linker C++ Compiler, Linker
Personcl.hh
Personcl.cc Personsv.cc
Personsv.hh
Client Server
includesgeneratesreads
40
5 COMPARISON
RPC architecture lacks interface repository.
IDL is more expressive than RPCL: inheritance,
attributes and
exceptions.
IDL has multiple standardized language bindings.
Corba handles failures with exceptions which are more expressive than returning a NULL pointer.
49
5 COMPARISON (CONT´D)
RPCs may be more efficient than CORBA operation invocations.
RPCs come with the UNIX OS whilst you would have to buy a CORBA product.
CORBA is more widely available on non-UNIX platforms.
RPCs are lightweight.
51
6 SUMMARY
The basic conceptual framework for remote object invocation in distributed systems.
Definition of RPC and how it works. CORBA object model and IDL. CORBA remote procedure definition and remote
object invocation. The similarities and differences between RPC and
CORBA. Read Textbook Chapters 5 and 20.
52
Recommended