1168-1171

Previous Table of Contents Next

Page 1168

 public int value() {              return _value;          }  public static final TransType from_int(int i)  throws  org.omg.CORBA.BAD_PARAM {                    switch (i) {                          case _DEPOSIT:                              return DEPOSIT;                      case _WITHDRAWAL:                          return WITHDRAWAL;                      default:                       throw new org.omg.CORBA.BAD_PARAM();                    }          }          private TransType(int _value) {                  this._value = _value;          }          private int _value; } 

The constructor here is private (there will be only one instance), and the int equivalent members are defined for use in the switch statement. This mapping might seem awkward , but it is necessary because Java does not define a true enumerated type.

In some cases, an OMG IDL constant is mapped to a public static final Java class. Specifically, constants declared outside any interface are mapped to a Java class, as in this example:

 module SavingsAndLoan {     const float MAX_INSURANCE = 100000; } 

This IDL is mapped to the following Java class:

 package SavingsAndLoan; public final class MAX_INSURANCE { public static final float value = (float) (100000L); }; 

To achieve a more natural mapping of constant values, consider defining related constants in a dedicated interface.

OMG IDL interfaces are mapped to a public Java interface and a public abstract class that must be extended by the implementation. Type declarations within an IDL interface are mapped to the appropriate Java types in a separate package. For example, consider the following module:

 module Bank {     interface Account {         enum TransType {DEPOSIT, WITHDRAWAL};         exception OVERDRAFT {             float withdrawal_amt;             float balance;         }; 

Page 1169

 struct TransInfo {             long AcctNo;             TransType trans;             float amt;         };         void ApplyNormalTransaction(in TransInfo tran) throws OVERDRAFT;     }; }; 

This module is mapped to two packages. The Bank package contains the Java interface and implementation base for the Account interface, which includes the ApplyNormalTransaction() operation only. A second package, Bank.AccountPackage, contains the classes for the TransType enumeration, the OVERDRAFT exception, and the TransInfo struct. The mapping does not nest these declarations within the Account base class.

OMG IDL sequences and arrays defined in structs and interfaces are mapped to unbounded public arrays of Java instance variables . All three of the following interface definitions result in the same Java source, for example:

 struct array {     short thevalues[10]; }; struct array {     sequence<short, 10> thevalues; }; struct array {     sequence<short> thevalues; }; 

Regardless of which of these definitions is used, the array class is generated as below:

 public final class array { // instance variables         public short[] thevalues;         // constructors         public array() { }         public array(short[] __thevalues) {         thevalues = __thevalues;         } } 

Differences exist in the Helper classes only. Helper and Holder classes are generated for each type that is mapped to a Java class, and Stub classes are generated for each interface. These classes have been omitted from the mapping discussion until this point because they are used primarily by ORB-specific functions and generally are unrelated to developing server implementations and client invocations when the supplied ORB core is used. A Holder class is generated for each user -defined IDL type to support out and inout parameters. Holder classes for each of the basic IDL types are included in org.omg.CORBA. Helper classes are generated to support the insert and extract operations, to get the repository ID and type information, and to read and write the type from and to a stream. These classes are generated to be used with the generic ORB core (org.omg.CORBA.ORB) supplied with JavaIDL. Implementers are free to extend this class to provide additional features.

Page 1170

Generating Java Source from IDL

Java source is generated from IDL using idltojava.exe. Switches are used to specify whether the client-side or server-side source should be generated, should pass parameters to the preprocessor, and so on. idltojava requires an external C preprocessor, so a minimal C compiler implementation must be installed. Suppose that source code is being generated for an IDL file named scott.idl with the declarations shown in Listing 52.2.

Listing 52.2. IDL source to create Java classes.

 module scott {     exception DBException {         short     ErrorCode;         string  SQLState;         string  Message;     };     struct DeptData {         long     deptno;         string     dname;         string  loc;     };     interface Dept {         void openList() raises(DBException);         DeptData fetchNext() raises(DBException);         void closeList() raises(DBException);         void insert(inout DeptData dept) raises(DBException);         void update(in DeptData dept) raises(DBException);         void delete(in DeptData dept) raises(DBException);     }; }; 

The files required by the client to access the Dept interface would be generated as the following:

 idltojava -fclient scott.idl 

This code creates a scott directory and package, including the following files and Java classes:

 DBException.java      DBExceptionHelper.java      DBExceptionHolder.java      Dept.java      DeptData.java      DeptDataHelper.java      DeptDataHolder.java      DeptHelper.java      DeptHolder.java      DeptStub.java 

Page 1171

The Helper and Holder classes are generated for each defined type, as well as implementations for the exception and structs; a client stub and Java public interface are generated for the Dept interface. The base class for the server implementation of the Dept interface (_DeptImplBase.java) is generated by the following command:

 idltojava -fserver scott.idl 

The entire set of files can be generated by a single command:

 idltojava -fclient -fserver scott.idl 

Generated source files should not be modified and must be compiled prior to developing the server implementation of the Dept interface.

Developing the Implementations

An implementation class for each IDL interface must be provided. In Listing 52.2, an implementation of the Dept interface is developed by extending _DeptImpBase. The implementation class does not need to explicitly implement the Dept interface because it is already implemented by _DeptImpBase. The implementation of Dept might be declared as the following:

 public class DeptImpl extends _DeptImpBase 

Only the methods of the Dept interface should be implemented. Do not attempt to override the methods defined in _DeptImplBase. The public Dept interface contains the following methods , which were declared in the IDL:

 void openList() throws scott.DBException; scott.DeptData fetchNext() throws scott.DBException; void closeList() throws scott.DBException; void insert(scott.DeptDataHolder dept) throws scott.DBException; void update(scott.DeptData dept) throws scott.DBException; void delete(scott.DeptData dept) throws scott.DBException; 

The developer is free to implement these methods in any manner. For example, JDBC could be used to communicate with an Oracle database. The implementation class is not restricted to these methods, but any additional methods defined will not be visible to the client, even when declared as public.

Binding Server Objects in the Name Service

In order for clients to access CORBA objects, they must be able to obtain an initial reference. This is accomplished by using the name server. The server process must bind at least one object in the name server.

Before an object can be bound with the name server, the name server must be running. JavaIDL implements a simple name server as a Java class and generates a script to start the name server as part of the installation. When properly installed and configured, the name server can be started with the following command:

 nameserv -ORBInitialPort portnum 
Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net