When you upgrade your Java EE applications to Oracle WebLogic Server and Oracle Fusion Middleware 11g, the external interfaces exposed by your applications can be affected. In turn, client applications that depend on those interfaces can be affected.
The following sections describe the ramifications of upgrade on application clients, as well as guidelines for addressing any the resulting client issues:
When an application is upgraded to WebLogic Server, JSP and servlet clients can be affected because of differences in the HTTP session state replication model between Oracle WebLogic Server and OC4J.
Unlike OC4J clusters, which can support any number of in-memory replicated copies of the HTTP session state, Oracle WebLogic Server in-memory HTTP session state replication supports only a primary-secondary, two-copy model.
In most cases, this difference should have no impact on JSP and Servlet clients; however, for rare cases where an application might explicitly rely on more than two copies of the HTTP session state to be available for its clients, consider using Oracle Coherence.
For more information, refer to the information about Oracle Coherence on the Oracle Technology Network (OTN):
The following sections describe considerations for clients of upgraded applications that use the OC4J Java Naming and Directory Interface (JNDI) provider:
Modifying Clients to Use the Oracle WebLogic Server JNDI Provider
Understanding the Scope of the Oracle WebLogic Server JNDI Namespace
If any clients of your upgraded applications use the OC4J Java Naming and Directory Interface (JNDI) provider to lookup application interfaces or resources, then you must modify those clients so they use the Oracle WebLogic Server JNDI provider instead.
You can change the application's JNDI initial context creation code as follows:
Identify all instances of the OC4J JNDI URLs in the client code.
Typically the OC4J URL is structured in the following format:
prefix://host:RMI_or_OPMN_request_port:oc4j_instance/application-name
An example URL for an Oracle Application Server 10g installation with an OC4J instance named oc4j1 and a deployed application called myapplication would be as follows:
opmn:ormi://127.0.0.1:6003:oc4j1/myapplication
Note that the prefix can be opmn:ormi for a full Oracle Application Server installation that is using the Oracle Process Management and Notification infrastructure, or it can be just ormi: if you are using a standalone OC4J installation.
Change the URL of the provider so it points to the target WebLogic Server domain's administration server using the t3 protocol.
For example:
t3://127.0.0.1:7001
Make sure the security credentials are valid within the target Oracle WebLogic Server domain.
Change the initial context factory to the Oracle WebLogic Server WLInitialContextFactory class.
This class should also be made available to the client application's class loader through a Oracle WebLogic Server client jar file. You create the client jar file (wlfullclient.jar) using the WebLogic JarBuilder tool.
For more information, see the following sections in Oracle Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server:
Note that if the client is itself running within an OC4J server instance, the environment-naming-url-factory-enabled attribute in the server's server.xml may have to be set to true to allow the use of multiple JNDI providers within the same OC4J instance.
Another important difference between the OC4J and Oracle WebLogic Server JNDI providers that might impact client applications is the scoping of JNDI namespaces.
OC4J JNDI objects can have an explicit application scope. Therefore, when performing a lookup, OC4J JNDI clients can use a URL which identifies a specific OC4J server instance and includes the name of the target application.
The Oracle WebLogic Server JNDI objects on the other hand always have a global namespace. Therefore, a Oracle WebLogic Server JNDI client performing a lookup cannot specify a URL identifying a target application explicitly.
As a result, as part of the upgrade to WebLogic Server, you must ensure that the JNDI name of all JNDI resources deployed to the same WebLogic Server domain are unique, regardless of the application to which they belong. If necessary, JNDI clients must be modified to use their target object's unique JNDI name.
There are two cases where the upgrade of an application to Oracle WebLogic Server could have impact an impact on EJB client applications. Refer to the following sections for more information:
EJB clients in this category are either stand-alone or deployed to an OC4J server.
For this category of EJB clients, you must modify the client to use the Oracle WebLogic Server JNDI provider, as described in Section 6.2.1, "Modifying Clients to Use the Oracle WebLogic Server JNDI Provider".
The use of the WebLogic Server JNDI provider will lead to the client application obtaining WebLogic Server EJB client stubs that can potentially impact the client application as follows:
RMI Protocol: Client applications must use one of the Oracle WebLogic Server RMI transport protocols, rather than the OC4J RMI transport protocol, ORMI.
The default WebLogic RMI transport protocol is the Oracle WebLogic Server T3 protocol, but you can also use IIOP.
Load Balancing: In OC4J, client EJB requests can be configured to be load-balanced through the InitialContext JNDI object (random or sticky) across the OC4J cluster for each invocation of Context.lookup().
In Oracle WebLogic Server, EJB client request load-balancing is handled automatically by remote EJB client stubs. The load-balancing behavior of these stubs is configured through weblogic-ejb-jar.xml deployment descriptor configurations and can be set to occur at InitialContext creation or EJB method invocation time.
Note that the considerations mentioned here apply to either stand-alone clients or clients currently running within an OC4J server instance, and also those being upgraded to run within a WebLogic Server instance.
For EJB clients that are not deployed as stand-alone applications and that will continue running within an OC4J server instance and making remote invocations to an upgraded WebLogic Server EJB application, the following two additional implications of an upgrade should also be considered:
First, the application's security context will not be automatically propagated. If this security propagation is necessary, the client will require modification in order to explicitly use the existing security context's credentials at the creation of the WebLogic Server JNDI initial context.
Second, JTA transaction propagation and XA recovery within the context of the remote EJB invocations will not be possible and if needed the client application itself will require upgrade.
Applications that you upgrade might act as remote clients to EJB components that will continue running within an OC4J server. You must modify clients in this category to use the OC4J RMIInitialContextFactory JNDI initial context factory located in the oc4jclient.jar file.
The oc4jclient.jar file must be available to the Oracle WebLogic Server class loaders for the application. For more information, see Section 5.3.4, "Using Shared Libraries and Class Loading on Oracle WebLogic Server".
Note that the propagation of security context requires the configuration of the target OC4J server instance as a Oracle WebLogic Server SSL client. Furthermore, JTA transaction propagation and XA recovery within the context of the remote EJB invocations will not be possible. If these features are required, then you must upgrade the target EJB application.
It should first be noted that the information contained in this section is with regards to JMS clients that are not Message Driven Beans (MDB). MDBs are usually tightly coupled to the JMS provider's resources and as such should always be upgraded together with these resources. Specific WebLogic Server MDB capabilities and behavior should be considered during the upgrade of MDB applications.The following sections describe two scenarios where the upgrade of an application to Oracle WebLogic Server might have an impact on JMS clients:
In this scenario, the JMS provider--and its related resources such as destinations and connection factories--is upgraded to Oracle WebLogic Server. You must modify both the upgraded client applications and the existing OC4J client applications still running within an OC4J server.
Specifically, you must modify the client applications to use the WebLogic Server JNDI provider as described in Section 6.2.1, "Modifying Clients to Use the Oracle WebLogic Server JNDI Provider".
When you modify the clients to use the Oracle WebLogic Server JNDI provider, the client applications obtain JMS resources from the Oracle WebLogic Server JMS provider and the following considerations should be taken into account because they could impact client applications:
Message Ordering: Like the OC4J JMS provider, Oracle WebLogic Server provides the capability to guarantee strictly ordered message processing. Additionally, the WebLogic Server JMS "Unit of Order" feature allows for additional message order processing capabilities. For more information, see "Using Message Unit-of-Order" in Oracle Fusion Middleware Programming JMS for Oracle WebLogic Server.
Connection Pooling: Unlike the OC4J JMS provider, the Oracle WebLogic Server JMS provider provides no pooling capability for stand-alone clients. If this feature is required, stand-alone clients should be modified to implement this capability through explicit re-use of JMS resources.
Network Connections: Clients using the WebLogic Server JMS provider use a single network connection per client virtual machine, regardless of the number of JMS connection objects used. This behavior is slightly different from the OC4J JMS provider, which associates each JMS connection object with a separate network connection.
JMS clients that are not stand-alone applications and that continue running within an OC4J server instance while using JMS resources within a WebLogic Server environment should use the OC4J Oracle Enterprise Messaging Server JMS Connector feature.
In this scenario, the JMS provider remains within an OC4J infrastructure and client applications being upgraded to Oracle WebLogic Server require adjustments. These types of client applications should treat the OC4J JMS resources as remote JMS providers and use the Oracle WebLogic Server "foreign server" feature in order to provide access to the OC4J JMS resources to the WebLogic Server deployed JMS clients.
For more information, see "Configuring Foreign Server Resources to Access Third-Party JMS Providers" in Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.