Lutris EAS versus HP-AS:
A Look at Competing Java Services Frameworks

Why Java Services?

Today, J2EE™ is the platform of choice for deploying shopping cart-style request/response applications, but there are many other application models that it has yet to address. For example, many applications require access to threads or sockets or need to conduct long duration transactions that characterize workflow behavior. Architects designing these types of applications must find clever approaches involving JMX or side-by-side servers connected via RMI to get around the limitations of the J2EE specification. Further, existing applications must be re-architected to run on Java application servers. Finally, existing application servers are monolithic, all-or-nothing implementations that cannot be configured to meet the particular needs of ISVs and other developers.

These and other limitations in current J2EE application server architectures have led both Lutris and HP to independently create application servers using services-based architectures for deploying Java Services. These architectures are similar to operating systems in that they are composed of a kernel and modular services that run on top of the kernel. Services implement J2EE, provide non-J2EE features such as wireless connectivity, scheduling, and polling, and provide custom features created by ISVs and end-users.

Lutris, HP, and others have banded together to begin a standardization process, which has resulted in the formation of Java Community Process' (JCP) JSR-111. JSR-111 has been established to find a way to extend the reach of Java to the application models that the J2EE framework and its current implementations do not support.

Lutris EAS vs. HP-AS at a Glance

Lutris EAS and HP-AS share many similarities including

  • A kernel supporting a variety of packaged services
  • Full J2EE support
  • An operating system-like set of interfaces to system resources
  • Hot-deploy and hot-swap of services/applications
  • Service versioning
  • JMX-based management
  • JNDI naming for service registration
  • XML deployment descriptors
  • Equivalent cost for fully configured systems

There are also important differences

  • EAS has comprehensive wireless device support (in addition to VoiceXML)
  • EAS supports JSP as well as innovative presentation layer technologies in XMLC and Barracuda (a MVC2 framework)
  • EAS offers easy legacy code integration

The topic of legacy (non-J2EE, non-EJB) code integration bears further explanation. HP-AS requires the refactoring of existing applications to adhere to HP-AS kernel interfaces. In contrast, EAS allows for the quick import of legacy code by writing a simple wrapper. This approach offers reduced implementation time and easier application upgrades in the future.

The Key Difference: Kernel Architectures

The most important distinction between Lutris EAS and HP-AS lies in their kernel architectures. Understanding kernel architectures is critical as they impact the fundamental capabilities of the application server as well as the entire lifecycle of hosted products built on top of the platform.

J2EE is an evolutionary, not revolutionary technology. Many of the design principles underlying J2EE were derived from knowledge obtained from years of implementing and deploying CORBA technology.

One of the key lessons learned from CORBA and now being applied to Java application servers is the need for a small, robust kernel. The CORBA ORB is a thin, simple technology designed solely to route messages from a client to a service. All other functionality is implemented as a set of services outside the ORB. This architecture has proven to have two key benefits: reliability and the ability to accommodate change. A further benefit is footprint control.

Reliability

A key strategy to achieve high levels of reliability is to keep kernel functionality thin. A kernel should be focused primarily on "resource allocation" where higher-level services require access to hardware components, threads, sockets and so on. Simply put, the less that can go wrong in a kernel, the better.

Accommodating Change

A critical factor in technology decision-making is the ability to accommodate changing standards, de facto and otherwise, many of which may be reflected in customer requirements. A thin kernel is best at accomplishing this goal.

If functionality is embedded in the kernel then feature updates require kernel updates. Functionality (logging, security, management, etc.) deployed as a service avoids this problem. Functional upgrades can be accomplished without replacing the kernel or even taking the server off-line.

Footprint Configuration

A thin kernel combined with plug-and-play services can also provide a small footprint. While many enterprise applications may need all the features provided by an application server, other applications need only a subset. With Java applications appearing in an increasingly broad range of environments - high end computer clusters to handheld devices - the need for footprint control becomes a critical decision factor.

HP-AS Kernel

HP-AS's kernel, the Core Software Foundation (CSF), goes against the philosophy of a small, highly reliable, and accommodating kernel by supporting a rich set of common services. The CSF kernel integrates the following capabilities:

  • Security
  • Logging
  • MBeanServer
  • Configuration Management
  • Deployment Support
  • Resource Sharing
  • Lifecycle Management
  • Security isolation of services

Clearly, this much functionality in a kernel poses problems:

  • It greatly increases the likelihood of kernel lockup and failure
  • It mandates a large footprint, making HP-AS unsuitable for many applications
  • It limits the ability of a developer to use custom features that may conflict with kernel features (logging, security, management, etc.)

Equally concerning is the fact that many CSF features are on-going topics of standards bodies and destined for change. For example, JSR-047 is working on a standard for a logging API. JSR-115 is examining a security API. Deploying a product that adheres to these new standards requires replacing the CSF kernel.

Lutris EAS Kernel

Unlike HP-AS, Lutris EAS was designed with the lessons of the past in mind. EAS contains a thin, highly reliable kernel. It was designed for application architectures that are composed of plug-and-play modular services. The EAS kernel supports core features that address the minimum needs to support a service framework:

  • Resource management
  • Lifecycle management
  • Hooks for legacy (non-J2EE) code integration
  • Security isolation (through an advanced class loader mechanism)

Lutris EAS vs HP-AS

Whether used for e-commerce, B2B, Web services, or embedded applications, application servers are becoming critical components of software and business strategies. An application server's kernel will greatly influence what can and cannot be accomplished with an application server implementing a Java Services platform today and in the future.

An examination of core architectural differences reveals that Lutris EAS provides a superior Java Services platform over HP-AS for the following reasons:

  • Higher reliability
  • Greater ability to accommodate change
  • Easier migration of legacy applications
  • Highly configurable footprint

Lutris EAS also offers superior features in the areas of wireless device support and presentation layer frameworks.