(mOSAIC) Packages


Big picture

Each organization, team, or individual developer -- that we shall call from now on just "developer" -- that wants to deploy an application is required to host one or multiple mOSAIC package repositories. (This has been greatly inspired by Java's Maven artifacts.)

Packages are nothing else than a group of files organized into directories, and maybe some accompanying meta-data. The packages can be of many types, like for example:

Each package is identified by the following coordinates (again inspired by Maven):

There are always at least two related package repositories (as inspired by DVCS tools like Git or Mercurial):

The packages are imported, and pushed into repositories by the usage of a custom mOSAIC tool, which we'll describe shortly, but the repositories are accessed by all the other tools (like for example the deployer) as either:

The frontend tool

Similar with Git or Mercurial there is only one tool which has multiple sub commands used to manage the local repository and push to the remote one. For example:

Security consideration

The security concerns are twofold: confidentiality and access control.

The confidentiality is solved by employing TLS at the transport layer, thus no further discussions are needed.

Access control is again split in two: authentication and authorization. Authentication is solved by either employing X.509 certificates, or just in the case of the HTTP access of packages through "secret" tokens that can be transmitted to trusted parties. The authorization is done at repository level, with only two rights: read of any packages stored within, or write in a similar manner.