Automating production of cross media content with AXMEDIS GRID framework

A GRID based Framework and tools for automating
production of cross media content
Pierfrancesco Bellini, Ivan Bruno, Paolo Nesi
DISIT-DSI, Distributed Systems and Internet Technology Lab
Dipartimento di Sistemi e Informatica, Università degli Studi di Firenze
Via S. Marta, 3, 50139 Firenze, Italy
http://www.AXMEDIS.org
nesi@dsi.unifi.it, paolo.nesi@unifi.it
http://www.disit.dsi.unifi.it/, http://www.dsi.unifi.it/~nesi, http://www.dsi.unifi.it/
Office: +39-055-4796523, Fax: +39-055-4796363
Abstract
The evolution of content distribution for
entertainment and infotainment is urging better pricing
and value-for-money for industry products and
services. Content providers, aggregators and
distributors constantly need to adopt innovative means
for reducing costs and to satisfy the user needs.
AXMEDIS Framework aims at providing technical
solutions and tools for automating content production,
formatting, protection and distribution. The solution
described in the paper was designed as a distributed
environment based on the GRID technology and
provides an efficient management of content
production/finalization as well as the dynamic service
discovery and composition, distributed resource
management and adaptive media delivery. AXMEDIS
is a large IST FP6 Integrated Project of Research and
Development, in which a set of enabling technologies
are developed to cope with the above mentioned
problems.
1. Introduction
The market of digital content for entertainment and
infotainment is urging better pricing and value-for-
money for industry products and services. Content
providers, aggregators and distributors constantly need
to adopt innovative means for reducing costs and to
satisfy the user needs. These goals can be reached by
acting on a set of factors that impact on: content
modeling, content processing, content protection,
digital rights management, interoperability of content,
component based architecture, etc. The state of the art
of content distribution, modeling, composition,
formatting, protection and management is grounded on
the content processing languages and content formats.
Presently, there is a large number of content formats
that ranges from the simple files: documents, video,
images, audio, multimedia, etc., to integrated content
models for packaging such MPEG-21 [1], [2],
WEDELMUSIC [3], SCORM, etc. These models
attempt to wrap any digital resource in a container to
make them ready for delivering by using a large range
of business and transaction models and supporting
them with some DRM (Digital Rights Management).
The standardization process of MPEG-21 is still under
completion; presently some parts are mature while
others are under evolution. The authors have also
worked on DRM aspects in WEDELMUSIC [3] and
for REL-RDD MPEG-21 as in [4], on MPEG-21 IPMP
and on M3W of MPEG.
In order to manage the complexity of content
processing for massive production suitable massive
architectures have to be set up to allow the fast
dynamic allocation of processes and their supervision.
On this purpose a GRID technology can be used [5],
[6]. Although, there is no widely agreed definition
what GRID means, the consequences for scientific and
research work, and also for the private users are
relevant. GRID computing is a form of distributed
computing that involves coordinating and sharing
computing, application, data, storage, or network
resources across dynamic and geographically dispersed
organizations. GRID is already being successfully used
in many scientific applications where huge amounts of
data have to be processed and/or stored. According to
the work described in this paper, the GRID Computing
is declined to the production and management of
multimedia content. It is envisaged that a large number
of multimedia services (music, video, radio, television,
etc.) will become suitable very soon for real-time (on-
demand) public access. Crucial technical issues of
providing access to such services are user-friendliness,
Proceedings of the 11th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS'06)
0-7695-2530-X/06 $20.00 © 2006

universal access to services, as well as an efficient
service GRID middleware that enables the dynamic
service discovery and composition, distributed
resource management and adaptive media delivery
Errore. L'origine riferimento non è stata trovata..
This paper reports AXMEDIS Framework that
addresses the above mentioned problems and critical
points. AXMEDIS framework provides a set of
innovations and technical solutions and tools to allow
the automation of cross media content production,
packaging, protection and distribution. AXMEDIS
solution is mainly based on MPEG-21 model and
specializes its format; it provides a P2P tool for content
sharing and distribution at B2B level, and it is capable
to work with a multichannel architecture for B2C
distribution for the production of content on demand
[8], [9].
AXMEDIS is a large Integrated Project of Research
and Development partially founded by the European
Commission in IST FP6 and includes about 18 partners
among them: University of Florence, HP, EUTELSAT,
TISCALI, EPFL, FHGIGD, ACIT, AFI, University
Pompeo Fabra, University of Leeds, STRATEGICA,
EXITECH, XIM, University of Reading, etc. More
technical information and about how to make
registration and affiliation to AXMEDIS can be
recovered on www.axmedis.org
The paper is organized as follows. In section 2, the
main goals of the AXMEDIS are reported. Section 3
refers to the AXMEDIS General Architecture putting
in evidence the most important components related to
the production and processing of content. In Section 4,
features of the AXMEDIS processing language for
content are reported. Section 5 describes the
architecture for Content Processing of AXMEDIS
based on GRID, descriptors, optimization, etc. In
Section 6, a small example is reported with some
details on the AXCP Rules for content processing.
Conclusions are drawn in Section 7.
2. AXMEDIS Framework Goals
AXMEDIS Framework is an architecture and open
solution developing a set of new technologies and
tools and integrating state of the art solutions, which
can be used to set up production and/or distribution
services. The new solutions of AXMEDIS allow the:
x reduction of costs and increasing efficiency for
content production, protection, management and
distribution: (i) integrating Content Management
Systems, CMSs; (ii) automating content gathering
and ingestion processes; (iii) automating
composition, GRID, optimization techniques for
content production, protection and formatting; (iv)
managing the workflow; (v) allowing content
production on demand;
x support for the whole value chain: composition,
packaging, integration, aggregation,
synchronization, formatting, adaptation,
transcoding, indexing, integration in the same
objects protected and non protected components,
definition of relationships with other resources,
metadata integration and remapping/transcoding,
protection, license production and verification;
x convergence of the media, interoperability of
content supporting the multichannel distribution,
support content distribution: (i) on different
channels such as satellite data broadcast, Internet,
cellular network, wireless, traditional supports as
DVDs, internet, mobiles networks, local and
wireless networks; (ii) including P2P in both B2B
and B2C levels; (iii) on different devices such as
PC, PDA, i-TV, etc.;
x adoption of new methods and tools for innovative,
flexible and interoperable DRM, including (i)
exploitation of MPEG-21 and overcoming its
limitations, (ii) supporting different business and
transactions models, (iii) supporting the
integration/interoperation of different DRM
models such as MPEG-21 REL and ODRL OMA;
The AXMEDIS Framework can be used to setup and
built many different applications and services in the
area of content production, protection and distribution.
The AXMEDIS is also an open format capable of
integrating any kind of cross media format (video,
images, animations, games, SW application, learning
objects, multimedia, audiovisual, document, audio,
etc.) in any digital format, any kind of metadata
including identification, classification, categorization,
indexing, descriptors, annotation, relationships and
play activities and protection aspects [8], [9].
AXMEDIS content format can be used for packaging
digital information and resources for leisure and
entertainment, infotainment, and also for managing
protected governmental content, healthcare
information, business of value information, etc.
3. AXMEDIS General Architecture
In Figure 1, the general AXMEDIS architecture is
reported. The diagram includes all the major areas of
the AXMEDIS framework and architecture.
AXMEDIS Factory for automatically collecting
content from legacy CMSs (Content Management
System), producing the content, programming and
scheduling the production process, editing and
processing metadata, composing and formatting
0-7695-2530-X/06 $20.00 © 2006

content, collecting content information from content
usage (accounting), producing licenses to harmonize
the production with workflow applications in the
factory and among geographically distributed factories,
etc. The AXMEDIS Factory is scalable in the sense
that it can satisfy the needs of small and large content
producers, integrators, and distributors.
AXMEDIS Distribution Area for automating the
content publication and acquisition in the business area
allowing the interconnection of AXMEDIS Factories
by means of the AXEPTools which is a secure and
legal P2P tool. Among connected AXMEDIS
Factories, it is also possible to make distributed queries
to search for content, and to automatically publish and
acquire/update content from/to the business partners,
etc. The tools in this area also allow scheduling content
distribution and publication towards external web
services for example those of front end distribution
servers.
AXMEDIS Player for content playing and execution
on several different platforms, to built specific and
customized content players, for distributing and
sharing content among final users by means of secure
P2P tools such as AXMEDIA P2P tool.
AXMEDIS Protection and Supervising tools for
registering users, certificating users, authenticating
devices and tools, monitoring all the activities on the
AXMEDIS content on AXMEDIS players and tools,
processing licenses, managing black lists, and
collecting and reporting the information about content
usage and rights exploitation, etc.
3.1 AXMEDIS Factory
A content factory can be built on the basis of
AXMEDIS tools in a scalable and flexible manner.
Tuning for example, GRID size, database size and
type, number of authoring tools, number and type of
tools/algorithms and libraries for content processing,
licenses, integration support based on Workflow or
not, etc.
The AXMEDIS Database Area includes the
AXMEDIS/MPEG-21 database model, supporting the
storage and access to AXMEDIS content via a set of
metadata for each object called AXInfo that can be
customized. The database also includes produced
licenses for the objects, history of performed actions
on content, potentially available rights for each digital
resource, models of contracts, etc.
Figure 1 – AXMEDIS Architecture
0-7695-2530-X/06 $20.00 © 2006

The AXMEDIS Content Processing Area (AXCP
Area) is based on a GRID solution for automating all
the activities to be performed for the production, and
processing of content, which is the major topic of this
article. The major tools in this area are: the AXCP
Engines and Scheduler, which are respectively the
single code of the GRID and the organizer of processes
on the GRID nodes.
The AXMEDIS Workflow Management tools
include a set of micro tools and interfaces which are
pervasively connected to all the AXMEDIS tools and
plug-ins to allow interfacing the whole content factory
to Workflow tools such as Open Flow and BizTalk.
The AXMEDIS Editor is the authoring tool for
manually producing AXMEDIS objects when needed
and for supporting the designer to create the scripts for
the AXCP that could be considered macros of the
AXMEDIS Editor.
The AXMEDIS Accounting Area includes a set of
tools which allows content producers, distributors or
collecting societies to collect administrative
information and reports about their content in order to
gathering information about the list of rights that have
been exploited on their AXMEDIS objects by the final
users and by the business users.
4. Content Processing Language Features
The AXMEDIS Content Processing Area and the
related language have been designed to provide a set of
features and capabilities for automating content
production and processing.
The processing algorithms are specified in terms of
script code (Spider Monkey) allowing the
manipulation of complex AXMEDIS data types and
simple digital resources and content in general, and for
the direct access to the AXMEDIS database and
processing queries with the help of the AXMEDIS
Query Support. The available data types, operators and
accessible algorithms allow manipulation of any digital
resources in a large number of formats for: images,
audio files, video, documents, multimedia (including
MPEG-4, HTML, LOM, etc.), plus MPEG-21 aspects,
MPEG-21 REL, MPEG-21 IPMP, etc.
As regard the processing capabilities, an AXCP Rule
formalises in its language features to perform the
following activities on content.
Content Ingestion and Gathering from
x Content Management Systems, from file system,
or protocols: ODBC, MySQL, ORACLE, MS-
SQL, etc., files systems, http and ftp accesses;
x processing resources and coupling them with
metadata;
Content Retrieval from
x AXMEDIS database;
x other AXMEDIS content Factories by means of
the P2P tools, namely AXEPTool;
x Content Management Systems;
Content Storage into
x AXMEDIS database;
x ODBC database, and other models;
Content Processing such as
x adaptation, extraction of descriptors, transcoding,
synchronisation, estimation of fingerprint,
watermarking, indexing, content summarization;
x metadata manipulation, mapping and adaptation;
Content Composition for
x packaging in MPEG-21; creation of content
components or objects as a combinations of raw
assets such as Text, Images, Audio, Video,
Animation, metadata, descriptors, licenses,
multimedia objects such as MPEG-4, HTML,
SCORM, macromedia tool file, games, etc.;
x creation of content as linear, nested or hierarchical
combination of content components;
Content Formatting
x gluing content elements together by means of
SMIL based templates and applying style sheets to
define the usage interface (format, layout) of the
content collection and the interested content usage
paradigms (leaving open some parameters). For
example, karaoke, collection browsing, selection
menus, sliding presentation, stable background
with a window with live video, animated text
moving on an image, running text, etc.;
x optimization of styling parameters left open or
defining them manually to arrange for example:
best fitting of images in the screen, optimizing the
amount of text in the page, best time fitting, etc.;
Content Protection such as:
x Protection of digital resources and full objects
with their complex structure;
x creation of Protection Information parameters
(IPMP of MPEG-21);
x Applying Protection Information model to
AXMEDIS object such as, segmenting digital
resources, applying encryption, scrambling;
x Posting specific protection information for each
given object to the AXMEDIS Certifier and
Supervisor server;
Content Licensing
x Generating license from license model and
additional information, storing licenses, posting
them on license server automatically;
0-7695-2530-X/06 $20.00 © 2006

x Transcoding/translating licenses from MPEG-21
REL to ODRL OMA formats;
x verification of licenses against available rights to
simulate the usage from the user site;
Content Publication and Distribution towards
x any distribution channel, producing programme
and its schedule;
x P2P network of other AXMEDIS Factories of
content integrators, producers, and distributors.
5. AXMEDIS Content Processing Tools
In order to exploit the above features, the AXMEDIS
Content Processing Area is governed by a set of tools
as depicted in Fig.2 and described as follows.
Figure 2 -- AXCP Architecture
AXMEDIS Rule Editor: to produce, debug, test and
validate the executable AXCP Rules. An AXCP Rule
is:
x written using the AXCP language for content
production. Such a language is an extension of
Java script;
x tested, debugged and validated on the AXMEDIS
Rule Editor;
x activated for content processing on any AXCP
GRID Node or on a single computer;
x used/parameterized for producing content on
demand or to be integrated in your content factory;
x activated from your Workflow Manager engine
via web service;
x activated by changes in remote objects and queries
in the local database and on the P2P network.
AXCP GRID consists of a set of general purpose or
specialized computers (called AXCP GRID Nodes or
Engines) to execute AXCP Rules governed by the
AXCP Rule Scheduler. This infrastructure is realized
by means a P2P technology based on TCP/UDP
protocol and socket developed.
The processing capabilities and functionalities reported
in the previous section and exploited from AXCP
Tools and Rules are expandable by realizing or
installing a set of additional plug-ins, by using the
AXMEDIS Plug-in descriptor and solution.
The AXCP Scheduler performs scheduling of AXCP
rules in GRID nodes according to the content
production and processing needs in terms of time and
resources. It performs the rule firing/activation, rule
executor discovering and management and rules
dispatching. It is capable to receive commands for
remote control and provide reporting (notifications,
exceptions, logs, etc…) via a web service.
The AXCP GRID Node is a single general purpose or
specialized computer of the AXCP GRID. It is the
effective executor of AXCP Rules and consists of a
script engine based on JavaScript (JS) Spider Monkey
released by Mozilla [10], [11]. It receives the Rule
code to be executed from the Scheduler and provides
to it the notifications, exceptions and errors messages
at runtime.
5.1 AXCP Rule Scheduler
The AXCP Rule Scheduler manages AXCP rules and
the available AXCP GRID Nodes. Each of them has a
corresponding counterpart model on the Scheduler side
to represents its capabilities and status. Knowing the
availability and capabilities of each GRID Node is
mandatory to verify the suitability of the computer that
will execute the rule. To this end, the association of
Rule to a GRID Node is based on the analysis of their
profiles/capabilities.
Each AXCP GRID Node provides its
profile/capabilities descriptor during its first
connection and discovery/connection in the GRID
network, containing:
x Execution status: running, idle, etc
x Identity and information of the executor: computer
name, IP address, location, etc.
x Capabilities: CPU, RAM, Clock, Disk Space, OS,
available workload, network cost for the
communication with the database, etc.
x Tools Provided: AXMEDIS Plug-Ins installed and
External tools Plug-In installed.
As depicted in Figure 3, the AXCP Rule scheduler
consists in several modules, hereby only key modules
will be described.
Internal Scheduler
The Internal Scheduler detects, fires, launches the
execution of rules, and
x manage and update the list of rules to be
scheduled and their status by: loading a new rule,
0-7695-2530-X/06 $20.00 © 2006

checking expiration conditions, updating firing
conditions of a periodic rule, etc.;
x select the rule that matches conditions for the
execution by checking the execution time and
date;
x execute commands on rule (run, kill, pause,
resume, etc…) coming from external applications
such as the AXMEDIS Workflow Manager or
from the Rule Editor;
The Scheduler includes two major components.
The Control Process
x manages the messages related to correct execution
of process to communicate at the user or at the
schedules higher level information;
x manages errors/faults during the phase of rule
association with an executor, due to the launching
phase, during the rule execution on remote
executor, due to a missed deadline;
x preserves the scheduled work from catastrophic
interruption of service (crash of the application)
saving when needed the information and giving
the possibility to restore the last status of activity.
An Optimizer which decide about the allocation of
rules on the Nodes. The decision is performed by
comparing the rule profile with the
Profiles/Capabilities of the Nodes. If none of the
available Nodes match satisfies the needs, the
association fails and an error message is propagated.
The allocation is presently performed by using a
Deadline Monotonic, while the usage of other
optimization algorithms is under development and
adaptation to this context: Taboo Search, Genetic
Algorithm, etc. [12].
Dispatcher
The main activity of the Dispatcher is to:
x discover GRID Nodes in the network, request and
receive their profile;
x associate Rules to the Node and start the running
the rule;
x monitoring the status of the GRID Nodes;
x manage possible errors messages and notifications
coming from the Nodes,
x create possible recovering exceptions;
x create logs and tracking the activities of Nodes.
The Dispatcher includes three major components.
The Resource Controller periodically explores the
network and refreshes the availability of remote
executors in the GRID network. For each new
discovered GRID Node, it acquires the profile and
generates/assigns a unique ID (Node ID). At runtime,
the Resource Controller manages and updates the
status and profile of each Node. A Node is removed
from the list when does not reply to the discovery or
some request. In this case, an exception is created if
the fault of the disappeared Node has not been already
communicated in form or error/fault or an error is
generated when a time out or deadline misses (e.g., the
remote executor did not respond to a request within a
time interval specified by a time out).
The Rule Launcher sends commands (kill, pause, run,
resume) to Nodes, to engage them to execute a Rule. If
the engaging procedure fails an error is generated. The
Rule Launcher provides also services for tracking
commands and controls sent to remote Nodes by
updating an activity log file.
The Rule Monitor continuously monitors the
execution of rules by listening and interpreting
messages and notifications coming from remote
executors. It communicates the status of a rule to the
Internal Scheduler for updating and routes possible
errors messages and notifications to the Internal
Scheduler. The Rule Monitor also manages the log file
and traces the activity of each rule executor by
reporting all received messages and notifications.
5.2 AXCP GRID Node
The AXCP GRID Node is an Executor of Rules
running on each GRID Node. It is a computational unit
in the distributed environment where rules are
executed. It hosts the SpiderMonkey Javascript engine
for JavaScript code execution and the GRID interface
for the network communication. The architecture of
the AXCP GRID Node is depicted in Figure 4, and it is
mainly constituted by the following main components:
x Rule Executor Manager to control the Script
Executor;
GRID PEER INTERFACE
GRID PEER
DISPATCHER
INTERNAL SCHEDULER
SCHEDULER
COMMAND MANAGER
ENGINE COMMANDS AND
REPORTING
SCHEDULER GUI
Figure 3 – AXCP Rule Scheduler
Architecture
0-7695-2530-X/06 $20.00 © 2006

x Rule Executor to execute rules that include an
instance of SpiderMonkey Javascript Engine
(called JS Engine).
The Rule Executor Manager is the interface between
the Scheduler and the Rule Executor. The GRID Peer
Interface allows the communication in the distribute
environment and provides the support for:
1. receiving commands, messages, requests and files
from the Scheduler;
2. sending messages, notifications, exceptions and
files to the Scheduler;
3. being discovered by the Scheduler during the
discovering phase.
The Rule Executor Manager analyses the Node to
recover the information to build its profile that sends it
to the Scheduler, when it is discovered. It stays in an
idle status until the Scheduler engages it asking to put
in execution a rule. In this case, the rule is received as
an XML file, and then it is fired by the Launcher. The
Rule Executor Manager provides to the Rule Executor
the communication support. In this way, errors, status
and the end of execution are notified to the Scheduler.
Finally, it provides remote control commands to kill,
pause, resume, of rules and to get the status of the
executor.
The Launcher prepares and launches the execution of
the Rules. It loads the XML code of the rule received
by the Scheduler and initializes the JS Engine
environment by preparing the execution according to
the SpiderMonkey guideline [7], [11]].
In the initialization step, all functions provided by
AXMEDIS plug-ins according to dependences list
contained in the Rule XML descriptor have to be
created and registered to the JS Engine. The actual
values specified in XML rule description as arguments
of the script are associated with global variables of the
script. This phase allows conceptualizing the script
execution and passing its parameters. If errors are
produced during the script initialization, a failure
message is generated and sent to Rule Executor
Manager that routes them to the Scheduler, otherwise it
invokes the Rule Executor to put in execution the
script.
The Rule Executor has been designed to host the JS
Engine and run a Rule also in the debugging and check
modalities. The former modality allows debugging and
monitoring the execution of a Rule by means of traps
in the code corresponding to breakpoints (interrupting
the execution), watching variables and managing the
stack of function calls. The latter modality allows
verifying the syntax of the rule before to run
definitively in the AXCP Rule Engine, and estimating
by partial execution some parameters related to the
complexity of the rule such as: requested time
computation, amount of disk space, data transferring
time, etc.
This last modality is obtained by executing the script
without the real execution of the procedures that are
the real cost of processing, with the aim of extracting
the main parameters that are going to influence the
execution time of the algorithm depending on the
context (Executor) in which it is going to the executed.
5.3 AXMEDIS DATA Types, Functions
and tools for JavaScript
The SpiderMonkey JavaScript engine’s built-in objects
were extended by wrapping AXMEDIS data types
(AXMEDIS JS Classes), functions (JS Functions) and
AXCP plug-in tools deriving from the AXMEDIS
Framework data types. They provide direct program
services, or they can serve as interfaces to program's
services. For example, an AXMEDIS JS Class that
provides direct service might be one that handles all of
an application's network access, or might serve as an
intermediary broker of database services. While, an
AXMEDIS JS object may mirror data and functions of
the AXMEDIS Framework data type. To this end
different sets of JS Classes were defined. In the
following, a brief description for the most relevant JS
Classes is reported:
x JS_AXOM wraps the AXMEDIS Object Model
(AXOM). It is responsible of AXMEDIS object
management in terms of: creation, embedding
digital resources and metadata, storing/retrieving
into/from database, etc. It includes classes for
managing the native metadata of the AXMEDIS
RULE EXECUTOR MANAGER
GRID PEER INTERFACE
RULE EXECUTOR
JS ENGINE (API Functions)
LAUNCHER
GRID PEER
JS AXMEDIS DATA TYPES, FUNCTIONS and
AXCP TOOLs
AXMEDIS FRAMEWORK Data Types
Figure 4 – AXMEDIS GRID Node
(AXCP Rule Executor)
0-7695-2530-X/06 $20.00 © 2006

objects (AXInfo) and the metadata related to the
Dublin Core.
x JS_AXOM_CONTENT_PROCESSING consists
in a metaclass that refers and allows to
dynamically connect and exploit AXMEDIS
Content Processing Plug-ins. It provides and
manages the access to the set of functions exposed
by DLLs discovered by the Plug-in Manager and
related to AXMEDIS content production,
protection, adaptation algorithms and tools.
Dependencies of the rule define the number of and
what plug-ins have to be loaded at the start of the
execution, each plug-in is a global instance of the
AXCP Plug-in class and the name of the instance
is the same of the plug-in. The class link plug-in
tool for: Fingerprint, Digital Resource
Adaptation, Metadata Adaptation and Accessing
to External tools;
x JS_SELECTION allows making queries to the
AXMEDIS database;
x JS_PROTECTION class provides methods for
managing DRM and protecting AXMEDIS object,
such as: encryption, scrambling, compression,
licensing access and manipulation (MPEG-21
REL/RDD and IPMP), .etc.;
x JS_FUNCTIONS is a set of auxiliary functions for
different purposes: Statistical, Combinatorial, Set
Management, Archive, System (e.g. file system,
system call and network communication
functions).
6. AXCP Rules and Tools
An AXCP is comprised of three main sections (see
Figs. 5 and 6). The Header contains general metadata
such as: rule name, AXRID (Rule ID), rule version,
rule type, software name, version of software, date of
production, time of production, author, affiliation,
URL, comment, last modification date and time.
Schedule section contains temporal constraints
describing the rule status (“active” or “inactive”) and
conditions for firing it such as: start date, start time,
periodicity (monthly, daily, weekly, etc.), expiration
date and expiration time. Such information is used by
the AXCP Rule Scheduler in the GRID environment
for planning the activity and associating active rules
with available computational resources. Definition is
the section that contains the rule signature in terms of
list of arguments (parameters and selections), list of
dependences (required AXMEDIS plug-ins) and the
script code to run. Dependences define constrains on
AXMEDIS plug-ins that has to be installed in a GRID
node.
A XML formalization can be obtained from Figure 6.
An AXCP rule can be used for different purpose in the
Content Processing Area.
Figure 6 – XML schema of the AXCP Rule
For instance, in an AXMEDIS Content Factory three
main different rules categories are used:
x Publication Rule: executed to automating the
process of publishing AXMEDIS objects from the
database to the distribution channel or P2P
network;
x Downloading Rule: executed to download a
Selection of objects from the P2P network and
move them into the temporary database for further
inspection and Load according to a Loading Rule.
x Loading Rule: executed to load into the
AXMEDIS Database with a selection of objects
retrieved from the P2P network;
Formally, the signature of the AXCP Rule is:
Figure 5 – AXCP Rule Editor
0-7695-2530-X/06 $20.00 © 2006

R = f(S1,S2,..,Sn,P1,…,Pm)
Where:
ƒ Si is a sequence of queries, to be sent to the
AXMEDIS Database to retrieve digital object
(content) IDs or a set of object IDs to AXMEDIS
objects or a mix of them; such parameter is called
Selection and is always exploded in terms of list of
objects IDs during the execution of the Rule f(.).
ƒ Pi is a parameter (basic type as integer, common
string, XML string, Boolean, etc.), it could be for
example, the scale factor or the MIME type of the
output format, the number of objects collections to
be created, name of the author, etc.
ƒ f is the identifier of rule (e.g., the ID of rule);
ƒ R is the consumptive result of the rule application.
It could be a status, a new AXMEDIS object, or a
metadata manipulation result, the license of an
AXMEDIS object, a message to be returned to the
AXMEDIS Content Processing Area, etc.
Other results are the resulting objects processed and/or
produced during the execution of the Rule and they
can be directly posted into the file system or database.
The Figure 5 shows a snapshot of the AXCP Rule
editor reporting the structure of rule in the tree view
and the javascript source code in main edit area. The
Figure 7 shows the snapshot of the AXCP rule
scheduler at work. The Rule scheduler provides two
views: the list of AXCP rules and the list of discovered
GRID nodes. It also allows monitoring the log activity
and setup network parameters such as port numbers,
net mask, time out, backup time, etc.
The script of Figure 5 (reported in Figure 8) produces
different AXMEDIS objects constituted of a picture
and at most maxDoc documents. The list of pictures
and documents are provided by two AxSelection
objects: pictureSel and docSel. They are used to
retrieve the array of AXOIDs from the AXMEDIS
database. The maxDoc parameter is a global variable
and it is used to store and fix the maximum number of
documents to retrieve from the documents selection
and associate with a picture.
The Dublin Core metadata are generated by the
createDublinCoreTitle() function for each new
composite AXMEDIS object associated with the axObj
instance of AxmedisObject by adding an AxDublinCore
object with the title. The picture adaptation is
performed by the ImageProcessing plugin object by
means of the Convert and Scale methods: each
function getTitle(axObj) {
var dc = axObj.getDC();
return dc.getElement("dc.title");
}
function createDublinCoreTitle(axObj, title) {
var dc = new AxDublinCore();
dc.addElement("dc:title", title);
axObj.addMetadata(dc);
}
/* Start of script: pictures and docs arrays collect results of
two selections objects. They provide AXMEDIS Objects to
use in the composition process */
var pictures_axoids = imageSel.resolve();
var doc_axoids = docSel.resolve();
var template = new SMILTemplate();
var style = new SMILStyle();
var formatter = new SMILFormat();
for(p in pictures_ axoids) {
var axObj = new AxmedisObject();
var obj = new AxmedisObject (pictures_ axoids [p]);
var nDoc = 0;
var title= GetTitle(obj);
// extraction of the picture resource reference
var vRes = obj.getContent();
// adaptation and scaling of the resource
ImageProcessing.Resize(vRes,width, height, vRes);
ImageProcessing.Converting(vRes,outFormat, vRes);
// embed the adapted object
axObj.addContent(obj);
for (d in doc_ axoids) { // adding maxDoc documents
axObj.addContent(doc_ axoids [d]);
nDoc++;
if(nDoc>maxDoc)
break;
}
createDublinCoreTitle(axObj, "Collection of "+title):
var template = new SMILTemplate(axObj);
var style = new SMILStyle(axObj);
// the formatter return an AxResource with the SMIL
smilRes = formatter.createSMIL(template,style);
axObj.addContent(smilRes);
// the Axmedis Object is stored into the DB
axObj.uploadToDB();
}
Figure 8 - Script for production and adaptation of
AXMEDIS objects
Figure 7 – The AXCP Rule Scheduler GUI
0-7695-2530-X/06 $20.00 © 2006

picture is converted in the format specified by the
outFormat rule parameter and then scaled as
indicated by with and height rule parameters. The
ImageProcessing plugin is a dependency for the script
and has to be included in the XML description in order
to instantiate the AxCPPlugin object in charge to load
the plugin and provide its functions. All new
AXMEDIS objects are successively formatted using
the SMILTemplate and SMILStyle objects to find the
best template and style to be used as input to the
SMILFormat object. Finally, the SMIL description is
added as resource to the AXMEDIS objects and then
they are stored in the AXMEDIS Database by the
uploadToDB() method of AxmedisObject class.
7. Conclusions
Content providers, aggregators and distributors
constantly need to adopt innovative means of
increasing efficiency in order to reduce cost.
AXMEDIS architecture and tool is a possible solution
to automating, accelerating and restructuring
production process. In this paper, the aims and the
capabilities of the script language of the AXMEDIS
Content Processing, AXCP, architecture have been
described. This AXCP is a flexible and scalable core
subsystem of the AXMEDIS Framework and
architecture. Such subsystem is involved in the
automatic content production, protection, formatting,
metadata adaptation, etc. The adopted solution is based
on GRID Computing and on a script language for
coding Rules to be executed. The AXCP Rule
Language extends the Javascript by adding a descriptor
for those rules and a large set of object types modelling
AXMEDIS data types for content processing: digital
resources, metadata, descriptors, ID in UUID, licenses
in MPEG-21 REL, protection information in MPEG-
21 IPMP, XML, SMIL, HTML, WSDL, etc. In
addition, rule capabilities for the rule description,
GRID Node capabilities, and plug-in component
descriptors have been defined in order to enable the
dynamic allocation and verification of AXCP Rules on
GRID Nodes. In addition, the model for describing the
components allows extending the capabilities of the
AXCP Language and the automatic installation of new
components via the AXC Scheduler if needed. The full
documentation can be recovered on AXMEDIS portal
http://www.axmedis.org. AXMEDIS is an open
platform in the sense that the specification and the
formats are accessible and royalty free. In addition, the
access to the source code of all the tools can be easily
obtained joining the AXMEDIS community
8. Acknowledgments
The authors would like to thanks to all AXMEDIS
project partners including the Expert User Group and
all affiliated members, for their contributions, funding
and collaborations. A specific acknowledgment to
European Commission IST FP6 DG INFSO for partial
funding of AXMEDIS project. A warm thanks to all
AXMEDIS people that have worked in the project and
sorry if they have not been involved in the paper and
have not been mentioned.
9. References
[1] MPEG Group, “Introducing MPEG-21 DID”,
www.chiariglione.org/mpeg/technologies/mp21-did/
[2] MPEG Group, “Introducing MPEG-21 IPMP
Components”,
www.chiariglione.org/mpeg/technologies/mp21-ipmp/
[3] P. Bellini, J. Barthelemy, I. Bruno, P. Nesi, M. Spinu,
``Multimedia Music Sharing among Mediateques,
Archives and Distribution to their attendees", Journal on
Applied Artificial Intelligence, Special Issues on
Artificial Intelligence for Cultural Heritage and Digital
Libraries, Vol.17, N.8-9, pp.773-796, 2003.
[4] P. Bellini, P. Nesi, D. Rogai, A. Vallotti, “MPEG-21
REL Authorization Algorithm, C implementation, with
RDD support”, Technical Report, DSI-DISIT,
Department of Systems and Informatics, University of
Florence, May 2004.
[5] D. W. Erwin and D. F. Snelling. UNICORE: A GRID
computing environment. Lecture Notes in Computer
Science, 2150, 2001.
[6] Foster. The anatomy of the GRID: Enabling scalable
virtual organizations. Lecture Notes in Computer
Science, n.2150, 2001.
[7] J. Mathe, K. Kuntner, S. Pota, Z. Juhasz, “The use of
Jini technology in distributed and GRID multimedia
systems”, in Proc. MIPRO 2003, Hypermedia and
GRID Systems, Opatija, Croatia, 19-23. May 2003., pp.
148-151.
[8] P. Bellini and P. Nesi, “An Architecture of Automating
Production of Cross Media Content for Multi-channel
Distribution”, in Proc. AXMEDIS 2005, Florence, Italy,
30 Nov. - 2 Dec., IEEE Press, pp 123-133
[9] Proc. AXMEDIS 2005, Florence, Italy, 30 Nov. - 2
Dec., IEEE Press.
[10] “JavaScript C Engine Embedder's Guide”,
http://www.mozilla.org/js/spidermonkey/apidoc/jsguide.
html
[11] J. Thiele, “Embedding SpiderMonkey - best practice”
http://egachine.berlios.de/embedding-sm-best-
practice/embedding-sm-best-practice-index.html
[12] L. Braccesi, M. Monsignori, P ~Nesi, ``Monitoring and
Optimizing Industrial Production Processes", Proc. of
the 9th IEEE International Conference on Engineering
of Complex Computer Systems, ICECCS2004, IEEE
Press, Florence, Italy, ISBN 07695-2109-6, April 2004.
0-7695-2530-X/06 $20.00 © 2006

Automating production of cross media content with AXMEDIS GRID framework

Recommended

Recommended

More Related Content

Similar to Automating production of cross media content with AXMEDIS GRID framework

Similar to Automating production of cross media content with AXMEDIS GRID framework (20)

More from Leonard Goudy

More from Leonard Goudy (20)

Recently uploaded

Recently uploaded (20)

Automating production of cross media content with AXMEDIS GRID framework