IDL to Java Mapping
CORBA IDL Series
Common Concepts
All the IDL types when mapped to Java, output two classes
- Holder
- Helper
Holder classes are used to simulate the C++ reference passing style. Consider for example, some generated method as below
void foo(Bar b) {
b = new Bar();
b.init(...); // probably reading from nw
return b;
}
Now, in this scenario, the calling function can never get the reference to the created Bar object.
In CORBA, the above scenario could be using network to read the value of a new Bar object and then make available the value to the calling function - typical out or inout parameters. To take care of this, Holder objects are used. For every Bar object there will be a BarHolder object which can read the Bar object from the wire (as it implements org.omg.CORBA.portable.Streamable interface). A typical scenario could be like -
void callingFunction() {
BarHolder holder = new BarHolder();
foo(holder);
Bar b = holder.value;
...
}
void foo(BarHolder holder, InputStream is) {
holder._read(is); // read from nw; part of Streamable interface
return holder;
}
Helper
Helpers have some common functionality for all IDL mapped types (but for Boxed Valuetypes). These are
- Provide read functionality from org.omg.CORBA.portable.InputStream. Infact holders finally call this for the contents they are holding.
- Provide write functionality to the org.omg.CORBA.portable.OutputSteam
- Return the typecode of the IDL type
- Return the repository Id of the IDL type
- Repository Id and typecode of the IDL type
- Extraction and Insertion operators to CORBA Any
- Narrow and safe narrows from base types. Please note that for Abstract interfaces, the narrow and safe narrow functionality is provided from java.lang.object. For those interfaces which inherit from abstract interfaces, narrow and safe narrow allow from both java.lang.object and org.omg.CORBA.Object and for pure interfaces, only org.omg.CORBA.Object is allowed
- VisiBroker prorpritory bind operations are provided for both abstact and interfaces (but not for local interfaces)
- Convinience factory operations for Valuetypes
All the main java mapping classes for IDL types implement or extend from this class. This class is used in for the reverse mapping (Java to IDL mapping) while marshaling. Typically, the marshal engine will detect that an entity is an instance of this interface and call the helper classes to marshal and unmarshal.
This class inherits from java.io.Serializable.
Mapping from IDL basic types to Java
boolean -> boolean
char -> char
wchar -> char
octet ->byte
string -> java.lang.String
wstring -> java.lang.String
short and unsigned short -> short
long and unsigned long -> int
long long and unsigned long long -> long
float -> float
double -> double
fixed -> java.math.BigDecimal
Constants
Constants can be defined either in the module scope or an interface scope. Mapping for these both is different in Java.
Constants in Module namespace
These are mapped to public interface with the same name as the constant and containing a field named "value" holding the constants value.
Constants in Interface namespace
The mapping is to fields in either the Java operations interface for non-abstract or the sole Java interface for the abstract interface.
Example
// IDL
module Bar {
interface Foo {
const long FooLong = 1;
};
const long BarLong = 2;
}
// Java
package Example;
public interface FooOperations {
int FooLong = 1;
}
public interface BarLong {
int value = 2;
}
Mapping for Structs and Unions
Structs are mapped to a final Java class with the same name as the IDL struct with the following charecteristics
- Implements org.omg.CORBA.portable.IDLEntity interface
- All the IDL struct members are public fields in the mapped class.
- All value and null constructors are also provided. Strings are given "" as default value.
Unions are also mapped to a final Java class with the same name as the IDL union with the following characteristics
- Implements org.omg.CORBA.portable.IDLEntity interface
- accessor method for the descriminator with the name discriminator(). No modifier
- accessor and modifier for each branch
- modifier for each branch with more than one case label
- modifier for the branch corresponding to the default case label if present
- default modifier if needed
Example
// IDL
struct StructType {
long field1;
string field2;
};
enum EnumType { first, second, third, fourth, fifth};
union UnionType switch(EnumType) {
case first: long win;
case second: short place;
case third:
case fourth: octet show;
default: boolean other;
};
//Java
final public class StructType implements org.omg.CORBA.portable.IDLEntity {
public int field1;
public string field2 = "";
public StructType() {}
public StructType(int f1, string f2) {...}
}
final public class UnionType implements org.omg.CORBA.portable.IDLEntity {
public UnionType() {...}
public EnumType descriminator() {...}
public int win() {...}
public void win(int i) {...}
public short place() {...}
public void place(short s) {...}
public byte show() {...}
public void show(byte b) {...}
public void show(EnumType d, byte value) {...}
public boolean other() {...}
public void other(boolean b) {...}
public void other(EnumType e, boolean b) {...}
}
Enums
An enum is mapped to a Java final class implementing IDLEntity interface as below. Helper and Holder classes are generated.
// IDL
enum EnumType {first, second}
// Java
public final class EnumType implements org.omg.CORBA.portable.IDLEntity {
protected EnumType(int i) { ...}
public int value() {...}
public static EnumType from_int(int v) {...}
public static final int FIRST = 0;
public static final EnumType first = new EnumType(FIRST);
public static final int SECOND = 0;
public static final EnumType second = new EnumType(SECOND);
}
Sequence and Arrays
An IDL sequence is mapped to a Java array with the same name. In the mapping, everywhere the sequence type is needed, an array of the sequence type is used. Bounds checking is done at the time of marshalling CORBA::MARSHAL exception will be raised.
An array is mapped just like bound sequence.
Helper and Holder classes are generated.
Exceptions
Their mapping is similar to structs. All CORBA user exceptions inherit from org.omg.CORBA.UserException which is a checked exception and implements org.omg.CORBA.portable.IDLEntity. Helper and Holder classes are also generated.
System exceptions are unchecked exceptions which inherits from java.lang.SystemException.
Interfaces
Apart from a Helper and a Holder class, an Interface is mapped to -
- Operations interface with the same name as the IDL interface suffixed by "Operations"
- Signature interface inheriting the operations interface, org.omg.CORBA.portable.IDLEntity and org.omg.CORBA.Object interfaces.
Portability
Since java code is often downloaded over the web and used with ORBs that are different from where it was developed, a need for portability layer which the generated stubs and skeletons can use arises. If the stubs and skeletons were coupled with the ORB, then for the downloaded code to work, the entire ORB aswell will also be needed to be downloaded.
To achieve this approach, two styles can be implemented by the ORB vendors -
- Streaming style Stubs and Skeletons - Uses the various stream classes
- DII/DSI style Stubs and Skeletons - Uses the DII/DSI Request objects and anys.
Tha major components to this architecture are -
- Portable Streamable layer - provided by org.omg.CORBA.portable.Streamable interface. This interface helps in providing the notion of complex streamable objects are implemented in the helper classes.
- Portable Stream classes - org.omg.CORBA.portable.OutputStream wraps the logic of outputting CORBA IDL types to a stream. This object can be got by using ORB.create_output_stream() method. From this object, org.omg.CORBA.portable.InputStream object can be got which allows to read CORBA data from a stream. These two classes inherit from java.io.OutputStream and java.io.InputStream. Package org.omg.CORBA_2_3.portable provides two more input and output classes.
- Portable Skeletons and Stubs
- Portable Stub and Servant Delegate
Client Side Mapping
- Stub inherits from org.omg.CORBA.portable.ObjectImpl and implements the Signature interface.
- Signature interface inherits from the Operations interface and org.omg.CORBA.portable.Object
- org.omg.CORBA.portable.ObjectImpl implements org.omg.CORBA.Object
- org.omg.CORBA.portable.ObjectImpl uses org.omg.CORBA.portable.Delegate
- Stub inherits from com.inprise.vbroker.CORBA.portable.ObjectImpl and implements the Signature interface.
- Signature interface inherits from the Operations interface and org.omg.CORBA.portable.Object
- com.inprise.vbroker.CORBA.portable.ObjectImpl extends org.omg.CORBA_2_3.portable.ObjectImpl and implements com.inprise.vbroker.CORBA.Object
- com.inprise.vbroker.CORBA.Object extends org.omg.CORBA.Object
- org.omg.CORBA_2_3.portable.ObjectImpl extends org.omg.CORBA.portable.Object
- com.inprise.vbroker.CORBA.portable.ObjectImpl uses com.inprise.vbroker.orb.DelegateImpl which inherits from com.inprise.vbroker.CORBA.portable.Delegate which inturn extends org.omg.CORBA_2_3.portable.Delegate further extending org.omg.CORBA.portable.Delegate
Server Side Mapping
On the server side, an implementation can be provided either by using
- Inheritance
- Delegation
If a Stream based skeleton is being used, then the skeleton inherits from org.omg.PortableServer.Servant and futher implements org.omg.CORBA.portable.InvokeHandler. This class then uses the various stream classes for reading and writing data. Otherwise, org.omg.CORBA.DynamicImplementation is the base class.
org.omg.PortableServer.portable.Servant uses org.omg.PortableServer.Delegate to delegate all its functionality. Generally, this is initialized by calling ORB.set_delegate() which then creates a delegate object and calls back setting the delegate on this servant. In VisiBroker, this delegate object is com.inprise.vbroker.poa.ServantDelegate.
posted by Sandesh Udupa at 1:56 PM
|
4 comments
