Post on 06-Jan-2016
description
CORBA Case Study
BySrinivas Narayanabhatta
21st March 2002
What is CORBA ?
Common Object Request Broker (ORB)Architecture
CORBA is OMG standard (Object Management Group)
to make better use of distributed systems to use object-oriented programming to allow objects in different programming languages to
communicate with one another
Evolution of CORBA
CORBA 1.1 (1992) Basic ORB, Naming, Interface Repository, C bindings,
Events, Basic Object Adapter,…
CORBA 2.0 (1995) Internet Inter-ORB Protocol (IIOP), C++ bindings,
Transactions, Security,…
CORBA 3.0 (and 2.2) (1998) Messaging (MOM), Portable Object Adapter (POA),
CORBA/DCOM interoperability, Java bindings, Objects by Value, Component Model,…
Object Management Architecture(OMA)
The main components of the CORBA architecture
client server
proxy
or dynamic invocation
implementation repository object
adapter
ORBORB
skeleton
or dynamic skeleton
client program
interface repository
Request
Replycorecore for A
Servant A
The CORBA architecture is designed to allow clients to 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 17.6
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 interface In 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 CORBA’s alternative. (we will discuss it later with the Interface Repository)
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 Fig. 5.6–more about the object adapter later.
Skeletons–skeleton classes (for OO languages) are generated in the language of the server by an IDL compiler.–remote method invocations are dispatched via the appropriate skeleton to a particular servant, –the skeleton unmarshals the arguments in request messages and 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 to generate one of the following:
for object-oriented languages the class of a proxyfor procedural languages a set of stub procedures.
– as before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies.
Implementation repositoryactivates registered servers on demand and locates running servers uses the object adapter name to register and activate servers.more about this later
CORBA RMI CORBA's Object Model
Clients are not necessarily objects The CORBA Object – refers to remote object implements an
IDL interface. CORBA IDL
Specifies a name and set of methods that clients can request
CORBA objects are passed by reference and primitives and constructed types are passed by value.
The CORBA Naming Service CORBA pseudo Objects
Implementations of CORBA provide some interfaces to the functionality of ORB. E.g.. ORB and its methods init, connect
CORBA IDL
Same lexical rules as C++ but has additional keywords to support distribution. E.g. interface, in, out, inout, readonly, raises
IDL Modules Allows interfaces and other IDL type definitions to be
grouped in logical units. IDL Interfaces
Describes the methods that are available in CORBA objects that implement that interface.
IDL Methods in parameter passed from the client to the invoked CORBA
object out parameter is passed back from the invoked CORBA
object to client.
CORBA IDL contd.. inout – indicate value may be passed in both directions oneway – indicates client invoking the method will not be
blocked while the target object is carrying out a method. raises – indicates user-defined exceptions that can be
raised. IDL Types
IDL supports fifteen primitive types. Object – indicates values of remote objects.
Attributes These are like public class fields in Java.
Inheritance IDL interfaces may be extended (multiple inheritance). All IDL interfaces inherit from type Object No operation overloading.
IDL Examplestruct Rectangle{ 1
long width; long height;long x;long y;
} ;
struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;
};
interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject
};
typedef sequence <Shape, 100> All; 4interface ShapeList { 5
exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;
};
From IDL to Java Stubs
CORBA language Mappings
The primitive types in IDL are mapped to the corresponding primitive types in Java
Structs, enums and unions are mapped to Java classes
Sequences and arrays in IDL are mapped to arrays in java.
The mappings in C++ are similarly straight forward.
The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3
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 and ShapeList). Here is the class ShapeListServant
a servant class extends the corresponding skeleton class (e.g. ShapeListImplBase)
a servant class implements the methods in the interface (ShapeList). newShape is a factory method. It creates new CORBA objects. It uses the connect method to inform the ORB about the new CORBA object. (it has a remote reference module)
CORBA objects are instances of servant classes.In non-OO languages implementations of CORBA objects can’t be classes.
This class has to create CORBA objects of type Shape. How does it do that?
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 17.4
The server class contains the main method
it creates and initialises the ORB
it creates an instance of ShapeListServant class - a Java object - which is made a CORBA object by using the connect method to register it with the ORB
it waits for client requests
1. it gets a reference to the Naming Service 2. narrows it to NamingContext- from Object 3. makes a NameComponent containing the name
“ShapeList” 4. makes a path
5. uses rebind to register the name and object reference
Java client program for CORBA interfaces Shape and ShapeList
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 17.5
it creates and initialises an ORB
1. it contacts the NamingService for initial context2. Narrows it to NamingContext3. It makes a name component4. It makes a path5. 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 Shapethe value returned is of type GraphicalObject
Static and Dynamic Invocations
Interface and Implementation Repositories
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
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 for each 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 interface repository about its methods and their parameter types
the client can use the dynamic invocation interface to construct an invocation with 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.
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
Fig. 5.6. 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 object name. 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 active CORBA object is registered with its object adapter,
which keeps a remote object table to maps names of CORBA objects to servants.
Each object adapter has its own name - specified by the application program or generated automatically.
CORBA remote object references
Transient IORs: Last only as long as the process that hosts them. Server ORB core receives the request, extracts object adapter
name from IOR, locates the servant through object name
Persistent IORs: Last between the activations of CORBA objects. Implementation Repository receives the request, extracts object
adapter name from IOR, attempts to activate if necessary, once activated returns its address details to the client ORB.
IOR format
IDL interface type nameProtocol and address details Object key
interface repositoryidentifier
IIOP host domainname
port number
adapter name object name
CORBA Services
CORBA specification includes a set of generic services that are useful for the distributed objects.
Naming Service Event Service Notification Service Security Service Trading Service Transaction and Concurrency control Services Persistent object service
Naming Service
Example of Naming Graph
initial naming context
ShapeList
CD E
B
initial naming context
P
R S T
V
Q U
initial naming context
XX
Figure 17.10Part of the CORBA Naming Service NamingContext interface in IDL
struct NameComponent { string id; string kind; };typedef sequence <NameComponent> Name;
interface NamingContext {void bind (in Name n, in Object obj);
binds the given name and remote object reference in my context.void unbind (in Name n);
removes an existing binding with the given name.void bind_new_context(in Name n);
creates a new naming context and binds it to a given name in my context.
Object resolve (in Name n); looks up the name in my context and returns its remote object reference.
void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi);
returns the names in the bindings in my context.};
Event Service
The CORBA Event service specification defines interfaces allowing objects of interest, called suppliers, to communicate notifications to subscribers, called consumers.
Event Channels are CORBA objects that my be used to allow multiple suppliers communicate with multiple consumers in an asynchronous manner.
The notification itself transmitted as an argument or result whose type is any.
consumersupplier
proxy consumernotification
proxy supplier
event channel
notificationnotification
Event Service – Interactive Models
Notification Service
The CORBA Notification Service extends the CORBA Event Service.
Notification Service provides support for filtering events.
Notifications may be defined as data structures. Event consumers can specify exactly which events
they are interested in. Event suppliers are provided with a means of
discovering the events the consumers are interested in.
Event consumers can discover the event types offered by the suppliers on a channel.
Security Service
Authentication of users and servers, generating credentials.
Access control can be applied to CORBA objects when they receive remote method invocation.
Access rights may be specified using ACLs. The security service requires cooperation on
behalf of ORB to guarantee the security. To make a secure RMI, client’s credentials are
sent with the request. The access decision made by the consulting
object.
Platform Support for CORBA
Visibroker Leading CORBA ORB, Client integrated in Netscape
Orbix Leading CORBA ORB, was ported to LynxOS Arbacus Commercial ORB, free for non-commercial
use OmniORB Free from AT&T, has been ported to
LynxOS2.5.1 ILU Free from Xerox.
IONA – ORBIX Architecture
CORBA – Strengths and Weaknesses
CORBA strength is in interoperability: languages, platforms, public domain software.
Has a very rich and complete set of facilities and services.
One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability.
There are many services defined but their implementations are slow to appear
By its working method OMG is creating compromises.