swing et tomcat

Le
olivier
bonjour à tous,

je travaille dans une boîte ou les développeurs utilisent assez
régulièrement swing pour développer des applications clients riches et
j'ai découvert dernièrement qu'ils utilisaient en parallèle avec swing
tomcat comme serveur d'application.

l'architecture est donc la suivante :

swing (interface client) -> requête http vers tomcat -> objets métiers
-> bdd

je m'interroge sur l'intérêt de cette architecture par rapport à un
client riche contenant déjà les objets métiers et faisant des appels
directs à la bdd, du style :

swing (interface client + objet métiers) -> bdd

en fait, quel intérêt d'un archi 3tiers par rapport à une archi
2tiers. je précise que personne chez nous n'utilise d'ejb. ce sont des
objets java "classiques".

je trouve qu'on se complique inutilement la vie, non ?
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
remy
Le #227407
bonjour

en gros et pour faire simple
cote serveur

objets_métiers_jdbc1
objets_métiers_jdbc2
obj client


Client client = new Client(new ApiJdbcImpl());
ou
Client client = new Client(new ApiJdbc2Impl());

client.getApi().fct();


***************************
public class Client {
ApiJdbc api;
public Client( ApiJdbc api) {
this.api = api;
}
public ApiJdbc getApi(){
return api;
}
****************************
public interface ApiJdbc {
public boolean fct();
}
************************
public class ApiJdbcImpl implement ApiJdbc
{
....
public boolean fct()
{
}
}
************
public class ApiJdbc2Impl implement ApiJdbc
{
....
public boolean fct()
{
}
}
**************

le client swing (cote utilisateur) il ne voie que la class client cote
serveur

a+ remy
--
http://remyaumeunier.chez-alice.fr/
olivier
Le #227406
oui, je comprend l'idée, par contre, comme tu communique avec le
serveur tomcat par http, tu vas devoir serialiser-deserialiser la
communication entre tes objets clients et serveur.

quel intérêt ?

rien ne t'empêche au niveau client d'avoir un objet metier et et un
objet jdbc (le metier appelle le jdbc), le jdbc exécute ensuite une
requete jdbc au serveur de base de données.

non ?
remy
Le #227405
oui, je comprend l'idée, par contre, comme tu communique avec le
serveur tomcat par http, tu vas devoir serialiser-deserialiser la
communication entre tes objets clients et serveur.


non parce que tu fait devrais faire du soap a mon avis



quel intérêt ?

rien ne t'empêche au niveau client d'avoir un objet metier et et un
objet jdbc (le metier appelle le jdbc), le jdbc exécute ensuite une
requete jdbc au serveur de base de données.

non ?


comment tu geres les differentes evolutions ou specifications
tu mets tout dedans ?

a+ remy




cfranco
Le #227404
olivier
je travaille dans une boîte ou les développeurs utilisent assez
régulièrement swing pour développer des applications clients riches et
j'ai découvert dernièrement qu'ils utilisaient en parallèle avec swing
tomcat comme serveur d'application.

l'architecture est donc la suivante :

swing (interface client) -> requête http vers tomcat -> objets métiers
-> bdd

je m'interroge sur l'intérêt de cette architecture par rapport à un
client riche contenant déjà les objets métiers et faisant des appels
directs à la bdd, du style :

swing (interface client + objet métiers) -> bdd

en fait, quel intérêt d'un archi 3tiers par rapport à une archi
2tiers. je précise que personne chez nous n'utilise d'ejb. ce sont des
objets java "classiques".

je trouve qu'on se complique inutilement la vie, non ?


Un des intérêts classiques est de permettre l'utilisation chez des
clients où les réseaux n'autorisent que le passage de flux HTTP (voir
HTTPS). Particulièrement intéressant quand tu as des utilisateurs
distants, cela peut éviter d'avoir à mettre en place des VPN et
autres...

En outre, cela permet de limiter énormément le nombre de connexions
simultanées à la base de données. Si tu as une application avec
plusieurs centaines d'utilisateurs, le serveur de base de données peut
apprécier.

Enfin, dans certains cas ça peut aussi permettre de libérer les postes
clients d'une partie du volume de travail, en le confiant à un ou
plusieurs serveurs qui n'ont que cela à faire. Même si de nos jours, la
tendance est plutôt à "charger" autant que possible les postes clients
qui ont de la puissance à ne plus savoir qu'en faire, et à pouvoir du
coup prendre de petits serveurs beaucoup moins couteux.


En dehors de ces avantages fonctionnels, cela permet aussi d'éviter les
tentations que pourraient avoir les développeurs de "bidouiller" dans le
code du client riche pour ajouter "vite fait mal fait" des
fonctionnalités de dernière minute. Ca décourage d'autant les décideurs
d'exiger de tels bidouillages...

--
Christophe Franco

cfranco
Le #227403
Christophe Franco
olivier
je travaille dans une boîte ou les développeurs utilisent assez
régulièrement swing pour développer des applications clients riches et
j'ai découvert dernièrement qu'ils utilisaient en parallèle avec swing
tomcat comme serveur d'application.

l'architecture est donc la suivante :

swing (interface client) -> requête http vers tomcat -> objets métiers
-> bdd

je m'interroge sur l'intérêt de cette architecture par rapport à un
client riche contenant déjà les objets métiers et faisant des appels
directs à la bdd, du style :

swing (interface client + objet métiers) -> bdd

en fait, quel intérêt d'un archi 3tiers par rapport à une archi
2tiers. je précise que personne chez nous n'utilise d'ejb. ce sont des
objets java "classiques".

je trouve qu'on se complique inutilement la vie, non ?


Un des intérêts classiques est de permettre l'utilisation chez des
clients où les réseaux n'autorisent que le passage de flux HTTP (voir
HTTPS). Particulièrement intéressant quand tu as des utilisateurs
distants, cela peut éviter d'avoir à mettre en place des VPN et
autres...


A ce sujet d'ailleurs, cela permet aussi de limiter le volume de données
qui transite sur le réseau, lorsqu'il faut récupérer de gros volumes de
données depuis la base de données alors qu'au final il y a un traitement
de l'information qui fait que le client n'a besoin que d'une toute
petite partie de ces données, si c'est le serveur Tomcat qui fait ce
traitement on aura un volume de données transitant vers le client qui
sera limité au strict nécessaire.


--
Christophe Franco


Jacques-Olivier Haenni
Le #227402
Bonjour,

Outre les avantages déjà mentionnés, cette architecture 3-tiers amène
également des avantages concernant la sécurité (par exemple, si le
client swing dialogue directement en jdbc avec la base de données,
qu'est-ce qui empêche un pirate de développer son propre client java qui
va se relier en jdbc sur la base ? Autre scénario: qu'est-ce qui
empêche ce pirate de développer un client qui stocke dans la base des
données invalides ? (en effet, certaines contraites métier ne peuvent
pas facilement être modélisées par des contraintes en base de
données)). Pour bénéficier d'une telle sécurité avec un client 2-tiers,
il faut développer des vues ou procédures stockées pour placer une
partie du traitement en base de données (et on se rapproche ainsi d'un
pseudo 3-tiers...).

Autre bénéfice potentiel: selon les cas, le tiers métier peut gérer un
cache pour les données, évitant ainsi des accès en base de données. De
même, il peut gérer des pools de ressources (par exemple un pool de
connexions JDBC).

Mais comme toujours, ces avantages ont un coût, comme cela a déjà été
relevé.

De plus, il n'existe pas d'architecture idéale convenant à toutes les
applications. Chaque problème a sa solution; chaque application a son
architecture propre. Si la solution miracle existait, ça se saurait...

Jacques-Olivier


Christophe Franco wrote:
Christophe Franco

olivier

je travaille dans une boîte ou les développeurs utilisent assez
régulièrement swing pour développer des applications clients riches et
j'ai découvert dernièrement qu'ils utilisaient en parallèle avec swing
tomcat comme serveur d'application.

l'architecture est donc la suivante :

swing (interface client) -> requête http vers tomcat -> objets métiers
-> bdd

je m'interroge sur l'intérêt de cette architecture par rapport à un
client riche contenant déjà les objets métiers et faisant des appels
directs à la bdd, du style :

swing (interface client + objet métiers) -> bdd

en fait, quel intérêt d'un archi 3tiers par rapport à une archi
2tiers. je précise que personne chez nous n'utilise d'ejb. ce sont des
objets java "classiques".

je trouve qu'on se complique inutilement la vie, non ?

Un des intérêts classiques est de permettre l'utilisation chez des

clients où les réseaux n'autorisent que le passage de flux HTTP (voir
HTTPS). Particulièrement intéressant quand tu as des utilisateurs
distants, cela peut éviter d'avoir à mettre en place des VPN et
autres...



A ce sujet d'ailleurs, cela permet aussi de limiter le volume de données
qui transite sur le réseau, lorsqu'il faut récupérer de gros volumes de
données depuis la base de données alors qu'au final il y a un traitement
de l'information qui fait que le client n'a besoin que d'une toute
petite partie de ces données, si c'est le serveur Tomcat qui fait ce
traitement on aura un volume de données transitant vers le client qui
sera limité au strict nécessaire.







Publicité
Poster une réponse
Anonyme