dm Server

The SpringSource dm Server is an OSGi-based Java EE application server. The dm Server is part of the SpringSource Application Platform. In addition to the dm Server, the Application Platform contains tools and components that simplify development and management of Java enterprise applications.

Life without the dm Server

We know that we should be starting with a positive outlook – you know, there are no problems, there are only solutions and so on, but let’s be honest for a moment and explore the issues we face in our Java EE application development and delivery. When we implement our Java EE applications, we usually take extra care not to introduce too many dependencies. We layer the applications and we use the development environments and build scripts to enforce the layering rules. We use circular dependency and complexity analysis tools to ensure our code is as clean as possible. Then we take our well-designed and cleanly structured code and build a deployment archive. The archive and the deployed application do not maintain the structure we have worked so hard to create. We also try to keep the libraries in our applications consistent. When we start building our application, we make sure that we satisfy the dependencies of all components in our application exactly. When we use Hibernate 3.3.0 SP1, we need to include Commons Collections 3.1. All is well until some other component needs Commons Collections 3.2.1. We cannot keep both the 3.1 and the 3.2.1 Commons Collections jars, so we only keep the latest version and hope for the best. Problems that are even more serious arise when we need to make changes to our application. In the current Java EE application servers, it is difficult to update components of running applications without restarting them. As a result, even a simple change means downtime and even if we exhaustively test the application in a pre-production environment, the deployment may still fail. Finally, when our deployed application is running, it becomes a black box. To alleviate this problem, we include management and logging code in our application. Unfortunately, each application uses slightly different logging infrastructure. Moreover, the logging that the management and monitoring infrastructure does not always contain the information the developers need. To summarize, the list of issues we face the traditional Java EE application deployment includes:

• Monolithic deployment archives. When we build our carefully designed application, all its structure is lost in the blob of the deployment archive.
• Complex re-use of services. It is difficult to simply refer to services from other already running applications. Even if we use framework services to reduce the complexity of exposing a service in a traditional Java EE application, we still face class loading and versioning problems. It not possible to have two versions of the same library in the application server’s shared libraries. This forces us to use other transport formats, such as XML, which only adds to the complexity of our applications.
• Complex change control. Whenever we want to deploy a new version of even a small component in a monolithic application, we have to deploy the entire application. Moreover, it makes it more difficult to determine the scope of the change we introduced. Without modularity, we have to re-test the entire application.
• Lack of versioning. It is impossible to reference a specific version of a library in our applications. We cannot deploy multiple versions of the same library (class) in our application server and then specify which version our application needs. We end up deploying many common libraries in each application; and even so, we may run into problems caused by the application server’s class loading behavior. Ultimately, we find ourselves in a deploy & pray situation, where we deploy the application and hope that it would somehow use the right library.
  *Complex management and monitoring of running applications. Over time, we have perfected the logging and monitoring of our Java EE applications. Still, time and time again, we find ourselves complaining that the logs do not contain enough information to identify an error.

We got used to living with these problems: we automatically package our applications into a monolithic archives; we hope that the different library versions will be compatible enough not to cause any problems in our application. We accept that to design a flexible service-oriented application, we have to jump through technological hoops. We are forced to consider the complexity of the logging framework and the application’s performance in order to record enough information in the log to allow us to successfully diagnose the problem. Often, we do not record enough state information about the failures and we record the topmost failure, rather than recording the first failure (the root cause of the problem). Now, forget all those limitations and imagine a perfect platform. Such a perfect development and deployment platform would help us:

• Enforce application’s structure at runtime. We would like to maintain the packaging and layering structure of our application even when we deploy it.
• Use versioning of the components. We would like to eliminate the possibility of incompatible libraries in our applications. We would like to be able to reference a library by its name and a version.
• Be able to change components of our applications without changing the rest of the application. If we could do this, we could reduce the downtime. More importantly, if we could keep the application modular, we’d focus more on loose coupling. We could also more easily control the development process in larger teams. Finally, we could reduce testing time, because we would know the specific components that have been changed.
• Closely monitor our application’s health and performance. If all our applications shared the same management and monitoring interface, we could simplify the work for the production team. In addition, the management and monitoring information should allow the developers to easily identify the problem.
• Explore different architectural and deployment models. Re-using services from one application in another involves solving technical problems: we need to design the applications in a particular way to be able to achieve this re-use. We would like to forget the technical detail and concentrate on the code that “makes us money”.

How does Cake Solutions fit in

We are experts in the dm Server development and deployment. We can help you evaluate the benefits you may gain from moving to the dm Server; we can also help your development write applications for the new OSGi world.

We gave a talk on migrating Java EE web application to the dm Server at the Spring in Finance Exchange conference and we are writing a book on dm Server — dm Server in Action — to be published in March next year by Manning.

Learn more

The dm Server is an exciting new platform. The first version gives us a glimpse of the future enhancements and features. We will keep this page updated with our latest insights and tutorials on the dm Server.

If you are keen to learn more, keep an eye on the cakesolutions channel on YouTube.

Blogs