One of the fundamental rules of making scalable architectures is to introduce as little stateful behavior as possible. That isn't really a very profound statement- any architect worth his salt will understand that state requires persistence, and that means a performance hit. For example, most real applications have things like shopping carts, in-flight transactions and so forth. The answer is not to simply make all applications stateless- there are very few business problems that get solved that way. So the architect is forced to deal with user state. But where to put it?
Way back when J2EE was young, it was thought that Stateful Session Beans might help (don't even get me started on EJB 1.1 Entity Beans). That discussion was over as soon as the first application using them needed to scale. Not to beat up on SFSBs necessarily- in theory they are a wonderful thing- but in practice they didn't pan out. Why is that?
Most developers really don't want to deal with user state management. It just feels "right" that the underlying application infrastructure should take care of it for you. But in practice, every customer I've ever talked to wrestles with this constantly in their architectures. There still remains a need to handle user state information in an elegant and scalable fashion. So the solutions that have been created over the years are:
a) Put the state in the database. Not a bad choice as hardware and networks continue to get faster. But you're still introducing a bottleneck behind your app servers.
b) Put the state into memory. Clearly the fastest choice, but not terribly fault tolerant and very difficult to share across JVMs.
c) Put the state into the client. Not everyone has the ability to accept cookies in their browser, not to mention the security implications.
Option 'b' seems to be the recurring favorite for most architects- it's hard to beat memory for pure speed and convenience. Many strategies have been developed to make "shared memories" across JVMs that adhere to various levels of transaction atomicity and consistency. These have ranged from WebLogic Server's own built-in session replication mechanism to elaborate JMS based pub/sub systems. But at the heart of these solutions are usually two challenges for large farms of JVMs:
1) limited state size (e.g. replicating 10MB for each user between many JVMs is just not practical)
2) overly complex configuration (e.g. who wants to maintain a giant rats nest of JMS topics and subscribers?)
This is precisely where Application Grid comes into the picture. Application Grid is primarily an approach whereby we introduce a way to handle our option 'b' above without the associated limitations or complexity.
A key part of Application Grid is the ability to establish a Data Grid layer between the app server and data sources. Think of the Data Grid as that "shared memory" that each JVM in an application server tier can use to handle stateful information. The Grid is built of nodes- each node contains some set of state information that is relevant to its clients. The Grid takes care of replicating the state across its own nodes automatically so that your applications (or even your application server) doesn't need to.
The Grid is scalable- add more nodes and it handles more load. The Grid is fault tolerant- take away nodes and you introduce request latency, not access failure. And finally the Grid is really simple- basically it's java.util.Map- how much simpler can it get for your developers? To boot, it also layers on top of WebLogic HTTP sessions and underneath TopLink JPA as an L2 cache.
Stateful applications are here to stay, and yet stateless architectures are a proven thing. Using a Data Grid approach can give you the best of both worlds without all of the headaches. We will explore some more use cases in future blog posts- stay tuned!
