Migrating
J2EE Applications from
BEA Weblogic to Lutris EAS 4.0
By Suneet Shah, Chief Technology Officer,
Diamelle Technologies
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.
|