Macromedia JRun 4 review

JRun originally started life as an Allaire product designed to enable Java Servlets to run under standard web servers. It evolved to embrace the complete J2EE (Java 2 Enterprise Edition) specification, with version 3.1 achieving official certification. Allaire was then taken over by Macromedia, and JRun 4 has become a key part of the company's MX strategy, which covers web development from end to end.

Macromedia is best known for its design tools, including Dreamweaver, Flash and Fireworks, but it's repositioning both Dreamweaver and Flash as application-development tools, using a combination of the Flash Player and standard web browsers as the client. On the server, there's ColdFusion for tag-based application logic, or JavaServer Pages (JSPs) powered by JRun 4. ColdFusion MX generates Java, so JRun plays an integral part in both scenarios. With the full JRun, you can go to the next stage and deploy EJBs (Enterprise JavaBeans), with support for enterprise-level features such as transactions, load balancing and automatic failover.

JRun 4 is J2EE 1.3 compliant and sports many new features. Scalability is much improved, including support for clustering both at the web container level and for EJBs and other services. Deployment is easier, with hot deployment providing automatic recompilation and reloading of servlets, web applications and EJBs, although this feature is disabled by default and not recommended for production servers. The main benefit is during development, where deploying without restarting the server raises productivity.

Support for Web Services is strong and based on the Apache Axis SOAP engine. You can expose Java classes or EJBs as XML Web Services, and it's also possible to generate Java proxies for external Web Services based on their WSDL (Web Service Description Language) files. In theory, this means a JRun application can easily call Microsoft .NET apps, and vice versa, though there may be some compatibility issues for more complex interfaces.

There are a few more interesting aspects. One is that Macromedia has redesigned JRun to use JMX (Java Management Extensions). This means JRun's management tools use MBeans (Manageable Beans) to configure and control the server. This is irrelevant if you're simply using the web-based interface provided, but will be a great advantage for those wanting to create, extend or integrate JRun services. You can programmatically access most JRun packages through MBean interfaces.

Another important JRun feature is Flash Remoting. Flash is mainly perceived as a design tool, with a player that renders vector images and supports animation to enable effects that aren't possible in standard HTML. However, Flash movies are programmable through ActionScript, which means you can create Flash client apps. This is using Flash as an alternative to a Java applet or ActiveX control. The attraction of Flash is that it's cross-platform and, according to Macromedia, more widely deployed than any other run-time environment. You wouldn't want to code extensive program logic in Flash, but as a rich client for remote services it has advantages. Using JRun with the Flash Remoting service installed, you can have a Flash movie call functions in a remote Java component, opening up the possibility of database access or extensions to corporate business apps.

Getting started is straightforward. I compiled a simple JavaBean and copied it to the correct directory in a JRun server, adding this directory to the server's classpath. I then created a Flash movie and included Macromedia's NetServices ActionScript file. With a few additional lines of code, I was able to connect to the JRun server, create a service object representing the remote JavaBean, call its methods and display the results within Flash. You don't have to use JRun for this, since Flash Remoting is also available for other application servers, but it's an obvious choice. It's an easy route to more powerful Flash apps.