Corba IDL Mapping Module in Java

In CORBA, mapping an IDL module to Java involves leveraging an "IDL-to-Java compiler" like `idlj` and understanding the underlying mapping rules. Here's a breakdown of the process:

1. IDL-to-Java Compilation:
   • You provide the "IDL file" containing the module definition.
   • The compiler translates the IDL module into corresponding "Java classes and interfaces".
   • This mapping adheres to the "OMG IDL to Java Language Mapping Specification".
2. Mapping Details:
   • Module: An IDL module maps directly to a "Java package". The package name matches the module name in the IDL file.
   • Interfaces: Each "IDL interface" within the module gets translated into a "Java interface". This interface mirrors the methods, parameters, and return types defined in the IDL.
   • Data Types: IDL data types like `string`, `long`, and `struct` are translated to their equivalent Java types like `String`, `int`, and custom classes.
3. Additional Generated Files:
   • Besides the interface class, the compiler often generates auxiliary classes like "stubs, skeletons, holders, and helpers". These classes facilitate communication between the client and server in a distributed CORBA environment.
   
   

Remember, using CORBA and legacy technologies like IDL may not be as common in modern development. However, understanding the mapping process can still be valuable for working with existing systems or exploring historical technologies.

Modules in IDL

1. define the scoping of all other elements
2. define the structure of all the other elements defined in that IDL.

All elements should be contained within a module, for organizational purposes as well as to prevent name clashes. The purpose of a module is exactly the same as that of a package in Java, therefore a module in IDL maps directly into a Java package.

Classes generated for elements defined within a module are placed within that Java package, and likewise into a directory for that package. Modules within modules become subpackages. So the IDL code shown below:

module MyTopMod {
    module ModTwo {
       module ModThree {
   } ;
       module ModFour {
       };
    };
    module ModFive {
    }
};

MyTopMod -+
          +--ModTwo -+
          |          +--ModThree
          |          +--ModFour
          |
          +--ModFive

Many IDL compilers will allow you to specify a base package name that is prepended to all packages generated for modules. This allows individual companies to generate classes in line with "Java standards for package naming".

This convention for package names holds that all packages produced should start with the domain name reversed. For example, if the producing company is xenotrope.com, all packages would start with com.xenotrope. If the producing company is the computer science department at Yale University, all packages would start with edu.yale.cs. These package names are generated for use with a particular implementation.
This base package does not have to be consistent across different system parts (although it is easier) even if they are communicating with the same IDL interfaces. The runtime creation of 1) stubs and 2) helper instances when dealing with a remote reference is based on the IDL interface repository ID for the IDL interface, not the Java classes of the remote implementation. The ORB core will find the classes with which the specific application was compiled.
In the next lesson, you will learn how to describe the mapping of an IDL interface to Java interfaces and classes.