J2EE provides a common set of processing constructs that provide common building blocks for creating e-commerce applications. In the case of connectors and containers, standardization relieves the development of infrastructure code, allowing application behavior to be declared rather than hardwired into the business logic.
Saying that two application servers are J2EE-compliant means that each interprets the deployment descriptors of the other and can reproduce the other's component containers. They provide the same services on which the application relies. What's not standard for application servers, though, are the components - the processing details and other content that provide a business process.
Standardization creates components that are more manageable. An organization that relies on J2EE doesn't want to create a new type of component to meet a previously unanticipated need. Having industry-defined component types and infrastructure dependencies avoids that.
The evolution of more deployable, more manageable Web applications won't stop with XML, prefab infrastructure services, or predefined component types. It's at the next level - codeless applications - that the differences between "standard" J2EE application servers are most telling. This is where implementation becomes a process of managing resources rather than of development or deployment. The focus is more inclusive, encompassing front- and back-end services, and the interface between them.
The goal is not just to provide an infrastructure server that one-of-a-kind applications invoke. It's to provide interoperable services so the distinction between these services and those provided by the infrastructure becomes as academic for IT as it is already for customers.
Mergers and partnerships require convergence of Web sites, which may not work technically, commercially, or even on an aesthetic level. Only when it addresses the totality of the application experience can the app server truly serve Web-ready applications.
Even if a partner's applications eventually demonstrate interoperability and cohesiveness, it may be too late. In an ideal world, no implementation would be needed, applications would plug into each other's URLs and work. The ultimate measure of a great application server is its ability to work within the Web environment. That requires interoperability, deployability, and manageability. Let's look at those characteristics.
In a nutshell, the best test of a true application server, as opposed to merely an infrastructure server, is to predefine application services, not just infrastructure. An application server should provide vertically integrated, server-based, ready-to-configure applications. By adhering to J2EE branding standards, an application server puts itself into a solid starting position to accomplish this. But providing superior interoperability, deployability, and manageability is just as critical.
- Interoperability: Sun provides tests and a test application against which vendors implement their servers as a model. But the real value of the branding program is that it gives organizations the opportunity to have their applications interoperate with their partners. They won't have to identify nonstandard code, write patches, or test servers.
- Deployability: Two obvious examples of this characteristic are hot swapping and synchronization. A third deployability shortcut is seamless, out-of-the-server support for different programming codes. Serving applications means the server should actually serve applications written in the various languages likely to be encountered in a Web environment - an environment likely to become even more heterogeneous.
- Manageability: A technology that allows you to plug-and-play application components over multiple servers takes you only partway. You also need a single, comprehensive, and simple-to-use, Java-based management console that lets the administrator configure every feature of the server and refresh all application components. It also calls for a public management API that lets application software do the same thing.
Billy Ho, as vice president of product solutions at Sybase Inc., is responsible for the strategy and development of the company's core products, including Sybase Enterprise Portal, middleware, and database products worldwide. He earned a BS in Engineering at McGill University and an MS in computer science at CalTech. [email protected]