Lutris EAS versus HP-AS:
A Look at Competing Java Services Frameworks
By Yancy Lind, Lutris Technologies
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.
|