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

R APPORT DE PROJET DE FIN D ’ ETUDES

Urbanisation d’un Système d’information universitaire

SOA & BPM

Elaboré par : K

W

Encadré par : N

F

Encadré par : F

Z

| A

M

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 Ministère de l’Enseignement Supérieur,

de la Recherche Scientifique et Technologie Direction Générale des Études

Technologiques

Effectué à :

Dédicaces

A toute ma famille, à mes enseignants,

à mes amis, et à mes camarades

je dédie ce travail.

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

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 1^er processus métier : ProcessRUById ... 74

3.3.3. Conception du processus : BatchProcessRU ... 77

3.3.4. Conclusion ... 78

Chapitre 4 : Réalisation ... 79

3.4. Installation & Configuration ... 79

3.4.1. Serveur FTP : ftp-etu.intranet.demo ... 79

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

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

‘

’

Adresse électronique: walid.karray@gmail.com

1. Chapitre 1 : Introduction

1.1. Introduction générale

Des systèmes informatiques qui sont réunis pour exécuter une tâche, peuvent tous êtres considérés comme étant un seul système, toute cette force peut être due à un échange d’une faible quantité d’informations entre les différents systèmes. On peut déduire ainsi que ces systèmes sont dépendantes les unes des autres, et si à un moment donné deux systèmes parmi l’ensemble n’arrivent pas à s’échanger d’informations, ça engendrera alors le dysfonctionnement de la totalité du système.

Malheureusement, à chaque fois qu’on se lance à la conception d’une application composite on découvre toujours des problèmes d’intégration avec des systèmes qui à la base ne sont pas pensées pour fonctionner ensemble utilisant des technologies différentes et des protocoles propriétaires.

Pour remédier à ce genre de problèmes on utilise souvent des logiciels intermédiaires appelées (intergiciels), le plus souvent appelé middlewares (en anglais) qui servent d’intermédiaire de communication entre plusieurs applications, généralement complexes ou distribuées sur un réseau informatique.

1.2. Entreprise d’accueil

Tritux, SARL¹ est une SSII² 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

l'approche des activités liées aux NTIC par l'adaptation du choix "Open Source " garantissant la sécurité, fiabilité, flexibilité, et surtout, une évolution quotidienne vers le top de la technologie.

Les domaines d’activités de Tritux s’étendent sur plusieurs disciplines à savoir : - Bases de données libres,

- Logiciels libres,

- Développement de solutions avec des outils/ressources libres, - Annuaires LDAP³,

- Messageries mail,

- Messageries courtes (SMS⁴) et Multimédia (MMS⁵), - Systèmes GNU⁶ 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

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

 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 ⁷permet l’hébergement de comptes pour les étudiants,

- le serveur d’impression permet d’envoyer un ordre d’impression à une imprimante distante partagée,

- le site web d’inscription en ligne permet de consulter les reçus de payements de chaque étudiant,

- le serveur Mail permet d’envoyer un message à un groupe d’étudiants,

7 File Transfer Protocol

- et encore plus…

Existe-il un système informatique aussi performent qui peut répondre à plusieurs besoins à la foi ? Comme par exemple, un système pouvant à partir des informations stockés sur chaque étudiant de gérer automatiquement leurs comptes FTP, leurs comptes Mail, leurs accès au réseau sans fil, les notifiés par SMS, leurs envoyer les calendriers et des documents numériques, etc...

Par les moyens présents, si un établissement pense à offrir ces différents services à ses quelques milliers d’étudiant, il faudra compter des semaines de travails pour arriver à un résultat presque satisfaisant !

Certainement que l’informatisation (automatisation) des différentes procédures cités précédemment est sans aucun doute quelque chose d’indispensable ; il faudra donc un système qui à la foi capable de gérer les différentes ressources et de coordonner l’échange d’informations d’une façon autonome entre les différents systèmes informatiques qu’on dispose. Mais avant de penser à une solution on se pose ces deux questions :

- Comment des systèmes de technologies et de protocoles de communications différents puissent s’interagir ?

- Par quel moyen sera assuré l’échange de flux d’information entre les différents systèmes ?

C’est pour cette raison que le concept SOA⁸ et le BPM⁹ 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

2) La deuxième phase consiste à la conception des processus métier à travers un workflow / orchestration¹⁰ de services web

10 Processus de coordination d'un échange d'information à travers l'interaction de services web. « Source Wikipedia – http://fr.wikipedia.o rg/wiki/Orchestration _(informatique) »

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éponse

Message

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

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

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’ar chitecture 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.

Application

Web Terminal Appareil

Mobile

Orchestration

WORKFLOW BPEL, BPM

Présentation

Consommateur Application

Services

Services Services web

Composants, Méthodes

Méthodes de classes bibliothèques,drivers...

Systèmes &

Ressources

Serveurs,

Bases de données..

DB DB

I0II0I0I0I0 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’ar chitecture 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.

2.2. Les services web

2.2.1. Introduction

Les services web représentent un ensemble de fonctionnalités distribués sur intranet ou internet qui peuvent être exécutés à distance à travers les protocoles d’internet tel que HTTP¹²/HTTPS ¹³et SMTP¹⁴.

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¹⁵ 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

<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 ¹⁶ se basent aussi sur l’échange de messages XML et se reposent sur le standard SOAP pour l’échange de message et WSDL ¹⁷ pour décrire les services web.

 Structure d’un document WSDL :

16 Simple Object Access Protocol

17 Web Services Description Language

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

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.

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

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.

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,

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

2.3. Orchestration de Services web

2.3.1. Introduction

Dans le concept SOA, l’orchestration s’explique par un enchainement d’invocation de services web de fines granularités obéissant à un chef d’orchestre : WS-BPEL¹⁸ 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)

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.

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

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 ¹⁹ 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

Process flow template Generates

BPEL Designer

Executes BPEL Engine

Design Time Run Time

Business Expert End User / Application

Figure 11²⁰ – 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

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

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

2.3.4. Résumé

 Avantages de BPEL

- Séparer le logique processus de la logique application,

- Possibilité de changer le processus sans impact sur les applications, - Agilité de l’entreprise ou l’organisme,

- Présenter le processus comme un service,

- Portable : supporté par plusieurs serveurs (moteurs BPEL), - Basé sur XML,

- Supporte plusieurs fonctionnalités tel que (Exécution asynchrone, fonction XSLT²¹, exécution en parallèle, validation, exceptions …).

21 eXtensible Stylesheet Language Transformation

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

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.

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

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

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 »

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

+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 (Conne cteur PodBridge de l’établissement)

 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

Service

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,te l,email,loginftp,adr mac,refrecu,proce ss). Array

Service

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

Service

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

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.

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)

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 :

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

 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

SERVICE

doCreateFTPUserAccoun t

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

défaut) boolean

SERVICE

setFTPUserAccountExpir yDate

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

SERVICE

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

SERVICE

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

SERVICE

doChangeFTPUserPa ssword

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

SERVICE

doDeleteFTPUserAcc ount

Supprime un compte utilisateur FTP du système.

user : Nom d’utilisateur.

String

Vrai si le compte d’utilisateur a été supprimé avec succès.

boolean

SERVICE

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.

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.

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 i d g e 1 . 2 S O A M i d d l e 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 i c 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 t e : u s e r a d d … - g F T P ...

A u t h e n t ic a t e a n d c h e c k p r iv ile g e

H a n d le r e q u e s t

< < I n c lu d e > > C a ll m e t h o d : s e t F T P U s e r W e lc o m e M s g ( )

C a ll m e t h o d : d o C r e a t e F T P U s e r A c c o u n t ( )

C a ll m e t h o d : s s h 2 E x e c ( )

S e r v ic e C o n s u m e r

< < I n c lu d e > >

< < I n c lu d e > >

G e t r e s p o n s e f r o m c a c h e

< < I n c lu d e > >

S h e ll E x e c u t e : c p … T e ll S S H S e r v e r t o

p e r f o r m t h e o p e r a t io n

< < I n c lu d e > >

if c a c h e d T r a c e r e q u e s t s a n d

r e s p o n s e s

< < I n c lu d e > >

F T P S e r v e r a d m in

C a ll m e t h o d : s e t F T P U s e r A c c o u n t

E x p ir y D a t e ( )

< < I n c lu d e > >

F r o n t e n d

G e t W S D L P B a d m in

S e t u p P B 1 . 2 M o n it o r t r a n s a c t io n s lo g

I n v o k e W S : d o C r e a t e F T P U s e r A c c o u n t

I n v o k e W S : s e t F T P U s e r W e lc o m e M s g

I n v o k e W S : s e t F T P U s e r A c c o u n t E x p ir y D a t e

I n v o k e W S : d o F T P s e n d F ile

C a ll m e t h o d : d o F T P s e n d F ile ( )

< < I n c lu d e > >

C a ll m e t h o d : g e t U n ix D a t e ( )

< < I n c lu d e > >

C a ll m e t h o d : g e n e r a t e R a n d o m P a s s w d ( )

< < I n c lu d e > >

C a ll m e t h o d : if U s e r E x is t s ( )

< < I n c lu d e > >

S h e ll e x e c u t e : u s e r m o d - e . . . .

< < I n c lu d e > >

S h e ll E x e c u t e : c h o w n . . .