Plugin Layer

The Plugin Layer has the purpose to provide an interface to interact with dynamically added datasinks, datasources and actions.

Interface

The project org.backmeup.plugin contains the interface Plugin with following operations:

• retrieve all available datasources, datasinks and actions,
• access the authorization mechanism of a certain datasource / datasink,
• download data from a datasource,
• upload data to a datasink.

Following operations must be added:

• execute necessary actions before uploading to a sink.

Implementation

The project org.backmeup.plugin.osgi.impl contains the [OSGi] (http://www.osgi.org/Main/HomePage)-implementation of the plugin layer. The layer uses [Apache Felix] (http://felix.apache.org/site/index.html) as OSGi implementation which will start / stop all OSGi bundles. After startup a thread will be created (within the class DeployMonitor) which will automatically start and stop bundles found within the deplomyenDirectory.

When the business layer gets an service instance from an OSGi-bundle, a proxy is generated which will do the actual work. First the plugin layer gets a ServiceReference to a specific class or interface. To achieve this a filter will be used. Note that a plugin creator has to specify the filter name with the value as returned by the bundles descriptor Describable.getId().

E. g. the dropbox plugin is called org.backmeup.dropbox and has an OSGi-service which implements the Describable interface, returning org.backmeup.dropbox when calling getId():

public class DropboxDescriptor implements SourceSinkDescribable {
  @Override
  public String getId() {
    return "org.backmeup.dropbox";
  }
  ...
}

Within the service configuration the filter name will be specified with the value org.backmeup.dropbox:

<service id="dropboxDescriptorService" ref="dropboxDescriptor" auto-export="interfaces">
  <service-properties>
    <!-- specifying the filter here -->
    <entry key="name" value="org.backmeup.dropbox"/>
  </service-properties>
</service>

All other services of this plugin require the same filter. Otherwise the plugin layer cannot find the services.

After that a proxy will be generated which gets this ServiceReference passed as an argument. A call to a method of the proxy (e.g. Datasource.downloadAll) will result in following operations:

1. Find the OSGi-service by its reference.
2. Invoke the method downloadAll of this service and pass all parameters.
3. Finally release the service-instance.

This workflow requires that an OSGi-bundle MUST BE STATELESS. Always pass all required data as a method parameter!

Configuration

The configuration of this layer can be performed within the file plugin.properties (currently within the folder org.backmeup.embedded/src/main/resources/). Following things can be adjusted:

• osgi.deploymentDirectory: The folder where all OSGi-bundles will be started from. Whenever you add a new bundle to this folder or remove an exsisting one, it will be automatically loaded/unloaded by Felix. Default autodeploy.
• osgi.temporaryDirectory: The temporary folder for OSGi. Default osgiTmp.
• osgi.exportedPackages: Packages that will be used by OSGi and by other layers of the project must be within the classpath of the application and available as OSGi-bundle. Apache Felix will delegate these classes to the parent class loader so that there will be no problem executing methods of an OSGi-service from outside of OSGi. If a class is not exported and the business layer calls a method on an OSGi-service, an IllegalArgumentException will be thrown with following hint: object is not an instance of declaring class. Fix the problem by adding the pacakge of this class to the osgi.exportedPacakges property. Default org.backmeup.plugin.spi org.backmeup.model org.backmeup.model.spi org.backmeup.plugin.api.connectors org.backmeup.plugin.api.storage