Transport Layer

In this blog I have tried to put across my idea of developing a clustered cache

Without a clustered cache implementation, it is difficult to implement a true Singleton object. The Object created in a particular JVM will not exist in any other JVM’s and hence the other JVM’s will create a different instance of the Singleton object. To avoid these issues in a clustered application, a clustered cache would turn out to be useful.

The idea behind a clustered cache is that the data created in one JVM should be copied to the other JVM’s. The synchronization of data between JVM’s should be the responsibility of the cache itself and transparent to the application. A sample component diagram is shown below. In this approach, application accesses the cache component in JVM1. The Cache component will interact with the Synchronization component in JVM1. The Synchronization component of JVM1 will transport the data using a transport layer. The synchronization component of JVM2 will receive data from the transport layer. Once the data is received by the Synchronization component in JVM2 it needs to update the local cache in JVM2. The synchronization component should implement the following features.

· Identifying instances when the data changes in the local cache.

· Initiate the transfer of cached data to the subscribed JVM’s.

· Ensure that the data is published to other subscribed JVM’s.

· Algorithm to effectively transport data like compressing, collating etc.

· Receive the cache data from other JVM’s.

· Update the local cache based on the data received from other JVM’s.

Some of the possible Transport Layers are described below.

· JMS – Java Messaging Services implementations can be used to transport the data. The disadvantage with this approach is that a transport layer needs to be added to the application framework like IBM MQ. This is definitely a cost addition to the application infrastructure. However in the later versions of Websphere Application Server, a embedded JMS implementation is provided which can be used as transport layer.

· IP Multicasting – Data can be transferred from one machine to other machine using socket connections. In this approach, SocketConnections and SokcetListeners should be developed which will be used to transport data. The disadvantage with this approach is that a particular port should be opened for the machine through which data can be transferred. This is considered as security risks in many bigger corporations.

· Remote Method Invocation – This is an approach where the data is transferred from one JVM to another JVM by using Remote Method Invocations. The marshalling and demarshalling algorithms should be developed for this implementation. The disadvantage with this approach could be the performance based on the network.

· EJB – Enterprise JavaBeans can be deployed in the JVM to transfer the data. This is very much similar to the RMI mode of transport except for the fact that marshalling and demarshalling will be automatically performed. The disadvantage with this approach is the necessity for an EJB Container. Hence the approach will not work on java processes implemented outside any J2EE container.