Interview: Keeping Track of Deployed Artifacts Over Time
Interview: Keeping Track of Deployed Artifacts Over Time
Join the DZone community and get the full member experience.Join For Free
Furthermore, Marcel is a committer at Apache ACE and Apache Felix. For the past 8 years he has been involved in many different OSGi related projects, ranging from embedded to enterprise systems.
Hi Marcel. What is Apache ACE in a nutshell?
Apache ACE is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. It is built using OSGi and can be deployed in different topologies. The target systems are usually also OSGi based, but don't have to be.
When assembling software out of reusable components, the task of deploying software onto an ever increasing number of targets is not trivial to solve. This becomes even harder when these targets require different components based on who's using them. Apache ACE allows you to group those components and assign them to a managed set of targets. This allows you to distribute updates and new components easily, while keeping a full history of what was installed where during what period. It also helps you setup an automated development, QA/testing, staging and production environment.
What are its origins and how does it relate to Luminis?
At Luminis we have over 8 years of experience developing OSGi based applications. In our first big commercial project we were involved with an embedded machine that had modular hardware that the software had to adapt to, which made it a very natural fit for OSGi. At that time, we were very much pioneering the technology, and I remember we initially used an OSGi implementation written by Sun called the Java Embedded Server. After using that for a while and being part of their beta program, I discovered a SourceForge project called Oscar, and even though it did not implement the full specification back then, I tried it with the bundles we developed and it worked just fine.
Already during this first project, we saw the need for an automated system to deploy bundles and other artifacts, so we started an in-house research project to come up with one. Over the years we added new requirements, improved the design and deployed the system in various places. About a year ago, we decided to open source the system and donate it to Apache as Apache ACE, because we realized that there were so many different ideas and directions to develop this system into, that we simply did not have the time to explore them all. Furthermore, a system like this is so fundamentally useful for everybody deploying component based applications that we felt it would attract a good user and developer community.
To visualize this, here is the Apache ACE web user interface (click to enlarge it):
Can you name 3 specific scenarios where I would use it?
The generic use case is any scenario where you are deploying artifacts to target systems and you want to keep track of that over time.
Specific scenarios where this is the case are:
- When you have embedded or mobile applications that you want to update from a central location, because either they have no user interface or you do not want to bother the user with manual installations or updates. A special case of this scenario that we support is the off-line scenario, where we support updating targets that are never in direct contact with the network. In this case, you can use a so called relay system that can easily run on a laptop or even mobile phone, and take that with you to the target you want to update. Once you're there, you can hook it up locally and it will be updated automatically.
- When you have an application for which plugins are available. You can make these plugins available through a website or extension to your applications user interface and have the user select the ones he or she wants to install. Plugins can be made up out of multiple components, which gives them an advantage over a system that simply exposes the OSGi internals and allows the user control over individual bundles.
- When you have an application that is deployed to a cluster, and you need to update all nodes in the cluster simultaneously or in some defined sequence. Here the central coordination of a central server can really help you, and the built in transactional updates of targets make sure that either updates get installed completely or not at all.
What are its competitors and how does it compare?
Equinox/p2, which is a component of the Equinox project. p2 provides a provisioning platform for Eclipse-based applications. p2 replaces Update Manager as a mechanism for managing your Eclipse install, searching for updates, and installing new functionality. It's hard to compare the two systems in just a couple of sentences, but its probably fair to say that ACE focusses on pure OSGi and can be used for really small embedded or mobile targets, where p2 focusses more on Eclipse RCP, so rich desktops and server systems. That being said, there is definitely some overlap in what these systems do.
Going back in history a bit, I remember a short talk I had with Jeff McAffer at JavaOne years ago where we briefly talked about provisioning. At that point in time we were already developing what has now become ACE when Jeff told me Eclipse were starting a project on that too. In the end I think it's good to have choice and drive innovation that way.
What are some future developments you're planning?
As an Apache project, we are driven by the contributions of the committers, so we do not have a fixed roadmap. That being said, there are a couple of things we're currently discussing.
- Java EE support, which is something that might be donated from AutoDeploy, and that can be integrated through the extensible mechanism we have for adding new file types to the deployment system. This allows us to deploy EARs, WARs and EJB-jars, configuration data and SQL scripts to create or modify database schemas.
- Mobile platform support, which is something we have been pioneering at Luminis for the Android platform and has resulted into Apache Felix running on Android out of the box. Combine Android with OSGi and you have a lot of capabilities to dynamically install and update components based on for example your location. In fact, we have setup a website some time ago to focus these efforts called EZDroid (see http://ezdroid.com/ for more info).
- Other things we're looking at are support for Spring DM and the corresponding blueprint services, Apache Felix Karaf feature support, Nexus integration and support for deploying components directly from within a local developer build or continuous integration environment.
We would also love people to help us out with support for other targets, such as RIA's like Flash and JavaFX.
Opinions expressed by DZone contributors are their own.