soa & bpm - walid.tn · les services web ... composite on découvre toujours des pro lèmes d...
TRANSCRIPT
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
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
Institut Supérieur des Études
Technologiques de Djerba
Département Technologie de l’Informatique
République Tunisienne
Ministère de l’Enseignement Supérieur,
de la Recherche Scientifique et Technologie
Direction Générale des Études Technologiques
Effectué à :
ISET Djerba | TriTux PAGE 1
ISET Djerba | TriTux PAGE 2
Dédicaces
A toute ma famille,
à mes enseignants,
à mes amis,
et à mes camarades
je dédie ce travail.
ISET Djerba | TriTux PAGE 3
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 4
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. Chapitre 3 : Etude conceptuelle ......................................................................................... 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 1er 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 5
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 6
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 7
‘ 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: [email protected]
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 8
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, SARL1 est une SSII2 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 9
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 LDAP3,
- Messageries mail,
- Messageries courtes (SMS4) et Multimédia (MMS5),
- Systèmes GNU6 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 10
- 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.….
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 11
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 7permet 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 12
- 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 SOA8 et le BPM9 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 1 : Introduction
ISET Djerba | TriTux PAGE 13
2) La deuxième phase consiste à la conception des processus métier à travers un
workflow / orchestration10 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) »
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 14
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.
Fournisseur / Prestataire
de service
Demandeur / Consommateur
de service
Demande
RéponseMessage
Message
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-I11.
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-*
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 15
La figure de ci-dessous décrit l’architecture SOA d’une façon globale:
Service X
Service Z
Service Y
Service W
Service U
Architecture SOA
Service composite
Demandeur 1
Demandeur 2
Orchestration
Service V
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 ci-
dessous.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 16
Application
WebTerminal
Appareil
Mobile
OrchestrationWORKFLOW
BPEL, BPM
PrésentationConsommateur
Application
ServicesServices
Services web
Composants,
MéthodesMéthodes de classes
bibliothèques,drivers...
Systèmes &
RessourcesServeurs,
Bases de données..
DBDBI0II0I0I0I0
II0III00I0I
0I0III0I0I0
I0I0I0
I0II0I0I0I0
II0III00I0I
0I0III0I0I0
I0I0I0
Func () {
----
---
}
Func () {
----
---
}
Func () {
----
---
}
Func () {
----
---
}
5
4
3
2
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 17
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
HTTP12/HTTPS 13et SMTP14.
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 18
<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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 19
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).
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 20
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 21
- 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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 22
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 23
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,
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 24
- 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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 25
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-BPEL18 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)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 26
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 27
Service partenaire (Internet
Banking Service)
Services partenaire (Google Maps
API)
Service partenaire (GSM Tracking) L'appareil Mobile
Quelles sont les espaces
qui m’entourent ?
Quelle est ma géoposition
(longitude & latitude)
Quel est mon solde ?
[Solde >= 10 Dinars]
[Nombre > 0]
Indiquer les salons de thé
sur la carte.
Afficher message
« Ce n’est pas le moment
pour aller au salon de thé !!! »
[Solde < 10 Dinars]
Afficher message « Désolé !
Aucun salon de thé trouvé
dans votre position. »
[Nombre = 0]
Entrée:
- Cherche (string) = "Salon de thé"
- Rayon en KM (real)
- Longitude (string)
- Lattitude (string)
Sortie:
- Nombre (integer)
- Liste des salons de thé (string XML)
Enrée:
- numéro de compte (number)
- code (string)
Sortie:
- Solde (real)
Entrée:
- SN (Subscriber Number) (number)
Sortie:
- Logitude (string)
- Lattitude (string)
Quel est son numéro de tel
et le numéro de sa carte de crédit ?
Saisir le rayon (zone de recherche
- Valeur en km)
Entrée: (Aucun)
Sortie:
- SN (Subscriber number) (number)
- numéro de compte (number)
{Donnée:
Rayon (real)
min=0.1
max=10.0}
HTTPS (SSL)
Saisir code confidentiel
Figure 10 – Exemple d’un processus faisant appel à 4 services
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 28
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 29
Process
flow
template
GeneratesBPEL
Designer
Executes BPEL
Engine
Design Time Run Time
Business Expert End User / Application
Figure 1120
– 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 30
<import namespace="urn:tns" location="services_rnu.wsdl" importType="http://schemas.xmlsoap.org/wsdl/"/>
- La balise <partenerLinks> :
Permet de lier des actions définies dans le fichier WSDL (via partnerLinkType) au process
BPEL.
<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"/>
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 31
- 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>
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 32
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
XSLT21, exécution en parallèle, validation, exceptions …).
21
eXtensible Stylesheet Language Transformation
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 2 : Etat de l’art
ISET Djerba | TriTux PAGE 33
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)…
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 34
3. Chapitre 3 : Etude conceptuelle
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 35
- 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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 36
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 37
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 »
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 38
Description des attributs :
Champ Description
id Identifiant de l’étudiant
nom Nom de l’étudiant.
prenom Prénom de l’étudiant.
dep Code de département
spec Code de spécialité
niveau Niveau
Tel Numéro de téléphone personnel (GSM).
email Adresse email.
loginftp Login du compte FTP sur le réseau de l’institut.
adrmac Adresse MAC de l’interface réseau sans fil de l’ordinateur portable de
l’étudiant.
refrecu Référence de l’accusé de payement.
process 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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 39
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
+getStudentById() : array
+updateStudentById() : boolean
+getNextId() : array
-executeSQL() : array
+connect() : boolean
+disconnect() : boolean
-conn : ressource = null
BDetu
Figure 14 - Classe BDetu (Connecteur PodBridge de l’établissement)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 40
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
Serv
ice
getStudientById
Renvoi les informations sur un étudiant depuis la base de données.
id : Identifiant. String
Informations sur l’étudiant (id,nom, prénom,
dep,spec,niveau,tel,email,loginftp,adr
mac,refrecu,process). Array
Serv
ice
updateStudentById
Met à jour une ou plusieurs informations sur un étudiant tel que, son email,
tel, login ftp…
id :Identifiant. String
Vrai si succès de la mis à jour. boolean
Tel String
adrmac String
ftp String
refrecu String
process String
Serv
ice
getNextId
Renvoi l’identifiant de l’étudiant suivant.
id : Identifiant. (Optionnel) -’Si elle prend null c’est pour récupérer le premier identifiant’ String
Identifiant. String
Code état du process (Filtre)
executeSQL
Envoi la requête SQL au SGBD et revoie le résultat.
sql : Requête SQL 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 41
PostgreSQL (initialise la ressource conn)
connexion. boolean
disconnect Se déconnecter du serveur PostgreSQL et libère la
ressource conn.
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 42
postgresql (5432)PodBridge 1.2 SOA Middleware
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
« Bdetu.connector.php »
End system
PostgreSQL DBMS
SQL Execute :
SELECT
.. FROM .. WHERE ..
Invoke WS :
getSudentByID
Authenticate and
check privilege
Handle request
<< Include >>
Invoke WS :
updateStudentById
Call method :
updateStudentById()
Call method :
getStudentById()
Call method :
executeSQL()
Service
Consumer
<< Include >>
<< Include >>
Get response from
cache
<< Include >>
SQL Execute :
UPDATE
.. SET .. WHERE ..
Tell PostgreSQL Server
to perform the
operation
<< Include >>
if cached
Trace requests and
responses
<< Include >>
Invoke WS :
getNextId
Call method :
getNextId()
<< Include >>
Frontend
Get WSDL
Setup PB1.2
Monitor
transactions log
PodBridge
admin
DBA
Figure 15 – Modélisation de la logique métier (Connecteur BDetu)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 43
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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 44
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
-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
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
FTPAccount
Figure 16 - Classe FTPAccount (Connecteur PodBridge de l’établissement)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 45
Description des attributs de la classe FTPAccount :
Nom de l’attribut Description Valeur initiale
sshCon Ressource sshclient null
authenticated Pour identifier si la connexion au serveur SSH est établit et en cours.
False
regexValidator Renferme différentes expressions régulières.
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
Génère un mot de passe aléatoire.
len : Longueur du mot de passe (optionnel)
5 par défaut
Integer
Mot de passe. String
ifUserExists
Vérifie si un utilisateur existe déjà sur le système.
user : Nom d’utilisateur String
Vrai si l’utilisateur est déjà existant. boolean
getUnixDate
Converti une date au
format JJ/MM/AAAA en une date au format
MM/JJ/AAAA.
date : Une date
(JJ/MM/AAAA) String
Une date
(MM/JJ/AAAA) String
SER
VIC
E
doCreateFTPUserAccount
Créer un nouveau compte d’utilisateur FTP.
user : Nom d’utilisateur
String
(login, mot de passe, nom de
domaine et n° port ftp) Array
expiry_date : Date
d’expiration boolean
use_welcome : Utiliser le message de bienvenu par défaut (Vrai par
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 46
défaut) boolean
SER
VIC
E
setFTPUserAccountExpiryDate
Modifie la date d’expiration d’un compte utilisateur FTP.
user : Nom d’utilisateur String
Vrai si la date d’expiration du compte à été modifiée avec succès. boolean
expiry_date : Date d’expiration
String
SER
VIC
E
setFTPUserWelcomeMs
g
Modifie le fichier « welcome.msg » qui existe dans la racine du compte utilisateur FTP.
user : Nom d’utilisateur. String
Vrai si le contenu du fichier « welcome.msg à été modifier. boolean
message : Message de
bienvenu. String
SER
VIC
E
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
SER
VIC
E
doChangeFTPUserPassword
Modifie le mot de passe d’un compte utilisateur FTP.
user : Nom d’utilisateur. String
Vrai si le mot de passe a été changé avec
succès. boolean password : Ancien mot de
passe. String
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
Vrai si la vérification est
positive et faux dans le cas
contraire. boolean
password : Mot de passe String
SER
VIC
E
doDeleteFTPUserAccount
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 47
SER
VIC
E
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
Le résultat d’exécution de 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
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 48
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 49
Figure 17 - Modélisation de la logique métier (Connecteur FTPAccount)
S S H (2 2 )
F T P (2 1 )
P o d B r id g e 1 .2 S O A M id d le w a r e
H T T P (8 0 )
P B 1 .2 C o r e
S O A P w e b s e r v ic e A P I
P B 1 .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 .p h p »
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
S h e ll e x e c u te :
u s e ra d d … -g F T P . . .
A u th e n t ic a te a n d
c h e c k p r iv i le g e
H a n d le re q u e s t
< < 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 ( )
C a ll m e th o d :
d o C re a te F T P
U s e rA c c o u n t ( )
C a ll m e th o d :
s s h 2 E x e c ( )
S e rv ic e
C o n s u m e r
< < In c lu d e > >
< < In c lu d e > >
G e t re s p o n s e f ro m
c a c h e
< < In c lu d e > >
S h e ll E x e c u te : c p …T e ll S S H S e rv e r to
p e r fo rm th e o p e ra t io n
< < In c lu d e > >
if c a c h e d
T ra c e re q u e s ts a n d
re s p o n s e s
< < In c lu d e > >
F T P S e rv e r
a d m in
C a ll m e th o d :
s e tF T P U s e rA c c o u n t
E x p ir y D a te ( )
< < In c lu d e > >
F r o n t e n d
G e t W S D LP B a d m in
S e tu p P B 1 .2
M o n ito r
t ra n s a c t io n s lo g
In v o k e W S :
d o C re a te F T P
U s e rA c c o u n t
In v o k e W S :
s e tF T P U s e rW e lc o m e M s g
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 :
d o F T P s e n d F ile
C a ll m e th o d :
d o F T P s e n d F ile ( )
< < In c lu d e > >
C a ll m e th o d :
g e tU n ix D a te ( )
< < In c lu d e > >
C a ll m e th o d :
g e n e ra te
R a n d o m P a s s w d ( )
< < In c lu d e > >
C a ll m e th o d :
i fU s e rE x is ts ( )
< < In c lu d e > >
S h e ll e x e c u te :
u s e rm o d -e . . . .
< < In c lu d e > >
S h e ll E x e c u te :
c h o w n . . .
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 50
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 :
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
+doForwardMACaddr() : array
+doRomoveForwordedMACaddr() : boolean
+getAccesPointInfo() : array
+connect() : boolean
+disconnect() : boolean
-regexValidator : array
APACLManager
Figure 18 – Classe APACLManager (Connecteur PodBridge de l’établissement)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 51
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
SER
VIC
ES
doForwardMACaddr
Ajoute une adresse MAC
dans l’ACL du point d’accès sans fil. (Autorise l’accès au réseau)
macaddr :
Adresse MAC. String
Vrai si adresse à
été ajoutée à la liste de contrôle du point d’accès. boolean
doRomoveForwordedM
ACaddr
Supprime une adresse
MAC depuis l’ACL du point d’accès sans fil. (Interdit
l’accès au réseau)
macaddr :
Adresse MAC. String
Vrai si adresse à
été supprimer de la liste de
contrôle du point d’accès. boolean
getAccesPointInfo
Renvoi des informations sur le point d’accès (l’SSID et la clé d’authentification).
(clé d’authentification, SSID). Array
connect
Se connecter au serveur
TELNET.
Vrai en cas de
succès de la connexion.
boolean
disconnect
Se déconnecter du serveur TELNET.
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 52
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 53
TELNET (23)PodBridge 1.2 SOA Middleware
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
« APACLManager.connector.php »
End system
Wireless Access Point
Add mac address to
ACL
Invoke WS :
doRomoveForworded
MACaddr
Authenticate and
check privilege
Handle request
<< Include >>
Invoke WS :
doForwardMACaddr
Call method :
getAccesPointInfo()
Call method :
doForwardMACaddr()
Call method :
SocketSend()
Service
Consumer
<< Include >>
Get response from
cache
<< Include >>
Remove mac address
from ACLTell Telnet Server to
perform the operation
<< Include >>
if cached
Trace requests and
responses
<< Include >>
Invoke WS :
getAccesPointInfo
Call method :
doRomoveForworded
MACaddr()
<< Include >>
Frontend
Get WSDL
Setup PB1.2
Monitor
transactions log
PodBridge
admin
Network
admin
Figure 19 - Modélisation de la logique métier (Connecteur APACLManager)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 54
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 :
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
+doPrintWebPage() : boolean
-doPrintInternalDocument() : boolean
+connect() : boolean
+disconnect() : boolean
-ipp : CupsPrintIPP Object = null
IPPService
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 55
Description des méthodes de la classe IPPService :
Nom de la méthode Description Entrée Sortie
SER
VIC
ES doPrintWebPage
Envoyer un ordre
d’impression d’une page web à une imprimante
partagée.
url : URL de la
page web. String
Vrai si l’ordre
d’impression à été envoyé.
boolean jobname : Nom du job
d’impression (optionnel)
String
getPrinters
Renvoie les adresses (URI)
des imprimantes partagées par CUPS
Des URI
délimités par des points virgules. String
doPrintInternalDocument
Envoyer un ordre d’impression à une
imprimante partagée d’un document présent sur le serveur.
filepath : Chemin d’accès à un
document présent sur le serveur. String
Vrai si l’ordre d’impression à
été envoyé. boolean
jobname : Nom du job d’impression (optionnel) String
connect
Se connecter au serveur CUPS.
Vrai en cas de succès de la
connexion. boolean
disconnect
Se déconnecter du serveur CUPS.
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 56
cups (631)PodBridge 1.2 SOA Middleware
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
« IPPService.connector.php »End system
CUPS Server
Scan for available
printers
Invoke WS :
doPrintWebPage
Authenticate and
check privilege
Handle request
<< Include >>
Invoke WS :
doPrintInternalDocument
Call method :
getPrinters()
Call method :
doPrintWebPage()
Service
Consumer
<< Include >>
<< Include >>
Get response from
cache
<< Include >>
start print job
Tell CUPS Server to
perform the operation
if cached
Trace requests and
responses
<< Include >>
Invoke WS :
getPrinters
Call method :
doPrintInternalDocument()
<< Include >>
Frontend
Get WSDL
Setup PB1.2
Monitor
transactions log
PodBridge
admin
Network
admin
<< Include >>
Figure 21 - Modélisation de la logique métier (Connecteur IPPService)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 57
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 :
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
-getAccuseRef() : string
+getAccuse() : array
+ssh2Exec() : stream
+connect() : boolean
+disconnect() : boolean
-curl_handle : ressource = null
wwwsubscr
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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 58
Nom de la méthode Description Entrée Sortie
getAccuseRef
Renvoi la référence de l’accusé de paiement pour une année universitaire donnée. (si paiement effectué)
studentident : Identifiant de l’étudiant. String
Référence de l’accusé de paiement. String
au : Année universitaire
(AAAA/AAAA). String
SER
VIC
E
getAccuse
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é.
studentident :
Identifiant de l’étudiant. String
Référence et url
de l’accusé de paiement. Array
au : Année
universitaire (AAAA/AAAA).
String
connect
Initialisation de la
ressource
Vrai si la
ressource à été initialisée.
boolean
disconnect Ressource libérée 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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 59
HTTP (80)PodBridge 1.2 SOA Middleware
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
« wwwsubscr.connector.php »End System
HTTP Server
(inscription.edu.demo
)
Get page of
requested URL
Invoke WS :
getAccuse
Authenticate and
check privilege
Handle request
<< Include >>
Call method :
getAccuseRef()
Service
Consumer
<< Include >>
Get response from
cache
<< Include >>
Authenticate
Tell WEB Server
To
perform the operation
if cached
Trace requests and
responses
<< Include >>
Call method :
getAccuse()
<< Include >>
Frontend
Get WSDL
Setup PB1.2
Monitor
transactions log
PodBridge
admin
Web user
<< Include >>
Figure 23 - Modélisation de la logique métier (Connecteur wwwsubscr)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 60
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 :
+doSendSMS() : boolean
-stripSpaces() : boolean
-ssh2Exec() : stream
+connect() : boolean
+disconnect() : boolean
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
SMSService
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 61
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
SER
VIC
E
doSendSMS
Envoyer un SMS. destinataire :
numéro de téléphone du
destinataire.
String
Vrai si l’SMS a
été envoyé au destinataire
boolean
message :
Message texte court à envoyer
String
stripSpaces
Supprimer des espaces qui existent dans le numéro de téléphone et valider son format.
phonenumber : Numéro de téléphone String
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
Le résultat d’exécution de 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
readResponse : si elle prend vrai, on récupère le résultat retourné par la commande (Faux par défaut)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 62
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
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 63
SSH (22)
PodBridge 1.2 SOA Middleware ( podbridge-12.intranet.demo)
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
«SMSService.connector.php »
End System
Server
Send SMS
command
Invoke WS :
doSendSMS
Authenticate and
check privilege
Handle request
<< Include >>
Call method :
stripSpaces()
Service
Consumer
Get response from
cache
<< Include >>
Tell SSH Server to
perform the operation
if cached
Trace requests and
responses
<< Include >>
Call method :
doSendSMS()
<< Include >>
Frontend
Get WSDL
Setup PB1.2
Monitor
transactions log
PodBridge
admin
Server
Admin
<< Include >>
Figure 25 - Modélisation de la logique métier (Connecteur SMSService)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 64
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 auto-gé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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 65
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
-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
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
MailAccount
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
Pour identifier si la
connexion au serveur SSH est établit et en cours.
False
regexValidator Renferme différentes
expressions régulières.
Expression régulière pour
un nom d’utilisateur (mail), prénom et adresse email.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 66
Description des méthodes de la classe MailAccount :
Nom de la méthode Description Entrée Sortie
generateRandomPasswd
Génère un mot de passe aléatoire.
len : Longueur du mot de passe (optionnel) Integer
Mot de passe. String
ifUserExists
Vérifie si un utilisateur existe déjà sur le système.
user : Nom d’utilisateur String
Vrai si l’utilisateur est déjà existant. boolean
generateUserName
Génère un nom d’utilisateur à partir du
nom et prénom passés en paramètres.
fstname : prénom. String
Nom d’utilisateur.
String lstname : nom.
String
doStripAtDomain
Extrait le nom
d’utilisateur à partir d’une adresse email du domaine (rnu.edu.demo).
emailaddr :
adresse email. String
Nom
d’utilisateur.
String
SER
VIC
E
doCreateMailUserAcco
unt
Créer un nouveau
compte mail (1)
user : Nom
d’utilisateur String
(adresse email,
mot de passe, port POP3, port
SMTP, adresse url du webmail
‘SquirrelMail’) Array
genpswd: vrai
pour auto générer le mot
de passe. boolean
password: mot
de passe (si genpswd reçoit
faux). String
SER
VIC
E
doCreateMailUserAccount2
Créer un nouveau compte mail (2)
fstname : prénom. String
(adresse email, mot de passe, port POP3, port
SMTP, adresse url du webmail ‘SquirrelMail’)
lstname : nom. String
genpswd: vrai
pour auto
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 67
générer le mot de passe.
boolean
Array
password: mot
de passe (si genpswd reçoit
faux). String
SER
VIC
E
doDeleteMailUserAccount
Supprime un compte
mail.
emailaddr :
adresse mail. String
Vrai si le compte
mail a été supprimé avec
succès. boolean
SER
VIC
E
doUnlockMailUserAccount
Active un compte mail. emailaddr : adresse mail.
String
Vrai si le compte mail a été activé.
boolean
SER
VIC
E
doLockMailUserAccoun
t
Désactive un compte
mail.
emailaddr :
adresse mail.
String
Vrai si le compte
mail a été
désactivé. boolean
SER
VIC
E
doChangeMailUserPassword
Modifie le mot de passe d’un compte
mail.
emailaddr: adresse email.
String
Vrai si le mot de passe a été
changé avec succès. boolean
password : Ancien mot de
passe. String
new_password Nouveau mot de
passe. String
SER
VIC
E
doSendMail
Permet (à un administrateur) l’envoi de messages à n’importe quelle adresse électronique.
from: adresse email de l’envoyeur.
String
Vrai si le message à été envoyé avec succès. boolean
to : adresse email du destinataire.
String
message : Corps du message
String
subject : Sujet du
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 68
message
String
doCheckPassword
Vérifie si le mot de passe passé en
paramètre est correct.
user : Nom d’utilisateur.
String
Vrai si la vérification est
positive et faux dans le cas
contraire. boolean
password : Mot de passe String
ssh2Exec
Demande au serveur
SSH d’exécuter une commande Shell.
cmd : La
commande. String
Le résultat
d’exécution de 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
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 69
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 70
SSH (22)
POP (110)
SMTP (25)
HTTP (80)
PodBridge 1.2 SOA Middleware
HTTP (80)
PB1.2 Core
SOAP web service API
PB1.2 Connector
« MailAccount.connector.php »
End system
OpenSSH and Postfix
and Dovecot on
Ubuntu server
Shell execute :
useradd … -g mail ...
Authenticate and
check privilege
Handle request
<< Include >>
Call method :
doSendMail()
Call method :
doCreateMail
UserAccount2()
Call method :
ssh2Exec()
Service
Consumer
<< Include >>
<< Include >>
Get response from
cache
<< Include >>Shell Execute :
mail -s…Tell SSH Server to
perform the operation
<< Include >>
if cached
Trace requests and
responses
<< Include >>
Mail Server
admin
Call method :
doChangeMail
UserPassword()
<< Include >>
Frontend
Get WSDLPB admin
Setup PB1.2
Monitor
transactions log
Invoke WS :
doCreateMail
UserAccount2
Invoke WS :
doDeleteMail
UserAccount
Invoke WS :
doChangeMail
UserPassword
Invoke WS :
doSendMail
Call method :
doDeleteMail
UserAccount()
<< Include >>
Call method :
doCheckPassword()
<< Include >>
Call method :
generate
generateUserName()
<< Include >>
Call method :
ifUserExists()
<< Include >>
Shell execute :
userdel -r ....
<< Include >>
Shell Execute :
usermod -p...
Figure 27 - Modélisation de la logique métier (Connecteur MailAccount)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 71
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 72
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
+getStudentById() : array
+updateStudentById() : boolean
+getNextId() : array
-executeSQL() : array
+connect() : boolean
+disconnect() : boolean
-conn : ressource = null
BDetu
+doForwardMACaddr() : array
+doRomoveForwordedMACaddr() : boolean
+getAccesPointInfo() : array
+connect() : boolean
+disconnect() : boolean
-regexValidator : array
APACLManager
-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
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
FTPAccount
+doPrintWebPage() : boolean
-doPrintInternalDocument() : boolean
+connect() : boolean
+disconnect() : boolean
-ipp : CupsPrintIPP Object = null
IPPService
-getAccuseRef() : string
+getAccuse() : array
+ssh2Exec() : stream
+connect() : boolean
+disconnect() : boolean
-curl_handle : ressource = null
wwwsubscr
+doSendSMS() : boolean
-stripSpaces() : boolean
-ssh2Exec() : stream
+connect() : boolean
+disconnect() : boolean
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
SMSService
Figure 28 – Connecteurs PodBridge (de l’établissement)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 73
+connect() : boolean
+disconnect() : boolean
«interface»
PodBridgeConnectorInterface
+getLastErrorMsg() : string
+setLastError()
+setParam()
+getSessionLog()
+setSessionLog() : array
+getSessionLogCounter() : integer
#params : array
#error : array
#sessionLog : array
#sessionLogCounter : integer = 0
PodBridgeConnector
-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
-sshCon : ressource = null
-authenticated : boolean = false
-regexValidator : array
MailAccount
Figure 29 - Connecteur PodBridge (du RNU)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 74
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 1er 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 75
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).
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 76
Donner l’identifiant de l'étudiant
RECEIVE: ProcessRUByIdIn
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é]
Lancer un nouveau job d’impression
pour l’accusé de paiement
INVOKE: « doPrintWebPage »Mettre à jour la BD,
état process PAI
INVOKE: « updateStudentById »
[Paiement non effectué]
Son département
est-il ‘TI’ ?
A-t-il donné son
adresse MAC ?
Possède-il un compte FTP ?
[oui]
[non] [oui]
Crée un message welcome
pour ce compte FTP
INVOKE: « setFTPUserWelcomeMsg »
Envoyer le calendrier
,les cours & TP
INVOKE: « doFTPsendFile »
Envoyer le cour d’UML2
INVOKE: « doFTPsendFile »
Est-il niveau 2 ou plus ?
[oui] [non]
Mettre à jour le filtre MAC du
point d’accès Sans fil (Ajout)
INVOKE: «doForwardMACaddr »
[oui]
[non]
Possède-il un
compte e-mail ?
Créer un nouveau compte e-mail
INVOKE:
«doCreateMailUserAccount »
[non]
[oui]
Mettre à jour la BD
(login FTP, e-mail,refrecu et état process ‘OK’)
INVOKE: « updateStudentById »
Renvoyer OK
REPLY: ProcessRUByIdOut
[non]
Renvoyer PAI
REPLY: ProcessRUByIdOut
Envoyer les paramètres du nouveau
compte mail par SMS
INVOKE: « doSendSMS »
Envoyer les paramètres du
point d’accès par SMS
INVOKE: « doSendSMS »
Envoyer les paramètres du
point d’accès par mail
INVOKE: « doSendMail »Envoyer les paramètres du
nouveau compte FTP par SMS
INVOKE: « doSendSMS »
Envoyer les paramètres du
nouveau compte FTP par mail
INVOKE: « doSendMail »
Etendre le délai d’expiration
INVOKE:
«setFTPUserAccountExpiryDate »
Créer un compte FTP
INVOKE: « doCreateFTPUserAccount »
Envoyer un SMS de bienvenue
INVOKE: « doSendSMS »
Envoyer un mail de bienvenue
INVOKE: « doSendMail »
Mettre à jour la BD,
état process EXE
INVOKE: « updateStudentById »
Appel service web
Figure 30 - diagramme d'activité « ProcessRUById »
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 77
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 : ATT22, 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).
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 78
Donner le filtre (soit ‘PAI’, ‘ATT’ ou ‘ * ‘)
RECEIVE: BatchProcessRUIn
Renvoyer (Etat process,
date de début et de fin d’exécution)
REPLY: BatchProcessRUOut
Récupérer l’indentifiant
Suivant
INVOKE: « getNextId »
Dernier identifiant ?
[oui]
[non]
Invoquer le service (ProcessRUById)
pour l’identifiant courant
INVOKE: « ProcessRUById »
renvoie le premier identifiant
à la première itération
Notifier l’administrateur
par SMS
INVOKE: « doSendSMS »
Notifier l’administrateur
par Mail
INVOKE: « doSendMail »
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 79
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) :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 80
$ 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/sites-
enabled/inscription.edu.demo :
<VirtualHost *:80>
ServerName inscription.edu.demo
DocumentRoot "/var/www/projects/unstable/inscription.edu.demo"
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 81
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 :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 82
$ 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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 83
$ ./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 yml23, 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)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 84
Figure 32 - Arborescence du projet PodBridge - Netbeans IDE
Ajout du connecteur pbFTPAccountConnector à PodBridge (Génération des services web, et
WSDL) :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 85
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:
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 86
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):
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 87
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 88
Réseau National Universitaire (WAN)
IPP : 631 SSH : 22SSH : 22 Telnet : 23 Pgsql : 5432
BD
étu
dia
nts
Po
stg
reS
QL
po
stg
res-8
3.in
tra
ne
t.d
em
o
Réseau local de l’établissement (LAN)
AP
AC
LM
an
ag
er
AP
AC
LM
an
ag
er.
co
nn
ec
tor.
ph
p
IPP
Se
rvic
e
IPP
Se
rvic
e.c
on
ne
cto
r.p
hp
BD
be
tu
BD
etu
.co
nn
ec
tor.
ph
p
SM
SS
erv
ice
SM
SS
erv
ice.c
on
ne
cto
r.p
hp
FT
PA
cc
ou
nt
FT
PA
cc
ou
nt.
co
nn
ec
tor.
ph
p
Po
int
d’a
cc
ès
Sa
ns
Fil
ap
-21
.in
tra
ne
t.d
em
o
Serveurs d’application,
Ressources
Systèmes hétérogènes
SSH : 22
Ma
ilA
cc
ou
nt
Ma
ilA
cc
ou
nt.
co
nn
ec
tor.
ph
p
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Connecteurs PodBridge
Logique métier
Middleware SOA – PodBridge1.2Intermédiation entre serveurs d’application et
consommateurs de services
WSDL & Services Web SOAPSOAP endpoint, description, XML,
XSD..
Protocoles de
communication
Règles de communication
HTTP : 80
ww
ws
ub
sc
r
ww
ws
ub
sc
r.c
on
ne
cto
r.p
hp
Operation
X
Operation
Y
Operation
Z
WS
SOAP
PodBridge 1.2 (Middleware SOA) – podbridge.intranet.demo PodBridge 1.2
ws.rnu.edu.demo
Se
rve
ur
CU
PS
cu
ps.in
tra
ne
t.d
em
o
Mo
de
m G
SM
co
nn
ec
té
à u
n s
erv
eu
r D
eb
ian
Le
nn
y
de
bia
n5
-02
.in
tra
ne
t.d
em
o
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Ad
min
. P
od
Bri
dg
e
Ad
min
. P
od
Bri
dg
e
Se
rve
ur
Ma
il –
SM
TP
& P
OP
3
rnu
.ed
u.d
em
o
Se
rve
ur
We
b d
u s
ite
d’in
sc
rip
tio
n u
niv
ers
ita
ire
inscrip
tio
n.e
du
.de
mo
Ad
min
. S
ys
tèm
e
Ad
min
istr
ate
ur
Sy
stè
me
Se
rve
ur
FT
P
ftp
-etu
.in
tra
ne
t.d
em
o
Consommateur
de service
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Consommateur
de service
Figure 33 –1ère
phase de l’urbanisation des deux réseaux (Services Web)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 89
3.6. Réalisation des processus métiers - phase 2
Déploiement de ProcessRUById et BatchProcessRU :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 90
ProcessRUById
WS
SOAP
GlassFish ESB 2.1composant sun-bpel-engine
bpel-engine.intranet.demo
BatchProcessRU
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Receive
invoke
Invoke
Processinvoke
invoke
Reply
BP
EL
BatchProcessRU
Receive
invoke
invoke
invoke
Reply
BP
EL
ProcessRUById
invoke
invoke
Messages XML SOAP
(Requête et réponse)
Figure 34 –Déploiement de ProcessRUById et BatchProcessRU
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 91
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)
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 92
Lancement d’un job d’impression pour l’accusé de paiement :
Boite de réception :
Paramètres du compte FTP (reçu par mail) :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 93
Notification par SMS – Message de bienvenu :
Compte FTP :
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 94
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
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 95
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>
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 96
3.7. Développement des applications
Réseau National Universitaire (WAN)
ProcessRUById
WS
SOAP
GlassFish ESB 2.1composant sun-bpel-engine
bpel-engine.intranet.demo
BatchProcessRU
WS
SOAP
IPP : 631 SSH : 22SSH : 22 Telnet : 23 Pgsql : 5432
BD
étu
dia
nts
Po
stg
reS
QL
po
stg
res-8
3.in
tra
ne
t.d
em
o
Réseau local de l’établissement (LAN)
AP
AC
LM
an
ag
er
AP
AC
LM
an
ag
er.
co
nn
ec
tor.
ph
p
IPP
Se
rvic
e
IPP
Se
rvic
e.c
on
ne
cto
r.p
hp
BD
be
tu
BD
etu
.co
nn
ec
tor.
ph
p
SM
SS
erv
ice
SM
SS
erv
ice
.co
nn
ec
tor.
ph
p
FT
PA
cc
ou
nt
FT
PA
cc
ou
nt.
co
nn
ec
tor.
ph
p
Po
int
d’a
cc
ès
Sa
ns
Fil
ap-2
1.in
tra
ne
t.d
em
oServeurs d’application,
Ressources
Systèmes hétérogènes
SSH : 22
Ma
ilA
cc
ou
nt
Ma
ilA
cc
ou
nt.
co
nn
ec
tor.
ph
p
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Connecteurs PodBridge
Logique métier
WSDL & Services Web
SOAPSOAP endpoint, description,
XML, XSD..
Protocoles de
communication
Règles de communication
SSH : 80
ww
ws
ub
sc
r
ww
ws
ub
sc
r.c
on
ne
cto
r.p
hp
Operation
X
Operation
Y
Operation
Z
WS
SOAP
PodBridge 1.2 (Middleware SOA) – podbridge.intranet.demo PodBridge 1.2
ws.rnu.edu.demo
Se
rve
ur
CU
PS
cu
ps.in
tra
ne
t.d
em
o
Mo
de
m G
SM
co
nn
ec
té
à u
n s
erv
eu
r D
eb
ian
Le
nn
y
de
bia
n5
-02
.in
tra
ne
t.d
em
o
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Se
rve
ur
Ma
il –
SM
TP
& P
OP
3
rnu.e
du.d
em
o
Se
rve
ur
We
b d
u s
ite
d’in
sc
rip
tio
n u
niv
ers
ita
ire
inscrip
tio
n.e
du.d
em
o
Se
rve
ur
FT
P
ftp
-etu
.in
tra
ne
t.d
em
o
Operation
X
Operation
Y
Operation
Z
WS
SOAP
Receive
invoke
Invoke
Processinvoke
invoke
Reply
BP
EL
BatchProcessRU
Receive
invoke
invoke
invoke
Reply
BP
EL
ProcessRUById
invoke
invoke
start-pru-09-
10-att.shdeleteftp.pl
ping.java
formulaire.php
Messages XML SOAP
(Requête et réponse)
Middleware SOA –
PodBridge1.2Intermédiation entre serveurs
d’application et consommateurs
de services
Figure 35 - SI après urbanisation
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 97
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/auto/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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 98
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());
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 99
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-bpel-engine.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,
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 100
- 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
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
licence Apache.
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 101
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
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
serveur.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 102
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 l igne 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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 103
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.
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Chapitre 3 : Etude conceptuelle
ISET Djerba | TriTux PAGE 104
Figure 36 - Architecture de PodBridge 1.2
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Perspective
ISET Djerba | TriTux PAGE 105
4. Perspective
De nombreuses perspectives peuvent être envisagées comme suites à ce travail .
Par le manque de temps, on n’a pu se concentrer que sur un seul système d’information,
mais il est plus intéressant si on s’intéresse à urbaniser d’autres systèmes informatiques
géographiquement répartis et de nature de services différents. On peut même imaginer une
multitude d’applications suite à l’interaction entre les différents services qui peuvent êtres
fournis par l’office des services universitaires (hébergement, restaurants, inscription..), la
Poste (service de paiement en ligne), le site du CNS (Conseil National de la Statistique), et
encore d’autres…
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Liste des abréviations
ISET Djerba | TriTux PAGE 106
5. Liste des abréviations
ACL............................................................................................................ Access Control List
AOS ........................................................................................ Architecture Orientée Services
API ..................................................................................Application Programming Interface
BD ................................................................................................................Base de Données
BPEL ............................................................................ Business Process Execution Language
BPEL4WS........................................ Business Process Execution Language For Web Services
BPM .......................................................................................Business Process Management
BSD ........................................................................................ Berkeley Software Distribution
CEO ..................................................................................................... Chief Executive Officer
CLI ................................................................................................... Command Line Interface
CNS .................................................................................... Conseil National de la Statistique
CUPS ..................................................................................... Common UNIX Printing System
DB .......................................................................................................................... Data Base
EJB .......................................................................................................... Enterprise JavaBean
FTP ........................................................................................................ File Transfer Protocol
GNU ................................................................................................................ Gnu’s Not Unix
GPL...................................................................................................... General Public License
GSM ............................................................................................... Global System for Mobile
HTTP ..........................................................................................HyperText Transfer Protocol
HTTPS............................................................................. HyperText Transfer Protocol Secure
IDE .............................................................................Integrated Development Environment
IIP ................................................................................................... Internet Printing Protocol
JDK ........................................................................................................Java Development Kit
LDAP .......................................................................... Lightweight Directory Access Protocol
MAC .................................................................................................. Medium Access Control
MMS ...................................................................................... Multimedia Messaging Service
MVC .................................................................................................... Model View Controller
NTIC ................................Nouvelles Technologies de l'Information et de la Communication
OASIS ....................................Organization for the Advancement of Structured Information
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Bibliographie
ISET Djerba | TriTux PAGE 107
ORM............................................................................................. Object Relational Mapping
PHP ............................................................................................PHP Hypertext Preprocessor
POP ......................................................................................................... Post Office Protocol
POP3 ........................................................................................Post Office Protocol version 3
RMI ............................................................................................. Remote Method Invocation
RNU......................................................................................... Réseau National Universitaire
RPC..................................................................................................... Remote Procedure Call
SARL .................................................................... Société Anonyme à Responsabilité Limitée
SGBD ......................................................................Système de Gestion de Base de Données
SI .........................................................................................................Système d'Information
SMS .................................................................................................. Short Messaging Service
SMTP....................................................................................... Simple Mail Transfer Protocol
SOA ......................................................................................... Service Oriented Architecture
SOAP .......................................................................................Simple Object Access Protocol
SQL.............................................................................................. Structured Query Language
SSH.......................................................................................................................Secure SHell
SSID........................................................................................................Service Set IDentifier
SSII ....................................................... Société de Service et d’Ingénierie de l’Informatique
SVN .......................................................................................................................SubVersioN
UDDI ........................................................ Universal Description, Discovery and Integration
UML ............................................................................................ Unified Modeling Language
URI ............................................................................................. Uniform Resource Identifier
URL ............................................................................................... Uniform Resource Locator
WS ...................................................................................................................... Web Service
WSDL ............................................................................. Web Services Description Language
WS-I .........................................................................................Web Services Interoperability
XML...........................................................................................eXtensible Markup Language
XSD .................................................................................................... XML Schema Definition
XSLT ........................................................... eXtensible Stylesheet Language Transformation
YAML........................................................................................ Yaml Ain’ t Markup Language
Rapport PFE Urbanisation d’un SI universitaire SOA & BPM Walid KARRAY | 2009 - 2010 Bibliographie
ISET Djerba | TriTux PAGE 108
6. Bibliographie
SOA and WS-BPEL par Yuli Vasiliev et packt publishing - ISBN 13 978-1-847192-70-7
Architecture Orientée Services : Démystification – Khaled BEN DRISS
http://www.tritux.com/index.php?option=com_content&task=view&id=21
http://www.softwareagility.gr/index.php?q=node/22
http://www.developer.com/services/article.php/3609381/An-Introduction-to-BPEL.htm
http://fr.wikipedia.org/wiki/XML-RPC
http://es.wikipedia.org/wiki/WS-BPEL
http://en.wikipedia.org/wiki/Web_service
http://en.wikipedia.org/wiki/Web_Services_Description_Language
http://fr.wikipedia.org/wiki/Urbanisation_(système_d'information)
http://en.wikipedia.org/wiki/System_integration
http://fr.wikipedia.org/wiki/Soa
http://fr.wikipedia.org/wiki/SOAP
http://fr.wikipedia.org/wiki/Proc%C3%A9dure_d%27entreprise
http://fr.wikipedia.org/wiki/Middlewares
Urbanisation d’un système d’information universitaire
SOA & BPM
M. WALID KARRAY
RRééssuumméé :: Ce rapport s'inscrit dans la préparation du Projet de Fin d' Etudes à l’Institut Supérieur
des Etudes Technologiques - ISET Djerba - 2009/2010. Le Projet a été réalisée dans la Société
''Tritux''- Tunis et vise à urbaniser les systèmes d'information académique et la gestion des données
sous les architectures de S.O.A et du B.P.M.
La migration vers l'Architecture Orientée Services ainsi qu'avec Business Process Management
permet la réorganisation des systèmes d'information de l'entreprise et la conformité rapide et
constante avec l'environnement évolutif.
Le projet est consacré totalement aux axes de l'architecture S.O.A pour générer une
fonctionnalité d'un ensemble de fonctions de base (Services) avec des composants afin de créer un
schéma d'interactions entre ces services.
Avec S.O.A et B.P.M, des efforts considérables ont été déployés pour garantir enfin un système
évolutif de l'information basée sur des composants connectés, sécurisé, facile à maintenir et à se
conformer aux normes standards.
MMoottss ccllééss :: Urbanisation, intergiciel, AOS, BPM, Services web, BPEL, orchestration.
AAbbssttrraacctt :: The present report comes within the preparation of the Final Project Studies at the
Higher Institute of Technological Studies - I.S.E.T Djerba - 2009/2010. It was carried at Tritux
Company - Tunis and aims at urbanizing the academic information systems and data management
under S.O.A architecture and B.P.M.
The migration to Service Oriented Architecture altogether with Business Process Management
helps reorganize the information systems of the company and enable for quick and constant
conformity with the changing environment.
The project makes total use of S.O.A paradigms to generate functionality into a set of basic
functions, called Services with definite components to finally create pattern of interactions between
those services. Within S.O.A and B.P.M, considerable attempts have been made to finally guarantee a
scalable Information System based on connected components, secure, easy to maintain and conform
to standards norms.
KKeeyywwoorrddss :: Urbanization, middleware, SOA, BPM, Web services, BPEL, orchestration.