Novell’s exteNd still a work in progress

Novell's exteNd is an umbrella product; its name spreads over several individual components that play separate roles in creating or deploying J2EE applications.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Novell exteNd Application Server 5.0 and Workbench Novell, novell.com Very Good  7.0 criteria score weight Ease-of-use 6 20% Interoperability 9 20% Management 6 20% Setup 7 20% Performance 7 10% Value 7 10% Cost: exteNd Application Server Developer Edition with Workbench, $495 per user; Professional Edition, $5,000 per CPU; Enterprise Edition, $10,000 per CPU Platforms: Windows 2000, NT, and XP; Linux; Solaris; HP-UX; AIX Bottom Line: ExteNd is a serviceable but plain application server, as is the accompanying Workbench IDE. However, the forthcoming Director and Composer tools, which will be associated with the exteNd app server, should make the whole greater than the sum of the parts. About our Reviews and Scoring Methodology

The center of the exteNd solar system is the exteNd Application Server. It is J2EE 1.3-compatible, and represents the evolution of the SilverStream application server that Novell acquired when it purchased SilverStream in the summer of 2002. Two companions orbit the application server, each the amalgam of a development tool and a run-time environment. One companion is the exteNd Composer, a development suite and run-time engine that taps into back-end data sources and wraps them as Web services. The other is the exteNd Director, aimed at the chores of constructing and executing portals and Web-based applications.

This three-component structure is still in exteNd's future; Novell is in the process of shifting the tools' structure to arrive at the triad described above. A fourth tool, exteNd Workbench, is included with the app server and will soon merge with the exteNd Director. I took a close look at Workbench and exteNd Application Server 5.0. They are good but need polish.

Rolling out Workbench

Workbench is the exteNd IDE and is archive-oriented; that is, the result of any Workbench project is an archive file ready for deployment to an application server. The first step in building any project within Workbench is the specification of the target archive -- WAR (Web Archive), EAR (Enterprise Archive), JAR (Java Archive), etc. -- which identifies the nature of the source code that will populate the project.

As with most other IDEs, Workbench is a den of wizards. There's an EJB Wizard, a Servlet Wizard, a JSP Wizard, Java Class Wizard, JavaBean Wizard, and Tag Handler Wizard. In all cases, the wizards jump-start a section of your project by creating skeletal source files whose content is guided primarily by the nature of the target, and secondarily by options entered through the wizard's dialogs.

Workbench's project architecture is reasonably capable. For example, projects admit subprojects as member elements. This is handy if you have a project that constructs an EJB, and you want to use that EJB in more than one J2EE application. Each of the J2EE application projects can become a "parent" project to the EJB child project.

When you create an archive from the Workbench, it also generates a "deployment plan," an XML file that resides outside the archive and acts as an application-server-specific deployment descriptor. This is an early breath of air from JSR (Java Specification Request) 88 (slated to become part of the JDK 1.4 standard). In a nutshell, JSR 88 -- among other things -- intends that the application-server-specific bits and pieces that currently litter deployment descriptors (and drive you mad) are pulled out of the archive, and moved to an external "deployment plan" file. What remains in the archive is generic information, but because their insides are unpolluted by application-server-specific data, archives will be more portable.

I encountered the "deployment plan" process when I tried to deploy a WAR (Web Application Archive) file that I had built in a separate IDE to the exteNd Application Server. I had successfully deployed and executed the WAR file on Tomcat, WebLogic, and WebSphere, so I knew it was reasonably generic. But the WAR file had no accompanying deployment plan, so I couldn’t use it as-is with Workbench.

Happily, the Workbench came to the rescue with its "deploy-only" project type, which let me import the WAR file. A deploy-only project takes an archive as input; within the project, you can invoke what amounts to a deployment plan wizard, which builds a skeletal plan. With my WAR file, the Workbench wizard conjured up enough of the plan so that I was instantly able to run the application on the exteNd application server.

The only other difficulty I had was deducing how to make the application server aware of my JDBC drivers. Execution went smoothly once I knew about the AGCLASSPATH variable, which specifies libraries and classes that the application server will make available to all applications. Adding a path to my JDBC drivers with AGCLASSPATH allowed the application server to “see” those drivers.

A Case of the Blahs

My initial opinion of an app server is heavily influenced by two things: how easy it is to deploy an application on the app server and the visibility that administration tools (usually a console) provide into the app server's internal workings.

Sadly, exteNd Application Server falls short on both counts. The first shortcoming, deployment, is only really a shortcoming if you try to work without exteNd Workbench. Without Workbench, you must use command-line tools to deploy applications and you must have a deployment plan file associated with the archive. (Of course, if you build a project within Workbench, it constructs the deployment plan for you.) Secondly, the exteNd Application Server places all deployed components into a database, rather than the file system. This means you cannot simply deposit archives into a server directory for "hot-deployment" as with Tomcat or JBoss, for example. Fortunately, this feature is slated for an upcoming release.

I’ve worked with many app servers that provide deployment tools as part of the administration console, but the exteNd app server does not. In addition, the app server’s console provides an extremely light quantity and quality of information concerning the application server's internal operations. For example, although I could use the administration console to list the objects deployed in the application server, the console would not allow me to read fundamental parameters of the WAR application such as the context root.

ExteNd Workbench is a decent IDE, but it follows a path pounded flat by legions of other IDEs. In at least one sense, that's a good thing. Most developers will have no trouble navigating the Workbench, and it gets the job done.

The exteNd application server is equally bland. Admittedly, the console is not the only vehicle for  evaluating the application server. It would be unfair, however, not to note that the exteNd application server is accompanied by the jBroker middleware products, which include a CORBA-compliant ORB (object request broker), a JMS (Java Message Service) implementation, a JTS (Java Transaction Service) implementation, and jBroker Web, which is a JAX-RPC environment for supporting Web service applications - all of which are becoming necessary ingredients in the J2EE and Web service world.

ExteNd is definitely a work in progress. Workbench's multi-app server support is welcome, and use of the deployment plan is certainly a move in the right direction. The promised confluence of Director, Composer, and the Application Server make the exteNd suite a toolset to watch.