> Tech > La classe Java côté serveur

La classe Java côté serveur

Tech - Par iTPro - Publié le 24 juin 2010
email

La classe côté serveur RemoteDatabase Server met en oeuvre l'interface RemoteDatabaseServerInf afin que classe côté client puisse envoyer un objet java.rmi.Remote vers la classe côté serveur en utilisant l'interface. Elle étend la classe Java java.rmi.server. UnicastRemoteObject, ce que vous devez faire pour tous les objets Java à  distance si vous

La classe Java côté serveur

utilisez RMI. Cette méthode
vous permet d’utiliser le code
déjà  présent, ce qui est toujours judicieux.

La méthode main() de la classe démarre
le RMI Registry, crée une instance
de la classe RemoteDatabase-
Server, puis lie cette instance au RMI
Registry. Ensuite, elle attend une requête
de la part du client. La méthode
envoie des messages à  la sortie standard
pour vous indiquer ce qui se
passe et pour vous informer d’erreurs
éventuelles.

RMI requiert que la classe à  distance
ait un constructeur de classe. Le
constructeur de classe doit émettre
une erreur java.rmi.Remote Exception
et exécuter le constructeur de la superclasse.

Le constructeur RemoteDatabase-
Server définit le gestionnaire de sécurité
d’après le gestionnaire de sécurité
RMI. Côté serveur, le gestionnaire de
sécurité RMI empêche le processus
serveur d’endommager la machine
hôte et empêche tout client d’utiliser
le serveur de manière malveillante. Le
constructeur obtient ensuite une
connexion avec la base de données en
utilisant la méthode getDatabase
Connection().

Toute l’action se déroule dans la
méthode getInvoice(). Quand la classe
Java côté client invoque un appel à  distance
vers cette méthode, un driver
JDBC-ODBC extrait la facture requise de la base de données. Si un enregistrement
est extrait correctement, la
méthode crée un objet Invoice pour
encapsuler l’information de facture. Si
une facture n’est pas trouvée, une référence
nulle à  un objet Invoice est renvoyée
à  l’appelant.

A noter que la méthode getInvoice-
() est définie comme une méthode
synchronisée parce que le serveur
peut être appelé simultanément par
plus d’un client. RMI traitera automatiquement
des requêtes multiples, mais
en rendant getInvoice() synchronisé,
nous verrouillons la méthode pour la
protéger contre un accès synchrone :
ainsi, deux requêtes de client ne pourront
pas se gêner mutuellement.
Chaque requête client devra attendre
que la requête client précédente ait été traitée, avant de pouvoir accéder à  la
méthode getInvoice().

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010