Application servers are not new. Many information systems, from mainframe transaction processing environments like CICS to the stored procedures of a DBMS, provide for the server-side execution of business processes. Running business logic on a server can improve security, managability, performance and reusability. With the explosive growth of intranets and the Internet, developers need a rich, flexible server to host their business applications---a server that complements the content from databases and Web servers.

As a platform, Java raises the bar for application servers. A Java application server marries the benefits of a robust, scalable application server with the expressive power and dynamism of the Java platform. Java's bytecode-based Virtual Machine allows objects, including both code and data, to be exchanged among heterogeneous systems. This means that rather than making an RPC call or sending a message composed of ints and structs to a server, a stock trading application can send a high-level business object like Order to a remote business component like Trader. Moreover, Java's dynamism allows applications to be partitioned and repartitioned at runtime by relocating a service component from one machine to another.

When it comes to deciding how to partition an application between the client and server(s), developers need flexible tools that best meet the needs of the problem at hand. For example, when performing an ad hoc query, you need database access directly from the desktop. But in a "thin-client" application, you want to hide the DBMS operations behind a set of reusable server-side business processes. Certain applications will require synchronous request-response between components (JavaBeans) or objects (RMI), while others are better organized using asynchronous communications like event publication and subscription, or point-to-point messaging. Just as developers use different kinds of collections for different kinds of data (e.g., Hashtable, Vector and Set), they also need a set of off-the-shelf tools (Remote Method Invocation, Events, Distributed JavaBeans) for tackling application communications.

Besides code mobility and partitioning, developers want to use Java-blessed programming models: database access via JDBC, name and directory services via JNDI, distributed objects via RMI and Enterprise JavaBeans, Web server plug-ins via Servlets, and event management and messaging via JMS. Merely wrapping a proprietary C/C++ API with Java won't cut it. Nor will inventing yet another set of non-portable proprietary APIs. Developers want to use Java industry-standard APIs so that the skills they learn on one project will be transferable to other projects and the code they write will run wherever there's a JVM.

Given that a developer should be able to assemble an application using best-of-breed products, a Java application server must be compatible with a diverse range of complementary technologies. It should work in harmony with leading Web servers and database management systems, and across heterogeneous Java platforms. The server should also work with major Integrated Development Environments (IDEs); it should not require the adoption of an IDE that is proprietary to the application server.

Standards and portability don't stop at the server. GUI building technology used for multitier applications should use standard widgets and JavaBeans - not yet another proprietary set of widgets. Any automatically generated Java code should be accessible for further customization so that you can tweak it, should you choose to, and not worry about getting out of sync with the tool.

Finally, a Java application server should provide an integrated management environment that offers a comprehensive view of the application and the server. Transaction semantics must be built in to ensure data integrity even across distributed components, and the Java application server must address network security using SSL and access control lists. The server should also allow access to the broadest number of clients through standard protocols like HTTP and IIOP. And in the end, a Java application server should be written entirely in Java so that it is portable, it can be easily embedded within value-added applications and so that new Java-native capabilities can be delivered rapidly to market.

This is a tall order. Java has been out of beta for about two years and many of the products and applications written in it have been servlet and applet plug-ins to non-Java systems rather than full-blown production applications. The time for the all-Java application server is now, and developers should demand nothing less in the server than the Java API standards, stability and robustness they require in the client.