TER 2008

Sujet 17 : Virtualisation d'orchestration de services

SUIVI DE CHAQUE MEMBRE DU GROUPE

• FayolleSamuel
• BaliRami
• AmselemJonathan
• GaleaNicolas

ENCADRANT

• Philippe COLLET

Sommaire

SUIVI DU GROUPE

4/02/08 :

• Rencontre avec mahiou Mehdi(étudiant ayant travaillé avec la même équipe l'année précédente) pour avoir une vue globale du projet TER.
• présentation rapide de l'architecture de ce qui a été fait lors des précédents TER
• présentation rapide de BPEL, WISDL, AMUI, et composants fractal

15/02/08 :

• premiere prise de contact avec notre encadrant

16/02/08 :

• Début de la phase d'apprentissage des technos(Fractal, BPEL, SCA)

28/02/08 :

• Réunion de groupe lors d'un TD pour commencer le Cahier des Charges

09/03/08 :

• premiere version chantier du cahier des charges avant premieres annotations cachier des charges
• ter.odt: TER 0.2eme verison
• ter1.odt: 0.3eme version
• ter3.odt: version 0.3.2

du 15 au 27 03/08 :

• Periode de projets et d'examens

27/03/08 :

• Reception du code experimental fournis par Mr Philippe Collet.

30/03/08 :

• Analyse preliminaire du code experimental

31/03/08 :

• Mises au point avec notre enseignant lors du Deuxième TD de Suivi du TER 2007-2008. Nouvelle version du cahier des charges :
• ter3.doc: version 0.4

02/04/08 :

• finalisation du cahier des charges et ajout de shemas.

03/04/08 :

• Reunion avec notre encadrant pour discuter des modifications à faire sur le cahier des charges.
• Correction du cahier des charges.
• Début de création des transparents pour la présentation.

04/04/08 :

• Virtualisationdorchestrationdeservices.pdf: Présentaion intermédiaire
• RapportVirtualisationFINAL.pdf: Cahier des charges

07/04/08 :

• Planning :

08/04/08

• Division en deux groupes :
  1. Rami et Nicolas: analyse et déploiment du code expérimental
  2. Samuel et Jonathan: recherche de pistes pour le développement futur (activeBPEL et 1-N)
• Réunion avec notre encadrant pour mettre au point l'avancement du projet.

Bilan

Nous avons analysé le code expérimental, effectué des tests de déploiement et recherché les classes permettant de récupérer l'état de l'orchestration.

Problèmes

Nous n'arrivons qu'à produire les proxys clients pour des WS mais pas comme serveur. Nous avons trouver une classe AeProcessViewBean^?? qui permet de récupérer un max de données mais la factory (AeEngineFactory^??) ne nous permet d'avoir que des données partielles.

Travail pour la semaine

• Créer et déployer une orchestration des test que nous créerons nous même car celles disponibles ne nous conviennent pas
• Lui ajouter un composant ou un controlleur pour récupérer l'état de l'orchestration.

14/05/08 au 18/04/08

• Recontres avec Annabelle Mercier (qui à participé à la création du code) pour mettre au point notre avancement et tenter de stabiliser le code.
• Recherche et mise en place d'une nouvelle stratégie pour surveiller l'orchestration : à partir du Web Service "BpelEngineAdmin". Détails des choix et explications de cette stratégie : compte-rendu_WSDL.pdf

21/04/08 au 25/04/08

• Une premiere idée était de concerver l'architecture un composant par orchestration. Pour différencier chaque instance nous voulions utiliser les

identifiants de corrélation du fichier BPEL. Nous pouvons peut être recupérer le Pid d'un processus à l'aide d'une extention d'ActiveBPEL,(ce qui rend l'idée non portable) , et ainsi suivre le flux d'execution (abx:getProcessusId avec le namespace http://www.activebpel.org/bpel/extension). Nous avons modifié notre fichier BPEL en conséquence, mais cela ne fonctionne pas et nous n'arrivons vraiment pas à résoudre l'erreur. Cependant la couche AXIS au dessus du proxy s'occupe de la récéption et fait un premier traitement sur le fichier SOAP(Celui ci contient justement dans son Header l'identifiant de corrélation). On ne voit donc qu'un appel java et pas le message xml(pour l'instant). Nous sommes ensuite incapable d'y acceder depuis les composants du proxy.

Nous avons pensé alors à une architecture 1-N un composant par instance d'orchestration. Pour cela nous sommes obligés de regénérer une nouvelle orchestration BPEL, car il faut spécifier les nouvelles redirections sur les nouveaux proxy à génerer. Le tout est trés côuteux et le travail ne sera surement pas terminé dans le temps qui nous est imparti.

• Nous avons travaillé sur l'aspect Contrôlleur/Intercepteur et nous avons trouvé qu'il existe bien un moyen de faire un contrôlleur qui se

déclenche avant ou après la méthode "ciblée". Nous avons trouvé comment l'implémenter en Java (un contrôlleur, un intercepteur) mais nous n'arrivons pas à le faire en Fractal. Nous avons une erreur, il n'accepte pas que l'on définisse des intefaces qui ont un nom terminant par "-controller" ! Or c'est le cas pour l'interceptor-controller. Il y a très peu de doc sur ce point, (http://fractal.objectweb.org/current/doc/javadoc/julia/overview-summary.html et un exemple ici : http://www.koders.com/noncode/fid4B8B962CEBF7DE49B22E6FE3AF9CB3F83ACB26F7.aspx?s=SimpleCodeGenerator )

Autre chose : On a mal compris le fonctionnement du moteur. Nous avions fait des prints pour etre sur que les proxies etaient appeles mais ces tests nous ont trompes. Nous nous sommes rendus compte que le code fourni ne modifiait pas le bpel déployé et donc c'est pour ca que l'orchestration marchait sans problèmes en parlant directement avec les WS. On a juste eu à modifier le bpel, deployer les classes services crées pour chaque proxies et donc maintenant activebpel parle bien avec les proxies.

Cela est fait automatiquement pendant la creation des proxies. Le code à Annabelle crée des proxies clients qui sont des composants avec une classe d'implémentation qui ne sert que de relai. En effet ce composant n'a pas d'interface serveur mais juste une interface cliente. Cette classe s'enregistre dans une hashmap a sa creation. Une autre classe appelee "nomInterfaceServiceImpl" doit etre deployee comme WS et va chercher l'impl du composant dans la hashmap et en tire son interface cliente pour faire les appels. Mais il y a un nouveau problème, comme activebpel parle avec nos proxies client comme des web services, leur classe est instantiee dans la JVM de tomcat alors que le composant s'est enregistre dans la JVM qui lance nos composants.

Nous pensons peut etre utiliser un rmiregistry a la place de la hashmap.

26/04/08 au 02/05/08

Mise en place des Controlleurs et Intercepteurs dans le but de surveiller l'état du système. Aucune documentation complète disponible, nous avons dû tester à partir d'exemples et beaucoup débeugguer... Finalement nous avons dû faire une nouvelle membrane puisque les controlleurs et intercepteur ne sont pas de nouveaux composants Fractal mais bien définis dans la membrane du composant à surveiller. Ce système que nous avons mis en place fonctionne, dès qu'une méthode est appellée (dans l'interface ciblée) l'intercepteur déclenche le controlleur correspondant. Cependant il est possible de lancer le controlleur avant ou après l'interception du message, et le "post" ne se lance pas pour l'instant.

Autre problème, il y avait un conflit entre les librairies d'ActiveBPEL et celles d'Axis. Des JARs de même nom (mais probablement quelque peu différents) devaient appartenir l'un à activeBEPL l'autre à Axis qui sont tous les deux dans Tomcat. Nous avons opté pour la solution suivante : faire tourner ActiveBPEL^? dans un Tomcat et nos proxy dans un autre Tomcat sur un autre port. Ainsi plus de conflit et ce modèle correspond mieux à l'architecture utilisée dans AMUI qui est le serveur de chat dans lequel nous testerons plus tard notre code.

Nous avons également fait un composant intermédiaire qui permet d'intéroger le serveur ActiveBPEL^? afin d'obtenir le maximum d'information sur l'état du système.

• rapport_17.pdf: Rapport final

• presentation_finale.pdf: Présentation

to top