Managing server-side Java applications is the diciest challenge of running a Web site. Because your applications are coded to run on a particular server, your customer requests may wait or go unanswered if that server is busy or unavailable. Your programmers must then kick into crisis mode to modify your code and frenetically direct your requests to another server. But by this time, your exasperated customers may have given up.
It doesn’t take too many incidents such as these before your company’s reputation – and bottom line – begin to suffer. But before you begin waving the white flag of defeat, take a look at Secant Technologies Inc.’s Extreme Internet Server 3.5 (EIS).
By eliminating the need to modify program code, this Web application server allows you to automatically route customer requests to any available and functioning server, saving development costs, keeping your Web site speedy, and sparing you from countless emergency code modification nightmares.
EIS’s most notable competition comes from Apache JServ, an open-source tool that can be used only on an Apache Web server and uses a proprietary protocol between Web server and application server.
EIS is affordable and easy to use, making servlet deployment as simple as a few clicks of the mouse. For these reasons – and because it keeps your sales registers ringing – I give it a score of Very Good.
Java servlets and JavaServer Pages (JSPs) perform tasks that your Web server cannot handle, such as accessing a database to send on-line catalogues to customer browsers. Although there is a significant technical difference between servlets and JSPs, for the purposes of this article they are synonymous and I will refer to both as servlets.
Sure, Java applications are easy to deploy in a single Web server/application server scenario. But in the real world, you often have two or more Web servers allocated on multiple machines. Dividing work over multiple servers ensures speedy response time, much like having several clerks behind the counter in a physical shop. And if one machine fails for some reason, the others can pick up the slack.
Unfortunately, the pesky links that assign an application to an application server are hardwired into your code, which means that if you need to send requests to alternate servers, a crew of programmers must modify your code on the spot.
To avoid this configuration hassle, many companies sacrifice speed and rely on a static configuration except in the most dire emergencies. This can keep business slow.
No line-ups
EIS will automatically route servlet requests to alternate servers without modifying any code. Therefore, your applications (and customers) will not stand in queue or be completely ignored because a particular server is down or busy.
From the EIS console, your systems administrator can create a cluster of hosts, each containing multiple servlet engines, that work together to respond to your Web applications’ servlet requests. Your applications now have a pool of servers to choose from, and your site can successfully handle an application server failure or a sudden swarm of transactions.
EIS works on Linux, Sun Solaris, Microsoft Windows NT and Berkeley Software Distribution (BSD) operating systems. In addition, you can create mixed clusters with hosts running on any supported OS and control them from a single EIS console, which simplifies administration and saves time.
After installing the product without incident, I used a wizard to create the configuration database and list the characteristics of my cluster. Among other things, I specified which database system to use, the name of the primary host computer, and the user and password for the EIS console.
The wizard stored this information in the database table and I fired up the Distributed Service Coordinator (DSC). The DSC is the heart of EIS. Based on configuration data and transaction load, it assigns servlets to appropriate or alternate application servers. The DSC ensures that no request waits too long or goes unanswered.
I then used the Extreme Console GUI to add servers and servlets to my configuration.
Typically, your server will be a standard Java servlet engine, but you can start multiple instances and associate a service to each of them. The Web server will automatically assign an EIS service name to each servlet and send the request to the DSC, which will dispatch the server associated with that service.
This may sound complicated but it took me less time to activate this configuration than it did to describe it. After saving and activating the configuration, I was ready to test my sample application.
Backup application
From a browser on another machine, I typed the URL of my sample application and it appeared on my screen. I repeated the installation on a second machine, this time instructing EIS to share the database on the primary installation.
This created a backup application server to keep my Web transactions running should my first server fail or slow down.
I then shut down one server and launched the Web application again. I am happy to report that the DSC on the first computer routed the servlet request to the second machine and the requested information appeared on my client computer. I did not notice any delay.
Next, I shut down the server on the second machine and repeated the test. To my amazement, I again received my requested information, although it took a fraction of a second longer to appear.
The DSC had automatically started the server I had shut down. I tried this test a few more times, and every time I launched the application the server started automatically. I had a Web server system that I literally could not break.
Unfortunately, EIS does not currently support CGI or Perl scripts (although Secant plans to do so in a future release) nor does it support Microsoft Active Server Pages. These drawbacks limit the product’s overall market usefulness and prevent me from giving it a score of Excellent, which I otherwise would have.
Nevertheless, if you use servlets or JSPs, EIS is the answer to your most fervent prayers. It will keep your Web applications responsive and your customers happy. Furthermore, it does not require any changes to your existing servlets and allows easy administration by non-programmers. This combination of timesaving, wallet-sparing features easily earns EIS a score of Very Good.
Apicella, a technology analyst for the InfoWorld Test Center, is an experienced programmer and database administrator. Send him e-mail at mario_apicella@infoworld.com.
Review box:
Extreme Internet Server 3.5
Supplier: Secant Technologies Inc.
Platforms: Windows NT, Windows 2000, Linux, BSD/OS 4.1, Sun Solaris
Cost: US$895 per server on Intel machines; US$5,000 per CPU on Sun Solaris
Pros: Easy installation and administration of Java application server clusters; excellent scalability and resilience without code changes; complete support of most popular platforms; free developer’s licence
Cons: No support for legacy scripts (CGI and Perl) or Microsoft Active Server Pages
