1164-1167

Previous Table of Contents Next

Page 1164

which is equivalent to writing a single accessor to read a value. The interface defined here demonstrates the use of attributes:

 interface Customer {     readonly attribute long InternalID;     attribute string Name; }; 

This definition is roughly equivalent to writing the following:

 interface Customer {     long internalID();     void Name(in string NameIn);     string Name(); }; 

OMG IDL type definitions can be nested inside an interface, as demonstrated by this definition:

 interface Bank {     struct Account {         long AcctNo;         long CustomerID;         float Balance;     };     void openAccount(in Account NewAcct); }; 

Type declarations must be unique within a defined scope, though; in external scopes where name conflicts may exist, the context should be identified explicitly. The following set of definitions is legal and unambiguous:

 interface AccountTransaction {     struct Account {         long  AcctNo;         float Amount;     };     void adjust(in Account AdjustmentInfo); }; interface Bank {     struct Account {         long AcctNo;         long CustomerID;         float Balance;     };     void freezeAccount(in Account DeadAcct); }; interface Audit: AccountTransaction, Bank {     void pullAccount(in Bank::Account AuditAcct); }; 

Two different Account structs are defined in separate interfaces, both of which are inherited by Audit. Notice the parameter to pullAccount() in the Audit interface. The Bank:: prefix must be applied to Account to avoid ambiguity. The following declaration is not legal:

Page 1165

 interface Audit {     struct Account {         long  AcctNo;         float Amount;     };     void adjust(in Account AdjustmentInfo);     struct Account {         long AcctNo;         long CustomerID;         float Balance;     };     void freezeAccount(in Account DeadAcct); }; 

Conflicting declarations of a named type or operation within the same scope are not permitted.

OMG IDL allows the definition of user -defined exceptions. An IDL exception can be viewed as a specialized struct, which can be raised by an interface's operations. An example exception definition follows :

 exception VERY_BAD_NEWS {     string WhatHappened;     string Why;     string WhatCanIDo; }; 

After an exception is defined, it can be raised by an operation ( assuming that it is visible within the scope of an interface). The following interface has an operation that raises the user-defined VERY_BAD_NEWS exception:

 interface Account {     void withdraw(in long AcctNo, in float Amt) raises(VERY_BAD_NEWS); }; 

All OMG IDL interface and type declarations can be enclosed in a module. The module name is used by IDL-based code generators to determine how source code is organized. An IDL-to-C++ tool, for example, may generate a header and source file with the same name as the module. An IDL-to-Java implementation might generate a package based on the module name. The filename in which a module is stored also can be used with the #include directive of the preprocessor to make an existing IDL file's definitions visible in another IDL file. A single module and IDL file can be used to declare all user-defined exceptions, for example:

 module BigProblems { exception VERY_BAD_NEWS {         string WhatHappened;     string Why;         string WhatCanIDo; }; }; 

Page 1166

Suppose that the module definition is saved in a file called BigProblems.idl. This exception could be used in any IDL file that includes BigProblems.idl, as illustrated here:

 #include "BigProblems.idl" module Bank {     interface Account {         void withdraw(in long AcctNo, in float Amt)                  raises(BigProblems::VERY_BAD_NEWS);     }; }; 

Because VERY_BAD_NEWS is not defined within the Bank module, it must be prefixed with the module name to determine the scope in which it is defined.

The simple examples covered in this section present some of the most commonly used features in the IDL specification. OMG IDL contains a number of interesting features that have not been discussed, but the information provided in this section should be sufficient for a basic understanding of the language.

NOTE

The CORBA specification is the definitive source for additional information on OMG IDL. It is available online at http://www.omg.org

Developing Java-Based CORBA Services

Currently, a number of Java-based ORB products are available; this section focuses on CORBA development using JavaIDL from JavaSoft. In addition to providing a basic ORB implementation, JavaIDL provides the low-level libraries required to develop a custom ORB from the ground up. Although it is currently in a prerelease format, JavaIDL is the most widely available implementation, and its open design facilitates the demonstration of CORBA concepts. All examples presented in this section are based on the prerelease 1.1 version of JavaIDL.

IDL-to-Java Mapping

The IDL-to-Java mapping presented here has not been officially incorporated into the OMG standard. OMG currently is accepting proposals for a standard Java mapping, and it seems logical that the creators of Java would have an inside track.

JavaSoft JavaIDL defines mappings for all types defined in the CORBA specification. At the highest level, the module name is mapped to a Java package. At the lowest level, the OMG IDL basic types are mapped to their Java equivalents. Table 52.5 lists the current mapping of basic types.

Page 1167

Table 52.5. IDL-to-Java mappings.

---

IDL Type	Java Type
boolean	boolean
char	char
wchar	char
octet	byte
string	java.lang.String
wstring	java.lang.String
short	short
unsigned short	short
long	int
unsigned long	int
long long	long
unsigned long long	long
float	float
double	double

OMG IDL structs, unions, enumerations, and exceptions are mapped to Java classes. OMG IDL structs and exceptions are mapped to a public final class that contains public instance variables corresponding to the members of the struct or exception. These structs and exceptions are generated with a default constructor and a constructor that can be used to initialize all the members . The primary difference between the resulting Java classes is that a class generated from an IDL exception inherits from java.lang.Exception, for obvious reasons.

IDL unions are generated as public final Java classes containing private instance variables to represent the discriminator, each branch (including the default), and the public accessor functions. Only a get() method is generated for the discriminator.

IDL enumerations are mapped to a public final class with a public value() method, two public static variables per named value, and an integer conversion function. For example, the enumeration defined in IDL as

 enum TransType {DEPOSIT, WITHDRAWAL}; 

results in a Java class defined as this:

 public final class TransType { public static final int    _DEPOSIT = 0,                   _WITHDRAWAL = 1;          public static final TransType     DEPOSIT = new TransType(_DEPOSIT);          public static final TransType     WITHDRAWAL = new TransType(_WITHDRAWAL); 

Previous Table of Contents Next