Discussion :

[bricecol]

bonjour,

j'ai besoin de l'aide de quelques chevronnés sur les architectures n-tiers !

voilà, j'ai un projet à réaliser qui va me demander d'utiliser pas mal d'outils pour être "propre", interopérable, modulaire, fonctionnel etc.. il s'agit d'avoir, comme pour un jeu en ligne, un serveur et des clients, jusque là tout va bien ! il y aura une ou plusieurs BDD.

quelques "contraintes" :
- programmer en JAVA/(opengl ou éq.)
- utiliser PostgreSQL
- utiliser HIBERNATE ou éq.
- utiliser la techno RMI ou éq.

voici mon problème principal. je souhaite savoir s'il serait judicieux (et si c'est possible, je pense que oui) d'utiliser la technologie JAVA RMI de ce genre d'architecture et avec mes autres contraintes ??? est-ce que "ça se fait" ou il y a mieux / plus simple ?

grosso modo, voici mon schéma final. le client est un container semi-lourd je dirai car il possède tous les médias lourds (objets 3d principalement). mais le client est une interface et l'objet client est crée sur le serveur (conformément au fonctionnement RMI). le code des actions client (comme se déplacer, attaquer etc...) est donc côté serveur et le serveur gère tous les clients. le client n'est donc pas surchargé en code. après vient le mapping avec HIBERNATE et les BDD (ça c'est pas trop compliqué).

j'aimerais savoir ce que vous en pensez. ah j'oubliais, je comptais utiliser MAVEN pour les dépendances et la gestion du projet (deux sous-projets donc : client et serveur).

alors ? c'est un bon choix ou il y a des choses qui vous semblent inutiles ou au contraire il manque une couche au dessus / en dessous de quelque chose ?

merci d'avance pour votre aide !
(n'hésitez-pas si j'ai oublié de préciser qq chose ou si vous avez des questions)

[OButterlin]

Comme ça, "à la louche", ça me parait correcte.
Tu pourrais accessoirement utiliser EJB à la place de RMI (même si EJB s'appuit sur RMI-IIOP) qui pourrait t'apporter un + (sauf si tu as une forte contrainte performance et/ou pas de serveur JEE à disposition).
Dans ce contexte, EJB3 entity peut remplacer avantageusement Hibernate ("natif"), même si tu peux utiliser Hibernate comme implémentation de JPA (d'EJB).
Pour le reste, un client lourd (en quoi ? swing ?) pour les traitements graphiques, c'est ok... si tu veux dessiner ou t'interfacer avec des composants de la machine cliente... sinon, tu pourrais utiliser une architecture web à base de jsf + facelets + richfaces... ça fait des choses fabuleuses visuellement... ça dépend un peu de ce que doit faire le client...
Peux-tu préciser cet aspect ?

[bricecol]

Tu pourrais accessoirement utiliser EJB à la place de RMI (même si EJB s'appuit sur RMI-IIOP) qui pourrait t'apporter un + (sauf si tu as une forte contrainte performance et/ou pas de serveur JEE à disposition).
Dans ce contexte, EJB3 entity peut remplacer avantageusement Hibernate ("natif"), même si tu peux utiliser Hibernate comme implémentation de JPA (d'EJB).

EJB est basé sur RMI ? et en fait, c'st donc plus lourd mais d'après toi plus simple d'utilisation ? EJB3 entity pourrait donc "remplacer" hibernate ?

en fait, je dois faire un petit jeu. donc d'un côté un serveur (j'ai un serveur debian complètement sous contrôle et assez puissant) interfacé avec le ou les BDD que je créerait (je mettrait une interface si il y ena plusieurs mais normalement, au ébut, ce ne sera pas le cas). et un côté client JAVA/opengl. le client lui même, si j'utilise RMI sera une interface distante au serveur mais tout objet client "vivra" sur le serveur. bien sur, du côté client, je dois aussi utiliser opengl mais la n'est pas le problème.

la ou je galère c'est savoir exactement ce qui répondrait le mieux à mes besoins. je n'ai pas besoin d'avoir des perfs de fou également.

[OButterlin]

EJB est basé sur RMI ?

oui, quand on utilise une interface Remote

et en fait, c'st donc plus lourd mais d'après toi plus simple d'utilisation ?

Plus lourd, certainement, ça fait beaucoup plus que du RMI.
En résumé, RMI n'est rien d'autre qu'une invocation à distance d'une méthode alors qu'EJB fait bien d'autres choses "nativement".
Les plus importantes :
- persistance
- les transactions
- le maintient d'état

Globalement, on a 3 grands types d'EJB :
- Entity (pour la persistance)
- Session (avec ou sans état (stateful / stateless)
- MessageDriven (comme son nom l'indique, répondant à un message (JMS))

EJB3 entity pourrait donc "remplacer" hibernate ?

Oui, en quelque sorte.
Il faut comprendre que la partie persistance des EJB3 est basé sur l'api JPA.
Elle définit une "norme" et ça s'arrête là.
On a ensuite les implémentations de JPA, et c'est ici qu'on retrouve Hibernate.
L'avantage, c'est qu'on pourrait passer d'une implémentation Hibernate à une implémentation TopLink (ou EclipseLink) sans modification de code.

Je pense que ton explication du besoin (côté client) tend à pousser vers les EJB3 plutôt que RMI

[bricecol]

ok. quand tu parles de persistance, il faut que je sache de quel côté. en effet, les clients sont crées côté client mais vivent coté serveur. leur "infos" sont stocké dans une BDD, côté serveur donc.

je connais JPA, des annotations en fait. ensuite, si j'ai bien compris, hibernate se sert de ces annotations, de cette "norme", pour faire l'interface avec la BDD (enfin, on peut aussi mettre des DAO entre les objets annotés et hibernate je pense là n'est pas le problème, on pourrait alors changer facilement pr un eq. d'hibernate).

j'avoue que je n'ai que très peu tenter de faire fonctionner "tout çà" au sein d'un même projet en "cohabitation" sans trop de troubles ^^

bon, j'essaie de faire un petit schéma récapitulatif de tout ca et je reviens

merci bcp pour ton aide !

[OButterlin]

ok. quand tu parles de persistance, il faut que je sache de quel côté. en effet, les clients sont crées côté client mais vivent coté serveur. leur "infos" sont stocké dans une BDD, côté serveur donc.

Côté serveur, c'est ce qu'il y a de mieux et de plus sécurisé (si besoin).
Tu utiliserais un EJB session stateless (à priori) pour faire la persistance.
Dans ce cas, on peut voir cet EJB comme une DAO remote.

Sinon, pour Hibernate natif et DAO, ça fonctionne très bien aussi.
Rien n'empêche de mixer les éléments :
- EJB stateful pour conserver l'état entre différents appels de chaque client et faisant office de Contrôleur
- des DAO standards appelés pour l'accès aux données

(c'est juste un peu dommage de se priver de la puissance des transactions déclaratives des EJB3 avec JTA)

[bricecol]

là où j'ai du mal à comprendre (je n'ai jamais utiliser çà...)

Tu utiliserais un EJB session stateless (à priori) pour faire la persistance.

j'ai fais un schéma de base avec une BDD, une interface pour y accéder (on peut y mettre ce qu'on veut, des objets (ici les remote client mais on peut y mettre aussi les autres objets utilisés par le serveur, les objets divers du jeu qui ne sont "déportés"). ces objets sont utilisés par le serveur. les objets côté client (remotes) sont liés aux objets sur le serveur (principe rmi, dc l'interface c'est l'enregistrement sur l'annuaire).

est-ce que tu peut m'aider a "compléter ce schéma". en fait, je pense que je comprendrai bien mieux le fonctionnement "global" de tous ces outils (fonctionnant ensembles). j'utilise dia, je vais donc joindre le fichier projet. je suis sur que je comprendrai mieux avec un schéma faisant figurer les liens entre les éléments... ce serait super sympa de ta part (j'ai pas envie de t'en demander trop mais tu sembles bien t'y connaitre ^^)

merci d'avance tu me sauves la vie

shéma dia : http://rapidshare.com/files/304094754/schema.dia.html
image : http://img11.imageshack.us/i/schemadr.png/

[OButterlin]

est-ce que tu peut m'aider a "compléter ce schéma". en fait, je pense que je comprendrai bien mieux le fonctionnement "global" de tous ces outils (fonctionnant ensembles). j'utilise dia, je vais donc joindre le fichier projet. je suis sur que je comprendrai mieux avec un schéma faisant figurer les liens entre les éléments... ce serait super sympa de ta part (j'ai pas envie de t'en demander trop mais tu sembles bien t'y connaitre ^^)

Là tout de suite, je suis un peu short en temps, mais si tu n'es pas trop pressé, pourquoi pas... C'est une chose de répondre ponctuellement à une question mais ça prend pas mal de temps de participer à l'architecture d'une application, surtout quand on ne sait pas trop ce qu'elle est sensée faire.
A ce sujet, il serait intéressant de préciser exactement ce qu'elle fait (et de chaque côté). D'autres que moi pourront également t'aider dans le choix de l'architecture et au final tu gagneras du temps... Ça ressemble à première vue à un jeu...

Essaye de dégager un maximum les acteurs sur ton schéma et ne t'occupe pas trop de l'aspect technique... ça complique inutilement la lecture

A+

[bricecol]

ok merci. oui je ne suis pas à quelques jours prêt ^^

alors voilà, je vais essayer de détailler tout çà sans aspects techniques. déjà effectivement, comme tu l'as dit, c'est pour réaliser un jeu, open source, reposant principalement sur JAVA et un moteur 3D libre comme opengl ou équivalent ^^

je ne suis pas tout seul sur le projet en fait. notre but, concrètement ce n'est pas de faire un jeu mais bien d'apprendre à utiliser certain outil. le jeu c'est un but ultime qui n'est pas plus important que ca. on veut juste gagner un peu d'expérience et s'amuser voilà, aucun prétention donc ^^. ce serait un jeu en réseau car on veut explorer les aspect BDD et la notion serveur/client bien sûr.

de mon côté, je suis déjà aller très loin côté JAVA, j'ai développé un framework de création d'application pour un centre de rechercher connu. mais c'était de la prog pur, je suis débutant dans le reste surtout niveau serveur et framework comme hibernate etc... j'ai déjà utiliser la techno RMI et je n'ai aucune souci avec les bdd (largement formé pour :p). j'ai avec moi d'autres programmeurs.

bref, revenons au sujet principal. je récapitule : jeu 3D réseau (ultra simpliste) en JAVA avec BDD.

l'idée n'est pas de gagner un maximum de perf ou de faire qq chose d'extrèmement lourd. je souhaite avant tout trouver "la meilleur architecture" selon ces besoins précis. je souhaite avoir un client léger JAVA et un serveur avec des couches clairement définies : moteur de jeu, persistance des objets et persistance de certaines infos (liées ou non aux joueurs : infos des comptes, infos de position des objets etc...).

il faudrait qu'on m'aide à trouver les outils minimum afin de respecter "les facons de faire" standard (MVC, n-tiers), un schéma minimaliste qui me permette de faire tout ca sans outils obscures et j'en passe.

je souhaite que mes objets métiers soient le plus simples possibles, hors de questions d'une usine à gaz qui les génère ^^.

côté client, c'est une appli JAVA avec une interface (il y a donc des médias) et bien sur, on utilisera un moteur 3D pour afficher les fenêtres, les objets etc... la classique quoi ! a part ca, je ne veux rien d'autre. l'objet le plus simple concernant le client doit être reliée au serveur via RMI pour permettre effectivement d'effectuer les actions demandées et les sauver sur le serveur. a chaque fois que l'objet est modifié, il faudrait, je pense, envoyer une notification a un écouteur et sauver ce changement en BDD de sorte que l'état de l'objet à un instant t soit le même en BDD à l'instant t+1.

enfin voilà, je crois que ca suffit pour cerner un peu tout le bazar !

[bricecol]

désolé de faire un up mais je viens de compléter un peu mon schéma. celui-ci n'est pas au niveau en ce qui concernerait ejb3... car je ne sais pas trop comment le mettre vu qu'il faut aussi placer hibernate, les deux étant liés... help ^^

http://rapidshare.com/files/30441620...eseau.dia.html
http://img190.imageshack.us/img190/2894/jeureseau.png

merci d'avance !

[OButterlin]

D'un point de vue formalisme RMI, du côté client, on a le stub, le skeleton est côté serveur.
Sinon, pour EJB, on pourrait garder une approche comparable.

Dans l'absolu, il faudrait découper (au sens large) :

1) -> contrôleur de jeu
2) -> DAO
3) -> persistance

Pour les EJB3, on aurait plus spécifiquement
1) EJB Session bean (stateful)
2) EJB Session bean (stateless)
3) EJB Entity

Sur ton schéma, tu fais référence à Tomcat. Dans ce cas, il faudra prévoir un plugin pour les EJB, nativement, il n'en a pas, c'est juste un conteneur de servlet.

[bricecol]

1) -> contrôleur de jeu
2) -> DAO
3) -> persistance

Pour les EJB3, on aurait plus spécifiquement
1) EJB Session bean (stateful)
2) EJB Session bean (stateless)
3) EJB Entity

là tu veux dire que c'est une correspondance ? grosso modo, EJB3 me permet de faire directement CTR <=> DAO <=> BDD c'est çà ?

Sur ton schéma, tu fais référence à Tomcat. Dans ce cas, il faudra prévoir un plugin pour les EJB, nativement, il n'en a pas, c'est juste un conteneur de servlet.

oui enfin, j'ai mis tomcat car je pensais que EJB3 en avait besoin, mais si ce n'est pas le cas et que, comme tu dis, EJB3 fait "tout", alors pas besoin de tomcat ?

bon si c'est EJB3 power, faut vraiment que je regarde comment il fonctionne parce que niveau EJB3 j'ai un niveau proche du zéro absolu...

et bien merci à toi. je vais tenter de me plonger du côté obscure de la doc d'EJB3. mais j'ai l'impression que je vais assez galérer pour concrètement voir ses applications par rapport à mes besoins ^^

[OButterlin]

là tu veux dire que c'est une correspondance ? grosso modo, EJB3 me permet de faire directement CTR <=> DAO <=> BDD c'est çà ?

Oui, mais on a des types différents d'EJB...

oui enfin, j'ai mis tomcat car je pensais que EJB3 en avait besoin, mais si ce n'est pas le cas et que, comme tu dis, EJB3 fait "tout", alors pas besoin de tomcat ?

bon si c'est EJB3 power, faut vraiment que je regarde comment il fonctionne parce que niveau EJB3 j'ai un niveau proche du zéro absolu...

EJB3 a besoin d'un conteneur spécifique que Tomcat n'a pas (par défaut).
JBoss ou GlassFish en ont un nativement.
Si tu tiens a utiliser Tomcat, il faut regarder le plugin OpenEJB d'apache

[bricecol]

EJB3 a besoin d'un conteneur spécifique que Tomcat n'a pas (par défaut).
JBoss ou GlassFish en ont un nativement.
Si tu tiens a utiliser Tomcat, il faut regarder le plugin OpenEJB d'apache

je n'ai pas de contrainte à ce niveau là. je pourrai très bien installer glassfish.

bon bon bon... ca va pas être du gateau ^^