In some cases, you may wish to use another vendor’s ORB in your client applications. For example, you may have an existing installation of the ORB on client workstations.
Clients that use another ORB can use the same code as for the EAServer ORB, except for the following differences:
You must use stub classes generated by the vendor’s IDL-to-Java compiler rather than stubs generated by EAServer Manager.
Your code to connect to EAServer and instantiate components may differ.
When executing methods, you may wish to use the EAServer conversion classes to create and interpret the predefined EAServer datatypes (see “Binary, fixed-point, date/time, and ResultSet types”). These conversion classes, in packages com.sybase.CORBA.jdbc102 and com.sybase.CORBA.jdbc11, are documented in Chapter 1, “Java Classes and Interfaces,” in the EAServer API Reference. The classes are compatible with any Java ORB.
You should generate stubs for your third-party ORB using the IDL-to-Java or IDL-to-C++ compiler provided by the vendor. Stubs created by EAServer Manager are not guaranteed to work with another ORB.
Each component’s IDL interfaces are specified in the Component Properties window, under the General tab. See “Configuring component properties” for more information. All interfaces are defined in IDL modules that are stored as plain text files in the EAServer Repository subdirectory. For example, if the component implements the Module1::I1 and Module2::I2 interfaces, you will need to copy the files Module1.idl and Module2.idl into a working directory for generating stubs for your third-party ORB software. You must also copy any files that are included by these modules, including those listed in Table 12-4: “Predefined EAServer IDL files”.
As an alternative to copying files, you can open modules in the EAServer IDL editor and use File | Save As to save them to your working directory. See “Creating and editing IDL modules, interfaces, and types” for more information.
Table 12-4 lists the names of the predefined EAServer IDL modules that are needed by all client applications.
Filename |
Description |
|---|---|
SessionManager.idl |
Defines interfaces for session-based creation of EAServer component instances. |
BCD.idl |
Defines the CORBA datatypes for EAServer’s binary and fixed-point numeric datatypes. |
MJD.idl |
Defines the CORBA datatypes for EAServer’s date and time datatypes. |
TabularResults.idl |
Defines the CORBA datatypes that represent result sets returned by a method invocation. |
WARNING! When creating stubs for another ORB, do not overwrite the EAServer Java stubs in the EAServer html/classes subdirectory. Use different package names when creating stubs for third-party ORBs or create the third-party ORB stubs under a different code base.
EAServer’s naming service cannot be used with other client ORBs, so you must use the EAServer SessionManager::Manager interface to instantiate components from another ORB, as described in “Instantiating proxy instances”. Set the org.omg.CORBA.ORBClass property to the name of the class provided by your ORB vendor.
Also, you must use standard format IORs, not the URL format, as described in “Standard format IORs”.
To simplify applet deployment, you can use one of the following techniques to avoid coding IORs into deployed HTML or Java class files:
Code your applets to open an HTTP connection to the server, then retrieve the contents of the server-generated .ior file that contains the IOR. (See “Standard format IORs” for more information on the generated .ior files.)
If your third-party ORB provides a name service, store the IOR for EAServer in the third-party name service.
