Solution overview

A rich-media platform is an important part of a digital-imaging application ecosystem. It does not redefine the world in terms of rich media but rather integrates into the modern business platforms. A rich-media platform must be inclusive of existing applications and services.

A rich-media platform needs to be part of a middleware architecture that enables and delivers applications that merge traditional business processing and modern rich-media elements. Middleware is the bridge between those with different domains of expertise. This difference is great between those who know media, such as file formats, color spaces, and stream encoding, and those who know business applications, such as database structures, messaging systems, and XML.

The logical architecture for a solution breaks down into four layers: business, application, component, and storage. Each layer tackles different problems, has different solutions, and effects different types of users. A rich-media platform defines a common model within each layer that allows for portability across implementations. Integrations between the layers allow for plug-and-play implementations of the architecture.

The foundation of a rich-media platform is the storage layer. Providing an abstraction to the digital assets is the key to developing rich media-based applications and services. Defining this layer has the same importance as defining a common language and API for accessing traditional relational-database systems. The storage layer is composed of the asset, the metadata about the asset, and the structure to store this information. The storage layer has to provide expected features such as insert, update, delete and query.

The component layer, also referred to as the repository layer, helps define access to the storage layer and allows functionality to be added that is not typical of a business developer and not typical of a storage system. Such functionality includes face recognition, sound to text, text to sound, watermarking, encoding, and decoding. The list of operations cannot be predetermined; hence a layer to add new features must be provided. The repository layer provides two of the basic input/output pipelines needed, including meta and asset. The meta pipeline allows the ingestion of assets and the extraction of metadata. When digital assets are retrieved from the storage system, the metadata pipeline allows information to be pushed back into the stream. The asset pipeline allows the transformation of the digital asset, using operations like watermarking or encoding. For example, an image-based program might get an image as a GIF when it is encoded by the underlying storage system as a JPEG file.

The application layer provides ties into the modern business platforms, such as J2EE. Current distributed architectures include Enterprise JavaBeans (EJBs). A subset of EJBs, called Entity EJBs, are a well-known mechanism for representing information stored in a traditional relational-storage system or object-oriented storage system. Unfortunately, they are not well suited for representing a digital asset. Current architectures do not provide proper support for digital rights management, transformation requests, metadata extraction, digital ingestion, or referenced resources.

The business layer helps unite the common business services and the rich-media services. This layer is most influenced by the MPEG-21 standards. The business layer utilizes existing technologies to help integrate services and define the ecosystem by uniting third-party providers of rich-media services with business processes. By providing the proper rich-media services, the cost of integrating rich-media applications and assets, which can be located throughout an organization, is reduced.

Figure 2 outlines the architecture for a rich-media framework. It is important to note that each of the service layers are required to bring together both low-level storage and translation capabilities with high-level programming and user features. Furthermore, these capabilities are not available off-the-shelf today with traditional environments.

New architectures, such as the one proposed here, are required to create a truly open-software platform that understands the structural details of rich-media content and provides a straightforward, standards-based interface for application development.

Figure 2: Overview of a rich-media framework architecture.

Java Community Process
The Evolution of Rich Media
Mining for Riches:A technical look at rich media platforms