This page last changed on Sep 30, 2011 by bbranan.

Introduction

This document is intended to provide guidelines for developing your own custom services that can be deployed into the DuraCloud services framework.
The framework has been designed to allow any Java code that can be deployed as an OSGi bundle and implements the ComputeService interface to be dynamically installable into a running DuraCloud application instance.

Overview

In order to understand the flow of services within the services framework, there are several entities with which to become familiar:

  1. DuraService
    • web application that exposes a REST-API for end-user management of services
      1. deploy service
      2. undeploy service
      3. configure service
      4. get service listing
      5. get service properties
    • responsible for retrieving a service to be deployed from the Service Registry and streaming it to the ServicesAdmin
    • responsible for mediating subsequent end-user management of deployed services to ServicesAdmin
    • responsible for passing service configuration to the OSGi container when a service is being deployed. 
      • service configuration is defined in the service-repo.xml which is built based on the ServiceInfo class for each service
  2. Service Registry
    • persistent holding area of deployable services
    • contains Service Packages and a single services-configuration descriptor XML object
    • implemented as one or more DuraCloud "space(s)"
      • the properties file to initialize DuraCloud contains duraservice.service-storage properties which allow configuration of the host, port, context and space
  3. Service Package
    • for simple services, this can be a single OSGi bundle, jar file
    • for more involved services, this would be a zip file containing
      1. OSGi bundle jar that implements the ComputeService interface
      2. OSGi bundle jars that are both dependencies of the ComputeService bundle (above) and not among the base bundles installed in the OSGi Container by default
      3. any support files (see 'Example Services' below)
  4. ServicesAdmin
    • management component resident in the OSGi container
    • exposes an internal REST-API through which communication from DuraService takes place
    • responsible for actually communicating with services via their common ComputeService interfaces
    • responsible for keeping track of currently deployed services and dependency-link counters
  5. OSGi Container

Example Services

All of the below services are currently functional and available in the DuraCloud source baseline.
They can all be found within the services directory

Pure Java Services
  1. Hello Service
  2. Replication Service
  3. WebAppUtil Service
  4. ImageConversion Service
  5. MediaStreaming Service
Web Application Services
  1. HelloWebAppWrapper Service
  2. J2K Service
System Services
  1. Script Service
  2. ImageMagick Service

Implementation Guidelines

This portion is still under construction.
OSGi Compatibility
  • Although there are several available OSGi containers, and the DuraCloud test harnesses employ Equinox, Felix, and Knoplerfish, the production container into which services need to be able to deploy is Equinox.
ComputeService Interface
Dependency Packaging
Service Descriptor
Document generated by Confluence on Oct 31, 2011 13:49