Bonsoir à tous,
Je m'excuse par avance de la longueur de mon message. Je m'adresse à
vous parce que je travaille actuellement sur l'architecture d'un jeu
Java EE libre. Et je pense humblement pouvoir vous intéresser, voire
même pouvoir lancer un vrai débat.
Ce jeu est pour le moment basé uniquement sur le Web, mais l'intérêt
principal que nous voyons à le faire libre est la volonté que nous
avons de créer une communauté (de "techniciens" : développeurs,
graphistes, musiciens...) qui pourraient le faire évoluer tout autant
que nous. Nous cherchons donc à le fonder sur une architecture
technologiquement neutre, bien qu'il soit fait en Java, et extensible.
Language-neutral aussi bien que vendor-neutral, comme auraient pu dire
nos amis les Anglais. :-)
Pour y parvenir, nous réfléchissons à une architecture applicative
classiquement basée sur les 3 couches que sont la vue (interface,
présentation), le métier (le jeu et ses règles) et le modèle (les
données et leur persistance). Cependant, et c'est je pense un peu plus
original, nous envisageons de mettre chacune de ces 3 couches logiques
sur son propre serveur d'application.
Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Quel est l'intérêt d'une telle architecture, me direz-vous, aussi
lourde et complexe à gérer ? Et bien, encore une fois, nous voulons un
jeu ouvert et évolutif. Et l'on peut par exemple avec ce modèle
imaginer remplacer le client léger Web (programmé par nous) par un
client lourd en 3D programmé en C (par des membres de la communauté).
Il "suffit" de remplacer le Tomcat gérant la vue par un serveur adapté
au nouveau client, qui communiquerait avec le même "serveur métier"
que le dit Tomcat. Et les deux peuvent idéalement fonctionner ensemble
et donner le choix au joueur entre un client 2D léger (au sens
habituel du terme "léger") ou un client en 3D plus lourd (au sens
habituel du terme "lourd"), avec les mêmes possibilités de jeu.
De même, nous avons dans le jeu des espèces extra-terrestres, 69 pour
être plus précis. Nous n'en ferons que 6. Et bien, en ajoutant un
nouveau "serveur métier" des contributeurs pourraient créer une
nouvelle espèces et la gérer eux-mêmes. Elle cohabiterait alors avec
les nôtres. Et si le modèle est suffisamment neutre, le nouveau
serveur métier pourrait là encore dialoguer avec un "serveur de vue"
quelconque et donc donner un choix en ce qui concerne le client.
La même idée pourrait bien sûr s'appliquer aux serveurs de données,
bien que l'intérêt de répartir les couches logiques sur des machines
physiques soit, là, moins évident.
Il paraît que l'on vient sur les newsgroups pour poser des questions
et y répondre :-) Alors ma question est :
notre jeu est un jeu basé sur un monde de science-fiction : cette
architecture vous paraît-elle elle aussi de la science-fiction ?
Qu'ajouteriez-vous ? Qu'enlèveriez -vous ? Et surtout : quelles
technologies emploieriez-vous pour faire communiquer les différents
type de serveur ?
On peut en effet imaginer des servlets, des Web Services, des EJB et
j'en oublie. Mais en restant dans le cadre de départ d'un client léger
HTML avec un moteur de servlets derrière et d'une base de donnée
relationnelle, les façons de remplir notre contrat laissent ouvert, je
pense, un grand choix possible de technologies. Lesquelles nous
conseilleriez-vous ?
Voilà, désolé pour ceux qui se sont endormis et merci d'avance pour
toute idée.
Pierre Goupil
Bonsoir à tous,
Je m'excuse par avance de la longueur de mon message. Je m'adresse à
vous parce que je travaille actuellement sur l'architecture d'un jeu
Java EE libre. Et je pense humblement pouvoir vous intéresser, voire
même pouvoir lancer un vrai débat.
Ce jeu est pour le moment basé uniquement sur le Web, mais l'intérêt
principal que nous voyons à le faire libre est la volonté que nous
avons de créer une communauté (de "techniciens" : développeurs,
graphistes, musiciens...) qui pourraient le faire évoluer tout autant
que nous. Nous cherchons donc à le fonder sur une architecture
technologiquement neutre, bien qu'il soit fait en Java, et extensible.
Language-neutral aussi bien que vendor-neutral, comme auraient pu dire
nos amis les Anglais. :-)
Pour y parvenir, nous réfléchissons à une architecture applicative
classiquement basée sur les 3 couches que sont la vue (interface,
présentation), le métier (le jeu et ses règles) et le modèle (les
données et leur persistance). Cependant, et c'est je pense un peu plus
original, nous envisageons de mettre chacune de ces 3 couches logiques
sur son propre serveur d'application.
Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Quel est l'intérêt d'une telle architecture, me direz-vous, aussi
lourde et complexe à gérer ? Et bien, encore une fois, nous voulons un
jeu ouvert et évolutif. Et l'on peut par exemple avec ce modèle
imaginer remplacer le client léger Web (programmé par nous) par un
client lourd en 3D programmé en C (par des membres de la communauté).
Il "suffit" de remplacer le Tomcat gérant la vue par un serveur adapté
au nouveau client, qui communiquerait avec le même "serveur métier"
que le dit Tomcat. Et les deux peuvent idéalement fonctionner ensemble
et donner le choix au joueur entre un client 2D léger (au sens
habituel du terme "léger") ou un client en 3D plus lourd (au sens
habituel du terme "lourd"), avec les mêmes possibilités de jeu.
De même, nous avons dans le jeu des espèces extra-terrestres, 69 pour
être plus précis. Nous n'en ferons que 6. Et bien, en ajoutant un
nouveau "serveur métier" des contributeurs pourraient créer une
nouvelle espèces et la gérer eux-mêmes. Elle cohabiterait alors avec
les nôtres. Et si le modèle est suffisamment neutre, le nouveau
serveur métier pourrait là encore dialoguer avec un "serveur de vue"
quelconque et donc donner un choix en ce qui concerne le client.
La même idée pourrait bien sûr s'appliquer aux serveurs de données,
bien que l'intérêt de répartir les couches logiques sur des machines
physiques soit, là, moins évident.
Il paraît que l'on vient sur les newsgroups pour poser des questions
et y répondre :-) Alors ma question est :
notre jeu est un jeu basé sur un monde de science-fiction : cette
architecture vous paraît-elle elle aussi de la science-fiction ?
Qu'ajouteriez-vous ? Qu'enlèveriez -vous ? Et surtout : quelles
technologies emploieriez-vous pour faire communiquer les différents
type de serveur ?
On peut en effet imaginer des servlets, des Web Services, des EJB et
j'en oublie. Mais en restant dans le cadre de départ d'un client léger
HTML avec un moteur de servlets derrière et d'une base de donnée
relationnelle, les façons de remplir notre contrat laissent ouvert, je
pense, un grand choix possible de technologies. Lesquelles nous
conseilleriez-vous ?
Voilà, désolé pour ceux qui se sont endormis et merci d'avance pour
toute idée.
Pierre Goupil
Bonsoir à tous,
Je m'excuse par avance de la longueur de mon message. Je m'adresse à
vous parce que je travaille actuellement sur l'architecture d'un jeu
Java EE libre. Et je pense humblement pouvoir vous intéresser, voire
même pouvoir lancer un vrai débat.
Ce jeu est pour le moment basé uniquement sur le Web, mais l'intérêt
principal que nous voyons à le faire libre est la volonté que nous
avons de créer une communauté (de "techniciens" : développeurs,
graphistes, musiciens...) qui pourraient le faire évoluer tout autant
que nous. Nous cherchons donc à le fonder sur une architecture
technologiquement neutre, bien qu'il soit fait en Java, et extensible.
Language-neutral aussi bien que vendor-neutral, comme auraient pu dire
nos amis les Anglais. :-)
Pour y parvenir, nous réfléchissons à une architecture applicative
classiquement basée sur les 3 couches que sont la vue (interface,
présentation), le métier (le jeu et ses règles) et le modèle (les
données et leur persistance). Cependant, et c'est je pense un peu plus
original, nous envisageons de mettre chacune de ces 3 couches logiques
sur son propre serveur d'application.
Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Quel est l'intérêt d'une telle architecture, me direz-vous, aussi
lourde et complexe à gérer ? Et bien, encore une fois, nous voulons un
jeu ouvert et évolutif. Et l'on peut par exemple avec ce modèle
imaginer remplacer le client léger Web (programmé par nous) par un
client lourd en 3D programmé en C (par des membres de la communauté).
Il "suffit" de remplacer le Tomcat gérant la vue par un serveur adapté
au nouveau client, qui communiquerait avec le même "serveur métier"
que le dit Tomcat. Et les deux peuvent idéalement fonctionner ensemble
et donner le choix au joueur entre un client 2D léger (au sens
habituel du terme "léger") ou un client en 3D plus lourd (au sens
habituel du terme "lourd"), avec les mêmes possibilités de jeu.
De même, nous avons dans le jeu des espèces extra-terrestres, 69 pour
être plus précis. Nous n'en ferons que 6. Et bien, en ajoutant un
nouveau "serveur métier" des contributeurs pourraient créer une
nouvelle espèces et la gérer eux-mêmes. Elle cohabiterait alors avec
les nôtres. Et si le modèle est suffisamment neutre, le nouveau
serveur métier pourrait là encore dialoguer avec un "serveur de vue"
quelconque et donc donner un choix en ce qui concerne le client.
La même idée pourrait bien sûr s'appliquer aux serveurs de données,
bien que l'intérêt de répartir les couches logiques sur des machines
physiques soit, là, moins évident.
Il paraît que l'on vient sur les newsgroups pour poser des questions
et y répondre :-) Alors ma question est :
notre jeu est un jeu basé sur un monde de science-fiction : cette
architecture vous paraît-elle elle aussi de la science-fiction ?
Qu'ajouteriez-vous ? Qu'enlèveriez -vous ? Et surtout : quelles
technologies emploieriez-vous pour faire communiquer les différents
type de serveur ?
On peut en effet imaginer des servlets, des Web Services, des EJB et
j'en oublie. Mais en restant dans le cadre de départ d'un client léger
HTML avec un moteur de servlets derrière et d'une base de donnée
relationnelle, les façons de remplir notre contrat laissent ouvert, je
pense, un grand choix possible de technologies. Lesquelles nous
conseilleriez-vous ?
Voilà, désolé pour ceux qui se sont endormis et merci d'avance pour
toute idée.
Pierre Goupil
> Le jeu tel que nous le créerons est un client léger affiché par u n
> navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
> nous voulons le découper en un "serveur de vue" (un moteur de servlet s
> envoyant le HTML au navigateur), un "serveur métier" (un autre serveu r
> réagissant aux demandes du premier et gérant les règles et
> possibilités du jeu) et un "serveur de données" (un dernier moteur de
> servlets (ou autre) s'occupant uniquement de la persistance des
> données).
Bon, c'est le pattern MVC.
Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînen t
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des E JB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas oblig é
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-a uction/wiki/server_struts
Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourra it
être, dans ton cas, une partie avec un objectif), services métiers,
objets métiers en utilisant le pattern MVC et des Web Services + patter n
DAO pour l'accès à la base de données afin de se rendre indépenda nt du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
> Le jeu tel que nous le créerons est un client léger affiché par u n
> navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
> nous voulons le découper en un "serveur de vue" (un moteur de servlet s
> envoyant le HTML au navigateur), un "serveur métier" (un autre serveu r
> réagissant aux demandes du premier et gérant les règles et
> possibilités du jeu) et un "serveur de données" (un dernier moteur de
> servlets (ou autre) s'occupant uniquement de la persistance des
> données).
Bon, c'est le pattern MVC.
Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînen t
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des E JB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas oblig é
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-a uction/wiki/server_struts
Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourra it
être, dans ton cas, une partie avec un objectif), services métiers,
objets métiers en utilisant le pattern MVC et des Web Services + patter n
DAO pour l'accès à la base de données afin de se rendre indépenda nt du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
> Le jeu tel que nous le créerons est un client léger affiché par u n
> navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
> nous voulons le découper en un "serveur de vue" (un moteur de servlet s
> envoyant le HTML au navigateur), un "serveur métier" (un autre serveu r
> réagissant aux demandes du premier et gérant les règles et
> possibilités du jeu) et un "serveur de données" (un dernier moteur de
> servlets (ou autre) s'occupant uniquement de la persistance des
> données).
Bon, c'est le pattern MVC.
Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînen t
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des E JB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas oblig é
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-a uction/wiki/server_struts
Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourra it
être, dans ton cas, une partie avec un objectif), services métiers,
objets métiers en utilisant le pattern MVC et des Web Services + patter n
DAO pour l'accès à la base de données afin de se rendre indépenda nt du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
Bonjour,
Tout d'abord, merci beaucoup de ta réponse très instructive. J'ai pris
le temps de la "méditer", voici ce que cela donne.
On 18 nov, 00:29, Wykaaa wrote:Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Bon, c'est le pattern MVC.
Tout à fait. Le but est bien de séparer les responsabilités (entre
serveurs).Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînent
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des EJB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas obligé
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
L'approche SOA vient bien sûr à l'esprit, puisqu'on parle bien de
comment proposer des services et de comment les coordonner. Mais je
connais mal cette approche, peut-être as-tu des pointeurs à me
donner ?
une solution élégante à mon problème. Egalement, comme tu le dis, son
ouverture et sa "technology-neutrality". En revanche, les
inconvénients que j'y vois, à tort ou à raison, sont tout d'abord que
dans le monde Java, c'est une technologie plutôt de second plan. Bien
sûr je peux me tromper, mais dans le cadre d'un projet libre cherchant
à créer une communauté, c'est déjà un risque. Et je ne le prendrais
pas sans une étude plus approfondie, vis-à-vis de ses implémentations
Java mais aussi dans d'autres langages.
Quant aux EJB : je pense déjà que leur réputation de complexité et de
mauvaises performances n'est plus (tant) méritée. Mais leur côté "Java
et rien d'autre" suffit à lui seul à me retenir de les utiliser, ou
alors uniquement en tant que core-component, pas en tant qu'interface
possible vers le monde extérieur.
Bien sûr, si vous me dites que c'est là aussi un problème réglé, c'est
différent. :-)
Quant aux Web Services, enfin, je partage totalement ton analyse :
séduisants, mais gaffe aux perfs. Cependant, tu sembles m'indiquer
qu'ils peuvent être intégrés comme couche métier (et uniquement là si
on le souhaite) d'une architecture SOA. Peux-tu m'en dire plus, STP ?
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-auction/wiki/server_struts
Bon pointeur, merci.Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourrait
être, dans ton cas, une partie avec un objectif), services métiers,
Notre priorité est tout d'abord d'utiliser des technos les plus
ouvertes et répandues possible afin d'attirer le maximum de profils au
sein de notre communauté. Nous ferons personnellement tout en Java EE,
mais nous ne voulons pas n'intéresser que ce type de profil-là. Notre
priorité est ensuite au niveau des performances.
Mais il est bien évident qu'il faudra faire des compromis
(performances Vs. complexité, par exemple) et surtout, comme tu le dis
très bien, prendre tout le temps nécessaire à nos analyses si nous
voulons qu'un tel type d'architecture soit bien fait. C'est aussi pour
cela que je suis là !
objets métiers en utilisant le pattern MVC et des Web Services + pattern
DAO pour l'accès à la base de données afin de se rendre indépendant du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
Pour la base de données, il est clair que nous ne nous limiterons pas
à n'autoriser que le vendeur que nous avons choisi nous-mêmes.
Cependant, je ne vois pas d'intérêt à supporter autre chose que le
modèle relationnel. Tu me détrompes ? ;-)
Il est répandu, éprouvé et efficace, à mon goût. Le but n'est pas
d'être extensible à l'infini mais plutôt de permettre à la communauté
de ré-implémenter une des couches de notre modèle dans le langage * de
programmation * de son choix, ainsi que de l'étendre bien sûr. Mais je
me dis que SQL n'est pas vraiment un langage de programmation mais
plutôt d'interrogation d'une base et du type de modèle (i.e.
relationnel) qu'il y a derrière, donc l'intérêt de supporter un autre
langage me semble limité, vu que le relationnel me semble suffisant.
Enfin, je ne conçois pas la partie modèle de l'architecture comme un
simple SGBD "passif" mais plutôt comme le serveur s'occupant de la
persistance de ce modèle ainsi que du SGBD avec lequel il travaille
main dans la main. Je ne sais pas trop si nous sommes tombés d'accord
sur ce point.
Quoi qu'il en soit, je vois que ces idées ne te paraissent pas
farfelues et c'est déjà beaucoup ! Encore un grand merci pour tes
réponses qui, comme tu le vois, apportent d'autres questions. :-)
Bonjour,
Tout d'abord, merci beaucoup de ta réponse très instructive. J'ai pris
le temps de la "méditer", voici ce que cela donne.
On 18 nov, 00:29, Wykaaa <wyk...@yahoo.fr> wrote:
Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Bon, c'est le pattern MVC.
Tout à fait. Le but est bien de séparer les responsabilités (entre
serveurs).
Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînent
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des EJB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas obligé
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
L'approche SOA vient bien sûr à l'esprit, puisqu'on parle bien de
comment proposer des services et de comment les coordonner. Mais je
connais mal cette approche, peut-être as-tu des pointeurs à me
donner ?
une solution élégante à mon problème. Egalement, comme tu le dis, son
ouverture et sa "technology-neutrality". En revanche, les
inconvénients que j'y vois, à tort ou à raison, sont tout d'abord que
dans le monde Java, c'est une technologie plutôt de second plan. Bien
sûr je peux me tromper, mais dans le cadre d'un projet libre cherchant
à créer une communauté, c'est déjà un risque. Et je ne le prendrais
pas sans une étude plus approfondie, vis-à-vis de ses implémentations
Java mais aussi dans d'autres langages.
Quant aux EJB : je pense déjà que leur réputation de complexité et de
mauvaises performances n'est plus (tant) méritée. Mais leur côté "Java
et rien d'autre" suffit à lui seul à me retenir de les utiliser, ou
alors uniquement en tant que core-component, pas en tant qu'interface
possible vers le monde extérieur.
Bien sûr, si vous me dites que c'est là aussi un problème réglé, c'est
différent. :-)
Quant aux Web Services, enfin, je partage totalement ton analyse :
séduisants, mais gaffe aux perfs. Cependant, tu sembles m'indiquer
qu'ils peuvent être intégrés comme couche métier (et uniquement là si
on le souhaite) d'une architecture SOA. Peux-tu m'en dire plus, STP ?
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-auction/wiki/server_struts
Bon pointeur, merci.
Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourrait
être, dans ton cas, une partie avec un objectif), services métiers,
Notre priorité est tout d'abord d'utiliser des technos les plus
ouvertes et répandues possible afin d'attirer le maximum de profils au
sein de notre communauté. Nous ferons personnellement tout en Java EE,
mais nous ne voulons pas n'intéresser que ce type de profil-là. Notre
priorité est ensuite au niveau des performances.
Mais il est bien évident qu'il faudra faire des compromis
(performances Vs. complexité, par exemple) et surtout, comme tu le dis
très bien, prendre tout le temps nécessaire à nos analyses si nous
voulons qu'un tel type d'architecture soit bien fait. C'est aussi pour
cela que je suis là !
objets métiers en utilisant le pattern MVC et des Web Services + pattern
DAO pour l'accès à la base de données afin de se rendre indépendant du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
Pour la base de données, il est clair que nous ne nous limiterons pas
à n'autoriser que le vendeur que nous avons choisi nous-mêmes.
Cependant, je ne vois pas d'intérêt à supporter autre chose que le
modèle relationnel. Tu me détrompes ? ;-)
Il est répandu, éprouvé et efficace, à mon goût. Le but n'est pas
d'être extensible à l'infini mais plutôt de permettre à la communauté
de ré-implémenter une des couches de notre modèle dans le langage * de
programmation * de son choix, ainsi que de l'étendre bien sûr. Mais je
me dis que SQL n'est pas vraiment un langage de programmation mais
plutôt d'interrogation d'une base et du type de modèle (i.e.
relationnel) qu'il y a derrière, donc l'intérêt de supporter un autre
langage me semble limité, vu que le relationnel me semble suffisant.
Enfin, je ne conçois pas la partie modèle de l'architecture comme un
simple SGBD "passif" mais plutôt comme le serveur s'occupant de la
persistance de ce modèle ainsi que du SGBD avec lequel il travaille
main dans la main. Je ne sais pas trop si nous sommes tombés d'accord
sur ce point.
Quoi qu'il en soit, je vois que ces idées ne te paraissent pas
farfelues et c'est déjà beaucoup ! Encore un grand merci pour tes
réponses qui, comme tu le vois, apportent d'autres questions. :-)
Bonjour,
Tout d'abord, merci beaucoup de ta réponse très instructive. J'ai pris
le temps de la "méditer", voici ce que cela donne.
On 18 nov, 00:29, Wykaaa wrote:Le jeu tel que nous le créerons est un client léger affiché par un
navigateur et est basé sur Tomcat. Cependant, comme je vous l'ai dis,
nous voulons le découper en un "serveur de vue" (un moteur de servlets
envoyant le HTML au navigateur), un "serveur métier" (un autre serveur
réagissant aux demandes du premier et gérant les règles et
possibilités du jeu) et un "serveur de données" (un dernier moteur de
servlets (ou autre) s'occupant uniquement de la persistance des
données).
Bon, c'est le pattern MVC.
Tout à fait. Le but est bien de séparer les responsabilités (entre
serveurs).Il faut s'inspirer d'une architecture SOA (Service Oriented
Architecture). Dans ce cadre tu as les processus métier qui enchaînent
des services métiers (il n'y a pas de logique applicative dans
"l'orchestration des services métiers). Chaque service métier
"orchestre" des méthodes des objets métiers (qui peuvent être des EJB).
Dans une telle architecture, les Web Services sont utilisés
principalement au niveau des services métiers (mais tu n'es pas obligé
d'utiliser des Web Services partout. Il peut y avoir des problèmes de
performances).
L'approche SOA vient bien sûr à l'esprit, puisqu'on parle bien de
comment proposer des services et de comment les coordonner. Mais je
connais mal cette approche, peut-être as-tu des pointeurs à me
donner ?
une solution élégante à mon problème. Egalement, comme tu le dis, son
ouverture et sa "technology-neutrality". En revanche, les
inconvénients que j'y vois, à tort ou à raison, sont tout d'abord que
dans le monde Java, c'est une technologie plutôt de second plan. Bien
sûr je peux me tromper, mais dans le cadre d'un projet libre cherchant
à créer une communauté, c'est déjà un risque. Et je ne le prendrais
pas sans une étude plus approfondie, vis-à-vis de ses implémentations
Java mais aussi dans d'autres langages.
Quant aux EJB : je pense déjà que leur réputation de complexité et de
mauvaises performances n'est plus (tant) méritée. Mais leur côté "Java
et rien d'autre" suffit à lui seul à me retenir de les utiliser, ou
alors uniquement en tant que core-component, pas en tant qu'interface
possible vers le monde extérieur.
Bien sûr, si vous me dites que c'est là aussi un problème réglé, c'est
différent. :-)
Quant aux Web Services, enfin, je partage totalement ton analyse :
séduisants, mais gaffe aux perfs. Cependant, tu sembles m'indiquer
qu'ils peuvent être intégrés comme couche métier (et uniquement là si
on le souhaite) d'une architecture SOA. Peux-tu m'en dire plus, STP ?
Si tu choisis Tomcat+MVC+EJB+servlet pour la prtie contrôle de MVC,
alors voir ici (tu peux t'en inspirer) :http://code.google.com/p/master-auction/wiki/server_struts
Bon pointeur, merci.Perso, si ta priorité (ce que j'ai compris de ton message) est
l'ouverture, il faut choisir SOA (tel que je l'ai mentionné ci-dessus)
avec des Web Services mais pour ne pas se planter, il est nécessaire de
faire une très bonne architecture (y passer du temps) avec les
différentes couches : processus métiers (un processus métier pourrait
être, dans ton cas, une partie avec un objectif), services métiers,
Notre priorité est tout d'abord d'utiliser des technos les plus
ouvertes et répandues possible afin d'attirer le maximum de profils au
sein de notre communauté. Nous ferons personnellement tout en Java EE,
mais nous ne voulons pas n'intéresser que ce type de profil-là. Notre
priorité est ensuite au niveau des performances.
Mais il est bien évident qu'il faudra faire des compromis
(performances Vs. complexité, par exemple) et surtout, comme tu le dis
très bien, prendre tout le temps nécessaire à nos analyses si nous
voulons qu'un tel type d'architecture soit bien fait. C'est aussi pour
cela que je suis là !
objets métiers en utilisant le pattern MVC et des Web Services + pattern
DAO pour l'accès à la base de données afin de se rendre indépendant du
fournisseur (et même du modèle : relationnel, objet ou BD XML).
Pour la base de données, il est clair que nous ne nous limiterons pas
à n'autoriser que le vendeur que nous avons choisi nous-mêmes.
Cependant, je ne vois pas d'intérêt à supporter autre chose que le
modèle relationnel. Tu me détrompes ? ;-)
Il est répandu, éprouvé et efficace, à mon goût. Le but n'est pas
d'être extensible à l'infini mais plutôt de permettre à la communauté
de ré-implémenter une des couches de notre modèle dans le langage * de
programmation * de son choix, ainsi que de l'étendre bien sûr. Mais je
me dis que SQL n'est pas vraiment un langage de programmation mais
plutôt d'interrogation d'une base et du type de modèle (i.e.
relationnel) qu'il y a derrière, donc l'intérêt de supporter un autre
langage me semble limité, vu que le relationnel me semble suffisant.
Enfin, je ne conçois pas la partie modèle de l'architecture comme un
simple SGBD "passif" mais plutôt comme le serveur s'occupant de la
persistance de ce modèle ainsi que du SGBD avec lequel il travaille
main dans la main. Je ne sais pas trop si nous sommes tombés d'accord
sur ce point.
Quoi qu'il en soit, je vois que ces idées ne te paraissent pas
farfelues et c'est déjà beaucoup ! Encore un grand merci pour tes
réponses qui, comme tu le vois, apportent d'autres questions. :-)