This topic includes the following sections:
|Notes:||The Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All Oracle Tuxedo CORBA Java client and Oracle Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.|
|Note:||Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.|
The steps for creating a CORBA C++ client application are as follows:
Each step in the process is explained in detail in the following sections.
The Oracle Tuxedo development environment for CORBA C++ client applications includes the following:
idlcommand, which compiles the OMG IDL file and generates the client stubs required for the CORBA interface.
buildobjclientcommand, which constructs a CORBA C++ client application executable.
Generally, the OMG IDL files for the available interfaces and operations are provided to the client programmer by the application designer. This section contains the OMG IDL for the Basic sample application. Listing 2-1 shows the
univb.idl file, which defines the following interfaces:
#pragma prefix "BEAsys.com"
typedef unsigned long CourseNumber;
typedef sequence<CourseNumber> CourseNumberList;
typedef sequence<CourseSynopsis> CourseSynopsisList;
in unsigned long number_to_get,
out unsigned long number_remaining
typedef unsigned short Days;
const Days MONDAY = 1;
const Days TUESDAY = 2;
const Days WEDNESDAY = 4;
const Days THURSDAY = 8;
const Days FRIDAY = 16;
Days class_days; // bitmask of days
unsigned short start_hour; // whole hours in military time
unsigned short duration; // minutes
unsigned short number_of_credits;
unsigned short number_of_seats;
typedef sequence<CourseDetails> CourseDetailsList;
in string search_criteria,
in unsigned long number_to_get, // 0 = all
out unsigned long number_remaining,
out CourseSynopsisEnumerator rest
CourseDetailsList get_courses_details(in CourseNumberList
Select the invocation type (static or dynamic) that you will use in the requests in the CORBA client application. You can use both types of invocation in a CORBA client application.
For an overview of static and dynamic invocation, see Static and Dynamic Invocation.
The remainder of this topic assumes that you chose to use static invocation in your CORBA client application. If you chose to use dynamic invocation, see Using the Dynamic Invocation Interface.
When creating CORBA C++ client applications, use the
idl command to compile the OMG IDL file and generate the files required for the interface. The following is the syntax of the
The IDL compiler generates a client stub (
_c.cpp) and a header file (
_c.h) that describe everything you need to have to use the client stub from the C++ programming language. You need to link these files into your CORBA client application.
In addition, the IDL compiler generates skeletons that contain the signatures of the CORBA object’s operations. The generated skeleton information is placed in the idlfilename
_s.cpp and idlfilename
_s.h files. During development of the CORBA client application, it can be useful to look at the server header files and skeleton file.
|Note:||Do not modify the generated client stub or the skeleton.|
For a complete description of the
idl command and options, see the Oracle Tuxedo Command Reference.
When creating CORBA client applications:
idltojavacommand to compile the OMG IDL file. For more information about the
idltojavacommand, see the documentation for the JDK version 1.2.
idltojava command or the IDL compiler generates the following:
Note that each OMG IDL defined exception defines an exception class and its helper and holder classes. The compiled
.class files must be in the
CLASSPATH of your CORBA client application.
In addition, the
idltojava command or the IDL compiler generates skeletons that contain the signatures of the operations of the CORBA object. The generated skeleton information is placed in the
To participate in a session with a CORBA server application, a CORBA client application must be able to get an object reference for a CORBA object and invoke operations on the object. To accomplish this, the CORBA client application code must do the following:
The following sections use portions of the client applications in the Basic sample application to illustrate the steps. For information about the Basic sample application, see the Guide to the CORBA University Sample Applications. The Basic sample application is located in the following directory on the Oracle Tuxedo software kit:
All CORBA client applications must first initialize the ORB.
Use the following code to initialize the ORB from a CORBA C++ client application:
CORBA::ORB_var orb=CORBA::ORB_init(argc, argv,ORBid
Typically, no ORBid is specified and the default ORBid specified during installation is used. However, when a CORBA client application is running on a machine that also has CORBA server applications running and the CORBA client application wants to access server applications in another Oracle Tuxedo domain, you need to override the default ORBid. This can be done by hard coding the ORBid as
BEA_IIOP or by passing the ORBid in the command line as
The CORBA client application creates a Bootstrap object. A list of IIOP Listener/Handlers can be supplied either as a parameter, via the
TOBJADDR Java property or applet property. A single IIOP Listener/Handler is specified as follows:
When the IIOP Listerner/Handler is provided via
TOBJADDR, the second argument of the constructor can be null.
The host and port combination for the IIOP Listener/Handler is defined in the
UBBCONFIG file. The host and port combination that is specified for the Bootstrap object must exactly match the ISL parameter in the Oracle Tuxedo domain’s
UBBCONFIG file. The format of the host and port combination, as well as the capitalization, must match. If the addresses do not match, the call to the Bootstrap object will fail and the following message appears in the log file:
Error: Unofficial connection from client at <tcp/ip address>/<portnumber>
For example, if the network address is specified as
//TRIXIE::3500 in the ISL parameter in the
UBBCONFIG file, specifying either
//trixie:3500 in the Bootstrap object will cause the connection attempt to fail.
On UNIX systems, use the
uname -n command on the host system to determine the capitalization used. On Window 2000, use the Network Control Panel to determine the capitalization.
The following C++ and Java examples show how to use the Bootstrap object:
Tobj_Bootstrap* bootstrap = new Tobj_Bootstrap(orb, “//host:port”);
Tobj_Bootstrap bootstrap = new Tobj_Bootstrap(orb,“//host:port”,
this is the name of the Java applet
An Oracle Tuxedo domain can have multiple IIOP Listener/Handlers. If you are accessing an Oracle Tuxedo domain with multiple IIOP Listener/Handlers, you supply a list of
Host:Port combinations to the Bootstrap object. If the second parameter of the Bootstrap command is an empty string, the Bootstrap object walks through the list until it connects to an Oracle Tuxedo domain. The list of IIOP Listener/Handlers can also be specified in
If you want to access multiple Oracle Tuxedo domains, you must create a Bootstrap object for each Oracle Tuxedo domain you want to access.
|Note:||Third-party client ORBs can also use the CORBA Interoperable Naming Service (INS) mechanism to gain access to an Oracle Tuxedo domain and its services. CORBA INS allows third-party client ORBs to use their ORB’s
The CORBA client application must obtain initial references to the environmental objects that provide services for the CORBA application. The Bootstrap object’s
resolve_initial_references operation can be called to obtain references to the FactoryFinder, InterfaceRepository, SecurityCurrent, TransactionCurrent, NotificationService, Tobj_SimpleEventsService, and NameService environmental objects. The argument passed to the operation is a string containing the name of the desired object reference. You need to get initial references only for the environmental objects you plan to use in your CORBA client application.
The following C++ and Java examples show how to use the Bootstrap object to resolve initial references to the FactoryFinder object:
//Resolve Factory Finder
CORBA::Object_var var_factory_finder_oref = bootstrap.resolve_initial_references
Tobj::FactoryFinder_var var_factory_finder_ref = Tobj::FactoryFinder::_narrow
//Resolve Factory Finder
org.omg.CORBA.Object off = bootstrap.resolve_initial_references
CORBA client applications get object references to CORBA objects from factories. A factory is any CORBA object that returns an object reference to another CORBA object and registers itself as a factory. The CORBA client application invokes an operation on a factory to obtain an object reference to a CORBA object of a specific type. To use factories, the CORBA client application must be able to locate the factory it needs. The FactoryFinder object serves this purpose. For information about the function of the FactoryFinder object, see CORBA Client Application Development Concepts.
The FactoryFinder object has the following methods:
The following C++ and Java examples show how to use the FactoryFinder
find_one_factory_by_id method to get a factory for the Registrar object used in the CORBA client application for the Basic sample applications:
CORBA::Object_var var_registrar_factory_oref = var_factory_finder_ref->
UniversityB::RegistrarFactory_var var_RegistrarFactory_ref =
org.omg.CORBA.Object of = FactoryFinder.find_one_factory_by_id
UniversityB.RegistrarFactory F = UniversityB.RegistrarFactoryHelper.narrow(of);
CORBA client applications call the factory to get an object reference to a CORBA object. The CORBA client applications then invoke operations on the CORBA object by passing it a pointer to the factory and any arguments that the operation requires.
The following C++ and Java examples illustrate getting the factory for the Registrar object and then invoking the
get_courses_details() method on the Registrar object:
UniversityB::Registrar_var var_Registrar = var_RegistrarFactory->
UniversityB::CourseDetailsList_var course_details_list = Registrar_oref->
UniversityB.Registrar gRegistrarObjRef = F.find_registrar();
The final step in the development of the CORBA client application is to produce the executable for the client application. To do this, you need to compile the code and link against the client stub.
When creating CORBA C++ client applications, use the
buildobjclient command to construct a CORBA client application executable. The command combines the client stubs for interfaces that use static invocation, and the associated header files with the standard Oracle Tuxedo libraries to form a client executable. For the syntax of the
buildobjclient command, see the Oracle Tuxedo Command Reference.
|Note:||You must use the
To process a request from a CORBA client application, the CORBA server application may need to request processing from another server application. In this situation, the CORBA server application is acting as a CORBA client application.
To act as a CORBA client application, the CORBA server application must obtain a Bootstrap object for the current Oracle Tuxedo domain. The Bootstrap object for the CORBA server application is already available via
TP::Bootstrap (for CORBA C++ client applications). The CORBA server application then uses the FactoryFinder object to locate a factory for the CORBA object that can satisfy the request from the CORBA client application.
The CORBA environment in the Oracle Tuxedo product supports Java2 applets as clients. To run Java2 applets, you need to install the Java Plug-In product from Sun Microsystems, Inc. The Java Plug-in runs Java applets in an HTML page using Sun’s Java Virtual Machine (JVM).
Before downloading the Java Plug-in kit from the Sun Web site, verify whether or not the Java Plug-In is already installed on your machine.
In Netscape Navigator, choose the About Plug-Ins option from the Help menu in the browser window. The following will appear if the Java Plug-In is installed:
From the Start menu in Windows, select the Programs option. If the Java Plug-In is installed, a Java Plug-In Control Panel option will appear.
If the Java Plug-In is not installed, you need to download and install the JDK1.2 plug-in (
jre12-win32.exe) and the HTML converter tool (
htmlconv12.zip). You can obtain both these products from
You also need to read the Java Plug-In HTML Specification located at
java.sun.com/products/plugin/1.2/docs. This specification explains the changes Web page authors need to make to their existing HTML code to have existing JDK 1.2 applets run using the Java Plug-In rather that the brower’s default Java run-time environment.
Write your Java applet. Use the following command to intialize the ORB from the Java applet:
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (this,null);
To automatically launch the Java Plug-In when Internet Explorer or Netscape Navigator browses the HTML page for your applet, use the
OBJECT tag and the
EMBED tag in the HTML specification. If you use the HTML Converter tool to convert your applet to HTML, these tags are automatically inserted. For more information about using the
EMBED tags, see