Main.MainConcept ( vs. r1.1)
Diffs

 <<O>>  Difference Topic MainConcept (r1.1 - 30 Aug 2004 - MichalFrackowiak)
Line: 1 to 1
Added:
>
>
META TOPICINFO MichalFrackowiak date="1093899017" format="1.0" version="1.1"
META TOPICPARENT ProjectDocumentation

Main Concept Overview

The aim of the project is to create both simple (in use) and universal high-level platform for distributed computing in Java through object migration.

While mechanisms like RMI or CORBA are low-level ones, so far almost all the projects targeted to create a higher-level platform for grid computing (e.g. JavaParty, Manta, JavaSymphony) failed or do not provide stable solutions for general use due to (as I believe) uncontrolled complexity of those solutions.

The base scenario for using JCuckoo is:

  1. Create a JC grid running dispatchers and computing nodes on computers.
  2. Client connects to the grid (top-level dispatcher), makes his object(s) remote and sends them to the grid.
  3. Client runs methods on the remote objects (using a grid is transparent, client uses local proxy objects).
  4. Methods return results to the client.

Planned JCuckoo features:

  • Creating complex computing topologies (consisting of dispatcher and computing nodes)
For example it will be possible to create a JCuckoo grid consisting of computers in one building, just running a Java-program on them. The solution will also work with sub-nets behind NAT etc. Using different transport layers and security managers it will also be possible to extend the grid to wider areas, even worldwide (with SOAP and SSL). Thus it seems possible to create very large distributed computing projects as SETI@HOME. Because it will be Java-based, can be run on many platforms Java supports and support multi-OS grids thus allowing turning even desktop computers into nodes of the grid. It is worth mentioning that no such projects (as far as we know) exists.

  • Maximizing easy of use for a client user (adding only a few lines of code to the original one will allow sending specified objects to remote nodes).
The programmer wishing to connect to the JC grid needs to connect only to the main dispatcher of the grid and change his Java code in a few places. In the basic usage scenario making an object remote and sending it to the grid is a matter of 2-3 lines of code. For more advanced (and more integrated with JCuckoo) there will be more possibilities.

  • Remote threads
It will be possible to implement remote threads which will help converting multithreaded applications to distributed applications.

  • Auto load-balancing, grid monitoring
And all the internal grid-like features.

  • Transport layers and security.
Transport layers can be changed so it helps building custom grids. Also a security manager will be included to authorize users to connect to the grid and use its resources.

Several other ideas are planned. But the idea is to keep the mechanism advanced but the usage as simple as possible. There are of course limitations and not any type of object can be made remote. But for example turning the computers in labs into grid and searching for primes seems to be simple with little effort of the final user of JCuckoo.

We have already created a prototype version at the Department of Mathematics and Computer Sciences (Nicolas Copernicus University) in Torun (Poland) as a team programming project. The project works and enables to use labs as computing grids. It uses JGroups as a transport layer.

JCuckoo (as a separate project) will be much more advanced, flexible, reliable and user-friendly.

The project will use Java language and will be available for all platforms Java supports.


Topic: MainConcept . { View | Diffs | r1.1 | More }

Revision -
Revision r1.1 - 30 Aug 2004 - 20:50 - MichalFrackowiak