45

CHAPITRE I : LES ARCHITECTURES DES SYSTEMES

DISTRIBUES [1], [4], [5], [11], [14], [15], [16], [19], [20]
1.1. HISTORIQUE

L'utilisation de processus concurrents communicant par passage de messages a

ses racines dans le système d'exploitation des architectures étudiées dans les années 1960. Les
premiers systèmes distribués les plus répandus ont été les réseaux locaux tels que Ethernet qui
a été inventé dans les années 1970.

ARPANET , qui est l'ancêtre de l' Internet , a été introduit dans les années
1960, et ARPANET e-mail a été inventé au début des années 1970. E-mail est devenu
l'application la plus réussie de l'ARPANET, et il est probablement le premier exemple d'une
application à grande échelle distribuée. En plus d'ARPANET, et son successeur, l'Internet,
d'autres réseaux informatiques dans le monde entier débutent, à partir des années 1980.

L'informatique distribuée est devenue une véritable branche de l'informatique

dans les années 1970 et début 1980.

L’essor des systèmes distribués a entraîné le développement de nouvelles

applications conçues pour s’y exécuter : les applications distribuées. Pour le programmeur
d’applications distribuées se pose alors un problème nouveau : celui de la communication. La
gestion des communications est une charge pour le programmeur du fait des imperfections de
la transmission des messages (perte par exemple) et des défaillances possibles des sites du
réseau de communication. Le développement des protocoles de communication fiable permet
alors de décharger le programmeur de la lourde tâche du traitement des erreurs de
transmission et des défaillances susceptibles de survenir pendant une communication.

1.2. NOTIONS D’INFORMATIQUE DISTRIBUEE

Le mot distribué dans des termes tels que «système distribué»,

«programmation distribuée», et « algorithme distribué »se référait initialement à des
réseaux informatiques où les ordinateurs individuels ont été distribués physiquement au sein
de certaines zones géographiques. Les termes sont aujourd'hui utilisés dans un sens plus large,
même autonome, se référant au processus qui s'exécutent sur le même ordinateur physique et
interagissent les uns avec les autres par passage de messages.
 45

L'informatique distribuée est un domaine de l'informatique qui étudie les

systèmes distribués. Un système distribué est constitué de plusieurs ordinateurs autonomes
qui communiquent entre eux à travers un réseau informatique . Les ordinateurs interagissent
les uns avec les autres afin d'atteindre un objectif commun. Un programme informatique qui
s'exécute dans un système distribué est appelé un programme distribué, et le processus
d'écriture de ces programmes est la programmation distribuée.

L'informatique distribuée se réfère également à l'utilisation de systèmes

distribués pour résoudre des problèmes informatiques. Dans le calcul distribué, un problème
est divisé en nombreuses tâches, dont chacun est résolu par un ou plusieurs ordinateurs.

1.3. LE CALCUL PARALLELE ET LE CALCUL DISTRIBUE

Les systèmes distribués sont des groupes d'ordinateurs en réseau, qui ont le
même objectif pour leur travail. Les termes « calcul parallèle » et « calcul distribué » ont
beaucoup de chevauchement, et aucune distinction claire n’existe entre les deux. Le même
système peut être caractérisé à la fois comme «parallèle» et «distribué».

Néanmoins, il est possible de classer les systèmes concurrents comme

«parallèles» ou «distribués» selon les critères suivants:

 Dans le calcul parallèle, tous les processeurs ont accès à une mémoire partagée . La
mémoire partagée peut être utilisée pour échanger des informations entre les
processeurs.

 Dans l'informatique distribuée, chaque processeur a sa propre mémoire privée

(mémoire distribuée ). Des informations sont échangées par le passage de messages
entre les processeurs.

Figure 1. Schéma de différence entre calcul distribué et calcul parallèle

 45

La figure (a) est une vue schématique d'un système typique distribué; en effet, le système est
représenté comme une topologie de réseau dans lequel chaque nœud est un ordinateur et
chaque ligne reliant les nœuds est un lien de communication. La figure (b) montre le même
système réparti de manière plus détaillée: chaque ordinateur a sa propre mémoire locale, et les
informations ne peuvent être échangées que par passage des messages d'un nœud à un autre
en utilisant les liens de communication disponibles. La figure (c) montre un système parallèle
dans lequel chaque processeur dispose d'un accès direct à une mémoire partagée.

Le calcul parallèle de haute performance dans une mémoire partagée utilise des
algorithmes parallèles multiprocesseurs tandis que la coordination d'un système à grande
échelle distribuée utilise des algorithmes distribués.

1.4. NOTION DE SYSTEME DISTRIBUE

1.4.1. Définition

Un système distribué est constitué d’un ensemble de postes de travail et de

périphériques reliés entre eux par un système de communication (réseau informatique) afin
d’atteindre un objectif commun.

On peut aussi le définir comme un ensemble d’ordinateurs indépendants

connectés et communicant via un réseau. Cet ensemble apparaît au niveau des utilisateurs
comme une entité unique.

Par opposition aux systèmes centralisés où tout est localisé sur la même
machine et accessible par le même programme. Donc ici le système logiciel s’exécute sur une
seule machine et on accède localement aux ressources nécessaires.

1.4.2. Vision matérielle et logicielle d’un système distribué

a) Vision matérielle d’un système distribué

La vision matérielle d’un système distribué se base sur :

 les machines multiprocesseurs avec mémoire partagée

 le cluster d’ordinateurs dédiés au calcul ou au traitement massif parallèle
 les ordinateurs standards connectés en réseau

b) Vision logicielle d’un système distribué

La vision logicielle se base sur un système logiciel qui est composé de

plusieurs entités qui s’exécutent indépendamment et en parallèle sur un ensemble
d’ordinateurs connectés en réseau.
 45

1.4.3. Caractéristiques d’un système distribué

 Le partage des ressources : partage des ressources matérielle et logicielle

 La concurrence : le traitement concurrent pour accroître les performances
 La scalabilité : élargissement du système en ajoutant de nouvelles ressources
 La tolérance à la panne : c’est la capacité qu’a le système à continuer une opération
après qu’une panne soit détectée.

1.4.4. Intérêts des systèmes distribués

 Utiliser et partager les ressources distantes : comme exemples illustratifs on a :

- Le système des fichiers : utiliser ses fichiers sur n’importe quelle machine
- Le partage de l’imprimante sur toutes les machines

 Optimiser l’utilisation des ressources disponibles : par exemple les calculs

scientifiques distribués sur un ensemble de machines.

 Obtenir un système plus robuste : comme le cas de la duplication d’une ressource

pour la fiabilité (ex : deux serveurs de fichiers dupliqués).

1.4.5. Avantages des systèmes distribués

Parmi les avantages que présentent les systèmes distribués, on peut citer :

 Le partage des ressources: matériel et logiciel

 Amélioration des performances: temps de réponse rapide et un débit plus élevé du

système

 Amélioration de la fiabilité et la disponibilité

 Extensibilité modulaire

1.4.6. Désavantages des systèmes distribués

 La complexité : les systèmes distribués sont plus complexes que les systèmes
centralisés
 45

 La sécurité : la nature d'un système distribué fait qu'il est beaucoup plus sujet à des
attaques. La communication à travers le réseau peut être interceptée et on ne
connaît pas toujours bien un élément distant avec qui on communique.

 La Manageabilité : beaucoup d’efforts sont requis pour le management du système.

 S’il y a un problèmes au niveau du réseau, le système marche mal ou ne marche

plus

 Bien souvent un élément est central au fonctionnement du système : le serveur. Si

celui-ci plante, le système ne peut fonctionner

1.4.7. Transparence des systèmes distribués

Lors de la mise en place d’un système distribué, le but est de cacher

l'architecture, le fonctionnement de l'application ou du système distribué pour apparaître à
l'utilisateur comme une application unique cohérente. C’est le principe de la « transparence ».

L’ISO définit plusieurs transparences (norme RM-ODP) :

 Transparence d’accès :
 Accès à des ressources distantes aussi facilement que localement
 Accès aux données indépendamment de leur format de représentation

 Transparence de localisation : Accès aux éléments (ressources) indépendamment

de leur localisation.

 Transparence de concurrence : c’est l’exécution possible de plusieurs processus en

parallèle avec utilisation de ressources partagées.

 Transparence de réplication : c’est lorsqu’il y a la possibilité de dupliquer certains

éléments (ressources) pour augmenter la fiabilité

 Transparence de mobilité : c’est la possibilité de déplacer des éléments

(ressources).

 Transparence des pannes : c’est lorsque le système supporte qu'un ou plusieurs

éléments tombent en panne.

 Transparence de performance : c’est la possibilité de reconfigurer le système pour

en augmenter les performances.
 45

 Transparence d’échelle : c’est la capacité à supporter l'augmentation de la taille du

système (nombre d’éléments, de ressources).

Un système distribué donné devrait offrir un certain nombre de transparences

souvent au minimum les transparences de localisation, d’accès et de concurrence.

1.4.8. Le Middleware

Le Middleware est le pont qui relie des applications distribuées sur différents
emplacements physiques, avec des plates-formes matérielles différentes, les technologies de
réseau, systèmes d'exploitation et langages de programmation. En d’autres mots c’est un
programme qui gère et supporte les différents composants d’un système distribué.

C’est une couche logicielle qui s’intercale entre le système

d’exploitation/réseau et les éléments de l’application distribuée. Il offre un ou plusieurs
services de communication entre les éléments formant l'application ou le système distribué.

Figure 2. Architecture d’un Middleware

 Exemples :
- Le moniteur de traitement des transactions
- Les convertisseurs des données
- Les contrôleurs de communication

 But et fonctionnalités d’un Middleware

- Gestion de l’hétérogénéité : la gestion des différents langages de programmations,

des différents systèmes d’exploitation utilisés.

- Offrir des abstractions de communication de plus haut niveau : ici le middleware

doit être en mesure d’offrir les services suivants :
a) L’appel d’une procédure à distance sur un élément
b) La communication via une mémoire partagée
c) La diffusion d’évènements
 45

- Offrir des services de configuration et de gestion du système : ces services sont :

a) Le service d'annuaire pour connaître les éléments présents
b) Services de persistance, de temps, de transaction, de sécurité

1.4.9. Quelques exemples des systèmes distribués ou d’application de calcul distribué

 Télécommunications des réseaux:

 Les réseaux téléphoniques et les réseaux cellulaires .

 Les réseaux informatiques tels que l’Internet .

 Réseaux de capteurs sans fil .

 Algorithmes de routage .

 Les applications réseau:

 World Wide Web et le peer-to-peer .

 Les jeux massivement multi-joueurs en ligne et de réalité virtuelle

communautés.

 Bases de données distribuées et de systèmes distribués de gestion de base de

données .

 Les systèmes de fichiers réseau .

 Systèmes distribués de traitement des informations telles que les systèmes

bancaires et les systèmes de réservation des compagnies aériennes.

 Contrôle de processus en temps réel:

 Avions systèmes de contrôle.

 Systèmes de contrôle industriel .

 Calcul parallèle :

 Calcul scientifique , y compris les clusters de calcul et de grid computing

1.5. LES ARCHITECTURES DES SYSTEMES DISTRIBUES

Divers matériels et architectures logicielles sont utilisés pour l'informatique

distribuée. A un niveau inférieur, il est nécessaire d'interconnecter plusieurs processeurs avec
 45

une sorte de réseau. À un niveau supérieur, il est nécessaire d'interconnecter les processus
exécutés sur ces processeurs avec une sorte de système de communication.

Les différentes architectures des systèmes distribués sont :

1.5.1. L’architecture Client-serveur

Figure 3. Architecture Client-serveur

Le modèle client-serveur est une informatique qui agit comme modèle

d'applications distribuées dont les charges de travail sont reparties entre les fournisseurs d'une
ressource ou un service, appelé « serveurs » , et les demandeurs de services, appelés
« clients ». Souvent, les clients et les serveurs communiquent via un réseau informatique sur
du matériel distinct, mais à la fois client et serveur peuvent résider dans le même système.

Une machine serveur est un hôte qui exécute un ou plusieurs programmes

serveurs qui partagent leurs ressources avec les clients. Un client ne partage aucune de ses
ressources, mais les demande dans le contenu d'un serveur ou d'un service de fonction. Les
clients sont donc initiés à des séances de communication avec les serveurs qui attendent les
requêtes entrantes.

La caractéristique client-serveur décrit la relation des programmes de

coopération dans une application. Le composant serveur dispose d'une fonction ou un service
à un ou plusieurs clients, qui initient des demandes pour de tels services.

Les fonctions telles que l'échange par courriel, accès à Internet et accès à la
base, sont construites sur le modèle client-serveur. Les utilisateurs accédant à des services
bancaires à partir de leur ordinateur d'utiliser un client navigateur Web pour envoyer une
requête à un serveur web dans une banque. Le modèle client-serveur est devenu l'une des
idées centrales de l'informatique en réseau . Beaucoup d’applications d'entreprises qui se
développent aujourd'hui utilisent le modèle client-serveur.
 45

L'interaction entre le client et le serveur est souvent décrite à l'aide de

diagrammes de séquences. L’Unified Modeling Language (UML) est un soutien pour les
diagrammes de séquences.

Certains types de clients comprennent les navigateurs Web , clients de

messagerie et de chat en ligne.

Certains types de serveurs sont des serveurs web , serveurs ftp , serveurs
d'applications , serveurs de bases de données , serveurs de noms , serveurs de messagerie ,
serveurs de fichiers , serveurs d'impression , et serveurs de terminaux . La plupart des services
Web sont également les types de serveurs.

1.5.2. L’architecture Peer-to-Peer

Un réseau client-serveur implique plusieurs clients se connectant à un seul

serveur central. En revanche, les réseaux peer-to-peer impliquent deux ou plusieurs
ordinateurs en commun et les ressources individuelles telles que les disques durs, CD-ROM et
les imprimantes sont partagées. Ces ressources partagées sont disponibles pour chaque
ordinateur du réseau, tandis que chacun d'entre eux communique via une session. Chaque
ordinateur agit à la fois comme client et comme serveur qui signifie que tous les ordinateurs
du réseau sont égaux, c'est de là que le terme peer-to-peer vient.

L'avantage de peer-to-peer est le concept de contrôle plus facile ne nécessitant

aucune entité de coordination supplémentaire et aucun retard de transfert par route via des
entités serveurs. Toutefois, la collision de la session peut être plus importante qu'avec le
routage via les nœuds de serveur.

Dans le réseau peer to peer, les applications logicielles peuvent être installées
sur l'ordinateur unique et partagée par tous les ordinateurs du réseau. Ils sont aussi moins
chers à mettre en place. D'autre part, le modèle client-serveur fonctionne avec n'importe
quelle taille ou configuration physique du réseau local et n'a pas tendance à ralentir avec une
utilisation intensive.

Les réseaux Peer-to-peer sont généralement moins sécurisés qu'un réseau

client-serveur, car la sécurité est assurée par les ordinateurs individuels, et non contrôlées et
supervisées sur le réseau dans son ensemble. Les ressources de l'ordinateur dans le réseau
peuvent être congestionnées comme ils doivent supporter non seulement l'utilisateur poste de
travail, mais aussi les demandes des utilisateurs du réseau.

Les réseaux client-serveur avec leurs capacités supplémentaires ont un coût

d'installation initial plus élevé que les réseaux peer to peer. En outre la concentration des
fonctions dans les serveurs performants permet de qualification faible performance de qualité
des clients.
 45

Il est possible de configurer un serveur sur un ordinateur de bureau moderne,

mais il est recommandé d'envisager des investissements dans les installations de serveurs
d'entreprise à l'échelle standardisée avec choix du matériel et des logiciels et à une stratégie
systématique et manœuvrable à distance. Il est plus facile de configurer et de gérer le matériel
serveur et des logiciels par rapport aux exigences distribués administrés avec un groupe
d'ordinateurs.

1.5.3. Les architecture 3-tiers et n-tiers

En génie logiciel , l’architecture multi-tiers (souvent désigné comme

architecture n-tiers) est une architecture client-serveur dans lequel la présentation, le
traitement de la demande, et la gestion des données sont logiquement des processus séparés.
Par exemple, une application qui utilise le middleware aux données des demandes de service
entre un utilisateur et une base de données emploie architecture multi-tiers. L'utilisation la
plus répandue de l'architecture multi-niveaux est l'architecture à trois niveaux.

L'architecture des applications n-tiers fournit un modèle pour les développeurs

pour créer une application flexible et réutilisable. En décomposant une application en
couches, les développeurs n'ont qu'à modifier ou ajouter une couche spécifique, plutôt que
d'avoir à réécrire toute l'application terminée. Il devrait y avoir une présentation, une couche
logique, et une couche de données.

Les concepts de la couche et de niveau sont souvent utilisés indifféremment.

Cependant, un point de vue assez commun est qu'il ya effectivement une différence, et qu'une
couche est un mécanisme de structuration logique pour les éléments qui composent la solution
logicielle, tandis qu'un niveau est un mécanisme de structuration physique pour
l'infrastructure du système.

Le modèle à trois niveaux est une architecture client-serveur dans laquelle l’

interface utilisateur , la logique des processus fonctionnels («règles métier»), le stockage de
données informatiques et les accès aux données sont développés et maintenus comme
indépendant des modules , séparés le plus souvent sur des plates-formes . Il a été développé
par John J. Donovan à Ouvrir Environnement Société (OEC), une entreprise des outils qu'il a
fondée en Cambridge, Massachusetts .

Le modèle à trois niveaux est une architecture logicielle et un modèle de

conception logicielle.

Outre les avantages habituels de la modularité du logiciel avec des interfaces

bien définies, l'architecture à trois niveaux est destinée à permettre à toutes les trois niveaux
d'être modernisés ou remplacés indépendamment en réponse aux changements dans les
exigences ou la technologie . Par exemple, un changement de système d'exploitation dans la
couche de présentation ne toucherait le code d'interface utilisateur.
 45

Typiquement, l'interface utilisateur fonctionne sur un ordinateur de bureau pour

PC ou poste de travail et utilise une norme d'interface utilisateur graphique, la logique des
processus fonctionnels peut être constituée d'un ou plusieurs modules séparés fonctionnant sur
un poste de travail ou serveur d'application , et un SGBDR sur un serveur de base de données
ou de mainframe contient la logique de l'ordinateur de stockage de données. Le niveau
intermédiaire peut être multi-niveaux lui-même (dans ce cas, l'architecture globale est appelé
une «architecture n-tiers»).

Architecture à trois niveaux comporte trois niveaux:

 La Couche de présentation

C'est le niveau le plus élevé de l'application. Il communique avec les autres niveaux en
produisant des résultats à la couche navigateur / client et tous les autres niveaux dans
le réseau.

 Le niveau application (logique métier , le niveau logique, le niveau d’accès aux

données, ou niveau intermédiaire)

Le niveau logique est sorti de la couche de présentation et, comme sa propre

couche, il contrôle la fonctionnalité d'une application en effectuant le traitement
détaillé.

 La Couche de données

Ce palier est constitué de serveurs de bases de données. Ici les informations

sont stockées et récupérées. Ce niveau conserve les données neutres et indépendant
des serveurs d'application ou de la logique métier.

La comparaison avec l'architecture MVC

À première vue, les trois niveaux peuvent semblés similaires au concept de

modèle-vue-contrôleur (MVC), mais ils sont typologiquement différents. Une règle
fondamentale est que dans une architecture à trois niveaux le client ne communique jamais
directement avec la couche de données, et dans un modèle à trois niveaux toutes les
communications doivent passer par la couche intermédiaire. Conceptuellement l'architecture à
trois niveaux est linéaire. Toutefois, l'architecture MVC est triangulaire: le point de vue
envoie des mises à jour du contrôleur, le contrôleur met à jour le modèle, et la vue est mise à
jour directement à partir du modèle.

Dans une perspective historique le concept d'architecture à trois niveaux a

émergé dans les années 1990 à partir d'observations des systèmes distribués (par exemple, les
applications web). Alors MVC vient de la décennie précédente (par le travail au Xerox PARC
 45

dans les années 1970 et début 1980) et est basé sur les observations des applications qui
tournaient sur une seule station de travail graphique.

L'utilisation du développement Web

Dans le développement web sur le terrain, le modèle à trois niveaux est souvent utilisé pour
désigner les sites Web , communément les sites internet de commerce électronique, qui sont
construits en utilisant trois niveaux:

1. Un frontal du serveur Web du contenu statique, et éventuellement certains en cache du

contenu dynamique. En application web, Front End est le contenu rendu par le
navigateur. Le contenu peut être statique ou générées dynamiquement.

2. Un traitement de contenu du milieu dynamique et la génération au niveau du serveur

d'application , par exemple Ruby on Rails , Java EE , ASP.NET , PHP , ColdFusion
plateforme.

3. Une arrière-base de données , comprenant deux ensembles de données et le système de

gestion de base de données ou de SGBDR logiciel qui gère et fournit l'accès aux
données.

Autres considérations

Le transfert de données entre les différents niveaux fait partie de l'architecture

et implique plusieurs protocoles ou technologies tels que SNMP , CORBA , Java RMI , . NET
Remoting , Windows Communication Foundation , les sockets , UDP , les services Web ou
autre norme ou de protocoles propriétaires. Souvent un intergiciel est utilisé pour connecter
des gradins séparés.

Traçabilité

La traçabilité de bout en bout des flux de données grâce à des systèmes n-tier
est une tâche difficile, qui devient plus important lorsque le système de complexité est
croissant. L' Application Response Measurement définit les concepts et les APIs permettant
de mesurer la performance et en corrélant les transactions entre les différents niveaux.

1.5.4. Une grappe d’ordinateurs

 45

Figure 4. Image d’une grappe d’ordinateurs

Une grappe d'ordinateurs est constituée d'un ensemble d'ordinateurs

indépendant appelés nœuds connectés afin de permettre une gestion globale et de dépasser les
limitations d’un ordinateurs pour :

 Augmenter la disponibilité
 Faciliter la montée en charge
 Permettre une répartition de la charge
 Faciliter la gestion des ressources (Processeurs, mémoire vive, …)

Les composants d'un cluster sont habituellement reliés les uns aux autres à
travers des réseaux locaux ; chaque nœud exécutant sa propre instance sur un système
d'exploitation . Les grappes d'ordinateurs sont apparues comme un résultat de convergence
d'un certain nombre de tendances de l'informatique, y compris la disponibilité de
microprocesseurs à faible coût, les réseaux haut débit, et les logiciels de haute performance de
calcul distribué .

Les grappes sont généralement déployés pour améliorer les performances et la

disponibilité plus que ce que ferait un seul ordinateur, tout en étant généralement beaucoup
plus rentable que l’ordinateur en question.

a) Les concepts de base

L'approche de clustering informatique en général (mais pas toujours) relie un

certain nombre de nœuds de calcul disponibles (par exemple, les ordinateurs personnels
utilisés comme serveurs) via un réseau rapide local . Les activités des nœuds de calcul sont
orchestrées par «middleware regroupement», une couche logicielle qui se trouve au sommet
des nœuds et permet aux utilisateurs de traiter le cluster comme dans l'ensemble une unité de
calcul cohérent, par exemple via un système à image unique.

Le regroupement informatique repose sur une approche de gestion centralisée

qui rend les nœuds disponibles comme des serveurs orchestrés et partagés. Elle est distincte
des autres approches telles que le peer to peer ou le grid computing , qui utilisent également
de nombreux nœuds, mais avec une nature plus distribuée .
 45

Une grappe d'ordinateurs peut être un simplement représentée par deux nœuds
du système qui relient seulement deux ordinateurs personnels, ou peut être un très rapide
supercalculateur . Une approche de base pour la construction d'un cluster est celle d'un
Beowulf cluster qui peut être construit avec un peu d'ordinateurs personnels pour produire une
alternative rentable au calcul traditionnel de haute performance . Un des premiers projets qui
ont montré la viabilité du concept a été les 133 nœuds Supercomputer pierre. Les
développeurs ont utilisé Linux , la machine parallèle virtuelle et le toolkit Message Passing
Interface bibliothèque pour atteindre la haute performance à un coût relativement faible.

Bien qu’une grappe puisse être constituée de quelques ordinateurs personnels

connectés par un réseau simple, l'architecture de cluster peut également être utilisée pour
atteindre des niveaux de performance très élevés. Le TOP500 liste semestriels organisation
des 500 plus rapides superordinateurs comprend souvent de nombreuses grappes, par
exemple, machine la plus rapide du monde en 2011 a été l' ordinateur de K qui a une mémoire
distribuée , l'architecture cluster.

b) Attributs des grappes

Les grappes d'ordinateurs peuvent être configurées à des fins différentes, allant
du milieu des affaires des besoins d’usage général tels que le web-services de soutien, aux
calculs intensifs des calculs scientifiques. Dans les deux cas, le cluster peut utiliser une
approche de haute disponibilité. Notez que les attributs décrits ci-dessous ne sont pas
exclusifs et un "cluster de calcul" peut également utiliser une approche de haute disponibilité.

Les " Load-balancing "clusters sont les configurations dans lesquelles la charge
de travail part des nœuds du cluster de calcul pour fournir de meilleures performances
globales. Par exemple, un cluster de serveurs web peut attribuer différentes requêtes à
différents noeuds, donc le temps de réponse global sera optimisé. Toutefois, les approches
d'équilibrage de charge peuvent différer significativement entre les applications, par exemple,
un cluster de haute performance utilisés pour les calculs scientifiques serait un équilibrage de
charge avec différents algorithmes à partir d'un cluster de serveur web qui peut simplement
utiliser une simple méthode round-robin en attribuant à chaque nouvelle requête vers un autre
nœud.

Les grappes de calcul sont utilisés pour le calcul intensif fins, plutôt que de la
manipulation OO orienté opérations telles que le service Web ou des bases de données. Par
exemple, un cluster de calcul pourrait soutenir des simulations informatiques de collisions
météorologiques ou d'un véhicule. Très étroitement couplés les clusters de calcul sont conçus
pour des travaux qui peuvent approcher les " supercalculateurs ". Le TOP500 liste semestriels
organisation des 500 ordinateurs les plus rapides comprend souvent plusieurs clusters.

Les grappes à haute disponibilité (aussi connu comme le basculement des

grappes, ou clusters HA) ont été conçus pour améliorer la disponibilité de l'approche cluster.
Ils fonctionnent en ayant des nœuds redondants, qui sont ensuite utilisés pour fournir des
services lorsque les composants du système d'échouer. Les implémentations du cluster HA est
 45

une tentative d'utilisation de la redondance des composants du cluster pour éliminer les points
uniques de défaillance . Il existe des implémentations commerciales de haute disponibilité des
clusters pour plusieurs systèmes d'exploitation. Le Linux-HA projet est celle couramment
utilisée gratuitement le logiciel package HA pour le système d'exploitation linux.

c) Conception et configuration

Un des problèmes résidant dans la conception d'un cluster est comment

étroitement coupler les nœuds individuels.

Les grappes d'ordinateurs ont toujours fonctionné sur des ordinateurs distincts
avec le même système d'exploitation . Mais avec l'avènement de la virtualisation, les nœuds
du cluster peuvent fonctionner sur des ordinateurs physiques séparés avec différents systèmes
d'exploitation qui sont peints au-dessus d'une couche virtuelle. Le cluster peut également être
virtualisé sur les différentes configurations où l'entretien a lieu. Un exemple d'implémentation
est Xen en tant que gestionnaire de virtualisation avec Linux-HA .

d) Partage des données et communication

Comme les grappes d'ordinateurs faisaient leur apparition au début des années
1970, elles étaient donc des superordinateurs . Un des éléments qui distinguait les deux
classes à l'époque était que les superordinateurs au début comptaient sur la mémoire partagée .
Les Grappes n’utilisent pas la mémoire physique généralement partagée, tandis que les
architectures de nombreux superordinateurs ont également abandonné.

Cependant, l'utilisation d'un système de fichiers en cluster est essentielle dans

les grappes d'ordinateurs modernes. Les exemples incluent l' IBM System général Parallel
File , Microsoft volumes partagés de cluster ou le système Oracle Cluster File .

Deux approches sont largement utilisées pour la communication entre les

nœuds du cluster sont MPI, le Message Passing Interface et PVM, la machine parallèle
virtuelle.

La PVM a été développé au Laboratoire national d'Oak Ridge vers 1989 avant
MPI était disponible. PVM doit être directement installé sur chaque nœud de cluster et il
fournit un ensemble de bibliothèques logicielles qui peignent les nœuds comme une «machine
virtuelle parallèle». La PVM offre un environnement d'exécution pour transmission de
messages, des tâches et de gestion des ressources, et la notification par défaut. La PVM peut
être utilisée par les programmes de l'utilisateur écrits en C, C + + ou Fortran, etc.
 45

MPI a émergé au début des années 1990 des discussions entre 40 organisations.
L'effort initial a été soutenue par l'ARPA et par la National Science Foundation (NSA) . Plutôt
que de partir à nouveau, la conception du MPI a attiré l’attention sur les diverses fonctions
disponibles dans les systèmes commerciaux de l'époque. Les spécifications MPI ont ensuite
donné lieu à des implémentations spécifiques. Les implémentations MPI utilisent
généralement le protocole TCP / IP et les connexions sockets. MPI est maintenant un modèle
de communication largement disponible qui permet aux programmes parallèles d'être écrits
dans des langages tels que C , Fortran , Python , etc. Ainsi, contrairement à PVM, qui fournit
une mise en œuvre concrète.

1.5.5. L’architecture orientée service (SOA)

Les Architectures Orientées Service, comme leur nom l’indique, ne

représentent pas une technologie mais une façon de concevoir et de déployer ses applications.
Plus précisément, il s’agit de structurer ses projets selon une approche basée sur le principe de
"services" et non plus, comme par le passé, sur la base d’applications que l’on pourrait
cataloguer, par opposition, de "monolithiques".

La notion de services, utilisée à outrance depuis l’avènement des services web

et l’arrivée des ESB (Enterprise Service Bus), met en avant la capacité des architectures à
faire preuve d’agilité, l’aspect "bus applicatif" ou encore "services distribuables" s’appuyant
fortement sur le concept de mouvement, c'est-à-dire de non localisation physique persistante
des traitements applicatifs.

La notion de SOA sera bien explicitée dans le prochain chapitre car c’est la
technologie que l’on va utiliser pour réaliser notre application de gestion des flux migratoires.
 45

CHAPITRE II : L’ARCHITECTURE ORIENTEE SERVICES [3],

[9], [12], [17], [18], [19], [20]

Le SOA (Service Oriented Architecture) n’est pas une démarche entièrement

nouvelle. L’idée de concevoir des architectures orientée services est née au début des années
1990 avec l’apparition des solutions Client / Serveur.

Aujourd’hui, les besoins d’ouverture du système d’information, les générations

récentes des serveurs d’application (J2EE, .NET) et les Web services (SOAP,
WSDL) donnent une nouvelle importance au SOA.

Il s’agit de bâtir des architectures applicatives adaptées aux serveurs

d’application, capables d’exposer des services interopérables (legacy, progiciels) et de
collaboration entre les entreprises (services métiers).

2.1. DEFINITION

Une architecture orientée services (notée SOA pour Services Oriented

Architecture) est une architecture logicielle s'appuyant sur un ensemble de services simples.

L'objectif d'une architecture orientée services est donc de décomposer une

fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des
composants et de décrire finement le schéma d'interaction entre ces services.

L'idée sous-jacente est de cesser de construire la vie de l'entreprise autour

d'applications pour faire en sorte de construire une architecture logicielle globale
décomposées en services correspondant aux processus métiers de l'entreprise.
Lorsque l'architecture SOA s'appuie sur des web services, on parle alors
de WSOA, pour Web Services Oriented Architecture).
 45

2.2. PRINCIPES GENERAUX D’UNE ARCHITECTURE ORIENTEE SERVICES

Il n'existe pas à proprement parler de spécifications officielles d'une architecture SOA,

néanmoins les principales notions fédératrices que l'on retrouve dans une telle architecture
sont les suivantes :
 La notion de service, c'est-à-dire une fonction encapsulée dans un composant que l'on peut
interroger à l'aide d'une requête composée d'un ou plusieurs paramètres et fournissant une
ou plusieurs réponses. Idéalement chaque service doit être indépendant des autres afin de
garantir sa réutilisabilité et son interopérabilité.
 La description du service, consistant à décrire les paramètres d'entrée du service et le
format et le type des données retournées. Le principal format de description de services est
WSDL (Web Services Description Language), normalisé par le W3C.
 La publication (en anglais advertising) et la découverte (discovery) des services. La
publication consiste à publier dans un registre (en anglais registry ou repository) les
services disponibles aux utilisateurs, tandis que la notion de découverte recouvre la
possibilité de rechercher un service parmi ceux qui ont été publiés. Le principal standard
utilisé est UDDI (Universal Description Discovery and Integration), normalisé par
l'OASIS.
 L'invocation, représentant la connexion et l'interaction du client avec le service. Le
principal protocole utilisé pour l'invocation de services est SOAP (Simple Object Access
Protocol).

2.3. AVANTAGES D’UNE ARCHITECTURE ORIENTEE SERVICES

Une architecture orientée services permet d'obtenir tous les avantages d'une
architecture client-serveur et notamment :
 Une modularité permettant de remplacer facilement un composant (service) par un autre
 Une réutilisabilité possible des composants (par opposition à une système tout-en-un fait
sur mesure pour une organisation).
 De meilleures possibilités d'évolution (il suffit de faire évoluer un service ou d'ajouter un
nouveau service)
 Une plus grande tolérance aux pannes et une maintenance facilitée

2.4. LES CONCEPTS DE BASE DU SOA

2.4.1. SOA et Service

Cadre méthodologique de construction des systèmes d’information et

d’implémentation du logiciel sous la forme de services.
 45

On peut mettre en place du SOA sans utiliser de Web services, ni retenir l’approche objet.

Un service expose une interface qui définit le traitement offert sous la forme
d’un message d’entrée et d’un autre de réponse. Pour son implémentation, le service peut
solliciter une ou plusieurs entités physiques de logiciel. Le service exprime donc un niveau «
logique » d’accès aux traitements et pas un niveau « physique » d’implémentation.

On distingue le concept de service métier spécifié au niveau du cahier des

charges (fonctionnel, métier) et le concept de service issu d’un travail d’architecture
applicative qui prépare l’implémentation des services métiers sous la forme des services.

Propriétés d’un service

Un service est un traitement qui respecte les cinq propriétés que nous détaillons
ci-après : couplage faible, activable à distance et interopérable, asynchrone, expose un contrat
d’utilisation (interface), respecte le pattern d’architecture SOA.

Les propriétés obligatoires sont le couplage faible, l’exposition d’un contrat

d’utilisation et le respect du pattern d’architecture SOA.

a. Un couplage faible

- Un service ne peut pas appeler un autre service. Il délègue cette fonction à un

traitement spécialisé dans l’enchaînement (fonction d’orchestration).

Figure 5. Schéma de Couplage faible d’un service

De manière complémentaire, on associe également la propriété du couplage

faible à l’indépendance de l’activation du service vis-à-vis des technologies
d’implémentation.

- Un service est activable indépendamment de sa technologie. Pour ce faire, l’activation

se réalise par l’envoi (et la réception) d’un message XML.
 45

Figure 6. Schéma d’activation d’un service

- Un service peut être activité suivant un mode asynchrone.

Dans ce cas, le service s’abonne à un événement auprès d’une fonction
d’orchestration.

Figure 7. Schéma d’activation asynchrone d’un service

b. Activation à distance et Interopérabilité

- Un service expose une interface d’utilisation qui est la même indépendamment de sa

localisation sur les réseaux. L’appel au service fonctionne quel que soit le langage et le
système d’exploitation du consommateur. Pour favoriser l’interopérabilité, l’usage des
Web services est intéressant (WSDL-SOAP).

c. Asynchrone

- Un service fonctionne de manière asynchrone. C'est-à-dire qu’il ne bloque pas le

consommateur pendant qu’il s’exécute. Ce principe est intéressant pour réduire les
goulots d’étranglement (performance, robustesse).

d .Exposition d’un contrat d’utilisation

- Un service expose un contrat d’utilisation décrit en deux parties. Une partie abstraite
qui déclare les messages d’entrée et de réponse du traitement offert. Une partie
concrète qui décrit les standards et protocoles techniques utilisés pour l’activation du
service10 : XMLRPC, SOAP-HTTP, SOAP-JMS, protocole binaire… Selon les choix
d’implémentation et de déploiement, il est possible d’avoir plusieurs parties concrètes
pour une même partie abstraite. On nomme aussi le contrat d’utilisation par le terme
d’interface de service.
 45

e. Respect du pattern de l’architecture SOA

- Le pattern d’architecture SOA consiste à créer une architecture applicative qui

décompose les traitements sous la forme de services rattachés à des paquets de classes.
Ces paquets forment des Catégories (objet métier, sujet métier), chacune dotée d’une
façade d’accès qui contient l’ensemble des services qu’elle expose (on parle aussi de
port). Un service a le droit d’interagir uniquement avec les classes de sa catégorie. En
SOA, l’encapsulation ne se fait pas uniquement au niveau le plus élémentaire de la
classe mais aussi au niveau supérieur des catégories UML.

Différence entre un Service et un Service Métier

Figure 8. Schéma différence entre un service et un service métier

La relation de service

L’architecture orientée services (AOS) est le terme utilisé pour désigner un

modèle d’architecture pour l’exécution d’applications logicielles réparties.

Ce modèle d’architecture prend forme au cours de l’activité pluriannuelle de

spécification des architectures de systèmes répartis, développée dans des contextes aussi
variés que ceux de :

 l’Open Group (Distributed Computing Environment ou DCE ) ;

 l’Object Management Group (Object Management Architecture/Common Object

Request Broker Architecture ou OMA/CORBA) ;

 l’éditeur de logiciels Microsoft (Distributed Component Object Model ou DCOM).

Les deux derniers modèles (CORBA et DCOM) relèvent de l’architecture par

composants logiciels répartis plutôt que de l’architecture orientée services, et le terme «
service » est généralement absent de leur terminologie (sauf, par exemple, dans CORBA où
l’on parle de services CORBA à propos de fonctions offertes par la plate-forme de
middleware aux composants applicatifs).
 45

L’activité des composants est qualifiée incidemment d’activité de prestation de

services pour les autres composants de l’architecture, mais le concept de composant logiciel
est primaire (de « première classe ») alors que le concept de service est secondaire et
dépendant de celui de composant.

Les préoccupations essentielles de ces modèles sont :

 la standardisation du mécanisme d’invocation de traitements distants (DCE, CORBA,

DCOM) ;

 la transparence de la localisation des composants dans un système réparti (CORBA,

DCOM).

Des travaux plus récents, comme ceux réalisés autour de Jini (Sun
Microsystems), Biztalk (Microsoft) et surtout e-Speak (Hewlett-Packard), première plate-
forme orientée services bâtie sur les technologies XML, ont permis l’émergence du concept
de service qui offre un degré d’indépendance par rapport au concept de composant logiciel.

Par ailleurs, l’émergence des technologies de services Web consolide un

modèle d’architecture dans laquelle le concept de service joue le rôle primaire alors que le
concept de composant logiciel (qui met en oeuvre le service) est réduit à un rôle dépendant,
banalisé et interchangeable. En outre, le concept même de middleware disparaît de
l’architecture : les applications réparties n’ont pas besoin d’un système de middleware réparti
commun pour communiquer, mais seulement de mettre en œuvre des protocoles et des
technologies de communication interopérables sur Internet.

Les éléments du service

Une application logicielle qui exerce une activité dont les résultats sont
directement ou indirectement exploitables par d’autres applications, éventuellement réparties
sur un réseau, joue le rôle de prestataire de services. L’ensemble des résultats exploitables de
l’activité est appelé prestation de services, et les applications qui en bénéficient jouent le rôle
de client du service. Les termes « prestataire » et « client » correspondent à des rôles
interprétés par les applications dans la relation de service. Une application peut être en même
temps prestataire de plusieurs services distincts et cliente de différents services.

Le rôle du client et du prestataire

Une difficulté importante que l’on rencontre dans la maîtrise du modèle de

l’architecture orientée services est la compréhension de la nature des rôles que sont ceux de
client et de prestataire de services.

En effet, ce modèle s’applique, au-delà des architectures client/serveur, aux

architectures réparties peer-to-peer, c’est-à-dire à des architectures réparties dans lesquelles il
n’y a pas a priori de limitation de rôles pour les applications constituantes.

Une application qui fait partie d’une architecture orientée services peut être
impliquée dans plusieurs relations de services et interpréter en même temps plusieurs rôles de
client et plusieurs rôles de prestataire.
 45

Une architecture orientée services est donc une fédération de services, à savoir
une architecture d’applications réparties qui participent à un réseau d’échange de services.

Nous appellerons par la suite une application qui a la capacité d’interpréter au

moins le rôle de prestataire ou de client d’au moins une relation de service, une application
orientée services.
Le contrat de service

La description d’une relation de service est formalisée par un contrat de

service. Ce contrat décrit les engagements réciproques du prestataire et du client du service.
Toute application pouvant satisfaire les engagements du prestataire (et, réciproquement toute
application pouvant satisfaire les engagements du client) peut interpréter le rôle de prestataire
(et, réciproquement, le rôle du client).

Lorsqu’un contrat régente une relation de service, la réalisation de la prestation

de services réside dans l’exécution du contrat.

2.4.2. Web Service

C’est une technologie d’interopérabilité entre des systèmes distribués et

hétérogènes mettant en œuvre XML et SOAP comme formats standards d’échange des
messages. Il est fortement recommandé de mettre en place SOA lorsque l’on construit des
Web services.

2.4.3. Approche Orientée Objet

C’est une méthodologie de construction des systèmes d’information et

d’implémentation du logiciel sous la forme d’objets. SOA et approche objet sont
complémentaires. En effet, on utilise un principe de décomposition du service sous la forme
de méthodes attachées à des objets.

2.4.4. Le composant

C’est l’élément logiciel exécuté par un serveur d’application. Par exemple,

dans l’infrastructure J2EE, un composant est un EJB, un javabeans, une servlet ou une classe
RMI.

Cette définition est différente de celle retenue dans l’approche basée sur les
composants (Component-Based Development). En effet, en CBD, le composant peut être
implémenté dans différentes technologies et exprime donc aussi un niveau logique de
représentation des traitements.
 45

En SOA, on distingue clairement les deux niveaux logique et physique : le service est le
concept du niveau logique, le composant est le concept physique d’implémentation.

Différence entre un Service et un Composant

Figure 9. Schéma différence entre un service et un composant

2.5. DEFINITION DES ROLES

- Le Fournisseur

Le fournisseur de services est l’organisation qui délivre un service.

- Le Consommateur

Le consommateur de service est l’organisation qui consomme un service, c'est-

à-dire qui implémente son contrat d’utilisation (Interface au sens d’une API ou d’un WSDL
pour un Web service par exemple) dans son système. Lorsqu’il s’agit de l’utilisation d’un
service métier (usage métier), le consommateur est souvent nommé « organisation cliente ».

2.6. LES APPORTS DU SOA

2.6.1. Les apports métiers

 45

Le SOA favorise la découverte et la spécification de services métiers au niveau

de la modélisation des processus. Il permet d’appréhender de manière rationnelle la notion «
d’entreprise étendue »:

- L’entreprise expose des services métiers à des organisations tierces.

- L’entreprise intègre dans son propre système d’information des services offerts par d’autres.

La SOA s’appuie sur des outils de management dont certaines fonctionnalités

sont directement destinées aux Maîtrises d’Ouvrage, par exemple pour agir sur le paramétrage
des services métiers et sur l’administration des contrats d’utilisation des services. Le niveau
d’implication des MOA lors de la spécification des services métiers mais aussi en exploitation
courante est un point déterminant du SOA. Il est très important de noter (Février 2005) que les
entreprises perçoivent l’intérêt du SOA dans un contexte d’usage multi-points des services
métiers. La figure suivante illustre ce mode d’usage. Dans ce contexte, il convient
d’appréhender correctement la mutualisation de certains développements, la gestion des
versions (favoriser la compatibilité ascendante par exemple) et suivre l’exploitation afin de
ventiler les dépenses auprès des consommateurs.

2.6.2. Les apports techniques

Le SOA permet :

- de rationaliser les développements orientés objets en apportant une structuration du

logiciel au dessus des arbres de classes via les catégories et les façades.

- de contrôler les risques de couplage fort entre les méthodes des classes. Plus
précisément, le couplage entre les méthodes n’est possible que dans le périmètre d’une
catégorie.

- d’intégrer un modèle d’architecture en couches (N-Tiers) indispensable pour la qualité

du logiciel.

- de tenir compte des besoins d’intégration du legacy et d’interopérabilité entre les

plateformes J2EE et .NET notamment en cas d’implémentation par les Web services.

- d’augmenter la flexibilité et la robustesse générale du logiciel par la création d’une

architecture applicative dont les services se projettent de manière adaptée dans
l’infrastructure technique (J2EE, .NET) et qui favorise la réutilisation. Par exemple en
J2EE, il s’agit de déterminer les règles de projection des services en composants EJB,
Servlet, javabeans…mais aussi en Web services (SOAP-XML).

2.7. PRESENTATION GENERALE DU PROTOCOLE SOAP

 45

2.7.1. Présentation et Fonctionnement de SOAP

SOAP (Simple Object Access Protocol) est un protocole d’invocation de

méthodes sur des services distants. Basé sur XML, SOAP est un format de communication
pour assurer communication de machine à machine. Le protocole permet d’appeler une
méthode RPC (Remote Procedure Call) et d’envoyer des messages aux machines distantes via
HTTP. Ce protocole est très bien adapté à l’utilisation des services web car il permet de
fournir au client une grande quantité d’informations récupérées sur un réseau de serveurs
tiers.

La version actuelle de SOAP est la 1.1. Cette version a été proposée au W3C
en 2000 par UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA,
Lotus, Microsoft, SAP. Le W3C travaille actuellement sur la version 1.2 de SOAP, elle
devrait sortir fin 2002 et à pour but de supprimer l’utilisation des RPC au profit des messages.

SOAP permet donc l’échange d’information dans un environnement

décentralisé et distribué, comme Internet par exemple. Il permet l’invocation de méthodes, de
services, de composants et d’objets sur des serveurs distants et peut fonctionner sur de
nombreux protocoles (des systèmes de messagerie à l’utilisation de RPC). Cependant, il
fonctionne particulièrement bien avec le protocole HTTP, protocole très souvent utilisé avec
SOAP.

SOAP utilise les protocoles HTTP et XML. HTTP comme mécanisme

d’invocation de méthodes en utilisant un des balises spécifiques pour indiquer la présence de
SOAP comme « <SOAP-ENV> ». Cela permet de franchir aisément les firewalls et proxy et
facilite le traitement en cas de filtrage. XML pour structurer les requêtes et les réponses,
indiquer les paramètres des méthodes, les valeurs de retours, et les éventuelles erreurs de
traitements.

XML joue un rôle prépondérant dans SOAP, on peut distinguer plusieurs

éléments :

- une enveloppe, expliquant comment la requête doit être traitée et présentant les
éléments contenus dans le message.

- un ensemble de règles de codage, permettant de différencier les types de données

transmises.

- une convention de représentation, permettant de représenter les appels aux

procédures de traitement et les réponses.
 45

Même si SOAP ressemble beaucoup en termes de fonctionnalités à des

protocoles comme IIOP pour CORBA, ORPC pour DCOM, ou JRMP (Java Remote Method
Protocol) pour JAVA, il possède un avantage indéniable.
En effet, SOAP utilise un mode texte alors que les autres fonctionnent en mode binaire, cela
facilite le passage des équipements de sécurité.

2.7.2. Présentation et Fonctionnement des Web Services

a. Présentation

Les Web services permettent de faire communiquer deux sous-systèmes

ensemble et cela indépendamment des architectures utilisées. Ces systèmes vont pouvoir
s’échanger des services ou des traitements applicatifs.

Les Web services constituent un moyen de distribuer un service de manière

standard grâce à XML tout en respectant un modèle de développement ayant déjà fait ses
preuves comme CORBA ou DCOM (Microsoft). Un des avantages des Web services est de
regrouper tous les acteurs derrière un seul et même standard.

b. Fonctionnement

Pour expliquer le fonctionnement des web services, il convient de distinguer

plusieurs étapes :

 Recherche dans un annuaire UDDI : le client cherche un service particulier, il

s’adresse à un annuaire qui va lui fournir la liste des prestataires habilités à
satisfaire sa demande. L’annuaire UDDI peut être comparé à un moteur de
recherche sauf que les documents sont remplacés par des services.

 Recherche de l’interface du composant à contacter : une fois la réponse reçue (en

XML) de l’annuaire, le client va chercher à communiquer via une interface. Cette
interface décrite en langage WSDL fournit l’ensemble des services disponibles.
Elle offre la possibilité de vérifier que le contrat correspond bien aux besoins
demandés.

 Invocation du service : le client doit maintenant passer les paramètres attendus par
le service et assurer la communication avec le serveur. L’outil utilisé pour cela est
le Proxy, c’est l’objet qui permet la communication entre le client et le serveur. Il
est généré par le client en utilisant l’interface WSDL.

2.7.3. Le protocole WSDL

 45

WSDL (Web Service Definition Langage) est un format de représentation des

interfaces de services Web en XML. Une analogie avec CORBA peut être faite, en effet
WSDL est la représentation XML du langage IDL (description d’interfaces).

WSDL a deux rôles prépondérants:

 Il sert de référence à la génération de Proxies.

 Il assure le couplage entre le client et le serveur par le biais des interfaces.

2.7.4. Le protocole UDDI

UDDI (Universal Description Discovery and Integration) est un protocole basé

sur XML qui sert à la publication et à l'exploration d'annuaires de Web Services. Il permet de
situer un service Web, de le décrire, et de l’intégrer. Ce protocole a été réalisé par IBM,
Microsoft et Ariba. Cependant UDDI est assez complexe et a été qualifié par certains «
d’usine à gaz ». C’est la raison pour laquelle IBM et Microsoft travaille actuellement sur un
autre protocole d’annuaire de services : Web Services Inspection (WS-Inspection). L’objectif
de WS-Inspection est de permettre à une entreprise de décrire facilement les services Web
dont elle dispose.

2.7.5. Différence entre IIOP et SOAP

IIOP (Internet Inter-ORB Protocol) est un protocole de transfert de méthode

utilisé par CORBA. Il définit le format des messages échangés entre la machine cliente et la
machine serveur. IIOP va permettre d’envoyer et de recevoir des types complexes de données.
Les clients et serveurs peuvent employer n’importe quel mélange de langages et de
plateformes. IIOP est un protocole très complet qui est capable d’effectuer tous les transferts
exigés par SOAP. Cependant l’utilisation de SOAP peut être parfois préférable pour plusieurs
raisons.

Tout d’abord, l’utilisation de IIOP nécessite de compiler et distribuer des

souches clients pour chaque type de clients avec qui l’on communique. Ce n’est évidemment
pas très pratique, en particulier quand le nombre de plateformes différentes ou de langages
différents est important.

Dans le cas des services web, IIOP va poser des problèmes pour le
franchissement des équipements de filtrage (firewall, proxy). Cela va demander un travail en
plus de la part de chaque personne administrant l’équipement. Au contraire, l’utilisation de
SOAP ne pose absolument pas de problèmes au niveau des firewalls. SOAP étant un
protocole utilisant HTTP, il y a peu de chance qu’il soit bloqué lors d’un filtrage. Evidemment
 45

CORBA, au travers de IIOP, est plus performant : il y a moins de données transitant sur le
réseau, et les opérations de conversion / dé conversion sont traitées plus rapidement.
Cependant avec SOAP les données circulent en format texte et en clair sur le réseau. Leur
lecture en est donc facilitée et le débogage est beaucoup plus simple.

SOAP est donc un très bon protocole si l’on cherche à dialoguer avec des
plateformes hétérogènes, ce qui est particulièrement le cas dans toutes les applications de type
« Web Services ». En fait, l’utilisation de CORBA ou de SOAP va surtout dépendre de ce que
l’on doit faire : dans le cas des webservices SOAP semble être une bonne solution, par contre
si l’on souhaite faire des applications distribuées classiques comme du calcul distribué, on
choisira plutôt CORBA.

2.7.6. Protocoles utilisés par SOAP

SOAP se sert le plus souvent de deux protocoles : HTTP et XML.

Un message SOAP est écrit en XML. HTTP est utilisé comme protocole de
transport.

Les messages SOAP vont donc être encapsulés dans HTTP, ce qui permet une
utilisation et une compatibilité très importante avec les réseaux et équipements existants.
HTTP est le protocole de transport le plus utilisé mais il n’est pas impossible de trouver des
implémentations de SOAP sur d’autres protocoles (avec SMTP par exemple).

Un message SOAP est un document XML qui possède une enveloppe SOAP et
éventuellement une déclaration XML. L’enveloppe SOAP est composée d’un corps SOAP et
éventuellement d’un en-tête.

Les règles de syntaxe sont les suivantes :

o Un message SOAP MUST être codé en XML

o Un message SOAP MUST avoir une enveloppe SOAP
o Un message SOAP CAN avoir un entête SOAP (header)
 45

o Un message SOAP MUST avoir un corps SOAP (body)

o Un message SOAP MUST utiliser l’espace de désignation de l’enveloppe
SOAP
o Un message SOAP MUST utiliser l’espace de désignation d’encodage SOAP
o Un message SOAP MUST NOT contenir une référence à une DTD
o Un message SOAP MUST NOT contenir des instructions de type XML
Processing

Figure 10. Structure d’un message SOAP

2.7.7. Problèmes posés par SOAP

Ces problèmes concernent principalement l’interopérabilité des messages

SOAP de type RPC. La plupart des problèmes posés par SOAP ne concernent pas directement
le protocole lui-même mais plutôt les protocoles utilisés, comme XML ou HTTP. Ils peuvent
être divisés en trois catégories :

- problèmes http
- problèmes XML
- problèmes liés au protocole SOAP

a) Problèmes HTTP

HTTP est utilisé pour le transport des messages SOAP en XML. Or certaines
balises spécifiques à SOAP ne vont pas être bien interprétées par tous les clients HTTP. Cela
va dépendre du client et ne pas fonctionner dans certains cas. On peut prendre l’exemple de la
fonction SOAPAction : la valeur de SOAPAction doit être en guillemets sauf s’il s’agit d’une
valeur nulle.
Exemple : « SOAPAction: http://test.org/ » ou « SOAPAction: »
 45

Cependant certains clients ne sont pas capables de fournir une valeur d’entête
HTTP nulle, si le serveur en attends une, l’appel ne fonctionnera pas.

b) Problèmes XML

Les problèmes d’interopérabilité XML concernent l’analyse du langage XML.

SOAP repose sur l’utilisation de ce langage, donc si XML pose des problèmes
d’implémentations, ceux-ci vont poser des problèmes sur SOAP.

c) Problèmes liés à SOAP

En lui-même, SOAP est relativement simple ; il requiert que les messages

soient placés dans une enveloppe avec le texte du message inclus dans un élément du corps.
Cependant il existe un certain nombre de problèmes d’interopérabilité comme par exemple le
problème lié à l’implémentation de l’attribut « mustUnderstand ». Les spécifications de SOAP
indiquent que si cet attribut est défini sur la valeur « 1 », il devra être traité. Pourtant certaines
implémentations de SOAP ne le font pas (principalement les premières à avoir été
développées). De nombreux autres problèmes d’interopérabilité ont été découverts, ils sont
consultables sur le forum http://groups.yahoo.com/group/soapbuilders. Cette liste contribue
grandement à l’amélioration du protocole.

2.7.8. Les fichiers WSDL

Afin des décrire les services disponibles sur un serveur, un langage de

description de service a été mis en place : le WSDL (Web Service Description Langage). Ce
langage est basé sur XML. Les fichiers WSDL contiennent donc la description de l’accès à
des Web services ainsi que des messages qui seront échangés avec les services en question.
(Arguments, types de donnée…). Une fois muni de cette description, appelée aussi parfois «
contrat », le client va pouvoir dialoguer avec les services de manière adéquate. On peut par
exemple générer automatiquement à partir du fichier WSDL un client ou un proxy pour ce
service.

Pour comprendre les différentes zones d’un descripteur WSDL, le schéma

suivant où se situe les différents éléments décrits dans un fichier WSDL.
 45

Figure 11. Les différents éléments décrits dans un fichier WSDL

Un fichier WSDL commence par <definition> et finit par </definition>. C’est à

l’intérieur de cette espace que l’on va déclarer tous les éléments constituant la description.
Nous allons prendre l’exemple du Web Service de Google pour montrer comment se construit
un fichier WSDL.

a) Services

Un service est la mise à disposition d’une ou plusieurs méthodes. On peut

imaginer par exemple une classe avec plusieurs méthodes invocables à distance. La classe
sera le service, et chaque méthode sera une opération sur ce service. La définition d’un service
se fait par l’utilisation de <service></service>.

b) Port

Pour chaque service on va définir des ports par lesquels ce service sera
disponible. En effet, il est possible de rendre disponible un service sur plusieurs supports
différents : HTTP GET, SOAP, SMTP…

c) Message

Les messages sont les éléments échangés entre le client et le serveur lors d’une
opération sur le port d’un service. Ces messages sont constitués de plusieurs parties (part) qui
représentent chacune une donnée avec un type associé.
 45

Ainsi, il est possible définir ses propres types en se basant sur les types de base.

d) Port type et Opération

Une méthode peut être représentée par une opération qui prend un en entrée et
renvoie un message en sortie. Ainsi chaque opération est représentée par
<operation></operation> indique le flux de message en entrée et en sortie correspondant en
définissant les éléments <input/> et <output/>.

Enfin, la collection de toutes les opérations d’un service est rassemblé dans un
Port type.

e) Binding

Enfin, pour compléter la description, il faut relier certains éléments entre eux.
C’est le rôle des bindings représentés par les balises <binding></binding>. On va spécifier
notamment tout ce qui concerne l’encodage des données dans les messages en indiquant les
règles que l’on utilise
 45

CHAPITRE III : MODELISATION DU PROCESSUS DE FLUX

MIGRATOIRES AERIENS [2], [7], [8], [14], [21]

3.1. INTRODUCTION

Dans ce chapitre il sera question de concevoir une architecture orientée

services pour la gestion des flux migratoires aérien dans la république démocratique du
Congo.

Pour se faire on aura à modéliser les opérations effectuée par une agence de
voyage, une compagnie aérienne et la Direction Générale de Migration dont le rôle est de
gérer les immigrants et les émigrants de la République Démocratique du Congo.

3.2. PRESENTATION DES ROLES ESSENTIELS DE NOS TROIS SYSTEMES

Dans cette section, il est question de présenter les rôles essentiels de nos trois
systèmes en fonction de l’application à réaliser.

3.2.1. L’agence de voyage

L’agence de voyage n’est qu’un sous-ensemble d’une société aérienne

quelconque. L’agence de voyage vend les billets de plusieurs sociétés sans pour autant savoir
les différentes recettes que la société aérienne a faites durant toute la journée. Par contre, la
société aérienne a un accès total sur toutes les recettes du jour de l’agence.

L’agence de voyage n’est pas obliger de vendre seulement les billets d’une
seule compagnie aérienne, elle présente aux clients les prix de plusieurs compagnies aériennes
et le client pourra choisir le prix le plus bas pour se procurer du billet. D’où l’agence de
voyage a le monopole de vente. Tandis que dans une compagnie aérienne on ne peut vendre
que les billets d’avion de cette seule compagnie non pas d’autres.

3.2.2. La Direction générale de Migration (DGM)

Conformément au Décret-loi n° 002/003 du 11 mars 2003, la Direction

Générale de Migration, D.G.M en sigle, est un service public de l'Etat Congolais doté d'une
autonomie administrative et financière.

Ses missions sont les suivantes :

• L'exécution de la politique du Gouvernement en matière d'immigration

• L'exécution sur le sol congolais des lois et règlement sur l'immigration et l'émigration
 45

• La Police des Etrangers,

• La Police des Frontières entendue comme la régulation des entrées et des sorties du
territoire national,
• La délivrance des passeports ordinaires aux nationaux et des visas aux étrangers,
• La collaboration dans la recherche des criminels et malfaiteurs ou des personnes suspectes
signalées par l'Organisation Internationale de la Police Criminelle Interpol.

Cependant, il est à noter qu'à ce jour, le passeport ordinaire est encore délivré
par le Ministère des Affaires Etrangères et de la Coopération Internationale.

Aux termes de la Loi, la Direction Générale de Migration exerce ses activités

sur l'ensemble du territoire national et dans les Chancelleries près les Missions diplomatiques
de la RDC à l'étranger. Mais, l'affectation des officiers de Migration dans les Chancelleries
près des missions diplomatiques n'est pas encore effective.

3.2.3. La Compagnie Aérienne d’Aviation

Une compagnie d’aviation a pour rôle de proposer ses horaires des vols à partir
desquelles les clients vont faire des réservations. Son rôle est aussi d’assurer aux passagers un
voyage sécurisé vers la destination souhaitée bien sûre en se servant de ses avions. Elle est
censée aussi de bien veiller sur les bagages des passagers.

3.3. SPECIFICATIONS INITIALES DU SYSTEME

Le projet consiste à créer un système de gestion des immigrants et des
émigrants à partir de l’aéroport. Il devra être capable de déterminer toutes les entrées et toutes
les sorties par jour. Il devra se baser sur l’identification automatique des passagers, leur
contrôle et le renouvellement de leur séjour.

3.4. ELABORATION D’UN CONCEPT

Dans ce paragraphe on essaiera de répondre aux questions ci-après :

- A qui l’application est-elle destinée ?

L’application est destinée à la Direction Générale de Migration, aux Agences des
voyages et aux Compagnies d’aviation.

- Quels problèmes l’application résoudra –t-elle ?

L’application résoudra le problème d’identification instantanée des émigrants et des
immigrants à l’aéroport ainsi que la diffusion de ces informations à travers toute la
République, la réservation des vols côté agence de voyage et la proposition des vols de
la part des compagnies aériennes.

- Quels sont les conditions d’utilisation du système ?

L’application n’est utilisé que pour identifier les immigrants et les émigrants à travers
la République afin saisir en justice ceux qui sont suspects ou problématiques ainsi que
les réservations et les vols.
- Pourquoi l’application est-elle attendue ?
 45

Vue la difficulté qu’éprouve la DGM à avoir les informations instantanée de toutes les
entrées et sorties à travers la République, notre application se pointe à l’horizon au bon
moment.

3.5. DIAGRAMMES UML

3.5.1. Le diagramme de cas d’utilisation

A. Le cas d’utilisation pour la réservation

Le processus de réservation d’un vol par le client dans l’agence de voyage se

présente comme suit :

« Le client se présente dans une agence et demande s’il est possible de réserver des places
pour un vol donné. L’employé de l’agence de voyage vérifie dans le site d’une des
compagnies d’aviation pour voir si réellement il y a des places. S’il y en a la compagnie
d’aviation va signaler à l’employé et ce dernier va le communiquer au client. Le client va
ensuite demander à l’employé de faire une réservation pour un certain nombre de places.
Celui-ci fera une réservation que la compagnie d’aviation devrait confirmer. Si c’est fait alors
l’employé de l’agence va donner au client le(s) billet(s) synonyme(s) de place dans l’avion ».

Cas Réservation

Résumé Procédure de réservation décrite ci-haut jusqu’à la délivrance du

billet de vol

Acteur primaire Le client

Acteurs secondaires L’employé de l’agence de voyage, la compagnie aérienne

Pré-condition Vérification des places pour le vol demandé

Résultat Billet d’avion

Exception Pas de délivrance du billet d’avion s’il n’y a pas de place

correspondant à la demande du client

Description 1. Le client présente sa demande

2. L’employé de l’agence envoi cette demande à la compagnie
d’aviation
3. La compagnie d’aviation répond affirmativement à la requête de
l’agence

…
 45

Tableau 1 : Tableau des scenarii du processus de réservation

En fonction des données ci-dessus on a le diagramme de cas d’utilisation
suivant pour l’opération de réservation :

Agence de voyage
c
Effectuer une réservation

Obtention du billet

Client

Délivrance du billet

Confirmation de la possibilité de réservation

Employé de l’agence
Envoi de la requête de réservation

Confirmation de la réservation

Compagnie
Aérienne
Possibilité de réservation

Figure 12 : Diagramme de cas d’utilisation de réservation d’un vol

 45

B. Le cas d’utilisation pour le contrôle des immigrants et des émigrants

Le processus de contrôle se présente comme suit : « A l’aéroport, un agent de la DGM est

présent pour enregistrer ceux qui entrent et ceux qui sortent de la république. Les passagers
entrants ou sortants doivent présenter leurs passeports pour le contrôle. Pour les passagers qui
sortent de la république, il y appose un caché de sortie et enregistre l’utilisateur tandis que
pour les passagers qui entrent, il y appose un caché d’entrée. Ceux qui entrent sont appelés
immigrants tandis que ceux qui sortent sont appelés émigrants ».

Cas Réservation

Résumé Procédure de contrôle des immigrants et émigrants du début

jusqu’à la fin

Acteur primaire Agent de la DGM

Acteurs secondaires Les immigrants et les émigrants

Pré-condition Présentation du passeport

Résultat Caché de sortie ou d’entrée

Exception Pas de caché s’il n’y a pas de passeport ou si le visa n’est pas
valable

Description 1. Le passager présente son passeport

2. L’agent de la DGM contrôle le passeport
3. Il y appose un caché de sortie ou d’entrée selon le cas et il
enregistre le passager.

Tableau 2 : Tableau des scenarii du processus de contrôle des passagers

On a le diagramme de cas d’utilisation suivant :

 45

Aéroport

Présenter passeport

Contrôler passeport Emigrant

Immigrant

Apposer caché d’entrée

DGM
Enregistrer passager

Apposer caché de sortie

Figure 13 : Diagramme de cas d’utilisation pour le contrôle des passagers

 45

3.5.2. Le diagramme d’activité

A. Diagramme d’activité pour le cas de réservation

Demande de
Réservation

Vérification de la demande

[Pas de place]

[Places disponibles dans

une Compagnie]

[Passeport invalide]
Vérification du passeport

Réservation
[Passeport valide]

Confirmation de
la réservation

Délivrance du billet d’avion

Figure 14 : Diagramme d’activité pour le cas de réservation

 45

B. Diagramme d’activité pour le cas contrôle des immigrants et des émigrants

Présentation du passeport par le passager

Contrôle du passeport

[Passeport invalide]

[Passeport valide]

Détermination du mouvement du passager

[Mouvement entrant] [Mouvement sortant]

Emigrant
Immigrant

Apposition du caché de sortie

Apposition du caché d’entrée

Enregistrement du passager
Enregistrement du passager

Figure 15 : Diagramme d’activité pour le contrôle des passagers

 45

3.5.3. Le diagramme de séquence

A. Diagramme de séquence pour le cas de réservation

Compagnie
Aérienne
Client Employé de l’agence

Demande d’une réservation

Envoi de la requête de la demande

Possibilité de réservation
Confirmation de la possibilité de
réservation

Réalisation d’une réservation

Envoi de la requête de la réservation

Confirmation de la réservation
Délivrance du billet

Figure 16 : Diagramme de séquence pour le cas de réservation

 45

A. Diagramme de séquence pour le cas de contrôle des immigrants ou

émigrants

Passager Agent DGM

Présentation du passeport

Contrôle du passeport

Apposition du caché

Remise du passeport

Figure 17 : Diagramme de séquence pour le cas de contrôle des passagers

3.5.4. Le diagramme d’états-transitions

 Cas d’une réservation

Annulation

Confirmée Annulée

Confirmation

Figure 18 : Diagramme d’états pour la réservation

 45

 Cas d’un vol

Fermeture

Ouvert Fermé

Ouverture

Figure 19 : Diagramme d’états pour le cas d’un vol

3.5.5. Le diagramme de classe

Par rapport aux tâches ci-dessus on le diagramme de classe ci-dessous :

On peut recenser les opérations suivantes concernant la réservation de vol d’un

client dans une agence de voyage :

 Des compagnies aériennes proposent différents vols : les compagnies aériennes

prédéfinissent déjà à l’avance les différentes destinations de leurs avions.

 Un vol est ouvert à la réservation et fermé sur ordre de la compagnie

 Un client peut réserver un ou plusieurs vols, pour des passagers différents : Ici il faut
retenir que le client c’est celui qui vient faire la réservation et le passager est celui qui
monte dans l’avion le jour du vol.

 Un client est caractérisé par le nom, post-nom et prénom du passager, sa date de

départ, sa date de retour (dans le cas d’un vol aller-retour), son numéro de téléphone,
sa compagnie aérienne et spécialement pour les clients qui veulent faire une
réservation pour les USA, un passeport dans lequel on va vérifier le numéro du
passeport, la validité du passeport, ainsi que sa date d’expiration.

 Une réservation concerne un seul vol, et un seul passager

 Une réservation peut être annulée ou confirmée : Ces deux opérations ne dépendent
pas de l’agence de voyage mais plutôt de la compagnie d’aviation

 Un vol a un aéroport de départ et un aéroport d’arrivée.

 Un vol est caractérisé par un jour de départ, un jour d’arrivée, une date de départ, une
date d’arrivée, le type d’appareil ainsi que la destination.
 45

 Un vol peut comporter des escales dans des aéroports

 Une escale a une heure d’arrivée et une heure de départ.
 Chaque aéroport dessert une ou plusieurs villes
 Un immigrant ou un émigrant est un passager
 Un agent de la DGM contrôle un ou plusieurs passeports
 Un passager possède un passeport

On a le diagramme de classe complet ci-dessous :

Client CompagnieAerienne
id_client code_compagnie
nom_client nom_compagnie
postnom_client
date_depart
date_retour
 1…*
type_vol

45

propose
1

a effectué

1…*
0…* arrivé
Vol e
Reservation date_depart 0…* 1 Aeroport
date 0…* 1 date_arrivée nom_aeroport
numero type_appareil départ
nom_agence adresse
adresse_agence concerne destination
0…* 1
Annuler () prix_billet
Confirmer ()
OuvrirVol () 0…* 1 1
FermerVol ()
1 {Ordered} dessert
concerne
InfosEscale 1…*
1…* heure_arrivée Ville
Passager heure_depart nom_ville
id_passager 1
nom_passager
postnom_passager
possède

1 DGM
1
matricule_agent
Immigrant Emigrant Passeport nom_agent
date_entrée date_sortie postnom_agent
heure_entrée heure_sortie num_passeport ApposerCache()
description description date_expiration
caché_entrée caché_sortie periode_validite
contrôle

1…*
Figure 20 : Diagramme de classe du système
 45

CHAPITRE IV : DEVELOPPEMENT DE L’APPLICATION DE

GESTION FLUX MIGRATOIRE aerien [6], [10], [21], [22]

Dans ce chapitre on va décrire les différentes étapes d’implémentation de notre

application qui au final un service web hébergé dans un serveur web et se connectant à une
base des données SQL Server 2008 précisément. Ce service web est en sorte une plateforme
permettant à nos trois parties qui sont Agences de voyages, Compagnies Aériennes et
Direction Générale de Migration de pouvoir se communiquer en vue d’obtenir une seule
plateforme gérant les mouvements migratoires aériens de la population à travers la RDC.

4.1. PRESENTATION DES DIFFERENTS OUTILS DE DEVELOPPEMENT

4.1.1. Le Système de gestion de base des données (SGBD) utilisé

Nous avons porté notre choix sur SQL SERVER 2008 Edition Express.
L’implémentation des différentes tables sous SQL SERVER est présentée par les différentes
requêtes SQL ci-dessous :

 Table CompagnieAerienne
create table CompagnieAerienne (code_compagnie int primary key,
nom_compagnie varchar(50) not null);

 Table Client
create table Client (id_client int primary key, nom_client
varchar(50) not null, postnom_client varchar(50) not null,
date_depart date not null, date_retour date not null, num_tel
varchar(20) not null, type_vol varchar(15) not null);

 Table Aeroport
create table Aeroport (nom_aeroport varchar(50) primary key,
adresse varchar(50) not null);

 Table DGM
create table DGM (matricule_agent varchar(5) primary key,
nom_agent varchar(50) not null, postnom_agent varchar(50) not
null);

 Table Ville
create table Ville (nom_ville varchar(50) primary key,
nom_aeroport varchar(50) references Aeroport(nom_aeroport));
 45

 Table Passeport
create table Passeport (num_passeport int primary key,
date_expiration date not null, periode_validite int not null,
matricule_agent varchar(5) references DGM(matricule_agent));

 Table Vol
create table Vol (id_vol int primary key, date_depart date not
null, date_arrivee date not null, billet bigint not not null,
type_appareil varchar(50) not null, destination varchar(50) not
null);

 Table Escale

create table Escale (nom_aeroport varchar(50) references

Aeroport(nom_aeroport), id_vol int references Vol(id_vol),
heure_arrivee time not null, heure_depart time not null);

 Table Reservation

create table Reservation (numero_reservation int primary key,

date_reservation date not null, id_client int references
Client(id_client), id_vol int references Vol(id_vol));

 Table Emigrant
create table Emigrant (id_emigrant int primary key,
nom_passager varchar(50) not null, postnom_passager varchar(50)
not null, date_sortie date not null, heure_sortie time not
null, description varchar(100), cache_sortie varchar(3) not
null, numero_reservation int references
Reservation(numero_reservation));

 Table Immigrant

create table Immigrant (id_immigrant int primary key,

nom_passager varchar(50) not null, postnom_passager varchar(50)
not null, date_entree date not null, heure_entree time not
null, description varchar(100), cache_entree varchar(3) not
null, numero_reservation int references
Reservation(numero_reservation));

 Table Posseder

create table Posseder (id_emigrant int references

Emigrant(id_emigrant),num_passeport int references
Passeport(num_passeport));
 45

 Table Avoir

create table Avoir (id_immigrant int references

Immigrant(id_immigrant),num_passeport int references
Passeport(num_passeport));

 Table Proposer

create table Proposer (code_compagnie int references

CompagnieAerienne(code_compagnie), id_vol int references
Vol(id_vol));

4.1.2. Le langage de programmation utilisé

Sachant que l’on a utilisé la méthode UML pour modéliser notre architecture,
le choix du langage serait tourné vers un langage orienté objet. De ce fait on a préféré le
langage C# de la plate forme Microsoft.NET avec comme environnement de développement
intégré le Visual Studio 2010. Le choix porté sur ce langage se justifie du fait que le Visual
Studio depuis sa version 2005 avec le Framework 3.0 a amené une nouvelle technologie qui
est le WCF (Windows Communication Foundation) qui n’est rien d’autre que la version
technique du SOA.

4.1.2. Petite Aperçu sur le WCF

Le WCF est une unification de tous les modèles qui ont existé de telle sorte à
pouvoir séparer le rôle de chaque modèle.

Figure 21 : Historique de la communication

 45

Avec DCOM, on pouvait invoquer à distance des objets COM pris en charge
par la plateforme Microsoft.

COM+ n’est rien d’autre que le nombre de service que l’on a ajouté a COM
(transaction, messagerie à distance). C’est un moyen d’invocation à distance des composants.

Avec MSMQ on peut envoyer des messages à une application sans être certain
que celle-ci est présente pour répondre directement.

L’Entreprise Services expose tous les services COM+ en Dot Net.

Les Web Services XML utilisent le protocole SOAP.

Figure 22 : Les composants de Windows Communication Foundation

Avec WCF, le développeur écrit le service sans se soucier de la façon dont ces
services seront exposés et l’administrateur va mettre en production ces services en utilisant les
différents protocoles (BasicHttp, Netcp, wsHttp, Msmq, …).

Comme le SOA, le WCF est basé sur l’échange des messages entre le client et
le serveur. Développer en WCF c’est faire du SOA.

 L’ABC du WCF
 45

Le WCF est fondé sur trois concepts principaux :

 L’attribut Contract : c’est l’ensemble de services que propose le développeur côté

serveur. C’est aussi l’exposition d’un certain nombre de méthodes qui vont prendre en
compte des paramètres et qui vont renvoyer ou pas des valeurs.

 L’attribut Binding : il définit comment nos services seront exposés et par quel
protocole. Il détermine aussi le type d’encodage à utiliser pour amener le message du
client au serveur.

 L’attribut Address : c’est l’URL finale à laquelle le service sera disponible

Ces trois notions forment ce que l’on appelle le EndPoint.

4.2. IMPLEMENTATION DE L’APPLICATION

4.2.1. Implémentation du Service de flux migratoire

Avant d’implémenter le service proprement dit, il faut d’abord implémenter les

différentes classes de notre application que l’on a obtenue avec le diagramme de classe du
chapitre précédent. L’implémentation des classes est la suivante :

[DataContract]
public class CompagnieAerienne
{

int code_compagnie;

[DataMember]
public int Code_compagnie
{
get { return code_compagnie; }
set { code_compagnie = value; }
}

string nom_compagnie;

[DataMember]
public string Nom_compagnie
{
get { return nom_compagnie; }
 45

set { nom_compagnie = value; }

}

//Classe client
[DataContract]
public class Client
{
int id_client;

[DataMember]
public int Id_client
{
get { return id_client; }
set { id_client = value; }
}

string nom_client;

[DataMember]
public string Nom_client
{
get { return nom_client; }
set { nom_client = value; }
}

string postnom_client;

[DataMember]
public string Postnom_client
{
get { return postnom_client; }
set { postnom_client = value; }
}

DateTime date_depart;

[DataMember]
public DateTime Date_depart
 45

{
get { return date_depart; }
set { date_depart = value; }
}

DateTime date_retour;
[DataMember]
public DateTime Date_retour
{
get { return date_retour; }
set { date_retour = value; }
}

string num_tel;
[DataMember]
public string Num_tel
{
get { return num_tel; }
set { num_tel = value; }
}

string type_vol;
[DataMember]
public string Type_vol
{
get { return type_vol; }
set { type_vol = value; }
}
}

//Classe Aéroport
[DataContract]
public class Aeroport
{

string nom_aeroport;
[DataMember]
public string Nom_aeroport
{
 45

get { return nom_aeroport; }

set { nom_aeroport = value; }
}

string adresse_aeroport;
[DataMember]
public string Adresse_aeroport
{
get { return adresse_aeroport; }
set { adresse_aeroport = value; }
}
}

//Classe DGM
[DataContract]
public class DGM
{

string matricule_agent;
[DataMember]
public string Matricule_agent
{
get { return matricule_agent; }
set { matricule_agent = value; }
}

string nom_agent;
[DataMember]
public string Nom_agent
{
get { return nom_agent; }
set { nom_agent = value; }
}

string postnom_agent;
[DataMember]
public string Postnom_agent
{
get { return postnom_agent; }
 45

set { postnom_agent = value; }

}

public bool ApposerCache()

{
return true;
}
}

//Classe Passager
[DataContract]
public class Passager
{
int id_passager;
[DataMember]
public int Id_passager
{
get { return id_passager; }
set { id_passager = value; }
}

string nom_passager;
[DataMember]
public string Nom_passager
{
get { return nom_passager; }
set { nom_passager = value; }
}

string postnom_passager;
[DataMember]
public string Postnom_passager
{
get { return postnom_passager; }
set { postnom_passager = value; }
}

Reservation numero_reservation = new Reservation();

[DataMember]
 45

public Reservation Numero_reservation

{
get { return numero_reservation; }
set { numero_reservation = value; }
}

//Classe Immigrant
[DataContract]
public class Immigrant : Passager
{
DateTime date_entrée;
[DataMember]
public DateTime Date_entrée
{
get { return date_entrée; }
set { date_entrée = value; }
}

DateTime heure_entrée;
[DataMember]
public DateTime Heure_entrée
{
get { return heure_entrée; }
set { heure_entrée = value; }
}

string description;
[DataMember]
public string Description
{
get { return description; }
set { description = value; }
}

bool caché_entrée;
 45

[DataMember]
public bool Caché_entrée
{
get { return caché_entrée; }
set { caché_entrée = value; }
}
}

//classe Emigrant
[DataContract]
public class Emigrant : Passager
{
DateTime date_sortie;
[DataMember]
public DateTime Date_sortie
{
get { return date_sortie; }
set { date_sortie = value; }
}

DateTime heure_sortie;
[DataMember]
public DateTime Heure_sortie
{
get { return heure_sortie; }
set { heure_sortie = value; }
}

string description;
[DataMember]
public string Description
{
get { return description; }
set { description = value; }
}

bool caché_sortie;
 45

[DataMember]
public bool Caché_sortie
{
get { return caché_sortie; }
set { caché_sortie = value; }
}
}

//Classe Passeport
[DataContract]
public class passeport
{
int num_passeport;
[DataMember]
public int Num_passeport
{
get { return num_passeport; }
set { num_passeport = value; }
}

int periode_validité;
[DataMember]
public int Periode_validité
{
get { return periode_validité; }
set { periode_validité = value; }
}

DateTime date_expiration;
[DataMember]
public DateTime Date_expiration
{
get { return date_expiration; }
set { date_expiration = value; }
}

Passager id_passager=new Passager();

[DataMember]
public Passager Id_passager
 45

{
get { return id_passager; }
set { id_passager = value; }
}

DGM matricule_agent;
[DataMember]
public DGM Matricule_agent
{
get { return matricule_agent; }
set { matricule_agent = value; }
}
}

[DataContract]
//Classe réservation
public class Reservation
{
int numero_reservation;
[DataMember]
public int Numero_reservation
{
get { return numero_reservation; }
set { numero_reservation = value; }
}

DateTime date_reservation;
[DataMember]
public DateTime Date_reservation
{
get { return date_reservation; }
set { date_reservation = value; }
}

Vol id_vol = new Vol();

[DataMember]
public Vol Id_vol
{
get { return id_vol; }
set { id_vol = value; }
 45

[DataContract]
//Classe Vol
public class Vol
{
int id_vol;
[DataMember]
public int Id_vol
{
get { return id_vol; }
set { id_vol = value; }
}

DateTime date_depart;
[DataMember]
public DateTime Date_depart
{
get { return date_depart; }
set { date_depart = value; }
}

DateTime date_arrivée;
[DataMember]
public DateTime Date_arrivée
{
get { return date_arrivée; }
set { date_arrivée = value; }
}

string type_appareil;
[DataMember]
public string Type_appareil
{
get { return type_appareil; }
set { type_appareil = value; }
}
 45

string destination;
[DataMember]
public string Destination
{
get { return destination; }
set { destination = value; }
}

DateTime heure_depart;
[DataMember]
public DateTime Heure_depart
{
get { return heure_depart; }
set { heure_depart = value; }
}

DateTime heure_arrivée;
[DataMember]
public DateTime Heure_arrivée
{
get { return heure_arrivée; }
set { heure_arrivée = value; }
}
}

Après on peut passer à l’implémentation du service de gestion de flux

migratoire. Cette implémentation implique :

- L’implémentation de l’interface IServiceFluxMigratoire qui n’est rien d’autre que le

contrat que l’on va présenter aux clients
- La définition de la classe ServiceFluxMigratoire qui va implémenter les méthodes de
l’interface IServiceFluxMigratoire.

 L’interface IServiceMigratoire se présente comme suit :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
 45

using System.ServiceModel.Web;
using System.Text;
using System.Data;

namespace WebServiceMemoire
{
// REMARQUE : vous pouvez utiliser la commande Renommer du menu Refactoriser pour
changer le nom d'interface "IService1" à la fois dans le code et le fichier de configuration.
[ServiceContract]
public interface IServiceFluxMigratoire
{
//Opération concernant les compagnies aériennes

[OperationContract]
void AjouterCompagnie(int code, string nom);

[OperationContract]
void SupprimerCompagnie(int code);

[OperationContract]
DataSet ListerToutesLesCompagnies();

[OperationContract]
DataSet ChercherCompagnie(int code);

[OperationContract]
void ModifierCompagnie(int ancien_code, int code, string nom);

//Opération concernant les clients

[OperationContract]
void EnregistrerClient(int id, string nom, string postnom, DateTime depart, DateTime
retour, string telephone, string typeDeVol);

[OperationContract]
void ModifierClient(int ancienid, int id, string nom, string postnom, DateTime depart,
DateTime retour, string telephone, string typeDeVol);

[OperationContract]
void SupprimerClient(int id);
 45

[OperationContract]
DataSet ListerTousLesClients();

[OperationContract]
DataSet RechercherUnClient(int code);

 La classe ServiceFluxMigratoire qui implémente l’interface se présente comme suit :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
using System.Data;

namespace WebServiceMemoire
{
// REMARQUE : vous pouvez utiliser la commande Renommer du menu Refactoriser pour
changer le nom de classe "Service1" dans le code, le fichier svc et le fichier de
configuration.
public class ServiceFluxMigratoire : IServiceFluxMigratoire
{
ConnexionBD obj = new ConnexionBD();
CompagnieAerienne ca = new CompagnieAerienne();

//Opérations concernant les compagnies aériennes

public void AjouterCompagnie(int code, string nom)
{
ca.Code_compagnie = code;
ca.Nom_compagnie = nom;
string sql = "insert into CompagnieAerienne values ('" + ca.Code_compagnie + "','" +
ca.Nom_compagnie + "')";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();
 45

public void SupprimerCompagnie(int code)

{
ca.Code_compagnie = code;
string sql = "delete from CompagnieAerienne where code_compagnie='" +
ca.Code_compagnie + "'";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();

public DataSet ListerToutesLesCompagnies()

{
DataSet list = new DataSet();
string sql = "select * from CompagnieAerienne";
obj.SeConnecter();
list = obj.Selection(sql);
obj.Fermer();
return list;
}

public DataSet ChercherCompagnie(int code)

{
ca.Code_compagnie = code;
DataSet list = new DataSet();
string sql = "select * from CompagnieAerienne where code_compagnie='" +
ca.Code_compagnie + "'";
obj.SeConnecter();
list = obj.Selection(sql);
obj.Fermer();
return list;
}

public void ModifierCompagnie(int ancien_code, int code, string nom)

{
ca.Code_compagnie = code;
ca.Nom_compagnie = nom;
 45

string sql = "update CompagnieAerienne set code_compagnie='" +

ca.Code_compagnie + "', nom_compagnie='" + ca.Nom_compagnie + "' where
code_compagnie='" + ancien_code + "'";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();
}

//Opération concernant les clients

Client host = new Client();
public void EnregistrerClient(int id, string nom, string postnom, DateTime depart,
DateTime retour, string telephone, string typeDeVol)
{
host.Id_client = id;
host.Nom_client = nom;
host.Postnom_client = postnom;
host.Date_depart = depart;
host.Date_retour = retour;
host.Num_tel = telephone;
host.Type_vol = typeDeVol;
string sql = "insert into Client values('" + host.Id_client + "','" + host.Nom_client +
"','" + host.Postnom_client + "','" + host.Date_depart + "','" + host.Date_retour + "','" +
host.Num_tel + "','" + host.Type_vol + "')";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();

public void ModifierClient(int ancienid, int id, string nom, string postnom, DateTime
depart, DateTime retour, string telephone, string typeDeVol)
{
host.Id_client = id;
host.Nom_client = nom;
host.Postnom_client = postnom;
host.Date_depart = depart;
host.Date_retour = retour;
host.Num_tel = telephone;
host.Type_vol = typeDeVol;
string sql = "update Client set id_client='" + host.Id_client + "', nom_client='" +
host.Nom_client + "', postnom_client='" + host.Postnom_client + "', date_depart='" +
 45

host.Date_depart + "', date_retour='" + host.Date_retour + "', num_tel='" + host.Num_tel +

"', type_vol='" + host.Type_vol + "' where id_client='" + ancienid + "'";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();
}

public void SupprimerClient(int id)

{
host.Id_client = id;
string sql = "delete from Client where id_client='" + host.Id_client + "'";
obj.SeConnecter();
obj.MisAJour(sql);
obj.Fermer();
}

public DataSet ListerTousLesClients()

{
DataSet ds = new DataSet();
string sql = "select * from Client";
obj.SeConnecter();
ds = obj.Selection(sql);
obj.Fermer();
return ds;

public DataSet RechercherUnClient(int code)

{
host.Id_client = code;
DataSet ds = new DataSet();
string sql = "select * from Client where id_client='" + host.Id_client + "'";
obj.SeConnecter();
ds = obj.Selection(sql);
obj.Fermer();
return ds;
}
}
}
 45

Classe de connexion à la BD est la suivante:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data;
using System.Data.SqlClient;

namespace WebServiceMemoire
{
public class ConnexionBD
{
SqlConnection con = new SqlConnection();

public void SeConnecter()

{
string chemin = "Data Source=FRESTY\\FRESTY; Initial Catalog=GestionVoyage; User
Id=sa; Password=mautu";
con = new SqlConnection(chemin);
con.Open();
}

public void MisAJour(string sql)

{
SqlCommand cmd = new SqlCommand();
cmd.CommandText = sql;
cmd.Connection = con;
cmd.ExecuteNonQuery();
}

public DataSet Selection(string sql)

{
DataSet ds = new DataSet();
SqlDataAdapter adapt = new SqlDataAdapter(sql, con);
adapt.Fill(ds);
return ds;
}

public void Fermer()

{
con.Close();
 45

}
}
}

4.2.2. Configuration du fichier web.config

Ici ce qui est important pour nous, c’est la configuration de nos EndPoint

Figure 23 : Image du fichier de configuration web.config

Après le débogage on a la page suivante :

Figure 24 : Image du Service de flux migratoires

 45

La section du code pour la génération du fichier WSDL est l suivante :

Figure 25 : Extrait de code pour la génération du contrat WSDL

Le fichier WSDL généré se présente comme suit :

Figure 26 : Le fichier WSDL généré

4.2.3. Implémentation de l’application pour une compagnie aérienne

Dans le développement de l’application pour une compagnie aérienne, il suffit

d’ajouter une référence de service, et d’écrire l’URL du fichier WSDL.
 45

Figure 27 : Ajout d’une référence de service du coté d’une compagnie aérienne

Figure 28 : Recherche du service des flux migratoires

Après l’ajout de la référence, il suffit d’invoquer les méthodes du service et tout va marcher
comme sur des roulettes. Voici un exemple du formulaire d’ajout des vols.
 45

Figure 29 : Ajout d’un vol dans la BD

4.2.4. Implémentation de l’application pour une agence de voyage

C’est la même démarche que pour la compagnie aérienne. En voici un exemple

du formulaire pour les réservations. Ici l’agence a des informations pour les différents vols
des différentes compagnies aériennes.
 45

Figure 30 : Liste des vols par compagnies

Figure 31: Réservation d’un vol

 45

4.2.5. Implémentation de l’application pour la Direction Générale de Migration

Après l’ajout d’une référence de service, on a le formulaire suivant qui décrit la situation des
immigrants par date. Quand on parle de situation, allusion est faite au nom, au post-nom, à
l’observation c’est-à-dire la vérification des litiges possibles, à la date d’entrée, à l’heure
d’entrée, au caché d’entrée, à la ville de la république par laquelle il est entré, au vol d’entrée,
et à la compagnie d’aviation qui a assurer ce vol.

Figure 32: Situation des immigrants par dates

Conclusion generale
 45

Nous voici au terme de notre travail qui a consisté à concevoir et réaliser une application de
gestion des flux migratoires aérien. La réalisation d’une telle tâche n’a pas été aisée du tout
d’autant plus qu’il fallait faire une analyse du système d’information d’une agence de voyage,
d’une compagnie aérienne et de la Direction Générale de Migration. Notons que nous n’avons
récolté que les informations concernant le processus de réservation d’un vol par un client et
du contrôle des passagers à l’aéroport.

La Direction Générale de Migration, « D.G.M »en sigle, exerce ses compétences sur toute
l’étendue de la République, il était impérieux de doter sa direction de contrôle d’un système
pouvant leur permettre de contrôler tous les flux migratoires aériens du pays et lui permet
d’avoir une idée sur le nombre exact des étrangers immigrants en RDC ainsi que la durée de
leur séjour.

L’application mise en place permet aussi aux différentes compagnies aériennes d’améliorer
leur stratégie de focalisation c’est-à dire tenir compte des destinations les plus rentables, et de
prix du billet en fonction de leurs concurrents.

Tout travail humain étant en perpétuel progression, nous osons croire que nous ménagerons
des efforts pour davantage améliorer cette approche utilisée dans d’autre cadre en se basant
sur des nombreux nouveaux outils et technologies qui sont annoncés sur les marchés dans un
avenir proche afin d’offrir aux générations futures un cadre idéal pour les recherches et
l’amélioration permanente de solutions de gestion et de suivi dans les entreprises.

Le travail de recherche actuel peut être prolongé dans un certain nombre de directions de
manière à répondre au mieux au plus grand nombre des besoins des utilisateurs.

Bibliographie
 45

I. LIVRES ET OUVRAGES
[1] Christine Morin, Architectures et systèmes distribués tolérants aux fautes,
L’Université de Rennes 1 Institut de Formation Supérieure en Informatique et en
Communication
[2] Christophe Dabancourt, Apprendre à Programmer, Eyrolles (2ème Edition), 2008

[3] Didier DONSEZ, Architecture orientée services, Université Joseph

FourierPolytech’Grenoble LIG/ADELE Didier, 2002

[4] Eric Cariou, Introduction aux Systèmes Distribués Licence Informatique 3ème année,
Université de Pau et des Pays de l'Adour Département Informatique

[5] F. Baude (baude@unice.fr),Cours Systèmes ((Distribués) Répartis, Maîtrise MIAGE

2003-2004

[6] Julien DEFAUT, Créer et consommer des web services sécurisés par HTTPS en C#,
2005

[7] Olivier SIGAUD, Introduction à la modélisation orientée objet avec UML, édition
2007- 2008.

[8] Pascal Roques, UML 2 par la pratique (Etudes des cas et Exercices corrigés), Eyrolles,
2004

[9] Pierre Bonnet, Cadre de Référence Architecture SOA (*) Meilleures Pratiques,
Orchestra Networks, Février 2005

[10] Serge Tahé, Apprentissage du langage C# 2008 et du .NET Framework 3.5, ISTIA
Université d’Angers, Mai 2008.

[11] Software engineerin 7th edition, Distributed Systems Architectures, ©lan Sommerville
2004
[12] Xavier Le Galles, Libero Maesano, Christian Bernard, Services Web avec
J2EE et NET Conception et implémentations, Edition Eyrolles, 2003

II. COURS INEDITS

 45

[13] DJUNGU S.J., Génie logiciel et construction des programmes, Cours inédit,
L1Info, Fac. Sciences, Math-Info, UNIKIN, 2009-2010

[14] DJUNGU S.J., Algorithme et Programmation parallèle, Cours inédit, L2 Info, Fac.
Sciences, Math-Info, UNIKIN, 2006-2007.

[15] KASENGEDIA MUTOMBE P., Systèmes d’objets repartis, Cours inédit, L1

Info, Fac. Sciences, Math-Info, UNIKIN, 2006-2007.

[16] MBUYI MUKENDI E, Cours des bases de données reparties, L1 et L2 Math-

Info, UNIKIN, 2008-2009.

III. WEBOGRAPHIE

[17] http://fr.wikipedia.org/wiki/Architecture_orientée_services , 2011

[18] http://www.cgi.com/fr/integration-de-systemes-et-services-conseils/architecture-orientee-
services-aos, 2011

[19] http://www.commentcamarche.net , 2012

[20] http://www.wikipedia.org , 2012

IV. MEMOIRES, TRAVAUX PRATIQUES ET COURS INTERACTIFS

[21] MUKENDI Steve, NKANKU Hervé, MUKENDI Trésor, Travail pratique de Génie
Logiciel et Construction des Programmes sur la Gestion des Immigrants Cas de la
DGM, L1 MATH-INFO, UNIKIN, 2009-2010

[22] Pascal BELAUD, Cours interactif sur Windows Communication Foundation, France
2005

Table des matieres

 45

DEDICACE……………………………………………………………………………………………....
i
Avant-prpos…………………………………………………………………………………………ii

Liste des abbreviations………………………………………………………………………...iii

Liste des FIGURES…………………………………………………………………………………..iv

Liste des tableaux………………………………………………………………………………..v

INTRODUCTION GENERALE............................................................................................................1
I. PROBLEMATIQUE.......................................................................................................................1
II. HYPOTHESE................................................................................................................................1
III. INTERET DU SUJET..................................................................................................................2
IV. DELIMITATION DU SUJET......................................................................................................2
V. METHODOLOGIE ET TECHNIQUES UTILISES......................................................................2
VI. SUBDIVISION DU TRAVAIL...................................................................................................2
CHAPITRE I : LES ARCHITECTURES DES SYSTEMES DISTRIBUES [1], [4], [5], [11], [14],
[15], [16], [19], [20]...............................................................................................................................4
1.1. HISTORIQUE................................................................................................................................4
1.2. NOTIONS D’INFORMATIQUE DISTRIBUEE...................................................................................4
1.3. LE CALCUL PARALLELE ET LE CALCUL DISTRIBUE........................................................................5
1.4. NOTION DE SYSTEME DISTRIBUE................................................................................................6
1.4.1. Définition..............................................................................................................................6
1.4.2. Vision matérielle et logicielle d’un système distribué...........................................................6
1.4.3. Caractéristiques d’un système distribué...............................................................................7
1.4.4. Intérêts des systèmes distribués............................................................................................7
1.4.5. Avantages des systèmes distribués........................................................................................7
1.4.6. Désavantages des systèmes distribués..................................................................................7
1.4.7. Transparence des systèmes distribués..................................................................................8
1.4.8. Le Middleware......................................................................................................................9
1.4.9. Quelques exemples des systèmes distribués ou d’application de calcul distribué...............10
1.5. LES ARCHITECTURES DES SYSTEMES DISTRIBUES......................................................................10
1.5.1. L’architecture Client-serveur.............................................................................................11
1.5.2. L’architecture Peer-to-Peer...............................................................................................12
1.5.3. Les architecture 3-tiers et n-tiers........................................................................................13
La comparaison avec l'architecture MVC......................................................................................14
L'utilisation du développement Web...............................................................................................14
 45

Autres considérations......................................................................................................................15
Traçabilité........................................................................................................................................15
1.5.4. Une grappe d’ordinateurs..................................................................................................15
1.5.5. L’architecture orientée service (SOA)................................................................................19
CHAPITRE II : L’ARCHITECTURE ORIENTEE SERVICES [3], [9], [12], [17], [18], [19], [20]....20
2.1. DEFINITION...............................................................................................................................20
2.2. PRINCIPES GENERAUX D’UNE ARCHITECTURE ORIENTEE SERVICES.........................................20
2.3. AVANTAGES D’UNE ARCHITECTURE ORIENTEE SERVICES.........................................................21
2.4. LES CONCEPTS DE BASE DU SOA...............................................................................................21
2.4.1. SOA et Service....................................................................................................................21
2.4.2. Web Service............................................................................................................................26
2.4.3. Approche Orientée Objet....................................................................................................26
2.4.4. Le composant......................................................................................................................26
2.5. DEFINITION DES ROLES............................................................................................................27
2.6. LES APPORTS DU SOA..............................................................................................................27
2.6.1. Les apports métiers.............................................................................................................27
2.6.2. Les apports techniques.......................................................................................................28
2.7. PRESENTATION GENERALE DU PROTOCOLE SOAP..................................................................28
2.7.1. Présentation et Fonctionnement de SOAP..........................................................................28
2.7.2. Présentation et Fonctionnement des Web Services............................................................30
2.7.3. Le protocole WSDL............................................................................................................30
2.7.4. Le protocole UDDI.............................................................................................................31
2.7.5. Différence entre IIOP et SOAP...........................................................................................31
2.7.6. Protocoles utilisés par SOAP..............................................................................................32
2.7.7. Problèmes posés par SOAP................................................................................................33
a) Problèmes HTTP......................................................................................................................33
b) Problèmes XML.......................................................................................................................34
c) Problèmes liés à SOAP.............................................................................................................34
2.7.8. Les fichiers WSDL..............................................................................................................34
CHAPITRE III : MODELISATION DU PROCESSUS DE FLUX MIGRATOIRES AERIENS [2],
[7], [8], [14], [21].................................................................................................................................37
3.1. INTRODUCTION.........................................................................................................................37
3.2. PRESENTATION DES ROLES ESSENTIELS DE NOS TROIS SYSTEMES............................................37
3.2.1. L’agence de voyage............................................................................................................37
 45

3.2.2. La Direction générale de Migration (DGM).........................................................................37

3.2.3. La Compagnie Aérienne d’Aviation.....................................................................................38
3.3. SPECIFICATIONS INITIALES DU SYSTEME...................................................................................38
3.4. ELABORATION D’UN CONCEPT..................................................................................................38
3.5. DIAGRAMMES UML...................................................................................................................39
3.5.1. Le diagramme de cas d’utilisation......................................................................................39
3.5.2. Le diagramme d’activité.....................................................................................................43
3.5.3. Le diagramme de séquence................................................................................................45
3.5.4. Le diagramme d’états-transitions.......................................................................................46
3.5.5. Le diagramme de classe......................................................................................................47
CHAPITRE IV : DEVELOPPEMENT DE L’APPLICATION DE GESTION FLUX MIGRATOIRE
aerien [6], [10], [21], [22].....................................................................................................................50
4.1. PRESENTATION DES DIFFERENTS OUTILS DE DEVELOPPEMENT................................................50
4.1.1. Le Système de gestion de base des données (SGBD) utilisé................................................50
4.1.2. Le langage de programmation utilisé.................................................................................52
4.1.2. Petite Aperçu sur le WCF.....................................................................................................52
4.2. IMPLEMENTATION DE L’APPLICATION......................................................................................54
4.2.1. Implémentation du Service de flux migratoire....................................................................54
4.2.2. Configuration du fichier web.config........................................................................................71
4.2.3. Implémentation de l’application pour une compagnie aérienne........................................72
4.2.4. Implémentation de l’application pour une agence de voyage.............................................74
4.2.5. Implémentation de l’application pour la Direction Générale de Migration.......................76
Conclusion generale.............................................................................................................................77
Bibliographie........................................................................................................................................78
Table des matieres................................................................................................................................80