OSGi Enterprise Management Suite

For almost 10 years, ProSyst is actively involved in the OSGi standardization process and focused on offering products and services around the OSGi technology. Our flag ship products are mBedded Server, and highly optimized OSGi framework implementation for embedded systems, and mPower Remote Manager (mPRM), a remote management system for OSGi-based system. The mPRM is used in a variety of deployments and is probably managing thousands and thousands of OSGi container by now.

Around 3 years ago, Java enterprise vendors got interested in OSGi. As a result of this, the OSGi enterprise expert group was created (EEG) and for the last 2 years I've had the pleasure to participate in this group. Furthermore, I got the chance to join and lead ProSyst's enterprise team to adopt the successful mPRM system to OSGi enterprise requirements. Java developers and architects quickly adopted the OSGi technology (server as well as applications) and started to profit from OSGi. While this improves the application's runtime and design, OSGi also brings enhanced remote server and application management features. Multi version support, dynamic updates and fine-grained management are well-known strengths of OSGi.

Our enterprise team worked hard in the last 2 years and I am proud to say that we finally finished the development and are about to release the "OSGi Enterprise Management Suite" (EMS). EMS is based on mPRM and focuses on enterprise OSGi requirements and use cases. Unlike our application stack for embedded environments, EMS focuses on managing Apache Felix and Eclipse Equinox based runtimes. Nevertheless, EMS is framework agnostic and will work with any OSGi 4.1 compliant implementation.

The key use case for EMS is remote server and application management. Let's say you finished your OSGi-based web application that you now want to bring into production. Even though the initial deployment might be easy, controlling the running application and using OSGi's fine-grained management abilities requires a sophisticated managed system. Another scenario is where you have dozens of deployments at e.g. customer side and want to update certain modules for important security bugfixes. Doing this by hand with in a remote shell is clearly not an option. EMS fulfills these needs by providing a central managing system. Some of my favorite features are:

• Bundle management
  Typical bundle install/update/remove operations.
  
  
• Multi-server management
  Install bundles on hundreds of servers in one operation. Useful for e.g. SOA and grid deployments. EMS will align the operation with each server individually.
  
  
• Software repository
  EMS has its own software repository used to store bundle artifacts. EMS will use the repository and it's metadata for proper dependency management. Maven user can directly import their Maven artifacts (specified in a POM, including transitive dependencies, support for Maven repositories) into the repository.
  
  
• Snapshots
  Whenever the server state changes (e.g. bundles), EMS will store a copy of the new state. This allows "roll backs" of e.g. faulty deployments even weeks after the deployment happend.
  

• Logging
  EMS will collect all log messages on the server and transfer to them to the central EMS system. Support for e.g. OSGi LogService, log4j, commons logging, Java Logging
  

• JMX representation
  EMS will register JMX MBeans in the managed server to present the OSGi state for JMX clients (e.g. Hyperic)
  

• Configuration
  Front-end for Configuration Admin
  

• Web UI frontend

Screenshot:


We will officially announce EMS in the next couple of weeks. However, I just wanted to share this information with you already today! Please feel free to contact me (r.roelofsen at prosyst.com) if you want to get more information! We also have a online evaluation version running if you want to give it a try!

Zen of OSGi

Even though my favorite languages are Scala and Java (yes, Scala comes first ;-) ), I used to use the Python programming language quite a lot. Python has some very well thought out design elements and programming patterns. The Python community actively communicates these patterns and continues to promote their use. As a result of this, the Zen of Python (http://www.python.org/dev/peps/pep-0020/) was created to capture them in a jokey, but still useful way. There is even an easter egg in the Python interpreter (hint: "import this").

While beeing a platform technology in its core, the OSGi technology seems to use and promote certain patterns as well. The Whiteboard and Extender pattern are well-known examples for this. So why shouldn't we put these patterns in a more jokey and useful way?

Zen of OSGi

1. Graphs are better than trees.
2. Prefer services over objects.
3. Import is better than required.
4. Although required is better than classpath.
5. Only export stuff you want to provide support for.
6. Once you support something, support it forever.
7. Import your exports.
8. Minimise your dependencies.
9. But do not omit imports you really use.
10. Do not rely on start ordering.
11. Listen to your customer, do not make them listen to you.
12. Communicate your version policy.
13. Be as permissive as possible but no more.
14. Use the obvious OSGi way.
15. Although that way may not be obvious at first unless you're Dutch.
16. Expect the unexpected (especially when you are dealing with services).
    

You can even discover some interesting similarities between these two Zens.

Any important rules missing?