ch 17. CORBA
-
Upload
rajesh-sadashiv-sarvankar -
Category
Documents
-
view
239 -
download
0
Transcript of ch 17. CORBA
-
8/3/2019 ch 17. CORBA
1/33
Chapter 17
CORBA case study
17.1 Introduction
17.2 CORBA RMI Client and server example
Architecture
CORBA IDL
CORBA object references
17.3 CORBA Services
-
8/3/2019 ch 17. CORBA
2/33
Introduction to CORBA
The Object Management Group (OMG) was formedin 1989. Its aims were: to make better use of distributed systems
to use object-oriented programming
to allow objects in different programming languages to communicate
with one another
The object request broker (ORB) enables clients to
invoke methods in a remote object
CORBA is a specification of an architecture
supporting this. CORBA 1 in 1990 and CORBA 2 in 1996.
-
8/3/2019 ch 17. CORBA
3/33
Introduction to CORBA
The main components of CORBAs RMI framework are:1. An interface definition language known as IDL.
2. An architecture.
3. The General Inter-ORB protocol (GIOP) defines an external data representation, called CDR
specifies formats for the messages in a request-reply protocol.
including messages for enquiring about the location of anobject, for cancelling requests and for reporting errors.
1. The Internet Inter-ORB protocol (IIOP) defines a standardform for remote object references.
IIOP is GIOP implemented in TCP/IP
CORBA services - generic services useful in distributedapplications e.g. Naming Service, Event Service.
-
8/3/2019 ch 17. CORBA
4/33
CORBA RMI
CORBA RMI is a multi-language RMI system.
The programmer needs to learn the following new concepts: the object model offered by CORBA;
the interface definition language and its mapping onto the implementationlanguage.
CORBA's object model similar to the remote object model in Chapter 5 clients are not necessarily objects a client can be any program that sends
request messages to remote objects and receives replies.
The term CORBA objectis used to refer to remote objects. a CORBA objectimplements an IDL interface, has a remote object reference
and its methods can be invoked remotely. A CORBA object can be implemented by a language without classes.
the class concept does not exist in CORBA.
therefore classes cannot be defined in CORBA IDL, which means thatinstances of classes cannot be passed as arguments.
-
8/3/2019 ch 17. CORBA
5/33
CORBA IDL interfaces Shape and ShapeList
struct Rectangle{
long width;long height;
long x;
long y;
} ;
struct GraphicalObject {
string type;Rectangle enclosing;
boolean isFilled;
};
interface Shape {
long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject
};
typedef sequence All;
interface ShapeList {
exception FullException{ };
Shape newShape(in GraphicalObject g) raises (FullException);All allShapes(); // returns sequence of remote object references
long getVersion() ;
};
Figure 17.1
an interface specifies a name and a set of methods
interface ShapeList
the parameter ofnewShape is an in parameterand
of type Graphical Object The return value is an
extra outparameter of type Shape.
sequences and arrays in typedefs
Exceptions defined by raises and set
by throw. They can have arguments.
this structis used as a parameter or result
type in methods in the remote interfaces.
this structis used in
defining anotherstruct.
-
8/3/2019 ch 17. CORBA
6/33
Parameters in CORBA IDL
Passing CORBA objects: Any parameter or return value whose type is specified by the name of a IDL
interface, e.g. Shape, is a reference to a CORBA object (see newShape)
and the value of a remote object reference is passed.
Passing CORBA primitive and constructed types: Arguments of primitive and constructed types are copied and passed by value.
On arrival, a new value is created in the recipients process. E.g., the structGraphicalObject(argument ofnewShape and result ofgetAllState)
Note: the method allShapes returns an array of remote objectreferences as follows:
typedef sequence All;
All allShapes();
Type Object- is a supertype of all IDL interfaces (its values areobject references).
-
8/3/2019 ch 17. CORBA
7/33
CORBA Naming Service
It is a binder that provides methods including rebindfor servers to register the remote object references of CORBA objects
by name (e.g. rebind(path, Object)
resolve for clients to look them up by name.(e.g.Object= resolve(path))
The names are structured in a hierarchy,
a path is an array ofNameComponent(a structwith a name in it) the path starts from an initial context provided by CORBA
This makes access in a simple example seem rather complex!
The name service is present in all CORBA installations. (Its
role is like the Java RMI registry)
Its use will be shown in program examples
-
8/3/2019 ch 17. CORBA
8/33
CORBA pseudo objects
Implementation of CORBA provides some interfaces to thefunctionality of the ORB that programmers need to use. They
are called pseudo objects.
Because they can not be used like CORBA objects.
ORB is the name of an interface. It includes:
The method init, which must be called to initialize the ORB
The method connect, which is used to register CORBA objects with
the ORB
Other methods which enable conversions between remote object
references and strings.
-
8/3/2019 ch 17. CORBA
9/33
CORBA client and server example
Illustration of CORBA with a Java client and server The interface compiler is called idltojava,when given an IDL
interface, it produces: the equivalent Java interfaces (e.g. ShapeListbelow)
server skeletons for each idl interface (e.g. _ShapeListImplBase)
proxy classes or client stubs (e.g. _ShapeListStub) a Java class for each structe.g. Rectangle, GraphicalObject
helper classes (one for each of the types defined in the IDL interface)
and holder classes (forout and inoutarguments which can not be
directly map on to java)
public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion();
}
Figure
-
8/3/2019 ch 17. CORBA
10/33
The ShapeListServantclass of the Java server program for the
CORBA interface ShapeList.
import org.omg.CORBA.*;
class ShapeListServant extends _ShapeListImplBase {
ORB theOrb;
private Shape theList[];
private int version;
private static int n=0;
public ShapeListServant(ORB orb){
theOrb = orb;
// initialize the other instance variables
}
public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException {
version++;
Shape s = new ShapeServant( g, version);
if(n >=100) throw new ShapeListPackage.FullException();
theList[n++] = s;
theOrb.connect(s);return s;
}
public Shape[] allShapes(){ ... }
public int getVersion() { ... }
}
A Java server has classes for its
IDL interfaces (e.g. Shape andShapeList). Here is the classShapeListServant
a servant class extends the corresponding
skeleton class (e.g. ShapeListImplBase)
a servant class implements the methods in theinterface (ShapeList).
newShape is a factory method. It creates new
CORBA objects. It uses the connectmethod to
register it with the ORB. (it has a remote object
reference)
CORBA objects are instances of servant classes.In non-OO languages implementations of CORBA
objects cant be classes.
-
8/3/2019 ch 17. CORBA
11/33
Java class ShapeListServer(the server class)
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;
public class ShapeListServer {
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null);
ShapeListServant shapeRef = new ShapeListServant(orb);
orb.connect(shapeRef);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", "");
NameComponent path[] = {nc};
ncRef.rebind(path, shapeRef);java.lang.Object sync = new java.lang.Object();
synchronized (sync) { sync.wait();}
} catch (Exception e) { ... }
}
}
Figure
The server class contains the main method
it creates and initialises the ORB
it creates an instance ofShapeListServantclass - a Java
object - which is made a CORBA object
by using the connectmethod to register it with the ORB
it waits for client requests
1. it gets a reference to the Naming Service, it
first get a root naming context2. narrows it to NamingContext- from Object
3. makes a NameComponentcontaining the
name ShapeList
4. makes a path
5. uses rebindto register the name and object
reference
-
8/3/2019 ch 17. CORBA
12/33
Java client program for CORBA interfaces Shape andShapeList
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class ShapeListClient{
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", "");
NameComponent path [] = { nc };
ShapeList shapeListRef =
ShapeListHelper.narrow(ncRef.resolve(path));Shape[] sList = shapeListRef.allShapes();
GraphicalObject g = sList[0].getAllState();
} catch(org.omg.CORBA.SystemException e) {...}
} Figure
it creates and initialises an ORB
1. it contacts the NamingService for initial context2. Narrows it to NamingContext
3. It makes a name component
4. It makes a path
5. It gets a reference to the CORBA object called
ShapeList, using resolve and narrows it
it invokes the allShapes method in the CORBA object to get an array
containing remote references to all of the GraphicalObjects currently
stored by the server
it uses one of the remote references in the array to
invoke the getAllState method in the corresponding
CORBA object whose type is Shape
the value returned is of type GraphicalObject
-
8/3/2019 ch 17. CORBA
13/33
The main components of the CORBA architecture
clientserver
proxy
or dynamic invocation
implementation
repository objectadapter
ORBORB
skeleton
or dynamic skeleton
clientprogram
interface
repository
Request
Replycorecorefor A
ServantA
The CORBA architecture is designed to allow clientsto invoke methods in CORBA objects clients and objects can be implemented in a variety of programming
languages
it has the following additional components compared to Figure 5.6 object adapter, implementation repository and interface repository
Figure
ORB coreThe role of the ORB core is similar to that of the communication module of Figure 5.6.
In addition, an ORB core provides an interface that includes the following:
- operations enabling it to be started and stopped;
- operations to convert between remote object references and strings;
- operations to provide argument lists for requests using dynamic invocation.
Dynamic invocation interfaceIn some applications (e.g. browsers), a client without the appropriate
proxy class may need to invoke a method in a remote object.
CORBA does not allow classes for proxies to be downloaded at run time
as in Java RMI.
The dynamic invocation interface is CORBAs alternative. (we will
discuss it later with the Interface Repository)
Object adapteran object adapter bridges the gap between
CORBA objects with IDL interfaces and
the programming language interfaces of the corresponding servant classes.
it does the work of the remote reference and despatcher modules in Fig. 5.6
more about the object adapter later.
Skeletons
skeleton classes (for OO languages) are generated in thelanguage of the server by an IDL compiler.
remote method invocations are dispatched via the appropriateskeleton to a particular servant,
the skeleton unmarshals the arguments in request messagesand marshals exceptions and results in reply messages.
Client stubs/proxies
these are in the client language. an IDL compiler for the client language uses an IDL interface togenerate one of the following:
for object-oriented languages the class of a proxy
for procedural languages a set of stub procedures.
as before, the client stubs/proxies marshal the arguments ininvocation requests and unmarshal exceptions and results in replies.
Implementation repository
activates registered servers on demand and locates running servers
uses the object adapter name to register and activate servers.
Interface repositorythe interface repository provides information about registered IDL interfaces to clientsand servers that require it.
-
8/3/2019 ch 17. CORBA
14/33
Object adapter
an object adapter bridges the gap between
CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant (classes).
it does the work of the remote reference and despatcher modules in RPC.
An object adapter has the following tasks: it creates remote object references for CORBA objects;
it dispatches each RMI via a skeleton to the appropriate servant;
it activates objects.
An object adapter gives each CORBA object a unique objectname. the same name is used each time an object is activated.
it is specified by the application program or generated by the object adapter.
Each object adapter has its own name - specified by theapplication program or generated automatically.
CORBA 2.2 standard for object adapters is called POA.
-
8/3/2019 ch 17. CORBA
15/33
Implementation repository
Implementation repository it activates registered servers on demand and locates running servers
it uses the object adapter name to register and activate servers.
it stores a mapping from the names of object adapters to the
pathnames of files containing object implementations.
when a server program is installed it can be registered with the
implementation repository.
when an object implementation is activated in a server, the hostname and
port number of the server are added to the mapping.
Implementation repository entry:
object adapter
name
pathname of object
implementation
hostname and port number
of server
- not all CORBA objects (e.g. call backs) need be activated on demand
- access control information can be stored in an implementation repository
-
8/3/2019 ch 17. CORBA
16/33
Interface repository
it provides information about registered IDL interfaces for an interface of a given type it can supply the names of the methods and foreach method, the names and types of the arguments and exceptions.
a facility for reflection in CORBA.
if a client has a remote reference to a CORBA object, it can ask the interfacerepository about its methods and their parameter types
the client can use the dynamic invocation interface to construct an invocationwith suitable arguments and send it to the server.
the IDL compiler gives a type identifier to each IDL type
a type identifier is included in remote object references
this type identifier is called the repository ID
because the interface repository stoes interfaces against their IDs applications that use static invocation with client proxies and
IDL skeletons do not require an interface repository. Not all ORBs provide an interface repository.
-
8/3/2019 ch 17. CORBA
17/33
CORBA IDL
IDL provides facilities for defining modules,interfaces, types, attributes and method signatures. examples of all of the above, except modules, is shown in Figure IDL
interfaces shape and shape and shapelist.
IDL has the same lexical rules as C++ but has
additional keywords to support distribution, for example interface, any, attribute, in, out, inout, readonly, raises.
It allows standard C++ pre-processing facilities. e.g.
typedefforAll.
The grammar of IDL is a subset of ANSI C++ with
additional constructs to support method signatures.
-
8/3/2019 ch 17. CORBA
18/33
IDL module Whiteboard
Modules allow interfaces and IDL type definitions tobe grouped.
A module defines a naming scope, which prevents
names define within a module clashing with names
defined outside it.module Whiteboard {
struct Rectangle{
...} ;
struct GraphicalObject {
...};
interface Shape {...};
typedef sequence All;
interface ShapeList {
...};
};
Figure
-
8/3/2019 ch 17. CORBA
19/33
IDL method signatures
[oneway] (parameter1,..., parameterL)[raises (except1,..., exceptN)]
[context (name1,..., nameM)]
each parameter is labelled as in, outorinout, e.g. void getPerson(in string name, out Person p);
onewaye.g. oneway void callback(in int version) the client will not be blocked and maybe semantics is used at-most-once call semantics is the default
The optional raises expression indicated user defineexceptions
The optional context expression is used to supplies mapping
form string names to string values
-
8/3/2019 ch 17. CORBA
20/33
Inheritance
IDL interfaces may extend one or more interfaces an extended interface may add new methods, types, constants
and exceptions It may redefine types, constants and exceptions but not
methods
Interface A{};
Interface B: A{};
Interface C{};
Interface Z: B and C{};
Figure
-
8/3/2019 ch 17. CORBA
21/33
FigureIDL constructed types 1
Type Examples Use
sequence typedef sequence All;typedef sequence Allbounded and unbounded sequencesof Shapes
Defines a type for a variable-lengthsequence of elements of a specifiedIDL type. An upper bound on thelength may be specified.
string String name;
typedef string SmallString;unbounded and boundedsequences of characters
Defines a sequences of characters,
terminated by the null character. Anupper bound on the length may bespecified.
array typedef octet uniqueId[12];
typedef GraphicalObject GO[10][8]
Defines a type for a multi-dimensionalfixed-length sequence of elements of aspecified IDL type.
Figure
-
8/3/2019 ch 17. CORBA
22/33
FigureIDL constructed types 2
Type Examples Userecord struct GraphicalObject {
string type;Rectangle enclosing;boolean isFilled;
};
Defines a type for a record containing agroup of related entities. Structs are
passed by value in arguments andresults.
enumerated enum Rand(Exp, Number, Name);
The enumerated type in IDL maps a
type name onto a small set of integervalues.
union union Exp switch (Rand) {case Exp: string vote;
case Number: long n;case Name: string s;
The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header is
parameterized by an enum, whichspecifies which member is in use.
};
-
8/3/2019 ch 17. CORBA
23/33
CORBA remote object references
CORBA 2.0 specifies a format for remote object references that issuitable for use,whether or not the object is activatable. Referencesusing this format are called 'interoperable object references'(IORs).
First field species the type name of the IDL interface of the CORBA object
Second field specifies the transport protocol Third field is used by the ORB to identify a CORBA object
IOR format
IDL interface type name Protocol and address details Object key
interface repositoryidentifier
IIOP host domainname
port number adapter name object name
-
8/3/2019 ch 17. CORBA
24/33
CORBA remote object references cont...
Transient IORs are for objects that last as long as the host process
they contain the address of the server hosting the CORBA object The server ORB core receives the request message containing the
object adapter name and object name of the target. It uses the object adapter name to locate the object adapter, which uses the object name to locate the servant.
Persistent IORs last between activations they contain the address of the implementation repository
the implementation repository receives the request and uses theobject adapter name to activate the object, then gives the serveraddress to the client
the client sends subsequent invocations to the server
-
8/3/2019 ch 17. CORBA
25/33
CORBA language mappings
Primitive types in IDL are mapped to the correspondingprimitive types in Java
Sequences and arrays in IDL are mapped to arrays in Java
Structs, enums and unions are mapped to Java classes
An IDL expression is mapped to a Java class
IDL allows methods to return several separate values visoutput parameters, where as Java can have only single result.The holder classes are provided to overcome this difficulty
-
8/3/2019 ch 17. CORBA
26/33
17.3 CORBA services
Naming Service Event Service and Notification Service Security service Trading service Transaction service and concurrency control service
Persistent object service
-
8/3/2019 ch 17. CORBA
27/33
CORBA services cont...
Naming Service It allows names to be bound to the remote object references of
CORBA objects within naming context
In fig CORBA objects are shown in the normal way, but namingcontexts are shown as plain ovals
Initial naming contexts provides a root for a set of bindings
Each name is consist of two strings, one for the name other for thekind of the object
-
8/3/2019 ch 17. CORBA
28/33
Naming Service cont...
CORBA services cont...
-
8/3/2019 ch 17. CORBA
29/33
CORBA services cont...
CORBA Event service: Defines interfaces allowing objects of interest, calledsuppliers to communicate notification to subscribers, calledconsumers
Notification are communicated as arguments or results
Notification may be propagated either by being pushed bysupplier to the customer or pulled by the consumer bysuppliers.
-
8/3/2019 ch 17. CORBA
30/33
CORBA services cont...
CORBA Notification service: Extent the CORBA Event Service retaining all of it's features It includes a filtering events that specify exactly which
events they are interested
Notification may be define as data structure
Event subscriber are provided with a mean of discoveringthe events the consumers are interested in
Event consumers can discovered the event type offered bythe suppliers by the channel
Possible to configure the properties of a channel, a proxy or
a particular eventAn event type repository is an optional extra
-
8/3/2019 ch 17. CORBA
31/33
CORBA services cont...
CORBA Security service: Authentication of principals (users and servers);
generating credential for principals (i.e. certificatestating their rights)
Access control can be applied to CORBA objectswhen they receive remote method invocations.
Auditing by servers of remote method invocations
Facilities for non-repudiation.
-
8/3/2019 ch 17. CORBA
32/33
CORBA services cont...
Trading service: allows CORBA objects to be located by attribute Attribute is a name value pair
The service type is a name
It's database contains a mapping from service types and theirassociated attributes onto remote object references of CORBA objects
Trading servers can perform quires on behalf of one another's clients.
Transaction service and concurrency control service TS provides flat or nested transactions
Client specifies a transaction as a sequence of RMI calls
Which are introduce by begin and terminated by commit or rollback
(abort). ORB attaches a transaction identifier to each remote invocation
CCS provides locking of CORBA objects
-
8/3/2019 ch 17. CORBA
33/33
CORBA services cont...
Persistent object service: for storing the state of CORBA objects in a passive form andretrieving it
The CORBA POS is intended to be suitable for use as an persistentobject store as an CORBA object.
Each persistent object has an identifier which includes the identity of
its data store and object number of that store. The implementation of persistent CORBA object must choose a
protocol for communicating with data store
E. g. The direct access protocol allows CORBA objects to access theattributes of persistent objects in the data store.