Besoin de l'avis d'architectes J2EE
Bonjour à vous tous,
Nous sommes une petite équipe et nous voulons développer une application Web. Notre choix s'est portée sur J2EE sans être confirmé dans cet environnement (nous venons du monde C et C++ et Java J2SE). Mais le domaine est si vaste qu'il nous amène a choisir les technos en environnement J2EE. C'est là où vous intervenez.
Après des journées, que dis-je des mois passés à nous documenter (merci google), voici ce que nous en avons retenu. J'espère que votre expérience nous aidera à orienter nos choix.
1. Besoins
L'application sera centrée sur un métier accessible via une application web, une application cliente (Swing), et des services Web publics. La performance, la sécurité et la montée en charge sont les paramètres les plus importants.
A priori l'utilisation des transactions distribuées ne sera pas nécessaire. Par contre JMS, EJB3 Stateless et Statefull nous semble utile sans être indispensable.
2. Choix initial
La solution qui nous vient à l'esprit c'est un serveur d'application JBoss?, le métier encapsulé dans des EJB, la persistence encapsulée dans une couche DAO elle-même utilisée par les EJB. L'application Web basée sur Struts? et les Services Web basés JAX-WS? appelant respectivement les EJB (local). L'application cliente développée en Swing utilise les EJB (remote) et déployée via Java Web Start.
3. Solutions alternatives
3.1 DAO vs Hibernate
Première question qui s'impose, le choix entre une couche DAO codée à la main avec JDBC ou l'utilisation de Hibernate via les EJB Entity.
La couche DAO permet d'utiliser toutes les fonctions du moteur SQL sélectionné. Nous contrôlons totalement le code exécuté. La productivité en prend un sacré coup.
D'après les documents que nous avons parcouru, Hibernate permet un gain non négligeable en terme de productivité, mais au niveau des perfs il est très difficile de trouver des informations. Quand la question est soulevée on parle de mécanismes de cache (objets et requêtes), donc cela veut dire que c'est plus lent mais dans quelle proportion ?
De plus rien ne nous interdit d'utiliser de tels mécanismes sur une couche DAO classique (à noter que le cache au niveau des requêtes est intégré à MySQL via la syntaxe SELECT SQL_CACHE * FROM foo).
Donc l'avantage est à relativiser hormis le fait que cela est peut être plus facile à mettre en oeuvre avec Hibernate et que la solution est déjà implémentée.
Donc la question est, est ce que Hibernate est compatible avec le mot performance où est-il préférable d'utiliser JDBC dans ce contexte ?
Le design de l'application n'implique pas trop de jointures par contre les transactions seront légions (insert & select).
Enfin Hibernate nous demandera aussi un apprentissage supplémentaire pour l'utiliser correctement.
3.2 Serveur d'applications Vs Spring+Servlet Container
En effet dans le framework Spring il existe la solution Spring Remoting pour fournir les services via RMI. Il est possible aussi d'utiliser JMS. Mais ne connaissant ni les perfs de Spring, ni les perfs des EJB le choix est difficile à faire.
Seule une personne ayant utilisée les 2 architectures pourraient nous donner un avis objectif et sans arrière pensée mercantile. Vous allez nous dire de le tester, mais nous avons tellement tester de technos ces derniers temps que nous commenceons à saturer.
A noter qu'il est possible d'utiliser un système de load balancing pour gérer la montée en charge au travers de plusieurs serveurs Tomcat?. Et il me semble avoir lu un article sur la mise en cluster d'applications Spring.
3.3 Serveur d'applications Vs Servlet Container
Pourquoi ne pas se passer de JMS et des EJB, coder une couche service, une couche DAO sous forme de librairies standards. Utiliser le tout par notre application web et les services Web. Utiliser dans l'application Swing les services Web pour accèder à notre métier.
La performance est primordiale au niveau de l'application Web et non pas au travers de l'application cliente Swing ni via les services web (sinon on ne les utiliserait pas).
L'architecture est plus légère qu'un serveur d'applications. Est-elle pour autant plus performante ?
4. Versioning des composants
Un autre point où nous n'avons pas trouvé de réponses malgré des recherches poussées, ce sont les best practices pour gérer les différentes versions des composants ejb, war déployés dans un serveur d'applications. En effet comment déployer une version plus récente d'un composant qui n'est pas retro-compatible avec la version précédente. Tout en gardant les versions précédentes accessibles.
Avec le peu d'expériences que nous avons en environnement J2EE, ce qui nous vient à l'esprit c'est de regrouper nos composants (ejb, war) que nous sérialisons dans un EAR (ex. appname-1.0.ear). Si l'EAR contient aussi une application web nous sérialisons aussi le contexte de l'application (ex. webappname-1.0).
Dans nos clients nous pensions utiliser alors la référence appname-1.0/MyBean/local ou remote selon l'usage. Est ce une solution acceptable ou existe-t-il une meilleure solution à ce problème ?
5. Votre avis
Ceux qui ont l'occasion de mettre en place ces différentes architectures pourraient peut être nous aider à faire notre choix. Et donc éviter les pièges qui ne nous sautent pas aux yeux pour l'instant.
Tout avis même partiel vis à vis des technologies présentées est le bienvenu.
Même si le serveur d'applications est plus lourd en terme de ressources, il offre beaucoup plus de services qui ne nous paraissent pas utiles pour l'instant mais qui le seront peut etre plus tard si le projet prend de l'importance. Je pense aux technos dont nous ignorons l'utilité comme JMX et tous ses acronymes propres au monde Java ;o)
La performance est impotante mais à choisir entre un gain de perfs de 5% et une diminution de la productivité de 30% nous préfèrons la solution où la productivité sera au rendez-vous surtout si le perte en terme de perfs peut être contre-balancée par la mise en place d'une machine supplémentaire pour traîter les requêtes.
Encore merci à ceux qui prendront le temps de nous répondre.
Passez une bonne journée.
