![]() |
![]() |
|
|
| |
Writing WebLogic Server Clients That Invoke CORBA Objects
The following sections describe the requirements to access BEA Tuxedo CORBA objects from WebLogic Server including:
You can also use WebLogic Enterprise Connectivity to invoke Java objects (EJBs and RMI objects) built using WebLogic Enterprise version 5.1. For more information, see Accessing a WLE EJB or RMI object in the WebLogic Enterprise Connectivity documentation in WebLogic Server version 6.0.
Before You Begin
Before you implement WebLogic Server clients that invoke BEA Tuxedo CORBA objects, you need to:
Configuring a WLEC Connection Pool
Configure a WLEC connection pool for each BEA Tuxedo domain that contains a BEA Tuxedo CORBA object you want to access from a WebLogic Server client. Because the security context established for the WebLogic Server client is propagated to the BEA Tuxedo domain through the WLEC connection pool, the WLEC connection pools are the basis for the security context propagation feature.
Before using WLEC connection pools, add WL_HOME/lib/wleorb.jar, WL_HOME/lib/wlepool.jar, and TUXDIR/udataobj/java/jdk/wleclient.jar to the CLASSPATH variable in the startAdminWebLogic.sh or startAdminWebLogic.cmd file. If you are using a JSP that requests an EJB served by WLE 5.1,add the location of the WLE 5.1 wlej2eecl.jar file to the CLASSPATH variable in the startAdminWebLogic.sh or startAdminWebLogic.cmd file.
Create a new WLEC connection pool for the purpose of security context propagation. To create a WLEC connection pool:
Using certificate authentication between the WebLogic Server environment and the BEA Tuxedo CORBA environment implies performing a new SSL handshake when establishing a connection from the WebLogic Server environment to a CORBA object. To support multiple client requests over the same SSL network connection, you must set up certificate authentication so that it operates as follows:
For more information about configuring security in BEA Tuxedo CORBA applications, see Using Security in CORBA Applications.
Accessing BEA Tuxedo CORBA Objects
This section describes accessing a BEA Tuxedo CORBA object from a WebLogic Server client.
Step 1. Create Client Stubs
Client stubs provide the programming interface for operations of a BEA Tuxedo CORBA object. To create client stubs, compile the Object Management Group (OMG) Interface Definition Language (IDL) file for the BEA Tuxedo CORBA object you want to access from the WebLogic Server client. To create client stubs for a BEA Tuxedo CORBA object, use the idl compiler that is included in the BEA Tuxedo software.
Make sure the WebLogic Server CLASSPATH environment variable includes the directory that contains the client stubs for the BEA Tuxedo CORBA object.
Step 2. Import Java Packages
Import the following Java packages into your WebLogic Server client:
Step 3. Connect the WebLogic Server Client to a BEA Tuxedo Domain
Each WLEC connection pool has a Tobj_Bootstrap object that lets you access the associated BEA Tuxedo domain. The WebLogic Enterprise Connectivity component provides an object called BootstrapFactory which provides access to the Tobj_Bootstrap object for a particular BEA Tuxedo domain. Include the following code in your WebLogic Server client to connect to a BEA Tuxedo domain:
Tobj_Bootstrap myBootstrap = Tobj_BootstrapFactory.getClientContext("myPool");
where
Step 4. Get an Object Reference for the BEA Tuxedo CORBA Object
Use the FactoryFinder object in your WebLogic Server client to get a reference to the BEA Tuxedo CORBA object.
org.omg.CORBA.Object myFFObject = myBootstrap.resolve_initial_references("FactoryFinder"); FactoryFinder myFactFinder = FactoryFinderHelper.narrow(myFFObject);
where
org.omg.CORBA.Object myFactoryRef = myFactFinder.find_one_factory_by_id(myFactoryHelper.id()); myFactory = myFactoryHelper.narrow(myFactoryRef);
where
Simple mySimple = mySimpleFactory.find_simple();
where the factory provides the find_simple() method for finding the Simple object.
For information about the FactoryFinder object, see the CORBA C++ Programming Reference in the BEA Tuxedo documentation.
Step 5. Start a Transaction (Optional)
You can access BEA Tuxedo CORBA objects within the scope of a transaction. The following sample code uses the TransactionCurrent object to access a BEA Tuxedo CORBA object within a scope of a transaction. You can also use the UserTransaction object when accessing a BEA Tuxedo CORBA object.
To start a transaction, include the following code in your WebLogic Server client:
org.omg.CORBA.Object myTCObject = myBootstrap.resolve_initial_references("TransactionCurrent"); CosTransactions.Current myTransaction = CosTransactions.CurrentHelper.narrow(myTCObject);
where
myTransaction.begin();
where the begin() method creates a transaction context and associates it with myTCObject in step 1. Because myTCObject is associated with myBootstrap and myBootstrap is associated with a specific WLEC connection pool, myTransaction is associated with a specific WLEC connection pool.
Step 6. Access the BEA Tuxedo CORBA Object and Its Operations
Call methods on the BEA Tuxedo CORBA object in the BEA Tuxedo domain associated with the WLEC connection pool.
If you are accessing objects within a transaction context, you can use the following TransactionCurrent methods to manipulate and query the transaction context:
Step 7. End the Transaction (Optional)
If you accessed the BEA Tuxedo CORBA object within a transaction context, use one of the following TransactionCurrent methods to end the transaction:
More Information About Transactions
This section includes additional information about transactions in the BEA Tuxedo environment.
Multithreading
The BEA Tuxedo CORBA Transaction service enables multiple threads of a single application process to start separate transactions simultaneously. For example, if two threads simultaneously call CosTransactions.Current.begin() or UserTransaction.begin() both threads have separate transaction contexts that correspond to separate transactions.
The CORBA Transaction Service does not let multiple threads of a single application work with the same transaction at the same time. If you use CosTransactions, you can suspend and resume a transaction in order to use the transaction in multiple threads:
If a thread tries to resume a transaction that has not been suspended, the BEA Tuxedo system throws an INVALID_CONTROL exception.
The UserTransaction interface does not support the suspend() and resume() methods. Therefore, you cannot use a transaction in multiple threads when you use UserTransaction.
Multiple Active WLEC Connection Pools
The WebLogic Enterprise Connectivity component supports multiple simultaneously active WLEC connection pools in a single WebLogic Server client. When you call CosTransactions.Current.begin() or UserTransaction.begin() to create a transaction context, the BEA Tuxedo system associates the transaction with a WLEC connection pool. All calls made inside the scope of the transaction must be for objects that reside in the domain associated with the transaction's WLEC connection pool.
A transaction cannot span multiple BEA Tuxedo domains. If you try to make a call for an object in a different domain, the BEA Tuxedo system throws an INVALID_TRANSACTION exception.
Relationship Between Active Transactions and Connections
When a WebLogic Server client starts or resumes a transaction, the WLEC connection pool infrastructure reserves a connection for requests that are sent in the context of the transaction. The WebLogic Enterprise Connectivity component does not use this connection to send requests that are not in the transaction context. The WebLogic Enterprise Connectivity component reserves the connection until the transaction is committed, rolled back, or suspended.
Note: The suspend() and resume() are available only for CosTransactions.
The number of concurrently active transactions is bound by the number of available connections in the pool. If a connection is not available when a thread begins or resumes a transaction, the WebLogic Enterprise Connectivity component throws a NO_RESOURCES exception.
Transaction Management
Each thread has its own transaction context. When a thread starts or resumes a transaction, the transaction is active until it is committed, rolled back, or suspended. There is no guarantee that subsequent invocations to a WebLogic Server client get executed in the same thread. Therefore, it is important for a thread to commit, roll back, or suspend a transaction before ending a WebLogic Server client invocation.
Note: The suspend() and resume() are available only for CosTransactions.
If necessary, you can use a transaction in multiple WebLogic Server client invocations as follows:
Be careful when using this solution, because a transaction can time out before you make the next WebLogic Server client invocation.
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|