Architecture d'un jeu Java EE

Le
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
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
Wykaaa
Le #17878121
Pierre Goupil a écrit :
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.



Ce n'est pas forcément plus original. Désolé...

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.
Attention, dans ce pattern, les EJB sont dans la partie modèle, les
servlets dans la partie contrôle et, évidemment les pages JSP dans la
partie vue.

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.



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).

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 ?



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

Voilà, désolé pour ceux qui se sont endormis et merci d'avance pour
toute idée.

Pierre Goupil



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,
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).
Pierre Goupil
Le #17903331
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
> 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.



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î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).



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 ? Ce qui me plaît en elle, c'est déjà que c'est certainement
une solution élégante à mon problème. Egalement, comme tu le dis, s on
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 prendra is
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é "J ava
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. Mais c'est un peu dommage, non ?
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-a uction/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 pourra it
ê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 + 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).



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 communau té
de ré-implémenter une des couches de notre modèle dans le langage * d e
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. :-)
Wykaaa
Le #17908261
Pierre Goupil a écrit :
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
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 ?



J'en ai un peu trop, hélas, car j'ai du mal à m'y retrouver.
Des choses de bases (du moins il me semble car maintenant je suis assez
pointu sur ce sujet...) :
- http://pie.bonnet.ifrance.com/ (tu télécharge les pdf : guide de
référence SOA (parties 1 et 2) et guide de référence Web Services
(parties 1 et 2)
- http://www.praxeme.org (le même Pierre Bonnet, avec d'autres)

Si tu comprends l'anglais (ce sont ds vidéos), il y a un site génial :
http://www.parleys.com/display/PARLEYS/Home#page=Home et, en particulier :
-http://www.parleys.com/display/PARLEYS/Home#title=Open%20Architecture;talk612251;slide=1
(attention, ça dure 50 minutes)

Sinon, toujours en anglais : http://www.osoa.org/display/Main/Home (Open
SOA)

Pour le recensement des Web Services :
- http://www.orchestranetworks.com/fr/soa/standardsws.cfm (août 2004
mais il y a les liens vers les specifs)

Perso, j'ai des dizaines de documents sur SOA et Web Services collectés
au fil du temps et un cours sur ces sujets...

Ce qui me plaît en elle, c'est déjà que c'est certainement
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.



Et bien, va déjà voir ce qu'en dit SUN :
http://www.sun.com/products/soa/index.jsp

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.



Je suis d'accord là-dessus dans le cadre de ta problématique.

Mais c'est un peu dommage, non ?

Oui. Enfin ça dépend car les avis sont partagés.

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 ?



Tu as les réponses, enfin il me semble, dans les documents de Pierre
Bonnet "Guide de référence SOA" dont j'ai parlé plus haut.



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.



Avec SOA et les Web Services, tous les langages et types d'applications
peuvent cohabiter. J'ai même vu des applications traditionnelles en
Cobol (!) intégrées dans une architecture SOA (il faut prendre quelques
précautions tout de même... :-)

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à !



Le travail sur l'architecture est, de loin, le plus important et ceci
est trop souvent négligé ce qui entraîne de nombreuses personnes à dire
que SOA, l'objet, etc. ça ne fonctionne pas. Evidemment si on saute
l'étape d'architecture et les processus métiers...



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 ? ;-)



Je te détrompe un peu oui car si, par ailleurs (dans les services
métiers, donc, pour toi, les différentes parties des scénarios du jeu),
sont utilisés les Web Services (WS), alors ils s'échangent des messages
en XML. Dans ce cas, il peut être intéressant d'envisager une base de
données en XML. Mais rien n'interdit d'ailleurs, dans une architecture
SOA d'avoir des données en relationnel et d'autres en XML à condition
qu'elles ne soient pas ou peu liées entre elles (tu vois la tête des
jointures sinon...)

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.



Ca renforcerait plutôt l'exploration de la voie BD XML.
Voir ici : http://exist-db.org/ (BD XML open source)

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. :-)



Ton approche n'est absolument pas farfelue mais il faut que, quelque
part, ce que tu veux faire se développe vraiment, sinon c'est une
approche "luxueuse" si ça ne débouche pas.
Publicité
Poster une réponse
Anonyme