Interfaces: references, inheritance, and operations
Objective
Describe the mapping of an IDL interface to Java interfaces and classes.
Interfaces: References, Inheritance, and Operations using Corba
IDL interfaces represent the core of communication with CORBA. The full mapping of an IDL interface to Java is complex and is dealt with more fully in the next module. Here we introduce the basics of that mapping to provide a framework for discussing client programming. Interfaces and types defined in IDL result in multiple .java files for each IDL element type to be mapped.
In addition to the class generated for the element itself, one or more extra classes contain helper methods, holders (which we will talk about later in this module), and any additional vendor-specific code.
Object References
The object reference primitive type ‘object’ in IDL maps to a Java interface org.omg.CORBA.Object. So regardless of the vendor's underlying implementation of the object reference stub, the Java programmer needs to deal only with an object of type org.omg.CORBA.Object. Any interface defined in IDL will, along with a few other classes, result in a Java interface that extends the org.omg.CORBA.Object interface. The interface will be placed in the package defined from the module. All operations in the interface will be inserted into the Java interface.
The following series of images below shows some of the class elements generated for an IDL interface definition:
Interfaces: references, inheritance, and operations
Interface Definition Language (IDL)
Another fundamental piece of the CORBA architecture is the use of the Interface Definition Language (IDL). IDL, which specifies interfaces between CORBA objects, is instrumental in ensuring CORBA's language independence. Because interfaces described in IDL can be mapped to any programming language, CORBA applications and components are thus independent of the language(s) used to implement them. In other words, a client written in C++ can communicate with a server written in Java, which in turn can communicate with another server written in COBOL, and so forth.
One important thing to remember about IDL is that it is not an implementation language. That is, you can't write applications in IDL. The sole purpose of IDL is to define interfaces; providing implementations for these interfaces is performed using some other language. When you study IDL more closely on Day 3, you'll learn more about this and other assorted facts about IDL.
Inheritance
To use remote references, only the interfaces are needed. Therefore, programmers can be protected from the vendor-specific stubs. If the IDL interface inherits from other IDL interfaces, the Java interface will take advantage of the ability of Java interfaces to deal with multiple inheritance, and extend from all the other generated interfaces as expected.
Elements defined in Interfaces
When complex IDL elements (struct, union, etc.) are defined within an interface, then the interface is used as a scope mechanism just like a module. A subpackage is created for the interface just as if it was a module. But because there is already a class file with the interface name, the package can not have the name as the interface. So the package is named InterfaceNamePackage.
In the next lesson, you will learn how to describe the mapping of IDL primitive types to Java types.