je travaille dans une bo=EEte ou les d=E9veloppeurs utilisent assez
r=E9guli=E8rement swing pour d=E9velopper des applications clients riches et
j'ai d=E9couvert derni=E8rement qu'ils utilisaient en parall=E8le avec swing
tomcat comme serveur d'application.
je m'interroge sur l'int=E9r=EAt de cette architecture par rapport =E0 un
client riche contenant d=E9j=E0 les objets m=E9tiers et faisant des appels
directs =E0 la bdd, du style :
swing (interface client + objet m=E9tiers) -> bdd
en fait, quel int=E9r=EAt d'un archi 3tiers par rapport =E0 une archi
2tiers. je pr=E9cise que personne chez nous n'utilise d'ejb. ce sont des
objets java "classiques".
je trouve qu'on se complique inutilement la vie, non ?
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
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
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
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 ?
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.
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
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
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 ?
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
olivier wrote:
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.
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
olivier <lemoigne.olivier@gmail.com> wrote:
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.
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...
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.
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
Christophe Franco wrote:
olivier wrote:
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.
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
Christophe Franco <cfranco@pobox.com> wrote:
olivier <lemoigne.olivier@gmail.com> wrote:
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.
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.
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.
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
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 wrote:
olivier wrote:
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.
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.
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 <cfranco@pobox.com> wrote:
olivier <lemoigne.olivier@gmail.com> wrote:
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.
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.
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 wrote:
olivier wrote:
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.
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.
