[AVIS & BONNE PRATIQUE] application client / serveur

Bonjour à tous,

Voilà, dans le cadre du développement d'une application client/serveur en java, je me pose la question suivante :

Lors de la communication entre clients et serveurs, est-il préférable de n'établir la connexion avec le serveur qu'une seule fois, ou est-il préférable de rétablir la connexion lors de chaque nouvelle requête ?

Je m'explique :

Le serveur est un serveur multi-thread. Un thread est à l'écoute des demandes de connexions, et un pool est chargé de traiter les demandes des clients.
Ma question est de savoir, est ce que le thread du pool, termine la connexion avec le client une fois la réponse renvoyée, ou est-il préférable de garder la connexion établie entre les deux ?

Ou encore, est-il préférable d'utiliser le principe de time out entre les deux ?

En vous remerciant pour les informations et explications qu'il vous sera possible de me fournir afin de développer l'application le plus proprement possible.

p.s. : je viens de me rendre compte que je suis dans la mauvaise partie du forum, et vous prie de m'en excuser.

L'idéal est de rétablir la connexion à chaque request. Cela t'éviteras d'engorger ton serveur.
Imaginons que ton serveur ne puisse servir que 100 personnes à la fois, une fois ce nombre dépassé, ton serveur empêchera toute nouvelle connexion. Imagines maintenant que quelqu'un va boir son café, il gardera la connexion ouverte et n'en fera rien.

De manière générale dans les applis web Java, on établit la connexion à chaque request.
J'imagines que les utilisateurs vont s'authentifier, ils recevront donc un token, et à chaque request, ce token est envoyé, cela permet de savoir qui se connecte et du côté serveur, tu auras toutes les infos à ta disposition pour écrire ta logique.

Merci pour cette réponse.

A présent, il me reste à me pencher sur la question des tokens, et de comment les gérer ... ;-) (oui, mon serveur, n'est basé sur rien, tout est géré manuellement, donc pas de Glassfish, ou tout autre modules / framework / environnement).

Je ne comprends pas bien l'architecture de ton application. Est-ce que tu peux détailler?

Salut ruscov,

En fait, l'architecture de mon application peut se voir comme sur l'illustration ci-dessous :

http://admdy.be/img/struct-serveur.gif

Le Pipe 1 est utilisé uniquement pour la transmission de la Socket entre le Thread Ecoute et le pool de thread Traitement.

Le Pipe 2 est utilisé pour le transfert des "requêtes" entre le thread traitement et le thread DB.

Un Thread complémentaire n'est pas représenté dans l'état actuel de la chose. Il s'agit du Thread Admin. Ce dernier sera utiliser pour la gestion distante du serveur.

Côté client, rien de compliquer, lancement de l'application avec une fenêtre principale, qui ne s'affichera que si l'authentification s'est déroulée correctement.

Voilà, je ne sais pas si cela répond à ta question de l'architecture de mon application.

Et dans la pratique, tu utilises quoi comme technologie?

:whistle: technologie -> c'est à dire ?

Ma base de données est une MySQL, pour les threads, j'utilise le Framework Executor.
Pour la communication entre le client et le serveur, j'utilise des objets créé de toutes pièces avec les informations dont j'ai besoin.

Par contre, je viens de me rendre compte d'une chose à laquelle je n'avais pas pensé :
- Comment je récupère les résultats de mes requêtes venant de mon thread DB dans le bon thread du pool ?

Je vais me repencher sur ce problème.

Mais honnêtement, je ne vois pas ce que tu veux dire par technologie.

Je voulais comprendre un peu mieux ce que tu faisais techniquement mais en relisant j'ai compris.

Ayant une expérience plus orientée architecture web, je ne suis pas bien placé pour t'aider sur ce coup-là. Désolé.:?

Bonjour,

si je comprend bien l'architecture de ton application ,
tu as d'un coté un client lourd (swing, eclipse rcp, ....) et de l'autre une application serveur et la communication se fait par des socket.

en gros la communication entre les 2 se fais via un string. tu vas devoir établir un protocole de communication entre ton appli client et ton appli serveur et empécher q'uon appelle ton serveur par un autre moyen que ton appli client.

je fermerais la connexion a chaque requête ainsi tu évite le problème que si ton client plante, une connexion reste ouverte au niveau de ton serveur et de gérer les timeout.

ps : pourquoi une tel architecture de nos jours ? alors que le web est plus facile a implémenter. pas besoin d'inventer un protocole, gestion des sessions, pas besoin d'écrire un client, plus facile a déployer, ...

Alors, pour en revenir aux réponses, et ceci avec un peu de retard.

Tout d'abord, merci pour le coup de clavier.

Effectivement fennec_, il s'agit bien d'une telle architecture (client lourd, et tout le reste).

Le pourquoi d'une telle solution, je ne sais pas. Etant seul informaticien ici, chaque décision est prise sur mes seules connaissances. Et, n'ayant pas trop envie de me planter, je parcours, très / trop souvent, divers forums et sites, dont developpez.com.

Le pourquoi une architecture comme celle décrite, plutôt simple la réponse en fait. Je n'ai pas la moindre idée de comment développez une application java en web. Les seuls langages connus pour le web, sont le html, le php (sans la couche O.O), et le css pour la mise en forme.
Je pense également, que lorsque l'on développe une application web en java, il faut un Glassfish ou autre pour gérer le tout non ? Si mes souvenirs sont bons, Glassfish est payant, et le but ici, est justement de ne pas avoir à débourser (à part mes prestations :-P).

Corrigez moi si je me trompe d'un côté comme de l'autre, je suis ouvert à toutes informations permettant d'améliorer les performances / rendement / faisabilité / facilité de déploiement / ...

En vous remerciant pour votre collaboration, je vous souhaite à tous, une bonne journée.

Si tu es libre, je te conseille franchement une arhitecture web. Ca te coutera 0 en technologie. Tu peux utiliser Tomcat qui est gratuit.
Tu peux profiter de l'occasion pour apprendre le Java Web, ca te fera un beau plus sur ton CV. Quand tu regardes les offres d'emploi en Java, c'est orienté web à 90%. Le client lourd est très marginal.

Tu as pas mal de tuto complet sur developpez.com. Je te conseille de commencer par http://tahe.developpez.com/java/baseswebmvc/

Glassfish est gratuit et sert de référence pour les implémentations de serveurs JavaEE.

Mais utiliser un serveur JavaEE peut s'avérer de l'overkill comparé à un conteneur de servlet tel que Tomcat. Si tu n'as pas besoin de ce qu'offre les spécifications, Tomcat suffit amplement.

Bon, en ce qui concerne le "sérieux plus" sur le CV, mouais, travaillant dans une administration, je ne pense pas avoir besoin d'un plus.
Malheureusement, énormément de société demande des preuves de connaissances (soit une certification, ou encore un diplôme). Dans mon cas, il n'y en aura pas à la clé.
Mais je vais me pencher plus en profondeur sur la solution Tomcat (les servlets, quel laids souvenir d'école).
En vous remerciant une fois de plus pour les informations fournies.

Citation:

---

Malheureusement, énormément de société demande des preuves de connaissances (soit une certification, ou encore un diplôme).

---

Habitant aussi en belgique et étant un habitué des interviews, on ne m'a fait passé des tests techniques que très rarement et on m'a jamais demandé mon diplôme...

Citation:

---

Mais je vais me pencher plus en profondeur sur la solution Tomcat (les servlets, quel laids souvenir d'école).

---

Pas nécessairement, tu as des frameworks comme Struts 2 ou Spring MVC qui sont beaucoup plus agréable à utiliser. Tu dois juste comprendre le principe de l'architecture n-tiers et c'est ok! Après c'est pas plus compliqué que n'importe quelle techno.

tu as plein de solutions pour ton probleme :

la tienne (recoder tout ce qui est échange réseau a la main) ainsi que la gestion du threadind du serveur : c'est tres casse gueule, et tu vas perdre beaucoup de temps.

t'appuyer sur ce qui existe deja pour faire ce genre de choses.

si un protocole déconnecté te suffit : t'appuyer sur http et tout ce qui existe dans le monde java pour faire du web.
ca va effectivement des serveurs d'applications jusqu'a des microframework comme sparkjava

je te conseille vivement la deuxieme approche ;)

Bonjour,

Alors, j'ai enfin configurer mon netbeans avec Tomcat, maintenant, reste à comprendre à quoi vont me servir struts et spring et me lancer dans l'analyse de la mise en place de ces deux bêtes de guerre dont tout le monde parle, et dont je n'ai jamais rien compris... 8O

Il y a des tonnes et des tonnes de tutos bien foutus sur le net et sur développez!

mouais, encore faudrait-il que j'ai la paix pour lire l'un de ces tutos sans être interrompu toutes les 4 minutes par un coup de téléphone du genre :" j'arrive pas à imprimer", "comment est-ce que je peux faire des cartes de visites sous Word ?", j'en passe en des meilleures ...

Même pour développer tout court en fait. Tu ne sais pas développer si on t'interromps tout le temps.

Sinon j'ai une solution : https://www.youtube.com/watch?v=PtXtIivRRKQ :mrgreen:

bon, cet après-midi était plus calme.

J'ai (re)commencer le tuto trouvé sur developpez.com (rédigé par Serge Tahe) nommé "Introduction à STRUTS2 par l'exemple", et je dois dire que :arf:

Le tuto est très bien fait, rien à redire, mais non d'un chien, que struts est casse pied au niveau de la syntaxe ...
Si dans un fichier on nomme avec majuscule et pas dans le suivant-> boum error 500 lors du test.

Enfin bref, je vais poursuivre mon apprentissage de struts, et je verrais bien où j'en serais à la fin (par contre, je pense que je ne me ferais jamais à toutes les balises).

Après struts, je me lancerai peut-être dans spring...

franchement si tu utilsies spring : oublie struts : spring integre deja un framework web tres bien fait : ca fait ca de moins a apprendre