Such state is stored in an HttpSession. This is the per-client server-side repository of conversational state and the only resource to be distributed in a <distributable/> Web Application.

The management of distributable HttpSessions is currently loosely specified. Consequently, it unfortunately tends to be very much an afterthought in existing Open Source implementations.

WADI's goal is to identify and explain the shortcomings present in current offerings and to provide an implementation which draws upon this crystallisation of the current state of play to provide a highly flexible toolkit capable of delivering a number of different solutions in a complex problem space.

WADI is able to achieve this, because the project is focussed, not on the delivery of a complete, working web-container, but simply upon the problem of distributed state management.

Ultimately, WADI will live or die upon its ability to justify its architecture in terms of the constraints placed upon it by the Servlet and Java language specifications and to deliver a production-ready implementation of this in a format that is sufficiently performant, flexible, functional and available as to be worth the investment, over and above just taking a vanilla web-container out of the box, that the user will have to make to put it to use.

You are the Jury. Your verdict is final! What are WADI's goals? [20/04/04] WADI is a collection of pluggable components which, ultimately, aim to provide a complete solution to all the common problems encountered in managing user state in the J2EE web tier. Particular issues addressed are/will be:

• A reliable solution to application and container space HttpSession concurrency issues
• Ensuring that HttpRequest and HttpSession meet somewhere in the cluster for correct processing
• Persistent HttpSessions - saved to store whilst web container is down
• Reversible eviction of aging HttpSessions to long term storage
• HttpSession migration directly between cluster nodes
• Bulletproof HttpSessions - through state replication
• A simple and reliable semantic which encompasses all the above

• J2SE 1.4.x
• J2EE 1.4 (Servlet 2.4)

In as far as WADI is integrated with the two web containers mentioned above, it may be considered integrated with application servers which embed them (notably e.g. Geronimo, Jonas and JBoss). Particular attention will be paid to the Geronimo integration, for reasons given below. How is this integration achieved? [19/04/04] WADI comprises three main components, A Filter, a portable HttpSession implementation and an HttpSession Manager. The Filter is portable. The Manager has implementations that plug into Jetty and Tomcat, replacing their existing HttpSession Managers and HttpSession implementations with its own. HttpSessions will be able to be exchanged between instances of any WADI-enabled web-container. The Filter end of WADI keeps track of which HttpRequests are visiting which HttpSessions, enabling WADI to know when it may interact with an HttpSession (e.g. for migration) without involving itself in concurrency issues with application-space threads. The Filter is also able to relocate requests, by various pluggable mechanisms, from one node to another, before the HttpRequest enters application code. The HttpSession Manager is responsible for HttpSession creation, destruction, pooling, location and migration. Auxiliary code performs all the other tasks involved in HttpSession migration etc... What functionality does WADI bring to the table? [19/04/04] Managing distributed state is a complex affair. Rather than mandate a particular direction, WADI attempts to abstract the basic patterns of use into Policy interfaces. A number of different such Policy plugins, governing e.g. eviction, migration, Id generation etc, ship with WADI, and the user is encouraged to write their own implementations and submit them to the project to fill any functional gaps.

Currently WADI can:

In a non-distributed environment:

• Perform the full set of duties of a standard session manager.

In a distributed environment:

• Persist sessions via a pluggable MigrationPolicy between web container start/stop cycles. All the correct notifications will be triggered upon HttpSessionActivationListeners.
• Select, according to a user supplied EvictionPolicy, sessions for Passivation and using the above MigrationPolicy, move them into shared storage, from which they may be re-activated, in a race-safe environment, by any web-container instance that shares the store. Once again, the correct notifications will be made to session Listeners.
• Reference based semantics (See WADI Paper - LINK TODO) may be completely maintained in a distributed environment. We believe this is the only Open Source Session Manager to be able to do this reliably. i.e., any legacy webapp, provided that it stores client state exclusively in the corresponding http session, may be deployed in distributed mode with no further code changes.

In the future we expect WADI to be able to:

• draw on existing functionality to provide performant and flexible high availibility and scalability of it's managed state, via a variety of pluggable backends.
• because of it's flexibility, WADI should provide a platform with which a number of mission critical third party product integrations (e.g. http load-balancers) will be able to be tightly integrated, resolving many of the existing problems in providing clustered web-tier state management.

State management in the EJB tier is more tightly specified, simpler and generally better implemented than the equivalent functionality in the web-tier, so the tendancy has been to push all important data in this direction, when high availibility and fail-over are a major concern.

Unfortunately, even designs such as the above cannot get away from the fact that the web-client requires a single handle on the conversational state held in some J2EE tier and that the only such handle provided by the J2EE specifications is that which binds a url parameter/session cookie to a web session. So whilst you can store all data in the EJB tier, unless you want to start learning proprietary tricks to associate an EJB handle with a web client, you have no option but to put your EJB into the relevant web session and pray that it survives whatever gets thrown at it.

This is obviously an unsatisfactory state of affairs, and WADI's aim is to restore confidence in the reliability of web sessions in general and to clearly demonstrate, that with a little thought, in a number of cases, a distributed web session may be implemented more efficiently and reliably than the corresponding stateful EJB session. Why should I need it? [19/04/04] If you have a requirement to store presentation state in your J2EE web tier and this state is of value and you are not keen on shoehorning it into the business tier in order to achieve its persistance and distribution, then you should be looking at WADI. How does it differentiate itself from the competition? [19/04/04] The competition is HttpSession implementations in the open source world. At the time of writing, and to the best of my knowledge, these begin to address the same issues as WADI, in terms of e.g. paging HttpSessions to/from disc, or state replication, but are marked as 'experimental' or have unclear semantics, or are non-performant.I haven't found a single implementation which addresses all the issues which WADI chooses to - otherwise I would have contributed to that project. Why AspectJ? - I prefer AspectXYZ [19/04/04] The complex and flexible requirements of middleware particularly lend themselves to AOP. The previous incarnation of WADI, the Jetty HttpSession replication implementation, used a system of deploytime aggregated custom 'interceptors' to compose its HttpSession container on the fly. The move to AspectJ is intended to preserve that investment of time in the decomposition of the HttpSession container into its various aspects whilst paying minimum price at runtime for what is now a statically-typed, compile time abstraction. At the time of the project's inception a number of AOP technologies were investigated. AspectJ was chosen as being the most runtime efficient and mature of this selection. Note that the investment is in figuring out how to break a system down into aspects, rather than implementing it using any particular proprietary aspect technology. If a more suitable AOP implementation comes along we foresee no problem in porting WADI to it. What is WADI's current status? [19/04/04] Changing daily :-)

WADI started as a 'proof of concept' project, but is moving rapidly towards production readiness. We will be looking for beta-testers soon.

Initial WADI development was done with Jetty and Tomcat was added recently, so the flexibility of the Tomcat integration still lags a little, but this is on our todo list. Where is it going? [19/04/04] Currently we are concentrating on resolving all the issues surrounding concurrency, migration and session/request relocation. Once these have been resolved, the next large piece of functionality will be state replication. How does WADI relate to Apache Geronimo? [19/04/04] WADI started life as a design for a Jetty/Geronimo component. We soon realized that, because of WADI's abstraction of all significant functionality into pluggable strategies with well-defined APIs, there would ultimately be nothing tieing it exclusively to Jetty or Geronimo. At this point it became WADI - a standalone project, now able to be used by a wider audience, particularly stand-alone Tomcat users.

Ultimately, WADI's goals still involve a seamless integration with Geronimo. This will be achieved by backing relevant WADI plugins with Geronimo services. The authors of this project are involved in the design of Geronimo clustering functionality and substantial part of WADI is simply the reflection of concerns encountered in the Web tier of this design. This is interesting stuff - how do I get involved? [19/04/04] Check out WADI from cvs or download a snapshot (when we get them going) and play with it in Tomcat or Jetty. Report problems on the mailing list or codehaus Jira and join in the discussion on the mailing list and irc (when we have one).Bug fixes are always welcome :-). These are the ways to have a direct impact on the quality and direction of the project. There will also be a WADI BOF at JavaOne this year, for those of you who are attending - more details to follow.

If your interest is more general, but still within the J2EE space, you might consider getting involved with the Apache Geronimo Project. There is plenty of scope here to scratch any itch that you might have. What's going on with the build system - Ant or Maven? [19/04/04] WADI started life as an Ant project. We are now moving over to Maven. Unfortunately, the way that the maven-aspectj-plugin does things is rather dissimilar to the way we were doing things in Ant. We hope to resolve this issue soon.

If anyone has successfully run AJDoc with AspectJ-1.2 from Ant, please drop us a mail with an example (jules@coredevelopers.net). How do I get started? [19/04/04] For the moment we will do this using Ant:

You'll need the following env vars set up in your shell (apologies to MS users - I'm sure you'll work it out).

• JAVA_HOME
• ASPECTJ_HOME
• JETTY_HOME
• TOMCAT_HOME

build.sh tomcat.0

build.sh jetty.0

It is intended that, ultimately, WADI will be packaged into a single wadi.jar. For Jetty I would expect this to be put in WEB-INF/lib whereas for Tomcat, somewhere like $TOMCAT_HOME/server/common. What is WADI using for Logging infrastructure? [19/04/04] WADI uses commons-logging, and in the current development configuration this is implemented via J2SE1.4 native logging. However, just to confuse matters, because I find the double line output format of this system unreadable, I have plugged in an Open Source logging formatter (gt2-main.jar) which has nicer output.

I didn't just use log4j, because I wanted to preserve a TRACE level, which it does not support out-of-the-box. How is WADI put together? [19/04/04] WADI installs as an HttpSession Manager for a particular Context/WebApp. This Manager then installs (programmatically) a Filter at the front of the webapp's Filter stack.

The Manager may be considered to be the webapp's HttpSession factory. It is in control of HttpSession creation and destruction and provides its own HttpSession implementation. Both Tomcat and Jetty (fortunately) have well defined internal Manager and HttpSession APIs. org.codehaus.wadi.shared provides core classes which implement standard and WADI functionality as well as interfaces defining pluggable strategies and policies. org.codehaus.wadi.tomcat and org.codehaus.wadi.jetty extend these classes with the necessary glue to fit them into the targer webcontainer. Finally, org.codehaus.wadi.plugins provides concrete implementations of these pluggable APIs, e.g. HttpSession and HttpRequest relocation mechanisms.

WADI does not set out to tell you how to distribute your webapp. We believe that there are many different ways that you might wish to do this. WADI simply provides a framework and (eventually) every conceivable ability that you might require. Useful default behaviour is supplied, but it is expected that this will be customised with the use of the supplied plugins. How do you deal with concurrency in a webapp's HttpSessions? [19/04/04] The servlet spec specifically mandates that implementations should allow multiple concurrent request threads to pass through an HttpSession. It omits describing any synchronisation protocol around the HttpSession that the container and application might use in order to coordinate their activities. This has presented a problem for a number of Manager implementations that I have looked at. Many chose simply to ignore the problem.

This problem becomes far more pressing as the number of activities that the Manager may wish to perform on an active HttpSession increases in frequency or complexity. WADI, for instance, needs to be able to guarantee that no application threads are altering an HttpSession's content whilst the Manager is trying to serialise the HttpSession as part of a relocation (migration) to long term store or another node.

Synchronising around the HttpSession would not actually solve our problem. If we wish to relocate an HttpSession to another node, we must prevent, once we have made this decision any further requests for this session on this node from entering application code here during the relocation.

WADI's Filter looks at each incoming request. If it references a local HttpSession it tries to acquire a non-exclusive lock in that HttpSession (non-exclusive so that many concurrent request threads may run). When the Manager wishes to e.g. relocate the HttpSession it will try to acquire an exclusive lock in the HttpSession. In this way application and container-space threads are properly coordinated. Tell me what you mean by HttpSession and HttpRequest relocation [19/04/04] Introducing state into a cluster thoroughly complicates matters. It becomes important that client request and server-side state meet each other somewhere in the cluster for correct processing. Location becomes all important. WADI has the ability to relocate both HttpSessions, by migrating them from node to node (or to long term store) and to relocate HttpRequests by redirection and proxying. Various pluggable strategies and policies allow the user to define how and when this will be done. Where can I buy support for WADI? [19/04/04] WADI is developed and maintained by partners in Core Developers Network. If you wish to discuss support, consulting or enhancements around WADI, please