![]() |
![]() |
|
|
Developing WebLogic Enterprise CORBA Applications
This topic includes the following sections:
For an in-depth discussion of creating WebLogic Enterprise CORBA client and server applications, see the following in the WebLogic Enterprise online documentation:
Overview of the Development Process for WebLogic Enterprise CORBA Applications
Table 4-1 outlines the development process for WebLogic Enterprise CORBA applications.
Step |
Description |
---|---|
1 |
Write the Object Management Group (OMG) Interface Definition Language (IDL) code for each CORBA interface you want to use in your WebLogic Enterprise application. |
2 |
Generate the client stubs and the skeletons. |
3 |
Write the server application. |
4 |
Write the client application. |
5 |
Create an XA resource manager. |
6 |
Create a configuration file. |
7 |
Create a TUXCONFIG file. |
8 |
Compile the server application. |
9 |
Compile the client application. |
10 |
Start the WebLogic Enterprise CORBA application. |
The steps in the development process are described in the following sections.
Figure 4-1 illustrates the process for developing WebLogic Enterprise CORBA applications.
Figure 4-1 Development Process for WebLogic Enterprise CORBA Applications
The Simpapp Sample Application
Throughout this topic, the Simpapp sample application is used to demonstrate the development steps. C++ and Java versions of the Simpapp sample application are available.
The server application in the Simpapp sample application provides an implementation of a CORBA object that has the following two methods:
Figure 4-2 illustrates how the Simpapp sample application works.
Figure 4-2 Simpapp Sample Application
The source files for the C++ and Java versions of the Simpapp sample application are located in the \samples\corba\simpapp and \samples\corba\simpap_java directories of the WebLogic Enterprise software. Instructions for building and running the Simpapp sample applications are in the Readme.txt files in the directories. For instructions for building and running the C++ and Java Simpapp sample applications, see Samples in the WebLogic Enterprise online documentation.
Note: The Simpapp sample applications demonstrate building C++ client and server applications and Java client and server applications. For information about building a simple ActiveX client application, see the Basic sample application in the WebLogic Enterprise online documentation.
The WebLogic Enterprise product offers a suite of sample applications that demonstrate and aid in the development of WebLogic Enterprise CORBA applications. For an overview of the available sample applications, see Samples in the WebLogic Enterprise online documentation.
Step 1: Write the OMG IDL Code
The first step in writing a WebLogic Enterprise application is to specify all of the CORBA interfaces and their methods using the Object Management Group (OMG) Interface Definition Language (IDL). An interface definition written in OMG IDL completely defines the CORBA interface and fully specifies each operation's arguments. OMG IDL is a purely declarative language. This means that it contains no implementation details. Operations specified in OMG IDL can be written in and invoked from any language that provides CORBA bindings.
The Simpapp sample application implements the CORBA interfaces listed in Table 4-2.
Interface |
Description |
Operation |
---|---|---|
SimpleFactory |
Creates object references to the Simple object |
find_simple() |
Simple |
Converts the case of a string |
to_upper() to_lower() |
Listing 4-1 shows the simple.idl file that defines the CORBA interfaces in the Simpapp sample application. The same OMG IDL file is used by both the C++ and Java Simpapp sample applications.
Listing 4-1 OMG IDL Code for the Simpapp Sample Application
#pragma prefix "beasys.com"
interface Simple
{
//Convert a string to lower case (return a new string)
string to_lower(in string val);
//Convert a string to upper case (in place)
void to_upper(inout string val);
};
interface SimpleFactory
{
Simple find_simple();
};
Step 2: Generate Client Stubs and Skeletons
The interface specification defined in OMG IDL is used by the IDL compiler to generate client stubs for the client application, and skeletons for the server application. The client stubs are used by the client application for all operation invocations. You use the skeleton, along with the code you write, to create the server application that implements the CORBA objects.
During the development process, use one of the following commands to compile the OMG IDL file and produce client stubs and skeletons for WebLogic Enterprise client and server applications:
Table 4-3 lists the files that are created by the idl command.
File |
Default Name |
Description |
---|---|---|
Client stub file |
application_c.cpp |
Contains generated code for sending a request. |
Client stub header file |
application_c.h |
Contains class definitions for each interface and type specified in the OMG IDL file. |
Skeleton file |
application_s.cpp |
Contains skeletons for each interface specified in the OMG IDL file. During run time, the skeleton maps client requests to the appropriate operation in the server application. |
Skeleton header file |
application_s.h |
Contains the skeleton class definitions. |
Implementation file |
application_i.cpp |
Contains signatures for the methods that implement the operations on the interfaces specified in the OMG IDL file. |
Implementation header file |
application_i.h |
Contains the initial class definitions for each interface specified in the OMG IDL file. |
Table 4-4 lists the files that are created by the m3idltojava command.
File |
Default Name |
Description |
---|---|---|
Base interface class file |
interface.java |
Contains an implementation of the interface, written in Java. Copy this file to create a new file, and add your business logic to the new file. By convention in the samples and in this document, this file is named interfaceImpl.java. Substitute the actual name of the interface in the filename. This new file is called an object implementation file. |
Client stub file |
_interfaceStub.java |
Contains generated code for sending a request. |
Server skeleton file |
_interfaceImplBase |
Contains Java skeletons for each interface specified in the OMG IDL file. During run time, the skeleton maps client requests to the appropriate operation in the Java server application during run time. |
Holder class file |
interfaceHolder.java |
Contains the implementation of the Holder class. The Holder class provides operations for out and inout arguments, which CORBA has, but which do not map exactly to Java. |
Helper class file |
interfaceHelper.java |
Contains the implementation of the Helper class. The Helper class provides auxiliary functionality, notably the narrow method. |
Step 3: Write the Server Application
The WebLogic Enterprise software supports C++ and Java server applications. The steps for creating server applications are:
Writing the Methods That Implement Each Interface's Operations
After you compile the OMG IDL file, you need to write methods that implement the operations for each interface in the file. An implementation file contains the following:
Within the activate_object() and deactivate_object() methods, you write code that performs any particular steps related to activating or deactivating the object. For more information, see Creating CORBA C++ Server Applications and Creating CORBA Java Server Applications in the WebLogic Enterprise online documentation.
You can write the implementation file by hand. However, both the idl and m3idltojava commands have an option that generates a template for implementation files.
Listing 4-2 includes the C++ implementation of the Simple and SimpleFactory interfaces in the Simpapp sample application.
Listing 4-2 C++ Implementation of the Simple and SimpleFactory Interfaces
// Implementation of the Simple_i::to_lower method which converts
// a string to lower case.
char* Simple_i::to_lower(const char* value)
{
CORBA::String_var var_lower = CORBA::string_dup(value);
for (char* ptr = v_lower; ptr && *ptr; ptr++) {
*ptr = tolower(*ptr);
}
return var_lower._retn();
}
// Implementation of the Simple_i::to_upper method which converts
// a string to upper case.
void Simple_i::to_upper(char*& valuel)
{
CORBA::String_var var_upper = value;
var_upper = CORBA::string_dup(var_upper.in());
for (char* ptr = var_upper; ptr && *ptr; ptr++) {
*ptr = toupper(*ptr);
}
value = var_upper._retn();
}
// Implementation of the SimpleFactory_i::find_simple method which
// creates an object reference to a Simple object.
Simple_ptr SimpleFactory_i::find_simple()
{
CORBA::Object_var var_simple_oref =
TP::create_object_reference(
_tc_Simple->id(),
"simple",
CORBA::NVList::_nil()
);
}
Listing 4-3 includes the Java implementation of the Simple interface from the Simpapp sample application.
Listing 4-3 Java Implementation of the Simple Interface
import com.beasys.Tobj.TP;
/**
*The SimpleImpl class implements the to_upper and to_lower
*methods.
*/
public class SimpleImpl extends _SimpleImplBase
{
/*Converts a string to upper case.*/
public void to_upper(org.omg.CORBA.StringHolder data)
{
if (data.value == null)
return;
data.value = data.value.toUpperCase();
return;
}
/*Converts a string to lower case.*/
public String to_lower(String data)
{
if (data == null)
return null;
return data.toLowerCase();
}
}
Listing 4-4 includes the Java implementation of the SimpleFactory interface from the Simpapp sample application.
Listing 4-4 Java Implementation of the SimpleFactory Interface
import com.beasys.Tobj.TP;
/**
*The SimpleFactoryImpl class provides code to create the Simple *object.
*/
public class SimpleFactoryImpl extends _SimpleFactoryImplBase
{
/*Create an object reference to a Simple object*/
public Simple find_simple()
{
org.omg.CORBA.Object simple_oref =
TP.create_object_reference(
SimpleHelper.id(), //Repository ID
"simple", //object id
null //routing criteria
);
//Send back the narrowed reference
return SimpleHelper.narrow(simple_oref);
};
};
};
Creating the Server Object
The Server object performs the following tasks:
In C++ server applications, the Server object is already instantiated and a header file for the Server object is available. You implement methods that initialize and release the server application, and, if desired, create servant objects.
Listing 4-5 includes the C++ code from the Simpapp sample application for the Server object.
Listing 4-5 C++ Server Object
static CORBA::Object_var static_var_factory_reference;
// Method to start up the server
CORBA::Boolean Server::initialize(int argc, char* argv[])
{
// Create the Factory Object Reference
static_var_factory_reference =
TP::create_object_reference(
_tc_SimpleFactory->id(),
"simple_factory",
CORBA::NVList::_nil()
);
// Register the factory reference with the FactoryFinder
TP::register_factory(
static_var_factory_reference.in(),
_tc_SimpleFactory->id()
);
return CORBA_TRUE;
}
// Method to shutdown the server
void Server::release()
{
// Unregister the factory.
try {
TP::unregister_factory(
static_var_factory_reference.in(),
_tc_SimpleFactory->id()
);
}
catch (...) {
TP::userlog("Couldn't unregister the SimpleFactory");
}
}
// Method to create servants
Tobj_Servant Server::create_servant(const char*
interface_repository_id)
{
if (!strcmp(interface_repository_id,
_tc_SimpleFactory->id())) {
return new SimpleFactory_i();
}
if (!strcmp(interface_repository_id,
_tc_Simple->id())) {
return new Simple_i();
}
return 0;
}
In Java server applications, you implement the Server object by creating a new class that derives from the com.beasys.Tobj.Server class and overrides the initialize() and release() methods. In the server application code, you can also write a public default constructor for the Server object. When creating Java server applications, you identify the name of the Server object in the Server Description File.
The create_servant() method, used in the C++ programming environment of the WebLogic Enterprise product, is not used in the Java environment. In Java, objects are created dynamically, without prior knowledge of the classes being used. In the Java environment of the WebLogic Enterprise product, a servant factory is used to retrieve an implementation class, given the interface repository ID. This information is stored in a server descriptor file. When a method request is received, and no servant is available for the interface, the servant factory looks up the interface and creates an object of the appropriate implementation class.
This collection of the object's implementation and data compose the run-time, active instance of the CORBA object.
When your Java server application starts, the TP Framework creates the Server object specified in the XML file. Then, the TP Framework invokes the initialize() method. If the method returns true, the server application starts. If the method throws the com.beasys.TobjS.InitializeFailed exception, or returns false, the server application does not start.
When the server application shuts down, the TP Framework invokes the release method on the Server object.
Any command-line options specified in the CLOPT parameter for your specific server application in the SERVERS section of the WebLogic Enterprise domain's UBBCONFIG file are passed to the public boolean initialize(string[] args) method as args. For more information about passing arguments to the server application, see Administration Guide in the WebLogic Enterprise online documentation.
Within the initialize() method, you can include code that does the following, if applicable:
Listing 4-6 includes the Java code from the Simpapp sample application for the Server object.
Listing 4-6 Java Server Object
import com.beasys.Tobj.TP;
public class ServerImpl
extends com.beasys.Tobj.Server
{
static org.omg.CORBA.Object factory_reference;
/**Method to start up the server*/
public boolean initialize(String[] args)
{
try {
// Create the factory object reference.
factory_reference = TP.create_object_reference(
SimpleFactoryHelper.id(),
"simple_factory",
null
);
// Register the factory reference with the FactoryFinder
TP.register_factory(
factory_reference,
SimpleFactoryHelper.id()
);
return true;
} catch (Exception e){
TP.userlog("Couldn't initialize server: " +
e.getMessage());
e.printStackTrace();
return false;
}
}
/** Method to shutdown the server*/
public void release()
{
try {
TP.unregister_factory(
factory_reference,
SimpleFactoryHelper.id()
);
} catch (Exception e){
TP.userlog("Couldn't unregister the
SimpleFactory: " + e.getMessage());
e.printStackTrace();
}
}
}
Defining an Object's Activation Policies
As part of server development, you determine what events cause an object to be activated and deactivated by assigning object activation policies, as follows:
Note: You also define transaction policies in the ICF and Server Description Files. For information about using transactions in your WebLogic Enterprise CORBA application, see Using Transactions in the WebLogic Enterprise online documentation.
The WebLogic Enterprise software supports the activation policies listed in Table 4-5.
Activation Policy |
Description |
---|---|
method |
Causes the object to be active only for the duration of the invocation on one of the object's operations. This is the default activation policy. |
transaction |
Causes the object to be activated when an operation is invoked on it. If the object is activated within the scope of a transaction, the object remains active until the transaction is either committed or rolled back. |
process |
Causes the object to be activated when an operation is invoked on it, and to be deactivated only when one of the following occurs:
|
The Simple interface in the Simpapp sample application is assigned the default activation policy of method. For more information about managing object state and defining object activation policies, see Creating CORBA C++ Server Applications and Creating CORBA Java Server Applications in the WebLogic Enterprise online documentation.
Creating and Registering a Factory
If your server application manages a factory that you want client applications to be able to locate easily, you need to write the code that registers that factory with the FactoryFinder object.
To write the code that registers a factory managed by your server application, you do the following:
You include an invocation to the create_object_reference() method, specifying the Interface Repository ID of the factory's OMG IDL interface or the object ID (OID) in string format. In addition, you can specify routing criteria.
Use the register_factory() method to register the factory with the FactoryFinder object in the WebLogic Enterprise domain. The register_factory() method requires the object reference for the factory and a string identifier.
Listing 4-7 includes the code from the C++ Simpapp sample application that creates and registers a factory.
Listing 4-7 C++ Example of Creating and Registering a Factory
...
CORBA::Object_var v_reg_oref =
TP:create_object_reference(
_tc.SimpleFactory->id(), //Factory Interface ID
"simplefactory", //Object ID
CORBA::NVList::_nil() //Routing Criteria
);
TP::register_factory(
CORBA::Object_var v_reg_oref.in(),
_tc_SimpleFactory->id(),
);
...
In Listing 4-7, notice the following:
Listing 4-8 includes the code from the Java Simpapp sample application that creates and registers a factory.
Listing 4-8 Java Example of Creating and Registering a Factory
...
// Save the Simple factory name.
SimpleFName = new String(args[0]);
org.omg.CORBA.Object simple_oref =
TP.create_object_reference(
SimpApp.SimpleHelper.id(), // Repository ID
SimpleFName, // Object ID
null // Routing Criteria
);
// Register the factory reference with the factory finder.
TP.register_factory(
fact_oref, // factory object referenc
SimpleFName // factory name
);
...
Releasing the Server Application
You need to include code in your server application to perform a graceful shutdown of the server application. The release()method is provided for that purpose. Within the release() method, you may perform any application-specific cleanup tasks that are specific to the server application, such as:
Once a server application receives a request to shut down, the server application can no longer receive requests from other remote objects. This has implications on the order in which server applications should be shut down, which is an administrative task. For example, do not shut down one server process if a second server process contains an invocation in its release() method to the first server process.
During server shutdown, you may want to unregister each of the server application's factories. The invocation of the unregister_factory() method should be one of the first actions in the release() implementation. The unregister_factory() method unregisters the server application's factories. This operation requires the following input arguments:
Listing 4-9 includes C++ code that releases a server application and unregistered the factories in the server application.
Listing 4-9 C++ Example of Releasing a WebLogic Enterprise Server Application
...
public void release()
{
TP::unregister_factory(
factory_reference.in(),
SimpleFactoryHelper->id
);
}
...
Listing 4-10 includes Java code that releases a server application and unregistered the factories in the server application.
Listing 4-10 Java Example of Releasing a WebLogic Enterprise Server Application
...
/**
* Method to shutdown the server.
*/
public void release)()
{
//This method will only be called if Server.initialize()
//succeeded, therefore, we know that the factory has been
//registered with the factory finder.
//Unregister the factory.
//Use a try block since cleanup code should not throw
//exceptions.
try{
TP.unregister_factory(
fact_ref, //factory object reference
SimpleFactoryHelper.id() //factory repository id
);
}catch (Exception e){
//Some exception occurred. The call to TP.userlog()
//will put the message in the ULOG file.
TP.userlog("Couldn't unregister the SimpleFactory:"
+e.getMessage());
e.printStackTrace();
}
}
...
Step 4: Write the Client Application
The WebLogic Enterprise software supports the following types of client applications:
The steps for creating client applications are as follows:
Note: For information about creating an ActiveX client application, see WebLogic Enterprise ActiveX Client Developer's Guide in the WebLogic Enterprise online documentation.
The client development steps are illustrated in Listing 4-11 and Listing 4-12, which include code from the Simpapp sample application. In the Simpapp sample application, the client application uses a factory to get an object reference to the Simple object and then invokes the to_upper() and to_lower() methods on the Simple object.
Listing 4-11 C++ Client Application From the Simpapp Sample Application
int main(int argc, char* argv[])
{
try {
// Initialize the ORB
CORBA::ORB_var var_orb = CORBA::ORB_init(argc, argv, "");
// Create the Bootstrap object
Tobj_Bootstrap bootstrap(var_orb.in(), "");
// Use the Bootstrap object to find the FactoryFinder
CORBA::Object_var var_factory_finder_oref =
bootstrap.resolve_initial_references("FactoryFinder");
// Narrow the FactoryFinder
Tobj::FactoryFinder_var var_factory_finder_reference =
Tobj::FactoryFinder::_narrow
(var_factory_finder_oref.in());
// Use the factory finder to find the Simple factory
CORBA::Object_var var_simple_factory_oref =
var_factory_finder_reference->find_one_factory_by_id(
_tc_SimpleFactory->id()
);
// Narrow the Simple factory
SimpleFactory_var var_simple_factory_reference =
SimpleFactory::_narrow(
var_simple_factory_reference.in());
// Find the Simple object
Simple_var var_simple =
var_simple_factory_reference->find_simple();
// Get a string from the user
cout << "String?";
char mixed[256];
cin >> mixed;
// Convert the string to upper case :
CORBA::String_var var_upper = CORBA::string_dup(mixed);
var_simple->to_upper(var_upper.inout());
cout << var_upper.in() << endl;
// Convert the string to lower case
CORBA::String_var var_lower = var_simple->to_lower(mixed);
cout << var_lower.in() << endl;
return 0;
}
}
Listing 4-12 Java Client Application From the Simpapp Sample Application
public class SimpleClient
{
public static void main(String args[])
// Initialize the ORB.
ORB orb = ORB.init(args, null);
// Create the Bootstrap object
Tobj_Bootstrap bootstrap = new Tobj_Bootstrap(orb, "");
// Use the Bootstrap object to locate the FactoryFinder
org.omg.CORBA.Object factory_finder_reference =
bootstrap.resolve_initial_references("FactoryFinder");
// Narrow the FactoryFinder
FactoryFinder factory_finder_reference =
FactoryFinderHelper.narrow(factory_finder_reference);
// Use the FactoryFinder to find the Simple factory.
org.omg.CORBA.Object simple_factory_reference =
factory_finder_reference.find_one_factory_by_id
(SimpleFactoryHelper.id());
// Narrow the Simple factory
SimpleFactory simple_factory_reference =
SimpleFactoryHelper.narrow(simple_factory_reference);
// Find the Simple object.
Simple simple = simple_factory_reference.find_simple();
// Get a string from the user.
System.out.println("String?");
String mixed = in.readLine();
// Convert the string to upper case.
org.omg.CORBA.StringHolder buf = new
org.omg.CORBA.StringHolder(mixed);
simple.to_upper(buf);
System.out.println(buf.value);
// Convert the string to lower case.
String lower = simple.to_lower(mixed);
System.out.println(lower);
}
}
Step 5: Create an XA Resource Manager
When using transactions in a WebLogic Enterprise CORBA application, you need to create a server process for the resource manager that interacts with a database on behalf of the WebLogic Enterprise CORBA application. The resource manager you use must conform to the X/OPEN XA specification and you need the following information about the resource manager:
When integrating a new XA resource manager into the WebLogic Enterprise system, the file $TUXDIR/udataobj/RM must be updated to include information about the XA resource manager. The information is used to include the correct libraries for the XA resource manager and to automatically and properly set up the interface between the transaction manager and the XA resource manager. The format of this file is as follows:
rm_name:rm_structure_name:library_names
where rm_name is the name of the XA resource manager, rm_structure_name is the name of the xa_switch_t structure that defines the name of the XA resource manager, and library_names is the list of the object files for the XA resource manager. White space (tabs and/or spaces) is allowed before and after each of the values and may be embedded within the library_names. The colon (:) character may not be embedded within any of the values. Lines beginning with a pound sign (#) are treated as comments and are ignored.
Use the buildtms command to build a server process for the XA resource manager. The files that result from the buildtms command need to be installed in the $TUXDIR/bin directory.
For more information about the buildtms command, see Commands, System Processes, and MIB Reference in the WebLogic Enterprise online documentation.
Step 6: Create a Configuration File
Because the WebLogic Enterprise software offers great flexibility and many options to application designers and programmers, no two applications are alike. An application, for example, may be small and simple (a single client and server running on one machine) or complex enough to handle transactions among thousands of client and server applications. For this reason, for every WebLogic Enterprise CORBA application being managed, the system administrator must provide a configuration file that defines and manages the components (for example, domains, server applications, client applications, and interfaces) of that application.
When system administrators create a configuration file, they are describing the WebLogic Enterprise application using a set of parameters that the WebLogic Enterprise software interprets to create a runnable version of the application. During the setup phase of administration, the system administrator's job is to create a configuration file. The configuration file contains the sections listed in Table 4-6.
Sections in the Configuration File |
Description |
---|---|
RESOURCES |
Defines defaults (for example, user access and the main administration machine) for the WebLogic Enterprise CORBA application. |
MACHINES |
Defines hardware-specific information about each machine running in the WebLogic Enterprise CORBA application. |
GROUPS |
Defines logical groupings of server applications or CORBA interfaces. |
SERVERS |
Defines the server application processes (for example, the Transaction Manager) used in the WebLogic Enterprise CORBA application. |
SERVICES |
Defines parameters for services provided by the WebLogic Enterprise application. |
INTERFACES |
Defines information about the CORBA interfaces in the WebLogic Enterprise CORBA application. |
JDBCONNPOOLS |
Describes the pooling of JDBC connections for Java servers. |
ROUTING |
Defines routing criteria for the WebLogic Enterprise CORBA application. |
Listing 4-13 shows the configuration file for the Simpapp sample application.
Listing 4-13 Configuration File for Simpapp Sample Application
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MASTER SITE1
MODEL SHM
LDBAL N
*MACHINES
"PCWIZ"
LMID = SITE1
APPDIR = "C:\WLEDIR\MY_SIM~1"
TUXCONFIG = "C:\WLEDIR\MY_SIM~1\results\tuxconfig"
TUXDIR = "C:\WLEDIR"
MAXWSCLIENTS = 10
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP
LMID = SITE1
GRPNO = 2
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_server
SRVGRP = APP_GRP
SRVID = 1
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //PCWIZ:2468"
*SERVICES
When creating Java server applications, include the JavaServer parameter in the UBBCONFIG file to start the Java server application. For example:
*SERVERS
.
.
.
JavaServer
SRVTYPE = JAVA
MODULES = Bankapp.jar
SRVGRP = APP_GRP
SRVID = 2
SYSTEM_ACCESS = FASTPATH
CLOPT = "-A -- -M 10 TellerFactory_1"
RESTART = N
If you are using an XA resource manager, use the JavaServerXA parameter in place of the JavaServer parameter to associate the XA resource manager with a specified server group. You need to include the information to open and close the resource manager in the OPENINFO and CLOSEINFO parameters in the GROUPS section of the UBBCONFIG file. The information needed to open and close the resource manager should be provided by the manufacturer of the resource manager.
Step 7: Create the TUXCONFIG File
There are two forms of the configuration file:
For more information about the tmloadcf command, see Commands, System Processes, and MIB Reference in the WebLogic Enterprise online documentation.
Step 8: Compile the Server Application
You use the buildobjserver command to compile and link C++ server applications. The buildobjserver command has the following format:
buildobjserver [-o servername] [options]
In the buildobjserver command syntax:
When creating Java server applications, use the javac compiler to create the bytecodes for all the class files that comprise your WebLogic Enterprise CORBA application. This set of files includes the *.java source files generated by the m3idltojava compiler, plus the object implementation files and server class files you created.
You use the buildjavaserver command to build a Java ARchive (JAR) file and link the Java server applications. The buildjavaserver command has the following format:
buildjavaserver [-s searchpath] input_file.xml
In the buildjavaserver command syntax:
You then need to specify in the APPDIR system environment variable the location of the JAR file for your Java server application. On Windows NT systems, this directory must be on a local drive (not a networked drive). On Solaris systems, the directory can be local or remote.
Step 9: Compile the Client Application
The final step in the development of the CORBA client application is to produce the executable client application. To do this, you need to compile the code and then link against the client stub.
When creating CORBA C++ client applications, use the buildobjclient command to construct a WebLogic Enterprise client application executable. The command combines the client stubs for interfaces that use static invocation, and the associated header files, with the standard WebLogic Enterprise libraries to form a client executable. For the syntax of the buildobjclient command, see Commands, System Processes, and MIB Reference in the WebLogic Enterprise online documentation.
When creating CORBA Java client applications, see your Java ORB's documentation for information about building client executables. You need to include the wledir\udataobj\java\jdk\m3envobj.jar file in your CLASSPATH when you compile the CORBA Java client application. The m3envobj.jar file contains the Java classes for the WebLogic Enterprise environmental objects.
Step 10: Start the WebLogic Enterprise CORBA Application
Use the tmboot command to start the server processes in your WebLogic Enterprise CORBA application. The WebLogic Enterprise CORBA application is usually booted from the machine designated as the MASTER in the RESOURCES section of the UBBCONFIG file.
For the tmboot command to find executables, the WebLogic Enterprise system processes must be located in $TUXDIR/bin. Server applications should be in APPDIR, as specified in the configuration file.
When booting server applications, the tmboot command uses the CLOPT, SEQUENCE, SRVGRP, SRVID, and MIN parameters from the configuration file. Server applications are booted in the order in which they appear in the configuration file.
For more information about using the tmboot command, see Commands, System Processes, and MIB Reference in the WebLogic Enterprise online documentation.
Additional WebLogic Enterprise CORBA Sample Applications
Sample applications demonstrate the tasks involved in developing a WebLogic Enterprise CORBA application, and provide sample code that can be used by client and server programmers to build their own WebLogic Enterprise CORBA application. Code from the sample applications are used throughout the information topics in the WebLogic Enterprise product to illustrate the development and administrative steps. For information about building and running the sample applications, see Samples in the WebLogic Enterprise online documentation.
Table 4-7 describes the additional WebLogic Enterprise CORBA sample applications.
WebLogic Enterprise CORBA |
Description |
---|---|
Simpapp |
Provides a C++ client application and a C++ server application. The C++ server application contains two operations that manipulate strings received from the C++ client application. |
Java Simpapp |
Provides a Java client application and a Java server application. The Java server application contains two operations that manipulate strings received from the Java client application. |
Basic |
Describes how to develop WebLogic Enterprise client and server applications and configure the WebLogic Enterprise application. Building C++ server applications and CORBA C++, CORBA Java, and ActiveX client applications are demonstrated. |
Security |
Demonstrates adding Tuxedo authentication to a WebLogic Enterprise application. For information about building and running the Security sample application, see Using Security in the WebLogic Enterprise online documentation. |
Transactions |
Adds transactional objects to the C++ server application and client applications in the Basic sample application. The Transactions sample application demonstrates how to use the Implementation Configuration File (ICF) to define transaction policies for CORBA objects. For information about building and running the Transactions sample application, see Using Transactions in the WebLogic Enterprise online documentation. |
Wrapper |
Demonstrates how to wrap an existing BEA Tuxedo application as a CORBA object. |
Production |
Demonstrates replicating server applications, creating stateless objects, and implementing factory-based routing in server applications. |
JDBC Bankapp |
Implements an automatic teller machine (ATM) interface and uses Java Database Connectivity (JDBC) to access a database that stores account and customer information. For information about building and running the JDBC Bankapp sample application, see Using Transactions in the WebLogic Enterprise online documentation. |
XA Bankapp |
Implements the same ATM interface as JDBC Bankapp; however, XA Bankapp uses a database XA library to demonstrate using the Transaction Manager to coordinate transactions. For information about building and running the XA Bankapp sample application, see Using Transactions in the WebLogic Enterprise online documentation. |
Secure Simpapp |
Implements the necessary development and administrative changes to the Simpapp sample application to support certificate-based authentication. Java and C++ versions are provided. For information about building and running the Secure Simpapp sample application, see Using Security in the WebLogic Enterprise online documentation. |
Introductory Events |
Demonstrates how to use joint client/server applications and callback objects to implement events in a WebLogic Enterprise CORBA application. The C++ version uses the BEA Simple Events API and the Java version uses the CosNotification API. For information about building and running the Introductory Events sample application, see Using the Notification Service in the WebLogic Enterprise online documentation. |
Advanced Events |
Provides a more complex implementation of events in a WebLogic Enterprise CORBA application with transient and persistent subscriptions and data filtering. The C++ version uses the BEA Simple Events API and the Java version uses the CosNotification API. For information about building and running the Advanced Events sample application, see Using the Notification Service in the WebLogic Enterprise online documentation. |
![]() |
![]() |
![]() |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|