The COGNITUS platform is built on a service-oriented architecture, consisting of several video and audio enhancement components, semantic analysis and quality assessment tools, as well as flow management and storage solutions. The heterogeneous nature of these components (regarding implementation technologies, inter-communication, timing etc.) and the need for high efficiency, led to a modular and decoupled architecture, easily scalable to address the high demands of uploading and enhancing the contributed User Generated Content (UGC). The components comprising the COGNITUS platform can be logically grouped into five functional categories: (i) Core components, (ii) Data management, (iii) Processing, (iv) Content streaming, and (v) User applications.
COGNITUS users’ applications
A basic objective of COGNITUS is to provide the necessary functionality to enable the voluntary contribution of User Generated Videos (UGV), captured by users that have participated in public events (e.g., festivals, sport games, etc.). The gathered content is enhanced and transposed to UHD videos, which are then made available to professionals. Using the COGNITUS platform, professionals can find and combine the high quality versions of the available UGV into a single plot, which is related to an event, and then make it available for broadcasting. COGNITUS users can upload their videos to the platform using the mobile application that has been implemented. For each UGV that is uploaded to the COGNITUS platform, a processing, editing and delivering process workflow is engaged towards the creation of new professional content, as well as the enhancement of the video and its delivery back to the end-users, through a diversity of devices, such as set-top boxes (STB), tablets, or mobiles. The COGNITUS applications are significant for the project, since they constitute the basic interface between the users and the platform.
COGNITUS core components
The architecture of the COGNITUS platform is based on a service-oriented model, utilizing services (COGNITUS components) as fundamental elements. This approach requires the existence of fundamental functionality, which provides the necessary coordination, monitoring, conformance and Quality of Service (QoS) assurance of the system. Additionally, the heterogeneous nature (in terms of the runtime environment and programming language of implementation) of the components founding the platform raises the need for a decoupled architectural model towards a service-oriented management. Communication between the components should occur seamlessly and in an efficient way via a common communication channel. The coordination part of the COGNITUS architecture addresses such concerns by introducing a set of fundamental components that shape the command and control centre of the platform.
Communication & orchestration
The modular architecture of COGNITUS entails the distribution of functionalities among a number of services, each one having particular responsibilities. This results in an organisational context that is more agile, allows faster development and efficiency in performance. Following the service orchestration paradigm in the context of Service-oriented Architecture (SoA), an entity (in this case named the ‘coordinator’), is responsible for invoking and combining the services, just like a real-life orchestrator managing his orchestra.
Therefore, the COGNITUS coordinator is introduced as a core component responsible for coordinating the interoperation among the other services. In specific, the COGNITUS coordinator triggers asynchronously, on an event-based manner, the execution of the COGNITUS components, one by one or in parallel, in order to accomplish specific tasks towards completing a system-wide task all together. The communication between the coordinator and the service components is achieved by utilizing a message broker for the task dispatching. The event-based nature of the communication between the components enables fast distribution of tasks, maintaining at the same time high efficiency on the coordinator.Message Broker, read more...
In addition to this decoupling approach, the utilisation of queues supports the scalability, reliability and efficiency features of the platform. New instances of processing components can be deployed on demand and start accomplishing tasks, by simply registering to the respective queue. In case that an instance of a service worker stops working while trying to complete a given task, the queue is smart enough to revert the task back to the queue so as to be consumed by another service worker.
For COGNITUS RabbitMQ (https://www.rabbitmq.com), a mature, open-source solution offering client libraries for almost any programming language, is utilized to serve as the message broker. RabbitMQ implements the AMQP protocol, thus providing a common platform to services for their message-driven communication. Also, facilitates the work queues required for the task dispatching in the context of COGNITUS.
COGNITUS has been created as an exploitation-ready product that should be easily deployed in a production environment. Towards this, several architectural aspects have been considered:
Components isolation and self-containment
Since many COGNITUS components need to work simultaneously, performing critical processing to meet the goals of the platform, it is important to ensure that all these components work reliably without being disrupted by other components. On the functional architecture level, this has been addressed through the COGNITUS coordinator and the message broker (RabbitMQ) components, which distribute and dispatch the work to the relevant components’ instances that run isolated from the other components. However, isolation must be addressed on the deployment level too, in order to continue ensuring that a potential component’s runtime malfunction will not affect other components and that resources continue to be shared and managed efficiently.
In addition, COGNITUS is a platform consisting of multiple heterogeneous components undertaking small pieces of work towards fulfilling the goals of the project. The deployment of such a platform raises great challenges as each component requires specific environment and libraries to run. To eliminate such constraints, the design of the deployment architecture has focused on service isolation and self-containment. According to this approach, any component can be deployed using the environment and configuration that best fits its needs, without having any software dependency conflicts with other services.Containerization approach, read more...
Currently there are many solutions that automate handling of containers, turning the management and deployment of software into a trivial task. In the context of COGNITUS, Docker (https://www.docker.com), one of the most significant solutions, has been employed. Docker is an open-source project, providing tools to support developers to create software and share their development environment, as well as system administrators to deploy software.
In order to follow this approach, all the COGNITUS components specify their working environments, including the OS and the libraries/dependencies required at runtime, by creating a specification file called Dockerfile. The instructions/commands needed to run the application are specified to this file too.
Enabling the COGNITUS platform to support scalability has been partially addressed by the proposed modular functional architecture. More specifically, the system is designed to be stateless, allowing runtime additions/removals of the components’ instances in a plug and play manner. To achieve this at a physical level, an automation tool, which enables the horizontal scaling up of the containers forming the COGNITUS platform was also incorporated. In particular, COGNITUS utilises the Swarm mode of Docker, which offers command line tools that enable clustering and scheduling for Docker containers. That means, that the platform can be easily scaled up or down according to the current load.
Availability is a characteristic of service-oriented systems that describes the period of time during which a service is available. The term high-availability is used to express the importance of high operational performance for a given period of time. When creating robust production systems, minimizing service interruptions is often critical. Nevertheless, no matter how reliable the software is, problems can occur (e.g., hardware malfunctions) that can bring down the applications. To create a really reliable and highly available distributed system two important features should be taken into account: load balancing and redundancy.Load balancing, read more...
Redundancy refers to the multiplication of the running instances of a service (replicas) running at any given time. For the support of redundancy, a replication controller was incorporated in the architecture for starting-up or killing instances of COGNITUS components according to the current load. Accordingly, instances are automatically replaced if they fail, get deleted or are terminated. The replication controller is a feature provided by Docker Swarm mode, which is the container management solution utilised.
Continuous Integration (CI) & automated builds
The Docker images produced during the development of the COGNITUS components need to be updated each time new commits to the respective source code are made. Thus, the developers need to re-build the images each time they add new features to their components. Additionally, each time a new feature is committed, the component should be checked against build or runtime errors that might be introduced.
To this end, COGNITUS follows the Continuous Integration (CI) development practice, a process of automating the build and testing of code every time a team member commits changes to version control. In specific, COGNITUS utilises for this process the CI tools offered by Gitlab (http://gitlab.com). Using a specification file (.gitlab-ci.yml) developers can specify the automated steps (stages) that will be executed towards building the project, running the unit and integration tests, and finally deploying the component.