II- STAGE : Un système bancaire distribué
II.1 Les objectifs
Dans le cadre de la recherche sur l'Interface Homme Machine et les Systèmes
Distribués,
le sujet de mon stage était de construire un noyau d'expérimentation d'un
système bancaire distribué,
basé sur le standard C.O.R.B.A..
Cette construction avait pour objectif de faire ressortir les difficultés
liées à la conception de Systèmes Distribués et tout particulièrement
celles spécifiques au rapport espace / temps.
Pour cela, je devais utiliser l'O.R.B. Orbix Web
de I.O.N.A dédié au langage Java.
Cependant, mon premier objectif a été de comprendre ce qu'était C.O.R.B.A.,
et comment utiliser
cette norme dans le développement d'applications distribuées.
Ce que j'ai retenu et compris de ce concept vous est expliqué ci-dessus
dans la première
partie du document.
Par la suite, ce projet a impliqué :
- la prise en main d'outils nécessaires au développement de l'application
(Microsoft Visual J++, IONA Obix Web, Javasoft Swing),
- la connaissance de la norme O.M.T. pour modéliser le système bancaire,
- l'utilisation d'un langage particulier : l'I.D.L. pour spécifier les classes,
- de bonnes bases en programmation orientée objet pour implanter les classes et l'application,
- enfin, de la rigueur et beaucoup de temps pour mener à terme ce "noyau " d'un système bancaire distribué.
Ainsi, je vous expose à travers ce rapport toutes ces étapes du
cycle de conception, mais aussi les difficultés posées par la distribution.
II.2 Les étapes de la conception
II.2.1 Prise en main des outils
Orbix Web 3.0 de IONA Technologies
Orbix Web est un environnement logiciel qui permet de construire et d'intégrer
des applications distribuées.
Orbix Web est une implantation complète de la spécification C.O.R.B.A.
de l'O.M.G.
Il associe la fonctionnalité C.O.R.B.A. au langage de
programmation Java.
Orbix combine :
- une approche puissante basée sur des standards pour le
développement d'applications distribuées,
- avec la fléxibilité et la facilité d'utilisation de
l'environnement Java.
Orbix web intègre les fonctionnalités suivantes :
- un O.R.B programmé en Java,
- un serveur java : Java Activator : orbixdj,
- un support complet pour l'adaptation I.D.L. / Java.
Par ailleurs, la technologie IONA est conforme au protocole
I.I.O.P. assurant ainsi l'interopérablité avec d'autres O.R.B.
Microsoft Visual J++
L'outil de développement choisi est Microsoft Visual J++,
c'est non seulement un compilateur java mais aussi un I.D.E. (Integrated
Developement Environement) qui comporte :
- Un éditeur
- Un compilateur
- Une documentation (A.P.I.)
- Un débugueur
- Un éditeur de ressources graphiques
- Un explorateur d'objets (liste des objets, classes, méthodes).
- ...
Cet outil a un avantage notoire la convivialité, mais aussi comme
inconvénient sa non fiabilité.
En effet le langage J++ n'a pas été attribué 100 % Java compatible.
Javasoft Swing
J'ai également utilisé Swing 1.1.1 Beta
(connue officiellement sous "Java Foundation Classes 1.1").
Ce pakage 100% java comporte un ensemble de classes d'objets graphiques,
tout comme java.awt swing permet de créer des interfaces mais beaucoup
plus ergonomiques et strictement identiques sur des plate-formes
différentes.
II.2.3 Spécification du problème en O.M.T.
II.2.3.1 Définition des objets
Mme F ADREIT, Mme
S EBERSOLD, Mr JC SAKDAVONG et
moi même avons réfléchi
sur les objets qui pourraient composer notre futur système bancaire.
Cette phase de réflexion s'est appuyée sur le
fonctionnement d'une banque dans le monde réel.
Nous nous sommes intéressés plus particulièrement au système bancaire français,
et à ses règles de gestion.
Ainsi, nous avons pu faire ressortir les points suivants :
- Un organisme compensateur gère les échanges entre
toutes les banques.
L'organisme compensateur représente donc un objet important du système
bancaire car il "supervise" en quelque sorte tout le système de gestion
des banques.
- Une banque possède un certain nombre d'agences dispersées à travers le pays.
Comme nous l'avons décrit ci-dessus,
toute banque dialogue avec l'organisme compensateur.
- Une agence d'une banque peut disposer de plusieurs
guichets dans sa ville :
- Des guichets humains.
A l'écoute des requêtes des clients, et ils
effectuent toutes les opérations bancaires demandées.
-
Des guichets automatiques pour les clients possédant une carte banque
dédiée (ou carte propriétaire).
Ces guichets permettent aux clients d'effectuer des consultations du solde et des opérations réalisées.
Les clients peuvent aussi y effectuer des retraits d'argent.
Les opérations de dépôt et de virement sont impossibles avec ce genre de guichet.
- Des distributeurs automatiques.
Ce sont des guichets accessibles avec une carte bancaire(carte magnétique comme la carte bleue).
On peut y effectuer seulement les opérations de consultation et de retrait d'argent.
On les appellera par la suite guichet CB. C'est une autre famille de guichets
automatiques.
- Des guichets "déplacés" chez les commerçants.
Lorsque nous allons faire des achats dans les magasins,
nous pouvons régler la note
avec la carte bancaire.
- Un gestionnaire gère tous
les comptes enregistrés dans cette agence de la banque en question.
Après avoir dépeind plus ou moins l'environnement bancaire,
penchons nous maintenant sur les mécanismes internes de gestion des comptes
à travers ce réseau.
- chaque agence possède un gestionnaire de comptes, qui comme son
nom l'indique
s'occupe des transactions bancaires sur chaque compte ouvert dans
cette agence.
- Il y a deux sortes de comptes bancaires :
- le compte client, ouvert pour un client de l'agence.
Initialement, le client dispose pour chacun de ses comptes d'une
carte bancaire propriétaire.
Mais un client peut aussi désirer une carte bleue, alors il
disposera en plus d'un compte carte bleue.
- le compte carte bleue n'a de sens que si le client
posède une carte bancaire,
en l'occrurence une carte bleue.
Ce compte est rattaché à une centre de cartes bleues qui gère
les opérations
de débit sur ce compte.
- un centre carte bleue supervise l'ensemble des guichets
utilisables avec la carte bleue.
- quant au client , acteur dans ce réseau bancaire, il peut être
décrit :
- par son identité : nom, prénom, age : données non
modifiables ,
- mais aussi par d'autres caractéristiques variables
comme l'adresse par exemple.
En effet, un même client peut résider dans deux domiciles
différents. Pourtant
il posséde un seul et même compte mais géré tantôt par la
première agence et tantôt par la deuxième.
Maintenant que les objets et leur relation ont été convenus, comment
exprimer alors clairement
la répartition et les liaisons entre eux?
Une représentation graphique semble être le mieux adapté.
Nous avons donc choisi de modéliser l'application en O.M.T.
(Object Model Techniques) selon les recommandations de M EBERSOLD.
II.2.3.2 Modélisation en O.M.T.
Qu'est ce que l'O.M.T.?
La notation graphique obtenue à partir des objets décrits ci-dessus
est la suivante :
Notations :
- un losange désigne une cardinalité multiple.
Par exemple, on lit : un organisme compensateur a plusieurs banques.
- un point noir désigne une cardinalité "unique".
Exemple : une banque a un et un seul organisme compensateur.
- un point blanc (vide cerclé de noir) illustre une cardinalité nulle.
- le triangle représente la notion d'héritage.
Exemple : guichet CB et guichet Agence héritent de Guichet;
(ce sont bien en effet deux sous-classes de guichet).
Cette représentation graphique symbolise parfaitement la structure de
l'application.
Il nous reste maintenant à définir les classes et les opérations possibles sur
celles-ci.
II.2.4 Spécification d'un sous-ensemble de classes en I.D.L.
Par manque de temps et par souci de "justesse", seules les classes en
relation avec le gestionnaire ont été spécifiées.
En effet, le fonctionnement d'une banque peut s'apparenter à celui du
gestionnaire de comptes.
En fait, dans une banque, on retrouve toutes les opérations les plus
élémentaires, décrites par le gestionnaire.
Ainsi, j'ai concentré mon travail sur la réalisation d'une
mini-application (un noyau), simulant le "comportement " d'un guichet client
"face" au gestionnaire de comptes d'une banque.
Plusieurs guichets clients pouront alors utiliser les fonctionnalités
offertes par le gestionnaire de leur banque.
Ceci grâce à la distribution de l'application cliente sur plusieurs sites
(ordinateurs, plate-formes hétérogènes).
L'application serveur de gestionnaires sera lancée sur un site, attendant les
requêtes des "guichets" clients.
Par ailleurs, j 'ai tenu à spécifier mes classes de la façon la plus
générale possible.
Ceci afin que mon travail puisse être complété par la suite, en y
intégrant le reste des objets décrits dans le modèle O.M.T.ci-dessus.
II.2.4.1 Spécification des classes, opérations et attributs.
C'est une étape fondamentale qu'il ne faut pas abréger car elle évite par
la suite de comettre des erreurs de conception,
de revenir en arrière et de perdre du temps.
Il est donc important de bien spécifier tous nos objets et les opérations
possibles sur ceux-ci avant
de se lancer dans la programmation proprement dite.
Les classes retenues
Du schéma des classes ci-dessus, nous nous sommes intéressés aux classes
suivantes :
- Agence. Elle est identifiable par :
- son nom,
- (la banque à laquelle elle appartient,
ici la classe banque n 'a pas été implantée;
mais il est facile de voir qu'une banque a un nom,
un ensemble d'agences, et est rattachée
à l'organisme compensateur).
- le gestionnaire qu'elle acceuille.
- Gestionnaire
. Il a toutes les fonctionnalités nécessaires à la gestion
des comptes bancaires :
- créer un compte client en prenant connaissance :
- du client,
- d'un numéro local qui s'incrémente à chaque ouverture de compte,
- de la somme déposée initialement,
- du découvert maximum autorisé,
- et d'un libellé.
De façon symétrique, nous pouvons reprendre cette méthode pour
la création d'un compte CB.
- fermer un compte,
- migrer un compte vers une autre agence,
- enregistrer tous les comptes ouverts dans une table
[identite bancaire <=> compte],
- accéder à un compte pour un identite bancaire donnée, et inversement,
- obtenir l'agence auquel il appartient, le numéro guichet
correspondant et le libelle qui le caractérise.
- Compte. Un compte est caractérisé par son client, un libellé, un
numéro local, et le solde.
Le client du compte peut effectuer :
- une opération (retrait, versement, virement, paiement par chèques, ...)
sur son compte
- ou consulter son solde et des opérations.
- Compte client. C'est une sous-classe de Compte qui a des
caractéristiques supplémentaires :
- le montant du découvert maximum autorisé,
- le gestionnaire auquel est rattaché le compte client,
- l'identité bancaire qui est construite à partir du code local,
code du gestionnaire et code de l'agence.
Le client a aussi la possibilité de modifier le découvert maximum
autorisé sur son compte.
- Compte CB. Comme le compte client, il hérite des propriétés
d'un compte normal, et dispose d'autres différentes :
- le code la carte bleue associée
- un retrait maximum hebdomadaire autorisé et la possiblité de
le modifier,
- un attribut qui représente l'état actuel du compte : bloqué ou non,
- une méthode pour bloquer le compte si par exemple faute
de découvert important dans la semaine, le client
n'est plus autorisé à débiter de l'argent avec sa carte bancaire.
- une méthode débloquer.
- enfin un attribut état qui reflète l'état bloqué ou débloqué
du compte.
- Client
. Il est identifié par son nom et son prénom.
En approfondissant notre réflexion sur les liaisons entre ces classes
(qu'est ce qui circule
entre le client et le compte, du compte au gestionnaire, ...), nous avons
fait apparaître de nouvelles classes qui décrivent les opérations,
consultations et résultat de ces transactions.
Soit :
- des objets de transaction bancaire :
- Operation. Ce peut être une opération de retrait, de virement
d'un compte vers un autre,
de dépôt d'argent sur un compte, ....
Elle prend en compte :
- le montant de la transaction,
- le compte source identifié par un numéro de compte bancaire
: l'Identité Bancaire
- le compte destinataire (pour les opérations de virement notamment)
identifié de la même façon,
- le numéro de chèque pour les paiements avec chéques.
- la date de l'opération,
- le libellé (retrait, virement, dépôt, ...),
- une signature ,
Nous avons rajouté pour des raisons (en partie de programmation),
un attribut supplémentaire : la cible.
Elle vaut 1 si l'opération est : source vers destinataire.
elle vaut 0 si c'est l'inverse, ou s'il n'y a pas de destinataire comme
pour les opérations de retrait et de dépôt d'argent.
Ainsi, en prenant connaissance de la cible, une banque peut "dispacher"
l'opération
aux agences (et leur gestionnaire) source et destinataire qui respectivement,
effectuent une opération de débit
sur le compte source et une opération de crédit sur le compte du destinataire
(s'il s'agit d' un virement).
- Consultation. Il y a deux types de consultation :
- type 1 : consultation du solde,
- type 2 : relevé des opérations.
- un objet "retour" des transactions effectuées :
Compte Rendu.
Il diffère selon les opérations et les consultations.
Le client peut obtenir :
- un premier compte rendu : son solde à la date du jour,
- un deuxième compte rendu : un tableau des opérations effectuées à partir
d'une date donnée.
- des objets qui permettent d'identifier un compte, et d'authentifier
les transactions :
- Identite Bancaire. C'est le numéro de compte bancaire.
Il est composés des trois champs
existant dans les R.I.B. du systéme français :
- le code de la banque : 5 chiffres,
- le code guichet (ou code de l'agence) : 5 chiffres,
- le code local du client : 11 chiffres.
Il permet d'identifier un compte dans son intégralité (banque?
agence? client?)
- Signature.
C'est une signature correspondant à la signature papier
Elle permet de valider une requête.
II.2.4.2 Ecriture en I.D.L.
Toutes les spécifications ont été décrites en I.D.L. pour être ensuite
exploiter dans la construction
des objets (implantation de leurs méthodes) .
Comme je l'avais expliqué dans la première partie, ce sont les interfaces
des objets (signature des méthodes et attributs) que l'on présente en I.D.L.
Je tenais à préciser que outre la spécification en I.D.L. des objets définis
plus haut, j'ai également
écrit en I.D.L. une interface MaDate qui reprend la spécification de la
classe Date existant en Java.
De plus, étant donné que le type vecteur n'existe pas en I.D.L., j'ai
construit une séquence d'Operation
que j 'ai appelée tabop. Tabop est un tableau d'opeartions,
il est nécessaire dans l'écriture de l' interface
CompteRendu car il apparait comme type retour de la méthode getReleve().
typedef sequence <Operation> tabop;
Le code en I.D.L. est disponible dans les annexes de ce document.
Explications techniques
Les interfaces écrites en I.D.L. sont "tapées" dans un fichier texte puis
sauvées dans mon répertoire de travail sous l'extension idl.
Ce fichier idl a ensuite été compilé (commande : idl AppBanque.idl)
par le compilateur d'I.D.L. vers Java fournit par Orbix Web.
Si des erreurs sont apparues à la compilation, on les corrige dans le fichier
idl et on le compile à nouveau jusqu'à ce qu'il n'y ait plus aucune erreur.
Lorsque la compilation s'est déroulée correctement, Orbix Web a généré
des fichiers Java incluant le corps des squelettes et stubs
utiles à la programmation de l'application. Par défaut ces fichiers
sont "déposés"
dans un répertoire crée par orbix Web à cet effet : java_output
Vous pouvez visualiser le contenu de ces fichiers en annexes.
II.2.5 Réalisation d'un sous-ensemble de classes
II.2.5.1 Fichiers généres par le compilateur d'Orbix Web
Le compilateur d'I.D.L. a produit plusieurs constructions Java qui
correspondaient
aux définitions I.D.L.. Ces constructions peuvent être scindées en deux
groupes :
- une première partie va permettre aux clients d'acceder à un objet
à travers l'interface de cet objet.
- une deuxième partie inclue l'ensemble des constructions qui permettent
à un objet d'être implanté par le serveur.
- une troisième partie sert à établir le lien entre le client et le serveur.
Première partie
Cette partie contient :
- une interface java pour chaque interface I.D.L.
- des classes Java qui implantent les méthodes définies dans l'interface
générée.
Ces classes fournissent les fonctionnalités de la souche de communication
cliente (le stub).
_GestionnaireStub
Il y a autant de _stub java que d'interfaces I.D.L.
Deuxième partie
contenu :
- une classe java utilisée par orbix Web qui propose les fonctionnalités
de la souche serveur (le skeleton).
Il s'agit de répartir les requêtes
arrivant sur le serveur de l'application vers l'implantation des objets.
(remarque : cette une classe qui n'a pas besoin d'être comprise du
développeur).
_gestionnaireSkeleton
- une classe java abstraite qui sert à implanter l'interface
d'un objet côté serveur .
C'est ce que l'on appelle " l'approche Implbase ".
_GestionnaireImplBase
- deux autres classes employées dans " l'approche TIE " : approche
d'implantation des interfaces spécifique à Orbix et non standardisée.
Classe _tie_Gestionnaire et classe _GestionnaireOperations
Nous reviendrons plus tard sur ces deux approches afin de déterminer la
mieux appropriée à notre application
Troisième partie
Deux types de classes générées :
- les classes Helper. Elles permettent de manipuler les types
définis dans l'I.D.L..
Ex : GestionnaireHelper.
- les classes Holder
.
II.2.5.2 Approche-Implbase ou Approche-TIE ?
Comparaison
Orbix Web fournit deux méthodes pour implanter une interface I.D.L.
Ces deux approches sont :
- l' approche Implbase qui utilse l'héritage, c'est l'approche standard
C.O.R.B.A.
- l'approche TIE qui utilise la "délégation" est préférée
pour construire les applications Java.
Le langage Java ne supporte pas l'héritage multiple.
Ainsi, utiliser l'héritage que l'approche ImplBase impose sur
l'implantation des classes limite la fléxibilité de ces classes.
De plus, cela élimine la possibilité de réutiliser les implantations
existantes des interfaces dérivées.
Par contre, il n'y a pas de restriction dans l'approche TIE ,
et c'est pour cela que nous l'avons choisie.
Etant donnée la compléxité d'héritage des classes de notre application,
j'ai choisi d'implanter mes objets avec l'approche TIE.
Mécanisme d'implantation d'un objet dans l'approche TIE
Ce mécanisme n'est possible que si l'on a au préalable implementé une
interface I.D.L.
Regardons le mécanisme sur le schéma suivant :
Le compilateur d'I.D.L.
d'Orbix a génèré une classe tie java pour chaque interface I.D.L.
Le fichier généré est nommé "_tie_xxx.java".
Un objet qui implante l'interface I.D.L. est passé
en paramètre au constructeur de la classe tie.
On définit ensuite une classe qui va implanter les
opérations et attributs définis dans l'interface I.D.L.
exemple de classe : GestionnaireImplementation
Cette classe n'a pas besoin d'hériter de toutes les classes générées
automatiquement.
Elle doit simplement implanter l'interface java :
_gestionnaireOperations.
Ensuite, le programmeur instancie un objet tie :
_tie_gestionnaire,
en passant l'objet implanté GestionnaireImplementation
au constructeur.
A la création des objets tie, il est possible de passer un second
paramètre au constructeur de type String. Ce marqueur permet
ainsi d'identifier de façon unique l'objet instacié sur le serveur.
GestionnaireImplementation g=new GestionnaireImplementation();
Gestionnaire gestCA= new _tie_Gestionnaire(g,"CA");
C'est une alternative au service de nommage.
Exemple implanté
[ cf sources annexes]
II.2.5.3 Classes implantées
Des classes ClassImplementation ont été écrites pour chaque
interface I.D.L.
Ces classes sont composées d'un constructeur, d'attributs et de
l'implantation des méthodes spécifiées dans l'I.D.L.
Chacune implante _ClassOperations : la classe générée par
le compilateur en accord avec l'interface écrite en I.D.L.
C'est le principe de l'approche tie.
Tous les sources sont disponibles dans les annexes.
La prochaine étape consiste à écrire les programmes serveur et client.
Puis décider d'une interface d'utilisation de l'application distribuée.
II.2.6 Classes et interfaces de test des classes implantées
Dans cette étape , j'écrits les deux classes suivantes :
- la classe ApplServeur qui contient le code exécutable du
programme serveur.
- la classe ApplClient qui contient le code nécessaire à
l'implantation du client.
En fait comme vous le verrez plus loin,
j'ai aussi écrit un deuxième programme client qui lui plus complet,
inclue une ébauche d'une interface utilisateur.
Je vous détaille ci-dessous l'implantation de ces classes tests.
II.2.6.1 Ecriture du programme serveur : classe ApplServeur
Mon serveur fournira deux gestionnaires de comptes :
- un pour la banque du Crédit Agricole,
- un autre associé à la banque du Crédit Lyonnais.
Le code de mon serveur instanciedonc deux objets Gestionnaire
ga et gc avec leurs objets tie associés : gestCA et gestCL.
Ces objets sont nommés respectivement CA et CL à leur construction.
Ainsi les clients pouront invoquer l'un ou l'autre, en se "liant" avec eux
sur le serveur par appel de la méthode :
bind ("nom de l'objet tie : nom du serveur d'objets",
"adresse de la machine serveur")
Cette méthode indispensable au programme client est davantage développée
dans la section suivante.
Revenons à notre programme serveur, chaque objet instancié doit être
connecté au bus.
Sinon, il sera impossible pour le serveur de gérer les invocations
clientes arrivant pour ces objets.
Il y a deux méthodes disponibles dans Orbix Web pour connecter les objets
à l'O.R.B :
- utiliser ORB.connect() et ORB.disconnect().
Ces méthodes sont définies dans la spécification C.O.R.B.A.
Ce sont des méthodes standards.
L'O.R.B continue d'appliquer les méthodes invoquées sur les objets-tie jusqu'à
ce qu'ils soient déconnectés (avec
ORB.disconnect(objet-tie)).
- ou bien utiliser _CORBA.Orbix.impl_is_ready.
C'est une méthode spécifique à Orbix Web.
Elle indique que le serveur a terniné l'initialisation d'un ensemble
d'objets, et qu'il est maintenant prêt pour recevoir les requêtes sur ces
objets.
Cette méthode "bloque" le serveur jusqu'à ce que des évènements
aient lieu.
Pour permettre au serveur d'être lancé soit de façon automatique (à partir
du client) soit manuellement, il est recommandé de passer le nom du serveur
en paramètre de impl_is_ready().
_CORBA.Orbix.impl_is_ready(String nom du serveur)
J'ai utilisé ORB.connect(gestCA) et ORB.connect(gestCL)
pour connecter mes objets gestionnaire au bus.
Le serveur a mis ses objets à disposition puis se met en veille (blocage du
processus).
Aprés un time out (delai), le processus serveur se reveille et
déconnecte ses objets
est d'enregistrer
Le serveur d'objets est enregistré auprés du référentiel des implantations
par la commande : putit -java nom du serveur
(dans une console)
Le code de la classe AppLServeur est visualisable dans les annexes
II.2.6.2 Ecriture du programme client et interface d'utilisation
Du côté client, nous pouvons utiliser et invoquer des traitements sur les
gestionnaires disponibles sur le serveur : créer un compte, déposer de
l'argent, consulter le solde, ...etc.
Pour tester mon application et vérifier si les méthodes que j'avais écrites
étaient correctes, j'ai d'abord écrit un premier programme client :
classe ApplClientDemo.
Dans ce programme de test, les opérations effectuées sont :
- initialisation de l'O.R.B.
- connexion aux gestionnaires gestCA et gestCL sur le serveur,
- création d'un compte (c1) au Crédit Agricole,
- opération de retrait de 400 F sur c1,
- dépôt de 56.50 F sur c1,
- création d'un compte c2 au Crédit Lyonnais,
- virement de 50 F de c1 sur c2,
- consultaion relevé des opérations de c1,
- consultation du solde de c1,
- consultation du solde de c2,
Ce programme fait rarement intervenir l'utilisateur.
En effet,c'était avant tout
une phase de test qui consistait à vérifier la cohésion et la validité des
méthodes des objets que j'avais implantées auparavant.
J'ai donc élaboré cette première application cliente dans un souci de
fiabilité en testant au fur et à mesure les opérations les plus élémentaires
sur un compte.
Une fois cette étape de validation terminée, je me suis lancée dans
l'écriture d'un autre programme client intégrant une mini-interface utilisateur.
Il s'agit de la classe ApplClient
Ainsi, un client peut manipuler l'application à l'aide de l'interface
graphique. La gestion des évènements dans cette interface a en partie été
gérée.
De plus, contrairement au premier programme client, j'ai "éclaté" la
méthode main()en plusieurs méthodes invoquées à la
construction de AppClientDemo.
Cette classe implantée permet :
- de mettre en place une interface utilisateur,
- d'ouvrir un compte,
- de consulter ou d'effectuer une transaction bancaire.
Bien sûr, cette réalisation peut sembler minimaliste mais les bases
peuvent être celles d'une réelle application distribuée.
Détails de programmation
Regardons plus précisément la méthode de connexion du client avec le serveur.
Cette méthode commune aux
deux programmes clients est la méthode standard pour se lier avec les objets
sur le serveur.
En effet bind() est utilisée pour créer les souches
de communication pour les objets qui ont été crées sur le serveur.
La création d'un proxy dans l'espace d'adressage du client permet aux
opérations d'être invoquées sur l'objet ciblé.
Lorsque l'opération est invoquée sur le proxy, Orbix web transmet
automatiquement la requête à l'objet ciblé.
Bind() est une méthode statique qui est automatiquement générée
par le compilateur d'I.D.L.pour chaque classe idl-java.
Pour chaque interface, la forme entière de bind() est déclarée
dans la classe java nom de la classe suivi de Helper.
La méthode bind() peut être utilisée pour spécifier exactement
l'objet requis, ou bien en utilisant les paramètres par défaut.
Orbix web permet une certaine liberté dans le choix de l'objet.
Dans mes programmes clients, j'ai choisi de paramétrer la méthode
bind() comme suit :
xxxHelper.bind(String nom de l'objet ciblé:String nom du serveur, String adresse de la machine serveur)
Exemple :
GestionnaireHelper.bind("CA:ApplServeur","mass-handicap.univ-tlse2.fr");
CA est le nom de l'objet Gestionnaire (du Crédit Agricole) disponible sur le serveur.
Applserveur est le serveur d'objets,
mass-handicap.univ-tlse2.fr : adresse de la machine où le serveur est implanté
Schéma explicatif
Par simplicité, j'ai fait en sorte que mon client crée lui aussi des objets : Client, Operation, consultation.
Cependant, ce n'est pas la méthode qu'il faut adopter dans le cadre général, en effet l'on disposera plutôt
de plusieurs serveurs d'objets : un serveur de gestionnaire, un serveur de clients,
un serveur d'opérations ...ect.
Je n'ai implanté qu'un serveur de gestionnaires sur lesquels les objets crées côté client
peuvent invoquer des méthodes.
Trace d'exécution sur le serveur
(cf annexe)
Difficultés posées par la distribution
Durant la réalisation de mon application distribuée, j'ai rencontré
plusieurs difficultés liées à la distribution.
Ces problèmes sont d'ordre spatial et temporel.
Problèmes liés à l'espace
Ma première grande difficulté a été de savoir comment
répartir l'information.
Sur quel site
(client ou serveur ?) les objets doivent être implantés, crées ou utilisés
par les acteurs du système réparti.
En effet, dans une architecture client / serveur, le partage et la mobilité
de l'information et des programmes contribuent au bon fonctionnement
d'une application distribuée.
Il aurait été interessant dans mon application de créer plusieurs
serveurs d'objets.
- Un serveur de gestionnaires fournirait un gestionnaire pour chaque banque,
- Un serveur de comptes associés à un gestionnaire,
-
Un serveur de clients,
- ... etc.
Or mon application ne fonctionne pour l'instant
qu'avec un unique serveur d'objets :
le fournisseur de gestionnaires.
Le client sans le savoir crée lui-même les autres objets entrant dans la
"composition" des requêtes.
Cette implantation ne gère donc pas au mieux l'espace de distribution, et
engendre alors des problèmes temporels.
Problèmes liés au temps
Si les ressources sont mal réparties dans l'application, cela peut "alourdir"
et "ralentir" le routage de l'information.
Mon application étant succinte, je ne me suis pas vraiment rendu
compte de ces problèmes temporels.
Par ailleurs, il faudrait aussi vérifier un ensemble de critères théoriques tels que
la fiabilité, l'intégrité, la sécurité des données et la synchronisation des processus.