An ontology driven architecture approach for open multimedia service oriented architectures
Myriam Lamolle, Chan Leduc
Ludovic Menet
IUT de Montreuil, Université Paris8 Laboratoire d'Informatique Avancée de St Denis, LIASD 140 rue de la Nouvelle France, 93100 Montreuil, France {myriam.lamolle, chan.leduc}@iut.univ-paris8.fr
Orchestra Networks R & D Department, (LIASD) 75, bld Hausmann, 75000 Paris
[email protected]
Abstract—The advent of semantic web and the new communication technologies require finding new solutions for self-deployment and self-adaptive distributed systems. In this paper, we propose coupling ontology driven methodology and service oriented architecture for open multimedia applications. We design several ontologies based on main multimedia standards. Service component architecture ontology models the service oriented architecture approach. Finally, we integrate a semantic data mapping module to transform a set of ontology's individuals to new individuals of another ontology. A study case (video on demand) experiments our multimedia ontology driven architecture. Model Driven Engineering, Ontology Driven Architecture, Service Oriented Architecture, Service Component Architecture
I. INTRODUCTION The advent of semantic web and the new communication technologies require finding new solutions for selfdeployment and self-adaptive distributed systems. On the other hand, the conventional design of software architecture from software engineering are insuffisient or inadequate in the context of knowledge engineering for a semantic web (commonly referred to as the Semantic Web initiative). Presently, overlaps between both fields are more and more apparent and many now acknowledge merit in a hybrid approach to IT systems development and deployment, combining Semantic Web technologies and techniques with more established development formalisms and languages like the Unified Modeling Language (UML).This is not only for the improvement of IT systems in general, but also for the future benefits of the Web, as systems and Web Services containing rich Semantic Web content start to come online. Taking into account these considerations, we propose a framework to design, to develop and to implement open networked multimedia systems. Our framework is based on the Ontology Driven Architecture (ODA) and on Service Oriented Architecture (SOA). We agree: (i) coupling ODA and SOA increases the self-deployment and self-adaptivity of a system in a semantic web environment, (ii) selfdeployment and self-adaptivity become mandatory for new multimedia web applications such as multimedia conferencing. This paper is organized as following. Second section introduces various driven oriented technologies and
multimedia frameworks providing the basis of the MODA framework. Section 3 presents our framework based on an Ontology Driven Architecture (ODA) dedicated to multimedia domain, following the approaches proposed by Model Driven Engineering and SOA. Section 4 details the Service Component Architecture ontology. Section 5 presents a Semantic Data Mapping (SDM) for distributed multimedia systems. Section 6 presents a study case aimed at illustrating how networked multimedia system can be dynamically deployed. Finally, section 7 presents the conclusions and perspectives II.
STATE OF THE ART
We present in this section an overview about Ontology Driven Engineering and Service Oriented Architecture. A. Ontology Driven Engineering The objective of a Model Driven Engineering (MDE) approach is to shift the complexity of the implementation of an application to the specification of this one. It is then a question of making an abstraction of the programming language using an abstract modeling process axed on the use of several standards such as MOF, OCL, UML and XMI. Model Driven Architecture [1,2] is a specific field of the MDE to specify architecture of 3 levels: • Representation of Computation Independent Model (CIM) from a business model. CIM describes the context in which the systems will be used. • Representation of Platform Independent Model (PIM) from CIM. It describes the system itself without any details of its use of its platform. A PIM will be suited for one or several real architectural platforms. • Representation of Platform Specific Model (PSM) from PIM. At this level, the environment of implementation platforms or languages is known. MDA allows designing a workflow based on the different mappings from CIM to PIM and from PIM to PSM. The mappings can be automated, particularly when a model type mapping specifies the mapping rules by a meta-model. In this manner, an MDA approach increases the interoperability in heterogeneous environments and provides a method of systems integration using generic mapping engines.
In recent years, the W3C Semantic Web Best Practices and Deployment working group has proposed to extend the MDA methodology by using semantic models or ontologies (i.e. RDF and OWL languages). This extension has been defined as the Ontology Driven Architecture (ODA) methodology [3]. ODA is aimed at extending MDA by providing representation of unambiguous domain vocabularies (e.g. requirements, constraints, services, properties, etc.), model consistency checking and validation as well as to enable new automatic software engineering capabilities. Several works have been carried out in order to illustrate how an ontology-based approach can be used in the design, development and management of distributed systems. For instance, in [4], an ontology-based application server has been designed allowing the design, development and management of software components. This ontology is aimed at describing the properties, relationships and behaviors of the software components. Based on this ontology, the components can be queried, preloaded, checked and composed during development as well as during run time. Another interesting application of ontologies within the MDA process is presented in [5], where ontologies are used to represent knowledge about platform diversity and how this information is used to perform safe configuration of refinement transformation between the platform models B. Service Oriented Architecture The Service Oriented Architecture (SOA) approach allows for the development of business process thanks to the aggregation of highly reusable services. The services are created in such way that they can easily adapt the way in which they function depending on the context in which they are being used. A simple redefined of the parameters of the business rules and master data that are used in the system is all that is needed to create a new variation of the initial function [6]. In order to improve the capabilities for automatic deployment, SOA approach can be used in order to better identify the services to be provided and composed in order to satisfy the requirements. The Service Component Architecture (SCA) is a set of specifications, which support the development of applications based on SOA. SCA proposes organizing in components the development and deployment of applications. Each component may offer services or need references in order to accomplish the offered services. The assembly of the components by interconnecting (wiring) services and references indeed allows building applications whether they are distributed or not, running in one process or multiple processes. In addition, SCA allows the implementation of the components in many languages like i.e. Java, C++, PHP, JavaScript, BPEL [7]. While the components are the base element in SCA, composites are the elements integrated by components. Composites may offer services through the promotion of components’ services, and may need other composites’ references. The remote access to composite’s services can be made through the use of bindings (e.g. Corba IIOP, web services, etc.). Finally, a set of interrelated composites within the same vendor's SCA implementation forms a Domain [8].
In order to describe a composite, SCA use the Service Component Definition Language (SCDL). SCDL is a XML based formatted language which allows characterizing the different components that form composites, and specify the relationships between them. SCDL works like a deployment descriptor for SCA applications. III. MULTIMEDIA ONTOLOGY DRIVEN ARCHITECTURE In this section, we introduce the MODA framework which aims to facilitate the spontaneous creation of ubiquitous multimedia systems and applications driven by user preferences (like application and/or user priorities). Figure 1 depicts the three levels CIM/PIM/PSM with the different integrated ontologies. The first level (CIM) embeds the various multimedia standard ontologies like ITU-F700 [9]. At the level PIM, we introduce IETF protocols, distributed multimedia systems ontology model and Service Components Architecture ontology. The last level (PSM) represents the different available implementations. All ontologies are expressed in OWL Web Ontology Language [10].
Figure 1. Multimedia Ontologies Driven Architecture
This framework is completed by a Semantic Data Mapping (SDM) [6]. SDM increases the level of abstraction and models transformations. It centralizes the knowledge of data transformation and integrates all necessary functionalities for its management. The mapping rules are expressed in XML and allow the ontologies alignment. In the next section, we detail the SCA ontology which is the main ontology to integrate the SOA approach in our MODA framework. IV.
SCA ONTOLOGY
The SCA Assembly Model defines the configuration of SCA domains using composites, components and the artifacts that allow describing how they are connected or linked. As a matter of fact there are no many concepts used in the SCA Assembly model in order to provide the SCA's programming model; namely SCA domain, composite, component, service, reference, properties, and wire. So we have developed a SCA ontology integrating all of these concepts, their relationships and properties.
A. OWL modelling SCA Figure 2 depicts our SCA ontology with its main classes. A such representation looks like UML representation. But, in OWL, properties describe binary relationships with metadata about reltionships. For each property hasX (e.g. hasComposite) in Figure 2, we define a inverse property isXOf (resp. isCompositeOf).
Figure 2. Main classes and properties of SCA ontology.
There are two main types of properties, Object properties and Datatype properties. Datatype properties describe relationships between individuals (i.e. instances in UML) and data values. Object properties describe relationships between two individuals of classes. The different kind of Object properties are: • functional; if a property is functional, for a given individual, there can be at most one individual that is related to the individual via the property. For example, hasComposite is functional property. • inverse functional; if a property is inverse functional then it means that the inverse property is functional. For example, isCompositeOf is inverse property of hasComposite. So, isCompositeOf is inverse functional. • transitive; if a property is transitive, and the property relates individual i1 to individual i2, and also individual i2 to individual i3, then we can infer that individual i1 is related to individual i3 via property P. • symmetric; if a property P is symmetric, and the property relates individual i1 to individual i2 then individual i2 is also related to individual i1 via property P.
•
asymmetric; if a property P is antisymmetric, and the property relates individual i1 to individual i2 then individual i2 cannot be related to individual i1 via property P. For example, hasComposite, hasComponent are antisymmetric. • reflexive; a property P is said to be reflexive when the property must relate individual i to itself. irreflexive; if a property P is irreflexive, it can be described as a property that relates an individual i1 to individual i2, where individual i1 and individual i2 are not the same. For example, hasComposite, hasComponent are irreflexive. Properties may have a domain and a range specified. Properties link individuals from the domain to individuals from the range. For example, the property hasComponent links individuals belonging to the class SCADomain to individuals belonging to the class of Composite. The domain of hasComposite is SCADomain and the range is Composite. Domains and ranges are used as “axioms” in reasoning. Then, restrictions describe classes of individuals. Existential restrictions describe classes of individual that participate in at least one relationship along a specified property to individuals that are members of a specified class (noted some in Protégé editor [11]). For example, the class of individuals (SCADomain) that have at least one (some) hasComposite relationship to members of class Composite. Universal restrictions describe classes of individuals that for a given property only have relationships along this property to individuals that are members of a specified class (noted only in Protégé). For example, the class of individuals (Composite) that only have hasComposite relationships to members of class Component B. Using Reasoners A key part of working with OWL ontologies is reasoning. Reasoners are used to check the consistency of ontologies, check to see whether the signature of an ontology contains unsatisfiable classes, compute class and property hierarchies, and check to see if axioms are entailed by an ontology. The main used reasoners are Pellet, FaCT++, Racer [12]. On the other hand, a distributed system is composed of a set of ontologies, connected by ontology alignments. An ontology alignment describes semantic relations between ontologies. In our context, we need to use algorithm based on Distributed Description Logics (DDL) [13] via an OWL API such as OWLlink. OWLlink interface provides an implementation-neutral mechanism for accessing OWL reasoner functionality [14]. V. S EMANTIC DATA MAPPING (SDM) SDM is a set of mapping rules between the different ontologies. These rules are XSL alignments. Due to the limitation space, we present in this section the mapping rules concerning the different communication tasks in multimedia context. The different possibilities to deploy multimedia system are resumed in Table 1.
TABLE I.
COMMUNICATION T ASKS FOR M ULTIMEDIA APPLICATION Communication Tasks
Communication configuration Point to point
bidirectional
Conversing
Point to multipoint
Unidirectional, from consumer
Sending
receiving
distributing
Multipoint to point Multipoint to multipoint
Unidirectional , from producer
collecting conferencing
Consequently, our multimedia ontology produces the following templates: 1) sending: The generic communication task sending implies the creation of two composites in SCA domain corresponding to source (producer in SCA) and sink (consumer) entities and a flow communication from source to sink. So, we design one composite for each users. Each composite includes one component using RTP protocol and one media controller component. The mapping rules apply the templates based on Table 1 to generate a new following SCA ontology individual such as: ... ... ... ... ... ... ...
2) receiving: The communication configuration is pointto-point, the flow information is unidirectional. The different properties of generic receiving communication implies the creation of composites using http protocol for source and sink as follow: ... … ... ... ... ... …
... ...
3) conversing: At flux level, it exists two flows between source and sink. Source controls the flow but sink sends also a flows to source. The communication delay is realtime and the temporal continuity is isochronous. So, these implies the creation of composites using RTP protocol. The structure is the same as sending on source side and on sink side. Moreover, the specific properties of multimedia applications are real-time and isochronous. All media is possible (with option no by default). Relations between media are symmetric between media with same type to allow bidirectional flow and synchronisation between audio and video (lip, audio stereo), audio and text (vocal synthesis), text and video/picture/graphs (subtitles synchronised with pictures). The generic communication task conversing implies the creation of two composites in SCA domain corresponding to source and sink entities and a flow communication from source to sink and vice versa. So, we design one composite for each users. Each composite includes one component using RTP protocol and one media controller component. MODA generates a new following SCA ontology individual: ... ... ... ... ... ...
4) Distributing: In this case, the communication configuration is point-to-multipoint and the flow information symmetry is unidirectional. One user controls the flow and n-1 users are sinks. All media can be used. At flux level, these implies the creation of composites using RTP protocol. So, the generic communication task distributing implies the creation of n composites in SCA domain corresponding to one source and n-1 sinks entities and a flow communication from source to each sink. So, we design one composite for each users. Each composite includes one component using RTP protocol and one media controller component. MODA generates a new following SCA ontology individual:
... …
