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.
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.
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)
Front-end for Configuration Admin
- Web UI frontend
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 p