Anis Masmoudi - Institut Superieur d'Informatique et des Techniques ...
Anis Masmoudi - Institut Superieur d'Informatique et des Techniques ... Anis Masmoudi - Institut Superieur d'Informatique et des Techniques ...
Figure 2. Modèle des services extrait de l’ontologie des spécifications SOCOM4. La structure XML de correspondanceL’idée de cette structure de correspondance provient du besoin d’agréger un ou plusieurs servicesde composants logiciels pour chaque activité du scénario d’apprentissage. Ces services peuventêtre de différentes catégories dépendamment du besoin de l’expert (Concepteur pédagogique dansnotre cas) qui développe l’ontologie du scénario de domaine. On distingue les servicesd’affichage par des interfaces usagers – appelée aussi services de présentation – des services detraitements ou des services de données. Il est important de savoir que cette structure decorrespondance sera instanciée par un ingénieur intégrateur et qu’elle sera validée ultérieurementpar l’expert au moment de l’exécution. Ce dernier utilise actuellement un simple client Java quilui permet d’interroger aussi bien l’ontologie des spécifications IMS-LD qui décrit le scénarioque celle de SOCOM[7].La Figure 3 montre la structure XML de correspondance. Dans le premier fragment, nousdéclarons les identificateurs des composants « componentId » qui interviennent dans laconstruction du scénario. Puis, pour chaque activité, nous listons dans un ordre logique lesservices qui l’implémentent. Pour développer le scénario au complet, nous avons associé àchacun des activités de la section 2 une combinaison des services listés dans la Table 1. Noussupposons que les composants existants fournissent une liste complète pour réaliser les scénariosdu laboratoire en ligne conçus. Nous prenons l’exemple de l’activité « A4 » (l’apprenant 2affiche le signal modifié à l’aide des interfaces dédiées) qui nécessite, dans l’ordre, les servicessuivants : C1 :S12 (Récupérer le signal modifié), C3 :S31 (Associer le signal au générateur defonction) et C4 :S41 (Afficher le signal dans une interface de visualisation). … …… ……Figure 3. La structure XML de correspondance4
5. Le scénario de la conception à l’exécutionNous appelons agrégat le fichier de correspondance en XML de la section 4 qui implémente notrescenario du domaine. Une fois ce fichier XML instancié, nous le transformons en un fichierBPEL 8 . Ce dernier représente l’agrégat exécutable. En effet, BPEL est un langage d’exécution deprocessus métiers. Et dans notre cas, le processus métier n’est autre que le scénario du domaine.Ce fichier BPEL est un fichier XML indépendant des plateformes BPEL. Il peut être exécuté dansn’importe quels serveurs BPEL tels que « Oracle BPEL Server 9 » et ActiveBPEL 10 . Nous avonsrécemment implémenté trois types d’agrégation avec BPEL [6].6. Conclusion et perspectivesCet article nous a permis de décrire une méthode de développement des scénarios dans lecontexte des laboratoires en ligne en nous appuyant sur deux ontologies existantes, une structurede correspondance et un langage d’exécution des processus métiers, soit BPEL. La structureXML de correspondance peut paraître inutile, vu qu’il est possible de construire le fichier BPELdirectement à partir des deux ontologies. Le choix de cette structure intermédiaire nous permettrad’implémenter nos scénarios dans d’autres langages d’exécution de processus métier« workflow » tel que XPDL 11 par exemple.En résumé, pour développer notre scénario, nous avons adopté simultanément deux approches,descendante et ascendante « top-down » et « bottum-up ». La première consiste à partir desbesoins du domaine et les exprimer dans un langage naturel (Voir Section 2). Cette approche nousproduit une instance de l’ontologie du domaine (Figure 1). La deuxième approche est une rétroingénieriequi part du code des composants pour modéliser l’ensemble des services fournis àl’aide de SOCOM. Cette approche, nous procure une instance de l’ontologie des servicestechniques fournis par les composants (voir Section 3). Nous utilisons ces deux instances pourconstruire notre fichier d’agrégation XML de correspondance. Ce dernier nous sera utile pourgénérer le fichier de l’agrégat exécutable en utilisant le langage BPEL.Dans nos travaux futurs, nous essayons de concevoir des interfaces usagers conviviales pourl’ingénieur intégrateur qui supporteront les différentes étapes de cette méthode. Nous étudionsactuellement la possibilité de remplacer la structure de correspondance d’une simple structureXML par une ontologie. Cette dernière s’alimentera par plusieurs référencements des ontologiesqui implémentent les spécifications du domaine (IMS-LD) et les spécifications techniques descomposants logiciels (SOCOM). En fait, le choix d’une ontologie de correspondance se justifiepar notre volonté d’interroger intelligemment [7], l’ontologie de correspondance existante,l’ontologie du domaine et l’ontologie technique pour construire les nouveaux scénarios. Cecipermet la réutilisation optimisée des correspondances existantes. Ces interrogations sont possiblesà l’aide des moteurs d’inférence qui offrent les services de raisonnement sur les ontologies. Ainsi,nous aidons l’expert du domaine (concepteur pédagogique) et l’ingénieur intégrateur dans leprocessus de développement des scénarios de laboratoire en ligne en se basant sur des ontologies8 BPEL (Business Process Execution Language): http://www-128.ibm.com/developerworks/library/specification/wsbpel/9 Oracle BPEL Server: http://www.oracle.com/technology/products/ias/bpel/index.html10 ActiveBPEL : un serveur d’exécution BPEL, http://www.activebpel.org/11 XPDL (XML Process Definition Language): www.wfmc.org/standards/XPDL.htm5
5. Le scénario de la conception à l’exécutionNous appelons agrégat le fichier de correspondance en XML de la section 4 qui implémente notrescenario du domaine. Une fois ce fichier XML instancié, nous le transformons en un fichierBPEL 8 . Ce dernier représente l’agrégat exécutable. En eff<strong>et</strong>, BPEL est un langage d’exécution deprocessus métiers. Et dans notre cas, le processus métier n’est autre que le scénario du domaine.Ce fichier BPEL est un fichier XML indépendant <strong>des</strong> plateformes BPEL. Il peut être exécuté dansn’importe quels serveurs BPEL tels que « Oracle BPEL Server 9 » <strong>et</strong> ActiveBPEL 10 . Nous avonsrécemment implémenté trois types d’agrégation avec BPEL [6].6. Conclusion <strong>et</strong> perspectivesC<strong>et</strong> article nous a permis de décrire une méthode de développement <strong>des</strong> scénarios dans lecontexte <strong>des</strong> laboratoires en ligne en nous appuyant sur deux ontologies existantes, une structurede correspondance <strong>et</strong> un langage d’exécution <strong>des</strong> processus métiers, soit BPEL. La structureXML de correspondance peut paraître inutile, vu qu’il est possible de construire le fichier BPELdirectement à partir <strong>des</strong> deux ontologies. Le choix de c<strong>et</strong>te structure intermédiaire nous perm<strong>et</strong>trad’implémenter nos scénarios dans d’autres langages d’exécution de processus métier« workflow » tel que XPDL 11 par exemple.En résumé, pour développer notre scénario, nous avons adopté simultanément deux approches,<strong>des</strong>cendante <strong>et</strong> ascendante « top-down » <strong>et</strong> « bottum-up ». La première consiste à partir <strong>des</strong>besoins du domaine <strong>et</strong> les exprimer dans un langage naturel (Voir Section 2). C<strong>et</strong>te approche nousproduit une instance de l’ontologie du domaine (Figure 1). La deuxième approche est une rétroingénieriequi part du code <strong>des</strong> composants pour modéliser l’ensemble <strong>des</strong> services fournis àl’aide de SOCOM. C<strong>et</strong>te approche, nous procure une instance de l’ontologie <strong>des</strong> servicestechniques fournis par les composants (voir Section 3). Nous utilisons ces deux instances pourconstruire notre fichier d’agrégation XML de correspondance. Ce dernier nous sera utile pourgénérer le fichier de l’agrégat exécutable en utilisant le langage BPEL.Dans nos travaux futurs, nous essayons de concevoir <strong>des</strong> interfaces usagers conviviales pourl’ingénieur intégrateur qui supporteront les différentes étapes de c<strong>et</strong>te méthode. Nous étudionsactuellement la possibilité de remplacer la structure de correspondance d’une simple structureXML par une ontologie. C<strong>et</strong>te dernière s’alimentera par plusieurs référencements <strong>des</strong> ontologiesqui implémentent les spécifications du domaine (IMS-LD) <strong>et</strong> les spécifications techniques <strong>des</strong>composants logiciels (SOCOM). En fait, le choix d’une ontologie de correspondance se justifiepar notre volonté d’interroger intelligemment [7], l’ontologie de correspondance existante,l’ontologie du domaine <strong>et</strong> l’ontologie technique pour construire les nouveaux scénarios. Ceciperm<strong>et</strong> la réutilisation optimisée <strong>des</strong> correspondances existantes. Ces interrogations sont possiblesà l’aide <strong>des</strong> moteurs d’inférence qui offrent les services de raisonnement sur les ontologies. Ainsi,nous aidons l’expert du domaine (concepteur pédagogique) <strong>et</strong> l’ingénieur intégrateur dans leprocessus de développement <strong>des</strong> scénarios de laboratoire en ligne en se basant sur <strong>des</strong> ontologies8 BPEL (Business Process Execution Language): http://www-128.ibm.com/developerworks/library/specification/wsbpel/9 Oracle BPEL Server: http://www.oracle.com/technology/products/ias/bpel/index.html10 ActiveBPEL : un serveur d’exécution BPEL, http://www.activebpel.org/11 XPDL (XML Process Definition Language): www.wfmc.org/standards/XPDL.htm5
Change language