Proposition1

Les supports d’exécution (middleware) sont des couches logicielles intermédiaires permettant de faire communiquer plusieurs nœuds distants d’une application. Ils ont été introduits pour minimiser le coût (en temps et en argent) de conception des applications réparties. Comme l’indique leur nom, les supports d’exécution se placent entre le matériel (y compris le système d’exploitation) et le logiciel (restreint au code de l’utilisateur). Dans certains cas, l’intergiciel implante toutes les fonctionnalités requises d’un système d’exploitation (concurrence..). Ainsi, au lieu d’avoir le code d’une application répartie qui s’interface directement avec les primitives du système d’exploitation ou le matériel (pour gérer la communication entre les noeuds de l'application par exemple), l’application invoque des primitives du support d’exécution qui sont de plus haut niveau et qui offrent une portabilité à son code.
Ce PFE vise à implanter un support d’exécution qui permet l’exécution des systèmes embarqués temps réels à base de composants. L’implantation sera faite par le langage Java ou le langage C.

Proposition2

Un grand intérêt a été porté aux Systèmes publier/souscrire pour permettre la propagation de l’information dans un système distribué appartenant à un réseau à large échelle. Ces systèmes sont actuellement utilisés dans plusieurs contextes d’applications distribuées et font l’objet de plusieurs travaux de recherche. L’un des domaines de recherches qui considèrent ces systèmes est leur déploiement sur des réseaux mobiles ad-hoc, appelés généralement MANET. Ces derniers consistent en une grande population d’unités mobiles se déplaçant dans un domaine quelconque et dont le seul moyen de communication est l’utilisation des interfaces sans fil, sans l’aide d’une infrastructure préexistante ou administration centralisée. Ces réseaux sont caractérisés par une topologie dynamique, une bande passante limitée, des contraintes d’énergie, une sécurité physique limitée, et l’absence d’infrastructure.
De ce fait, le déploiement des systèmes publier/souscrire sur des réseaux ad-hoc pose divers problèmes tels que la panne d’un noeud ou d’un lien et la dégradation de la qualité de service. Dans ce cadre, se situe ce sujet qui vise à évaluer les performances du système publier/souscrire déployé sur MANET. Pour ce faire, on propose d’élaborer une simulation du système décrit à fin de suivre son état au cours du temps et mesurer certains critères de qualité de service (avant et après l’occurrence de défaillance). Les résultats de simulation nous mènera à avoir une vue globale du réseau et à analyser l’état du système au cours du temps.

Proposition3

Il s’agit de concevoir et de développer un plugin pour l’environnement de développement Eclipse permettant de représenter graphiquement les différentes entités du langage d’aspect AO4AADL. AO4AADL est un langage d’aspect abstrait. Il s’intègre sous la forme d’une annexe à des modèles d’architecture écrits dans le langage AADL.
La programmation orientée aspect (en anglais Aspect-Oriented Programming, AOP) est un paradigme de programmation qui permet de séparer les considérations techniques des descriptions métier dans une application. Ce type de programmation permet d’améliorer la modularité et d’assurer une meilleure réutilisation. Comme exemple de langage : AspectJ/Eclipse est une extension orienté aspect pour le langage de programmation Java.
AADL (Architecture Analysis & Design Language) est un langage de description d'architecture. Il permet de décrire les systèmes TR2E (Temps Réel Répartis Embarqués) en assemblant des blocs développés séparément. Il repose principalement sur la notion de « composant ». Tout système décrit est un assemblage de composants connectés. AADL permet de décrire à la fois la partie matérielle et la partie logicielle d'un système. Il est axé autour de la définition d'interfaces précises pour les blocs construits. Il sépare l'implantation interne de la description des interfaces. AADL peut être exprimé en utilisant une syntaxe textuelle aussi bien qu'une représentation graphique. Un modèle AADL contient (en plus de la description de l'architecture du système) des éléments non architecturaux : caractéristiques temps-réel ou embarqués des composants (temps d'exécution, empreinte mémoire), descriptions comportementales…Ainsi, il est possible d'utiliser AADL comme l'épine dorsale pour décrire la majorité d’n système. Par ailleurs, grâce aux deux mécanismes de propriété et d’annexes, AADL propose un processus de production assez ouvert et pouvant être facilement enrichi.
Objectifs :
1. Prise en main de l’outil ADELE (permettant de représenter graphiquement des modèles AADL)
2. Prise en main du langage AO4AADL
3. Utilisation des Frameworks EMF/GMF pour concevoir le plugin Eclipse

Proposition4

La mobilité forte des composants logicielle consiste à interrompre l'exécution d'une application, de la migrer vers un nouvel hôte et de continuer son exécution à partir du point du dernier état capturé appelé encore checkpoint.

Cette technique peut être appliquée pour les processus d'orchestration BPEL grâce à une transformation de code. Le code généré est capable de capturer son état d'exécution au moment du déploiement de  l'Aspect de checkpoint. Cet Aspect stocke le checkpoint chez un service distant appelé WSCM. Apres interruption et migration du BPEL, la continuation de son exécution se fait grâce au WSIM qui invoque le BPEL déployé sur le nouvel hôte. Sur ce dernier, un Aspect de rétablissement est déployé afin de récupérer le checkpoint du WSCM et l'intégrer dans le BPEL pour continuer son exécution.

L'objectif de ce PFE est l'automatisation de la génération d'un code BPEL supportant la mobilité forte. Le point d'entré est un code BPEL quelconque et le WSDL correspondant. Ainsi, le travail demandé consiste à parser ces deux fichiers, appliquer les règles de transformation de code et générer le code mobile correspondant, générer le code des différent Aspect permettant le checkpoint, la mobilité et le rétablissement de l'exécution et enfin générer le code des deux services de gestion de mobilité (WSIM et WSCM).

Proposition5

Le projet consiste à implémenter un Plug-in Eclipse permettant de modéliser un profil UML pour la conception de la dynamique des architectures logicielles. Le plug-in est développé en utilisant les plug-ins EMF, GEF et GMF de Eclipse. Le projet est composé par trois parties :
Partie conception
Cette partie consiste à implémenter, en utilisant les plug-ins EMF, GEF et GMF de Eclipse, deux interfaces graphiques :
- Une première pour la modélisation UML du style architectural
- Une deuxième pour la modélisation UML des opérations de reconfigurations
Partie mapping
Une fois les deux interfaces graphiques sont implémentées, il faut implémenter le mapping : passage des modèles UML générés vers le langage formel Z.
Partie Aspect
La troisième partie consiste à implémenter le mapping entre les spécifications Z générées, des opérations de reconfiguration, et les aspects selon le langage AspectJ.

Proposition6

L'auto adaptabilité d'un service Web correspond à sa capacité de se reconfigurer lors d'un changement du contexte d'exécution afin de corriger une panne ou d'améliorer ses performances. Ce processus se compose généralement de 4 phases: la supervision, l'analyse, la planification et l'exécution.

La supervision consiste à collecter les informations sur l'environnement et l'exécution du service (solution implémentée dans le cadre de la thèse de M. Riadh ben Halima)

L'analyse correspond à analyser ces informations afin de déduire l'état actuel du service. En cas de nécessiter cette phase déclenche la planification afin de corriger le problème (solution implémentée dans le cadre du Master de Mlle Afef Mdhafer)

La planification se base sur un ensemble de règles permettant d'identifier les actions nécessaires pour adapter le service (ces règles sont identifiées dans le cadre du Master de Afef Jmal)

Et enfin l'exécution qui correspond à exécuter les actions planifiées. Les actions utilisées dans ce projet sont les actions de checkpoint et de mobilité (ces actions sont implémentées dans le cadre de la thèse de Mme Soumaya Marzouk)

Ce sujet de PFE a comme objectif de relier les différentes solutions afin de créer un framework d'auto-adaptabilité des services Web. Pour ce faire, le travail consiste à développer un moteur de règles (en utilisant par exemple l'outil Jess) qui jouera le rôle du planificateur. Ce moteur prendra comme entrée le résultat de l'étape d'analyse, évaluera les règles de planification et exécutera les actions résultantes.

Proposition7

Contexte (Pour les propositions 7 et 8)
L’un des avantages importants des services web est la possibilité de leur composition afin de construire des services plus complexes. Dans le processus de composition, l’étape de sélection des services permet de choisir les services web concrets qui seront, avec le client, les entités participantes à la composition de services. En fait, chacune de ces entités reçoit et fournit des données afin d’accomplir le service requis. De point de vue sécurité des messages, chaque entité possède sa propre politique concernant la protection de ses données entrantes et sortantes. Ainsi, outre les contraintes fonctionnelles, l’étape de sélection de services doit tenir compte des contraintes sécuritaires de chaque entité participante. Dans ce travail, nous nous sommes intéressés aux contraintes liées à la confidentialité des messages. Nous avons proposé une approche de sélection de services qui se base sur les modèles flux de données et  flux de contrôle de la composition et qui permet d’avoir une politique de confidentialité satisfaisant les exigences sécuritaires de toutes les entités participantes à ce flux de données. Dans notre approche, nous avons proposé une architecture d’un sélectionneur de services. Cette architecture contient plusieurs modules tels que :
- Un module nommé 'security policy intersection';
- Un module nommé 'security mapping'
Description
Il s’agit d’implémenter le module de 'security policy intersection' en se basant sur une ontologie de sécurité de messages SOAP déjà existante (proposée par Garcia et al [1]). En fait le module de 'security policy intersection' réalise l’intersection entre deux politiques de sécurité : une politique sécuritaire requise par le client et une politique sécuritaire disponible chez le service web. Si l’intersection des politiques n’est pas vide, on dit que le service est convenable et peut être choisis.
Le candidat doit donc :
1. Implémenter l’ontologie de sécurité de messages SOAP proposée par Garcia et al [1].
2.  Construire et implémenter un algorithme qui fait l’intersection entre deux politiques sécuritaires et retourne l’ensemble d’alternatives communes
Connaissances acquises
Après la réalisation de ce PFE, le candidat acquiert des compétences en :
- Architecture orientée services
- Services Web
- Web sémantique
- Sécurité informatique
Références
[1] D. Garcia, M. B. Felgar de Toledo, Web service security management using semantic web techniques, in proceedings of the 2008 ACM Symposium on Applied Computing (SAC 2008), Fortaleza, Ceara, Brazil, March 16-20, 2008.

Proposition8

Description
Il s’agit d’implémenter le module de 'security mapping' en se basant sur un module de XML schema mapping. En fait je me suis basée sur l'approche de XML schema mapping de Boukottaya et al. Donc le candidat peut chercher le code source d'un outil de XML schema mapping qui rassemble à celui de Boukottaya et al ou commencer au début par des expressions de XML schema mapping statiques/prédéfinies (et non pas calculées automatiquement).
Le 'security mapping' consiste à construire une politique sécuritaire PS2 à partir d’une autre politique sécuritaire PS1. PS1 concerne un ensemble de données D1 et PS2 concerne un ensemble de données D2. En fait D1 et D2 décrivent les même données XML mais de deux façons différentes. C’est pourquoi le 'security mapping' se base sur le ‘XML schema mapping’.
Le candidat doit donc :
1.      Trouver et choisir un module de ‘XML schema mapping’ qui existe déjà
2.      L’adapter pour réaliser le 'security mapping' décrit par les algorithmes que j’ai proposés
3.      L’intégrer dans un Framework d’utilisation de services web
Connaissances acquises
Après la réalisation de ce PFE, le candidat acquiert des compétences en :
- XML Schéma
- Architecture orientée services
- Services Web
- Sécurité informatique

Proposition9

Description
ZigBee [1] is a network and application layer specification based on the IEEE 802.15.4 standard [2] for Low-Rate Wireless Personal Area Networks (LR-WPANs). ZigBee is developed by a multi-vendor consortium called the ZigBee Alliance. Backed by more than 150 member companies, the ZigBee standard was ratified in late 2004, and released for public non-commercial use in June 2005. Eventhought this standard was not specifically developed for Wireless Sensor Networks [3] (WSNs), it is intended to be suitable for them since WSNs can be built up from LR-WPANs [4].
Routing strategy in ZigBee uses a combination of two kinds of routing protocols as default. The first is a reactive routing protocol that discovers the best route by broadcasting a route request and waiting for replies from the destination or intermediate nodes, similar to the AODV protocol.  It has the drawback of being greedy with respect to bandwidth and energy consumption. The second is a Tree Routing protocol, which is an extremely simple routing algorithm where a node only forwards packets to its parent or child nodes along the logical tree. This tree is established and maintained based on link quality estimation. Typically, a node performs a channel scan to identify the potential parents and chooses the one that provides the best child-parent link quality. Link quality estimation is performed using LQI (Link Quality Indicator), a hardware-based metric that is directly read from the radio transceiver.
Zigbee Tree Routing is a low-overhead protocol. It avoids flooding the network with route request/update messages, which conserves bandwidth and energy. It avoids also storing routing tables, whose update would be a costly operation. Hence, Zigbee Tree Routing is most suitable for energy-constrained WSNs.  However, some recent studies, such as [5-8] argued that Zigbee Tree Routing has the main drawback of resulting in increased hop-counts leading to inefficient routing. This is totally reasonable since the logical tree forming and maintenance do not take into account the hop-count information.  Another weakness of Zigbee Tree Routing would be the use of LQI metric for establishing and maintaining the tree. Indeed, the child node selects or updates its current parent based on the measure of the LQI that estimates the quality of the parent-child link. Previous empirical studies have shown that such metric does not provide accurate link quality estimation [10,11]. Furthermore, in [12], MultihopLQI- a tree routing protocol based on LQI - has been shown as inefficient mainly due to inaccuracy of LQI in estimating link quality.
In this project, we aim to improve Zigbee Tree Routing performance by integrating a new metric for parent selection that we call F-PQI: Fuzzy Parent Quality Indicator [13].  This metric is inspired from [14] and consists in combining five different properties using Fuzzy Logic to select the most convenient parent. These properties include Energy indicator (Ei), Depth (Dp) (i.e. hop-count), Children Number (CN), four-bit [18] link quality estimator, and LQI.

References 

[1] ZigBee Alliance, “ZigBee Specification “, ZigBee Document 053474r05, Version 1.0 , December 14th, 2004 

[2] IEEE 802.15.4 Standard,” Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Low-Rate Wireless Personal Area Networks (LR-PANs)”, IEEE Standard for Information Technology, IEEE-SA Standards Board, 2003.

[3] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam and E. Cayirci, “Wireless sensor networks, a survey”, Computer networks, Volume 38, Issue 4 , 15 March 2002, Pages 393-422

[4] A. V. Nieuwenhuyse, A. Koubaa, M. Alves, “On the use of the ZigBee protocol for Wireless Sensor Networks”, IPP-HURRAY Technical Report, HURRAY-TR-060603, Jun 2006

[5] Kim, T., Kim, D., Park, N., Yoo, S., Lopez, T.S.: Shortcut Tree Routing in ZigBee Networks, In: 2^nd International Symposium Wireless Pervasive Computing, 2007.

[6] Qiu,W., Cheng,Q., Skafidas, E,.: A Hybrid Routing Protocol for Wireless Sensor Network, International Symposium on Communications and Information Technologies, pp. 1383-1388, 2007.

[7] M. Al-Harbawi, M. F. A. Rasid, N. K. Noordin, Improved Tree Routing (ImpTR) Protocol for ZigBee Network, International Journal of Computer Science and Network Security, VOL.9 No.10, October 2009

[8] Qiu, W., Skafidas, E., and Hao, P. 2009. Enhanced tree routing for wireless sensor networks. Ad Hoc Netw. 7, 3 (May. 2009), 638-650.

[9] Nefzi, B., Song, Y.: Performance Analysis and Improvement of ZigBee Routing Protocol, 7th IFAC International Conference on Fieldbuses & Networks in Industrial & Embedded Systems, Toulouse, 2007.

[10] K. Srinivasan and P. Levis, “Rssi is under appreciated,” in In Proceedings of the Third Workshop on Embedded Networked Sensors, 2006.

[11] J. Polastre, R. Szewczyk, and D. Culler, “Telos: enabling ultra-low power wireless research,” in IPSN ’05: Proceedings of the 4th international symposium on Information processing in sensor networks. Piscataway, NJ, USA: IEEE Press, 2005.

[12] Gnawali, O., Fonseca, R., Jamieson, K., Moss, D., and Levis. Collection tree protocol. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems (SenSys '09). ACM, New York, NY, 1-14. 2009

[13] Nouha Baccour, Anis Koubaa, and Habib Youssef:  Fuzzy Parent Quality Indicator (PQI): a new metric for potential parents evaluation using Fuzzy logic, Work in progress.

[14] Nouha Baccour, Anis Koubâa, Habib Youssef, Maissa Ben Jamâa, Denis do Rosario, Mario Alves and Leandro Becker. F-LQE: A Fuzzy Link Quality Estimator for Wireless Sensor Networks, The 7th European Conference on Wireless Sensor Networks (EWSN 2010), Coimbra, Portugal, September 17-19, 2010.