All about Grid and Cloud Computing: Discover the limits

Sun has many cloud computing initiatives e.g. network.com. Playing only a underpart is the work done in the RESERVOIR project. RESERVOIR stands for Resources and Services Virtualization without Barriers and is part of the Framework 7 program of the European Union.

Sun is part of this RESERVOIR project and provides great technologies to the project. Besides working on standards for upcoming Cloud Computing frameworks Sun will

• setup and configure the Sun Grid Engine so it is able to run in Cloud Computing environments
• Develop a application container which allows it to handle Java based applications the Cloud way.

The first part is pretty straight forward, while the second part involves more software development. The goal is it to provide a application container which allows the deployment of different kind of Java applications. Those services should then be managed  e.g. based upon predefined SLA definitions. Service can then be started, migrated, suspended, consolidate/distributed (if more instance are running) and stopped.

Sun is therefor developing the Virtual Java Service Container with the project name Floccus :-) More details are coming up.

I have been a great fan of pushing the degree of automation to a limit. And as stated in this blog post: Software engineering and as a follow up of OSGi dependencies and OSGI  Best practices: I now present  the consistency and OSGi dependency checker :-)

The setting is a multi modul maven project for a OSGI based application - with all the nice maven features turned on (reports (all kind off), scm, issue tracker, mailinglist, etc) - so to speak of a complete Software Development Environment.

The broken window principal says:

"Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside. Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars."Source: wikipedia

And to prevent the broken window principal I implemented a small tool doing some of this stuff:

• Checks what kind of dependencies are available between the OSGi Bundles
• Detects cycles (which is bad :-))
  
• Looks for unused imports and exports

As a result you get e.g. a report and a graph.

The second part of the tool is maybe even nicer :-) Beside all the good reports and tools you can use like findbugs, pmd, checkstyle, and others; sometimes I'm missing the very basic stuff. I implemented some consistency checks which can check for the following stuff, and verify the consistency of your project:

• Look if all needed Unittests are available
• Look for old unused code
• Look for old empty packages
• Test  if the 80% code coverage mark is reached by the Unittest (and if methods are tested for sanity, failure, and success)
  
• Look for files which are not included in the binary build (they might be obsolete)

You could integrate those checks in the build systems or even force them on checkin like svnchecker does. Or you can use it to generate reports.

I like the OSGi platform, and I have been using it for quite a while. One of the most important things is to keep track of your dependencies (e.g. like preventing cycled dependencies). Auto-generated MANIFEST.MF files are most of the time not really optimized. Therefor I started writing some python code to check dependencies. 

 It reads in all the MANIFEST.MF files from the bundles and creates a dependency graph. It will look for unnecessary and unneeded imports and exports. Look for cyclus etc. It is written using the networkx library for python. Also useful is the zipfile extension in python :-) It can be used to extract the jar files of bundles.