Discussion :

[Kalipseo]

Bonjour,

Ma question ne porte pas sur du code.
J'aurais voulu avoir plus de précision quant à la définition d'un client lourd.

Celle que j'ai à présent:

Il s'agit d'une application développée pour être exécutée sur un poste.
Le traitement des données est effectué sur celui ci, mais la persistance des données peut être effectuée par une BDD se trouvant sur un serveur en réseau locale, ou distant.

D'ailleurs dès que le traitement des données est effectué sur une machine distance on sort du contexte du client lourd, pour arrivé dans un contexte d'application gérer par une servlet?

Les avantages d'un client lourd, sont la vitesse d'exécution, l'ergonomie propres à ceux ci (Swing).

Les inconvénients d'un client lourd, sont le déploiement (Grandement amélioré par la mise en place de Java Web Start).

Donc il y aurait des ajouts, des modifications quant à la définition que j'en est? Des avantages/inconvénients que j'aurais oublié?

Merci d'avoir lu.

[kmdkaci]

Bonjour,
Généralement, un client qui n'est PAS lourd, est une application web exécutée via un navigateur. Ceci comporte le téléchargement de la page, les différents vas et viens entre client et serveurs...., dans la plus part des cas, c'était le protocole HTTP qui est utilisé....

Un client lourd, est ton application que tu installes sur ton poste, avec une interface pas aussi limité qu'une appli web.

Mais je trouve aussi les explications que tu as avancé sont suffisantes.

[Kalipseo]

Merci d'avoir répondu aussi rapidement.

Donc, la communication entre les postes où est déployé l'application lourde, et le serveur qui gère la BDD, ou qui permet de gérer la mise à jours grâce au protocole JNLP ne communique pas via http?

Donc il y aurais d'autres protocoles de communication que http qui serait utilisés dans se cas? Quels sont ils?

A moins que cela soit possible par http et que justement se soit le plus adapté à ce genre d'application, vis a vis de la disponibilité du fichier JNLP (Se situant sur un simple site web par exemple) et le fait de pouvoir passer a travers le firewall des postes?

Merci d'avoir lu.

[fr1man]

Avec un client lourd, tu peux choisir ton protocole de communication, selon que tu utilises des webservices, des ejbs pour communiquer avec ton serveur d'application.

[adiGuba]

Salut,


Il y a en fait 3 grands types d'application client/serveur :

Les clients lourds correspondent à des applications installées sur le poste client, ce qui permet de faire a peu près tout (il suffit de le coder ). En général le serveur sert principalement à fournir les informations (accès à la BD, etc.) et c'est l'application cliente qui traite les données. Par contre cela peut s'avérer assez lourd en déploiement surtout si l'application évolue beaucoup...
Actuellement c'est toujours utilisé sur des protocoles standard où les communications entre le client et le serveur sont figé et évolue peu (par exemple, les clients mails comme Outlook ou Thunderbird).

Les clients légers ont explosé en même temps qu'Internet se développait. En fait tout les traitements s'effectue sur le serveur, qui génère la page de résultat que le client léger se contente d'afficher. On utilise en général un navigateur web pour cela : l'affichage tout comme les fonctionnalité est donc fortement limité par rapport aux possibilités du HTML. Par contre cela ne nécessite aucune installation mis à part la présence d'un navigateur !
Pour conserver l'exemple du mail, les premiers webmails peuvent être considéré comme des clients légers, mais également la quasi-totalité des application web (pas besoin d'installer quoi que ce soit pour utiliser un site marchand ou même ce forum ).

Enfin, on parle également de clients riches, qui tentent de réunir le meilleurs des deux mondes, en permettant la création d'application complexe sans limitation ou presque (comme les clients lourds) sans poser de problème de déploiement (comme les clients légers).
La définition d'un client riche n'est pas très claire, mais consiste en fait à utiliser un runtime permettant d'effectuer des traitements complexes coté client, afin d'améliorer son expérience utilisateur.
Cela peut être simplement le cas d'une application à base d'Ajax (comme GMail ou les autres webmails modernes) ou d'un environnement plus complexe (Flash, Java, .NET ou autre).
En fait la différence avec un client léger vient du fait que cela nécessite en plus la présence d'un runtime sur le poste client (la JVM dans notre cas), et la différence avec un client lourd vient du déploiement, qui est généralement automatique et basé sur le protocole HTTP...


En fait Java Web Start te permet de faire du client riche :

• Le fichier JNLP permet de déployer simplement ton application tout en gérant les mises à jours via HTTP, à partir du moment où le client possède une JVM.
• Tu peux tout à fait communiquer avec ton serveur via le protocole HTTP pour accéder aux données.
• Tu es libre d'utiliser toutes l'API Java et des librairies externes, même native (toutefois, pour des raisons de sécurité, certaines fonctions dont l'appel de code natif nécessite des permissions de la part de l'utilisateur)

a++

[Kalipseo]

Merci pour ces précisions.

Donc au final, Java Web Start ne peux pas être appliquer à un réseau locale qui aurait besoin de faire tourner une application Lourde, afin de mettre à jours aisément et rapidement tout ces postes?

[adiGuba]

Pourquoi tu ne pourrais pas ??? Il suffit d'un serveur Web sur le réseau local...
Tu es bien en client/serveur ?

a++

[Kalipseo]

D'accord.

Donc en définitif, Java Web Start peut être utilisé pour déployer facilement des applications Lourdes, et Riches, via une machine serveur Web.

Tiens je profite pour avoir une petite précision:

Une application Riche peut traiter des données ou est obliger de les renvoyer au servlet? Car sinon elle n'est plus considérer comme une application Riche mais Lourde.

[adiGuba]

Une application riche n'est ni plus ni moins qu'une application lourde avec un mécanisme de déploiement automatique.

Elle peut faire ce qu'elle veut !

Après c'est plutôt une question de sécurité : peut-on faire confiance au poste client ???

a++

[Kalipseo]

Donc au final la technologie Java permet de développer:

Des Clients Lourds :
-Affichage/Traitement.
- Déploiement longs et fastidieux.
- Accès aux données en Locale ou en Réseau.

Des Clients Riches :
-Affichage/Traitement.
- Déploiement Rapide et facile (JWS).
- Accès aux données en Locale ou en Réseau.

Des Clients Légers :
-Affichage / Traitement (Langage de Scripting JSP, Javascript, PHP ...).
-Déploiement dûs aux navigateur Web.
-Traitement via Servlet(Tomcat) ou Serveur D'applications(Jonas ...).
- Accès aux données via Hibernate/JDBC/ EJB3.

De même qu'on peut trouver un traitement via Servlet et Serveur d'application pour un client Riche.

Donc j'ai émis des erreurs? Omis des choses?