The Moving Picture Experts Group

Component Model

Standard: 
MPEG-E
Part number: 
3
Activity status: 
Closed
Technologies: 
Software architectures

 

MPEG Multimedia Middleware (M3W) Component Model

 

 

MPEG doc#: N8689
October 2006
Authors: Johan Muskens & Jean Gelissen (Philips)

 

1.      Introduction

MPEG, a working group in ISO/IEC, has produced many important international standards (for example: MPEG-1, MPEG-2, MPEG-4, MPEG-7, and MPEG-21). MPEG feels that it is now important to standardize an Application Programming Interface (API) for Multimedia Middleware (M3W) that is based on a defined set of requirements [1]. This API provides a uniform view to a multimedia middleware platform that can be realized by a number of different vendors. In order to guarantee the interoperability of multiple parts of M3W realization provided by different parties, the same realization technology shall be used.

ISO/IEC 23004 Part 3 [2] – Component Model specifies such a realization technology. The goal of this realization technology is to enable cost effective software development and increase of productivity by enabling software reuse and easy software integration. This realization technology shall be strict enough to get inter-operability and flexible enough to allow different vendors of parts of a M3W realization to discriminate themselves from the competition.

The specified realization technology is based on component based software engineering (CBSE) techniques. In CBSE software artefacts interact through well defined interfaces. One of the key concepts is a (software) service. ISO/IEC 23004 Part 3 – Component Model specifies:

  • Component model
  • What is a service
  • How to interact with a service
  • How it is packaged
  • Core framework
  • Standard interfaces for managing lifetime of services

In the remainder of this white paper we give a brief introduction on the component model and core framework.

2.      Component Model

The M3W component model gives rules on how to develop software in order to facilitate reuse and easy integration, but also supports a low resource footprint, (runtime) upgrading and extension, building robust and reliable software, and component trading. Reuse and easy integration is achieved by interacting using well defined interfaces. Late loading and binding supports runtime upgrading and extension. Uniform error mechanisms, explicit dependencies and a number of optional frameworks (resource management, fault management and integrity management) enable the development of robust and reliable software. Component trading is supported by allowing a large (open) set of different models for all the different stakeholders in the software development life cycle.

The component model specifies what constitutes and how to interact with a service, an executable component and an M3W component. Services are the basic architecture elements of a software system. Services are pieces of software that can be instantiated and provide coherent functionality through a number of different interfaces (Interfaces consist of one or more operations). Standard interfaces have been defined for navigation between interfaces, interface binding and managing the lifetime of a service.

Executable components are the unit of loading and are containers for services. The form of an executable component depends on the operating system. Each executable has a single and fixed entry-point (rcIComponent interface) which can be used to get to the service factory for a service. Using the service factory instances of a specific service can be created.

M3W components are the unit of trading. A M3W component is a set of models and their relations. Typically one of these models is the executable component (sometimes called the executable model). Some of the models are human readable (documentation), others are machine process-able (interface description model). Some of the models are needed during development (interface description), others during the trading process (factsheets).

3.      Core Framework

M3W specifies a core framework based on the M3W component model. This core framework consists of a runtime environment, support tools, and standard services that enable usage of services on a remote machine. The runtime environment is responsible for instantiation of services. This includes the on demand loading and unloading of executable components.

The runtime environment is very flexible and supports runtime upgrading and extension through a registry. This registry is a database that contains knowledge about the executable components and services that are available on the device. New executable components and services can be registered. Old versions can be removed. There is also the possibility to register compatibility between services.

Two optional standard services (REMI-P and REMI-R) allow usage of services on a remote machine. REMI-P enables a developer to make a service available for remote usage. REMI-R enables a developer to use a remote service.

The M3W API is specified in terms of logical components. Logical components can be realized by a number of different services. A standard service called ServiceManager is responsible for finding and instantiation of a number of services that realize a logical component, based on the id of the logical component.

4.      Summary

The Application Programming Interface (API) for Multimedia Middleware specified by M3W provides a uniform view to the Multimedia Middleware in a device. A realization of such a middleware can be provided by a number of different vendors. In order to get interoperability and easy integration between these different parts the same realization technology shall be used.

In ISO/IEC 23004 Part 3 – Component Model we have specified a component based realization technology that targets cost effective development and high productivity by enabling reuse and easy integration. This realization technology supports:

  • Low resource footprint
  • Upgrading and extension
  • Building robust and reliable software
  • Component trading

The realization technology that consists of a component model and core framework can be extended with an open set of optional frameworks (e.g. resource management, component download, fault management, and integrity management). The main idea behind this approach is that if you do not need a specific framework there is no undesired overhead.

5.      References

[1]   The Multimedia Middleware (M3W) requirements are in the annex to the Multimedia Middleware (M3W) Requirements Document Version 2.0 (ISO/IEC JTC1/SC29/WG11 N6981). A Call for Proposals derived from these requirements was issued at the 70th MPEG Meeting in Palma, Mallorca

[2]   ISO/IEC 23004, Information Technology — Multimedia Middleware, The M3W standard.