Distributed Web-Applications using the Keel Meta-Framework
Fortunately, yet another open source project brings an answer to fill this need. Most Java applications use the JDBC API to communicate with their database(s), via a JDBC driver especially written for the database they choose (in our example, PostgreSQL). A new project, called C-JDBC (c-jdbc.objectweb.org), provides a JDBC driver that does not talk to a single database: instead, it talks to a heterogeneous collection of databases, making them appear to the application on the other end as a single large database. Database writes are distributed across the entire group. Database reads, however, are load-balanced to a single database in the group. This does two things for us: it gives us the ability to eliminate the single point of failure of the database. If C-JDBC cannot reach any one database, it is simply marked as offline and the others in the group used instead. It also allows us to reap the performance and scalability benefits of clu! stering at the database level, especially in read operations. Most applications spend more of their time reading the database than writing to it, so this can be a large boost in such situations. Database failover and clustering like this has been available for a few of the higher-end commercial databases for some time, but usually at a high cost, and always with the requirement that all of the clustered databases be of the same type. C-JDBC has the unique advantage that even different database engines can be mixed in the cluster. A few MySQL servers, a few PostgreSQL and a Hypersonic: all can be combined into a single powerful cluster.
Fifth Breakout: Eliminate Single Point of Failure
As you can see in our last diagram, bringing C-JDBC into the mix gives us a fairly resilient overall architecture. Let's examine the possibilities: if a web application server fails, Balance will simply shift the load to the remaining servers (each of which has a copy of any user context needed). If an application server (e.g. a Keel server instance) fails, the load again shifts seamlessly to the remaining servers in the cluster, and again the current Context is shared and available to the other servers. With C-JDBC, even a database failure is not a show-stopper: the database that does not respond simply gets "skipped" temporarily, and can be brought back up-to-date when it is back in operation.
The old saying about a fool proof system no doubt holds true: a more inventive fool will come along to find a way to break it. At the same time, it is now possible, using only open source technologies, to provide a highly failure resistant application that can start small and simple, and grow as quickly as demand dictates and in the way that makes best sense for the specifics of the application being run.
About the AuthorMichael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at firstname.lastname@example.org
Page 3 of 3