Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Novell's exteNd still a work in progress

Novell's app server and Workbench IDE are bland, but sufficient for their duties

By Rick Grehan, InfoWorld, 12/05/03

Novell's exteNd is an umbrella product; its name spreads over several individual components that play separate roles in creating or deploying Java 2 Platform, Enterprise Edition (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 runtime environment. One companion is the exteNd Composer, a development suite and runtime engine that taps into backend 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 (Enterprise JavaBeans) Wizard, a Servlet Wizard, a JSP (JavaServer Pages) 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.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.