The impact of SOA on the enterprise software infrastructure market has been substantial. A variety of architectural components designed to orchestrate the creation, deployment and management of services have been brought to market in the past several years. However, application servers continue to play an important role as endpoints in a SOA environment. After all, the code still has to run somewhere! SOA has increased the importance of domain-specific containers such as web services servers, brokers and gateways. Frequently these domain-specific containers are implemented on top of the Java EE application servers.
Another significant impact is the increased importance of event driven architecture (EDA). With increasing frequency, code is executed as a result of an event trigger rather than as a result of a user interacting with a web browser.
What this all means for the application server is that there is an increasing demand on the server to support a larger number of container types and execution models. As the legacy Java EE application servers have continued to heap these containers onto their stack the footprint of the products has grown dramatically and the products have become increasingly unwieldy.
Data Center Consolidation
Data center consolidation has also had a substantial impact on the run-time aspects of the application server. The proliferation of data, code and hardware has increased data center utilization and cost to the point where CIOs have had to deal with the problem. One common approach to addressing this has been data center consolidation. Data center consolidation is intended to reduce cost through a variety of approaches but in the past few years the principal focus has been on real estate (measured in lab space required to host the hardware), and power consumption. We will examine each of these areas in more detail below.
Power consumption is a function of both the electricity that each server consumes to run it and the air conditioning needed to keep the servers cool. The power bill to run a typical server can exceed the cost of the hardware in about two years.
In order to address this problem CIOs are looking for technology that allows them to do more processing with less hardware. Server utilization has been studied and discussed extensively. Studies showing server utilization of less than 50% are common. A fully utilized server doesn’t use any more energy or take up any more space than a 50% utilized server. So, increasing utilization is generally recognized as a valid approach to the problem. Increasingly, the approach to increased server utilization has been through a combination of virtualization and elasticity.
Virtualization and Elasticity
There are multiple variations and approaches to virtualization but hardware virtualization is the most common. Hardware virtualization involves slicing up a physical server into multiple virtual spaces. Each space provides a complete compute environment. When fully optimized, hardware virtualization can drive additional requirements onto the application server.
In order to make efficient use of resources and keep down hardware footprint and power consumption, an application server design that is optimized for virtualized environments will be lightweight, fast and flexible.
A data center can be “right sized”, or built with minimal extra capacity if the application infrastructure can expand across additional compute resources elastically. Increasingly, administration tools must be able to interact with the virtualization layer to coordinate optimal resource utilization and expand to additional compute resources when needed. The tools must allow the administrator to define service level agreements, monitor resource utilization, provision additional servers and services to meet compute requirements and start and stop services on demand. The tools must also scale to large numbers of servers.
To get the workload to the right server, the system also requires a workload controller (a load balancing router that is payload-aware) and a service locator that knows how to find a server that has been provisioned to run the payload.
The overall management domain architecture must be flexible and highly scalable. It must accommodate mixed topologies spanning physical hardware, virtualized environments and elastic environments.
The Squeeze Effect
We have discussed how several industry trends are driving change in application server designs. On the one hand, the maturity of Java EE and SOA are both driving increased footprint in the Java EE app servers. On the other hand, developers are looking for better productivity with lightweight containers. Data center consolidation is also driving requirements for lightweight, fast and flexible deployment architectures. The convergence of these diametrically opposed requirements creates a challenge for the traditional J2EE application servers.
The Java EE 6 profiles are intended to address this by providing Java EE certification and branding at multiple tiers. However, the traditional application servers were not architected for modularity. They are not designed to provision, start and stop services on demand, and their designs are not optimized for virtual and elastic environments. They are anything but lightweight. The challenges of evolving these architectures to meet the new requirements while maintaining backwards compatibility are substantial. This is creating an opportunity for new entrants in the market. We will examine some of the key characteristics of these new entrants in the following sections.
The New Breed of Application Server
A new breed of application server is emerging. This new application server has a small, in-memory footprint. It starts fast and runs fast. It has a highly modular architecture and it can host a variety of services and domain-specific containers. It can respond to directives from a “grid controller” and it can provision, deploy, start, stop and tear down services on the fly. It runs efficiently in an elastic topology that may span heterogeneous physical hardware and virtualized hardware. We’ll take a look at a few of the important characteristics that define the breed.
The next generation application server has the ability to host multiple, domain-specific services or container types on a common backplane or microkernel. The application server can be configured to execute different services. The microkernel manages the lifecycle of services and the interdependencies between the services. Configuration may be either static (require reboot) or dynamic. The microkernel usually has a small in-memory footprint.
OSGi is a framework that defines an application life cycle model, a component model, a service registry and an execution environment for services (modules.) Applications are deployed against the OSGI backplane in the form of bundles. Bundles can be installed, started, stopped, updated and uninstalled without restarting the backplane. Services can detect the addition of new services and adapt appropriately.
OSGI is widely deployed in embedded systems running in cell phones, automobiles and PDAs. It is also beginning to emerge in grid computing and application servers. The Eclipse IDE embeds OSGI.
A number of the micro-kernel projects in development today incorporate OSGI. Some architectures use OSGI internally while others expose OSGI to the end-user application.
OSGI is backed by an organization called the OSGI Alliance. A number of the major vendors participate in the OSGI Alliance. Although enterprise software adoption of OSGI is still in the early stage, it is conceivable that OSGI will one day obtain the stature of Java EE as a component model for low-level Java infrastructure.
Distributed Data Cache
In order for distributed systems to execute efficiently, the data that each service needs to operate on needs to be readily accessible to that service. The data needs to either reside locally or be cached locally. Distributed data caches are designed to address this problem. Most of the application servers today already work with distributed data caches but over time we will see application servers use the cache more extensively for internal data stores such as replicated session state.
Event Driven Architecture
The next generation container doesn’t necessarily expect to be invoked by a browser. More frequently code execution will be triggered by a process generated event. Events frequently arrive in the form of a message. The architecture is optimized towards reacting to a variety of event stimuli.
Components of enterprise software solutions are frequently loosely coupled and communication between components is implemented by a messaging system or an enterprise service bus (ESB). The next generation platform will support a variety of messaging formats and standards including JMS. Messaging will also continue to be used heavily in the practice of software integration.
Integration with pre-existing systems, data formats, message formats and 3rd-party software, will continue to be important. The next generation application server will support both standards-based and pattern-based integration.
Whereas many enterprise applications currently run on fixed clusters of servers, in the future, applications will frequently run across a dynamic, loosely-coupled and elastic configuration of servers. This configuration is sometimes referred to as a service fabric. This concept applies equally to service oriented architectures and next generation compute environments. The fabric is usually heterogeneous. Some or all of the servers included are frequently virtualized. The fabric is managed by a controller that has the ability to discover the state of the servers and can also interact with the virtualization or grid layer to coordinate resource availability. The system includes a router, or software load balancer that can route work to servers based on payload and resource availability. The fabric has the ability to expand by adding servers including servers that run in a compute cloud environment.
The new application servers are architected to run efficiently in a fabric environment. They can be discovered, and dynamically provisioned. They can receive payloads and execute chunks of processing independently and asynchronously. The output of a service may trigger a subsequent service request.
There is a broad spectrum between a container that runs efficiently in a virtualized environment and the fully developed service fabric architecture. It is likely that there will be implementations at various points on that spectrum.