We have just contributed our own videocast to the YouTube black hole. It is the first out of three videos that deal with migrating Java EE applications to the dm Server.
This first part (for some strange reason, we decided to call it Episode IV) shows the outline of the process, but skims over the details such as the structure of the archives being deployed and the MANIFEST.MF descriptors.
The second part is going to concentrate on packaging structure of the shared libraries WAR deployment model. The second part is therefore going to show details of the Ant build files. We are also going to show the Bnd tool that bundlifies any JAR.
The final part is going to show the shared services WAR model; we are going to show the main reason why you’d move to the shared services WAR: to use services exported from other bundles in the dm Server!

Episode IV

We’ve received the cover designs for our book, dm Server in Action. We had three choices and the final scores are:
In the third place miserable looking so and so, whose pen hides Ani’s name!

In the second place, a fairly wealthy turk. We think he’s rich, because he’s dressed in blue and in his time, blue was the most expensive colour. To get truly rich blue colour, you needed natural ultramarine, which turns out to be the most difficult pigment to grind by hand, and for all except the highest quality of mineral sheer grinding and washing produces only a pale grayish blue powder.

And the winner is…

We actually don’t know anything about her, we can only guess that she’s Dutch and that she’s not particularly wealthy. But that’s OK, we’re not snobs at all, even if we live in the UK, have kippers and toast for breakfast and cups of tea and biscuits at 5.

Aleksa and I gave talk at the Spring in Finance Exchange in London on Friday 10th October. We took a large Java EE web application (a huge 22MB WAR file) and deployed it in the dm Server. And it worked!
But that was just a small preview of things to come.

Shared Libraries WAR

Next, we deployed the application in the shared libraries WAR model. In short, this allows you to share the libraries from your applications amongst other applications running in the dm Server. Imagine that you have three large applications, two of them are using Hibernate 3 and one is using Hibernate 2 (oh, the humanity!). You can install two independent versions of the Hibernate classes in the dm Server. This means that the memory footprint of the dm Server running the three applications is significantly smaller than the footprint of Tomcat or any other application server in the same situation.

Shared Services WAR

Shared libraries solve some Java EE deployment problems, but do not address the situation where you need to access some of the services exposed from other bundles in the dm Server. If you wish to do that, you have to deploy your application as shared services WAR. In this model, you split your application into its “services” bundle and keep the web module as simple as possible. The important consequence of this deployment model is that you can import (and export) other services from your application’s “services” bundle.
For more interested readers, check out the video podcasts on the Skills Matter site.

SpringSource have released the GA version of the dm Server. The dm Server is an OSGi-based Java EE application server.

OSGi what?

OSGi will allow you to keep the structure of your application even at runtime. You will be able to kiss good-bye to the monolithic deployment archives that obliterate your application’s structure. However, straight OSGi comes with a terrible price.

Remember this?

; set PE bit
mov eax, cr0
or eax, 1
mov cr0, eax
jmp cs:@pm
@pm:

This switched the 80286 CPU to protected mode; the 80386 also brought paging and virtual address space. In protected mode, we can run the same code as in real mode, but the memory addresses are completely different. This means that old trusty code in BIOS is unusable; we can keep our applications, but the applications cannot use int 0x13 to read from the disk. We had to start using real operating systems, whose kernels process the applications’ requests and access the hardware directly, without the real-mode code in BIOS.

What does that have anything to do with OSGi? Well, OSGi can run any ol’ Java code, but you cannot “just add this jar to the classpath”. This means that virtually all applications need to be re-packaged and updated to make them run in OSGi execution environment. In fact, there is no application in OSGi, there are only bundles. This is in principle excellent, but we still think about applications as umbrellas for bundles.

SpringSource OSGi repository

The work involved in turning 100 odd jars in a typical Java EE application into OSGi bundles is terrible. Luckily, SpringSource have a repository of trusty old Java EE libraries turned into OSGi bundles. You can download and use these bundles in place of the jars you had in your JEE applications.

dm Server

As you can guess, the dm Server bridges the pure OSGi world and standard Java EE application server world. You can deploy existing WAR as well as new PAR (Platform Archive, a collection of bundles). Additionally, each bundle can specify its personality. The personality specifies the type of code the bundle contains. A web personality tells the dm Server that the bundle will be processing HTTP requests and that it will need to be deployed in Tomcat, which is bundled with the dm Server.

Baby steps

We won’t go into detailed description of the dm Server’s architecture — we can’t give out all details of our book, SpringSource Application Platform in Action. We will, however, invite you to Spring in Finance Exchange, where Aleksa and I are going to show how to move a complex Java EE web application from WebLogic to the dm Server live!