Geertjan is a DZone Zone Leader and has posted 466 posts at DZone. You can read more from them at their website. View Full User Profile

Interview: Keeping Track of Deployed Artifacts Over Time

11.30.2009
| 7063 views |
  • submit to reddit
Marcel Offermans is a software architect at Luminis, a Dutch IT company made up of independent divisions with their own expertise. Marcel works for Luminis Technologies, the international technology and support division, where innovative open source based software is developed, distributed and supported, enabling organisations and developers to exploit the full potential of an interconnected, interoperable world.

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.

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Jeff Mcaffer replied on Mon, 2009/11/30 - 6:56pm

Thanks for the interview Marcel. Good stuff. I would like to comment on the characterization of p2 as somehow not being (for) "pure OSGi" or embedded. I've no idea what "pure OSGi" means in this (or any) context but I can say that p2 was designed from the beginning with an eye firmly on OSGi usecases. If you mean that p2 is not limited to just OSGi then I would wholeheartedly agree :-) p2 is a provisioning platform designed to manage generic metadata and artifacts, and instantiated for OSGi and Eclipse-based systems. While it is true that p2 is used by millions of people to manage their Eclipse IDEs and RCP applications, that is just one example of p2 use. At EclipseSource we work with people who use p2 to manage remote heavy equipment (embedded), firmware distribution (mobile), as well as web services, folks who are installing RPMs, MSIs, tweaking registry entries, delivering native apps, ... You know, all the stuff that real systems are made of. That's why we made a provisioning platform rather than a provisioning solution--everyone's provisioning problem is different. Anyway, I don't mean to quibble as I quite like that you are doing Ace (gotta love competition and new ideas) but I don't want people to get the wrong idea about p2.

Marcel Offermans replied on Mon, 2009/11/30 - 7:55pm in response to: Jeff Mcaffer

Thanks for clarifying that Jeff, it was not my intention to misrepresent p2. Most of what I wrote about it was my interpretation of what I found on the wiki pages that introduce it (which seem to mention Eclipse and RCP more than they do OSGi). I agree with you that any provisioning solution should not be limited to "just OSGi" and it's good to see that both systems have solutions to extend them.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.