Une ou plusieurs applications java pour plusieurs applications métiers ?

Bonjour

Nous avons plusieurs métiers à couvrir par le biais d'un développent Java.
Notre prestataire nous propose de ne faire qu'une seule application (et donc à priori de ne publier un seul jar ou war).

Mais de notre côté, nous ne voulons pas avoir à recetter une application qui adresse tous nos métiers quand l'évolution ne concerne qu'un des métiers.
Autrement dit, on pense nous qu'il faudrait une application X pour le métier X et une application Y pour le métier Y, mais aussi une application dédiée pour la gestion des droits utilisateurs au sein de X et Y.
En effet, cela nous éviterait de faire la recette de Y quand X est modifiée, et cela éviterait d'impacter la gestion des droits quand une des applications est modifiée.

Et nous nous disons que la mise en production serait simplifiée car nous n'aurions à arreter uniquemant la JVM du métier modifié ; cela éviterait de bloquer tous les métiers.

Quel est votre avis sur cela ? Peut être que cela peut être géré autrement (au niveau des classes ...) ?

Est-ce que c'est possible techniquement de séparer l' application (ou module) de gestion des droits des autres applications/modules?

Est-ce que cela conduit forcément à avoir au final 3 jar et donc 3 JVM ?
Est-ce que cela est alors plus consommateur de ressources d'avoir 3 JVM sur un serveur J2EE ou pas plus qu'une seule JVM pour un jar d'une unique application ?

Est-ce que le fait d'avoir plusieurs JVM permet aussi de n'arrêter que la JVM dédiée à ce métier, ou faut il de toute façon relancer tout le serveur J2EE pour intégrer une évolution ?

Merci beaucoup

Bonjour,

En préambule, je dirai qu'il semble logique de faire un système d'information par métier. Et cette logique est d'autant plus avérée si le couplage entre les métiers est faible, voire idéalement nul.

Si c'est le cas (couplage faible), ton argumentaire sur l'indépendance des applications et de leurs cycles de vie est imparable.

En revanche si ça n'est pas le cas, tu devras constamment gérer l'interopérabilité entre les 2 systèmes. Donc toute modifications de l'un entrainera des tests de non régressions ou à minima d'interopérabilité de l'autre. il est toutefois à noter que cette problématique d'interopérabilité est adressable au travers de toute la théorie des EAI.

Pour le moment je préfère ne pas aborder ton soucis d’optimisation des VM sur l’hébergement de ta solution finale en production.
Je pense qu'il faut au préalable que tu nous confirmes (ou nous infirmes) l’indépendance de tes Systèmes d'Information.
Et pour ne pas non plus tout mélanger je préfère également attendre ta réponse pour réfléchir à une gestion mutualisée des droits.

Bon courage,

Bonjour

En reponse à marc : les metiers sont par exemple la gestion des assurés, le recouvrement des cotisations, les prestations de retraite et la mise a jour de la carrière. Ils sont aujourd'hui traités par des services metiers différents. Donc oui je pense qu il y a peu d interactions même si tout est relié à l assuré.
On a aussi besoin d un module de contrôle des travaux faits par les services donc celui la est plutot transverse.

Merci encore

Personnellement, je privilégie toujours la modularité, donc, dans ton cas, je partirais également sur plusieurs modules.

Pour l'aspect commun, transversal, c'est toujours un peu un problème.
Généralement, ce sont les données qui sont communes, la gestion étant souvent affectée à un module. Pour ça, JEE a bien sûr plusieurs façons de faire.

Pour les applications web, le fait d'avoir plusieurs modules n'implique pas forcément d'avoir autant de JVM, on peut faire tourner le tout sur la même.
Pour l'aspect sécurité et droits d'accès, JAAS est une spécification très intéressante, plutôt ouverte, la gestion des droits et des utilisateurs pouvant se faire de différentes manières (DB, fichiers, LDAP, etc...).

Pour la couche métier (la plus importante normalement), les EJB3 sont une très bonne réponse à toutes les problématiques, ils incorporent l'aspect local ou distant, les transactions peuvent être gérées par annotations etc... (personnellement, je les utilise et je les conseille... malgré tout ce qu'on peut lire de contradictoire sur le sujet).

A titre d'exemple, nos applications ont toutes la même architecture :

- une couche cliente (qui décrit les éléments communs, DTO, entity, interfaces Local et/ou Remote) qu'on définit comme "module" (au sens JBoss7)
- une couche métier EJB qui implémente les interfaces et fournit les DTO ou entity
- une couche Web JSF2/Primefaces pour la mise en forme
- un EAR pour publier sur un serveur d'application (JBoss7 pour le moment)

Les accès et droits sont gérés par JAAS avec un "custom module" pour fournir des notions spécifiques d'accès aussi bien à la couche web que la couche EJB (nous avons un objet "Principal" enrichit et les rôles ont des attributs spécifiques).
Certains éléments, comme toi, sont transversaux (clients, fournisseurs, collaborateurs, etc...) et ça fonctionne très bien.

Maintenant, pour les évolutions, il va de soit que certaines modifications nécessiteront de refaire une batterie de tests de non régression, mais d'autres non. Dans tous les cas, si tu n'as qu'une seule application, ça ne change rien à la problématique...

Voilà, c'est mon avis et mon expérience, on peut en trouver d'autres ;)

Je sens que nous sommes tous partis vers de la modularité. Normal, c'est un forum JAVA. Les aficionados des ERP auraient eu une autre approche ;)

En ce qui concerne le module de gestion des droits je partage l'avis de OButterlin, tu dois demander à ta maitrise d’œuvre d'implémenter la spécification JAAS.
C'est peut être aussi le moment de penser (ou repenser) l'authentification et le référencement des utilisateurs (internes et externes) de ton système d'information d'entreprise.
Y a-t-il dans ton entreprise un annuaire (LDAP - AD) ou une base de données unique qui fait office de révérenciel unique des utilisateurs? Si la réponse est oui, l'utiliser devra être pour la SSII une exigence.

Quant à l’hébergement, tu dois d'abord définir l'architecture de ta solution en production :
quel OS --> microsoft ou unix/linux
quel AS --> sans EJB (TOMCAT...) ou avec EJB (wildfly...)
quelle base de données --> relationnelle ou nosql
dans un second temps tu dois savoir si tu héberges dans le cloud ou dans tes murs

Bonjour

Merci à vous pour ces éléments.

Oui on a un AD pour l'authentification avec jasslounge pour le SSO vers l'appli.
Et il est prévu de gérer les droits au sein de l'application dans un "écran"/"module" de l'application (et en base de données relationnel)

Pour l'hébergement je n'ai pas de soucis, c'est surtout sur l'indépendance de fonctionnement des modules/applications que je m’interroge.
Par exemple dans les précisions données plus haut, je voudrais qu'une modification fonctionnelle sur le domaine recouvrement ne m'oblige pas à faire la recette du domaine retraite mais aussi que je puisse mettre en production les modifications recouvrement sans arrêter le fonctionnement du domaine retraite.
C'est pour ça que je m'interroge sur la représentation technique d'une application et/ou d'un module en lien avec la JVM, par exemple je ne relance que la JVM recouvrement et non la JVM retraite .. et dans ce cas, est-ce plus consommateur de ressources (cpu, ram) d'avoir 2 JVM au lieu d'une qui contient les 2 domaines ? j'ai aussi vu une spec OSGI, peut être que ça permet de modulariser comme je veux ?

Là le prestataire nous propose de gérer le domaine recouvrement dans un jar et le domaine retraite dans un autre jar puis de déployer au travers d'un unique war. Je n'ai pas la vision JVM par contre.
Mais je n'ai pas l'impression que cela réponde à ma problématique d'indépendance pour limiter la recette et l'arret de prod ...

Merci

A partir du moment où tu déploies un war sur un serveur, les "modules" tournent sur la même JVM (si tu n'utilises pas de cluster).
C'est l'instance de JBoss qui prend une JVM, pas les applications déployées sur ce serveur.

Citation:

---

Envoyé par stef2015

Là le prestataire nous propose de gérer le domaine recouvrement dans un jar et le domaine retraite dans un autre jar puis de déployer au travers d'un unique war.
Merci

---

J'ai peur que ton prestataire ne te propose une suite applicative un peu monolithique pour toutes tes applications. Certainement pour 2 bonnes raisons :
1/ la base de données métier doit être mutualisée selon lui
2/ il ne doit voir qu'un seul correspondant MOA pour les spécifications de toutes les applications

Et une 3^ème, il ne veut mettre qu'un dev sur toutes les applications.

as-tu une spec par application et une recette indépendante pour chacune ?

Bonsoir

Pour la base de données, pour l instant on a des diagrammes de classes tres tres macro par domaine métier, pas un global et pas ou peu d interactions décrites entre domaines. Mais oui on est parti sur une unique bdd à priori.
On est en fin de SFG avec un unique document mais un chapitre par domaine métier.

Pour la MOA, le programme dispose d un leader MOA par domaine métier donc le presta connait le contexte. La recette se fera par le leader MOA concerné et si besoin le service métier concerné.

Mais effectivement je pense que c est surtout car le presta préfère du monolitique qui doit etre plus simple en terme de dev ( generation de code ...). Ca il nous le dit pas ;)

Le découpage en modules fonctionnels n'est pas incompatible avec une base de données unique (au sens "schema" unique)...