Let's start by getting the naming business out of the way! First there was a company named Borland. Then, for apparently no good reason, they changed their name to Inprise. The Inprise name was supposed to encompass the Enterprise products (such as VisiBroker, Entera, etc.) and the Borland name was kept for the tools (JBuilder, Delphi, C++Builder, etc.). Well, all the name change did was confuse everyone.

No, they weren't bought out. Yes, it's the same company, with the same developers. No, I don't know why they changed their name. Late last year the name experiment ended, and the name Borland now reigns supreme, referring to all the products made by the company Borland (formerly Inprise, formerly Borland). Now, is that straightened out?

The reason for the immediate digression into naming concerns the product I'm reviewing. This product started life many years ago as an application server for CORBA development. It featured excellent tools that made creating CORBA applications a breeze, writing much of the plumbing code for you. That was the Inprise Application Server, and it predated Java 2 Enterprise Edition. When J2EE became a reality, the product kept the same name but completely changed over to an EJB container (along with many other application server services). The Inprise app server existed until version 4.1. Now we have the Borland Application Server version 4.5, which I am about to officially review. The point of this history lesson is to indicate that this product is not a Johnny-come-lately to the application server market. It's based on solid technology and has been around awhile.

Installation is straightforward, running a standard InstallShield installer. Borland AppServer (BAS) installs not only the classes necessary for J2EE compliance, but VisiBroker as well. It was smart to build BAS around the VisiBroker core because VisiBroker is a well-established, rock-solid ORB. Why reinvent the wheel - and create a buggy wheel - when you already have proven code lying around? BAS installs the app server itself, which runs as a console application. It also installs the Borland AppServer console, which is the graphical management console. The BAS console is a Java Swing-based client that's very impressive.

It features a tree view on the left that shows all the pertinent running services, including different nodes for different app servers. This means you can manage multiple app servers from the same console. It also shows a great deal of information on the right-hand side about the artifact selected on the left (see Figure 1). This shows the status of a container- managed entity bean that's currently installed and available.

The console also serves as the deployment tool for EJBs. It offers wizards (real, functional wizards, not simple little apprentices) to deploy EJBs, generate JAR files for clients from existing EJBs (what a great idea), merge JARs together (another great idea), and migrate from an EJB 1.0 bean to an EJB 1.1 bean. This console is by far the best I've seen for an app server.

The third installed tool is the Borland J2EE Deployment Descriptor Editor. This tool allows you to create deployment descriptors for just about any conceivable J2EE resource including EARs, WARs, EJBs, and JNDI, and is the tool used to create BAS deployment descriptors for EJBs. Figure 2 shows part of the dialog used to create a deployment descriptor for an EJB.

If you're familiar with JBuilder 4's EJB deployment tools, you'll recognize the ones from BAS - the code looks the same. Again, if you have a working code base, why rewrite it? Of course, this means that JBuilder and BAS are well integrated (as you'd expect). As with most application servers, command-line versions of all these tools exist, enabling the development process to be automated.

BAS is a very capable application server. I created and installed all different types of EJBs, including the dreaded container-managed persistent entity beans, without too much difficulty. BAS doesn't seem to care for JDBC 1.0 drivers (i.e., drivers that don't have support for javax .sql.DataSources). It's a little cumbersome to set up connection pools with these types of drivers, but this is understandable. No one uses JDBC 1.0 drivers unless they're forced to.

I did run into a few unusual naming service problems until I did some research and discovered that BAS doesn't really like to have the J2EE JAR file on the classpath that starts it. I assume that this interferes with the order in which it needs to load these classes. Once I removed it, I had no further problems.

I set up a cluster of two machines to test its ability, and it couldn't have been easier. I suspect this is because of the VisiBroker heritage, which makes it easy for machines to discover one another and use each other's services.

In summary, BAS seems to be a well-developed application server. I installed some EJBs and other services and informally stress-tested it, and it came through with flying colors. It looks like it has a smaller memory footprint than some of its rivals (this was in the marketing material and I confirmed it). Because it uses memory very efficiently, it should be able to support a larger pool of beans than most of its competitors on a single machine or cluster. The application server market is crowded and very competitive. BAS deserves to be evaluated against its competitors, where it should excel. It combines effective tools with high performance, proven technology, and ease of use.