This is my first post and I hope to follow this with a number of posts on the progress of my thesis and some general rambling. I am working on developing an abstraction for Terracotta to provide a single system image (SSI). SSI is the idea where workstations that form a cluster work collectively to provide an illusion of a single system to the user as well as the developer. With such an abstraction, the developer is completely oblivious to the issues related to distributed computing and writes an application just like any other application meant for a single system. Issues like socket connection, remote method invocations, consistency guarantees and scheduling of threads are some of the many details that are abstracted.
Unlike JavaSpaces, which provides an API for distributed programming, where the developer is expected to learn the API and use them wisely inorder to scale an application, the idea here follows no use of an API or no knowledge of distributed systems. The motive is to develop a middleware that leverages compute intensive multi-threaded java application for scalability and provide full transparency desired for running already existing applications (even when the source code is not available).
The current most popular system that uses the concept of JVM-level clustering is Terracotta. JVM-level clustering simplifies enterprise Java by enabling applications to be deployed on multiple JVMs, yet interact with each other as if they were running on the same JVM. At present, Terracotta has no concept of global thread scheduler and the programmer of a multi-threaded application needs to be concerned about manually launching multiple instances of the applications, and manual load-balancing. Also, a current Java program that launches several threads using only the Java Thread class cannot take advantage of the Terracotta infrastructure. If we had a middleware that could bridge both Terracotta and multi-threaded Java applications, handling the scheduling of threads and using the existent shared object space to keep data consistent, we could run already existing applications in a distributed environment with almost no extra effort and obtain scalability. This is what I will be working on for the next 6 months.
For now, I have been doing some background study understanding the architecture and internals of Terracotta. The development of the middleware involves heavy byte-code instrumentations and I plan to use the ASM framework for the same. For the past few days, I have been playing around with custom class loading, understanding byte-codes (not a pleasant experience given my lack of expertise in assembly programming) and nigh-outs at Bairro Alto.
