Java Development News:
Adding the Novell exteNd Application Server to TheServerSide Cluster
By Dion Almaer
13 May 2003 | TheServerSide.com
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.
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.xmlWe went through the EJBs and made links to other beans that they needed to lookup and add the ejb-refs. For example,
<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 descriptorsNow we have the standard ejb-jar.xml happy, but we need to go through all of the vendor descriptors to link up the references to the real location in JNDI. This is where having a cluster of different vendors makes it more work :) If we had been using something like
XDoclet, then these could have been auto-generated for us of course :)
Don't forget the web.xml / vendor web descriptorsThe web tier (Action classes) needs to lookup the beans too, so we needed to add the same EJB references to their descriptors. We only have to link in the Session Beans of course (which also has the side benefit of not allowing a sneaky developer to lookup an Entity directly from the web tier! Take that!).
Updating EJBHomeFactory.javaSince we had abstracted all EJB lookups into an EJBHome Factory, all we had to do was make one change, and the entire app was then going to the ejb-references instead of to absolute JNDI names. Simple.
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
Like other vendors, Novell has an Apache module (Web Server Integration (WSI)). It uses multiple sockets and also supports connection pooling for improved performance. So, we changed our Apache config to use this module, and the performance came back. Perfect.
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
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.