Download Java IDL (CORBA)

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
of 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
other 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
octet
byte
short/unsigned short
short
long/unsigned short
int
long long/ unsigned long long
long
float
float
double
double
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_CONVERSIONexception
• 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
module M1 { … };
//Java
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,
org.omg.CORBA.Object,
org.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
org.omg.CORBA.UserException{
…
}
BR 11/05
Exceptions
• Inherit from java.lang.Exceptions
• CORBA::SystemExceptions are
RuntimeExceptions
• UserExceptions inherit from
org.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
obj.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,
• Java
public class Color …{
public static final
public static final
public int value() {
public static Color
...
}
green};
int _red=0;
Color red=new Color(_red);
... }
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:
org.omg.CORBA.ORBClass=org.openorb.CORBA.ORB; e.g. null
• Obtain object reference
– from IOR or INS
org.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
obj=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
BR 11/05