Four Principles The AIP is based on four principles that embody this trade-off between application transparency and infrastructure efficiency.

To enable developers to focus on implementing business logic, the infrastructure should provide high-level, server-based execution, integrity, interaction and gateway services to applications. However, high-level infrastructure services are often wasteful of resources and inefficient unless designed, deployed and maintained by specially skilled infrastructure developers, so it's crucial to regard application infrastructure as a strategic asset with its own life cycle and tools.

Applications require four categories of services through the infrastructure:

Execution services provide an execution environment for application components in a server-based container framework, which is responsible for component activation, termination, failover and load balancing.

Integrity services provide ACIDS (atomicity, consistency, isolation, durability and security) capabilities, enabling the partition of business processes into logical units of work guarded by authentication, access control and encryption.

Interaction services have four types: client to application server, application server to database server, application server to application server, and database server to database server.

Gateway services provide adapters that integrate legacy applications into the AIP. They deal with the protocol conversion and handshake negotiation between the AIP and legacy applications (or between heterogeneous AIPs).

Execution services are based on transaction component models, such as Microsoft's MTS (which has been shipping for 18 months), and OMG's ECB (Enterprise CORBABeans) and Sun's EJB (Enterprise JavaBeans), both due in 1999. All incorporate integrity services.

Interaction services are based on a middleware stack that is an extension of TCP/IP. If IP provides a logical network circuit, then interaction services provide logical application circuits built out of interaction, data flow, format, interface and semantic layers. Many interaction styles will be supported, but BQM will be the foundation for most styles.

Gateway services are the end points of an AIP, connecting external applications and data into the AIP. These external systems may be legacy systems, or business-partner systems based on a different AIP. Although database gateways are traditionally the most popular gateway, application-server gateways will soon dominate, because update access to application-owned data must happen via the application, not behind its back.

You can't yet find all these services in one product. BEA's Iceberg, IBM's Component Broker, Microsoft's DNA architecture and Oracle's NCA (Network Computing Architecture) come closer to a complete AIP than Web-tool vendors ever will be, but users should expect to roll their own AIPs out of various components, including Web tools, until full offerings mature in three to four years.

Attempts to create high-level infrastructure services have been tripped up by the promise to provide simple interfaces for application developers along with efficient performance out of the box. This promise can never be met. The fundamental insight underlying the AIP is that, just as applications must be configured and managed for efficient performance, so too must infrastructure. Thus, there must be interfaces (invisible to application developers) that let infrastructure developers configure and manage infrastructure.

This separation of function lets application developers focus on easy-to-use, location-transparent interfaces and rely on infrastructure developers to map the interfaces efficiently onto the actual infrastructure. Infrastructure developers create components, frameworks, patterns and interfaces for application developers. Just as application developers work with database analysts to define the data schemas an application needs, they will work with infrastructure developers to define distributed interfaces.

The trade-offs infrastructure developers and application developers agree upon should be captured in an "infrastructure impact statement," analogous to an environmental impact statement. The nexus of the trade-offs is the AIP.

It's clear that certain data, processes and resources are enterprisewide and must be designed and managed accordingly. In contrast, most applications are specific to a line of business (LOB). IT must understand that infrastructure delivery is fundamental to application delivery. And the half-life of an infrastructure is much longer than the half-lives of the applications running on it. Enterprisewide infrastructure cannot rely on LOB-oriented application developers.

The AIP assumes that application infrastructure is a strategic asset, independent of the applications that use its services, and with its own life cycle. Unfortunately, tools for each of the infrastructure life-cycle phases are primitive, immature or nonexistent. The most advanced tools are unique to immature, prototype AIPs. The most primitive tools are for mature prototype AIPs, such as Encina and TUXEDO.

Easy-to-use rapid infrastructure development tools are essential to the creation of cost-effective, adaptable infrastructure. Such tools will come not only from infrastructure vendors, but from independent software vendors specializing in development tools, middleware management tools and application-networkability monitoring tools.

As the application center of gravity converges on server-centric distributed component middleware, users must develop AIPs and new roles and responsibilities for the changing paradigm. Some are assembling proto-AIPs by combining emerging distributed-component middleware with transaction servers and business-quality messaging. In the coming years, packaged infrastructure including a well-integrated AIP and supporting tools surely will emerge.

Nick Gall is a program director with the META Group's Open Computing & Server Strategies service. He can be reached at nick.gall@metagroup.com.