The ACE Architecture

The central concept of the aceMedia Integrated Project is the idea of an Autonomous Content Entity (ACE). An ACE has three layers: the content itself, its associated metadata, and an "intelligence" layer, consisting of distributed functions that enable the content to instantiate itself according to its context including its network environment, the user terminal, and recorded user preferences.

The overall aceMedia software architecture consists of a framework on top of which applications are executed. This framework, called aceFramework, can be seen as a kind of generic content management middleware supporting the concept of the ACE.

The purpose of this aceFramework is to provide a convenient and secure environment for ACEs to be run, content analysis modules to be plugged into, and content to flow from one device to another. For example, an application could use the aceFramework to browse ACEs, to execute an ACE, or to analyze the content inside an ACE using some of the tools provided by the aceFramework.

An aceMedia system will then be composed of an instantiation of the aceFramework together with one or more applications on top of it and provides functionality, either locally to users interacting with the system, or remotely (via a remote aceFramework).

The figure above shows a high level overview of the components in a single aceMedia-enabled device.

The mission of the aceFramework is to provide a set of standardised services to aceMedia applications, so that those applications are developed more easily and more consistently, facilitating reusability. Since aceMedia systems must run in a number of devices, e.g. PCs, mobile handsets and set top boxes, the aceFramework has been implemented in Java to maximise portability.

The aceMedia architecture is modular and makes it possible to adapt the system to a great number of environments, from resource-constrained devices to full-fledged systems. While some components of the aceFramework are required to be local on an aceMedia-enabled device, Application Modules (AMs) may reside on the same system or can be located on remote aceMedia systems and be accessed via the network facilities, thus effectively creating a distributed system for multimedia processing.

The required components on an aceMedia-enabled device are:

  1. The central one is the aceManager, which coordinates and controls the communication between the other components within the aceFramework on the one hand and between the other components and the outside world on the other hand. It is akin to a kernel in an Operating System. Additionally it provides base functionality such as user session creation, authentication and logging.
  2. The aceRepository provides storage and retrieval of ACEs. Its interface hides the actual implementation of the repository, which could be a simple file system, but also a smart database with fast indexing capabilities, local or remote. This provides the scalability to handle multiple aceMedia platforms, for example mobile phones, set-top boxes and high-end servers at a content provider.
  3. The aceExEnv is the ACE execution environment. It is a confined environment to run the intelligence layer of an ACE using Virtual Machine (VM) technology. A confined environment is needed to maintain system integrity, as ACEs may contain untrusted code. The execution of an ACE can, for example, be requested by an Application or another ACE. However, the ACE execution in the aceExEnv is always initiated and controlled via the aceManager.
  4. The aceNetworkLayer handles all communication with third parties. Communication is needed in the aceFramework for several purposes, for example:
    • To receive an ACE from another aceMedia-enabled device, or to send an ACE to such a device, e.g. when sharing ACE collections between several households (peer-to-peer communication);
    • To allow ACEs to communicate with other ACEs (ACE peer-to-peer communication);
    • To let ACEs contact a designated trusted web service from which they can download additional information, content and/or metadata.
    • To invoke a remote AM from another aceMedia-enabled device, e.g. a high-consuming content analysis module that cannot run on a constraint device.
    Generic networking functions are provided by the aceNetworkInterface, independent of the actual protocols that are being used to communicate with third parties over the network.
  5. The Application Modules (AMs) are pieces of software that provide services to the aceMedia applications. They can be content analysis modules or any other module that manages ACEs. The AMs are deployed as OSGi bundles and have to be registered through the Application Module registry (AMRegistry) containing several AMs. The AMRegistry provides a general interface to register, request and get access to AMs. It keeps track of all AMs on the local device. If an ACE or an Application wants to use an AM, it has to request access to the AMRegistry via the aceManager first. AMs themselves can make use of other AMs. Take for example a Person Recognition AM that can identify which people are present on photos. This module could make use of a Face-region Detection AM if that is available. If needed, the Person Recognition AM can make a request to aceManager for permission to communicate with the Face Detection module, and then set up a fast communication link between them.
  6. The Configuration Storage component safely stores user's preferences, network profiles system settings and system defaults that relate to the local aceMedia device. Such settings can be set by the user via an application on top of aceFramework. The Configuration Storage ensures that settings can only be changed by the component that set them in the first place. Also, ACEs are generally not allowed to read or change the configuration settings.