InformationWeek

Glowacki points out that app servers don't just save time and money in the initial implementation. They also ease ongoing maintenance. "Say you write some Oracle code and six months later Oracle makes a change that affects that code," he says. "Without Metaserver, that would be our problem." Instead, since Metaserver keeps all of its Oracle connectivity up-to-date, Glowacki has effectively offloaded such issues to his app server vendor.

Indiana University's Walsh says some app servers can even help manage site code. "Most programmers want to just start writing code," he says. "But that can create a maintenance nightmare over time, especially since I can't depend on the programmer being here tomorrow to explain why they wrote something in a particular way." The structure of an app server brings discipline to coding, assembly, and methodology--something many programmers dislike. "But they're not the ones who are going to be responsible for these systems down the road," says Walsh. "I am."

However, IT departments pay a price for the speed of implementation that app servers offer. Because app server infrastructure and connectivity facilities are highly specific to each vendor's architecture, it's no simple matter to change app servers down the road. As more and more of its business logic is stored in a particular vendor's app server, a company can find itself tightly locked into that vendor's product line.

"There's definitely a lock-in factor," admits Ali Kazeroonian, chief technology officer at Active Research in Burlingame, Calif., which provides online buyer's guides to large sites such as Yahoo and uses Allaire Corp.'s ColdFusion application server. "And it's an issue that we have to consider as we move forward." This lock-in factor can be particularly troublesome if a company's app server vendor falls behind the competition in terms of features or standards support. "As long as they keep up, there's nothing to worry about," Kazeroonian says.

That raises the question: How much of an incremental benefit would make it worthwhile to undertake the labor required to switch from one vendor's tags and/or modules to another's? Kazeroonian estimates that such a shift would take a few months. That's not something that a dot-com development team trying to work at an Internet-time pace can easily afford.

Kazeroonian says one way to protect yourself against app server lock-in is to build applications in such a way that each application function is separated into its own discrete component. That way, if any particular feature of your app server becomes obsolete, you can replace it with another technology, without scrapping your whole system.

"If we don't want to use Allaire's load-balancing, for example, we can just go in and substitute someone else's tools instead," he says. "But you can only do that if you've designed your architecture that way from the beginning."

Another way to minimize vendor lock-in is to use an application server that lets programmers work in standard programming environments such as C++ and Java. This ensures that the investment in the app server doesn't require an additional investment to train programmers in a specific software environment.

Perhaps the most important standard in the app server market is Enterprise JavaBeans. First introduced in 1998, JavaBeans defines a standard architecture for server-side Java application components. Components written to this specification share a common mechanism for component distribution, transaction management, and security. Thus, JavaBeans-compliant components can theoretically be mixed and matched, regardless of whether they've been developed in-house or purchased from a third party, or whether they're part of an app server framework.

While application server vendors as a whole have been slow to fully embrace JavaBeans, some, including Bluestone and Metaserver, have shown support. And many app server users are hopeful that JavaBeans will help standardize a market that has been characterized by highly proprietary architectures. Planalytics' Worden is using JavaBeans exclusively for the next version of the Weatherplanner.com site. "Any app server that follows the JavaBeans spec will be able to run our code," he says. "So we will have effectively achieved the vendor-independence we're looking for."

continued...page 3
return to page 1