Mediaserver core module
Restful-API -> documentation according to apiary.
The Mediaserver (aka. 'attachment server') handles media files and their metadata.
The functionality is implemented using the RESTful-architecture style
- The Mediaserver can be used as a standalone server (no coupling to an external system).
- The Mediaserver can be used as an integrated part of the collections management system (coupled).
The Mediaservers has the basic CRUD responsibilities:
- Storing : Storing binaries to the filesystem and Storing the metadata to a database.
- Retrieving: Retrieving the binaries and retrieving the metadata for the binaries.
- Update: Updating the binaries and updating the metadata for the binaries.
- Delete: Deleting the binaries and updating the metadata for the binaries.
- The Mediaserver stores the binary-files to the local file system, to the file system where the Mediaserver is installed.
The Mediaserver should provide services for other systems.
- To store media files (Create)
- To edit media files (Update)
- To search on metadata, fetch mediafiles (Retrieve)
- To delete media files (Delete)
The mediafiles are stored in the filesystem, which has a depth of 3 levels. Only one mediafile is stored, no derivates for images are created at the same time.
All medifiles are stored using UUID as names.
UUID, " Universally unique identifier, 128-bit number." ( http://tools.ietf.org/html/rfc4122)
The directories range from '0' to 'F' (hexadecimal) with a depth of 3 layers, which results in 4096 directories ( 16^3 ). To illustrate, 10 000 000 (ten million) mediafiles would be, with an even spread, would be divided into 2441 mediafiles per directory.
All media files are processed in the same way - they are streamed to the filesystem and streamed back to their client.
The mediafile will hold their own 'media-type'/'mime-type' ( stored in the database )
- The principle is the following :
-
- if the generated UUID is 'ab30899c-58a0-4305-85a6-bbfa14f89b92'
- Then the file is stored in the following directory ( subdirectory is made up by the first 3 chars ):
-
- directory = /opt/data/mediaserver/newmedia/a/b/3
-
- directory and file = /opt/data/mediaserver/newmedia/a/b/3/ab30899c-58a0-4305-85a6-bbfa14f89b92
The terms “metadata" and “tags” are distinguished in the following way:
- 'metadata' are immuatable, data about the file.
- 'tags’ are mutable, data about the file content.
- original filename
- mime type
- owner
- visibility (i.e 'private' or ‘public')
- md5hash
- Saving the md5hash for every media file facilitates finding duplicates.
- Exif-metadata Exif-metadata for media files where type is an image are stored in a separate table.
- Exif-metadata is stored in a table of its own.
- there is a configurable Boolean parameter in the database, this parameter is a flag set to 'true' or 'false'.
The Mediaserver sets no constraint on the keys that are used.
This gives an external module using the Mediaserver freedom to define its own keys and constrain others keys.
Generics tags are supported and saved as a text-string in the database.
- ':' is used as the delimiter between key and its value.
- '&' is used as the delimiter between key/value-pairs
i.e setting key='country' with value='sweden' and key='view' with value='dorsal'.
is saved as -> 'country:sweden&value=dorsal'
The Mediaserver is database- and application server agnostic.
The guiding principle is 'ease of installation and management'.
base url (default) : http://localhost:8080/MediaServerResteasy/
If all goes well: the server returns a UUID
The log from the wildfly-server : class se.nrm.bio.mediaserver.rs.MediaResourceForm
00:42:13,996 INFO [se.nrm.bio.mediaserver.rs.MediaResourceForm] (default task-3) in POST -> /load using multiform
00:42:14,005 INFO [se.nrm.bio.mediaserver.rs.MediaResourceForm] (default task-3) writing to file /opt/data/media/9/f/e/9fe963f5-0125-45e3-bec1-23885031e952
directory: docs/demo-data
BASE_URL="http://localhost:8080/MediaServerResteasy/media"
echo "Base URL is " $BASE_URL
curl -H "Accept: application/json" -H "Content-type: application/json" -X POST -d @corvuxcorax.b64 $BASE_URL | json_pp
The log from the wildfly-server : class se.nrm.bio.mediaserver.rs.MediaResourceForm
00:51:45,691 INFO [se.nrm.bio.mediaserver.rs.MediaResourceForm] (default task-4) in POST -> /media using multiform
'turn-key' docker-project at dw-media
'turn-key' docker-project at media-docker
- git clone
- install and populate the chosen database-engine, use the liquibase-script
- install the Application server (AS), Wildfly 8.x
- Set up a datasource/datapool/JNDI-handle ( JNDI: java:/MediaDS), same JNDI-name as in the persistence.xml
- set up the filesystem-path for the media files
- cd '/mediaserver-module' ( root pom ) :
- prompt>mvn clean package wildfly:deploy
### NB: if you fail on setting up the datasource you will get the following error
* [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.2.Final:deploy (default-cli) on project mediaserver-ear: *
same info here: https://gist.github.com/Inkimar/d81639a9cd41e96903bfbaa9d07decff
- mysql module
- eclipse module https://docs.jboss.org/author/display/WFLY8/JPA+Reference+Guide#JPAReferenceGuide-UsingEclipseLink
A link-table in the database maps the ID from the external system to one or many media files.
Documentation according to apiary
- @POST mediafile
- @GET the metadata of the mediafile
- @GET the mediafile itself
- @GET a derivate of an image-file ( i.e : height = 150)
- @UPDATE the mediafile
- @DELETE the mediafile
Licenses are stored in a separate license-table
This gives the administrator full control of what licenses are permitted in the system.
The database table ADMIN_CONFIG A table ( key/value) in the schema is used for managing settables :
For instance the below ( key/value ) is set in the database.
- is_exif = [true||false]
- path_to_files = '/opt/data/mediaserver/newmedia'
example to increase the possibility to post 4.2GB
- /opt/jboss/wildfly/bin/jboss-cli.sh
- [standalone@localhost:9990 /] connect
- [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=4200000000)
- [standalone@localhost:9990 /] :reload
- verify
- [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:read-attribute(name=max-post-size)