You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Note: requirement for CyberSEES project

  • Access control: for example, there are LIDAR data from municipality and they don't want to share the data outside of the project.

This is the page to describe how to integrate Medici 2 and DataWolf with supporting IRODS. Through this integration/refactoring, we will achieve

  • DataWolf will use Medici 2 as Dataset storage.
    • But, the design/refactoring will allow for DataWolf to store workflows in Medici 2
  • Medici 2 will use IRODS as file storage
    • Medici 2 currently has two implementation for file storage: MongoDB GridFS and local file system
    • It is possible for us to store the part of the meatadata of datasets/files to IRODS, too. But it is a low priority and can be done later

Implementing IROD data storage in Medici 2

Medici 2 has the file storage API. It has two implementations: local file system and mongoDB GridFS. We need to have an implementation for IRODS. Since DataWolf already has an IRODS implementation for file storage using the IRODS java client library, Jargon, this can be leveraged for the Medici implementation.  

Refactoring DataWolf to use Medici 2 as dataset storage

In order for DataWolf to use Medici 2 as dataset storage, the following tasks needs to be done

Researching on Spring Data vs Guice

Regarding eclipse (OSGI) support and properties configuration support.

 

 

Separating the service layer and implementations

  • Remove current JPA annotation from beans (separating spring data specifics)
    • workflow, workflow step
    • workflowtool
    • dataset
    • file
  • Defining service API as abstract supporting (DAO -> service and implementation)
    • CRUD and extra capability (save, load, remove, update etc)
  • Implementation layer for each service
    • JPA  (without annotation in the bean but with xml definition)
    • Mongo
    • Medici 2

 

  • No labels