OVH Cloud OVH Cloud

JSP ou SERVLET ?

12 réponses
Avatar
Mathieu
Quelles sont les différences ?

Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.

Merci

Mathieu

10 réponses

1 2
Avatar
Stephane Zuckerman
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.



Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment écrits
en Java par derrière).


--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Avatar
Fabien Bergeret
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.




Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment écrits
en Java par derrière).


Précisons : la servlet, et la jsp sont exécutées coté serveur, en

peuvent envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par une servlet (connexion BDD, envoi requête, construction d'une liste
de livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.


Avatar
Mathieu
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?

Mathieu


"Fabien Bergeret" a écrit dans le
message de news: 42e65a23$0$7835$
Stephane Zuckerman wrote:
Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.




Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).


Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent

envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.




Avatar
Lasher
Mathieu wrote:
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?


Oui, puisque tout se passe du côté serveur. Seules les entrées du client
doivent être vérifiées, théoriquement.

--
Stéphane ZUCKERMAN

Avatar
Fabien Bergeret
Mathieu wrote:
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?

Mathieu


"Fabien Bergeret" a écrit dans le
message de news: 42e65a23$0$7835$

Stephane Zuckerman wrote:

Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent remplacer
les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.




Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou bien
(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).




Précisons : la servlet, et la jsp sont exécutées coté serveur, en peuvent
envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet sont
orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée par
une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.




Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM

(je parle bien d'une archi standard servlet/jsp sans serveur d'application).
Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.

Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime




Avatar
Mathieu
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?

Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?

Mathieu



"Fabien Bergeret" a écrit dans le
message de news: 42e692e1$0$7116$
Mathieu wrote:
Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?

Mathieu


"Fabien Bergeret" a écrit dans
le


message de news: 42e65a23$0$7835$

Stephane Zuckerman wrote:

Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent
remplacer





les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.




Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou
bien




(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).




Précisons : la servlet, et la jsp sont exécutées coté serveur, en
peuvent



envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet
sont



orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée
par



une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.




Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM

(je parle bien d'une archi standard servlet/jsp sans serveur
d'application).

Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.

Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime






Avatar
Stephane Zuckerman
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?

Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?


La question est trop vague. Comme il a déjà été dit auparavant, les JSP
sont surtout là pour la partie "mise en forme", et ne sont pas censés
effectuer de traitements lourds.

Si l'on doit faire un traitement "métier" (c'est presque toujours le cas),
alors la servlet permet de faire le pont entre le côté métier et le côté
présentation.

Enfin, ensuite, il y a d'autres modèles plus avancés qui existent (voir
Struts, Spring, JSF, et le pattern MVC en règle générale).

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Avatar
ZebX
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?


A moins de vouloir réinventer la roue, aimer le code illisible,
programmer pour programmer, chronométrer au centième les perfs,
travailler sur une application extraordinaire, tu trouveras d'excellents
guides archi-connus au travers des tutoriaux de sun, de struts ou de
string, eclipse au travers le plugin WST. (J'indique ce que je connais,
y'a peut être mieux).


--
ZebX - Mécano-boucher

Avatar
Fabien Bergeret
Mathieu wrote:
Est ce mieux d'ecrire une seule servlet qui effectuerai differentes
operations?

Appelee de differents jsp en passant un parametre que l'on controlerai alors
dans le code de la servlet et suivant cela on effectuerai l'operation?
Ou plusieurs servlet qui effectue chacune une operation distinct ?

Mathieu



"Fabien Bergeret" a écrit dans le
message de news: 42e692e1$0$7116$

Mathieu wrote:

Ok donc faire communiquer un jsp avec une servlet c'est bon, et est ce
fiable point de vue securite ? point de vue performance ?

Mathieu


"Fabien Bergeret" a écrit dans



le

message de news: 42e65a23$0$7835$


Stephane Zuckerman wrote:


Je pensais que les jsp etait pour le cote client et alors qu'on gerait
les
bd et autre du cote serveur avec les servlet.
Apparement si j'utilise (ou meme pas) des beans , ils peuvent






remplacer

les
servlet . OUI ou NON ???

Je suis un peu perdu dans ce concept.




Les deux sont exécutées côté serveur.

De ce que j'ai compris, une JSP est compilé, et est en réalité une
servlet
spéciale. Simplement, là où une servlet "classique" est faite de pur
Java,
une "servlet JSP" permet de mélanger du code HTML à du code Java ou





bien

(et c'est préférable) à des tags personnalisés (qui sont évidemment
écrits
en Java par derrière).




Précisons : la servlet, et la jsp sont exécutées coté serveur, en




peuvent

envoyer du HTML (ou autre) au client.
Toutefois, les JSP sont orientées présentation, alors que les servlet




sont

orientées traitement.
Dans une architecture "standard", la requête issue du navigateur client
(je recherche tous les livres dont l'auteur est "Asimov") est traitée




par

une servlet (connexion BDD, envoi requête, construction d'une liste de
livre), qui transmet les données résultant du traitement (la liste de
livres) à la JSP, qui genère le HTML et l'envoie au client.




Sécurité = no soucy : la servlet et la jsp s'exécutent sur la même JVM

(je parle bien d'une archi standard servlet/jsp sans serveur


d'application).

Les mécanismes de sécurité entrant en jeu sont les mécanismes std J2EE,
où l'on peut restreindre certaines url à certains rôles.

Niveau perf : dès que l'on hiérarchise une application en couche, et
c'est bien le cas (avec une séparation traitement/présentation), le
franchissement d'une couche à un coût.
Mais ce coût est minime




Dans une approche servlet/jsp pure, il est tres fortement deconseille de

proceder de la sorte (l'approche est alors de créer une classe servlet
de base qui factorise le comportement communde toutes les servlets de
ton appli, et de l'etendre, pour creer une servlet pour chaque action
unitaire de ton appli).
Si l'on s'appuie sur un framework tel que struts, il existe une seule
servlet, mais qui n'a aucune valeur ajoutee d'un point de vue
traitement, et qui redistribue les appels vers des "actions" suivant un
fichier xml de mapping.






Avatar
Mathieu
Donc tu me dis de creer plusieurs Jsp.
Une servlet Mere qui fera appel a des servlet fille pour exeuter tel Jsp ?
Si c'est ca je vais me lancer dans la doc car je ne vois pas encore comment
effectuer l'appel d'une servlet a partir d'une autre.
Sinon en faisant comme ca qu'elle est le gain ?

Mathieu

Dans une approche servlet/jsp pure, il est tres fortement deconseille de
proceder de la sorte (l'approche est alors de créer une classe servlet
de base qui factorise le comportement communde toutes les servlets de
ton appli, et de l'etendre, pour creer une servlet pour chaque action
unitaire de ton appli).
Si l'on s'appuie sur un framework tel que struts, il existe une seule
servlet, mais qui n'a aucune valeur ajoutee d'un point de vue
traitement, et qui redistribue les appels vers des "actions" suivant un
fichier xml de mapping.


1 2