[BACK]

Migrating J2EE Applications from
BEA Weblogic to Lutris EAS 4.0

The J2EE specification provides guidelines on how to build applications using it various technologies such as Enterprise JavaBeans, Servlets, JSP, etc.  These guidelines are designed to assist developers in developing applications that are portable across J2EE application servers regardless of vendor.  However, a number of factors prevent automatic portability. These factors come from two primary sources:

  • Functionality in the specification which are either vague or optional
  • Non standard features provided by application servers either due their pre-J2EE origins or features that are meant to address real world problems that have not yet been addressed by the specification.

Diamelle Technologies provides several suites of EJB components targeted at e-Commerce, CRM, Content Management and Security. In total there are approximately 75 EJB components and large number of supporting classes that offer features such as Object Relational Mapping, workflow, Property containers, composites, etc.  We had already deployed our components to a number of popular application servers, including BEA Weblogic, iPlanet and WebSphere.  We recently added EAS 4 from Lutris on to our list of supported servers. The process took us two days to deploy the components and run some initial tests. 

It should be noted that we originally authored our EJBs to run on WebLogic following the EJB spec and avoiding functionality that was clearly proprietary.  Then, over time we decided to port them to iPlanet 6.0 and WebSphere 4.0 and.  This experience resulted in  minor changes to the EJBs themselves.  Most changes pertained to obtaining the JNDI context and environment variables that were defined in the deployment descriptors..  Once we decided to port to Lutris EAS, however, our earlier efforts to enhance portability paid off. There were no code changes to any of the EJBs and much of the porting time was spent in creating new deployment descriptors.  The rest of this article highlights some areas that we found are worth paying attention to, so that portability between servers is facilitated.

Porting Deployment Descriptors

We started our deployment process on to EAS by creating new deployment descriptors for each of the EJBs that we had written.  Our samples also create Servlets, but we’ve found that Servlets, and the corresponding web.xml deployment descriptor, is rarely in need of modifications between J2EE servers [see Glen Carl’s article in the previous LEJ for migration WARs from WebLogic to Lutris EAS]. We found that we were able to take the ejb-jar.xml file from other servers like BEA and use it as is. It’s worth noting that the ejb-jar.xml file should not have contained environment entries that contain values that are application server specific.  If your application does require environment entries, then you will have to create a new ejb-jar.xml file that contains values for environment values for EAS.  In our case, we had originally used a third party Object Relational mapping tool that required an environment entry to specify a factory that was app server specific. Fortunately we had replaced this with our own mapping solution that did not require this.

Next we create a jonas-ejb-jar.xml file.  This file is analogous to the Weblogic-ejb-jar.xml file does in WebLogic. While you can create this file from scratch, a utility is provided that will derive the jonas-ejb-jar.xml from the ejb-jar.xmlA sample of the Weblogic-ejb-jar.xml and corresponding jonas-ejb-jar.xml are shown below:

Weblogic-ejb-jar.xml

    <weblogic-enterprise-bean>
        <ejb-name>diamelle.common.CategoryService</ejb-name>
        <reference-descriptor>
            <resource-description>
                <res-ref-name>jdbc/diamellePool</res-ref-name>
                <jndi-name>diamellePool</jndi-name>
            </resource-description>
        </reference-descriptor>
        <jndi-name>diamelle.common.CategoryService</jndi-name>
    </weblogic-enterprise-bean>

jonas-ejb-jar.xml

          <jonas-session>
                   <ejb-name>diamelle.common.CategoryService</ejb-name>
                   <jndi-name>remote:CategoryServiceHome</jndi-name>
                   <jonas-resource>
                             <res-ref-name>jdbc/diamellePool</res-ref-name>
                             <jndi-name>diamellePool</jndi-name>
                   </jonas-resource>
          </jonas-session>

JNDI Context

While simple in nature, failure to have a portable mechanism to obtain the JNDI context will make portability difficult for applications that rely on EJB. Under the EJB 1.1 specification, obtaining a context using new InitialContext() from a Servlet will ensure portability in J2EE compliant application server.  However, this will not work if you are accessing the beans from a remote client, such as a swing application. In this case you will most likely be using RMI/IIOP. You will also need to pass in a series of properties into the InitialContext() that it may locate your application server host and use the appropriate classes.  It is under this scenario that there is great variation among servers.  We abstracted this out through a factory object that uses implementation classes to obtain a JNDI context. The factory class reads a resource file to obtain the properties. Using these properties, the appropriate concrete class is instantiated that will in term lookup the context.  The benefit of this design is that you can change servers without impacting code the client code. 

Looking up EJBs

Another area that can cause incompatibility is the way an EJB is accessed in the lookup. Suppose you have an Order EJB that has a JNDI name of “diamelle.Order”. Weblogic allows you lookup the ejb using

 javax.rmi.PortableRemoteObject.narrow(ctx.lookup(“diamelle.Order”),homeClassName)

EAS, like many J2EE server, requires a slight variation:

javax.rmi.PortableRemoteObject.narrow(ctx.lookup("ejb/diamelle.Order"),homeClassName);

We addressed this variation in much the same as the above. We abstracted it out. So the differences are maintained in an implementation class and the client layer is not bothered by these differences.

Final Thoughts on Porting from BEA:  Startup Classes

Weblogic provides a feature outside the J2EE specification called a Startup class that can be used for application initialization or other tasks that need to occur before an application starts. Lutris EASdoes not directly offer a startup class feature.  If an existing application that uses Startup Classes needs to be ported to EAS, then some of this functionality will likely be implemented in EAS using the init() of a Servlet.  For more sophisticated tasks, EAS also supports the creation of custom services that are loaded upon application startup.

Creating portable J2EE applications is possible today. However, we need to be aware of certain problematic areas and address them. As the J2EE specification evolves, developers will have to spend even less time in addressing portability as it will be even better defined in the spec.

 

[TOP]
 
Legal Notices ---- Privacy Policy