SOA & BPM - Tux86

111
R APPORT DE PROJET DE FIN DETUDES 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é à :

Transcript of SOA & BPM - Tux86

Page 1: SOA & BPM - Tux86

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é à :

Page 2: SOA & BPM - Tux86

ISET Djerba | TriTux PAGE 1

Page 3: SOA & BPM - Tux86

ISET Djerba | TriTux PAGE 2

Dédicaces

A toute ma famille,

à mes enseignants,

à mes amis,

et à mes camarades

je dédie ce travail.

Page 4: SOA & BPM - Tux86

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

Page 5: SOA & BPM - Tux86

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

Page 6: SOA & BPM - Tux86

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

Page 7: SOA & BPM - Tux86

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

Page 8: SOA & BPM - Tux86

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]

Page 9: SOA & BPM - Tux86

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

Page 10: SOA & BPM - Tux86

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

Page 11: SOA & BPM - Tux86

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.….

Page 12: SOA & BPM - Tux86

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

Page 13: SOA & BPM - Tux86

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

Page 14: SOA & BPM - Tux86

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) »

Page 15: SOA & BPM - Tux86

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-*

Page 16: SOA & BPM - Tux86

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.

Page 17: SOA & BPM - Tux86

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.

Page 18: SOA & BPM - Tux86

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

Page 19: SOA & BPM - Tux86

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

Page 20: SOA & BPM - Tux86

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).

Page 21: SOA & BPM - Tux86

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.

Page 22: SOA & BPM - Tux86

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 :

Page 23: SOA & BPM - Tux86

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.

Page 24: SOA & BPM - Tux86

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,

Page 25: SOA & BPM - Tux86

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.

Page 26: SOA & BPM - Tux86

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)

Page 27: SOA & BPM - Tux86

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.

Page 28: SOA & BPM - Tux86

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

Page 29: SOA & BPM - Tux86

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

Page 30: SOA & BPM - Tux86

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

Page 31: SOA & BPM - Tux86

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"/>

Page 32: SOA & BPM - Tux86

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>

Page 33: SOA & BPM - Tux86

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

Page 34: SOA & BPM - Tux86

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)…

Page 35: SOA & BPM - Tux86

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.

Page 36: SOA & BPM - Tux86

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.

Page 37: SOA & BPM - Tux86

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.

Page 38: SOA & BPM - Tux86

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 »

Page 39: SOA & BPM - Tux86

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 :

Page 40: SOA & BPM - Tux86

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)

Page 41: SOA & BPM - Tux86

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

Page 42: SOA & BPM - Tux86

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.

Page 43: SOA & BPM - Tux86

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)

Page 44: SOA & BPM - Tux86

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 :

Page 45: SOA & BPM - Tux86

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)

Page 46: SOA & BPM - Tux86

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

Page 47: SOA & BPM - Tux86

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

Page 48: SOA & BPM - Tux86

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.

Page 49: SOA & BPM - Tux86

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.

Page 50: SOA & BPM - Tux86

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 . . .

Page 51: SOA & BPM - Tux86

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)

Page 52: SOA & BPM - Tux86

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.

Page 53: SOA & BPM - Tux86

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.

Page 54: SOA & BPM - Tux86

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)

Page 55: SOA & BPM - Tux86

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

Page 56: SOA & BPM - Tux86

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.

Page 57: SOA & BPM - Tux86

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)

Page 58: SOA & BPM - Tux86

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 :

Page 59: SOA & BPM - Tux86

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.

Page 60: SOA & BPM - Tux86

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)

Page 61: SOA & BPM - Tux86

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

Page 62: SOA & BPM - Tux86

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)

Page 63: SOA & BPM - Tux86

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.

Page 64: SOA & BPM - Tux86

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)

Page 65: SOA & BPM - Tux86

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 :

Page 66: SOA & BPM - Tux86

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.

Page 67: SOA & BPM - Tux86

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

Page 68: SOA & BPM - Tux86

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

Page 69: SOA & BPM - Tux86

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

Page 70: SOA & BPM - Tux86

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.

Page 71: SOA & BPM - Tux86

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)

Page 72: SOA & BPM - Tux86

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.

Page 73: SOA & BPM - Tux86

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)

Page 74: SOA & BPM - Tux86

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)

Page 75: SOA & BPM - Tux86

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

Page 76: SOA & BPM - Tux86

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).

Page 77: SOA & BPM - Tux86

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 »

Page 78: SOA & BPM - Tux86

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).

Page 79: SOA & BPM - Tux86

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.

Page 80: SOA & BPM - Tux86

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) :

Page 81: SOA & BPM - Tux86

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"

Page 82: SOA & BPM - Tux86

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 :

Page 83: SOA & BPM - Tux86

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

Page 84: SOA & BPM - Tux86

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)

Page 85: SOA & BPM - Tux86

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) :

Page 86: SOA & BPM - Tux86

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:

Page 87: SOA & BPM - Tux86

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):

Page 88: SOA & BPM - Tux86

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

Page 89: SOA & BPM - Tux86

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

à 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)

Page 90: SOA & BPM - Tux86

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 :

Page 91: SOA & BPM - Tux86

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

Page 92: SOA & BPM - Tux86

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)

Page 93: SOA & BPM - Tux86

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) :

Page 94: SOA & BPM - Tux86

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 :

Page 95: SOA & BPM - Tux86

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

Page 96: SOA & BPM - Tux86

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>

Page 97: SOA & BPM - Tux86

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

à 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

Page 98: SOA & BPM - Tux86

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.

Page 99: SOA & BPM - Tux86

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());

Page 100: SOA & BPM - Tux86

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,

Page 101: SOA & BPM - Tux86

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.

Page 102: SOA & BPM - Tux86

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.

Page 103: SOA & BPM - Tux86

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.

Page 104: SOA & BPM - Tux86

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.

Page 105: SOA & BPM - Tux86

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

Page 106: SOA & BPM - Tux86

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…

Page 107: SOA & BPM - Tux86

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

Page 108: SOA & BPM - Tux86

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

Page 109: SOA & BPM - Tux86

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

Page 110: SOA & BPM - Tux86
Page 111: SOA & BPM - Tux86

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.