1. CORBA (Common Object Request Broker Architecture)
7. CORBA 7.1. Basics
What is CORBA?
CORBA (Common Object Request Broker Architecture)
- is an integration technology, that makes calls between objects written in different languages possible;
- is a specification for creating and using distributed objects and that vendors follow to make CORBA-compliant products, i.e. product that can talk to each other following the CORBA integration technology.
- it is not a programming language.
What is it good for?
- integrating legacy code, e.g. legacy data stores;
- using services at remote locations, independent of implementation language of the server.
Who developed it?
OMG (Object Management Group) ( ), that specified the Object Management Architecture or OMA
Fall 2003
MET CS 667: 7. CORBA

2. 7.2. Object Management Architecture - OMA
Two major components:
Core Object Model states the basic concepts of
- object,
- interface,
- operation,
- etc.
OMA Reference Architecture defines services and mechanisms to allow objects to interoperate; it includes
- Object Request Broker or ORB: this is a kind of universal translator for inter-object CORBA communication; it must be installed on the server as well as on the client side.
Note: different vendors have different ORB implementation, but all CORBA 2.0 and higher compliant ORBs communicate through the Internet Inter-ORB Protocol(IIOP).
Fall 2003
MET CS 667: 7. CORBA

3. naming service: supports search of objects by name;
OMA (continued)
- Object Services, also called CORBA services: services needed by almost all objects; they are accessed through the ORB and include
naming service: supports search of objects by name;
startup service: starts a process.
life cycle service: supports creating, copying, moving or destroying objects;
event service: supports notification of events to interested objects;
provides asynchronous communication between cooperating remote
objects;
persistent object service: provides common interface for managing object persistence in a data-store independent manner.
concurrency control service for mediating simultaneous access by more than one client, ensuring that object remains consistent and coherent.
- Object Facilities: provides functionality at the application level, that include
horizontal facilities: user interface, information management, systems and task management;
vertical or domain facilities: provide facilities for specific domain, e.g. telecommunication, e-commerce, health care,
Fall 2003
MET CS 667: 7. CORBA

4. Interface Definition Language - IDL
References: (HoCo 2002, Ch.5)
As previously discussed, in a distributed system the object requesting the service (client) needs to know the names and signatures of methods the server object exposes.
Problem: If the goal is to allow objects implemented in different languages to communicate with each other, one needs a language independent way for specifying data types, attributes, operations, interfaces, etc.
CORBA's answer to this problem is IDL – a language for describing the attributes, methods, interfaces used by client and server.
The interface is typically written on the server side and then distributed to clients.
At the client side it is compiled by an IDL-to-SomeLanguage compiler that generates a source file and several helper files for argument marshaling and remote calls.
Fall 2003
MET CS 667: 7. CORBA

5. IDL supports inheritance and has C++/Java like syntax
IDL Overview
IDL supports inheritance and has C++/Java like syntax
CORBA IDL Java C++
Module Package Namespace
Interface Interface Pure abstract class
Method Method Member function / Method
The rules for translating IDL into another language are referred to as IDL language bindings or mappings.
OMG has standardized the language bindings thus requiring all vendors to use the same rules for mapping IDL constructs to the constructs of a particular language.
Languages with IDL mappings include C, C++, Java, Smalltalk, Lisp, Python
Fall 2003
MET CS 667: 7. CORBA

6. IDL for Client Requests
Object Implementation
IDL
ORB
Notes:
Client as well as Server are isolated from the ORB through the IDL interface;
All requests are managed by the ORB, i. e. every single invocation, (whether remote or local) of a CORBA object is handled by the ORB. The difference between the remote and local invocation is only that it is passed from the ORB of the client to the ORB of the server.
Client and Server side can be at different locations and use different ORBs.
Fall 2003
MET CS 667: 7. CORBA

7. Object Implementation
CORBA 2.0 ORB Structure
Client
Object Implementation
ORB CORE
ORB
Interface
Static IDL
skeletons
Stubs
Dynamic
Invocation
Object Adaptor
DII Dynamic Interface Invocation: client obtains instance of CORBA object at run time and dynamically constructs requests. DII uses the interface repository (IR) to validate and retrieve signature of requested operation.
DSI Dynamic Skeleton Interface server side analog of DII, allows server to be written without skeleton or compile time knowledge (since CORBA 2.0)
Interface Repository (IR) allows client to locate object that was unknown at compile time, find info about its interface and build request
Object Adapters (OA) primary way of object implementation to access ORB services.
Fall 2003
MET CS 667: 7. CORBA

8. 7.3. Implementing CORBA Objects
Write IDL interface, that specifies what object does.
Compile interface with IDL compiler for target language(s) and generate required stubs and helper classes.
Write server objects in language of your choice. Compile server object code.
Write server that creates and registers the server objects. The CORBA naming service offers a convenient registration method. (Similar to RMI registry)
Write client that locates server objects and invokes services on them.
Start naming service, server program and client program.
Important Differences to RMI:
Client and Server can be implemented in any language with CORBA binding;
Interfaces are specified in IDL
Fall 2003
MET CS 667: 7. CORBA

9. string getenv (in string name); }; file Env.idl
Example "Env": Java client asks value of an environmental variable, C++ server obliges (HoCo 2000, Ch.5)
interface Env {
string getenv (in string name); };
file Env.idl
Note lowercase
IDL-to-Java Compiler, e.g.
idltojava or idlj
(Sun's JavaIDL 1.2 and 1.3 respectively)
Note semicolon after interface definition
Three helper classes
interface Env {
String getenv (String name); }
file Env.java
EnvStub.java
Stub class
Fall 2003
MET CS 667: 7. CORBA

10. IDL Basics – method parameters
Parameter Passing: the direction parameters are passed can be defined in the method definition by declaring a parameter as
in from client to server as input (same as in Java)
out from server to client as output (no analog in Java);
method stores value in each out parameter before returning;
caller can retrieve values stored in out parameters
inout in both directions
Example: find method looks for some product and stores product object
interface Warehouse{
boolean locate(in string description, out Product p); };
For an out only parameter methods do not expect initialization.
For an inout parameter caller must supply a value and the method can change that value.
Fall 2003
MET CS 667: 7. CORBA

11. IDL Basics – Holder classes
In Java, out and inout parameters are simulated with holder classes. Holder classes are automatically generated by the IDL compiler with a Holder suffix added to the class name. In order to retrieve changes to the parameters, every holder class has a public member value that is of the type of the IDL parameter from which it was generated.
idltojava
interface Warehouse{
boolean locate(in string description, out Product p); };
boolean locate(String description, ProductHolder p); …
Change of method signature
Fall 2003
MET CS 667: 7. CORBA

12. Holder classes (continued)
In general:
<method>(out <OutputType> firstOut, inout <MsgType> ourMessages)
<method>(<OutputType>Holder firstOut, <MsgType> Holder ourMessages)
Each holder class has a value public instance variable that stores changes and is of the type of the original in or inout parameter. Thus
firstOut.value of type <OutputType>
and
ourMessages.value of type <MsgType>
There are predefined holder classes for the fundamental types, e.g. IntHolder, DoubleHolder, etc..
Fall 2003
MET CS 667: 7. CORBA

13. Calling Methods with Holder classes
When calling a method with a holder class one needs to pass a holder object
Warehouse w = ...;
String description = ...;
Product p;
ProductHolder pHolder = new ProductHolder( );
if ( w.locate ( description , pHolder ) )
p = pHolder.value ;
Creating holder object
Passing holder object as parameter
object of Product type retrieved:
The changed value of the Holder class is retrieved through the public variable value
Fall 2003
MET CS 667: 7. CORBA

14. basic: char, short, long, float, double, boolean
IDL Types
Types are C/C++ like
basic: char, short, long, float, double, boolean
constructed: struct, union, enum
typedefinition: typedef <UserType> <Name>
fixed size arrays as in C, e.g. short points[10];
sequences: template type, used to define arrays of varying size, e.g.
sequence < double> eField;
sequence < double, 15>
typedef sequence<Product> ProductSeq;
interface Warehouse{
ProductSeq find (in Customer c); … };
Translated in Java to
Product [] find (Customer c);
Unbounded sequence with double elements
Bounded sequence with double elements
Dynamic array of Product elements
ProductSeq type; can be used in method definition
Fall 2003
MET CS 667: 7. CORBA

15. IDL – Raising an Exception
Throwing an exception: exception type must be first defined, then a raises declaration used:
interface Warehouse{
exception BadCustomer { string reason; } ;
ProductSeq find (in Customer c) raises BadCustomer;
... };
IDL compiler translates the exception type into a class:
final public class BadCustomer
extends org.omg.CORBA.UserException{
public BadCustomer() {};
public BadCustomer(String _reason) {reason = _reason; };
public String reason; }
Fall 2003
MET CS 667: 7. CORBA

16. IDL - constants, attributes
Interfaces can contain constants
Interfaces can contain attributes
The Java translation is a pair of methods both with the attribute name:
interface Warehouse{
const int SOLD_OUT=555;
... };
interface Book{
attribute string isbn;
... };
String isbn( ); //accessor
void isbn(String _isbn); //mutator
// no mutator is generated if attribute is declared readonly
Fall 2003
MET CS 667: 7. CORBA

17. Interface inheritance is declared by colon ( : ), as in C++
IDL - inheritance
Interface inheritance is declared by colon ( : ), as in C++
multiple interfaces can be inherited
7. Definitions of interfaces, types, constants, exceptions can be grouped into modules
interface Book : Product {...};
Book inherits from Product
module Supplier {
interface Book {…};
interface Product {...};
interface Warehouse {...}; .. };
Translated in Java through package
Note: Variables cannot be specified in CORBA interfaces. IDL does not address implementation, and the data representation for objects is an implementation decision
Fall 2003
MET CS 667: 7. CORBA

18. Example "Env": Classes generated by the IDL Compiler
interface Env {
string getenv (in string name); };
file Env.idl
IDL-to-Java
IDL-to-C++
Env.java - the interface definition;
EnvHolder.java – holder class for
out and inout parameters;
EnvHelper.java
_EnvImplBase.java – superclass
for implementation class
_EnvStub.java – stub class to
communicate with ORB
Env.hh – header file defines classes Env,
EnvHelper,
_sk_Env – base class for server
implementation classs ;
EnvSK.cpp – C++ source code for
above classes
Fall 2003
MET CS 667: 7. CORBA

19. Example "Env": C++ interface implementation (treat as legacy code)
class EnvImpl : public virtual _sk_Env{
public:
virtual char* getenv(const char *name){
char* value = :: getenv(name); //call getenv of the standard C library
return CORBA::string_dup(value); } };
Fall 2003
MET CS 667: 7. CORBA

20. Example "Env": Server and Client actions
Server program (in C++ - treat as legacy code)
Start ORB;
Create object of EnvImpl class and register it with the ORB;
Bind object to a name using the name server;
Wait for invocation from client
Client program needs to
Initialize ORB;
Locate naming service by retrieving the initial reference to "NameService" and narrowing it to a NamingContext reference;
Locate the object whose methods you want to call by assembling its name and calling the resolve method of the NamingContext;
Narrow the returned object to the correct type and invoke desired method.
Fall 2003
MET CS 667: 7. CORBA

21. Example "Env": Client – initialization, listing services
Initialize ORB;
Locate a naming service that allows locating other objects. The CORBA naming service is just another CORBA object. In CORBA 2 the call
lists the names of some standard services the ORB provides. (The ORB of the Java 2 platform lists only the naming service itself, other ORBs have additional initial services).
ORB orb = ORB.init(args, null);
String [] services = orb.list_initial_services();
Fall 2003
MET CS 667: 7. CORBA

22. Example "Env": Client – Using the Naming Service
The Naming service associates names with server objects – a process known as stringifying the reference. It performs object-to string and string-to-object mapping
The naming service supports
creating an object-to string mapping, referred as binding an object;
removing an object-to string mapping, referred as unbinding an object;
obtaining an object reference by passing a string, is referred to as resolving the name
The Naming Service runs as a separate process and both server and client can consult and manipulate it.
The naming service has the standard name NameService. To obtain an object reference to this service the resolve_initial_references method must be called:
org.omg.CORBA.Object namingContextObj
= orb.resolve_initial_references ( "NameService");
returns generic CORBA object:
instance of class org.omg.CORBA.Object
Fall 2003
MET CS 667: 7. CORBA

23. Example "Env": Client – Narrowing the NamingContext
In order to use the methods of the NamingContext interface, however, we need a NamingContext reference, not just a generic CORBA object.
CORBA does not allow simple cast of references.
In order to obtain a NamingContext type, one must use the narrow method of the helper class of the target interface
NamingContext namingContext
= (NamingContext) namingContextObj;
// ERROR!!!!
NamingContext namingContext
= NamingContextHelper.narrow(namingContextObj);
Fall 2003
MET CS 667: 7. CORBA

24. Example "Env": Client - Locating Objects
Locate the object whose methods you want to call by assembling its name and calling the resolve method of the NamingContext;
Names are nested sequences of name components.
Name hierarchies can be built similarly to the directories of the file system.
A name component consists of an
id - name of component that is unique among all names with the same parent component, e.g. corejava, Env, and a
kind - some indication of the type; not standardized. As an example "Context" is used for name components that have nested names, and "Object" for object names
In the "Env" example the server program has given the EnvImpl object the name
(id = "corejava", kind = "Context"), (id = "Env", kind = "Object")
In order to find the object its name is built through an array of name componenets
NameComponent[] path = { new NameComponent ( "corejava", "Context"),
new NameComponent("Env", "Object") };
Fall 2003
MET CS 667: 7. CORBA

25. Example "Env": Resolving the name and Using the Object
Resolve the resulting name to obtain an Env object
Narrow the returned object to the correct type and invoke desired method
Call method (finally!!).
org.omg.CORBA.Object envObj = namingContext . resolve(path);
Env env = EnvHelper . narrow ( envObj ) ;
System.out.println ( env . getenv ( " PATH " ) );
Fall 2003
MET CS 667: 7. CORBA

26. Example "Env": Client Code
import org.omg.CosNaming.*;
import org.omg.CORBA.*;
public class EnvClient
{ public static void main(String args[])
{ try
{ ORB orb = ORB.init(args, null);
org.omg.CORBA.Object namingContextObj
= orb.resolve_initial_references ( " NameService ") ;
NamingContext namingContext
= NamingContextHelper.narrow ( namingContextObj ) ;
Fall 2003
MET CS 667: 7. CORBA

27. Example "Env": Client Code (continued)
NameComponent[] path
= { new NameComponent("corejava", "Context"),
new NameComponent("Env", "Object") };
org.omg.CORBA.Object envObj = namingContext . resolve(path);
Env env = EnvHelper . narrow ( envObj ) ;
System.out.println ( env.getenv ( " PATH " ) ); }
catch(Exception e)
{ System.out.println("Error: " + e);
e.printStackTrace(System.out);
Fall 2003
MET CS 667: 7. CORBA

28. RPC between objects written in any languages;
CORBA vs. RMI
RPC between objects written in any languages;
BUT: CORBA has done this for you
RMI allows RPC between Java objects;
BUT: RMI can call services on remote, non-Java code as follows: write a wrapper Java object around the non-Java code on the server side.
Wrapper connects externally to Java clients via RMI and internally to the non-Java code code using Java Native Interface (JNI) or J/Direct
Yes, but now I do not need a 3d party ORB
Fall 2003
MET CS 667: 7. CORBA