JAVA Language Mapping Java IDL (CORBA) introduced in Version 1.2 - - PDF document

BR 11/05

JAVA Language Mapping

BR 11/05

Java IDL (CORBA)

• introduced in Version 1.2 of the Java 2 platform,

– provides an interface between Java programs and distributed objects and services built using the Common Object Request Broker Architecture (CORBA).

• CORBA is defined by the Object Management Group (OMG).

– describes an architecture, interfaces, and protocols that distributed objects can use to interact with each other. – Interface Definition Language (IDL) is an implementation-independent language for describing the interfaces of remote-capable objects.

• Standard mappings for converting IDL interfaces

– into C++ classes, C code, and Java classes, – generated classes use the underlying CORBA framework to communicate with remote clients – Java IDL is Sun's implementation of the standard IDL-to-Java mapping – standard Java SDK in the org.omg.CORBA package, the org.omg.CosNaming package, and other org.omg .* packages.

BR 11/05

A Note on Evolving Standards

• At the time of Java 2 Version 1.2, the CORBA specification and the

IDL-to-Java binding for CORBA were in a bit of flux.

– The server-side object adaptor interface had been altered significantly by the OMG in Version 2.3 of the CORBA specification. – The Basic Object Adaptor (BOA) interface had been replaced by the Portable Object Adaptor (POA). – This filled a gap in the specification left by the BOA that led to vendor-specific extensions and, therefore, CORBA server objects that were dependent on particular vendor ORB implementations.

• IDL-to-Java mapping took some time to be updated to support POA

– JDK 1.2 was released before the new version of the Java mapping. – By the time JDK 1.4 was introduced in beta in 2001, the POA-compatible version

• f the IDL-to-Java mapping had been released, and the Java IDL packages, as

well as the IDL-to-Java compiler in JDK 1.4, were based on this mapping.

BR 11/05

IDL Primer

• The syntax of both Java and IDL were modeled on C++

– Interfaces in IDL are declared much like classes in C++ and, thus, classes or interfaces in Java.

• The major differences between IDL and Java are:
• IDL is a declaration language.

– In IDL, you declare only the names and types for interfaces, data members, methods, method parameters, etc. – Method implementations are created in the implementation language you choose (in this case Java), after you've used an IDL compiler to convert your IDL interface to your target language.I

• IDL, like C++ , includes nonclass data structure

definitions, like structs, unions, and enumerations.

BR 11/05

IDL Primer (contd.)

• Method parameters in IDL include modifiers that specify

whether they are input, output, or input/output variables.

– In Java, all primitive data types are passed by value, and all object data types are passed by reference.

• An IDL file can include multiple public interfaces.

– Only a single public class can be defined in a given Java file (although Java does allow for multiple inner classes within a single public class definition, and multiple nonpublicclasses per file). – Modules, which are similar to Java packages, can be nested within

• ther modules in the same IDL file, and interfaces in multiple distinct

modules can bedefined in the same IDL file. – In Java, you can define a class only within a single package in a single Java file.

BR 11/05

Standards (contd.)

• Interoperable Naming Service (INS) interface adds new

utilities and functionality on top of the standard CORBA Naming Service.

– INS was incorporated into the CORBA 2.3 specification, and support for it in Java IDL was introduced in JDK 1.4. – If you are using JDK 1.4 or later, you are using a POA-compatible mapping of the CORBA interfaces. – If you are using JDK 1.3 or JDK 1.2, you are using the "pre- POA" version of the IDL-to-Java mapping that Sun used prior to adding the POA support. – JDK 1.4 or later has access to the INS interface and the Naming Service provided with the Java IDL. – The Object Request Broker (ORB) supports these extended features.

BR 11/05

Java Language Mapping

• J2SE 1.4 and J2SE 5.0 comply with CORBA 2.3.1 spec

– formal/99-10-07 – http://www.omg.org/cgi-bin/doc?formal/99-10-07

• Language Mapping

– ptc/00-01-08 – http://www.omg.org/docs/ptc/00-01-08.pdf

BR 11/05

Identifier

• Mapped to Java equivalents except for

– Java keywords – Identifiers ends of –Holder, -Helper, -Operations, -POA, -POATie or –Package are escaped with an underscore – e.g. IDL Java new _new fooHelper _fooHelper

BR 11/05

Primitive Types

IDL Data Type Java boolean boolean char/wchar char string/wstring java.lang.String

• ctet

byte short/unsigned short short double double long/unsigned short int long long/ unsigned long long long float float fixed java.math.BigDecimal

BR 11/05

Types (2)

• Range of Java-char is bigger that IDL-char

– May raise a CORBA::DATA_CONVERSION-exception

• Bounded Strings are mapped to java.lang.String

– may raise CORBA::MARSHAL or CORBA::DATA_CONVERSION- exception

• Big unsigned values are represented as negative

values

• No long double
• TRUE,FALSE => true,false
• No explicit nil-reference, use null instead

BR 11/05

Module

• Mapped to packages with the same name

//IDL //Java module M1 { … }; package M1; module M2 { module M3 { … }; package M2.M3; };

BR 11/05

Interfaces

• Non abstract IDL interfaces are mapped to 2 public java

interfaces

– signature interface – operations interface

• Signature interface

– same name as the IDL interface – used for object references

• Operations interface

– Suffix Operations – includes method definitions

BR 11/05

Interfaces (2)

• IDL

interface Hello{ string sayHello(string msg); };

• Java

public interface Hello extends HelloOperations,

• rg.omg.CORBA.Object,
• rg.omg.CORBA.portable.IDLEntity{}

public interface HelloOperations{ String sayHello(String msg); }

BR 11/05

Attributes

• Pairs of get/set methods in the Operations interface
• IDL

interface I{ attribute short a1; readonly attribute double a2; }

• Java

public interface IOperations{ public short a1(); public void a1(short value); public double a2(); }

BR 11/05

Custom Types

• Defined in a package <interface name>Package
• public final classes
• IDL

interface AskMe{ exception Ex{ string why;}; struct Info{ string name; short age; }; Info getInfo(in long id) raises(Ex); };

BR 11/05

Custom Types (2)

• Java

public interface AskMeOperations{ public AskMePackage.Info getInfo(long id) throws AskMePackage.Ex; } package AskMePackage; final public class Ex extends

• rg.omg.CORBA.UserException{

… }

BR 11/05

Exceptions

• Inherit from java.lang.Exceptions
• CORBA::SystemExceptions are

RuntimeExceptions

• UserExceptions inherit from
• rg.omg.CORBA.UserExceptions

BR 11/05

Holder class

• Java does not know Call-by-reference
• The holder class is a wrapper used when types are

called for as out or inout arguments in an IDL method.

• Implements org.omg.CORBA.portable.Streamable

– public void _read(InputStream istream); – public void _write(OutputStream ostream);

• Predefined for CORBA base types in org.omg.CORBA.

– BooleanHolder, CharHolder, IntHolder, ByteHolder, … – BooleanSeqHolder, CharSeqHolder, IntSeqHolder, …

BR 11/05

Holder class (2)

• inout, out arguments need to be valid objects references
• IDL

long foo(out float val1);

• Java

public long foo(FloatHolder val1);

BR 11/05

Holder class (3)

• Server

public long foo(FloatHolder val1){ val1.value=5; return 42; }

• Client

FloatHolder f=new FloatHolder(); //allocate

• bj.foo(f);

BR 11/05

Helper-class

• All user defined IDL types have an additional “helper” Java

class with the suffix Helper appended to the type name generated

• public static void insert(org.omg.CORBA.Any a,

<Type> that) – Insert into CORBA::Any

• public static <Type> extract(org.omg.CORBA.Any a)

– Extract from CORBA::Any

• public static <Type> narrow(org.omg.CORBA.Object a)

– Cast to interface type – throws CORBA::BadParam on invalid cast (in constrast to C++)

BR 11/05

Constants

• Within an interface

– fields in the signature interface

• Not within an interface

– public interface with the same name – field with the name value

BR 11/05

Enumerations

• Class with 2 static fields per enum value

– int value – Class instance initialized with the enum value

• IDL

enum Color { red, blue, green};

• Java

public class Color …{ public static final int _red=0; public static final Color red=new Color(_red); public int value() { ... } public static Color from_int(int value) { ... }

... }

BR 11/05

IDL-to-Java translation

BR 11/05

Generating Java classes

• Run the idl compiler:

– C:\>idlj -fall Account.idl

• This creates five Java classes:

– a Java version of the interface, – a helper class, – a holder class, – a client stub, and – a server skeleton.

• The -fall option tells the compiler to generate both

client-side and server-side mapping interfaces.

BR 11/05

Client

• Initialize the ORB
• ORB orb=ORB.init(args,properties);

– args commandline arguments –ORB… – properties, environment variables:

• rg.omg.CORBA.ORBClass=org.openorb.CORBA.ORB; e.g. null
• Obtain object reference

– from IOR or INS

• rg.omg.CORBA.Object obj=orb.string_to_object("IOR:….. ");
• Cast to interface

– <Type> t=<Type>Helper.narrow(obj);

• Invoke calls on interface object

BR 11/05

IDL-to-Java (server-side)

• The IDL-to-Java compiler can also generate server-side

skeleton classes

– Can be used for the server-side implementation of the remote CORBA interface.

• Pre-POA:

– server skeleton class called _interface-nameImplBase (e.g., _ServerImplBase), which is a base class for a server-side implementation of the interface.

• POA:

– server skeleton class named <interfaceName>POA (e.g, HelloPOA), which implements a generated interfaceNameoperations interface and extends the POA-related server-side interfaces.

• Inheritance-based approach

BR 11/05

Delegation-based Server Side implementation

• So far, server-side implementation depends on directly

extending a generated class

– interfaceNamePOA or _interfaceNamelmplBase

• The delegation model is based on a scheme in which a

server-side delegate is generated by the IDL compiler.

– This delegate extends the generated skeleton class, and implements each of the mapped remote methods by delegating the incoming method request to a delegate object. – This delegate object needs to implement the interfaceNameOperations interface generated by the IDL compiler, but it doesn't have to extend a concrete or abstract base class. – This can prove to be useful in cases where you have a preexisting Java class with its own inheritance scheme and want to "export" this class through CORBA for remote access.

BR 11/05

Server

• Implement Servant class

– Inherit from <interface>POA

• Initialize ORB
• Obtain a RootPOA reference

– org.omg.CORBA.Object

• bj=orb.resolve_initial_references(„RootPOA“);

– POA rootpoa=POAHelper.narrow(obj)

• Create servant object
• Register servant with ORB

– servant._this(orb); – make IOR availiable to the client,

BR 11/05

Server (2)

• IOR

– String s=orb.object_to_string( servant._this() );

• Activate the POA manager

– poa.the_POAManager().activate();

• Start ORB main loop

– orb.run();

BR 11/05

Further Topics

• Not covered

– Sequences – Arrays – Unions