SOA & BPM. Urbanisation d un Système d information universitaire RAPPORT DE PROJET DE FIN D ETUDES

République Tunisienne Ministère de l Enseignement Supérieur, de la Recherche Scientifique et Technologie Direction Générale des Études Technologiques Institut Supérieur des Études Technologiques de Djerba Département Technologie de l Informatique RAPPORT DE PROJET DE FIN D ETUDES Urbanisation d un Système d information universitaire SOA & BPM Elaboré par : KARRAY WALID Encadré par : NAFAA FREAA Effectué à : Encadré par : FOURAT ZOUARI AHMED MASMOUDI Année Universitaire 2009/2010 - Semestre 1 Référence Dép. TI AN/SE 2010/S01 CODE IRP05

ISET Djerba TriTux PAGE 1

Dédicaces A toute ma famille, à mes enseignants, à mes amis, et à mes camarades je dédie ce travail. ISET Djerba TriTux PAGE 2

Remerciement Je tiens à remercier chaleureusement Mr. Mounir Khalifa CEO de Tritux, Mr. Fourat Zouari et Mr. Ahmed Masmoudi, chefs de projets ainsi que toute l équipe de développement à Tritux. Mes forts remerciements à mon encadreur Mr. Nafaa Freaa ainsi que mes enseignants. Je remercie encore la communauté Ubuntu GNU/Linux, Canonical Ltd., la communauté PHP et Open ESB. et un aussi grand MERCI à la communauté Open Source! Walid Karray ISET Djerba TriTux PAGE 3

Table des matières Dédicaces... 2 Remerciement... 3 Table des matières... 4 Liste des illustrations... 6 1. Chapitre 1 : Introduction... 8 1.1. Introduction générale... 8 1.2. Entreprise d accueil... 8 1.3. Contexte et objectif du projet... 11 2. Chapitre 2 : Etat de l art... 14 2.1. Introduction au concept SOA... 14 2.2. Les services web... 17 2.2.1. Introduction... 17 2.2.2. Les différents types de services web... 17 2.2.3. Résumé... 24 2.3. Orchestration de Services web... 25 2.3.1. Introduction... 25 2.3.2. Exemple... 25 2.3.3. Le langage BPEL... 28 2.3.4. Résumé... 32 2.4. Résumé sur le concept SOA... 33 3.... 34 3.1. Introduction... 34 3.2. Phase 1 : Conception des Services Web... 35 3.2.1. Introduction... 35 3.2.2. Urbanisation du SI de l établissement... 37 3.2.3. Urbanisation du SI du RNU... 64 3.2.4. Conclusion... 71 3.3. Phase 2 : Processus métier et orchestration de services... 74 3.3.1. Introduction... 74 3.3.2. Conception du 1 er processus métier : ProcessRUById... 74 3.3.3. Conception du processus : BatchProcessRU... 77 3.3.4. Conclusion... 78 Chapitre 4 : Réalisation... 79 3.4. Installation & Configuration... 79 3.4.1. Serveur FTP : ftp-etu.intranet.demo... 79 ISET Djerba TriTux PAGE 4

3.4.2. Serveur CUPS : cups.intranet.demo... 79 3.4.3. Serveur de BD PostgreSQL : postgres-83.intranet.demo... 79 3.4.4. Serveur web d inscription en ligne : inscription.edu.demo... 80 3.4.5. Point d accès sans fil : ap-21. intranet.demo... 81 3.4.6. Serveur mail : (ws.rnu.edu.demo)... 81 3.4.7. Modem GSM connecté au serveur Lenny : debian5-02.intranet.demo... 82 3.4.8. PodBridge 1.2... 82 3.4.9. Installation de GlassFish ESB 2.1... 83 3.4.10. Installation des plugins SOA & BPEL pour NetBeans... 83 3.5. Réalisation des connecteurs... 83 3.5.1. Exemple de réalisation d un connecteur : pbftpaccountconnector... 83 3.5.2. Test du service web docreateftpuseraccount par l utilitaire SoapUI 3.0.1... 85 3.6. Réalisation des processus métiers - phase 2... 89 3.6.1. Test de ProcessRUById (Invocation du service composite)... 91 3.6.2. Test de BatchProcessRU (Invocation du service composite)... 94 3.7. Développement des applications... 96 3.7.1. Appel web-service SOAP en PHP5... 97 3.7.2. Exemple d appel web-service SOAP en Perl (Suppression d un compte FTP)... 98 3.7.3. Appel web-service SOAP en JAVA SE Swing (Invocation du service Ping (test PodBridge))... 98 3.7.4. Appel web-service SOAP en Shell (Invocation du service composite BatchProcessRU)... 99 3.8. Environnement de travail... 99 3.8.1. Matériel utilisé... 99 3.8.2. Logiciels utilisés :... 100 4. Perspective... 105 5. Liste des abréviations... 106 6. Bibliographie... 108 ISET Djerba TriTux PAGE 5

Liste des illustrations Figure 1 - Diagramme hiérarchique de l entreprise... 10 Figure 2 Requête / Réponse (SOA)... 14 Figure 3 L architecture SOA... 15 Figure 4 - Le modèle en couches de l architecture SOA... 16 Figure 5 Connexion à PostgreSQL en ligne de commande... 20 Figure 6 Premier extrait du document WSDL... 22 Figure 7 Deuxième extrait du document WSDL... 22 Figure 8 Message XML SOAP Requête... 23 Figure 9 Message XML SOAP - Réponse... 23 Figure 10 Exemple d un processus faisant appel à 4 services... 27 Figure 11 Eléments de BPEL (Architecture)... 29 Figure 12 Modélisation d un connecteur PodBridge1.2 (Cas général)... 36 Figure 13 - Table «etudiant»... 37 Figure 14 - Classe BDetu (Connecteur PodBridge de l établissement)... 39 Figure 15 Modélisation de la logique métier (Connecteur BDetu)... 42 Figure 16 - Classe FTPAccount (Connecteur PodBridge de l établissement)... 44 Figure 17 - Modélisation de la logique métier (Connecteur FTPAccount)... 49 Figure 18 Classe APACLManager (Connecteur PodBridge de l établissement)... 50 Figure 19 - Modélisation de la logique métier (Connecteur APACLManager)... 53 Figure 20 Classe IPPService (Connecteur PodBridge de l établissement)... 54 Figure 21 - Modélisation de la logique métier (Connecteur IPPService)... 56 Figure 22 Classe wwwsubscr (Connecteur PodBridge de l établissement)... 57 Figure 23 - Modélisation de la logique métier (Connecteur wwwsubscr)... 59 Figure 24 Classe SMSService (Connecteur PodBridge de l établissement)... 60 Figure 25 - Modélisation de la logique métier (Connecteur SMSService)... 63 Figure 26 Classe MailAccount (Connecteur PodBridge 1.2)... 65 Figure 27 - Modélisation de la logique métier (Connecteur MailAccount)... 70 Figure 28 Connecteurs PodBridge (de l établissement)... 72 Figure 29 - Connecteur PodBridge (du RNU)... 73 Figure 30 - diagramme d'activité «ProcessRUById»... 76 Figure 31 - diagramme d'activité «BatchProcessRU»... 78 Figure 32 - Arborescence du projet PodBridge - Netbeans IDE... 84 Figure 33 1 ère phase de l urbanisation des deux réseaux (Services Web)... 88 Figure 34 Déploiement de ProcessRUById et BatchProcessRU... 90 Figure 35 - SI après urbanisation... 96 Figure 36 - Architecture de PodBridge 1.2... 104 ISET Djerba TriTux PAGE 6

Ce document représente le rapport de projet de fin d étude effectué par l étudiant au 5ème niveau informatique réseaux Walid Karray, de l Institut Supérieur des Etudes Technologiques de Djerba, au sein de l entreprise Tritux, pendant la période Septembre 2009 - Janvier 2010. Adresse électronique: walid.karray@gmail.com ISET Djerba TriTux PAGE 7

Chapitre 1 : Introduction 1. Chapitre 1 : Introduction 1.1. Introduction générale Des systèmes informatiques qui sont réunis pour exécuter une tâche, peuvent tous êtres considérés comme étant un seul système, toute cette force peut être due à un échange d une faible quantité d informations entre les différents systèmes. On peut déduire ainsi que ces systèmes sont dépendantes les unes des autres, et si à un moment donné deux systèmes parmi l ensemble n arrivent pas à s échanger d informations, ça engendrera alors le dysfonctionnement de la totalité du système. Malheureusement, à chaque fois qu on se lance à la conception d une application composite on découvre toujours des problèmes d intégration avec des systèmes qui à la base ne sont pas pensées pour fonctionner ensemble utilisant des technologies différentes et des protocoles propriétaires. Pour remédier à ce genre de problèmes on utilise souvent des logiciels intermédiaires appelées (intergiciels), le plus souvent appelé middlewares (en anglais) qui servent d intermédiaire de communication entre plusieurs applications, généralement complexes ou distribuées sur un réseau informatique. 1.2. Entreprise d accueil Tritux, SARL 1 est une SSII 2 Tunisienne née par le regroupement, au sein d'un réseau professionnel, des compétences provenant de divers horizons et partageant la même conviction : que les nouvelles technologies de l'information et de la communication (NTIC) basées sur les logiciels libres, constitueront le choix fondamental face aux exigences de la société future, société de l'information. Dynamique, rapide et accompagnant les changements et bouleversements induits par l'émergence de nouvelles techniques et des nouveaux besoins des usagers, Tritux a repensé 1 Société Anonyme à Responsabilité Limitée 2 Société de service et d ingénierie de l informatique ISET Djerba TriTux PAGE 8

Chapitre 1 : Introduction l'approche des activités liées aux NTIC par l'adaptation du choix "Open Source " garantissant la sécurité, fiabilité, flexibilité, et surtout, une évolution quotidienne vers le top de la technologie. Les domaines d activités de Tritux s étendent sur plusieurs disciplines à savoir : - Bases de données libres, - Logiciels libres, - Développement de solutions avec des outils/ressources libres, - Annuaires LDAP 3, - Messageries mail, - Messageries courtes (SMS 4 ) et Multimédia (MMS 5 ), - Systèmes GNU 6 Linux, - Supervision et monitoring, - Réseaux complexes, - Sécurité et optimisation, - Références de Tritux: - Tunisie Telecom, - Assurances BIAT, - Mobile Services, - Nouvelair, - Alva, 3 Lightweight Directory Access Protocol 4 Short Message Service 5 Multimedia Messaging Service 6 Gnu s Not Unix ISET Djerba TriTux PAGE 9

Chapitre 1 : Introduction - Sameteam, - PixelJ, - Attijari Bank, - Groupe Délice Tunisie, - Diagramme hiérarchique de l entreprise: Figure 1 - Diagramme hiérarchique de l entreprise CEO : Acronyme anglais pour «Chief Executive Officer», en français le chef de direction et tient le rang le plus élevé dans la hiérarchie de l entreprise son rôle est de superviser tout les projets en cours de développement et leurs état d avancement, maintenir le contact avec les clients, en contact avec les chefs de projet, le recrutement etc.. Les chefs de projets : Les chefs de projets sont chargées de guider les équipes de développements et de mener les projets et de contrôler leur bon déroulement. Secrétaire : Elle s'occupe pour les comptes, des communications téléphoniques, de la rédaction des comptes rendus de réunions, etc.. ISET Djerba TriTux PAGE 10

Chapitre 1 : Introduction Service Technique : Sa fonction et de bien veiller sur le bon fonctionnement du réseau local de l entreprise ainsi ses différents équipements, installer et mettre à jour les logiciels, achat de nouveau matériel et la réparation des équipements informatiques en cas de panne. Equipe de développement : Représente la force motrice de l entreprise, l équipe est constituée d une dizaine de développeurs et d ingénieurs qualifiés pour exécuter des tâches sous la responsabilité des chefs de projets. Chargé de la documentation : C est une personne chargé de la rédaction et la mise à jour des documents techniques et des manuels d utilisation pour les produits réalisés. 1.3. Contexte et objectif du projet Notre projet de fin d étude consiste à urbaniser un SI (Système d Information) universitaire. Il est noté que les différents systèmes informatiques visés du SI universitaire, les différentes procédures d urbanisation ainsi que les applications réalisées dans ce projet ont été virtualisés dans un environnement local. La quasi-totalité des établissements d enseignement supérieurs en Tunisie disposent de systèmes informatiques hétérogènes (matériel et applicatif) déjà performants pour répondre à des besoins très élémentaires, tel que: - L SGBD permet la gestion des informations sur chaque étudiant, - le point d accès sans fil permet l accès au réseau, - le serveur FTP 7 permet l hébergement de comptes pour les étudiants, - le serveur d impression permet d envoyer un ordre d impression à une imprimante distante partagée, - le site web d inscription en ligne permet de consulter les reçus de payements de chaque étudiant, - le serveur Mail permet d envoyer un message à un groupe d étudiants, 7 File Transfer Protocol ISET Djerba TriTux PAGE 11

Chapitre 1 : Introduction - et encore plus Existe-il un système informatique aussi performent qui peut répondre à plusieurs besoins à la foi? Comme par exemple, un système pouvant à partir des informations stockés sur chaque étudiant de gérer automatiquement leurs comptes FTP, leurs comptes Mail, leurs accès au réseau sans fil, les notifiés par SMS, leurs envoyer les calendriers et des documents numériques, etc... Par les moyens présents, si un établissement pense à offrir ces différents services à ses quelques milliers d étudiant, il faudra compter des semaines de travails pour arriver à un résultat presque satisfaisant! Certainement que l informatisation (automatisation) des différentes procédures cités précédemment est sans aucun doute quelque chose d indispensable ; il faudra donc un système qui à la foi capable de gérer les différentes ressources et de coordonner l échange d informations d une façon autonome entre les différents systèmes informatiques qu on dispose. Mais avant de penser à une solution on se pose ces deux questions : - Comment des systèmes de technologies et de protocoles de communications différents puissent s interagir? - Par quel moyen sera assuré l échange de flux d information entre les différents systèmes? C est pour cette raison que le concept SOA 8 et le BPM 9 sont les choix les plus appropriés pour résoudre notre problématique. Pour pouvoir répondre à cette problématique l étude conceptuelle de ce projet va être divisé sur deux phases : 1) La première phase consiste à l exposition d un protocole de communication ouvert (unifié) pour chacun des systèmes à travers un middleware. (migration aux services web) 8 Service Oriented Architecure 9 Business Process Management ISET Djerba TriTux PAGE 12

Chapitre 1 : Introduction 2) La deuxième phase consiste à la conception des processus métier à travers un workflow / orchestration 10 de services web 10 Processus de coordination d'un échange d'information à travers l'interaction de services web. «Source Wikipedia http://fr.wikipedia.org/wiki/orchestration_(informatique)» ISET Djerba TriTux PAGE 13

Chapitre 2 : Etat de l art 2. Chapitre 2 : Etat de l art 2.1. Introduction au concept SOA L architecture orientée services AOS, ou plus souvent appelé SOA acronyme anglais pour «Services Oriented Architecture» est un moyen d interaction applicatif qui met en œuvres une collection de services (des composant logiciels) qui peuvent être exécutés sur n importe quelle plateforme. Par définition un service est une tâche exécuté par un individu (un fournisseur) à l attention d un autre individu (un consommateur), le principe est le même dans le jargon informatique. Demandeur / Consommateur de service Message Demande Réponse Message Fournisseur / Prestataire de service Figure 2 Requête / Réponse (SOA) Par analogie avec le concept objet, un service ressemble beaucoup à une méthode d une classe, il permet de recevoir des données et de renvoyer le résultat. Disposant plus d avantages qu une méthode un service est distingué par le fait qu il peut être invoqué à distance et par n importe quelle plateforme. Au terme d interopérabilité, l architecture SOA repose sur des normes décrites à travers WS-I 11. Un service peut être une activité (suite d appels à d autres services), appelé autrement service de large granularité ou service composite. 11 Un consortium industriel initié pour la promotion de l interopérabilité entre plateformes par la rédaction des spécifications des Services Web WS-* ISET Djerba TriTux PAGE 14

Chapitre 2 : Etat de l art La figure de ci-dessous décrit l architecture SOA d une façon globale: Architecture SOA Service X Service W Demandeur 2 Service Y Demandeur 1 Service Z Service U Service composite Service V Orchestration Figure 3 L architecture SOA Un service est l unité atomique de l architecture SOA L architecture SOA est représentée par un modèle en couches, voir la figure de cidessous. ISET Djerba TriTux PAGE 15

Chapitre 2 : Etat de l art Présentation Consommateur Application Application Web Terminal Appareil Mobile 5 Orchestration WORKFLOW BPEL, BPM 4 Services Services Services web 3 Composants, Méthodes Méthodes de classes bibliothèques,drivers... Func () { ---- Func () { ------ } --- } Func () { ---- Func () { ------ } --- } 2 Systèmes & Ressources Serveurs, Bases de données.. DB DB I0II0I0I0I0 II0III00I0I I0II0I0I0I0 0I0III0I0I0 II0III00I0I I0I0I0 0I0III0I0I0 I0I0I0 1 Figure 4 - Le modèle en couches de l architecture SOA Couche 1 (Les systèmes et les ressources): Englobe des systèmes informatiques (logiciels et matériels) hétérogènes et différentes types de ressources telle que les bases de données et des fichiers. Couche 2 (Composants et méthodes) : Représente des méthodes (fonctions) qui tiennent la logique métier, ainsi que les composants d applications qui sont utilisés pour dialoguer avec différents systèmes et ressources. Couche 3 (Services) : C est à ce niveau que la logique métier est devenu caché à l utilisateur ainsi que le dialogue avec les différentes systèmes et ressources est devenu au moyen d un protocole ouvert (standard). Couche 4 (Orchestration): Vient juste au dessus de la couche services, l orchestration de services est définit par l interaction et l échange des flux d information métier entre plusieurs services d une façon autonome. Couche 5 (Présentation): Elle représente l interface par laquelle les utilisateurs finaux (consommateurs de services) peuvent consumer les différents services et interagir indirectement avec les différents systèmes existant. ISET Djerba TriTux PAGE 16

Chapitre 2 : Etat de l art 2.2. Les services web 2.2.1. Introduction Les services web représentent un ensemble de fonctionnalités distribués sur intranet ou internet qui peuvent être exécutés à distance à travers les protocoles d internet tel que HTTP 12 /HTTPS 13 et SMTP 14. 2.2.2. Les différents types de services web Il existe différents types de services web : 2.2.2.1. XML-RPC XML-RPC est un protocole RPC (Remote procedure call), une spécification simple et un ensemble de codes qui permettent à des processus s'exécutant dans des environnements différents de faire des appels de méthodes à travers un réseau. Les processus d'invocation à distance utilisent le protocole HTTP pour le transport des données et la norme XML 15 pour le codage des données. XML-RPC est conçu pour permettre à des structures de données complexes d'être transmises, exécutées et renvoyées très facilement. Voici un exemple d une requête/réponse XML-RPC : Requête XML-RPC : POST /xmlrpc HTTP 1.0 User-Agent: myxmlrpcclient/1.0 Host: 192.168.1.2 Content-Type: text/xml Content-Length: 169 <?xml version="1.0"?> <methodcall> 12 HyperText Transfer Protocol 13 HTTP Secure 14 Simple Mail Transfer Protocol 15 Extensible Markup Language ISET Djerba TriTux PAGE 17

Chapitre 2 : Etat de l art <methodname>calculesurfacecercle</methodname> <params> <param> <value><double>2.41</double></value> </param> </params> </methodcall> Réponse XML-RPC : HTTP/1.1 200 OK Date: Sat, 02 Jan 2010 23:20:04 GMT Server: Apache.1.3.12 (Unix) Connection: close Content-Type: text/xml Content-Length: 124 <?xml version="1.0"?> <methodresponse> <params> <param> <value><double>18.24668429131</double></value> </param> </params> </methodresponse> Réponse fault (Erreur) XML-RPC : <?xml version="1.0"?> <methodresponse> <fault> <value><string>no such method!</string></value> </fault> </methodresponse> 2.2.2.2. Les services web SOAP Les services web de type SOAP 16 se basent aussi sur l échange de messages XML et se reposent sur le standard SOAP pour l échange de message et WSDL 17 pour décrire les services web. Structure d un document WSDL : 16 Simple Object Access Protocol 17 Web Services Description Language ISET Djerba TriTux PAGE 18

Chapitre 2 : Etat de l art Un document WSDL (basé sur XML) permet la description d un service, il décrit les paramètres d entrés du service et le format et le type des données retournées. Voici quelques éléments d un document WSDL : - porttype : définissant le service web, en particulier les opérations qu il réalise et le type de messages échangés. - message : comprend une ou plusieurs parties représentant les paramètres d entrés. - types : définissant les types de données utilisés par le service web. - binding : précisant le protocole utilisé et le format de message. 2.2.2.3. Un exemple de service web (type SOAP) : L exemple qui suit démontre comment il est possible de récupérer des informations depuis une base de données PostgreSQL à travers un service web SOAP via le protocole HTTP. Avant de passer au service web, la figure de ci-dessous explique les différentes procédures à effectuer au moyen d un client PostgreSQL pour récupérer les informations sur un étudiant donné par son identifiant (id). ISET Djerba TriTux PAGE 19

Chapitre 2 : Etat de l art Figure 5 Connexion à PostgreSQL en ligne de commande Les inconvénients : - Il faut avoir une idée sur les structures des différentes tables pour pouvoir exécuter des requêtes, - Il faut savoir utiliser les différentes fonctionnalités fournis par le client de PostgreSQL, - Cette opération ne peut être exécutée que depuis le réseau de l établissement tant que le port 5432 n est pas autorisé depuis l extérieur, - Lors de développement d une application, le langage de programmation à utiliser doit supporter une extension qui lui permet de se connecter au serveur PostgreSQL. - Le développeur de l application doit obligatoirement maitriser le langage SQL ainsi les syntaxes spécifiques pour PostgreSQL. ISET Djerba TriTux PAGE 20

Chapitre 2 : Etat de l art - Communiquer des informations sur l SGBD tel que son adresse IP, le port qu il utilise, nom des tables peuvent aider les pirates pour accéder illégalement aux données confidentielles. Maintenant, si on reprend le même exemple, mais cette fois en se basant sur les services web SOAP. (Après une procédure d urbanisation) On suppose que les informations suivantes sont déjà communiquées : - La clé d authentification (Key): 691292877050480f54b5 (Doit être passé en paramètres à chaque invocation d un service, permettant de sécurisé l accès au service ainsi d identification de son consommateur) - L emplacement/adresse (URL) du document WSDL qui sert à décrire le service getstudentbyid : http://podbridge12.intranet/projects/unstable/podbridge/web/index.php/wsdl/auto /691292877050480f54b5/getStudentById Les deux figures suivantes représentent des extraits du même document WSDL décrivant le service getstudentbyid : ISET Djerba TriTux PAGE 21

Chapitre 2 : Etat de l art Figure 6 Premier extrait du document WSDL Figure 7 Deuxième extrait du document WSDL Grâce au document WSDL on a pu : - Identifier les paramètres nécessaires ainsi que leurs types pour pouvoir générer le message XML SOAP (requête) approprié pour notre service. - Savoir d avance la structure du message de retour XML SOAP (réponse). - Identifier l emplacement (URL) du service web. ISET Djerba TriTux PAGE 22

Chapitre 2 : Etat de l art Invoquer un service web SOAP est le faite d envoyer à travers HTTP-POST un message au format XML (Requête) à l adresse URL (SOAP Address) indiquée dans le document WSDL. Requête (Message XML SOAP envoyé par le client): Figure 8 Message XML SOAP Requête Réponse (Message XML SOAP Renvoyé par le serveur): Figure 9 Message XML SOAP - Réponse Les avantages : - Consulter la BD sans la moindre requête SQL, ISET Djerba TriTux PAGE 23

Chapitre 2 : Etat de l art - la logique métier est caché à l utilisateur (procédures d authentification au SGBD, les différentes requêtes ) - aucune information n est communiquée sur le serveur de base de données (Type, IP, Port, nom des tables, utilisateur...), - l invocation du service est sécurisée par une clé (key) d authentification, - grâce au WSDL, on connait les différents paramètres, les variables, les types du service. - tout les services web peuvent êtres consumer/tester par le même client. - Le port 80 est toujours ouvert parce qu'il est employé par le protocole HTTP utilisé par les navigateurs Web, donc l invocation d un service web peut être possible de n importe quel emplacement et par n importe quel plateforme. - La quasi-totalité des langages de programmation supportent des bibliothèques ou des extensions lui permettant d invoquer les services web SOAP ou d envoyer des requêtes HTTP-Post. 2.2.3. Résumé On peut dire que les services web : - communiquent en utilisant des protocoles ouverts, - sont souvent réutilisables, - sont des composants d'application, - sont autonomes et auto-descriptif, - peuvent être utilisés par d'autres applications, - se basent sur XML. ISET Djerba TriTux PAGE 24

Chapitre 2 : Etat de l art 2.3. Orchestration de Services web 2.3.1. Introduction Dans le concept SOA, l orchestration s explique par un enchainement d invocation de services web de fines granularités obéissant à un chef d orchestre : WS-BPEL 18 est un langage d orchestration de services web. Dans un service composite les services web sont reliés à travers des standards (Messages XML). Ces standards assurent le découplage, c est-à-dire la réduction des dépendances ; (Couplage faible). 2.3.2. Exemple Dans cet exemple, on se propose de réaliser un processus pour une gamme d appareils mobile, qui renseigne son utilisateur sur les salons de thé les plus proches en les indiquant sur la carte de Google Maps. Notre process aura besoin de faire appel à 4 services partenaires (correspondent aux rectangles colorés en verts dans le diagramme qui suit). Voici une description sur le rôle de chacun de ces services : 1) Service embarqué: Un service embarqué dans l appareil mobile, à son invocation, il renvoi toutes les informations confidentielles à propos son utilisateur (profil utilisateur) tel que son nom, prénom, numéro de sa carte crédit, code. 2) Internet Banking Web Service : Service web fournit par la banque de l utilisateur de l appareil qui lui permet de consulter son solde en tout sécurité. 3) GSM Tracking Web Servie : Service web de géolocalisation fournit par l opérateur de téléphonie mobile. Il permet de renvoyer la longitude et la latitude de l emplacement de l appareil. 18 (Business Process Execution Language) ISET Djerba TriTux PAGE 25

Chapitre 2 : Etat de l art 4) Google maps API : Service web fournit par Google permettant de renvoyer des informations (tel que : sa nature, son nom, longitude, latitude ) sur les endroits qui entourent un point donné par sa longitude et latitude. ISET Djerba TriTux PAGE 26

Chapitre 2 : Etat de l art Services partenaire (Google Maps API) Service partenaire (GSM Tracking) L'appareil Mobile Service partenaire (Internet Banking Service) {Donnée: Rayon (real) min=0.1 max=10.0} Saisir le rayon (zone de recherche - Valeur en km) Entrée: (Aucun) Sortie: - SN (Subscriber number) (number) - numéro de compte (number) Entrée: - Cherche (string) = "Salon de thé" - Rayon en KM (real) - Longitude (string) - Lattitude (string) Entrée: - SN (Subscriber Number) (number) Sortie: - Logitude (string) - Lattitude (string) HTTPS (SSL) Quel est son numéro de tel et le numéro de sa carte de crédit? Saisir code confidentiel Sortie: Quel est mon solde? - Nombre (integer) - Liste des salons de thé (string XML) [Solde >= 10 Dinars] [Solde < 10 Dinars] Quelle est ma géoposition (longitude & latitude) Afficher message «Ce n est pas le moment pour aller au salon de thé!!!» Enrée: - numéro de compte (number) - code (string) Quelles sont les espaces qui m entourent? Sortie: - Solde (real) [Nombre = 0] [Nombre > 0] Afficher message «Désolé! Aucun salon de thé trouvé dans votre position.» Indiquer les salons de thé sur la carte. Figure 10 Exemple d un processus faisant appel à 4 services ISET Djerba TriTux PAGE 27

Chapitre 2 : Etat de l art En examinant le diagramme précédent on constate que les différents services dépendent les uns des autres. La longitude et la latitude renvoyées par le service de géolocalisation fournis par l opérateur ont étés utilisées dans les paramètres d entrées du service Google Maps. 2.3.3. Le langage BPEL BPEL est l acronyme de «Business Process Execution Language», qui est un langage de programmation destiné à l exécution des procédures d entreprises. BPEL4WS «Business Process Execution Language For Web Services», devenu WS- BPEL est un standard de l orchestration de services web. Ce langage a été défini dans sa version 2.0 par une spécification du consortium OASIS 19 en 2007. BPEL : Architecture Les trois principaux éléments de BPEL sont : - Editeur graphique BPEL (BPEL Designer) : Outil permettant la génération du code BPEL à travers une interface graphique. - Process flow template : code source (BPEL) du processus métier générer par l éditeur graphique BPEL. - Moteur BPEL (BPEL Engine) : Le moteur BPEL agissant comme une machine virtuelle, permet l exécution du code BPEL (ça inclus l invocation des servies web, le mapping de donnés, les transactions, la sécurité, et encore plus ) 19 Organization for the Advancement of Structured Information ISET Djerba TriTux PAGE 28

Chapitre 2 : Etat de l art Business Expert End User / Application Design Time Run Time BPEL Designer Generates Process flow template Executes BPEL Engine Figure 11 20 Eléments de BPEL (Architecture) Fichier BPEL : C est un fichier dont le contenu est basé sur XML et qui porte dans la plus part des cas l extension (.bpel), qui représente le code source de l application qui va constituer le processus décrivant la logique des actions à exécuter par le moteur d orchestration. Le code BPEL (syntaxe) : BPEL est un langage d orchestration de services web basé sur langage XML, comme n importe quel langage de programmation il possède un vocabulaire propre à lui. - La balise <process> : Représente l élément racine du document BPEL, dans la quel se trouve la description du processus. Par exemple l attribut name pour donner un nom au processus. <process name="processrubyid" targetnamespace="http://enterprise.netbeans.org/bpel/processrubyid/processrubyid" [ ] xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:xsd="http://www.w3.org/2001/xmlschema" - La balise <import> : Permet d importer un fichier WSDL 20 Figure - Référence: http://www.developer.com/services/article.php/3609381/an- Introduction-to-BPEL.htm ISET Djerba TriTux PAGE 29

Chapitre 2 : Etat de l art <import namespace="urn:tns" location="services_rnu.wsdl" importtype="http://schemas.xmlsoap.org/wsdl/"/> BPEL. - La balise <partenerlinks> : Permet de lier des actions définies dans le fichier WSDL (via partnerlinktype) au process <partnerlinks> [ ] <partnerlink name="pbserviceslocalpl" xmlns:tns="http://enterprise.netbeans.org/bpel/serviceswrapper" partnerlinktype="tns:podbridgelinktype" partnerrole="podbridgerole"/> [ ] </partnerlinks> - La balise <variables> : Permet de définir les variables utilisées par le processus. <variable name="key" type="xsd:string"/> - La balise <sequence> : Pour réunir une suite d actions à exécuter dans le processus. <sequence name="main_seq"> [Actions] </ sequence> - La balise <receive> : Permet de recevoir un signal de l extérieur d un processus, ce qui permettra d instancier le processus, ou d attendre qu un événement se termine avant de continuer le processus. <receive name="receive" createinstance="yes" partnerlink="processrubyidpl" operation="processrubyidoperation" xmlns:tns="http://j2ee.netbeans.org/wsdl/processrubyid/processrubyid" porttype="tns:processrubyidporttype" variable="processrubyidoperationin"/> - La balise <reply> : Permet de renvoyer une réponse à un partnerlink qui en attend une. <reply name="reply" partnerlink="processrubyidpl" operation="processrubyidoperation" xmlns:tns="http://j2ee.netbeans.org/wsdl/processrubyid/processrubyid" porttype="tns:processrubyidporttype" variable="processrubyidoperationout"/> ISET Djerba TriTux PAGE 30

Chapitre 2 : Etat de l art - La balise <invoke> : Permet d appeler un service web. <invoke name="create_ftp" partnerlink="pbserviceslocalpl" operation="docreateftpuseraccount" porttype="pbns:podbridgeporttype" inputvariable="docreateftpuseraccountin" outputvariable="docreateftpuseraccountout"/> - La balise <if> : Condition <if name="ifhastel"> <condition>$getstudentbyidout.body/ns1:response/ns1:tel!= ''</condition> </if> [ ] - La balise <flow> : Permet l exécution en parallèle de plusieurs actions. <flow name="flow1"> [ ] </flow> - La balise <foreach> : <foreach name="foreach1" parallel="no" countername="foreach1counter"> <startcountervalue>0</startcountervalue> <finalcountervalue>$variable</finalcountervalue> [ ] </ foreach > - La balise <while> : <while name="while1"> <condition>$variable!= true()</condition> [ ] </while> - La balise <repeatuntil> : <repeatuntil name="repeatuntil1"> [ ] <condition>$getnextidout.body/ns0:response/ns0:last = true()</condition> </repeatuntil> ISET Djerba TriTux PAGE 31

Chapitre 2 : Etat de l art 2.3.4. Résumé Avantages de BPEL - Séparer le logique processus de la logique application, - Possibilité de changer le processus sans impact sur les applications, - Agilité de l entreprise ou l organisme, - Présenter le processus comme un service, - Portable : supporté par plusieurs serveurs (moteurs BPEL), - Basé sur XML, - Supporte plusieurs fonctionnalités tel que (Exécution asynchrone, fonction XSLT 21, exécution en parallèle, validation, exceptions ). 21 extensible Stylesheet Language Transformation ISET Djerba TriTux PAGE 32

Chapitre 2 : Etat de l art 2.4. Résumé sur le concept SOA Les avantages : - Se base sur des standards (Exemple : SOAP/WSDL pour les services web et BPEL pour orchestration) - interopérabilité : ne différencie pas les plateformes (matérielles et logicielles), - une réutilisabilité possible de services, - améliore la rapidité ainsi que la productivité des développements, - une modularité permettant de remplacer facilement un service par un autre, - de meilleures possibilités d évolution, - une plus grande tolérance aux pannes, - une maintenance facilitée. Les inconvénients : - Le temps de réponse est plus long en le comparant avec le temps de réponse du système final, cet alourdissement est à l origine du protocole utilisé et du système d intermédiation (middlewares) : analyse des messages, ordonnancement, le Framework, sécurité, logging, - Si le niveau de granularité d un service augmente, le temps de réponse lui aussi augmente. - La sécurité dépends de l infrastructure elle-même ; les logiciels d intermédiation, les équipements de routage, les protocoles utilisés (pour le cas des services web, il est conseiller d utiliser HTTPS) ISET Djerba TriTux PAGE 33

3. 3.1. Introduction Maîtriser des langages de programmation orientée objet tel que PHP, C++ ou Java est aujourd hui quelque chose fondamentale pour la réalisation des applications complexes, en plus grâce à la programmation objet, on apprendra à savoir décomposés les grands problèmes en des sous-problèmes, et par suite ça permet à des équipes indépendantes de les résoudre aisément. Malgré ça une question qui se pose toujours : comment va-t-on présenter notre application à des individus ne maitrisant pas le langage par lequel a été développé? Pour cela, il nous faut : 1) un langage (pour s'exprimer clairement à l'aide des concepts objets), qui doit permettre de : - représenter des concepts abstraits (graphiquement par exemple), - limiter les ambiguïtés (parler un langage commun, au vocabulaire précis, indépendant des langages orientés objet), - faciliter l'analyse (simplifier la comparaison et l'évaluation de solutions). 2) une démarche d'analyse et de conception objet, pour : - ne pas effectuer une analyse fonctionnelle et se contenter d'une implémentation objet, mais penser objet dès le départ, - définir les vues qui permettent de décrire tous les aspects d'un système avec des concepts objets. UML est notre choix! UML est avant tout un support de communication performant, qui facilite la représentation et la compréhension de solutions objet : - Sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. ISET Djerba TriTux PAGE 34

- L'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions. - Son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. Comme UML n'impose pas de méthode de travail particulière, il peut être intégré à n'importe quel processus de développement logiciel de manière transparente. UML est une sorte de boîte à outils, qui permet d'améliorer progressivement nos méthodes de travail, tout en préservant nos modes de fonctionnement. Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait possible. La faculté d'uml de se fondre dans le processus courant, tout en véhiculant une démarche méthodologique, facilite son intégration et limite de nombreux risques (rejet des utilisateurs, coûts...). 3.2. Phase 1 : Conception des Services Web 3.2.1. Introduction Cette première phase de l étude conceptuelle s intéresse au 3 premiers couches du Concept SOA. Dans notre étude on s intéressera à la modélisation des connecteurs PodBridge 1.2, à travers lesquels on va intégrer les différentes systèmes et protocoles présents. Ces connecteurs servent d'interface entre le middleware (PodBridge) et les différents systèmes applicatifs présents. Les connecteurs de PodBridge sont des classes qui dérivent tous de la même classe mère PodBridgeConnector et qui implémentent l interface PodBridgeConnectorInterface. ISET Djerba TriTux PAGE 35

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer NOM_DU_CONNECTEUR Figure 12 Modélisation d un connecteur PodBridge1.2 (Cas général) Les différents systèmes et ressources visés par notre projet sont répartis sur deux réseaux géographiquement distants, le premier est un réseau local d un établissement d'enseignement supérieur et l autre est celui du Réseau National Universitaire (RNU). Les systèmes informatiques visés de l établissement supérieur: 1) Le serveur de base de données dans lequel sont centralisées les informations sur chaque étudiant. 2) Le serveur FTP dédié aux étudiants du département informatique. Chaque étudiant à le droit d avoir un seul compte dans le quel il peut stocker ses documents, comme il peut ainsi s en servir même de chez lui. ISET Djerba TriTux PAGE 36

3) Le point d accès sans fil du département informatique qui permet une connexion sans fil au réseau local de l établissement et à internet, la connexion est sécurisé grâce au filtrage MAC ainsi par une clé. 4) Une imprimante partagée sur le réseau de l établissement. 5) Un Modem GSM permettant l envoi des SMS en masse. Les systèmes informatiques visés du RNU: 1) Le serveur web d inscription universitaire «inscription.edu.demo». 2) Le serveur mail «rnu.edu.demo» pour héberger les comptes de messageries électronique des étudiants et des enseignants. 3.2.2. Urbanisation du SI de l établissement 3.2.2.1. Le serveur de base de données PostgreSQL Dans ce projet, on a supposé que toutes les informations sur les étudiants sont stockées dans une seule table appelée «etudiant». Description de la table «etudiant» : etudiant id : character varying(8) <<PK>> nom : character varying(25) prenom : character varying(25) dep : character varying(5) spec : character varying(5) niveau : integer tel : character varying(8) email : character varying(255) loginftp : character varying(255) adrmac : character varying(17) refrecu : character varying(16) process : character varying(3) Figure 13 - Table «etudiant» ISET Djerba TriTux PAGE 37

Description des attributs : Champ id nom prenom dep spec niveau Tel email loginftp adrmac refrecu process Identifiant de l étudiant Nom de l étudiant. Prénom de l étudiant. Code de département Code de spécialité Niveau Description Numéro de téléphone personnel (GSM). Adresse email. Login du compte FTP sur le réseau de l institut. Adresse MAC de l interface réseau sans fil de l ordinateur portable de l étudiant. Référence de l accusé de payement. Code d état du process. Objectif : Avoir 3 services web qui permettent de : 1) Récupérer toutes les informations sur un étudiant, 2) Mettre à jours une ou plusieurs informations sur un étudiant, 3) Connaitre l identifiant de l étudiant suivant. Note : En cas d erreur (identifiant non existant, serveur déconnecté ) chaque service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure suivante représente la modélisation de la classe BDetu : ISET Djerba TriTux PAGE 38

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer BDetu -conn : ressource = null +getstudentbyid() : array +updatestudentbyid() : boolean +getnextid() : array -executesql() : array +connect() : boolean +disconnect() : boolean Figure 14 - Classe BDetu (Connecteur PodBridge de l établissement) ISET Djerba TriTux PAGE 39

Service Service Service Rapport PFE Description des attributs de la classe BDetu: Nom de l attribut Description Valeur initiale conn Ressource PostgreSQL Client null Description des méthodes de la classe BDetu : Nom de la méthode Description Entrée Sortie getstudientbyid updatestudentbyid getnextid executesql Renvoi les informations sur un étudiant depuis la base de données. Met à jour une ou plusieurs informations sur un étudiant tel que, son email, tel, login ftp Renvoi l identifiant de l étudiant suivant. Envoi la requête SQL au SGBD et revoie le résultat. id : Identifiant. String id :Identifiant. String Tel String adrmac String ftp String refrecu String process String id : Identifiant. (Optionnel) - Si elle prend null c est pour récupérer le premier identifiant String Code état du process (Filtre) sql : Requête SQL String Informations sur l étudiant (id,nom, prénom, dep,spec,niveau,te l,email,loginftp,adr mac,refrecu,proce ss). Array Vrai si succès de la mis à jour. boolean Identifiant. String Résultat de la requête. Array Numrows : Nombre de ligne retournées integer connect Se connecter au serveur Vrai si succès de la ISET Djerba TriTux PAGE 40

disconnect PostgreSQL (initialise la ressource conn) Se déconnecter du serveur PostgreSQL et libère la ressource conn. connexion. boolean Vrai en cas de succès de la déconnexion. boolean Les méthodes suivantes: getstudentbyid(), updatestudentbyid() et getnextid() seront choisis pour êtres exposées en tant que services web SOAP à travers PodBridge. La figure suivante fournit une description étendue sur la logique métier caché derrière chaque service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 41

PodBridge 1.2 SOA Middleware postgresql (5432) Frontend Monitor transactions log Setup PB1.2 PB1.2 Core Trace requests and responses PB1.2 Connector «Bdetu.connector.php» End system PostgreSQL DBMS PodBridge admin HTTP (80) Get WSDL SOAP web service API Authenticate and check privilege Call method : getstudentbyid() << Include >> SQL Execute : SELECT.. FROM.. WHERE.. << Include >> << Include >> Call method : executesql() Invoke WS : getsudentbyid << Include >> Call method : getnextid() << Include >> << Include >> SQL Execute : UPDATE.. SET.. WHERE.. DBA Service Consumer Invoke WS : updatestudentbyid Invoke WS : getnextid Handle request << Include >> if cached Call method : updatestudentbyid() Tell PostgreSQL Server to perform the operation Get response from cache Figure 15 Modélisation de la logique métier (Connecteur BDetu) ISET Djerba TriTux PAGE 42

3.2.2.2. Le serveur FTP dédié aux étudiants Objectif : Avoir 7 services web qui permettent de : 1) Créer un nouveau compte FTP, 2) Modifier la date d expiration d un compte FTP, 3) Modifier le message de bienvenu affiché lors de la connexion au compte FTP, 4) Désactiver le message de bienvenu affiché lors de la connexion au compte FTP, 5) Modifier le mot de passe d un compte FTP, 6) Supprimer un compte FTP, 7) Transférer des fichiers ou répertoires vers n importe quel compte FTP. Note : En cas d erreur (utilisateur déjà existant, serveur FTP déconnecté ) chaque service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure suivante représente la modélisation de la classe FTPAccount : ISET Djerba TriTux PAGE 43

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer FTPAccount -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array -generaterandompasswd() : string +ifuserexists() : boolean -getunixdate() : string +docreateftpuseraccount() : array +setftpuseraccountexpirydate() : boolean +setftpuserwelcomemsg() : boolean +dodisableftpuserwelcomemsg() : boolean +dochangeftpuserpassword() : boolean -docheckpassword() : boolean +dodeleteftpuseraccount() : boolean +doftpsendfile() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 16 - Classe FTPAccount (Connecteur PodBridge de l établissement) ISET Djerba TriTux PAGE 44

SERVICE Rapport PFE Description des attributs de la classe FTPAccount : Nom de l attribut Description Valeur initiale sshcon Ressource sshclient null authenticated regexvalidator Pour identifier si la connexion au serveur SSH est établit et en cours. Renferme différentes expressions régulières. False Expression régulière d un nom d utilisateur. Description des méthodes de la classe FTPAccount : Nom de la méthode Description Entrée Sortie generaterandompasswd ifuserexists getunixdate docreateftpuseraccoun t Génère un mot de passe aléatoire. Vérifie si un utilisateur existe déjà sur le système. Converti une date au format JJ/MM/AAAA en une date au format MM/JJ/AAAA. Créer un nouveau compte d utilisateur FTP. len : Longueur du mot de passe (optionnel) 5 par défaut Integer user : Nom d utilisateur String date : Une date (JJ/MM/AAAA) String user : Nom d utilisateur String expiry_date : Date d expiration boolean use_welcome : Utiliser le message de bienvenu par défaut (Vrai par Mot de passe. String Vrai si l utilisateur est déjà existant. boolean Une date (MM/JJ/AAAA) String (login, mot de passe, nom de domaine et n port ftp) Array ISET Djerba TriTux PAGE 45

SERVICE SERVICE SERVICE SERVICE SERVICE Rapport PFE défaut) boolean setftpuseraccountexpir ydate Modifie la date d expiration d un compte utilisateur FTP. user : Nom d utilisateur String expiry_date : Date d expiration String Vrai si la date d expiration du compte à été modifiée avec succès. boolean setftpuserwelcomems g Modifie le fichier «welcome.msg» qui existe dans la racine du compte utilisateur FTP. user : Nom d utilisateur. String message : Message de bienvenu. String Vrai si le contenu du fichier «welcome.msg à été modifier. boolean dodisableftpuserw elcomemsg Supprime le fichier «welcome.msg» qui existe dans la racine du compte utilisateur FTP. user : Nom d utilisateur. String Vrai si le fichier «welcome.msg à été supprimer. boolean dochangeftpuserpa ssword Modifie le mot de passe d un compte utilisateur FTP. user : Nom d utilisateur. String password : Ancien mot de passe. String Vrai si le mot de passe a été changé avec succès. boolean new_password : Nouveau mot de passe. String docheckpassword Vérifie si le mot de passe passé en paramètre est correct. user : Nom d utilisateur. String password : Mot de passe String Vrai si la vérification est positive et faux dans le cas contraire. boolean dodeleteftpuseracc ount Supprime un compte utilisateur FTP du système. user : Nom d utilisateur. String Vrai si le compte d utilisateur a été supprimé avec succès. boolean ISET Djerba TriTux PAGE 46

SERVICE Rapport PFE doftpsendfile Fait une copie des fichiers ou dossiers d une source à un compte utilisateur FTP. file : Chemin du fichier ou du répertoire source. String Vrai si la copie de fichiers est terminée avec succès. boolean user : Nom d utilisateur. String ssh2exec Demande au serveur SSH d exécuter une commande Shell. cmd : La commande. String exception : Lever une exception dans le cas où le résultat retourné par la commande est une erreur. (Vrai par défaut) boolean Le résultat d exécution de la commande. String readresponse : si elle prend vrai, on récupère le résultat retourné par la commande (Faux par défaut) boolean connect Se connecter au serveur SSH (initialise la ressource sshcon). Vrai en cas de succès de la connexion. boolean disconnect Se déconnecter du serveur SSH et libère la ressource sshcon. Vrai en cas de succès de la déconnexion. boolean Les méthodes suivantes: docreateftpuseraccount (), setftpuseraccountexpirydate (), setftpuserwelcomemsg (), dodisableftpuserwelcomemsg (), dodisableftpuserwelcomemsg (), dodeleteftpuseraccount () et doftpsendfile () seront choisis pour êtres exposées en tant que services web SOAP à travers PodBridge. ISET Djerba TriTux PAGE 47

La figure de la page suivante fournit une description étendue sur la logique métier caché derrière chaque service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 48

P o d B r id g e 1.2 S O A M id d le w a r e S S H ( 22) F T P ( 21) F r o n t e n d M o n ito r tr a n s a c tio n s lo g S e tu p P B 1. 2 PB1.2 C o r e T r a c e r e q u e s ts a n d r e s p o n s e s PB1.2 C o n n e c t o r «F T P A c c o u n t.c o n n e c t o r.php» C a ll m e th o d : d o C r e a te F T P U s e r A c c o u n t () << In c lu d e >> C a ll m e th o d : g e n e r a te R a n d o m P a s s w d () E n d s y s t e m O p e n S S H a n d p r o F T P d o n U b u n t u s e r v e r P B a d m in H T T P ( 80) G e t W S D L S O A P w e b s e r v ic e A P I A u th e n tic a te a n d c h e c k p r iv ile g e << In c lu d e >> << In c lu d e >> << In c lu d e >> C a ll m e th o d : ifu s e r E x is ts () << In c lu d e >> S h e ll e x e c u te : u s e r a d d - g F T P... S e r v ic e C o n s u m e r In v o k e W S : d o C r e a te F T P U s e r A c c o u n t In v o k e W S : s e tf T P U s e r A c c o u n te x p ir y D a te In v o k e W S : s e tf T P U s e r W e lc o m e M s g In v o k e W S : d o F T P s e n d F ile << In c lu d e >> C a ll m e th o d : s e tf T P U s e r W e lc o m e M s g () H a n d le r e q u e s t << In c lu d e >> if c a c h e d G e t r e s p o n s e fr o m c a c h e C a ll m e th o d : d o F T P s e n d F ile () C a ll m e th o d : s e tf T P U s e r A c c o u n t E x p ir y D a te () << In c lu d e >> << In c lu d e >> C a ll m e th o d : ssh2 E x e c () << In c lu d e >> << In c lu d e >> T e ll S S H S e r v e r to p e r fo r m th e o p e r a tio n << In c lu d e >> C a ll m e th o d : g e tu n ix D a te () S h e ll e x e c u te : u s e r m o d - e... S h e ll E x e c u te : c p S h e ll E x e c u te : c h o w n... F T P S e r v e r a d m in Figure 17 - Modélisation de la logique métier (Connecteur FTPAccount) ISET Djerba TriTux PAGE 49

3.2.2.3. Le point d accès sans fil Objectif : Avoir 3 services web qui permettent de : 1) Ajouter une adresse dans le filtre MAC du point d accès sans fil (autorisation d accès). 2) Supprimer une adresse du filtre MAC du point d accès sans fil. (interdiction d accès) 3) Récupérer des informations sur le point d accès sans fil. Note : En cas d erreur (format adresse MAC incorrecte, connexion impossible au Point d accès ) chaque service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure ci-dessous représente la modélisation de la classe APACLManager : «interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer APACLManager -regexvalidator : array +doforwardmacaddr() : array +doromoveforwordedmacaddr() : boolean +getaccespointinfo() : array +connect() : boolean +disconnect() : boolean Figure 18 Classe APACLManager (Connecteur PodBridge de l établissement) ISET Djerba TriTux PAGE 50

SERVICES Rapport PFE Description des attributs de la classe APACLManager : Nom de l attribut Description Valeur initiale regexvalidator Renferme différentes expressions régulières. Expression régulière d une adresse MAC. Description des méthodes de la classe APACLManager : Nom de la méthode Description Entrée Sortie doforwardmacaddr doromoveforwordedm ACaddr getaccespointinfo connect disconnect Ajoute une adresse MAC dans l ACL du point d accès sans fil. (Autorise l accès au réseau) Supprime une adresse MAC depuis l ACL du point d accès sans fil. (Interdit l accès au réseau) Renvoi des informations sur le point d accès (l SSID et la clé d authentification). Se connecter au serveur TELNET. Se déconnecter du serveur TELNET. macaddr : Adresse MAC. String macaddr : Adresse MAC. String Vrai si adresse à été ajoutée à la liste de contrôle du point d accès. boolean Vrai si adresse à été supprimer de la liste de contrôle du point d accès. boolean (clé d authentificatio n, SSID). Array Vrai en cas de succès de la connexion. boolean Vrai en cas de succès de la déconnexion. boolean Les méthodes suivantes: doforwardmacaddr (), doromoveforwordedmacaddr () et getaccespointinfo () seront choisis pour êtres exposées en tant que services web SOAP à travers PodBridge. ISET Djerba TriTux PAGE 51

La figure de la page suivante fournit une description étendue sur la logique métier caché derrière chaque service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 52

PodBridge 1.2 SOA Middleware TELNET (23) PodBridge admin Frontend Monitor transactions log Setup PB1.2 Get WSDL PB1.2 Core Trace requests and responses PB1.2 Connector «APACLManager.connector.php» Call method : doforwardmacaddr() << Include >> End system Wireless Access Point HTTP (80) SOAP web service API Invoke WS : doforwardmacaddr Authenticate and check privilege << Include >> << Include >> << Include >> Call method : doromoveforworded MACaddr() Call method : SocketSend() << Include >> Add mac address to ACL Network admin Service Consumer Invoke WS : doromoveforworded MACaddr Handle request << Include >> Tell Telnet Server to perform the operation Remove mac address from ACL if cached Invoke WS : getaccespointinfo Get response from cache Call method : getaccespointinfo() Figure 19 - Modélisation de la logique métier (Connecteur APACLManager) ISET Djerba TriTux PAGE 53

3.2.2.4. Le serveur d impression CUPS Objectif : Avoir 2 services web qui permettent de : 1) Imprimer une page du web sur une imprimante partagée via CUPS, 2) Retourner une liste de noms des imprimantes partagées par le serveur CUPS. Note : En cas d erreur (page web introuvable, serveur CUPS déconnecté ) chaque service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure ci-dessous représente la modélisation de la classe IPPService : «interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer IPPService -ipp : CupsPrintIPP Object = null +doprintwebpage() : boolean -doprintinternaldocument() : boolean +connect() : boolean +disconnect() : boolean Figure 20 Classe IPPService (Connecteur PodBridge de l établissement) Description des attributs de la classe IPPService : Nom de l attribut Description Valeur initiale ipp Objet de la classe CupsPrintIPP. null ISET Djerba TriTux PAGE 54

SERVICES Rapport PFE Description des méthodes de la classe IPPService : Nom de la méthode Description Entrée Sortie doprintwebpage getprinters doprintinternaldocument connect disconnect Envoyer un ordre d impression d une page web à une imprimante partagée. Renvoie les adresses (URI) des imprimantes partagées par CUPS Envoyer un ordre d impression à une imprimante partagée d un document présent sur le serveur. Se connecter au serveur CUPS. Se déconnecter du serveur CUPS. url : URL de la page web. String jobname : Nom du job d impression (optionnel) String filepath : Chemin d accès à un document présent sur le serveur. String jobname : Nom du job d impression (optionnel) String Vrai si l ordre d impression à été envoyé. boolean Des URI délimités par des points virgules. String Vrai si l ordre d impression à été envoyé. boolean Vrai en cas de succès de la connexion. boolean Vrai en cas de succès de la déconnexion. boolean Les méthodes suivantes: doprintwebpage () et getprinters () seront choisis pour êtres exposées en tant que services web SOAP à travers PodBridge. La figure de la page suivante fournit une description étendue sur la logique métier caché derrière chaque service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 55

PodBridge 1.2 SOA Middleware cups (631) PodBridge admin Frontend Monitor transactions log Setup PB1.2 PB1.2 Core Trace requests and responses PB1.2 Connector «IPPService.connector.php» End system CUPS Server HTTP (80) Get WSDL SOAP web service API Authenticate and check privilege Call method : doprintinternaldocument() << Include >> Scan for available printers Invoke WS : doprintwebpage << Include >> << Include >> << Include >> << Include >> Tell CUPS Server to perform the operation start print job Network admin Service Consumer Invoke WS : doprintinternaldocument Handle request << Include >> Call method : doprintwebpage() << Include >> Invoke WS : getprinters if cached Call method : getprinters() Get response from cache Figure 21 - Modélisation de la logique métier (Connecteur IPPService) ISET Djerba TriTux PAGE 56

3.2.2.5. Le serveur web (inscription.rnu.demo) Objectif : Avoir 1 service web qui permet de : - Renvoyer la référence et l URL de l accusé de payement d inscription universitaire d un étudiant depuis le site d inscription inscription.edu.demo. Note : En cas d erreur (identifiant incorrecte, site web indisponible ) ce service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure ci-dessous représente la modélisation de la classe wwwsubscr : «interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer wwwsubscr -curl_handle : ressource = null -getaccuseref() : string +getaccuse() : array +ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 22 Classe wwwsubscr (Connecteur PodBridge de l établissement) Description des attributs de la classe wwwsubscr : Nom de l attribut Description Valeur initiale curl_handle ressource curl null Description des méthodes de la classe wwwsubscr : ISET Djerba TriTux PAGE 57

SERVICE Rapport PFE Nom de la méthode Description Entrée Sortie getaccuseref getaccuse connect disconnect Renvoi la référence de l accusé de paiement pour une année universitaire donnée. (si paiement effectué) Renvoi la référence et l URL de l accusé de paiement pour une année universitaire donnée. Si getaccuseref renvoie la référence de l accusé. Initialisation de la ressource Ressource libérée studentident : Identifiant de l étudiant. String au : Année universitaire (AAAA/AAAA). String studentident : Identifiant de l étudiant. String au : Année universitaire (AAAA/AAAA). String Référence de l accusé de paiement. String Référence et url de l accusé de paiement. Array Vrai si la ressource à été initialisée. boolean Vrai si la ressource à été libérée. boolean La méthode getaccuse ( ) sera choisi pour êtres exposée en tant que service web SOAP à travers PodBridge. La figure de la page suivante fournit une description étendue sur la logique métier caché derrière ce service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 58

PodBridge 1.2 SOA Middleware HTTP (80) PodBridge admin Frontend Monitor transactions log Setup PB1.2 PB1.2 Core Trace requests and responses PB1.2 Connector «wwwsubscr.connector.php» End System HTTP Server (inscription.edu.demo ) HTTP (80) Get WSDL SOAP web service API Authenticate and check privilege Call method : getaccuse() << Include >> Get page of requested URL Invoke WS : getaccuse << Include >> << Include >> << Include >> << Include >> Tell WEB Server To perform the operation Authenticate Web user Handle request Call method : getaccuseref() Service Consumer << Include >> if cached Get response from cache Figure 23 - Modélisation de la logique métier (Connecteur wwwsubscr) ISET Djerba TriTux PAGE 59

3.2.2.6. Le modem SMS Objectif : Avoir 1 service web qui permet de : - Envoyer un message court (SMS) à numéro de téléphone particulier. Note : En cas d erreur (format du numéro de téléphone incorrecte, serveur déconnecté ) ce service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure ci-dessous représente la modélisation de la classe SMSService : «interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer SMSService -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array +dosendsms() : boolean -stripspaces() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 24 Classe SMSService (Connecteur PodBridge de l établissement) Description des attributs de la classe SMSService : Nom de l attribut Description Valeur initiale sshcon Ressource client ssh null authenticated Pour identifier si la connexion au serveur SSH est établit et en cours. False ISET Djerba TriTux PAGE 60

SERVICE Rapport PFE regexvalidator Renferme différentes expressions régulières. Expression régulière d un numéro de téléphone de 8 chiffres. Description des méthodes de la classe SMSService : Nom de la méthode Description Entrée Sortie dosendsms stripspaces Envoyer un SMS. destinataire : numéro de téléphone du destinataire. String Supprimer des espaces qui existent dans le numéro de téléphone et valider son format. message : Message texte court à envoyer String phonenumber : Numéro de téléphone String Vrai si l SMS a été envoyé au destinataire boolean Numéro de téléphone sans espaces blanc String ssh2exec Demande au serveur SSH d exécuter une commande Shell. cmd : La commande. String exception : Lever une exception dans le cas où le résultat retourné par la commande est une erreur. (Vrai par défaut) boolean Le résultat d exécution de la commande. String readresponse : si elle prend vrai, on récupère le résultat retourné par la commande (Faux par défaut) ISET Djerba TriTux PAGE 61

connect disconnect Se connecter au serveur SSH (initialise la ressource sshcon). Se déconnecter du serveur SSH et libère la ressource sshcon. boolean Vrai en cas de succès de la connexion. boolean Vrai en cas de succès de la déconnexion. boolean La méthode dosendsms () sera choisi pour être exposée en tant que service web SOAP à travers PodBridge. La figure de la page suivante fournit une description étendue sur la logique métier caché derrière ce service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 62

PodBridge 1.2 SOA Middleware ( podbridge-12.intranet.demo) PodBridge admin HTTP (80) Frontend Monitor transactions log Setup PB1.2 Get WSDL SOAP web service API PB1.2 Core Trace requests and responses Authenticate and check privilege PB1.2 Connector «SMSService.connector.php» Call method : stripspaces() SSH (22) End System Server Invoke WS : dosendsms << Include >> << Include >> << Include >> Call method : dosendsms() Send SMS command Server Admin Handle request << Include >> Service Consumer << Include >> Tell SSH Server to perform the operation if cached Get response from cache Figure 25 - Modélisation de la logique métier (Connecteur SMSService) ISET Djerba TriTux PAGE 63

3.2.3. Urbanisation du SI du RNU 3.2.3.1. Serveur Mail Objectif : Avoir 7 services web qui permettent de : 1) Créer un nouveau compte mail (1 ère version - nom d utilisateur est au choix), 2) Créer un nouveau compte mail (2 ème version - le nom d utilisateur doit être autogénéré à partir du nom et le prénom de son propriétaire), 3) Changer le mot de passe d un compte mail, 4) Supprimer un compte mail, 5) Désactive un compte mail, 6) Active un compte mail, 7) Envoyer un message à n importe quelle adresse électronique. Note : En cas d erreur (compte utilisateur déjà existant, problème de connexion au serveur ) chaque service web doit le signaler en renvoyant au client la description et le code de l erreur. La figure ci-dessous représente la modélisation de la classe MailAccount : ISET Djerba TriTux PAGE 64

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer MailAccount -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array -generaterandompasswd() : string -ifuserexists() : boolean -generateusername() : string -dostripatdomain() : string +docreatemailuseraccount2() : array +docreatemailuseraccount() : array +dochangemailuserpassword() : boolean -docheckpassword() : boolean +dodeletemailuseraccount() : boolean +dounlockmailuseraccount() : boolean +dolockmailuseraccount() : boolean +dosendmail() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 26 Classe MailAccount (Connecteur PodBridge 1.2) Description des attributs de la classe MailAccount : Nom de l attribut Description Valeur initiale sshcon Ressource sshclient null authenticated regexvalidator Pour identifier si la connexion au serveur SSH est établit et en cours. Renferme différentes expressions régulières. False Expression régulière pour un nom d utilisateur (mail), prénom et adresse email. ISET Djerba TriTux PAGE 65

SERVICE SERVICE Rapport PFE Description des méthodes de la classe MailAccount : Nom de la méthode Description Entrée Sortie generaterandompasswd ifuserexists generateusername dostripatdomain docreatemailuseracco unt docreatemailuseracco unt2 Génère un mot de passe aléatoire. Vérifie si un utilisateur existe déjà sur le système. Génère un nom d utilisateur à partir du nom et prénom passés en paramètres. Extrait le nom d utilisateur à partir d une adresse email du domaine (rnu.edu.demo). Créer un nouveau compte mail (1) Créer un nouveau compte mail (2) len : Longueur du mot de passe (optionnel) Integer user : Nom d utilisateur String fstname : prénom. String lstname : nom. String emailaddr : adresse email. String user : Nom d utilisateur String genpswd: vrai pour auto générer le mot de passe. boolean password: mot de passe (si genpswd reçoit faux). String fstname : prénom. String lstname : nom. String genpswd: vrai pour auto Mot de passe. String Vrai si l utilisateur est déjà existant. boolean Nom d utilisateur. String Nom d utilisateur. String (adresse email, mot de passe, port POP3, port SMTP, adresse url du webmail SquirrelMail ) Array (adresse email, mot de passe, port POP3, port SMTP, adresse url du webmail SquirrelMail ) ISET Djerba TriTux PAGE 66

SERVICE SERVICE SERVIC E SER VICE SERVIC E Rapport PFE générer le mot de passe. boolean Array password: mot de passe (si genpswd reçoit faux). String dodeletemailuseracco unt Supprime un compte mail. emailaddr : adresse mail. String Vrai si le compte mail a été supprimé avec succès. boolean dounlockmailuseracco unt Active un compte mail. emailaddr : adresse mail. String Vrai si le compte mail a été activé. boolean dolockmailuseraccoun t Désactive un compte mail. emailaddr : adresse mail. String Vrai si le compte mail a été désactivé. boolean dochangemailuserpass word Modifie le mot de passe d un compte mail. emailaddr: adresse email. String password : Ancien mot de passe. String Vrai si le mot de passe a été changé avec succès. boolean new_password Nouveau mot de passe. String dosendmail Permet (à un administrateur) l envoi de messages à n importe quelle adresse électronique. from: adresse email de l envoyeur. String to : adresse email du destinataire. String Vrai si le message à été envoyé avec succès. boolean message : Corps du message String subject : Sujet du ISET Djerba TriTux PAGE 67

message String docheckpassword Vérifie si le mot de passe passé en paramètre est correct. user : Nom d utilisateur. String password : Mot de passe String Vrai si la vérification est positive et faux dans le cas contraire. boolean ssh2exec Demande au serveur SSH d exécuter une commande Shell. cmd : La commande. String exception : Lever une exception dans le cas où le résultat retourné par la commande est une erreur. (Vrai par défaut) boolean Le résultat d exécution de la commande. String readresponse : si elle prend vrai, on récupère le résultat retourné par la commande (Faux par défaut) boolean connect Se connecter au serveur SSH (initialise la ressource sshcon). Vrai en cas de succès de la connexion. boolean disconnect Se déconnecter du serveur SSH et libère la ressource sshcon. Vrai en cas de succès de la déconnexion. boolean ISET Djerba TriTux PAGE 68

Les méthodes suivantes: docreatemailuseraccount (), docreatemailuseraccount2 (), dodeletemailuseraccount (), dounlockmailuseraccount (), dolockmailuseraccount (), dochangemailuserpassword () et dosendmail () seront choisis pour êtres exposées en tant que services web SOAP à travers PodBridge. La figure de la page suivante fournit une description étendue sur la logique métier caché derrière chaque service allant du consommateur de service au système final. ISET Djerba TriTux PAGE 69

PB admin HTTP (80) Service Consumer Frontend Monitor transactions log Setup PB1.2 Get WSDL SOAP web service API Invoke WS : docreatemail UserAccount2 Invoke WS : dochangemail UserPassword Invoke WS : dodeletemail UserAccount Invoke WS : dosendmail PodBridge 1.2 SOA Middleware PB1.2 Core Trace requests and responses Authenticate and check privilege << Include >> << Include >> Handle request << Include >> if cached Get response from cache PB1.2 Connector «MailAccount.connector.php» Call method : docreatemail UserAccount2() Call method : dosendmail() Call method : dodeletemail UserAccount() << Include >> Call method : dochangemail UserPassword() << Include >> << Include >> << Include >> << Include >> Call method : generate generateusername() Call method : ssh2exec() << Include >> << Include >> Tell SSH Server to perform the operation << Include >> Call method : ifuserexists() << Include >> Call method : docheckpassword() SSH (22) POP (110) SMTP (25) HTTP (80) End system OpenSSH and Postfix and Dovecot on Ubuntu server Shell execute : useradd -g mail... Shell execute : userdel -r... Shell Execute : mail -s Shell Execute : usermod -p... Mail Server admin Figure 27 - Modélisation de la logique métier (Connecteur MailAccount) ISET Djerba TriTux PAGE 70

3.2.4. Conclusion Finalement on est arrivé à la fin de cette première phase par la conception des connecteurs PodBridge 1.2. Chaque connecteur englobe une logique métier lui permettant de s adapter et dialoguer avec le système informatique dont il est conçu pour. PodBridge se chargera de la génération des services web SOAP et des WSDL. ISET Djerba TriTux PAGE 71

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer BDetu -conn : ressource = null +getstudentbyid() : array +updatestudentbyid() : boolean +getnextid() : array -executesql() : array +connect() : boolean +disconnect() : boolean FTPAccount -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array -generaterandompasswd() : string +ifuserexists() : boolean -getunixdate() : string +docreateftpuseraccount() : array +setftpuseraccountexpirydate() : boolean +setftpuserwelcomemsg() : boolean +dodisableftpuserwelcomemsg() : boolean +dochangeftpuserpassword() : boolean -docheckpassword() : boolean +dodeleteftpuseraccount() : boolean +doftpsendfile() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean IPPService -ipp : CupsPrintIPP Object = null +doprintwebpage() : boolean -doprintinternaldocument() : boolean +connect() : boolean +disconnect() : boolean APACLManager -regexvalidator : array +doforwardmacaddr() : array +doromoveforwordedmacaddr() : boolean +getaccespointinfo() : array +connect() : boolean +disconnect() : boolean wwwsubscr -curl_handle : ressource = null -getaccuseref() : string +getaccuse() : array +ssh2exec() : stream +connect() : boolean +disconnect() : boolean SMSService -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array +dosendsms() : boolean -stripspaces() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 28 Connecteurs PodBridge (de l établissement) ISET Djerba TriTux PAGE 72

«interface» PodBridgeConnectorInterface +connect() : boolean +disconnect() : boolean PodBridgeConnector #params : array #error : array #sessionlog : array #sessionlogcounter : integer = 0 +getlasterrormsg() : string +setlasterror() +setparam() +getsessionlog() +setsessionlog() : array +getsessionlogcounter() : integer MailAccount -sshcon : ressource = null -authenticated : boolean = false -regexvalidator : array -generaterandompasswd() : string -ifuserexists() : boolean -generateusername() : string -dostripatdomain() : string +docreatemailuseraccount2() : array +docreatemailuseraccount() : array +dochangemailuserpassword() : boolean -docheckpassword() : boolean +dodeletemailuseraccount() : boolean +dounlockmailuseraccount() : boolean +dolockmailuseraccount() : boolean +dosendmail() : boolean -ssh2exec() : stream +connect() : boolean +disconnect() : boolean Figure 29 - Connecteur PodBridge (du RNU) ISET Djerba TriTux PAGE 73

3.3. Phase 2 : Processus métier et orchestration de services 3.3.1. Introduction Finalement, on est arrivés au niveau de la couche orchestration de services. Dans cette phase 2 ème phase de l étude conceptuelle on s intéressera à la conception des processus de coordination d un échange d information à travers l interaction des services web précédemment conçus. Notre objectif est de concevoir à travers de diagrammes d activité (workflows) deux processus métiers (ProcessRUById et BatchProcessRU). 3.3.2. Conception du 1 er processus métier : ProcessRUById Ce processus doit exécuter quelques procédures pour offrir à un étudiant donné par son identifiant les différents services que proposent les systèmes informatiques de l établissement en se référant sur ses informations stockés dans la base de données. Avant d exécuter ces différentes procédures, ce processus doit automatiquement vérifier depuis le site (inscription.edu.demo) si l étudiant a déjà payé les frais d inscription de l année en cours. Quelques remarques : Etats du processus : - EXE : Processus en cours d exécution. - PAI : Renvoyé à la fin d exécution. dans le cas où l étudiant n a pas encore effectué le paiement des frais d inscription. - OK : Renvoyé à la fin d exécution ; Succès de l exécution de toutes les procédures. Voici les différentes procédures que doit exécuter notre processus (ProcessRUById) : - Mettre à jours la valeur du champ process par EXE (dans la table etudiant) pour l identifiant passé en paramètre. - vérifier depuis le site inscription.edu.demo, si l étudiant a effectué le paiement des frais d inscription. Si les frais d inscription n ont pas été payés, un message ISET Djerba TriTux PAGE 74

d alerte doit lui être envoyé par mail et SMS, ensuite le processus doit finir son exécution et renvoyer le message PAI, - envoyer à une imprimante partagée un job d impression pour l accusé de paiement de l étudiant (pour le service de la scolarité de l établissement), - si l étudiant ne possède pas un compte mail, un nouveau compte mail doit donc lui être créé sur le domaine RNU, ensuite les paramètres de son nouveau compte doivent lui être envoyés par SMS. - si l étudiant est en informatique et ne possède pas déjà un compte FTP, alors un nouveau compte FTP doit lui être créé, ensuite les paramètres de son nouveau compte FTP doivent lui être envoyés sur son mail et par SMS. - dans le cas où l étudiant possède déjà un compte FTP, la date d expiration de son compte doive être étendue d une année, - envoyer sur son compte FTP son calendrier, ses cours et TP (en s appuyant sur les informations : département, spécialité et niveau). - si l étudiant a déjà fourni l adresse MAC de la carte réseau sans fil de son ordinateur portable, alors son ordinateur doit être autorisé à se connecté au réseau sans fil de l établissement à traves l interface Wifi, ainsi qu il doit être informé par SMS et mail des paramètres du réseau Sans fil tel que (SSID, Clé), - envoyer à l étudiant un message de bienvenu par mail & SMS, - mettre à jour les données de l étudiant sur la base de donnée par les nouvelles informations telles que : la référence de son accusé de paiement de l année universitaire en cours, son nouveau login FTP, sa nouvelle adresse mail et le code (process state code) renvoyé par le process à sa fin d exécution, - renvoyer le message OK (code sucés d exécution). ISET Djerba TriTux PAGE 75

Donner l identifiant de l'étudiant RECEIVE: ProcessRUByIdIn Mettre à jour la BD, état process EXE INVOKE: «updatestudentbyid» Récupérer les informations de l étudiant depuis la base de données INVOKE: «getstudentbyid» Récupérer la référence de l accusé de paiement et son URL depuis le site inscription.edu.demo INVOKE: «getreceipt» [Paiement effectué] [Paiement non effectué] Lancer un nouveau job d impression pour l accusé de paiement INVOKE: «doprintwebpage» Possède-il un compte e-mail? [non] Créer un nouveau compte e-mail INVOKE: «docreatemailuseraccount» Envoyer les paramètres du nouveau compte mail par SMS INVOKE: «dosendsms» [oui] Mettre à jour la BD, état process PAI INVOKE: «updatestudentbyid» Renvoyer PAI REPLY: ProcessRUByIdOut Son département est-il TI? [non] [oui] Possède-il un compte FTP? [non] Créer un compte FTP INVOKE: «docreateftpuseraccount» [oui] A-t-il donné son adresse MAC? [oui] Mettre à jour le filtre MAC du point d accès Sans fil (Ajout) INVOKE: «doforwardmacaddr» [non] Crée un message welcome pour ce compte FTP INVOKE: «setftpuserwelcomemsg» Envoyer les paramètres du point d accès par SMS INVOKE: «dosendsms» Envoyer les paramètres du nouveau compte FTP par SMS INVOKE: «dosendsms» Etendre le délai d expiration INVOKE: «setftpuseraccountexpirydate» Envoyer les paramètres du point d accès par mail INVOKE: «dosendmail» Envoyer les paramètres du nouveau compte FTP par mail INVOKE: «dosendmail» Envoyer le calendrier,les cours & TP INVOKE: «doftpsendfile» Est-il niveau 2 ou plus? [oui] [non] Envoyer le cour d UML2 INVOKE: «doftpsendfile» Mettre à jour la BD (login FTP, e-mail,refrecu et état process OK ) INVOKE: «updatestudentbyid» Appel service web Envoyer un SMS de bienvenue INVOKE: «dosendsms» Envoyer un mail de bienvenue INVOKE: «dosendmail» Renvoyer OK REPLY: ProcessRUByIdOut Figure 30 - diagramme d'activité «ProcessRUById» ISET Djerba TriTux PAGE 76

3.3.3. Conception du processus : BatchProcessRU Objectif: Concevoir un processus métier permettant d exécuter les mêmes procédures du processus ProcessRUById sur un grand nombre d étudiants, et de notifier l administrateur (celui qui lance le processus) par Mail & SMS à la fin d l exécution. Paramètres d entrés : Un paramètre filtre (chaine de caractère) doit être spécifié avant l exécution du processus et doit prendre l une des valeurs suivantes : ATT 22, PAI ou * (signifie ATT et PAI). Les différents cas : - Si filtre prend ATT : le processus parcoure seulement les identifiants possédants un champ process égale à ATT. - Si filtre prend PAI : le processus parcoure seulement les identifiants possédants un champ process égale à PAI. - Si filtre prend * : le processus parcoure seulement les identifiants possédants un champ process égale à ATT ou PAI. Information renvoyées : A la fin de l exécution du processus, les informations suivantes doivent êtres renvoyés : - Message (Chaine de caractères) : Succes, fail. - Code (Entier) : 0 pour Succes, 2 pour fail. - Date et heure de lacement du processus. (DATETIME). - Date et heure de fin d exécution du process. (DATETIME). 22 Indique que dans la table étudiant l identifiant possédant le champ process égale à ATT n a été traité aucune fois par le processus ProcessRUById. (ATT est la valeur initiale du champ process à chaque nouvelle insertion dans la table etudiant). ISET Djerba TriTux PAGE 77

Donner le filtre (soit PAI, ATT ou * ) RECEIVE: BatchProcessRUIn renvoie le premier identifiant à la première itération Récupérer l indentifiant Suivant INVOKE: «getnextid» Invoquer le service (ProcessRUById) pour l identifiant courant INVOKE: «ProcessRUById» [non] Dernier identifiant? [oui] Notifier l administrateur par SMS INVOKE: «dosendsms» Notifier l administrateur par Mail INVOKE: «dosendmail» Renvoyer (Etat process, date de début et de fin d exécution) REPLY: BatchProcessRUOut Appel service web Figure 31 - diagramme d'activité «BatchProcessRU» 3.3.4. Conclusion Finalement on est arrivé à la fin de la 2 ème phase par la conception de deux processus métiers ProcessRUById et BatchProcessRU permettant l orchestration des services conçus dans la première phase. ISET Djerba TriTux PAGE 78

Chapitre 4 : Réalisation 3.4. Installation & Configuration 3.4.1. Serveur FTP : ftp-etu.intranet.demo - Ajout du domaine ftp-etu.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) 3.4.2. Serveur CUPS : cups.intranet.demo - Ajout du domaine cups.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) - Installation de CUPS Serveur et Client : $ sudo apt-get cups cups-client - Démarrage du serveur CUPS : $ sudo /etc/init.d/cups start Voir l interface web de configuration de serveur CUPS dans la section (3.2) - documentation technique 3.4.3. Serveur de BD PostgreSQL : postgres-83.intranet.demo - Ajout du domaine postgres-83.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) - Installation de PostgreSQL : $ sudo apt-get install postgresql-8.3 - Démarrage de PostgreSQL : $ sudo /etc/init.d/postgresql-8.3 start - Etapes de création du nouvel utilisateur (bdetuadmin) et schéma (bdetu) : ISET Djerba TriTux PAGE 79

$ sudo -u postgres psql h postgres-83.intranet.demo -p 5432 postgres=# create user bdetuadmin; postgres=# create database bdetu owner bdetuadmin; postgres=# \q Création de la structure de la table etudiant et insertion des données de test. Voir Documentation technique (2.1.1 pour le script de création) et (2.1.2 pour le script d insertion). -- Connexion postgres=# \i /home/walid/sql/create.sql postgres=# \i /home/walid/sql/insert.sql postgres=# \q Lister le contenu de la table après l insertion des données de test. -- Connexion postgres=# select * from etudiant; Resultat : 3.4.4. Serveur web d inscription en ligne : inscription.edu.demo - Ajout du domaine ftp-etu.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) Création d un virtualhost (Apache) dans le fichier /etc/apache2/sitesenabled/inscription.edu.demo : <VirtualHost *:80> ServerName inscription.edu.demo DocumentRoot "/var/www/projects/unstable/inscription.edu.demo" ISET Djerba TriTux PAGE 80

DirectoryIndex index.php <Directory "/var/www/projects/unstable/inscription.edu.demo"> AllowOverride All Allow from All </Directory> </VirtualHost> - redémarrage du serveur HTTP: $ sudo /etc/init.d/apache2 restart 3.4.5. Point d accès sans fil : ap-21. intranet.demo - Ajout du domaine ap-21.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) Configuration : - Fonction : Accès Point - SSID : ETUDIANTS_WIRELESS - Norme de sécurité : WPA2 - Clé de chiffrement : soaetbpm 3.4.6. Serveur mail : (ws.rnu.edu.demo) - Ajout du domaine ws.rnu.edu.demo dans /etc/hosts (Voir documentation technique - 1.1) - Installation du serveur POP3/IMAP : $ sudo apt-get install dovecot - Démarrage du serveur POP3/IMAP : $ sudo /etc/init.d/dovecot start - Installation du serveur SMTP : $ sudo apt-get install postfix - démarrage du serveur SMTP : ISET Djerba TriTux PAGE 81

$ sudo /etc/init.d/postfix start - Installation du webmail: $ sudo apt-get install squirrelmail Création d un virtualhost (Apache) dans le fichier /etc/apache2/sites-enabled/ webmail.rnu.edu.demo: <VirtualHost *:80> ServerName webmail.rnu.edu.demo DocumentRoot "/usr/share/squirrelmail" DirectoryIndex index.php <Directory "/usr/share/squirrelmail"> AllowOverride All Allow from All </Directory> </VirtualHost> - redémarrage du serveur HTTP: $ sudo /etc/init.d/apache2 restart Voir capture écran de squirrelmail (écran de connexion) dans la documentation technique. 3.4.7. Modem GSM connecté au serveur Lenny : debian5-02.intranet.demo - Ajout du domaine debian5-02.intranet.demo dans /etc/hosts (Voir documentation technique - 1.1) 3.4.8. PodBridge 1.2 - Ajout du domaine podbridge.intrant.demo et ws.rnu.edu.demo dans /etc/hosts (Voir documentation technique - 1.1) - Déploiement de PodBridge 1.2 : $ mkdir p /var/www/projects/unstable/podbridge && cd /var/www/projects/unstable $ svn co https://svn.tweety.tux/podbridge/trunk podbridge $./pbadmin pb-fix-perms $ sudo -u postgres psql h podbridge.intrant.demo postgres=# create user podbridge; postgres=# create database podbridge owner podbridge; postgres=# \q ISET Djerba TriTux PAGE 82

$./pbadmin pb-build-all-load 3.4.9. Installation de GlassFish ESB 2.1 Voir document accompagné (Glass Fish ESB 2.1 & Netbeans 6.7.1 BPEL Designer Installation & Sample tutorial ) 3.4.10. Installation des plugins SOA & BPEL pour NetBeans Voir document accompagné (Glass Fish ESB 2.1 & Netbeans 6.7.1 BPEL Designer Installation & Sample tutorial ) 3.5. Réalisation des connecteurs 3.5.1. Exemple de réalisation d un connecteur : pbftpaccountconnector Le connecteur pbftpaccountconnector doit êtres copié sous le répertoire : Podbridge/plugins. Les fichiers sous pbftpaccountconnector/data/fixtures sont au format yml 23, destinés pour stocker la configuration (pour la génération du WSDL) ainsi que les paramètres par défaut du connecteur. pbftpaccountconnector/lib/connector contient la classe «FTPAccount.connector.php» qui implémente les différentes méthodes qui seront exposées par PodBridge en tant que services web. 23 Extension pour les fichiers basés sur Yaml (Yaml Ain t Markup Language) ISET Djerba TriTux PAGE 83

Figure 32 - Arborescence du projet PodBridge - Netbeans IDE Ajout du connecteur pbftpaccountconnector à PodBridge (Génération des services web, et WSDL) : ISET Djerba TriTux PAGE 84

3.5.2. Test du service web docreateftpuseraccount par l utilitaire SoapUI 3.0.1 Invocation du service web docreateftpuseraccount XML SOAP Request Message : docreateftpuseraccount Réponse - XML SOAP Response Message: ISET Djerba TriTux PAGE 85

Accès au nouveau compte FTP: Re-Invocation du même service web docreateftpuseraccount utilisant les mêmes paramètres XML SOAP Request Message : Réponse (Utilisateur déjà existant / Code erreur : 804) SOAP Faut Message: Tentative d invocation du service web docreateftpuseraccount (Avec une clé erronée): ISET Djerba TriTux PAGE 86

Réponse (Erreur d authentification) SOAP Faut Message: L illustration de la page suivante donne une vue générale sur l intégration de chacun des systèmes visés au moyen de PodBridge1.2 ISET Djerba TriTux PAGE 87

Réseau local de l établissement (LAN) Réseau National Universitaire (WAN) BD étudiants PostgreSQL postgres-83.intranet.demo SSH : 22 Telnet : 23 IPP : 631 Pgsql : 5432 SSH : 22 FTPAccount FTPAccount.connector.php APACLManager APACLManager.connector.php IPPService IPPService.connector.php BDbetu BDetu.connector.php SMSService SMSService.connector.php Point d accès Sans Fil ap-21.intranet.demo HTTP : 80 SSH : 22 Admin. PodBridge wwwsubscr wwwsubscr.connector.php MailAccount MailAccount.connector.php Admin. PodBridge Administrateur Système Serveur FTP ftp-etu.intranet.demo Serveur CUPS cups.intranet.demo Modem GSM connecté à un serveur Debian Lenny debian5-02.intranet.demo Serveur Web du site d inscription universitaire inscription.edu.demo Serveur Mail SMTP & POP3 rnu.edu.demo Admin. Système PodBridge 1.2 (Middleware SOA) podbridge.intranet.demo PodBridge 1.2 ws.rnu.edu.demo WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP Consommateur de service Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Y Operation Z Consommateur de service Serveurs d application, Ressources Systèmes hétérogènes Protocoles de communication Règles de communication Connecteurs PodBridge Logique métier Middleware SOA PodBridge1.2 Intermédiation entre serveurs d application et consommateurs de services WSDL & Services Web SOAP SOAP endpoint, description, XML, XSD.. Figure 33 1 ère phase de l urbanisation des deux réseaux (Services Web) ISET Djerba TriTux PAGE 88

3.6. Réalisation des processus métiers - phase 2 Déploiement de ProcessRUById et BatchProcessRU : ISET Djerba TriTux PAGE 89

WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y invoke invoke invoke invoke Messages XML SOAP (Requête et réponse) BPEL Receive invoke invoke Reply invoke ProcessRUById GlassFish ESB 2.1 composant sun-bpel-engine bpel-engine.intranet.demo BPEL Receive Invoke Process Reply invoke BatchProcessRU WS SOAP WS SOAP ProcessRUById BatchProcessRU Figure 34 Déploiement de ProcessRUById et BatchProcessRU ISET Djerba TriTux PAGE 90

3.6.1. Test de ProcessRUById (Invocation du service composite) Requête : POST http:// sun-bpel-engine.intranet.demo:9080/processrubyidservice HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: application/soap+xml;charset=utf-8 User-Agent: Jakarta Commons-HttpClient/3.1 Host: sun-bpel-engine.intranet.demo:9080 Content-Length: 281 <soap:envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:proc="processrubyidca"> <soap:header/> <soap:body> <proc:processrubyidoperation> <identifiant>12345678</identifiant> </proc:processrubyidoperation> </soap:body> </soap:envelope> Réponse : HTTP/1.1 200 OK Content-Type: application/soap+xml;charset="utf-8" Transfer-Encoding: chunked Date: Thu, 14 Jan 2010 13:58:02 GMT <?xml version="1.0"?> <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:body> <processrubyidoperationresponse> <statut xmlns:msgns="http://j2ee.netbeans.org/wsdl/processrubyid/processrubyid"> OK</statut> </processrubyidoperationresponse> </env:body> </env:envelope> Voici les informations de l étudiant ayant l identifiant 12345678 après l exécution du processus. (Depuis BD table étudiant) ISET Djerba TriTux PAGE 91

Lancement d un job d impression pour l accusé de paiement : Boite de réception : Paramètres du compte FTP (reçu par mail) : ISET Djerba TriTux PAGE 92

Notification par SMS Message de bienvenu : Compte FTP : ISET Djerba TriTux PAGE 93

La connexion au réseau sans fil (ETUDIANT_WIRELESS) est autorisée : 3.6.2. Test de BatchProcessRU (Invocation du service composite) Requête : POST http://sun-bpel-engine.intranet.demo:9080/batchprocessruservice HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: application/soap+xml;charset=utf-8 User-Agent: Jakarta Commons-HttpClient/3.1 Host: sun-bpel-engine.intranet.demo:9080 ISET Djerba TriTux PAGE 94

Content-Length: 382 <soap:envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:bat="batchprocessruca" xmlns:bat1="http://xml.netbeans.org/schema/batchprocessrutypes.xsd"> <soap:header/> <soap:body> <bat:batchprocessruoperation> <part1> <bat1:filter>pai</bat1:filter> </part1> </bat:batchprocessruoperation> </soap:body> </soap:envelope> Réponse : HTTP/1.1 200 OK Content-Type: application/soap+xml;charset="utf-8" Transfer-Encoding: chunked Date: Thu, 14 Jan 2010 13:48:19 GMT <?xml version="1.0"?> <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:body> <BatchProcessRUOperationResponse> <part1 xmlns:msgns="http://j2ee.netbeans.org/wsdl/batchprocessru/batchprocessru"> <ns0:message xmlns:ns0="http://xml.netbeans.org/schema/batchprocessrutypes.xsd"> success</ns0:message> <ns0:statecode xmlns:ns0="http://xml.netbeans.org/schema/batchprocessrutypes.xsd"> 0</ns0:statecode> <ns0:date xmlns:ns0="http://xml.netbeans.org/schema/batchprocessrutypes.xsd"> <ns0:start>2010-01-14t14:41:08.34+01:00</ns0:start> <ns0:end>2010-01-14t14:48:19.76+01:00</ns0:end> </ns0:date> </part1> </BatchProcessRUOperationResponse> </env:body> </env:envelope> ISET Djerba TriTux PAGE 95

3.7. Développement des applications Réseau local de l établissement (LAN) Réseau National Universitaire (WAN) Serveur FTP ftp-etu.intranet.demo Point d accès Sans Fil ap-21.intranet.demo Serveur CUPS cups.intranet.demo BD étudiants PostgreSQL postgres-83.intranet.demo Modem GSM connecté à un serveur Debian Lenny debian5-02.intranet.demo Serveur Web du site d inscription universitaire inscription.edu.demo Serveur Mail SMTP & POP3 rnu.edu.demo Serveurs d application, Ressources Systèmes hétérogènes Protocoles de communication Règles de communication SSH : 22 Telnet : 23 IPP : 631 Pgsql : 5432 SSH : 22 SSH : 80 SSH : 22 Connecteurs PodBridge Logique métier FTPAccount FTPAccount.connector.php APACLManager APACLManager.connector.php IPPService IPPService.connector.php BDbetu BDetu.connector.php SMSService SMSService.connector.php wwwsubscr wwwsubscr.connector.php MailAccount MailAccount.connector.php Middleware SOA PodBridge1.2 Intermédiation entre serveurs d application et consommateurs de services WSDL & Services Web SOAP SOAP endpoint, description, XML, XSD.. PodBridge 1.2 (Middleware SOA) podbridge.intranet.demo PodBridge 1.2 ws.rnu.edu.demo WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP WS SOAP Operation X Operation Operation Z Y Operation Operation X Operation X Operation Operation Z Operation Z Y Y Operation Operation X Operation X Operation Operation Z Operation Z Y Y Operation X Operation Operation Z Y Operation X Operation Operation Z Y invoke invoke invoke invoke BPEL Receive invoke invoke Reply invoke ProcessRUById GlassFish ESB 2.1 composant sun-bpel-engine bpel-engine.intranet.demo BPEL Receive Invoke Process Reply invoke BatchProcessRU Messages XML SOAP (Requête et réponse) WS SOAP WS SOAP ProcessRUById BatchProcessRU ping.java formulaire.php deleteftp.pl start-pru-09-10-att.sh Figure 35 - SI après urbanisation ISET Djerba TriTux PAGE 96

3.7.1. Appel web-service SOAP en PHP5 Exemple : 1 <?php 2 3 //init 4 $client = new SoapClient("http://podbridge.intranet.demo/projects/unstable/podbridge/web/index.php/wsdl/a uto/691292877050480f54b5/getstudentbyid"); 5 6 try { 7 8 //Arguements (paramètres d'entrées) 9 $arguments=array( 10 'key'=>'691292877050480f54b5', 11 'sync'=>'1', 12 'id'=>'12345678' 13 ) ; 14 15 //Apel de la méthode getstudentbyid 16 $result = $client->getstudentbyid($arguments); 17 18 //Affiche toute la réponse - Type: stdclass Object 19 print_r ($result); 20 //Affiche status - Type: stdclass Object 21 print_r ($result->status); 22 23 24 //Affiche le message renvoyé par podbridge (reponse) 25 echo $result->status->message."\n"; 26 //Affiche le prénom 27 echo $result->response->prenom."\n"; 28 //Affiche l'adresse email 29 echo $result->response->email."\n"; 30 31 } 32 catch (SoapFault $e) { 33 echo '['.$e->getcode().']'; 34 echo $e->getmessage(); 35 } 36 37?> Voir source et capture d écran de l application web PHP (formulaire info etudiant) dans la documentation technique. ISET Djerba TriTux PAGE 97

3.7.2. Exemple d appel web-service SOAP en Perl (Suppression d un compte FTP) #!/usr/bin/perl -w # # Ce code permet d appeler le service web (dodeleteftpuseraccount) exposé par podbridge # use SOAP::Lite; my $soap = SOAP::Lite -> uri ('urn:ftpacntns') -> proxy ('http://podbridge.intranet.demo/projects/unstable/podbridge/web/api/index.php?wsdl'); my $res = $soap ->dodeleteftpuseraccount(soap::data->name('key' => '691292877050480f54b5'),SOAP::Data->name('user' => 'etu_12345678')); unless ($res->fault) { print $res->result(),"\n"; }else{ print 'FAULT CODE : ',$res->faultcode,"\n",'fault MESSAGE : ',$res->faultstring,"\n"; } 3.7.3. Appel web-service SOAP en JAVA SE Swing (Invocation du service Ping (test PodBridge)) 66 67 68 pbns.podbridgepingservice service = new pbns.podbridgepingservice(); 69 70 QName portqname = new QName("urn:pbns", "PodBridgePingPort"); 71 String req = "<ping xmlns=\"urn:pbns\"><key>691292877050480f54b5</key><sync>1</sync></ping>"; 72 73 try { // Call Web Service Operation 74 Dispatch<Source> sourcedispatch = null; 75 sourcedispatch = service.createdispatch(portqname, Source.class, Service.Mode.PAYLOAD); 76 Source result = sourcedispatch.invoke(new StreamSource(new StringReader(req))); 77 String resultstring = sourcetoxmlstring(result); 78 System.out.println("Received xml: \n" + resultstring); 79 } catch (Exception ex) { 80 System.out.println("An error has occured: \n" + ex.getmessage()); ISET Djerba TriTux PAGE 98

81 } 82 83 84 3.7.4. Appel web-service SOAP en Shell (Invocation du service composite BatchProcessRU) Fichier (soap-request.xml) : <soap:envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:bat="batchprocessruca" xmlns:bat1="http://xml.netbeans.org/schema/batchprocessrutypes.xsd"> <soap:header/> <soap:body> <bat:batchprocessruoperation> <part1> <bat1:filter>att</bat1:filter> </part1> </bat:batchprocessruoperation> </soap:body> </soap:envelope> Fichier script Shell (start-pru-09-10-att.sh) : #!/bin/bash curl http://sun-bpelengine.intranet.demo/projects/unstable/podbridge/web/api/index_dev.php -d @soap-request.xml 3.8. Environnement de travail 3.8.1. Matériel utilisé Ordinateur portable (Toshiba A210-16C) : - Microprocesseur : 2x1.8 GHz, AMD Athlon X2 - Architecture 64 bits, - Mémoire vivre : 3 Go DDR2, - Disque dur : 12O Go SATA, - Contrôleur graphique : ATI X1200 ~320 Mo, ISET Djerba TriTux PAGE 99

- Carte réseau : Ethernet LAN 10/100Mbps (interface RJ45). Imprimante Laser (Lexmark E120) 3.8.2. Logiciels utilisés : SquirrelMail 1.4.15 (Client mail sur navigateur web) : Site web officiel : http://squirrelmail.org SquirrelMail est un webmail écrit en PHP4. Il supporte les protocoles POP, IMAP et SMTP, et toutes les pages générées le sont en pur HTML (sans aucun JavaScript),ceci afin d'être compatible avec le maximum de navigateurs. Dovecot 1.1.11 (Serveur POP3/IMAP) : Site web officiel : http://squirrelmail.org Postfix (Serveur SMTP) : Site web officiel : http://squirrelmail.org Apache 2.2.11 (Serveur HTTP) : Site web officiel : http://www.apache.org licence Apache. Apache HTTP Server, est un logiciel de serveur HTTP produit par l'apache Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécifique de licence, nommée PostgreSQL 8.3 (Serveur & Client) : Site web officiel : http://www.postgresql.org PostgreSQL est un système de gestion de base de données relationnelle et objet(sgbdro). C'est un outil libre disponible selon les termes d'une licence de type BSD. PostgreSQL n'est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et d'entreprises. ISET Djerba TriTux PAGE 100

proftpd 1.3.1 (Serveur FTP) : Site web officiel : http://www.proftpd.org ProFTPd est un serveur FTP libre. Il est puissant et parfaitement sécurisé. Il est distribué selon les termes de la licence GNU GPL. Son architecture est modulaire, ce qui a permis d'écrire des extensions pour le support de la cryptographie SSL/TLS (protocole FTPS) et l'extension de l'authentification via des bases RADIUS, LDAP ou SQL. OpenSSH (Serveur SSH) : Site web officiel : http://www.openssh.com OpenSSH (OpenBSD Secure Shell) est un ensemble d'outils informatiques libres permettant des communications sécurisées sur un réseau informatique en utilisant le protocole SSH. Créé comme alternative Open Source à la suite logicielle proposée par la société SSH Communications Security, OpenSSH est développé par l'équipe d'openbsd, dirigée par son fondateur. CUPS (Serveur.) : Site web officiel : http://www.cups.org CUPS est l acronyme de (Common Unix Printing System) est un système modulaire d'impression informatique pour les systèmes d'exploitation Unix et assimilés. Tout ordinateur qui utilise CUPS peut se comporter comme un serveur d'impression ; il peut accepter des documents envoyés par d'autres machines (ordinateurs clients), les traiter, et les envoyer à l'imprimante qui convient. Ubuntu 9.04 (Jaunty Jackalope) : Site web officiel : http://www.ubuntu.com serveur. Ubuntu est une distribution Linux libre fondé sur Debian (basé sur GNU/Linux) et commandité par la société Canonical. Ubuntu Server est une version pour ISET Djerba TriTux PAGE 101

SoapUI 3.0.1 : Site web officiel : http://www.soapui.org SoapUI est outils de test de services web pour l architecture SOA écris en java et distribué sous licence LGPL, il offre une multitude de fonctionnalité sue les services web tel que les inspecter, les invoquer, simuler... Netbeans IDE 6.8 : Site web officiel : http://www.netbeans.org NetBeans est un environnement de développement intégré (IDE) pour Java, placé en open source par Sun sous licence CDDL et GPLv2. En plus de Java, NetBeans permet également de supporter différents autres langages, comme Python, C, C++, XML, Ruby, PHP et HTML. Il comprend toutes les caractéristiques d'un IDE moderne (éditeur en couleur, projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages web). Conçu en Java, NetBeans est disponible sous Windows, Linux, Solaris (sur x86 et SPARC), Mac OS X et Open VMS. PHP 5.2.6 : Site web officiel : http://www.php.net PHP (sigle de PHP: Hypertext Preprocessor), est un langage de scripts libre principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les programmes en ligne de commande. PHP est un langage impératif disposant depuis la version 5 de fonctionnalités de modèle objet complètes. En raison de la richesse de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu'un simple langage. Symfony 1.0.22-PRE (Framework) : Site web officiel : http://symfony-project.org Symfony est un Framework MVC «Modèle-Vue-Contrôleur» libre entièrement écrit en PHP 5. En tant qu un Framework, il facilite et accélère le développement des sites et d'applications Internet et Intranet. ISET Djerba TriTux PAGE 102

Symfony intègre Proprel qui est lui aussi un Framework de mapping objet relationnel «ORM» offrant une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. On pourrait le désigner par «correspondance entre monde objet et monde relationnel». Les fichiers de configuration employés par Symfony sont au format YAML qui est un langage de sérialisation de données comme XML mais plus humain et facile interpréter. GlassFish ESB 2.1 : Site web officiel : http://glassfish.java.net PodBridge 1.2 : Site web officiel : http://www.tritux.com PodBridge est un middleware qui favorise une évolutivité des systèmes, applications et données, qui permet d'étendre, d'augmenter ou de réallouer les ressources conformément aux contraintes et à la croissance du marché par plusieurs fonctions : Mettre en place un écosystème composé d'applications hétérogènes, assurant la sécurité d échange d'informations et l enregistrement complet d un suivi/traçabilité des flux de données et de gestion de processus, pour renforcer la connaissance des mouvements d'entrée/sortie. Développer des connecteurs centralisés ou distribués permettant d'interfacer des applications utilisant des protocoles de communication différents. En effet, un seul connecteur suffit pour communiquer plusieurs informations. ISET Djerba TriTux PAGE 103

Figure 36 - Architecture de PodBridge 1.2 ISET Djerba TriTux PAGE 104