Skip to content
David Fischer edited this page Oct 20, 2013 · 4 revisions

Architecture

The application is composed of charms deployable with JuJu the cloud orchestrator.

|component_application|

The architecture of the platform

Here are the charms developed for this application:

Charm Short description (services and goals) Provides Requires
WebUI Provides a web based interface for the users of the platform (e.g. broadcasters) website storage api
Orchestra Provides the RESTful API and handles the DB & tasks scheduling (the brain) api transform publisher storage
Transform Handles media encoding tasks to transform medias from/to various formats (nothing) storage transform
Publisher Handles media publication tasks to make medias available for the audience (nothing) storage publisher
Storage Provides a shared medias storage mounted by other components of the application storage (nothing)

The provides and requires columns are the name of the relations required or provided by the charm.

|components_2|

Purpose of the relations between components of OSCIED

Here are the relations :

Relation Interface Provider side Requirer side
api orchestra Send RESTful API url Update config. with RESTful API url
website http Update config. & add proxy to white list Enable HTTP redirection
transform subordinate Send database & message broker connections Update config. & connect to broker
publisher subordinate Send database & message broker connections Update config. & connect to broker
storage mount Send parameters required to mount the storage Update config. & mount the storage

Remark: Don't panic, they are only the required credentials to access to tasks related database !

The application's charms can be connected to charms of the Store thanks to the nice contributors behind every of the charms. For example, one can imagine to plug Nginx charm in front of (e.g. 5x) publication points and closer to the user to reduce load and network traffic of back-end distribution points !

As you can imagine, next diagram will be a little bit more complicated, as it enter into charms to show you the open-source tools used internally by them.

|component_application_inside|

Charms of the project including involved sub-components

The charm's hooks (Python scripts) are represented by hooks<X> and the service's implementation (Python source-code) is represented by code<X>.

Clone this wiki locally