|
|
|
Implementing Applications That Use WebLogic Enterprise Connectivity
Prerequisites
Before you implement applications that use WebLogic Enterprise Connectivity (WLEC), you need to:
Implementation Overview
To implement an application that uses WLEC, do one of the following:
Create a WLS application (servlet, EJB, JSP, or RMI object) and include code for accessing existing WLE objects and operations:
Add code for accessing existing WLE objects and operations to an already-existing WLS client (servlet, EJB, JSP, or RMI object):
Modify a WLE client application into a WLS application (servlet, EJB, JSP, or RMI object) and add code for accessing WLE objects and operations:
Configuring an IIOP Connection Pool
Configure an IIOP connection pool for each WLE domain that you want to access from a WLS application. To do this, modify the weblogic.properties file as described in Setting Up WebLogic Enterprise Connectivity.
The rest of this section describes optional procedures for configuring and monitoring an IIOP connection pool:
Configuring Security Context Propagation
To configure an IIOP connection pool to use security context propagation:
For information about the ISL command, see the WebLogic Enterprise Reference:
securitycontext=YES,\
For details about this parameter, see Setting Up WebLogic Enterprise Connectivity.
username=myself,\
For details about this parameter, see Setting Up WebLogic Enterprise Connectivity.
If the username that WLS sends does not match a WLE username, WLE returns a CORBA.NO_PERMISSION exception to WLS. If WLS does not send a username, WLE uses the username that was used to establish the trusted connection pool.
Configuring an IIOP Connection Pool for SSL
To configure an IIOP connection pool to use SSL:
This step is necessary because you cannot install the WLE Encryption Package kit unless the WLE core bits are installed. Installing the WLE client installs the WLE core bits.
For the WLE CORBA Java client installation procedure, see WebLogic Enterprise Installation on Windows Systems in the WLE documentation:
The TUXDIR environment variable is necessary for the WLE Java client. Set TUXDIR to the directory in which you installed the WLE Java client software.
The Encryption Package kit provides the SSL functionality.
For the Encryption Package installation procedure, see WLE Encryption Package Installation on Windows Systems in the WLE documentation:
See Configuring the WLE Environment for the SSL Protocol in the WLE documentation:
appaddrlist=corbalocs://555main.com:1024;corbalocs://main.com:1024,\ failoverlist=corbalocs://555failover.com:1024,\
For details about these parameters, see Setting Up WebLogic Enterprise Connectivity.
certificatebasedauth=YES,\ minencryptionlevel=56,\ maxencryptionlevel=128,\
For details about these parameters, see Setting Up WebLogic Enterprise Connectivity.
If an IIOP connection pool is configured for SSL and a WLS application sends a request that does not contain the correct security information, WLEC returns an error.
Monitoring an IIOP Connection Pool
To monitor IIOP connection pools, use the WebLogic Console as described in Running the WebLogic Console.
Reinitializing an IIOP Connection Pool
You can use the Commands tab in the WebLogic Console to reinitialize WLEC IIOP connection pools without stopping WLS. See Running the WebLogic Console for information about reinitializing an IIOP connection pool.
Accessing a CORBA Object
This section describes the steps for accessing a WLE CORBA object from a WLS client.
Step 1. Create Client Stubs
Client stubs provide the programming interface for CORBA object operations. To create client stubs:
See Using the idltojava Command in the WLE documentation:
Step 2. Import Java Packages
Import the following Java packages:
import org.omg.CORBA.*; import com.beasys.Tobj.*; import com.beasys.*;
Step 3. Connect the Application to a WLE Domain
Each IIOP connection pool has a Tobj_Bootstrap object that lets you access the pool. WLEC provides an object called BootstrapFactory, which provides access to the Tobj_Bootstrap object. To connect the application to a WLE domain:
Tobj_Bootstrap myBootstrap = Tobj_BootstrapFactory.getClientContext("myPool");
About this code:
See the WebLogic Enterprise Connectivity API Reference for information about Tobj_Bootstrap.
Step 4. Get an Object Reference
Use the FactoryFinder to get a reference to a CORBA object:
org.omg.CORBA.Object myFFObject =
myBootstrap.resolve_initial_references("FactoryFinder");
FactoryFinder myFactFinder =
FactoryFinderHelper.narrow(myFFObject);About this code:
org.omg.CORBA.Object myFactoryRef =
myFactFinder.find_one_factory_by_id(myFactoryHelper.id());
myFactory =
myFactoryHelper.narrow(myFactoryRef);
About this code:
Call the object's "find" method. For example, if you are accessing an object named Simple, this line of code could be:
Simple mySimple = mySimpleFactory.find_simple();
About this code:
For information about the FactoryFinder interface, see FactoryFinder Interface in the WLE documentation:
Step 5. Start a Transaction (optional)
You can access WLE objects within transactions. This sample code uses TransactionCurrent. You can also use UserTransaction when accessing a CORBA object. To start a transaction:
org.omg.CORBA.Object myTCObject =
myBootstrap.resolve_initial_references("TransactionCurrent");
CosTransactions.Current myTransaction =
CosTransactions.CurrentHelper.narrow(myTCObject);
About this code:
myTransaction.begin();
About this code:
See Transactions Topics in the WLE documentation on the Web.
Step 6. Access Objects and Operations
Call methods on objects that belong to the WLE domain associated with the IIOP connection pool.
If you are accessing objects within a transaction context, you can also use the following TransactionCurrent methods to manipulate and query the transaction context:
Step 7. End the Transaction (optional)
If you accessed objects within a transaction context, use one of the following TransactionCurrent methods to end the transaction:
Accessing an EJB or an RMI Object
This section describes the steps for accessing a WLE EJB or RMI object from a WLS client.
Step 1. Create Client Stubs
Client stubs provide the programming interface for EJB and RMI object operations. To create client stubs:
For more information, see the RMI compiler information in the WLE documentation:
Step 2. Import Java Packages
Import the following Java package:
import javax.naming.*;
You also need to import a package for the stubs and skeletons of the EJB or RMI object you access. For an example of how to import a package for stubs and skeletons, see the WebLogic Enterprise Connectivity JSP Stateless Session Bean Example.
Step 3. Connect the Application to a WLE Domain
Use a hash table to set environment properties for the JNDI InitialContext class. The InitialContext class implements the Context interface and provides the starting context for naming operations. The environment properties determine how the InitialContext attaches to an IIOP connection pool. To connect the application to a WLE domain:
public Context getInitialContext() throws Exception { Hashtable myEnvironment = new Hashtable(); myEnvironment.put(Context.PROVIDER_URL, "wlepool://myPool"); myEnvironment.put(Context.INITIAL_CONTEXT_FACTORY, "com.beasys.jndi.WLEInitialContextFactory"); myEnvironment.put(Context.SECURITY_AUTHENTICATION, "securityStyle"); myEnvironment.put(Context.SECURITY_PRINCIPAL, "username"); myEnvironment.put(Context.SECURITY_CREDENTIALS, "password"); return new InitialContext(myEnvironment); } . . . myContext = getInitialContext();
About this code:
These properties are described in the Javadoc API reference for the Context interface:
Some of these properties are also described in Using the WLE SPI Implementations for JNDI:
Step 4. Get an Object Reference
To get a reference to an EJB or RMI object, perform a JNDI lookup and cast the object:
myObjectRef = (myObjectType)myContext.lookup("objectName");
About this code:
Step 5. Access Objects and Operations
Call methods on objects that belong to the WLE domain associated with the IIOP connection pool. If desired, you can access objects and operations within a transaction context. To access EJBs and RMI objects in a transaction context, you must use UserTransaction.
For More Information About EJBs and RMI Objects
See the following topics in the WLE documentation:
Modifying a WebLogic Enterprise Application
To change a WLE application into a WLS application:
Working with Transactions
This section covers the following topics:
Multithreading
The WLE 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 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 WLE system throws an InvalidControl exception.
UserTransaction does not support suspend() and resume(). Therefore, you cannot use a transaction in multiple threads when you use UserTransaction.
Multiple Active IIOP Connection Pools
WLEC supports multiple simultaneously active IIOP connection pools in a single WLS. When you call CosTransactions.Current.begin() or UserTransaction.begin() to create a transaction context, the WLE system associates the transaction with an IIOP 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 IIOP connection pool.
A transaction cannot span multiple WLE domains. If you try to make a call for an object in a different domain, the WLE system throws an INVALID_TRANSACTION exception.
Relationship Between Active Transactions and Connections
When a WLEC client starts or resumes a transaction, the IIOP connection pool infrastructure reserves a connection for requests that are sent in the context of the transaction. WLEC does not use this connection to send requests that are not in the transaction context. WLEC reserves the connection until the transaction is committed, rolled back, or suspended.
Note: 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, WLEC 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 WLS 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 WLS client invocation.
Note: Suspend and resume are available only for CosTransactions.
If necessary, you use a transaction in multiple WLS client invocations as follows:
Be careful when using this solution, because a transaction can time out before you make the next WLS client invocation.
Security
WLS uses the security attributes in the weblogic.properties file when it creates connections in pools. Therefore, applications on WLS do not have access to the WLE security API. If you try to access the security API by calling resolve_initial_reference("SecurityCurrent") on the Tobj_Bootstrap object, the WLE system throws an InvalidName exception.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|