What _is_ a Services Architecture?
By David H. Young, Lutris Technologies
[revised 5 Feb 2002]
The Java Services Framework Market
There are only two real commercial players in the
Java Services Framework arena: HP and Lutris. Predictably,
as an HP partner, we are asked to compare Lutris EAS and HP-AS products
and their respective Java Services framework architectures:
To begin with, there are certainly a lot of similarities,
including the cost for equally commercially supported configurations.
And, as good J2EE implementations, we support many of the same features.
We could also take the approach of feature differentation such as EAS
4's native superior wireless capabilities. Or the business approach of
dealing with an independent software vendor as opposed to a hardware vendor.
But, for a prospective application server decision maker, there's a much
more fundamental question to answer because it impacts many decisions
you must make over the lifetime of the product or solution you build on
top of these platforms.
The most critical aspect of a Java Services architecture
addresses the design philiosophy of the underlying "kernel"
and its relationship to the Java services that it hosts. Both HP and Lutris
have implemented their architectures with an underlying kernel. But, it's
the details of the kernel design that will bring out the key philosophical
differences that will have a direct bearing on issues and implications
on software designs that ISVs and VARs must consider..
This article focuses on the core philosphical differences
in the overall goals of defining and designing a Java Services architecture
that makes sense in a world of rapidly evolving standards and frameworks.
Why a Services Architecture?
The need for a Java Services architecture has been
identified by Lutris and others, including the Java Community Process'
(JSP) JSR-111, Java Services Framework. Today, J2EE is the platform of
choice for deploying Internet-style request/response applications, but
there are many other application models that it has yet to address. For
example, many applications require threads or sockets or conduct long
duration transactions that characterize workflow behavior. Architects
designing these type of applications must find clever approaches to get
around the "thou shalt nots" of the J2EE specification. JSR-111
was established to find a way to extend the reach of Java to the application
models that the J2EE framework currently does not support.
What is a Services Architecture?
Perhaps the question posed by this article's title
should be, "what should a services architecture be?"
In good software engineering practices, the question always begins with,
"what are the requirements?" Interestingly enough, the JCP group
JSR-111, Java Services Framework, fails to publish a set of requirements,
which makes the task of requesting and evaluating submissions a bit tricky.
Visit the
JSR-111 page and see for yourself.
In lieu of JSR-111 stated requirements, let's throw
out a non-exhaustive short list:
- It must adopt an operating system set of responsibilities
- APIs to system resources
- Hot-swap of installed services without halting the platform
- It must be highly adaptable in size of footprint
- It must be highly configurable to address the wide variety of user
and per-market requirements
- e.g. Fortune 100 Enterprise IT to mass market product ISV.
- Must not clash with other JSRs
- Must provide a reasonably "soft landing"
for the migration of legacy applications/services
- Must be "framework agnostic."
Let's expand on "framework agnostic."
There are many other application frameworks in the Java space besides
J2EE, such as JINI, Apache's AvalonI and OSGi. Keep in mind that JSR-111
addresses the extension of Java, not J2EE, to support a Java Services
framework. It is JSR-159 that is more focused on extending J2EE to support.
for example, long term transactions. JSR-111 is focused at Java directly.
Having reviewed some of the baseline requirements,
the remainder of this discussion will focus on how HP and Lutris differ
in their implementations.
What HP has built
Lutris' and HP's Java Services platforms both feature
JMX for management, JNDI naming for service registration, XML deployment
descriptors, a resource management kernel, service versioning and so
on. So it's natural to wonder: "what's the difference?"
The HP Core Software Foundation, CSF, supports
a rich set of common services. The CSF kernel integrates the following
capablities and non-plugin services:
- Security
- Logging
- MBeanServer
- Configuration Management
- Deployment Support
- Resource Sharing
- Lifecycle Management
- Security isolation of services
At first glance, this is an impressive list. Lutris have also identified
and implemented the same functionality. Clearly HP have built a rich kernel,
complete with essential services that support the construction of robust
Java applications. So what's the problem?
The problem is that the CSF kernel is too rich. So how can a kernel
be "too rich" if you get all that functionality that makes your
development and deployment tasks easier? Let's discuss a couple of perspectives:
reliability and change.
Reliability
Operating systems must be designed to be "left
standing" when all else fails. They are designed to, for example,
continue running when a printer driver is removed. One way to approach
this level of non-stop performance is to keep a kernel functionally thin,
focused primarily on "resource allocation" when high lever services
require access to hardware components, threads, sockets and so on. Or,
another way of putting it, the less that can go wrong in a kernel, the
better. A review of the CSF kernel, and the aforementioned list of core
services, demonstrates that there is a lot that can go wrong because there
is so much built-in, core functionality.
Accommodating Change
Another issue with providing the convenience of
sweeping built-in functionality is the "locking in" effect of
the supported APIs. Many of the features supported by the CSF kernel are
topics of SCL JSRs. For example, the logging JSR (047) is working on a
standard for a logging API. Other frameworks have their own logging API
as well. When you build an application to use the logging mechanism of
a kernel, you are locked into that logging API until the platform vendor,
HP in this case, rolls out a new version of the entire platform.
This is a critical issue in evaluating any platform
that will influence the design of your application architecture for the
next two years. How will you be able to respond to changing standards,
de facto and otherwise, that are eventually reflected in your customer's
requirements.
What Lutris has built
Now that we've pointed out some key issues with
the CSF design, how does Lutris Services Architecture do it better?
Reliability
The ESA kernel is thin. It was designed for application
architectures that view the world through pluggable, modular services.
Therefore, the ESA kernel supports core features that address the mininum
needs to support a service framework, namely
- resource management,
- lifecycle management,
- legacy hooks and
- security isolation (through advanced classloader mechanism).
The result is a super thin kernel that is less
vulnerable to failover.
Accommodating Change
Lutris was also influenced by the OMG's CORBA,
but chose instead to adopt many of the principles and strategies and not
the ORB itself. The Lutris kernel supports a slimmed down list of features
compared to the HP architecture:
The Influence of OMG on the Lutris Services
Architecture: Modularity
Although HP-AS incorporates a great deal of CORBA
technology, we believe that the Lutris Services Architecture was modeled
more closely to the design philosophy of the OMG and its CORBA architecture.
First of all, the OMG and its members have already spent the last 10 years
doing the hard work, particularly in the area of defining the services
required to support a distributed object system.
For example, OMG defined decorators, as method-level
interceptors that can give developers the ability to see what their application
is doing at the method level. This has huge implications on "micro
billing," performance monitoring and debug tracing. Interceptors
are a concept incorporated into the Lutris ESA architecture.
But at a more profound level, it was the OMG's
sense of modularity that most influenced the ESA Services Architecture
design. If you look at an ORB, it is very thin. It is all about routing
messages from a client to a service. Those services lie outside the ORB
and are replaceable and upgradeable with no impact on the ORB. ESA was
designed with the same philosophy. Application developers who leverage
the services of pluggable Java Services and less on kernel-level services
are in a better positioin to later adopt new services, such as the JSR-115
security API, as they emerge.
What about all that Legacy code?
So far, we haven't touched on what may be the most
impactful differentiation between these two platforms. Namely, what does
it take to migrate your existing application to each platform?
HP-AS and CSF were designed assuming that you would
be willing to reworking your existing application in order to implement
various CSF interfaces to, for instance, participate in the JMX management
view. So, when your code changes, you probably have to reimplement these
interfaces.
In EAS, rather than modifying your legacy code,
you add your legacy code as a Java Service by subclassing the TAP interface
to make a manager for your code. Since this is a wrapper strategy, when
your code changes, you don't have to worry about making ESA-dependence
changes.
The direct implication for your legacy code is
that with Lutris EAS you 1) get to market more quickly 2) incorporate
no EAS-specific interfaces in your code and 3) incur less overhead when
updating your product.
What does it take to build "the operating
system of the Internet?"
Lutris Technologies was bootstrapped by a group
of former SCO folks representing expertise in systems management, device
drivers and kernel threads, as well as distributed computing, having designed
and built SCO's Distributed Computing Environment (DCE) technology. A
good deal of that experience has been folded into the design of the service
architecture's kernel.
Many are now referring to application servers as
assuming the role of "the operating system of the Internet."
We believe that the Lutris ESA services architecture is much closer to
that goal compared to any other industry application server player, thanks
in large part to the operating system style nature of the ESA kernel.
We also believe that the ESA services architecture
excels beyond the CSF architecture to deliver many values:
- Easier and more maintainable migration of legacy applications
- More standards-proof (i.e., standards accommodating) architecture
- More adaptable architecture to other non-J2EE frameworks.
- A more reliable framework upon which to build and deploy Java applications.
The kernel and its native functionality will greatly
influence what you can and cannot do with a Java Services platform today
and over the course of the next two years. These issues address upgradeability,
maintainability and standards compliance. And clearly, whether you are
talking about e-commerce, b2b, Web services or embedded applications,
application servers are becoming an inherent component of long term business
strategies for any developer from IT organizations to ISVs and VARs. We
hope that this article as highlighted a key perpspective and related considerations
when evaluating the new world of Java Services architectures.
|