ANNEXE D

                                               FORUM de la MJES

                                               Dossier Technique

     Cette annexe présente une description technique du travail qui a été réalisé pour la mise en place du service FORUM du ministère. Tout au long de ce dossier il sera question de présenter la technologie utilisée dans le processus de programmation de l’application ainsi que des différents composants qui les constituent afin de mieux faciliter l’étape de son intégration au sein du portail et de permettre aussi son suivi dans le futur. Le lecteur sera ,vers la fin, averti des problèmes qui peuvent suivre le processus d’intégration et des solutions envisageables.  

1        Technologie utilisée  

Notre application de FORUM utilise la technologie JAVA RMI pour la réalisation d’un environnement client-serveur. RMI (Remote Method Invocation) permet de réaliser des applications distribuées de Java à Java, dans lesquelles les méthodes d’objets éloignés peuvent être invoquées à partir d’autres machines virtuelles pouvant résider dans d’autres ordinateurs. Autrement dit, un programme Java peut appeler une méthode se trouvant sur un autre ordinateur et ce, de façon totalement transparente, à condition qu’elle soit écrite en Java.

L’utilisation de JAVA comme langage de programmation permet d’assurer la portabilité de l’application sur les différentes plates-formes et de permettre une programmation purement Orienté Objet. La Fig. D.1 met à l’évidence la manière avec laquelle RMI assure la transparence de notre application que se soit vis à vis de l’environnement client ou du réseau d’interconnexion. Cette transparence est assurée par un environnement en couche applicative qui sera adapté à la nature de l’application.

Fig. D.1 - le schéma fonctionnel de RMI

2       Composantes de l’application :

Notre application est formée essentiellement de trois parties principales qui interagissent entre eux en vue d’assurer le service souhaité.  Ces trois parties sont :

Dans ce qui suit, ces trois composantes seront détaillées une à une pour mieux comprendre leurs processus d’intégration.  

2.1              Le Serveur FORUM_Server 

Ce serveur est constitué essentiellement d’une implémentation d’un objet distant « ServerImpl.class » et d’un ensemble de modules permettant la gestion et le suivi des différentes connections.

L’objet « ServerImpl » contient un ensemble de méthodes qui vont être appelées par les applications clientes tout au long de leur existence.

Pour le moment, il y a trois modules avec le ServerImpl : « ConnectionsVector » et « LogConnection » « LogDeconnection ». Le premier est utilisé pour assurer un nettoyage automatique de la BD au fur et à mesure de l’avancement du processus d’exécution, les deuxième et le troisième assurent la création de fichiers journal afin de garder l’historique de l’ensemble de connections et déconnections clientes.     

2.2            La partie cliente 

      Elle est formée de deux applettes qui vont établir une connexion réseau automatique avec le serveur du FORUM. Il y’a l’applette d’administration qui sera utilisée uniquement par l’administrateur du FORUM pour la gestion des différentes conférences et de différents utilisateurs. La deuxième applette est celle de la communication qui sera utilisée par le jeune pour accéder à la conférence à laquelle il est inscrit. 

2.3            La partie BD 

Afin de garder toutes les informations concernant l’ensemble de conférences ainsi que les invités et les messages qui transitent, le serveur interagit avec une base de données relationnelle réalisée pour le moment à l’aide de Microsoft Access. Cette base, et selon le besoin actuel du FORUM, est formée de trois tables reliées entre eux par des contraintes d’intégrités référentielles (jointure de type une à plusieurs). La fig. D.2 donne une représentation des différentes tables ainsi que le schéma relationnel entre eux. 

Fig. D.2 - le schéma conceptuel de la BD

3                   Installation 

Vu la technologie avec laquelle notre application a été conçue, le processus d’installation de différents composants nécessite un certain nombre de règles qu’il faux satisfaire.

3.1            Installation Serveur 

Il faut que l’environnement serveur soit muni d’une machine virtuelle 1.3 ou plus supportant le RMI. Le serveur sera livré avec un fichier batch « server.bat » qui permet de le lancer automatiquement sans aucun problème. Vu que le répertoire d’installation vari d’un système à un autre, il est donc utile de commenter les différentes lignes de ce fichier « server.bat ».

C :> edit server.bat

# Il faut positionner le classpath  sur le répertoire d’installation du serveur.

set classpath=C:\Inetpub\chat\server 

# Cette ligne permet en cas de besoins de recompiler tous les fichiers formant le serveur.

c:\jbuilder5\jdk1.3\bin\javac -deprecation *.java

# Cette ligne crée à partir du ServerImpl, les fichier ServerImpl _stub et ServerImpl #_skeleton qui serons utilisés pour établir une connexion en toute transparence entre client et   # serveur. 

c:\jbuilder5\jdk1.3\bin\rmic ServerImpl

# Cette ligne permet de lancer le serveur avec des options préétablies.

# La première concerne la politique de sécurité utilisée par le serveur pour permettre les

# connections distantes des clients. Cette politique mentionnée dans le fichier « policy » qui   # trouve avec le serveur et il est bien configuré. La deuxième indique  l’URL où le serveur 

# publie les classes qui serons téléchargées par le client pour établir la connexion avec l’objet

# distant serveur.

c:\jbuilder5\jdk1.3\bin\java  -Djava.security.policy=policy   -Djava.rmi.server.codebase =http://www.jeunesse.tn/webpub   ServerImpl

Remarque : il faut que le stub soit publié dans le répertoire publique du serveur de la jeunesse.

3.2             Installation du client 

L’installation de la partie cliente varie selon son mode d’utilisation. En effet la partie cliente pourra être utilisée soit comme une applette intégrée dans une page WEB ou bien au sein d’une application indépendante qui sera installée une fois pour toute.

C’est dans le premier cas où il y a le plus de problèmes. En effet l’applette sera téléchargée à partir du site du portail pour être interprétée par la machine virtuelle du navigateur client, or il y a encore quelques problèmes avec la compatibilité de certains navigateurs avec la technologie RMI et aussi avec certains environnements graphique.

Dans le deuxième cas à savoir celui de l’application, la partie cliente sera livrée avec un programme d’installation qui assurera une compatibilité totale avec l’environnement du client.        

3.3            Installation de la BD 

Pour la partie BD il suffit d’ajouter une source de données ODBC au nom de « chat » vers le chemin de la base Access.

4                    Schéma global de fonctionnement

La figure D.3 résume le processus global de fonctionnement de l’application forum.

 Fig. D.3 – Schémas global de fonctionnement.

1 : Le serveur ServerImpl s’enregistre auprès du serveur de nom tout en publiant le stub    pour être disponible en téléchargement par le client.

 2 : Un client demande un objet distant au serveur.

 3 : Le serveur de nom lui retourne une instance de ServerImpl_stub.

 4 : Le client demande ServerImpl_stub qui se trouve dans le répertoire de publication du serveur.

5 : le serveur WEB de la jeunesse lui renvoi le ServerImpl_Stub class.

Une fois le téléchargement du Stub s’est bien terminé, le client pourra communiquer avec l’objet distant serveur en toute transparence.