Migrate the EJBs from JVM to OC4J...?

Question

We are plan to migrate the EJBs modules from Oracle8i JServer to OC4J.
From now we have developed the EJBs by using JDeveloper as the following
conditions;
- JVM: Oracle8i JServer (8.1.6.3.0)
- EJBs: Session Beans only
- IDE tool: JDeveloper 3.2
And now we wanna migrate or re-deploy to the OC4J. Is there any good
suggestions or idea to do it? Also I wanna know sth to considerate...
Thanks in advance for any advice
Phyllis
null

Answer 1

It would be good for you to migrate to OC4J as performance in OC4J is a lot better. Here is a little migration writeup I had done sometime back. It is work in progress. Hope this helps.
Migrating EJB components from Database EJB container to OC4J
Author: Ashok Banerjee [[email protected]]
Oracle recommends the new J2EE containers in Oracle9iAS (OC4J) for deploying J2EE components. The goal of this paper is to recommend ways to migrate existing EJB applications, from database EJB container, to OC4J.
The database EJB container runs on the aurora session based Java Virtual Machine, whereas the new container runs on standard JDK (version 1.2.2 onward) .
The database EJB container runs in a database session. The database is itself the middle tier, in such a configuration. Users therefore have a logically three tiered architecture, that runs physically on two tiers. The database serves as both the middle tier and the backend. In such situations users would use the "kprb" driver (used for requests made from within the database). No further authentication is needed if the backend database is the same as the middle tier. Users can also use one database as the middle tier and another database as the backend.
In OC4J the middle tier does not require a database installation on the middle tier. This helps make the middle tier lightweight. OC4J is also seen to significantly faster than the EJB container inside the database. Since OC4J runs on regular JDK the user can run OC4J on the Java Virtual Machine which is best for his/her specific needs. OC4J however has a limitation in that does not support pure CORBA clients. Currently OC4J does not support RMI over IIOP either.
To migrate existing EJB applications from inside the database to OC4J the set of changes is minimal.
Code changes
1. Change all references in the code and any configuration files using JDBC URLs from kprb driver to either thin or oci. "kprb" driver is only for applications running inside the database. The new OC4J runs outside the database and therefore it must use thin or oci driver.
2. The database EJB container clientside JNDI lookups were like:
env.put (Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put (Context.SECURITY_PRINCIPAL, user);
env.put (Context.SECURITY_CREDENTIALS, password);
env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
Context ic = new InitialContext (env);
while in OC4J container the lookup code should read:
env.setProperty("java.naming.factory.initial","com.evermind.server.ApplicationClientInitialContextFactory");
env.setProperty("java.naming.provider.url","ormi://localhost");
env.setProperty("java.naming.security.principal","username");
env.setProperty("java.naming.security.credentials","password");
Context ic = new InitialContext (env);
3) Remove all references to oracle.aurora.* classes - they will not work with OC4J. These classes are specific to the container in the database.
4) Check for client demarcation of Bean Managed Transactions and remember that transaction in OC4J cannot be propagated across tiers. In other words client demarcated transaction will work provided the client is another EJB or a servlet in the same OC4J instance. This is also listed in the "Current Limitations" section.
Build changes
1. For EJB in the database we use loadjava to load classes into the database - this step is not necessary any longer for middle tier EJBs. The user merely needs to ensure that the classes are in the classpath.
2. Similarly the concept of resolver specification in the database EJB container ceases to be useful in OC4J. To make classes "findable" the user sets the classpath. In OC4J any jars in the $OC4J_HOME/lib directory are on the server side classpath of the application classloader. The user can also include classes in their own ear files before they deploy the ear. [If you do not know about the resolver specification, then you have not used it and do not need to know about it].
3. The database J2EE container did not have support for .ear files. The OC4J container supports J2EE standard .ear files. Both makefiles and ANT files are available in the code samples on OTN which show how to build ear files and also provides samples for the structure of the EAR files.
EAR File contains META-INF/application.xml
META-INF/orion-application.xml [optional]
applicationEjb.jar
applicationweb.war
applicationEjb.jar contains
META-INF/ejb-jar.xml
META-INF/orion-ejb-jar.xml
EJB classes
applicationWeb.war contains
WEB-INF/web.xml
WEB-INF/orion-web.xml
WEB-INF/lib/jar files needed
WEB-INF/classes class files needed for JSP servlets
For further information on how to write the xml files etc. please refer to their respective DTDs.
Both web.xml and ejb-jar.xml should be unaffected by the migration.
4. The deployejb tool used to deploy EJB to the database has been deprecated. In OC4J EJBs are deployed as shown below:
% java -jar admin.jar ormi://localhost:<rmi-port> userName password -deploy -file ejbdemo.ear -deploymentName jndiName
5. The ApplicationClientContainer does not need aurora_client.jar in the classpath instead it needs oc4j.jar in the classpath.
Configuration Changes:
1. In the database EJB container the configurations exist in database tables but in OC4J the configuration exists in industry standard XML files. By default these files are located at $OC4J_HOME/config directory. Users can start their OC4J instance with a different configuration using the -config switch to specify a different server.xml file.
%java -jar oc4j.jar -config config1/server1.xml
2. In the database EJB container scalability was achieved using the MTS architecture and session based Java Virtual Machine. In OC4J scalability is achieved by clustering and using the loadbalancer. For more details on loadbalancer please read <link to loadbalancer.doc>
3. The bindds tool used to bind data-sources to the JNDI namespace of the database EJB container is deprecated. In OC4J datasources are bound to the the namespace using the data-sources.xml in $OC4J_HOME/config. Non oracle data-sources can also be bound to the namespace. A typical entry in data-sources.xml could look like:
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="scott"
password="tiger"
url="jdbc:oracle:thin:@dlsun1688:5521:jis2"
inactivity-timeout="30"
/>
4. Database EJB container used database authentication (database roles and database users) to authenticate users to the middle tier. OC4J uses principals.xml file to list groups and users and perform authentication. One can also implement UserManagers for OC4J to perform more complex authentication.
5. The ports used by OC4J for RMI, JMS and HTTP are all specified in rmi.xml, jms.xml, web-site.xml.
6. Both OC4J and the database container SSL (client authentication as well as server authentication).
7. The database EJB container could only be remotely debugged using a jdb like interface by starting a debugagent on the server, and a debugproxy on the client. OC4J containers on the other hand run on JDK and can be debugged with any debugger. This is very useful for debugging EJB/Servlet application running in the server.
8. The database EJB container comes with a database and hence has AQ (Advanced Queue) available for JMS. With OC4J there is a default in memory JMS implementation. OC4J server program can also connect to other JMS implementations(including AQ) using jms.xml. However a JNDI context may need to be implemented for AQ.
Current Limitations
1. The OC4J container at present does not support 2 phase commit.
2. The OC4J container at present does not support transaction context propagation across tiers. Hence client demarcated transactions are not supported in OC4J except where the client demarcating the transaction is in the same container, for example an EJB having its transaction demarcated by another EJB or servlet, in the same container.
3. In the classic container Oracle did not support RMI-IIOP tunneling through HTTP however in OC4J RMI over HTTP is supported.
null