One of the first things that crossed my mind after being asked to review JRun 3.0 was this: How could I objectively evaluate this product without being biased by my own experience working with a competing product? To give you a little background, all but one of the major Internet application projects I've worked on used this other product (which will remain nameless) as their Java application server. In addition, I've seen this product used so often in conjunction with Oracle Enterprise and Sun servers that the combination in my mind has become a semiofficial architectural standard. Despite its prominence in the Java application server space I had to come to the realization that other application servers on the market are just as capable and have unique and desirable features of their own. One such product is Allaire's JRun Application Server 3.0.
JRun 3.0 ships with several new features that make it very competitive, including an Enterprise JavaBean (EJB) server, advanced transaction and messaging services, and improved load-balancing and fail-over services. Add some new development features, and you have a viable alternative to develop large-scale Internet applications. It's not that JRun doesn't have a large installed base. With over 20,000 licenses sold JRun is one of the most widely adopted JSP/servlet engines around. The full adoption of the Java 2 Platform, Enterprise Edition (J2EE) makes this product all the more capable.
Reviewing a Java Application Server for J2EE can be a daunting task. Instead of providing you with a laundry list of JRun's features (which will only put you to sleep), I decided instead to concentrate on those things a developer would need to know to get started, including installation, licensing issues, hardware/software prerequisites, and J2EE features. I'll also provide an administrator's view of the product. Finally, I'll cover some of the unique features of JRun, especially those that help it stand apart from the competition.
Okay, you want to get started as a JRun developer. First, you'd typically ask: How do I get a copy of the product and how much time do I have before the evaluation period ends? In addition, you'd need to know how much a development license costs and if enough has been budgeted in the project plan. The latter two questions become a nonissue as we'll see later. The question of what kind of machine you need to install JRun on is also a lot easier because JRun is a 100% Java product. You can run it on a variety of machines, including Windows NT, Windows 2000, and Solaris. So far, getting JRun installed and running on your desktop is easy. How well is it documented? As I'll discuss later, the documentation is excellent and helpful in getting you going as a developer. Starting up with JRun is as easy as it sounds.
Key Developer Features
JRun 3.0 provides several new features that improve overall performance. Resource pooling is automatically implemented for various server objects, including database connections, JSP pages, and query statements. In addition, JRun uses a server side data cache that reduces disk I/O operations. Admittedly, outside of system logging I can't imagine what the server would need to cache; database I/O is typically processed by a separate database system.
Often when testing enterprise JavaBeans, you need to shut down the server to reload your components. The time it takes to shut down the service and bring it back up again time after time adds up. With JRun's Dynamic Bean, loading capability you can redeploy a beans implementation without having to restart the application server. There are some restrictions, though. For instance, you can change and reload only the bean's implementation and not its home and remote interfaces. If the interface does change, you'll need to recompile the jar file and restart the service. The second limitation is that you need to start the service in stand-alone mode (from the command line).
Overall, this feature can be especially helpful when you have many developers cranking out beans and deploying to a central development server. You can't afford to be constantly restarting the server every time a bean changes. The same mechanism used to redeploy EJBs is similar to the one used to redeploy servlets.
JRun comes with a set of JSP custom tags that allow you to work with common J2EE API calls without the need to directly program it in Java. The JRun Tag Library provides a convenient way to invoke common J2EE API calls, handle HTML form processing, populate dropdown lists, and use conditional JSP block expressions. For example, you can send a message to a specific JMS subscriber queue using a single JSP tag statement. Another surprisingly useful tag in the library does XSL processing and transformation of an XML source document.
In addition to the limited documentation provided out of the box on the Tag Library, you can download full documentation from Allaire's DevCenter located on their Web site. They do provide a quick reference card for most of the JSP tags. Although the JSP tag library is useful, there's no way to handle the J2EE exceptions occurring within the embedded HTML files. This essentially leaves you at the mercy of the default exception handler resident in the JSP/servlet engine.
JRun provides out-of-the-box J2EE functionality, including Java Message Service (JMS) and Java Naming and Directory Interface (JNDI). You can use the JRun implementation of these services or configure a third-party product to use with the standard APIs.
One of the points stressed by Allaire is that JRun 3.0 is fully compliant with the J2EE architecture and the server doesn't alter any of the interfaces or modify their implementation. In fact, JRun 3.0 is listed on Sun's Web site as a fully licensed Java 2 Platform, Enterprise Edition server. It also passes Sun's write once, run anywhere (WORA) requirements by getting a passing grade on the J2EE verification test suite. This means you're guaranteed that JRun fully implements the J2EE interface and can use components developed on other J2EE-compliant platforms on an interchangeable basis.
The JRun 3.0 application server also provides built-in benchmarking tools through its Instrumentation services. The Instrumentation service is a nonintrusive way to benchmark various method calls within a servlet and present the information to the log file. It's also flexible in that you can optionally change where the benchmarking information is sent. For instance, you can route the logging information to a different file or provide access to the information through an HTML page. The one limitation is that Instrumentation records only metrics for servlet method calls.
Although full J2EE compliance is a big selling point, Allaire still decided to include API extensions. It seems that every vendor needs to include some sort of unique capabilities to their product. Repeatedly you go through the same decision-making process on a project: Do you or don't you use the extensions provided by a vendor? The use of extensions can help make a more robust application, but they do have a tendency to lock you in to a particular product. It all depends on weighing the advantages and disadvantages.
The good news is that JRun 3.0 extensions are limited in scope. For example, one of the extensions involves extending the HttpServlet-Response interface allowing servlets to programmatically call a JSP document. There are a few more, but that's it. It's up to you whether to use them or not. In the case of JRun, use of extensions shouldn't pose a significant problem.
Finally, JRun 3.0 provides network connectors for the following Web servers:
- Microsoft IIS
- Netscape Enterprise/FastTrack/iPlanet
- Zeus WebServer
- O'Reilly WebSitePro
The request is processed by first passing it to JRun, then passing the results back to the Web server.
Key Administrative Features
The JRun 3.0 Enterprise Edition includes a copy of ClusterCATS, which provides robust features for Web site availability, load balancing, and fail-over services.
You can configure ClusterCATS to automatically restart a server if it's not responding using the Remote Method Invocation Daemon (RMID) protocol. The restart command is issued by the JRun monitor and associated probes and occurs when the server isn't responding to HTTP "GET" requests from the monitor. By design, the ClusterCATS service can only shutdown and restart the full JRun service. It doesn't have the ability to restart specific subsystems (for instance, only shut down and restart the EJB services). Since all services run under a single JVM, it's all or nothing.
One interesting feature ClusterCATS provides is the ability to feed load-balancing metrics to a Cisco LocalDirector router. Using Cisco's Dynamic Feedback Protocol (DFP), ClusterCATS provides the router with various load and volume metrics. LocalDirector then uses that data to make better load-balancing decisions across a clustered server environment. To use this feature you must have LocalDirector version 3.1.4 or later.
Clustering occurs at the HTTP request level (primarily servlets) and provides a high availability mechanism for your application. In addition, you gain a level of scalability by having more than one application server servicing HTTP requests.
JRun supports session-level failover by using session persistence in conjunction with ClusterCATS. Similar to other clustering strategies, ClusterCATS provides a "sticky" mechanism that will bind a particular user application session to a server, therefore maintaining session state on a single server. One area of improvement would allow an EJB client to use EJB services on any machine in a clustered server environment. JRun supports EJB servers distributed anywhere on the network.
Another smart feature is the ability to program the ClusterCATS administration module to diagnose whether a server is "up." To accomplish this, JRun allows you to configure small self-test operations called JRun probes that can be assigned to an individual monitor. In turn, each server can be assigned a monitor containing multiple probes. Each probe requires some custom configuration by the site administrator and works by comparing retrieved HTML content (from a specific URL) against a known good set. Any variation in the content or nonresponse by the server is considered by the probe to be a server failure, and the monitor will act accordingly to shutdown the service.
Last, JRun 3.0 provides an administrator with some flexibility in configuring the servers. For instance, you can run JRun as a stand-alone servlet engine or a servlet engine/EJB service depending on the configuration settings.
Installing JRun is a two-step process involving a straightforward setup program (for Windows 2000) and an HTML configuration step (see Figure 1). The setup program guides you through the usual application server questions, including what JVM you want to use (I had six on my machine - decisions, decisions), TCP/IP port designations, and more. The setup phase of the installation performed without any difficulties and has a clean, well-laid-out design. The individual setup frames provide just enough information so you can make an intelligent choice. Allaire took some extra care here. The installation CD also includes a JVM you can install if you don't currently have one on your machine. The Professional version requires JVM 1.8 or later (support for EJBs isn't included), while the Developer and Enterprise versions require JVM 1.2 or later.
One particular annoyance in the installation process occurred when I was asked to enter the initial administrative login on the JRun Management Console (see Figure 2). Although earlier in the setup you were required to enter an administrator password (that I remembered), I wasn't quite sure what the login name was. After trying different combinations of "Administrator," "Admin," etc., I finally stumbled on "admin" as the correct one. The proper login was mentioned on the password assignment page, but the help message was a bit confusing. I think the message "JRun Admin Password (Admin username is 'admin')" threw me off. It would help if the login defaulted to "admin" in this case to get you started.
The second phase of the installation is browser based and executed automatically by the setup program if you want to connect an external Web server to JRun. Here's where it became fun. The installation performed so cleanly that I decided to try to set up a connection between a Microsoft Internet Information Server (IIS 4.0) running on a separate NT server to my JRun service.
Having previously had the opportunity to set up and configure Microsoft's IIS 4.0, I realized that getting IIS to redirect HTTP requests to JRun wouldn't be an easy task. Getting the connection set up and working correctly is part skill, part luck, and part voodoo. Being somewhat adventurous, I let JRun's Connector Wizard walk me through the process (see Figure 3). This part of the setup seemed to be working correctly, and it was definitely going through the proper steps. For instance, it knew where to place the DLL file under the IIS virtual directory (c:\inetpubs\scripts) and provided directions as to when to restart the IIS WWW services on the NT server.
When the decisive moment came to test the connection from IIS to JRun, it didn't work. The only option at this point was to finish the installation process using the management console on IIS. For those of you familiar with IIS 4.0, you know what a hassle it is to successfully set up connections to third-party application servers using the administrator. There was also a slight glitch in the administrator where the connector wizard wouldn't proceed to the fourth step when the "Install as Global Filter" checkbox was off. There was no user feedback requiring you to check the box before proceeding. Aside from the problems encountered in the connection wizard, the JRun Management Console appears to be well designed and organized.
Documentation and Support
I've always enjoyed getting a boxful of manuals whenever I buy software. I guess it's something tangible to hold onto when you first learn how to use a product and you're not quite sure what's going on. At least you can strategically place the box in your cubicle to make a statement - hey look at me, I'm an expert (even though you don't have the slightest clue). Don't get me wrong. I think it's wonderful that you can download and install a sophisticated development product nowadays without even getting a CD, and through the vendor's Web site you're able to get enough PDF files to keep you busy reading for years. It's still nice to get a box. I guess you can call me old fashioned.
Anyway, what I am leading up to is that with JRun 3.0 you get a box full of the best-written documentation I've seen in a while for this type of product. Besides an installation guide, you get a comprehensive development guide, a samples guide, a guide to using ClusterCATS, and some handy quick-reference cards. In addition, you can go to their Web site for a wealth of additional information and development support. The Developing Applications with JRun manual is exceptional and not only provides you with a step-by-step approach to developing J2EE applications in JRun, it's also an excellent tutorial on J2EE technology itself. The guide provides plenty of examples and is very polished. Allaire gets extra credit for this one.
JRun 3.0 comes in three versions, Developer, Professional, and Enterprise. As a developer you often need to obtain a copy of a development product in advance of purchasing a license. For example, you may need the product for evaluation purposes. The most common reason is that it usually takes time to purchase and get a license key. Allaire gets some extra brownie points again - the licensing for JRun Developer is free. This takes a bit of the stress off the development team.
The Developer version limits you to three concurrent connections (plenty for the individual developer) and an unlimited number of concurrent JVMs. Of course, this version isn't meant for deployment purposes. The Professional version allows an unlimited number of JVMs and sessions for servlets and JavaServer Pages (JSP). This version is good if you're deploying a simple application using servlet and JSP technology without the EJB middle tier. The price is considerably less, too, so that you're not paying for unused functionality.
The Enterprise version comes with the full-blown J2EE environment, including EJB, JMS, and JTA. The Enterprise version also includes load-balancing and fail-over capabilities using Allaire ClusterCATS (mentioned earlier). All three versions are packaged without any type of Integrated Development Environments for EJB or JSP/servlet development. For that a good companion tool would be Allaire JRun Studio that's based on the HomeSite HTML editor.
JRun provides a competitive product in the Java application server space. Besides implementing J2EE, JRun provides some nice additions that make developing Java Internet applications a whole lot easier. The price is competitive, and it does provide better licensing flexibility than the competition. It could use some improvement in its current clustering implementation by providing fail-over mechanisms below the HTTP request level, but outside of that it has about everything you need to create sophisticated Java applications using J2EE architecture.
Joe Mitchko is a principal engineer with eTime Capital, Inc., where he specializes in Internet architecture.
Dell Inspiron 3800 notebook with Pentium 3 600Mhz
processor with 256M RAM. Windows 2000 Professional
with SP1 installed. He can be reached at
725 Grove St.
Newton, MA 02466
Phone: 617 219-2000
E-mail: [email protected]
Pricing: Developer - Free
Professional: $795 per processor
Enterprise: $4,995 per processor