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, and functional 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? [08/06/04] We can crystallise WADI's goals into two stages:

• To be able to walk into your web farm and 'ctl-c' any webcontainer node without losing any HttpSessions (i.e. customers).
• To be able to walk into the same web farm and 'kill -9' any webcontainer node without losing any HttpSessions (i.e. customers).

The first of these two cases is important because it allows easy maintenance of existing h/w or s/w. This may seem a trivial requirement, but many existing solutions are time-consuming and/or error-prone (involving draining sessions off target nodes over long periods etc.), to the point that many sites simply accept that maintenance will impact quality of service.

The second of these two cases deals with a more exceptional case - the catastrophic failure of a webcontainer node. As online competition for business increases, systems are being required to provide higher and higher levels of availibility. This can be critical in particular areas. The ability to preserve web-tier state beyond the failure of its node is correspondingly an increasing requirement. What resolutions to these goals does WADI propose? [22/11/05] WADI addresses its problem space through dividing and conquering. The goals above have been broken down into the following feature set.

• Perform the full set of duties associated with a standard, non-distributable session manager.
• A reliable solution to application and container space HttpSession concurrency issues - so that the container may safely serialise a session if/when the need arises.
• The ability to migrate sessions to/from a pluggable shared long-term storage mechanism allows WADI to preserve JVM resources by evicting infrequently used sessions during a node's lifetime and to ensure their availibility to its peers both during its lifetime and after shutdown.
• Further pluggable strategies allow the user to control e.g. compression algorithms used in such migration. These could be extended to perform other types of transformation - e.g. encryption, for sites where security is a priority.
• WADI is able to relocate sessions by migration directly between peer nodes in the cluster. If a request arrives at a node that does not have the corresponding session, it can locate it and arrange its immigration underneath the incoming request.
• Pluggable load-balancer integrations allow WADI to leverage specific mechanisms to control/predict on which node user requests will fall.
• WADI is also able to relocate requests between peers. It uses redirection (load-balancer integration permitting) or proxying. If a request arrives at a node that does not have the corresponding session, it can locate it and send the request on to the correct node..
• Bulletproof HttpSessions - through state replication - This is the second phase of WADI development, currently under implemention. We are drawing on the experience of having already twice implemented such mechanisms for Jetty. More details to follow...
• All of the above in a manner completely compatible with the current J2EE Servlet Specification (2.4), thus preserving the users investment in the J2EE platform and avoiding vendor lockin.

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

• Tomcat 5.0
• Tomcat 5.5
• Jetty 5
• Jetty 6
• JBoss 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 is being paid to the Geronimo integration, for reasons given below. How is this integration achieved? [22/11/05] WADI comprises three main components, A Filter, a portable HttpSession implementation and an HttpSession Manager. The Filter is portable. The Manager plugs into the webcontainer, replacing theirits own native HttpSession Manager and HttpSession implementation. WADI HttpSessions are portable between any WADI-enabled webcontainer, so these may be freely mixed within a cluster whilst still aloowing the migration of sessions between themselves. 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, migration and replication. Auxiliary pluggable code performs all the other tasks involved in HttpSession migration etc... Why would I even want to store important information in the Web tier? [19/04/04] Strictly speaking, data associated with presentation lives in the web tier whilst data associated with the business should be stored in the EJB tier.

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? [22/11/05] 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 have unclear semantics under concurrent load, or are lacking important features. I haven't found a single implementation which addresses all the issues which WADI chooses to in one package - otherwise I would have contributed to that project.

Here is a brief summary of the current state of play:

Implementation	Session Persistance	Shared Store	Session Eviction	Session Replication	Replication Whole/Delta	Replication Partitioned	Replication Technology	Author
Jetty5,6/TC5.0,5.5: WADI	Y	Y	Y	NYI - Y	NYI - both	NYI - auto - pluggable	ActiveCluster/Pluggable	Jules Gosnell & The WADI Team
Jetty4/5: Jules' DSM	Y	Y	N	Y	both	manual	JGroups/Pluggable	Jules Gosnell
TC4/JBoss: Thomas' DSM	N	N	N	Y	whole	manual	JBossHA/JGroups	Thomas Peuss
TC5: PersistentManager	Y	?	Y	N	N	N	N/A	Kief Morris
TC5: DeltaManager	N	N	N	delta	N?	?	JGroups?	Filip Hanik, Craig McClanahan, Jean-Francois Arcand
TC5: SimpleTcpReplicationManager	N	N	N	Y	delta	N?	JGroups	Filip Hanik, Bela Ban
TC5: - New JCluster-based	?	?	?	?	?	NYI - auto - clock	JCluster/JGroups	Rob Block

Please notify us of mistakes or other features/implementations that you would like to see in this table. So tell me about WADI and mod_jk [22/11/05] Mod_jk poses particular problems for session maintenance beyond the lifetime of a single vm. Mod_jk implements session affinity via a contract with the webcontainer. Each node has a unique id. This id is appended to any session created on this node i.e. if a session '1234' is created on node 'red', the cookie returned to the browser will have a value of '1234.red'. Mod_jk's workers.properties is used to map the 'red' to a particular host:port combination each time it is seen. This is a very efficient and effective way of achieving affinity, until 'red' disappears. Then the browser is left holding a cookie with no corresponding node. Rather than implementing a contract involving some sort of predictability, e.g. failing over to the next node in the list. Mod_jk will simply treat the session as if it had no affinity and select a 'random' live node and drop the request on it. Subsequent requests will be routed to different nodes, whilst the session cookie still ends in '.red'.

How does WADI maintain a session's availability in these circumstances ? If 'red' is shutdown cleanly it will migrate its sessions to its surviving peers. The next request will cause the node upon which it lands to acquire the relevant session from a peer, if it does not already own it, and then process the request in the normal manner. This node will then rewrite the routing info at the end of the session id with its own unique id, sticking all subsequent requests to itself. Thus affinity immediately 'fails-over' onto another node, maintaining session availibility at minimum price paid only in the exceptional case. Why AspectJ? - I prefer AspectXYZ [22/11/05] 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.

Update: We have now removed our Aspectj dependency and collapsed the aspected code back into pure Java. This was done for a number of reasons.

• The number of cross-cutting concerns found was not as great as was expected at the outset of the project.
• AspectJ integration with Eclipse, whilst useful, was often flaky
• AspectJ integration with Maven1 was inadequate and we had to roll our own
• AspectJ integration with Maven2, at the point of our migration, did not exist
• The number of developers on the project is growing and the use of AspectJ raises the skills requirement
• I have heard FUD to the effect of 'Aspects are slow' being taken seriously by architects in big companies.

WADI started as a 'proof of concept' project, but is moving rapidly towards production readiness. We will be releasing very shortly.

Functionality in Tomcat and Jetty is now equivalent, so all further WADI development is now being done on a webcontainer-independant platform. Where is it going? [22/11/05] Currently, we are concentrating on hardening the distributed hash map, implementing in-vm state replication and openEJB and Geronimo integrations. How does WADI relate to Apache Geronimo? [22/11/05] 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.

WADI has acccepted the Geronimo community's invitation to become an official geronimo subproject and the relevant pieces of the project will soon be moving over to the ASF. This site will continue as the optional WADI code that integrates with GPL and LGPL licensed 3rd party components may not be distributed from ASF servers. How does WADI relate to OpenEJB? [22/11/05]

WADI provides a number of clustering related services to the web-tier which have direct equivalents in the EJB tier (The management of clustered SFSBs).

WADI and OpenEJB communities are in discussion as to how WADI technology may be reused beneath OpenEJB in order to provide HA EJBs.

We expect the outcome to be a genericisation of a number of WADI components, a number of intelligent client-side EJB client proxies and some pluggable OpenEJB internals. Work is underway on a complete OpenEJB integration. This is interesting stuff - how do I get involved? [22/11/05] Work you way through the Getting Started documentation and the Maven2 and Eclipse Developers sections on the WIKI. Get onto the mailing lists and #WADI, report problems here or on Codehaus Jira.Bug fixes are always welcome :-). These are the ways to have a direct impact on the quality and direction of the project

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 format is WEB-INF/wadi-web.xml in? [22/11/05]

We looked at various mechanisms including those already in use by Jetty and Tomcat and ultimately chose Spring for WADI's configuration mechanism.

• It will already be familiar to part of our community and has a growing community of its own
• It extends as quickly as you can write classes - no admin overhead (c.f. TC and Digester)
• Small and lightweight - it took 6 lines of code to insert

The format is basically a direct mapping from Java to XML with a little syntactic sugar. Any public method on the WADI session manager or its subcomponents may be called directly from XML just before it is started. This results in anextremely flexible configuration mechanism, which is exactly what WADI needs at this stage. Please peruse the online WADI JavaDoc for a complete listing of available methods/types. What is WADI using for Logging infrastructure? [22/11/05] WADI uses commons-logging, and this is backed onto org.apache.commons.logging.impl.SimpleLog logging. We chose this over Jdk1.4 logging, because this seems to swallow all its input afterstarting Runtimme.ShutdownHook(). Logging what happens during shutdown is important to WADI and SimpleLog seems to do this with no problems.

We didn't use the log4j backend, because we wanted to preserve a TRACE level, which it does not support out-of-the-box.

When running in JBoss we provide a custom commons-logging backend which maps WADI's TRACE level directly to JBoss' TRACE level (by default WADI DEBUG and TRACE will be collapsed into JBoss DEBUG). 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