App Server Attack!

Web application servers are more than just middleware solutions. These infrastructures-in-a-box let developers build and manage Web apps easier than ever before.

Additional Information

BEA Systems Inc., WebLogic

HP Bluestone, Total-e-Server

IBM, WebSphere

SilverStream, SilverStream Application Server

When David Cooper needed to design a Web site where people could apply online for student loans and access financial information, he faced what he describes as an almost bewildering number of problems. Cooper, a project manager with Sallie Mae Inc., explains, "We didn't have the necessary resources to develop a custom solution in-house."

Sallie Mae is a major player in the education space, managing more than five million loans for college students of all ages. Thus, application security and availability are key concerns.

In the end, Sallie Mae enlisted the expertise of IBM's Global Services division. Together, they decided to design on top of IBM's WebSphere Application Server. The new Web site—christened—is tightly integrated with the company's existing IT infrastructure.

The result has been an unqualified success: "The application was developed to leverage WebSphere technology," Cooper explains. "We succeeded in developing an application that is highly scalable and easy to manage."

A Global Issue
Sallie Mae's experience parallels that of many other companies seeking to retrofit and revamp their information systems for e-business. Increasingly, organizations are foregoing blends of traditional and custom-developed middleware solutions, and are instead deploying packaged Web application servers, such as IBM's WebSphere, BEA Systems' WebLogic, HP's Total E-Server or SilverStream Software's SilverStream Application Server.

"Companies are buying packaged applications, so we [see] over and over that people want to buy middleware solutions rather than build them themselves," confirms Dave Miller, director of product management with the Non-Stop Software division of Compaq.

Enterprise Middleware Then and Now
Once the exclusive helpmate of mainframes, transaction-processing, message-queuing and other specialty systems, enterprise middleware has evolved substantially.

"There have been dramatic changes," agrees Judith Hurwitz, president of the Hurwitz Group. "Ten years ago, middleware was just part of the infrastructure. It was tightly designed into the application itself, so when you bought an application, the middleware would be an integral part of that—it often would not be a separate process or a separate technology."

Today, Hurwtiz says, application vendors and IT organizations alike are increasingly looking at middleware as a kind of separate, middle-level operating system to which applications can be written. Middleware thus becomes the infrastructure.

"If you define middleware as a set of software services that ensures communication between different systems and different processes, then you're really talking about an infrastructure, aren't you?" Hurwitz concludes.

John Capobianco, general manager of strategic marketing for HP's middleware division, agrees. According to Capobianco, as organizations gear up for an expected age of e-services, a new kind of middleware infrastructure—which he designates an "Internet operating environment"—will work to tie old and new information systems together.

"This whole world of e-services and Web services demands a scalable and robust infrastructure that we're calling middleware," he comments. "This new kind of middleware is actually a conglomeration of loosely coupled application sets that provide application server and integration server capabilities in tandem."

Delayed Obsolescence
Capobianco believes that transaction processing, message queuing and other such middleware solutions that have powered the enterprise for decades won't simply disappear. Rather, IT organizations that have existing investments in these legacy technologies will work to integrate them with the "sexy" new e-business applications that power their e-commerce sites. The Web application server functions as a key point of integration.

Many companies may even find themselves implementing these technologies anyway. Compaq's Miller explains, "If you look at lots of dotcoms and their start-up environments, they typically start out with sort of a straightforward client-server database application but quickly discover that they need something like Tuxedo or CICS to get it to scale, and of course WebLogic and WebSphere support both of these."

New Face on Enterprise Middleware
When it came time for Mark Atchison's business unit at EDS to implement a new Web application server for a client's Internet banking application, he knew better than to develop it himself.

Atchison, who used to build systems himself before Web application servers were available as prepackaged fare, says that custom developing a sophisticated, custom middleware component, such as a Web application server, is a thankless task.

"Outside of the cost and expense of writing the Web application server, which were considerable, and the design and engineering time to test it and write it and whatnot, you tend to write something that's only as specific as what your requirements are at that point in time," Atchison explains.

As a result, Atchison found himself spending more time maintaining the Web application server and less time managing and enhancing the Internet banking application for which he'd build the server.

"When we'd finally written our own Web application server, I couldn't modify anything in the target app without having to touch the Web application server again," he says.

Like his counterparts at Sallie Mae, Atchison went shopping for a packaged Web application server. He eventually chose the Sapphire Web Server from Bluestone Software, which has since been acquired—and rebranded—by HP as Total-e-Server.

Atchison's experience exemplifies both the good and bad ways in which Web application server middleware is revolutionizing application development.

One Big Snag
Shortly before Atchison's team was due to deliver a production-ready solution to its client, Atchison discovered that the Web application server simply wouldn't work with his client's existing network infrastructure.

After substantial give-and-take, Bluestone eventually acknowledged that the problem was with its software and not with his client's network infrastructure or with the Internet banking application itself.

"We had to spend the better part of a week proving to this vendor that it was their software that was not operating to specification, and in the meantime, my client delivery date had slipped past," he concludes.

Bluestone eventually dispatched a technician, and Atchison's team was able to deliver a working solution to the client less than 24 hours later.

Famous AMOS
Altura International is another Bluestone/HP customer who has had great success with the Sapphire Web application server. The company's Altura Merchant Operating System (AMOS) application has run on Sapphire Web for almost a year—supporting an average of 100,000 users per day—without a hitch.

Altura's executive vice president of engineering, Vince Hunt, appreciates their ability to make quick changes. "We never stop adding features or new malls," he explains. "We just write the Java and HP Bluestone does the rest."

Open Sesame
Web application servers facilitate rapid application porting and deployment scenarios, preventing the platform compatibility issues that have plagued IT departments since the advent of client/server computing.

"Today, it's possible to build [applications] for the Internet, with less and less of an investment for any particular OS, because the OS no longer has to be the defining standard for applications," maintains Scott Hebner, director of marketing for WebSphere Software with IBM.

"If you build to the open standard of the Internet," he adds, "you no longer have to worry about porting your applications from one platform to another. It's the Web application server that provides support for these open Internet standards."

Most major Web application middleware vendors will support Java and XML; the Simple Object Access Protocol (SOAP), which defines a distributed object access protocol based on HTTP; and Universal Description, Discovery and Integration (UDDI), an XML-based specification that interoperates with SOAP, enabling software to discover available services on the Web automatically.

Upgradability and portability were key concerns for Vinh Dao, president of VoicePlanet Inc., a Web hosting and "office space" vendor. VoicePlanet initially considered developing its own application server middleware, Dao says, "but we decided to focus on just the application aspect of it, because we really couldn't design that kind of enabling technology ourselves."

Consequently, VoicePlanet decided to implement IBM's WebSphere Web application server. The company did so in large part because of WebSphere's support for Internet standards and heterogeneous operating system platforms.

"We looked at its support for different platforms, but the main thing that we wanted [was] upgradability," explains Dao. "Programming for WebSphere lets us provide a solution not just for now, but probably beyond what we're currently doing."

Faster Time to Market
Writing one's own application server middleware is a tedious task. "It's one of those things that, on the surface, doesn't seem that difficult," says EDS' Atchison, "but then you start pulling the thread and pretty soon the entire sleeve unravels."

Such slow development cycles simply won't fly in the e-enterprise, maintains Hurwitz Group's Hurwitz. "If you have to build a new system every time, you'll never be able to be proactive with your business," she observes. "And as e-business gets more competitive, as companies need to be able to react faster with less money, answers, like ‘We'll need six months to build this' simply don't work anymore."

Packaged Web application servers ease the developer's burden by consolidating a suite of integrated software services, such as communications, failover and scalability facilities. In many cases, these would otherwise have to be written from scratch by a development team or achieved by means of discrete middleware point products.

"I don't have to worry about load-balancing, managing queues, restart and recovery, guaranteed delivery or managing sessions—I can focus on writing the application itself," Atchison concludes.

This added time means that developers can focus more on giving customers what they want. Compaq's Miller agrees. "Organizations can develop rather sophisticated applications without having spent a year implementing something and deciding that it wasn't really what they needed."