Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SMILA/Project Concepts/Binary Storage
Contents
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 structure
- 2. Hierarchical structure
- II. Distributed file system (SFTP, FTP)
- I. Local hard drive
- B. Object DataBase
File:2.SMILA-BinaryStorage-HighLevel.jpg
A. File System
I. Local hard drive
1. Flat structure
2. Hierarchical 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.