The Artima Developer Community
Sponsored Link

Clustering J2EE with Jini
A Conversation with Sean Neville, Part I
by Bill Venners
October 21, 2002

<<  Page 2 of 4  >>

Advertisement

Object Clustering

Bill Venners: Define what you mean by object clustering.

Sean Neville: In our context, clustering is related to providing high availability, failover, and load balancing for RPC (remote procedure calls) and in making that mechanism as simple to use and as close to zero-admin as possible. We're talking about clustering remote objects. We wanted high availability when clients perform remote calls, so we needed to have multiple skeletons available to process the call. We also wanted failover, so that a user working with a particular stub could automatically failover to another one. Finally, we wanted basic load balancing. Although load balancing is typically handled at the hardware level, developers also expect to find it available at the software level. As part of the load balancing feature, we needed the ability for a stub to choose its skeleton in an algorithm-specific way. We also wanted the algorithm to be pluggable so users could define their own algorithms. And we wanted to make the whole thing simple to use.

Like several application servers today, JRun is built on a service-based microkernel architecture. At the base level is a microkernel that manages services, and all J2EE features are implemented in terms of those services. Services can play many roles, one of them being a manageable role implemented through MBeans.

Bill Venners: MBeans?

Sean Neville: Managed Beans, defined in the JMX specification, which take the JavaBean component model and infuse it with management standards. This is how the service kernel works: if you build a service and deploy it into JRun, in addition to being many other things, it is also an MBean. So standard systems management products, such as Tivoli or OpenView, can manage it. We represent most everything -- from our EJB containers to deployers to our servlet engine -- as MBeans. But MBeans are also remoteable; they are another example of a remote object in our server. This isn't unique to JRun. Other application servers take a similar approach. Among the application servers that use this JMX service framework in one way or another -- and they range from the extremely expensive and fat, to the slim mid-range (like ours), to the free and open-sourced -- I believe JBoss exploits it to the greatest degree.

In any event, our customers were asking for EJB clustering, specifically stateless session-bean clustering. But instead of just developing a specific solution for stateless session-bean clustering and tacking it on front of the container, which is what many vendors ended up doing, we wanted to build clustering into the base remote mechanism itself. So any remoting technology that we built on top of this mechanism -- JMX, EJB, whatever -- would automatically inherit this clustering functionality, and we wouldn't have to do anything new for specific cases beyond configuring the metadata.

Bill Venners: So customers were mostly interested in stateless session-bean clustering, but you wanted to have generic clustering functionality that could also give people that stateless session-bean clustering.

Sean Neville: Right. We also wanted to apply the clustering mechanism to EJB types other than stateless session beans, and make it easy for customers to extend the mechanism. Two of JRun's strongest targets are the OEM and ISV (original equipment manufacturer and independent software vendor) markets. A number of major software businesses embed JRun in their products. As a user, you might not actually know that you're using JRun, because it's often rebranded. We like that case. So we try to design each feature to be as small and as extensible as possible. Larger J2EE servers seem less concerned with the extensibility use cases of OEM/ISV scenarios and in implementing them to be small and simple, perhaps because we're talking about a pure software objective rather than a hardware or services play.

We also wanted the clustering architecture for our own internal convenience. We didn't want to have to think about developing and maintaining cluster code every time we invented a new subsystem. We wanted to have a single mechanism to handle it. So clustering needed to be designed for our own reuse, as an aspect of our service infrastructure that could be applied to any service.

<<  Page 2 of 4  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us