MSc Course in Advanced Distributed Systems

Session 2.1: CORBA and CORBA Programming using JAVAhttp://info.comp.lancs.ac.uk/msc/ads/index.htm

CORBA and CORBA programming

• overview of lecture– context: the OMG and its OMA (which includes

CORBA)– description of the CORBA architecture and its main

concepts– highlights of CORBA v3.0– practical focus on programming a simple client/ server

• additional reading– Very good online tutorials at http://java.sun.com/j2ee/corba/– www.omg.org

• acknowledgements to Weihai Yu, Univ. of Tromsø

Part 1: An overview of the OMG’s OMA/ CORBA

What is the OMG?

• formed in 1989 to address problems of developing distributed applications for heterogeneous systems

• world’s largest software industry consortium– more than 800 members– IBM, Sun, HP, Iona, ...

• works through a “Request for Proposals” (RFP) process

The Object Management Architecture (OMA)

Object Request Broker (CORBA)

object services

Domain interfacesApplication interfaces

• example domain interfaces– financial services,

heath care, real-time systems, ...

• example object services– naming service,

interface repository, AV streams, transactions, persistence, events, time service, ...

CORBAFacilities

CORBAServices

Goals of CORBA

• to simplify object-based distributed programming by automating:– object location and activation– parameter marshaling/ unmarshaling– request demultiplexing– error handling

• to provide a foundation for higher level services

The Common Object Request Broker Architecture (CORBA)

Main concepts in CORBA

• the OMG Interface Definition Language (IDL)– and its mapping to different programming languages

• clients, objects (servants), object references, and servers

• stubs and skeletons• ORB core• General Inter-ORB Protocol (GIOP) and Internet

Inter-ORB Protocol (IIOP)• Portable Object Adapter (POA)• Dynamic Invocation Interface (DII)/ Dynamic

Skeleton Interface (DSI)

RMI vs CORBARMI Advantages1. native JAVA, so is cleaner and

similar

2. Simple to use

3. Free, no licensing needed

Disadvantages1. just a remote procedure call

system

2. Language dependent

3. Not very powerful

CORBAAdvantages1. Defines a robust distributed

environment

2. All features needed for distributed applications

3. language independent

Disadvantages1. CORBA is non-native, so requires

lots of wrappers in JAVA

2. Advanced features are complicated to use (as you will see )

CORBA’s Interface Definition Language (IDL)

• a declarative language supporting programming language independence and platform independence

• object-oriented– interfaces with operations and attributes– basic and constructed types– single and multiple interface inheritance

• all interfaces inherit from Object– built-in exceptions

• mappings are defined to many languages– C++, C, Java, COBOL, LISP, ...

An example IDL file

// IDLmodule TimeServices {

struct TimeOfDay {short hour; // 0-23short minute; // 0-59short second; // 0-59

};interface Time {

void set_time(in TimeOfDay t);TimeOfDay get_gmt();string get_gmt_as_string();

}}

Some differences between IDL and JAVA/C++

• no statements• no pointers• no constructors • no templates• no int data type• constrained parameter

passing modes (in, out, inout)

• oneway call semantics

• unions require a tag• strings/ sequences are

different • exceptions are

different • etc.

IDL-JAVA-C++ mappings

IDL Java C++Module package namespace

Interface interface abstract class

Operation method member function

Attribute pair of methods pair of functions

exception exception exception

The IDL-to-JAVA mapping

• basic typesIDL JAVAboolean booleanchar charshort shortlong intstring Stringfloat floatoctet bytelong long long

• attributesInterface long myAttribute;

the compiler generates two new methods to access the attribute…

int getmyAttribute() throws omg.corba.SystemException;

void setmyAttribute() throws omg.corba.SystemException;

• interfacesinterface Test {...}

class TestImpl (serv. outline) Object Implementation class Test (stub), Client side

Clients, objects (servants), and servers

• an object or servant is an implementation of an IDL interface type—it ‘incarnates’ an IDL type

• a server holds (potentially many) servants• a client calls a (potentially remote) servant

– must hold an object reference for the servant (see later)• ‘client’ and ‘servant’ are actually roles; e.g. a

servant can also be a ‘client’

Stubs and skeletons

• both generated by the IDL compiler• stubs

– act as proxies for potentially remote servants

– marshal arguments to remote operations and unmarshal results

• skeletons– unmarshal arguments and marshal results

– ‘upcall’ servant

– servants derive from the skeleton class

The ORB core

• implemented as a library linked into both client and server address spaces– there may be separate client and server libraries

• transparently mediates object requests• under the hood...

– connection management– request transfer (e.g., using GIOP/ IIOP)– demultiplexing of requests– threading strategies– etc.

GIOP/ IIOP

• GIOP is an ‘abstract’ protocol that enables inter-operation between heterogeneous ORBs– defines requirements on underlying transport protocol

(layer 4)– defines Common Data Representation (CDR)

• this and IDL are the main CORBA mechanisms for the support of language and system independence

– defines formats and semantics of messages (8 message types in total)

• IIOP is GIOP running over TCP/IP

The GIOP message types

The Portable Object Adapter

• ‘life support environment’ for servants• facilitates server-side portability• demultiplexes incoming requests to target servant• activates servant objects if necessary• manages object references and object IDs

– acts as a local object name (ID) space– POAs can be nested to represent local hierarchical namespaces

• supports various policies– persistent or transient servants– thread pools and priorities– application or POA supplied object IDs– transactional semantics– etc.

Dynamic Invocation Interface (DII)/ Dynamic Skeleton Interface (DSI)

• a slower, less convenient, but more general alternative to static stubs/ skeletons

• DII– enables calling of servants for which we don’t have pre-compiled stubs

• get IDL details from Interface Repository CORBAService• laboriously build the request by ‘pushing’ args onto a ‘request stack’

• DSI – enables request-handling by servants for which we don’t have pre-

compiled skeletons• used by ‘generic’ applications like bridges, debuggers and database

browsers– these must be able to deal with IDL types unforeseen at compile time

• supports an asynchronous-invocation-with-polling invocation mode

A brief overview of CORBA v3

• quite recently released as a coherent package (although many parts have been individually available since 2.x)

• improved ‘internet integration’– XML mapping/ DOM; valuetypes; interoperable name service;

better interoperability with Java; firewall support

• quality of service support– asynchronous messaging (AMI), including QoS directives– minimum-, fault-tolerant- and real-time-CORBA specifications

• distributed component support– development of the CORBA component model (CCM) and

associated CORBA Scripting Language

Part 2: An introduction to programming in CORBA v2.x with

the JAVA mapping

CORBA programming example

• Consider a time service accessible to remote clients...

// JAVA client code; outline only

int main(void)

{ Time timeRef = TimeHelper.narrow(obj);

// call the Time server object and print results

TimeOfDay tod = timeRef.get_gmt();

Print(tod);

}

The IDL specification

// IDLmodule TimeServices {

struct TimeOfDay {short hour; // 0-23short minute; // 0-59short second; // 0-59

};interface Time {

TimeOfDay get_gmt();};

};

IDL-to-JAVA mappings

• module TimeServices– maps to a similarly named JAVA package

• struct TimeOfDay – maps to a similarly named JAVA class (plus constructor) in

TimOfDay folder• interface Time

– Maps to a abstract class called _TimeImplBase which has to be inherited and completed by the programmer

– ...which inherits from a generic class (invisible to the programmer) called org.omg.CORBA.portable.ObjectImpl which encapsulates server skeleton functionality

– also _TimeStub (client stub), and Timehelper, TimeHolder and TimeOperations which are JAVA functionality wrappers

The servant class

class TimeServant extends __TimeImplBase

{

public String get_gmt()

{

return s;

}

}

The server main program//JAVA implemented by the user

public class server {

public static void main(String args[]) {

try{// boilerplate initialisation... // create and initialize the ORB ORB orb = ORB.init(args, null);

// START THE SERVANT HERE...(see next slide) // create servant and register it with the ORB TimeServant timeRef = new TimeServant(); orb.connect(timeRef);

// block waiting for invocations from clients java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); }

} catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out);}}

}

Starting the servant

// JAVA IOR method implemented by the user. There are many other possible ways, e.g. via the naming service.

//...

// create servant and register it with the ORB TimeServant timeRef = new TimeServant(); orb.connect(timeRef);

// stringify the TimeRef and dump it in a file String str = orb.object_to_string(timeRef); String filename = System.getProperty("user.home")+ System.getProperty("file.separator")+"EchoIOR"; FileOutputStream fos = new FileOutputStream(filename); PrintStream ps = new PrintStream(fos); ps.print(str); ps.close();//...

Bringing the server together

Now the client side: the client main program

// JAVA implemented by the userimport java.io.*;import org.omg.CORBA.*;

public class client { public static void main(String args[]) {

try{ // create and initialize the ORB

ORB orb = ORB.init(args, null);

// GET OBJECT REFERENCE HERE TimeOfDay tod = tm.get_gmt();System.out.println(“Time in Greenwich is” + tod);

} catch (Exception e) { System.out.println("ERROR : " + e) ; e.printStackTrace(System.out);}

}}

Getting the object reference// JAVA implemented by the user. There are many other possible ways, e.g. via the naming service.

• // ...

// Get the stringified object reference and destringify it. String filename = System.getProperty("user.home")+ System.getProperty("file.separator")+"echoIOR"; BufferedReader br = new BufferedReader(new FileReader(filename));

String ior = br.readLine(); org.omg.CORBA.Object obj = orb.string_to_object(ior);

Echo echoRef = EchoHelper.narrow(obj);

// call the Echo server object and print results String echo = echoRef.echo("Hello, World"); System.out.println(echo);// ...

Bringing it all together (again)

Running the application (under windows/dos)

C:\ java server server.ior – run server in the background and direct to a file

the stringified reference that it prints

C:\ java client server.ior– pass the result of cat’ing the stringified

reference file to the client as argv[1]

Expected learning outcomes

• you should be able to place the OMG’s OMA and CORBA in the overall context of middleware systems

• you should appreciate the role of the OMG in the middleware standardisation arena

• you should understand basic CORBA concepts in concrete programmatic terms

• you should be able to write simple CORBA programs (post today’s PM session at least!)

• you should appreciate the main additional features in CORBA v3.0 – you’ll learn more about the CCM later...