Novell’s exteNd still a work in progress
Novell’s app server and Workbench IDE are bland, but sufficient for their duties
Novell's exteNd is an umbrella product; its name spreads over several individual components that play separate roles in creating or deploying J2EE applications.
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.