[jacorb-developer] Meaning of each generated file by JacORB IDL compiler

[Phil Mesnier]

Hi Nick,

Kujtim and I took the discussion of the list for a while. He was looking for some concise annotation of the generated java files that he could reference in a paper. 

Here's what I gave him. I suppose I should have posted it earlier so others can improve it.

> The IDL compiler maps CORBA Interfaces, which define CORBA Objects, int Java
> code which can be invoked by applications. To achieve this, a set of Java files
> containing both classes and interfaces are generated.
> 
> The set of generated files is saved as a collection in a the path derived from
> module names in the IDL file. If an interface contains nested type definitions
> such as exceptions, the generated files for these types will be saved in a
> subdirectory named for the containing interface. Thus, given an interface:
> 
> module Controls {
> 
>   interface Termostat {
>      readonly attribute long minTempAllowed;
>      readonly attribute long maxTempAllowed;
>      exception TempNotAllowed {short deviceID;};
>      void setTemperature(in short devID) raises (DeviceNotFound, TempNotAllowed);
>   };
> 
> };
> 
> The IDL compiler will generate:
> 
> $BASE_DIR/Controls/Termostat.java
> $BASE_DIR/Controls/TermostatHelper.java
> $BASE_DIR/Controls/TermostatHolder.java
> 
> These first three files define classes that are used directly by the
> application developer.
> 
> The file with the same name as the IDL interface contains a Java interface
> which combines the mapped operations along with CORBA specified functionality.
> 
> The Helper class provides utility functions, most commonly <T>.narrow() used
> to cast a reference as the object's type.
> 
> The Holder class is used as a container for receiving "out" arguments from
> an operation.
> 
> $BASE_DIR/Controls/TermostatPOA.java
> $BASE_DIR/Controls/TermostatPOATie.java
> 
> These files are used in the implementation of the CORBA object. The <T>POA
> class is an abstract base class that provides the linkage between the server-
> side ORB infrastructure and the application's servant code. In this case the
> servant code extends the <T>POA, providing the implementation defined by the
> Object's operations
> 
> The <T>POATie performs the same function as the POA, but accepts any application
> class that implements the Object's operations as a delegate for the servant. In
> this case one could have a single Java servant object that implements multiple
> interfaces, being used as a shared delegate.
> 
> $BASE_DIR/Controls/TermostatOperations.java
> $BASE_DIR/Controls/_TermostatStub.java
> 
> The <T>Operations file contains a Java interface including all of the mapped
> operations defined in the IDL file. It is not used directly by application code,
> apart from being implemented by the servant.
> 
> The _<T>Sub file contains the ORB infrastructure elements necessary on the client
> side to send requests to remote objects. A narrowed CORBA object is implemented
> on by this stub. While the stub exists in the client application's address space,
> application should only use the operations as defined by the IDL.
> 
> $BASE_DIR/Controls/TermostatPackage/TempNotAllowed.java
> $BASE_DIR/Controls/TermostatPackage/TempNotAllowedHelper.java
> $BASE_DIR/Controls/TermostatPackage/TempNotAllowedHolder.java
> 
> These files fit the same roles as those mentioned above. There are no POA or _stub
> classes since there are no operations associated with exceptions.
> 



--
Phil Mesnier
Principal Engineer & Partner

OCI | WE ARE SOFTWARE ENGINEERS.
tel  +1.314.579.0066 x225
ociweb.com