We’re excited to tell you that our new book, SpringSource dm Server in Action, is now available under the Manning Early Access Program. As you can guess, the book focuses on the dm Server and its impact on the world of Java EE programming.

What’s inside?

We start with the basics: installation of the dm Server and the Tool Suite, followed quickly by your first helloworld bundle. Then we dive into the deep waters of the dm Server’s architecture. Understanding the architecture and capabilities of the dm Server allows us to explore the different approaches we can take to architecting our applications. Our code is no longer bound by the monolithic structure of WARs, RARs, EJB JARs and similar foul beasts. However, we cannot ignore existing applications and we dedicate two chapters to moving existing Java enterprise applications to the dm Server. Finally, we show how to monitor and manage dm Server instances in production environment and — using the information we gathered — we explain how to improve your applications’ performance and reliability.

Wait no longer!

If you are interested in writing new OSGi-based applications or migrating existing Java enterprise applications to the dm Server, wait no longer and get your hands on our book at http://www.manning.com/machacek/.

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!

With the RC2 of SpringSource’s dm Server the OSGi development in Java will gain even more momentum. There are two camps of developers: one hates OSGi and the other loves it.
The reasons for hate include steep learning curve, difficulty in migrating existing applications and complexity of deployment. The first two reasons are understandable. Our SpringSource Application Platform in Action book will help with the first one and the dm Server will do an excellent job in making the migration as painless as possible. The third complaint — complexity of deployment — is not so clearly cut. If you currently need to deploy multiple versions of the same service at the same time, chances are that the complexity of your application is far greater than the complexity if equivalent OSGi-based application. In most cases, programmers actually refer to deploying a new version of a particular class or jar. But they do not want the new version to be available at the same time as the old one. Essentially, once the new version is out, the old version is lost. It is the typical update & pray scenario. You can obviously do the same with OSGi bundles. There’s nothing stopping you from updating a bundle whilst keeping its version number. OSGi is not obtrusive at all in this respect!

Assemblies

Similar thing happened to .NET assemblies: the assemblies can include a version number and .NET type identification includes the class name, the assembly and optionally a version number. Most systems use only the simple type identification, without the version number. The users of the .NET Framework have thrown away the versioning control in favour of trivial deployment and risk of problems.

Change of thinking

What we need is a shift in thinking: you can still continue with the big bang deployment, even in the OSGi world. You should, however, try to make full use of the features of the OSGi’s execution environment. This will pave the way towards easily maintainable applications in the future.