Introduction - The Portability Challenge
At the end of September 2002, TheServerSide ported its codebase to be clusterable around BEA WebLogic 7, and Oracle 9iAS - the ultimate display of J2EE portability in action. We then wrote an article which discussed the task. Since that time, we have focused on adding features to TheServerSide, to expand the usefullness of the site to our users. Recently we worked with Sun and added Sun ONE Application Server to the cluster. The latest vendor to join in the fun is Novell. This article discusses the port of TheServerSide to Novell's exteNd Application Server.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this article we will discuss:
- General Observations on Novell exteNd
- Differences in Novell exteNd and how we dealt with them
General Observations on Novell exteNd
Did you ever work with / try out / play with the SilverStream Application Server? I remember meeting developers who swore by it. At one training course for "another one of the big players" one student kept trying to show off how much easier it was to "do stuff" with SilverStream. The work bench really was easy to use... even in a time where many of the vendors were putting effort into the backend tech, but little into the developer GUIs.
As we all know, Novell purchased SilverStream, and the result is the Novell exteNd Application Server. Version 5 is J2EE 1.3 certified, and builds on the strong dev IDE for J2EE components, and Web Services. I used to feel that there were a couple of top J2EE vendors, and the others were way behind ... catching up. Now, they have caught up. Novell exteNd is a solid J2EE platform for development, and it even runs on Netware :).
Differences in Novell exteNd and how we dealt with them
You have probably read the porting efforts that we have gone through with BEA and Oracle, and then Sun. Just because there is a J2EE spec, doesn't mean that there isn't room to maneuver, or that servers have their own little quirks. This was the case once again. The port was fairly pleasant once again. I always fear the worst (I have been burned in the past), but our application was simple to port to Novell exteNd.
Here are the differences that we found with Novell, and how we changed the app to conform to them.
JNDI Namespace Issues
The TSS codebase didn't use <ejb-ref>s in the
EJBHomeFactory.java. Instead, all JNDI lookup's for the Home stub were through absolute bound entries. So, instead of looking up
java:comp/env/ejb/ThreadHome we looked up
portal.services.ejb.ThreadHome. Novell exteNd namespaces the JNDI tree to avoid collisions (it is hard to debug an error which is caused by two apps using the same JNDI name!). We knew that we probably should have been using ejb-ref aliases all along, so we changed our application to do so.
This change required:
Updating standard ejb-jar.xml
<ejb-ref> <ejb-ref-name>portal.ThreadHome</ejb-ref-name> <ejb-ref-type>Entity</ejb-ref-type> <home>portal.services.ejb.interfaces.ThreadHome</home> <remote>portal.services.ejb.interfaces.Thread</remote> <ejb-link>portal.Thread</ejb-link> </ejb-ref>
Updating vendor specific ejb-jar deployment descriptors
Don't forget the web.xml / vendor web descriptors
From mod_proxy to Novell exteNd Web Server Integration
We have found that having Apache doing it's job and serving the static content makes sense. So, we have an apache server running in the front, and it proxies requests back to the application server. This works for us as:
- Apache deals with static content which it is good at
- The application server can be secured more [no one can access it directly]
- Load balancing could be placed between these two tiers
Deploying the application
Each vendor has a hook in our Ant build system. For Novell, their hook split up the WAR file, so only JSPs / Servlet code went into it. All of the static content gets moved to the Apache server side of things. This keeps the war file nice and small for the application server. A few lines of Ant script later, and the application deployed just fine.
You can see that there were VERY few issues in porting to Novell exteNd. The ONLY code changes were to do with getting JNDI lookups happy. All lookups were converted to go through the
java:comp/env namespace. I expected more strange errors to come up, leading to needed vendor specific settings, but that didn't happen. Kudos to Novell on taking SilverStream and making it a fast, solid J2EE platform, and a viable choice for developers.
About the Author
Dion Almaer (email@example.com) is Chief Architect of TheServerSide.com, a service of The Middleware Company (www.middleware-company.com), one of the nation's leading training companies in EJB/J2EE and B2B technology training.