Macromedia JRun 4

For those who care about compliance with the latest standards, JRun 4 is compliant with J2EE 1.3 (as of this writing, J2EE 1.4 is in beta). For those who are price conscious, JRun is one of the lowest-priced application servers (besides the free ones like Tomcat). 

We evaluated a 30-days evaluation version of JRun 4 by installing it on a machine running WinXP Professional with JDK 1.4.0 and IIS 5.1 Web server. JRun 4 expects JDK 1.3.1 or higher to be preinstalled, and doesn’t install it automatically if it’s doesn’t find it there. Ideally, as the JDK is a critical component, it should ship with

JRun.

Once installed, configuring Web applications, Enterprise JavaBeans and Web services was a pleasant experience because of the graphical, Web-based JMC (JRun Management Console). We deployed a Web application consisting of JSPs and servlets, which was earlier running on Tomcat. We also packaged the same Web application in a Web application archive and deployed it on JRun without any problems. Re-deploying after making changes to the servlet code was a matter of a button click and happened without restarting JRun. JRun can also be set up to autodeploy a Web application. This is as simple as adding the parent directory containing the Web application/s to Auto Deployment Directories using JMC. Additionally, marking the Hot Deploy option automatically re-deploys Web applications upon changes. 

JRun 4 comes with connectors for Apache, IIS and Netscape Web servers. These connectors can be set up with a Web server to talk to JRun. Using JRun’s graphical Web server configuration tool, we were able to set up the connector for the IIS Web server easily. However, we found issues in using the Apache connector. The connector did not work for Apache 2.0 (we tested it with versions 2.0.39 and 2.0.43). In both the cases, it showed an error message saying mod_jrun20.c is not compatible with the version of Apache. The connector, however, worked fine with Apache 1.3 (version 1.3.27). 

An exciting feature bundled with JRun 4 is Flash Remoting MX. It is something similar to CGI and other server-side scripting technologies and enables a front-end designed in Flash to communicate with scripts/components residing on an application server like JRun. While in CGI, static and dumb HTML pages invoke a server-side script, with Flash

Remoting, Flash’s ActionScript is used to invoke the script using the Flash Remoting MX component. Thus, it is more powerful and flexible.

While it was easy to code and set up a simple hello world program to see the technology at work, for writing real world applications a good knowledge of ActionScript is required besides programming knowledge of JSPs, Servlets and

JavaBeans.

Flash Remoting MX component includes classes like RecordSet and DataGlue, which can be used to bind the data fetched from the database by a servlet or JavaBean, to a Flash component like a listbox. This is similar to the DataGrid component used in Visual Basic. To see Flash Remoting in action, Flash player version 6 or above is required, which gets installed along with Macromedia Flash

MX. 

The bottom line It was easy and straightforward to cluster multiple JRun servers. After registering/adding the JRun servers running on different machines through the JMC, we defined a new cluster domain (jruncluster). Subsequently, JMC prompted to add the registered servers to the cluster. Once done, the cluster was up and running. So, we were able to set up the cluster in three to four steps. Adding Web applications to the cluster was as easy as adding them to individual servers using

JMC.

Shekhar Govindarajan