SMILA/Project Concepts/Binary Storage

Overview

Design a service to easy store / access binary data documents.

Description

Client components will access the Binary Storage Service for persisting binary data (attachments) into the binary storage. The binary data shall be simply identified by a unique key / identifier as a String data type. No directely client component access to the persistence storage shall be available; the persistence storage will be only accessible through the Binary Storage Service API which provides the needed CRUD operations.

Backend mechanism of Binary Storage shall be completely transperent to the client, thus user shall have the oppurtinity to setup basic configuration of the service. Binary Storage shall be able to determine and use default/optimistic configuration in case no one is specified by the user.

Storage Mechanism. Internal Structure.

Binary Storage will depend on the amount of data it needs to persist/manage. Because of this the persistence storage of service shall be able to deal with fallowing persistence structures/techniques, depending on service configuration:

• A. File System
  • I. Local hard drive
    • 1. Flat file system structure
    • 2. Hierarchical file system structure
  • II. Distributed file system (SFTP, FTP)
• B. Object DataBase

Technical aspects for designing the Binary Storage Service

• The file system will be used as physical storage
• The Apache Commons Virtual File System (Commons VFS) framework is to be used for accessing the file system.
• For performance improvement (in case of ) the binary storage shall be hierarchically/tree organized; and not flat
• Binary storage shall internally manage its persistence hierarchy
• The binary service shall be designed as a single bundle / service. Main reason for doing this is that there is only one “client”, the Blackboard service
• Exception handling mechanism should treat all internal binary storage (logical and unexpected) errors and wrap the exceptions into a “binary storage exception” that makes sense for the Blackboard service
• Resources synchronization shall be done at the lowest possible level
• Binary Storage shall manage its configuration internally (highly couple classes are difficult to maintain and hard to understand in isolation – they tend to introduce internal dependencies). Decouple binary storage configuration from blackboard service

• The Binary Storage Service API shall stay as simple as possible

Current Binary Storage Service

Current implementation of Binary Storage is designed in five bundles, where the org.eclipse.eilf.binstorage(.impl) bundle acts as “service factory” for the Blackboard service, providing the files-service, configuration and file-content services.

Current Binstorage class diagram:

Current implementation is deprecated and it will be soon changed.