Architecture client/serveur TCP (socket)

Résolu
Noemie O'connor Messages postés 78 Date d'inscription mercredi 27 novembre 2013 Statut Membre Dernière intervention 12 novembre 2014 - 27 sept. 2014 à 17:52
Noemie O'connor Messages postés 78 Date d'inscription mercredi 27 novembre 2013 Statut Membre Dernière intervention 12 novembre 2014 - 28 sept. 2014 à 11:49
Bonjour à tous,

Dans le cadre d'utilisation du package java.net (Socket, SocketServer,...) pour le développement d'une application serveur, comment organiseriez vous vos différents objets afin de réaliser quelque chose de fonctionnel et d'évolutif?

Par exemple, on pourrait faire un objet connexion qui va se charger de gérer le socket et d'attendre une requête. Une fois un requête reçue on pourrait utiliser une Factory qui determinerait comment réagir face a la requête (appel d'un service dans un nouveau thread par exemple).
Cela vous semble-il suffisant? En termes de sécurité, à quoi serait-il bon de penser pour sécuriser les transmissions? Un système de cryptage asymétrique (clés privée/publique)?

Merci pour vos opinions! :)
N
A voir également:

2 réponses

KX Messages postés 16739 Date d'inscription samedi 31 mai 2008 Statut Modérateur Dernière intervention 19 mai 2024 127
Modifié par KX le 27/09/2014 à 18:41
Bonjour,

Déjà pourquoi repartir aussi bas niveau que les socket ? Tu pourrais très bien faire des EJB, du JAX-WS, JAX-RS...

En terme d'organisation du projet il faudrait faire 4 livrables, a) le serveur, b) le client, c) l'api : uniquement des interfaces, éventuellement des bean qui font le pont entre client et serveur, d) le common : les classes abstraites ou utilitaires communes entre client/serveur.

Pour la factory je ne suis pas convaincu, il faudrait voir ce que tu veux faire exactement entre ton client et ton serveur.

En terme de sécurité il serait bon de ne pas réinventer la roue, Java intègre déjà de la sécurité (SSLSocket par exemple).
La confiance n'exclut pas le contrôle
0
Rejoignez-nous