|
|
YOUR FEEDBACK
Did you read today's front page stories & breaking news?
SOA World Conference
Virtualization Conference $200 Savings Expire May 16, 2008... – Register Today!
SYS-CON.TV |
TOP THREE LINKS YOU MUST CLICK ON Open-Sourcing Java
Fault Tolerance with Open Source and JVM Clustering
A marriage made in Java
By: Ari Zilka
Nov. 1, 2006 02:00 PM
Digg This!
Many in the Open Source community (including the camps following Tomcat, Geronimo, Struts, Spring, and Hibernate) have chosen to focus on solving problems of developer efficiency and software elegance, and are sometimes forced to leave production operating characteristics such as HA (high availability)/fault tolerance and central management control for future releases. Or, in some cases, the elegance of the framework stems from its lightweight nature and thus the user community as a whole can't be made to suffer the complexities of clustering and HA for the needs of the few.
Therefore, in response to this growing issue, more than five Open Source clustering projects have recently emerged, but the task of integrating them into development frameworks is pretty significant and will realistically take quite some time. Java serialization (some architects refer to this as the big "S") can impose an insurmountable number of complexities on an application's domain model, and simultaneously reduces performance to a significant degree. So what's an IT manager to do, wait and hope for the best? Enter clustering at the JVM-level. Access to the network when reading and writing objects to heap can be transparent and efficient. Think "network attached memory" with performance optimizations that, at runtime, pushes only heap-level deltas and only to JVMs that are actively accessing particular parts of objects. With heap-level replication, the Open Source frameworks don't have to change when an enterprise IT management team decides an application is too important to run without HA, for example. Let's examine a use case. Spring Web Flow or Rife Continuations both aim to solve a similar problem for the developer of Web applications. This is a well-understood problem around making support for the "forward" and "back" buttons in Web browsers work in a consistent and logical fashion across Web sites without custom coding by each application developer in each enterprise. For example, in visiting three Web sites a consumer adds an item to his shopping basket at each site. On one site, clicking the "back" button implicitly removes the item from the basket while on the other two it doesn't. This is due to the fact that without container support for the "back" button, a Web app developer is left to his own devices when defining the "back" behavior for the site. Continuations provide an easy way to restore an application's state to the mode it was in when the Web page was first rendered. This lets the developer decide what changes to state should or shouldn't be rolled back without lots of custom code. This is a very powerful development paradigm. But it trades off the value originally sought after with load balancers and session clustering. That value was one of total fault tolerance; with sessions clustered and a sticky load balancer, no one app server was critical to production operation, and yet the applications didn't bottleneck prematurely on network replication of the session state. The application server's internal clustering can't always guarantee that the information that the Spring or Rife framework needs to restore state is available on the server that the load balancer has sent the HTTP request to. If Serialization was used to copy the state of a Continuation around the application server cluster, all objects that can be accessed and edited during a response to that request would have to be serializable, and the developer would have to resolve possible conflicts when objects start getting duplicated around the cluster. So Spring and Rife have chosen to leave this problem to a JVM-level clustering solution and have been cooperating with Terracotta. It's a unique marriage, but it works. Terracotta provides a production-proven JVM clustering engine for Java applications in production. Since clustering at the JVM-level requires no code changes, the technology allows Spring, Rife, Tomcat, Geronimo, and other frameworks to be clustered with no changes either to the framework or the code that enterprises write when using those frameworks. Clustering and, thus, HA, can be injected at runtime after an application is designed, written, QA'd, debugged, and launched into production, as long as no one tries to cluster that application by hand. Terracotta provides a (pure Java software-based) server that acts as a network attached memory hub and efficiently brokers all communication among the application JVMs. It can be downloaded and comes pre-configured for many current frameworks (with more to come on the horizon). When Terracotta servers are used underneath Open Source frameworks to inject HA at runtime, the Terracotta server's production license is free. However, just to avoid any confusion, please note that Terracotta is a commercial company that offers support and services in conjunction with production use of its products. The value is in delivering HA to any and all Open Source. And soon Terracotta will introduce a developer area on their web site, where Open Source framework integration will be fully supported via online tools consistent with the community's expectations: support forums, bug tracking systems, etc. Furthermore, the site's developer area will offer open sourced source code that implements key design patterns for working optimally with network attached memory constructs. The key benefits of combining Open Source and Terracotta:
LATEST JAVA STORIES & POSTS
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK BREAKING JAVA NEWS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||