An Interview with Appistry's Kevin Haar from JavaOne 2007

---

Application state is usually meant to describe persistent or transient data related to a user's interaction with the applications: Data in a user's HTTP session, or business data accessed and modified by a user, would be part of such application state. In this interview with Artima, Appistry's Kevin Haar defines this type of application state as "explicit state," to distinguish it from what he calls "implicit" state: Data associated, not necessarily with user interaction or business information, but data generated by the application, and in the course of operating the application.

According to Haar, such state data is of little interest to users, or even to developers, but can be invaluable to a runtime infrastructure. An enterprise infrastructure can, for instance, replicate implicit state to multiple cluster nodes to provide for continuous availability in case of hardware failure:

There are, really, two distinct notions of state: There is the explicit state that a developer might access through a distributed cache. But there is also the implicit state that is really a byproduct of the way the application is structured. It's that implicit state that the [enterprise] fabric uses to provide software-based fault-tolerance. Because that state information is propagated out to multiple machines in the fabric, the fabric will continue the work someplace else [in case of node failure].

We want to make it so a developer doesn't have to think about scalability and reliability at all, but rather, is able to inherit both of those characteristics from the fabric.

Implicit state still has to be available to the enterprise fabric in order to provide scalability and reliability to the application, according to Haar. Hooks for such information can be provided either by an enterprise framework, such as Spring, or by developers through the use of code-level metadata, such as via annotations:

With our Spring application support, we allow developers to develop applications as if the [applications] were to be deployed on a single machine, and then deploy them into a fabric which could consist of tens or hundreds of machines, and transparently scale their applications across that fabric. We are able to do that because Spring externalizes a lot of the metadata and configuration, and our fabric is able to infer what it needs to provide that scale and reliability... For .NET applications, we allow developers to use annotations and source-level metadata to accomplish the same things.

Kevin Haar, CEO of Appistry, talks talks about explicit and implicit application states. (86 minutes 9 seconds)

What do you think of Haar's distinction between these two states, and about the notion of an enterprise fabric providing automatic scalability and fault-tolerance with the use of implicit state?

Post your opinion in the discussion forum.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the authors

Bill Venners is president of Artima, Inc. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.