Page tree
Skip to end of metadata
Go to start of metadata

Membrane is Data Federation as a RESTful service, based on Apache MetaModel.

Project status

The project was just recently accepted as a subproject of Apache MetaModel.

Our first release, version 0.1, is out! Check out our Docker Hub page for easy-to-use set up steps.

Project information

WhatWhere
Git repostoryhttps://git-wip-us.apache.org/repos/asf/metamodel-membrane.git
GitHub mirrorhttps://github.com/apache/metamodel-membrane
Mailing listsSame as Apache MetaModel
IssuesSame as Apache MetaModel (JIRA)
Docker imagehttps://hub.docker.com/r/apache/metamodel-membrane

Core concepts

Tenant

A "tenant" in Membrane can be used traditionally as a tenant in a multi-tenant system, where each tenant of the system essentially has his own workspace.

Tenants can also be seen simply as a logical grouping of data sources (see below).

Data source

A "data source" in Membrane is the data that defines a connection to a datastore such as a JDBC database, a file or something else.

Data sources are configured using key/value properties. For example:

{
"type": "csv",
"resource": "/path/to/file.csv",
"quote-char": "\"",
"separator-char": ";",
"escape-char": "\\",
"encoding": "UTF-8"
}
or
{
  "type": "jdbc",
  "url": "jdbc:postgresql://localhost:5432/mydb"
  "username": "johndoe",
  "password": "secret"
}

Security in Membrane

Currently Membrane does not attempt to implement its own security layer. Rather it leans on RESTful principles which would make it easy for you to define a secure HTTP proxy as a security gateway for the service.

Essentially a security gateway could be implemented based on HTTP path and method, like this:

  • Consider access rights based on the tenant name.
    • Assign each user to one or more tenants.
    • First part of the path is the tenant name, so validate access rights based on that.
  • Consider permissions based on the HTTP method
    • GET is for "read" access.
    • PUT, POST, DELETE is for "write" access.

 

  • No labels