ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

JBoss Cache as a POJO Cache
Pages: 1, 2, 3, 4, 5, 6

Traditionally, to provide complete failover (or persistence) capability, the system has to be designed to manage the object relationship explicitly, as in a modern day object-relation mapping (ORM) solution approach. And in a traditional entity persistence layer-style design, you have to do the following:

  • Externalize the relationship mapping (e.g., in a XML file).
  • Break down the object construct individually into primitive types.
  • Have a notion of object identity to preserve the relationship.
  • Keep track of dirty fields (if you want to avoid the whole object serialization cost).
  • Finally, assemble the primitive types back into objects.

By using the JBoss POJO Cache to handle your object states, however, none of the problems mentioned above exist! To elaborate, the benefits are as follows:

  • Instantaneous failover (through state replication) without modifying your domain object model or specifying complicated object relational mapping.
  • Optional state persistency that can preserve the object graph, as well.
  • Fine-grained replication (or persistency) that can be batched for optimized network traffic.

As we described above, the replication and/or persistence aspects in the POJO cache are totally transparent to the user. Note that for total clustering, there is another aspect of load balancing or locating the primary and/or secondary managers to which both the client GUI (for administrators) and the sensors should connect. We do not cover such issues here, and will focus only on the replication of the sensor network state across the managers.

Topology and Object modeling

Figure 3 is the topology for our sensor supervising system example. Basically, in this simplified example, we have two stations (Tokyo and Yokohama) and within each station we will have one wind and one rain sensor. For each sensor, there are numerous components that need to be supervised; e.g., the power supply and the sensor unit itself. Our goal is to supervise the sensors efficiently by 1) monitoring the individual item status (e.g., a StateItem) as well as their overall status (e.g., Wind Summary), and 2) having the ability to bring up and down individual sensors at runtime without restarting the clustered manager nodes.

Topology for the sensor supervising system
Figure 3. Topology for the sensor supervising system

Figure 4 illustrates this domain model using a class diagram. Essentially, we have a PropagationManager at the top level that handles the whole sensor network. It always has one root Node. The root Node can have, recursively, numerous Nodes. Each Node can have multiple StateItems. A StateItem is the smallest management unit; for example, representing the unit's power supply.

Class diagram for the sensor supervising system
Figure 4. Class diagram for the sensor supervising system

For the current topology in Figure 3, Japan represents the root node, while Tokyo and Yokohama are the station nodes, respectively. The different sensors (rain or wind) are represented by a Node object as well. Each sensor then has two StateItems, namely Power Supply and Sensor Unit.

The relationship between Nodes is bidirectional; we can navigate from the root node all the way to the leaf node, or we can navigate backwards through the parent node as well. In addition, there are one WindSensor Summary and one RainSensor Summary StateItem instances that reference the respective sensors. The purpose of the summary items is to monitor the overall health of, say, the wind and rain sensor units as a group. As a result, the objects in the object graph for the sensors are multiple referenced (as shown in Figure 2 and 3).

Pages: 1, 2, 3, 4, 5, 6

Next Pagearrow