Discussion :

[fatypunk]

Bonjour,

Je me suis mis au EJB3 depuis quelques semaines maintenant (Netbeans 6 beta + Glassfish v2 + PostgreSQL 8.2). J'ai assimilé un certain nombre de chose à leur sujet mais j'ai une question concernant l'architecture d'une application se voulant le plus modulaire possible. Je m'explique :

Un module d'une application gère par exemple un carnet d'adresse. Je n'ai eu aucune problème pour créer un EJB Entity qui gère la persistance dans une table PostgreSQL ni pour créer un EJB Session (stateless/remote) avec un set de méthodes d'interrogation. J'ai ensuite créé un client java SE qui accède à l'EJB Session à l'aide d'un fichier jndi.properties.

Mon problème c'est que dans cet façon de faire il faut inclure le jar de l'EJB dans le classpath du client ! Or j'aimerais une application plus modulaire, soit pouvoir redévelopper une version différente d'un module côté serveur (même interface) et pouvoir utiliser soit l'un soit l'autre lors d'un déploiement. Et ceci à la volée grâce à un gestionnaire de module.

J'ai tenté de placer l'interface remote dans un module et le code du stateless bean dans un autre mais le module d'interface refuse de compiler car il ne contient aucun EJB !

J'ai fait plein d'autre tentative mais rien de fonctionne...

Quel architecture serait adaptée à un tel besoin ? Peut-être faudrait-il un bus de services mais au final je ne vois pas comment me passer d'inclure le jar contenant le code métier dans le classpath du reste de l'application...

C'est pourtant nécessaire si l'on veut vraiment de la modularité !

[OButterlin]

Peux-tu clarifier...

Tu veux utiliser des facades différentes avec les mêmes signatures de méthodes et les mêmes types d'objet (pojo/entity), c'est ça ?
(en d'autres termes, le code d'exécution pourait être différent pour les mêmes interfaces et objets)

[fatypunk]

Presque... mais pas tout à fait. Prenons un exemple concret, c'est plus facile.

Prenons une application simple, composée de 2 modules (une bibliothèque de prêts) :
- Gestion des clients
- Gestion des livres

Dans le déploiement de base les livres et les clients sont stocké dans la DB de l'application, au travers des EJB Entity et Session. Un client lourd en java SE se connecte au serveur d'application et propose l'UI principale. C'est cette architecture qui est déployée en général.

Un nouveau client dispose déjà d'une base de client (accessible par exemple en services web ou d'une autre manière ça n'a pas d'importance). Il serait inadéquat de migrer leur système de gestion des clients car il est partagé avec d'autres entreprises. L'idéal serait de réécrire uniquement le code métier de l'EJB Session (qui par exemple utilise des services web pour se connecter à l'autre système plutôt que de se connecter aux EJB Entity de l'application). De cette manière en déployant le nouveau module à la place du module de base l'application (une contrainte du gestionnaire de module empêche l'installation des deux modules en //) fonctionne (sans avoir à recompiler-reversioner le client et le module de gestion des livres).

Evidement dans ce cas-ci il paraîtrait plus judicieux de synchroniser notre DB avec l'autre système, mais si par exemple un client veux une version plus évoluée du module de gestion de leurs clients. On pourrait leur coder un nouveau module côté serveur ainsi qu'un nouveau module côté client, mais ne pas toucher au module de gestion des livres (car le nouveau client utilise les mêmes interfaces que celles du module de base, ce n'est que la partie client spécifique à le gestion des clients qui utilisent une interface plus spécialisée).

Est-ce plus clair ?

[OButterlin]

Finalement, tu veux substituer des morceaux d'applications en fonction d'éléments que le client pourrait déjà avoir, c'est bien ça ?

[fatypunk]

C'est un exemple de chose que je pourrait être amené à faire. Mais de façon générale j'aimerais trouver une architecture la plus modulaire possible (c'est à dire la plus découplée possible).

Je suis toujours en train de tester différentes possibilité mais je n'ai pas encore trouver ce que je veux (et surtout je code des solutions qui sorte de mon imagination et mon but ici est de voir si certaines architecture existante me permettrait de résoudre mon problème).

J'ai cherché des docs et exemple mais je tombe toujours sur les même choses simple et rien n'approche mon problème...

[OButterlin]

Bon et bien visiblement, je n'ai pas encore compris ton problème...

Tu veux pouvoir utiliser des "morceaux" de base de données du client final et "encapsuler" le tout dans ton application ?

Si je te suis bien, le client à déjà une base de données référençant les clients et tu voudrais chercher le données concernant un client dans cette base plutôt que dans la base par défaut de l'application.

Pour ce qui est du mapping, Hibernate serait tout à fait indiqué pour faire ça, il faudrait juste que la session soit spécifique à la base cible...

En conjugant avec un EntityManager (EJB3), je pense que tu peux t'en sortir, en liant tes Entity à des managers différents via unitName (un pour les clients, un autre pour les livres)

On peut faire la même chose avec des DataSources...

[fatypunk]

Ah oui alors il y a bien un problème de compréhension... (merci toutefois de prendre le temps de comprendre...).

Tout d'abord l'exemple évoqué n'est pas l'application que je veux développer. Je monte un projet d'une application libre assez conséquente. Cette application ne doit pas correspondre aux besoin d'un client unique mais de multiples clients potentiels. Comme il s'agit d'un logiciel libre le but est aussi d'avoir une architecture performante permettant une grande souplesse dans l'ajout/remplacement de certains modules par d'autres équipes de dev indépendants (sans avoir à recompiler toute l'application !).

Pour le client lourd je m'oriente sur la Netbeans Platform (la gestion des mise à jour des modules clients me semble vraiment idéale pour ce que je veux faire). Et j'aimerais monter un principe modulaire côté serveur d'application (déploiement de modules serveur (EJB) à la volée !).

J'ai encore des soucis avec les modules Netbeans Platform pour lier les libraires JEE dans le classpath (mais je tourne sur la beta de la version 6 de la plateforme et il me semble qu'e certains soucis sont du à ça... mais bon au cas ou je me renseignerai sur un forum plus spécialement dédié à cette plateforme).

Pour l'instant je code une appli simple de 2 modules (la phase du projet en est au test des framework et outil afin de définir l'architecture, ce qui nous permettra ensuite de passer à la phase de conception...).

Évidement dans une telle architecture, les tables ne peuvent pas utiliser les capacités relationnelles du serveur DB entre les modules (au sein d'un module oui mais entre les modules les relations doivent être gérée à un niveau supérieur par une sorte de bus de services par exemple).

Les décisions qui sont arrêtée à 99% sont :
IDE : Netbeans
Serveur DB : Postgres
Serveur JEE : Glassfish

Décision en voie d'être prise :
Client lourd basé sur la Netbeans Platform (mais uniquement si les tests d'intégration avec JEE sont concluants).

Concernant l'architecture nous sommes en plein débat ! Si je remarque (ma tâche actuelle consiste à la définir) qu'un découplage très très marqué pose trop de problème je risque de proposer quelque chose de plus monolithique... Cela me décevrait car cela rend les contribution externe plus ardue ! Mais il est possible de voir un modèle ou d'autre équipes indépendantes modifie un module (plutôt que d'en proposer un nouveau), et ensuite les gens qui gèrent le repository officiel (structure de "les gens" pas encore définie) décident d'intégrer (avec éventuellement des modifications pour correspondre à la charte de développement du projet) les modifications réalisées par d'autres. Mais le principe de remplacement d'un module par un autre fonctionnant différemment à la manière d'un plug-gin est très séduisante.

Peut-être que cette explication de nos objectifs rend ma question plus précise...

J'ajoute encore que ces considérations proviennent d'une équipe de dev expérimentés (mais malheureusement pas en JEE). Personnellement j'ai une solide expérience de Java SE (j'avais un peu délaissé ce langage en 1999. Je jugeait que l'absence de la généricité était un gros handicap pour faire de la POO...). Aujourd'hui la donne change et notre objectif a avantage a tirer parti des grosses plateformes, et .NET pour un projet libre se voulant multi-plateforme sans financement particulier ça fait un peu tâche tout de même...

[fatypunk]

Pour mon problème d'utilisation de JEE dans un projet Netbeans Platform j'ai trouvé ce qu'il me fallait :

http://wiki.netbeans.org/wiki/view/D...nNbPlatformTut

C'est exactement ce que j'étais en train d'essayer de faire. Ça ne résout pas le problème de l'architecture mais ça me permet de croire qu'un client lourd basé sur Netbeans Platform est envisageable.