Sujet 17 : Virtualisation d'orchestration de services
SUIVI DE CHAQUE MEMBRE DU GROUPE
ENCADRANT
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 :
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 :
07/04/08 :
- Planning :
08/04/08
- Division en deux groupes :
-
Rami et Nicolas
: analyse et déploiment du code expérimental
-
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.
to top