Adaptation de flux de données avec MMSA

Au cours du processus de création de l’architecture, la prise en compte de l’adaptation pour résoudre le problème d’hétérogénéité des éléments de l’architecture (composant, connecteur et configuration) est faite en trois étapes successives : (I) adaptation de types (Transmoding) (II) adaptation de formats (Transcoding) (III) adaptation de propriétés (Transforming). Nous partons du plus générique au plus

« MMSAGlu » Communication G Ad GQdS

Composant 1

Composant 1

« MMSAGlu » Communication G Ad GQdS « MMSAGlu » Communication G Ad GQdS

Page 77

spécifique (top down), ce choix s’explique par le fait qu'un type inclut plusieurs formats, et qu’un format peut avoir plusieurs propriétés.

Sound Text Composant1 Composant2 Video Video Composant3 Composant4 Image Image Composant5 Composant6 MPEG 3GP JPEG resolution 800 X 600 resolution 1280 X 768 Étape 1 Étape 2 Étape 3

Figure 2.8. Présentation des types d’hétérogénéités entre composant

Le flux est un constituant essentiel des composants fonctionnels, il est souvent spécifié comme contrainte à associer à une fonctionnalité de communication pouvant impliquer plusieurs composants. Les contraintes de flux telles que le type, le format et les paramètres du média doivent être spécifiées au niveau architectural. Pour cela, nous considérons un nouveau type de composant destiné à assurer un aspect non-fonctionnel : celui de l’adaptation. On l’appelle connecteur d’adaptation des données multimédia échangées entre composants.

La détection d’hétérogénéités se fait automatiquement par la vérification des contraintes de formes et de couleurs. Par exemple un port de type «Text» doit être lié seulement avec un port de type «Text» ayant le même format multimédia. Il en va de même pour les autres types.

4.1. Adaptation de types

L’hétérogénéité des composants qui manipulent des médias de types différents est détectée par l’utilisation des formes différentes pour représenter les ports des composants (étape 1, figure 2.8). Donc, deux composants qui n’ont pas les même ports (exemple : port Texte et port Son) ne peuvent être reliés qu’avec l’utilisation d’un ou plusieurs connecteurs d’adaptation de type (cf. figure 2.9). Ce problème sera résolu par l’intégration des connecteurs de transmodage au niveau architectural.

Figure 2.9. Connecteur de transmodage texte vers audio

Connecteur d’adaptation Texte

vers Son

Composant 2 Composant 1

Page 78

4.2. Adaptation de formats

L’hétérogénéité des composants qui manipulent le même type de média mais avec des formats d’encodage différents (étape 2, figure 2.8) peut être détecté par la présence de couleurs différentes entre les formats du même type. Donc, deux composants qui n’ont pas la même couleur pour le même port (exemple : port vidéo avec couleur rouge .MPEG et bleue .3GP) ne peuvent être reliés que par l’utilisation d’un ou plusieurs connecteurs d’adaptation de format (cf. figure 2.10). Ce problème sera résolu par l’intégration de connecteurs de transcodage au niveau architectural.

Figure 2.10. Connecteur de transcodage MPEG vers 3GP

4.3. Adaptation de propriétés

L’hétérogénéité des composants qui manipulent le même type de média ayant le même format (étape 3, figure 2.8) mais avec des propriétés différentes (exemple : résolution et couleur pour l’image, vitesse et échantillonnage pour la vidéo, etc.) ne peut pas être exprimée visuellement dans notre architecture en raison du nombre important de paramètres qui dépendent du média et du service d’adaptation (paramètres du service). Donc, deux composants qui ont la même couleur pour le même port (exemple : port Image) peuvent être reliés avec un simple connecteur de communication et, lors de l’exécution, le gestionnaire d’adaptation et le gestionnaire de qualité de service gèrent ensemble l’adaptation. A ce niveau le problème d’hétérogénéité sera résolu à l’exécution par une manipulation des paramètres du service d’adaptation, s’il est paramétrable, en fonction du flux produit par le service. Dans le cas contraire, on adoptera un changement de service d’adaptation.

Figure 2.11. Connecteur d’adaptation de contenu image

Le service d’adaptation est paramétré pour qu’une adaptation puisse être appliquée dans différentes situations. Il est appliqué dans plusieurs contextes, par exemple, pour l’adaptation de la résolution d’une image (cf. figure 2.11). Adaptation de contenu Paramètres d’image : -Résolution -Nombre de couleurs Paramètres de service d’adaptation : -taux de compression -Etc. Composant 1 « MMSA Glu » Communication GAd GQdS Composant 2 Connecteur d’adaptation Vidéo vers Vidéo

Page 79

Eléments d’implantation de l’architecture MMSA

Il est largement admis qu’un composant « ne peut être accessible que via des interfaces bien définies» [SZY02]. Ces interfaces lient les composants avec l’environnement. Les langages de description d’architecture proposent des concepts différents pour décrire les interfaces : des éléments tels que les services, les ports, les interfaces, les protocoles, ayant parfois des significations différentes. Par exemple, dans Fractal [BRU04] ou dans Enterprise JavaBeans [MON99], les concepts de port et d'interface sont mélangés c'est pourquoi on ne parle que d’interfaces. Dans les composants UML [CHE00], les deux concepts de ports et d'interface existent comme dans ArchJava [ALD02] où les interfaces sont appelées port d’interfaces. C'est pourquoi nous avons choisi d'expliquer clairement les choix que nous avons faits pour MMSA. En MMSA, un composant fournit ou requiert des services par les ports décrits dans l’interface fournie/requise. Ainsi, MMSA propose un typage de ports pour les différencier selon le type de média manipulé (Texte, Son, Vidéo, Image).

1.

Composants MMSA

Les composants sont les éléments de base (au sens brique logicielle) à partir de laquelle une application MMSA est créée. Comme les atomes, les composants MMSA se comportent de façon cohérente avec les connecteurs d’adaptation et ils peuvent être assemblés en différentes configurations.

Figure 2.12. Modèle de composant multimédia

Un composant est une instance d'une application qui a été correctement configurée. La mise en œuvre est le code qui réalise effectivement les fonctions du composant, comme une classe Java ou un processus BPEL (Business Process Execution Language). Un composant MMSA fournit des fonctionnalités nommées services. Fondamentalement, un service est un sous-programme défini dans un programme ou une méthode dans le modèle orienté objet. Pour décrire un composant MMSA, nous devons définir les concepts d’interface, de port, de service et de domaine qui permettent la modélisation des lieux d’exécution des composants et donc la distribution des composants.

Output ports Input ports Business component Constraints of flow Input Int e rf a ce Multimedia flow Supervisor Multimedia flow Container Service 1 Service n Service 2 O ut put In te rf a ce

Page 80

1.1. Interfaces - composants

De façon générale, les interfaces sont un support de description des composants permettant de spécifier comment ils peuvent être assemblés ou utilisés au sein d’une architecture. Les interfaces se situent soit à un niveau local (associées à un port) soit à un niveau global (associées à un composant). Les interfaces de composants en MMSA sont vues comme les points de connexion des composants et sont le support des invocations de services. Le concept de port est utilisé pour représenter les échanges de données via les interfaces des composants.

• Ports (Fourni et Requis)

«Un composant est une abstraction statique avec plugins» [NIE95]. Les ports représentent ces plugins qui sont les points d'interaction des composants. Cela signifie que tout passe par ces ports, comme l'invocation de services par exemple. Le port est présent dans presque tous les modèles de composants mais avec différentes sémantiques. Lorsque les ports sont unidirectionnels comme dans ComponentJ [SEC00] ou Fractal [BRU04], un composant fournit ou requiert l’ensemble de services via ses ports. En ArchJava [ALD02] ou UML 2.0 [CHE00] les ports sont bidirectionnels et un composant requiert et fournit à la fois des services à travers chacun de ses ports.

Dans MMSA les ports sont unidirectionnels parce qu’un port peut fournir/requérir des données via/à partir des connecteurs. Ces derniers peuvent appliquer des adaptations sur les données et, généralement, les services d’adaptation ne sont pas bidirectionnels (cf. Figure 2.13, le service d’adaptation du texte vers le son n’est pas le même que celui d’adaptation du son vers le texte).

Figure 2.13. Connecteur de transformation TexteToAudio

Figure 2.14. Connecteur de transformation AudioToTexte

La figure 2.14 montre qu’il est impossible d’utiliser le connecteur d’adaptation audioToText pour assurer l’adaptation inverse (TextToAudio). Il faut donc recourir à un autre connecteur avec un autre service qui n’est pas toujours disponible et/ou faisable.

Composant 2 « MMSAGlu » Communication G Ad GQdS Composant 1 Composant 2 « MMSAGlu » Communication G Ad GQdS Composant 1

Page 81

• Services

Un service est une fonctionnalité assurée par le composant, il possède un ensemble de paramètres qui permet d’en maîtriser les sorties. L’ensemble de ces paramètres avec les arguments (paramètres d’appel) décrit l’interface du service qui communique avec l’extérieur via les ports fournis/requis du composant.

Figure 2.15. Modélisation des services et de leurs paramètres dans MMSA

On peut dire qu’un service est une fonction définie à l’intérieur d’un composant et offerte aux autres composants pour qu’ils puissent l’invoquer. Les paramètres de services et le passage des arguments lors de l’invocation de service soulèvent de nombreuses questions : Qu’est-ce qu’un paramètre ? A-t-on réellement besoin de paramètres ? Quelle est la différence entre argument et paramètre ?

Dans MMSA, les arguments sont les éléments nécessaires à l’exécution d’un service (la variable, terme ou expr ession sur laquelle un service opère), alors que les paramètres sont les éléments de contrôle de QdS. (e.g. un service qui permet la transformation d’une image BMP en JPEG reçoit en argument une image Bitmap et en paramètre le taux de compression).

1.2. Domaine

Les domaines sont un concept important, ils définissent la disposition et la distribution des composants sur les différentes machines (Téléphones portables, PDA, Ordinateurs de bureau ou portables, etc.). Un domaine peut contenir un ou plusieurs composites chacun ayant des composants mis en œuvre dans un ou plusieurs processus s'exécutant sur une ou plusieurs machines [CHA07]

La notion de domaine telle qu’elle est présentée dans SCA [CHA07] est utilisée dans MMSA, cette notion permet de prendre en considération des contraintes sur l’environnement d’exécution, afin de fournir un bon service à la machine qui exécute le composant (e.g. un composant d’affichage de vidéo à besoin de connaitre les contraintes de la machine sur laquelle il va s’exécuter pour pouvoir adapter la résolution ou la vitesse par exemple)

.

La figure 2.16 montre un domaine avec trois machines et huit composants. En haut à gauche, trois composants s’exécutent dans un seul processus, à droite on trouve deux composants qui s’exécutent dans

Data flow Data flow

Component

Service1 Service2 Service3 Input Port

Output Port Service

Page 82

deux processus différents mais sur la même machine. Au dessous, trois composants dans deux processus qui s’exécutent sur la même machine.

Figure 2.16. Exemple de la notion du domaine

Un domaine est composé de plusieurs machines, chaque machine est chargée de l'exécution de plusieurs processus et chaque processus peut contenir un ou plusieurs composants (cf. figure 2.17).

Figure 2.17. Modélisation du concept de Domaine

La notion de domaine est importante dans MMSA, pour le choix des connecteurs et des services d’adaptation permettant la prise en compte des contraintes de l’environnement au moment de la conception de l’architecture d’une application.

2.

Connecteur MMSA

Permettre à des composants hétérogènes d'interagir les uns avec les autres est une tâche non négligeable. L'adaptation est considérée comme un besoin non-fonctionnel d'un composant. Cette tâche doit être assurée par un autre élément. Le connecteur fournit les aspects non-fonctionnels (communication, adaptation, sécurité, etc.) dont le composant a besoin. Le rôle du connecteur d’adaptation est de recevoir les données, de les adapter selon les directives du gestionnaire de QoS et de les acheminer vers le composant/connecteur destinataire.

Domain

Process Device

Domain Machine

Process Execute Component

1 1 1..* 1..* 1..* 0..*

Page 83

Comparés à ceux des langages de description d’architectures [ALL97a] [MEH00], les connecteurs que nous proposons peuvent être simples ou composés et peuvent même assurer des services. Autrement dit, ces connecteurs n’assurent pas uniquement les liens de communications mais également l’adaptation des données échangées entre composants. Dans notre approche, le connecteur constitue l’entité de communication et d’adaptation, c'est-à-dire qu’il est capable de transférer des données multimédia entre les différents composants tout en assurant l’adaptation de ces dernières.

Figure 2.18. Relation composant, service et connecteur

La figure 2.18 montre qu’un service est proposé pour satisfaire un besoin : il peut être proposé par un composant (besoin fonctionnel), un connecteur (besoin non-fonctionnel) ou comme un service d’adaptation (besoin d’interaction). Un connecteur d’adaptation est composé d’un ensemble de services d’adaptation et peut être lié à d’autres composants non MMSA (eg. Web service). C’est un connecteur spécifique entre deux composants hétérogènes.

Un connecteur d’adaptation sert à satisfaire un besoin non-fonctionnel d’un composant, ce besoin est détecté lors de l’assemblage des composants, il s’agit d’une incompatibilité des flux de données échangés entre les composants d’une même configuration, cette incompatibilité est qualifiée d’hétérogénéité sémantique.

L’hétérogénéité est causée par l’utilisation de données de nature différentes (le son, le texte, l’image et la vidéo) ou l’échange de données de différents types et formats ou les caractéristiques physiques des composants de présentation de l’information. La solution que nous proposons est basée sur l’adaptation des flux échangés entre composants hétérogènes, il s’agit d’une adaptation assurée par les connecteurs lors de la communication. Cette solution permet d’éviter de devoir rechercher des composants compatibles en matière de flux, et d’éviter des reconfigurations des applications et des réassemblages de composants qui peuvent engendrer des problèmes d’incohérence. Il existe plusieurs techniques et services d’adaptation qui dépendent du type ou du format de média. Celles qui nous intéressent sont l’adaptation

1..* 1 2 Connecteur MMSA Utilise 1..* 1..* Composant MMSA Service d'adaptation Service Interface 1..* 1 Adaptateur Composant Non-MMSA Glu QdS Communication 1 1 1 Attachement 1 1 Liaison 1

Page 84

de type (transmodage), l’adaptation de format (transcodage), et la transformation, ainsi que la gestion des paramètres des services d’adaptation qui représentent les différentes qualités produites par ces services.

Transmoding connector

Connector V-I Connector V-S Connector S-T Connector T-S

Connector T-I Connector I-V Connector S-V

Transcoding connector

Connector Image Connector Sound Connector Video Connector Text

Adaptation connector Glu Interface 1 1 1 2

Image Role Sound Role Video Role Text Role

1 2 1 2 1 2 1 2 1 1 Mng Com Mng ada Mng QoS 1 1 1 1 Adaptation service Parametre of Service 1 * 1 * «uses» Transforming connector

Figure 2.19. Présentation des types de connecteurs d’adaptation

Il existe plusieurs types de connecteurs d’adaptation (figure 2.19) qui dépendent des types et des formats de données. Un connecteur d’adaptation est constitué d’une glu et de deux interfaces, une pour les entrées et l’autre pour les sorties. Chaque interface contient des rôles, le type des rôles dépend du service d’adaptation, par exemple, un connecteur de transformation de format d’image contient deux rôles de type image, un pour l’entrée et un pour la sortie. Les connecteurs d’adaptation ont la même structure pour la glu qui est composée de trois composants (communication, adaptation, QdS), la seule différence se situe au niveau du type des rôles (image, texte, son, vidéo).

Tous les connecteurs, même ceux affectés à la communication, ont la même structure interne. La seule différence entre les connecteurs se situe au niveau des rôles qui permettent la connexion avec des composants qui ont les mêmes ports. Cette distinction offre deux avantages :

1) Lors de l’exécution on peut demander au connecteur de communication d’assurer une tâche d’adaptation de format pour satisfaire un nouveau besoin lié à un nouveau contexte d’exécution.

Page 85

2) Une gestion de la qualité de service assure l’adaptation suivant les besoins et le contexte, et le changement éventuel du service d’adaptation dans le cas où ce service n’est pas capable de fournir la qualité demandée.

Figure 2.20. Modèle de connecteur d’adaptation Pour le 1er

1)-

point prenons l’exemple d’un utilisateur qui voyage dans un train et qui veut regarder un match de foot. Pour cela il utilise son téléphone portable qui se connecte directement à un composant d’acquisition et de diffusion via un connecteur. Le connecteur assure la connexion et la communication entre les deux composants (cf. figure 2.21, 1). Après une demi-heure l’utilisateur a remarqué un problème d’énergie et pense que la batterie ne tiendra pas jusqu’à la fin du match. Il décide de ne garder que le son afin d’écouter le match jusqu'à la fin. La solution idéale est d’installer un service d’adaptation au niveau du connecteur pour faire l’extraction du son à partir de la vidéo, et n’envoyer que le son à l’utilisateur (cf.

figure 2.21, 2).

2)-

Figure 2.21. Exemple de modification de service du connecteur d’adaptation lors de l’exécution

Concernant le 2eme point, le tableau suivant présente la représentation textuelle d’un connecteur sans service d’adaptation et d’un connecteur avec service d’adaptation :

Output roles Input roles Constraints flow Multimedia flow Multimedia flow O u tp u t i n te r fa c e Inp ut i nt e r fa c e Supervisor Qos manager Communication manager Adaptation manager Glue Camera Communi cation Glu Camera QoS Communication Adaptation Glu

Page 86

Connecteur de communication Connecteur d’adaptation Class Adaptation-connector {

Properties {flow =} Service {Connection}

Glue { //simple case of a glue Communication {Synchronous}

Adaptation service {} QoS {}}

Interface {

Required-Roles {category A} Provide-Roles {category A}}

}

Class Adaptation-connector {

Properties {flow = proprieties of data} Service {Connection, adaptation}

Glue { //adaptation glue Communication {Synchronous}

Adaptation service {service of adaptation} QoS {parameters of adaptation}}

Interface {

Required-Roles{category A or category B} Provide-Roles{category A or category B}}

} • Rôles (Fourni et Requis)

Il existe deux catégories de connecteurs d’adaptation :

Connecteur de format : Cette catégorie regroupe les connecteurs qui ont le même type de rôle pour l’entrée et la sortie. Les connecteurs appartenant à cette catégorie sont regroupés dans le tableau suivant :

Connecteur d’adaptation de format Représentation graphique Classe de connecteur Connecteur-Image : ce connecteur est responsable des

adaptations de transcodage entre médias de type image.

Class Image-connector {

Service {Connection, adaptation} Glue { Communication service {} Adaptation service {} QoS {}} Interface { Required {Input-Role-Image} Provide { Output-Role-Image }} } Connecteur-Texte : ce connecteur est responsable des

adaptations de transcodage entre médias de type texte.

Class Text-connector {

Service {Connection, adaptation} Glue { Communication service {} Adaptation service {} QoS {}} Interface { Required {Input-Role-Text} Provide { Output-Role-Text}} } Connecteur-Son : ce connecteur est responsable des adaptations de transcodage entre médias de

type son.

Class Sound-connector {

Service {Connection, adaptation} Glue { Communication service {} Adaptation service {} QoS {}} Interface { Required {Input-Role-Sound} Provide { Output-Role-Sound}} } Connecteur-Vidéo : ce connecteur est responsable des

adaptations de transcodage entre médias de type vidéo.

Class Video-connector {

Service {Connection, adaptation} Glue { Communication service {} Adaptation service {} QoS {}} Interface { Required {Input-Role-Video} Provide { Output-Role-Video}} } Image Text Sound Video

Page 87

Connecteur de type : Cette catégorie regroupe les connecteurs qui n’ont pas le même type de rôle pour l’entrée et la sortie. Le tableau suivant présente quelques exemples de connecteurs appartenant à cette catégorie sont regroupés dans le tableau (la liste des connecteurs n’est pas exhaustive)

Connecteur d’adaptation de type Représentation graphique

Connecteurs permettant d’assurer des adaptations sémantiques entre des médias de

différents types. Ce type d’adaptation s’appelle le transmodage.

• Services d’adaptation

Le connecteur assure la communication entre deux composants (même hétérogènes) à partir des services fournis par des composants ou des fournisseurs de service, suivant la qualité exigée par le gestionnaire de QdS. Component 1 Connector Text2Sound Component 2 Fournisseur de service Texte Sound

Figure 2.22. Relation Connecteur-Fournisseur

Le service d’adaptation est chargé de participer à la réalisation d’une adaptation de données échangées par des composants. La représentation d’un composant par un ensemble de services rend possible l’utilisation de ces services pour des tâches d’adaptation (cf. figure 2.22). Le mécanisme de cette utilisation ressemble à l’utilisation de Web Services en considérant les composants comme fournisseurs de services locaux. Video to Sound Sound to Text Text to Sound Text to Image Video to Image Sound to Video Sound to Video

Page 88

Figure 2.23. Utilisation de services des composants pour assurer l’adaptation

Deux mécanismes peuvent être exploités ici : La composition de services telle que définie dans Kmelia [ATT06] et la notion de bibliothèque de composants telle que définie dans Fractal [COU06].

- La composition crée une relation de structuration hiérarchique (inclusion) qui permet de définir de nouveaux services à partir de services existants. La disponibilité de mécanismes de composition de services facilite la définition de nouvelles abstractions de services sans passer nécessairement par l’introduction de nouveaux composants. Pour cette composition de services, le concept d’inclusion « Include » défini par un diagramme de cas d’utilisation a été utilisé dans

Dans le document Modelisation et implementation d’un systeme d’information de gestion de flux multimedia pour des architectures logicielles integrant des appareils sans-fil mobiles (Page 78-91)