Enterprise Java Community: <a href="/tt/articles/article.tss?l=tsscluster3" class="_undecorated">Adding the Novell exteNd Application Server to TheServerSide Cluster</a>

Discuss this Article

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
Conclusion

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

We 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 descriptors

Now 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 descriptors

The 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.java

Since 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

We had a problem, where the performance was not as we expected with mod_proxy sitting in front of exteNd. The issue turned out to be that exteNd keeps a socket connection open for a client that uses keepAlive, and also keeps a server thread allocated to serve that client's subsequent requests, provided the server has sufficient free threads. This is really a performance feature, which avoids the overhead of opening a new socket connection and allocating a thread from the thread pool on subsequent requests. Apache mod_proxy was a performance bottleneck because it sends all requests through the same socket.
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.

Conclusion

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 (dion@theserverside.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.

PRINTER FRIENDLY VERSION