The platform approach has been a major boost for the success of Eclipse. This is mainly due to two key attributes:

1. Eclipse uses an OSGi Runtime (Equinox) which allows platform components to be added, removed or updated. Major advantages compared to traditional Java libraries are improved control mechanisms for dependencies between components, release versioning and the component lifecycle within the OSGi container.
2. The Extension Point Registry: This allows a formal definition of components that can be processed in an application. An interface implemented as an extension point schema is created that enables any developer to contribute and expand it.

These two characteristics will come in handy when we start implementing the example application.
Information units may be bunched together as OSGi bundles and then remotely installed in the application as OSGi bundles. These bundles only contain raw content and application-specific structural descriptions for identifying the content and integrating it in the application context. Identification is accomplished via the extension registry, which essentially means that these content bundles contain extension points with information enabling the application to read the data and make it available to the user.

There are three tremendous benefits to this approach:

1. The bundle lifecycle is the same as the application-specific content lifecycle. In other words, the state of my application-specific data is mapped to that of installed bundles. The OSGi Runtime functionality is also used for installing, uninstalling and updating applications. In addition, content dependencies can be defined at OSGi level.
2. By using extension points to describe information units, you can leverage the advantages of a highly flexible fully implemented “standard” that enables the access as well as the representation and processing of these information units. Implementation efforts remain only minimal.
3. The PDE with its tools for bundle (plug-in) creation provides a complete environment for the creation of new content units. In order to implement this function, the PDE just needs to be supplemented by a content-specific layer.

Example

Ok, let’s cut a long story short. How can this be demonstrated? – We want to create an RCP application for a centralized approach to PDF document distribution as the end point. These PDFs will be visualized in the application for users and tagged with metadata allowing the data to be put in the context of the process currently employed by the user. Although the PDFs will be read-only files, users will be able to create further data associated with the provided files and distribute them. We have also envisioned a basic collaboration tool on the information level.

Outlook

In the next sequel we will get started on the actual implementation. We will start off by generating a model reflecting the requirements, which will be done using the EMF. Then we will go on to create an extension point for PDF documents.

We will also discuss some aspects concerning a specific use case, e.g. information units refer to PDF documents and additional data which can be associated with PDF files. Let me just point out that this will be a simplified implementation.

Stay tuned.