All about Grid and Cloud Computing: Discover the limits

The Web on OSGi is an interesting slide set from JavaONE. Presented by Don Brown from Atlassian I agree with several issues he address. For example the 'know your wires' on slide 42 (See also: http://blogs.sun.com/intheclouds/entry/inspecting_the_integrity_of_your and http://blogs.sun.com/intheclouds/entry/osgi_dependencies1).

Peter Kiens somehow replied to this slide set in this blog entry: http://www.osgi.org/blog/2009/06/osgi-case-studies-pain.html

Don Brown replied with: http://www.jroller.com/mrdon/entry/clarifications_re_javaone_web_on. In that post he says:

OSGi has let us write big features in a portable, modular way across products, and has dramatically sped up the development process via its hot deployment capability.

I am a big fan of modular software. It allows the reuse of software parts and clear designs. Especially the later one. Think of a Object Orientated Software project where 100 of classes can just call each other - We invented OO programming for more cleaner designs and now the dependency graphs look horrible (have a look here), because every class depends on other classes and no clear boundaries are available.  With the help of modular design it is possible to clean it up. But it needs to be enforced (see also here). If you say a programmer you should do it, he won't. Therefore I suggest using OSGi! (But OSGi can become a mess to: 1 2)

Now I discovered a project for modularity in space and satellite design. With CubeSat (10cm x 10cm x 10xm) cubes are used as modules for satellites. It is therefor possible to create 1U, 2U (two cubes) and XU (X cubes) big satellites. Great idea! And it seems to work. Only the reuseability does not seem to work :-)

Also great it the reduction of cost by using this satellite model. This is also true when using modular designs in software. You can run successful projects within time and resource usage with the right planning, tools and a modular design.

Other sites about the CubeSat:

http://cubesat.atl.calpoly.edu

http://www.cubesatkit.com/  - yes you can even build your one :-)

Craig Walls (author of the book Modular Java) has written a nice entry about OSGi and myths around it: http://java.dzone.com/articles/dozen-osgi-myths-and.

He works around these 12 topics and bust most of the myths (except one):

1. OSGi is too complex
2. OSGi is too heavyweight
3. OSGi isn't a "standard"
4. OSGi is too new
5. OSGi isn't ready for the "real world"
6. There aren't many OSGi tools
7. OSGi is for Eclipse users
8. OSGi is a solution looking for a problem
9. I can get modularity without OSGi
10. OSGi is difficult to test
11. OSGi doesn't have a cool name
12. There are no books on OSGi

I fully agree with his thoughts.  Even when it comes to the name...To be honest OSGi is really not that 'cool' :-)

Another nice quote:

Well I'm working with OSGi for quite some time now but here is a nice introduction to OSGi. 

This webinar is hosted at eclipse live and definetly worth to watch: http://live.eclipse.org/node/407

ModuleFusion won one of the awards at EclipseCon 2009. ModuleFusion describes itself as:

The goal of ModuleFusion is to help programmers to use the OSGi Service Platform as their underlying runtime environment. ModuleFusion contains a full stack typical for Java enterprise applications. This stack currently consists of best-of-breed open source frameworks from the Java ecosystem. Additionally, ModuleFusion contains the necessary glue code to easily use these frameworks within OSGi.

It currently consists of the Equinox as well as the Apache Felix OSGi framework. nice work & congratulations!

P.S. another award winner was: http://directory.apache.org/studio/

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've been working with OSGi for the past years - and I must admit I really like it. If you follow some best practices rules your applications are definitely going to perform better and look nicer. Therefor I remembered an presentation about best practices when using OSGi. I have almost nothing to add - See for yourself: OSGi Best Practices!

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.