Novell’s exteNd still a work in progress
Novell’s app server and Workbench IDE are bland, but sufficient for their duties
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.