What _is_ a Services Architecture?

[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:

  • HP's CSF
  • Lutris' ESA

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.