Objectifs des TPs
Ces TPS doivent vous apprendre à :
Ecrire un protocole d’application d’un serveur de façon à ce qu’il soit suffisamment complet et précis pour qu’un client puisse être implémenté afin d’utiliser votre serveur
Appréhender des technologies telles que le RMI de Java qui permettent de générer automatiquement une grande partie des codes Client et Serveur
Déployer une application Client Serveur correctement sur les postes Client et Serveur


Description du sujet : un serveur de surnoms
Dans la lignée de services très utiles tels que ceux offerts par les serveurs de noms (DNS...) et les serveurs de clés, nous vous proposons de mettre en place un serveur de surnoms. Ce serveur stocke le nom associé au surnom d'un étudiant ou d'un enseignant du département SI de l'EPU. Deux personnes différentes ne peuvent pas avoir le même surnom mais une personne peut être affublée de plusieurs surnoms. Il doit être  possible par exemple d'enregistrer un nouveau surnom et un nom associé, de modifier l'enregistrement, de lister les noms et surnoms enregistrés dans le serveur. Le service offert ne sera pas persistant : il initialise les associations surnom - nom au lancement et perd les nouvelles associations lorsqu'il est arrêté.

Ressources
Vous pouvez vous référencer à
    aux cours  Sockets , IntroObjetRepartis , RMI et la réflexivité Java
    aux tutoriaux Java
et vous devez utiliser et compléter les classes suivantes :
Enseignant.java,
 Etudiant.java
Personne.java,
Surnom.java

Modalité des TPs
6 séances encadrées sont consacrées à ce travail.
Vous devez travailler en binôme et coopérer ponctuellement avec d'autres binômes dont un choisi par votre encadrant de TP

Partie Sockets (4 séances encadrées)


1. Communication client-serveur simplifiée en mode TCP

Etape 1
Choisissez un autre binôme avec qui coopérer.
Lister ensemble les requêtes offertes par votre serveur (appelées plus loin services). Vérifier que cela permet d'offrir un service complet, suffisant et correct.
Tirer au sort la sérialisation à mettre en œuvre (version Object ou chaîne de caractères).
Préparer un fichier protocoleDApplication.txt qui contient la description du protocole d’application et de la sérialisation.

Etape 2

A partir des informations contenues dans protocoleDApplication.txt :
Implémenter  le code du serveur qui implémente les services que vous avez listés précédemment. Le serveur n'est pas multi-clients dans un premier temps. Les services peuvent être incomplets (simulés).
Ecrire le code d'un client qui teste l'ensemble des services offerts par votre serveur.
Tester votre serveur avec votre client.
Tester à distance votre client avec le serveur développé par  le binôme collaborateur.
Si cela s’avère nécessaire, mettez à jour le fichier protocoleDApplication.txt

Etape 3

Votre encadreur affecte un nouveau binôme collaborateur
Vous vous échangez les fichiers protocoleDApplication.txt et toute classe Java qui pourrait être utile et toute autre communicatin ne doit se faire que si vous êtes bloqués pour réaliser a suite et uniquement par mail.
Ecrire le code d'un client qui teste l'ensemble des services offerts par le serveur du binôme collaborateur.
Tester à distance votre client avec le serveur développé par  le binôme collaborateur.
Si cela s’avère nécessaire, mettez à jour le fichier protocoleDApplication.txt (en cas d’échanges mails)

 

2. Questions de recul

Comment rendre le serveur multi-clients ?
Comment concevoir le serveur afin de pouvoir simplement réutiliser du code si le type de communication change ?
Quels seraient les principaux avantages et/ou inconvénients d'une communication par messages pour ce type de service ?

Supposons que le serveur de surnoms soit un serveur très important pour l'école et que nous soyons amenés à mettre en place des serveurs esclaves qui soient des copies de ce serveur. Pour simplifier nous utiliserons une communication en mode multicast dans laquelle tous les serveurs esclaves sont des clients du serveur principal. Via cette communication le serveur principal informe régulièrement (délai de temps) les serveurs esclaves de son état.

Quel est le protocole d'application que vous pourriez mettre en place pour cette partie ?
  Comment faire évoluer le code du client et du serveur afin de mixer le service de Surnoms et celui de "réplicats" ?

Partie RMI (2 séances  encadrées)

Vous allez tester et appréhender la communication réseau par RMI

Expliquer comment le service de surnoms aurait-il pu être développé en RMI ?
Ecrire le protocole d'application en RMI et implémenter un Client et un Serveur RMI qui implémentent au moins un des services.
Déployer votre service avec un autre binôme

Questions de recul

Quelles parties des codes Sockets se rapprochent le plus des stubs ? 
Comment la réflexivité Java est utilisée pour générer (ou remplacer) les stubs ?

RENDUS

à envoyer par email à votre responsable de TP (lito@polytech.unice.fr, faron@polytech.unice.fr, pinna@polytech.unice.fr) et à pinnapolytech.unice.fr au plus tard 48H avant le TP suivant
Les sujets des mails seront dans l'ordre des rendus demandés ci-dessous RENDU Sockets 1, RENDU Socket 2, RENDU RMI
Toute non conformité aux règles de rendus sera pénalisée.

Le fichier protocoleDApplication.txt en Semaine 2 (entre la deuxième et la troisieme séance)
Le fichier protocoleDApplication.txt en Semaine 4 + les codes Client et serveur + la réponse aux questions (entre la quatrième et la cinquième séance)
Un fichier RMI.txt expliquant le déploiement  pour un client (comparez avec le déploiement Socket)  +   les questions de recul en semaine 6 (entre la sixième semaine et l’exam)