IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java EE Discussion :

Besoin de l'avis d'architectes J2EE


Sujet :

Java EE

  1. #1
    Membre du Club
    Inscrit en
    Novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 50
    Points : 64
    Points
    64
    Par défaut 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.

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    352
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 352
    Points : 445
    Points
    445
    Par défaut
    Oula, vaste sujet auquel je ne vais pas répondre catégoriquement, car beaucoup de choix dépendent du contexte du projet (donc je risque souvent de faire des réponses de Gascon : p'etre ben qu'oui, t'etre ben que non )

    Pour pouvoir te répondre plus précisément sur certains points il manque quelques données de contexte:
    1. Est-ce une application intranet (lan), extranet (wan)
    2. L'environnement de l'application est-il figé : OS, SGBD, serveur d'application, contraintes de sécurité
    3. Sécurité : tu dis que c'est un critère, oui mais c'est un peut flou : contraintes firewall, protocoles sécurisés, authentification
    4. L'application est-elle interne ou externe (destinée à être déployée chez un client), y a-t-il des contraintes budgétaires ou autres (coût des softwares, favoriser le libre, ...?)


    Tous ces points ont un impact sur les choix d'architecture et de solutions. Mais essayons de fournir quelques pistes.

    Si j'ai bien compris tu as 3 modes d'accès : swing, browser et service. Pour des raisons de maintenabilité ces 3 modes doivent utiliser les mêmes services. Par contre pour des raisons de performances le protocole d'accès peut être différent. L'approche Web Services globale peut sembler attrayante dans un premier abord, mais attention à l'overhead généré par les web-services : ils ne sont peut-être pas le meilleur choix pour chacun des modes.

    N'ayant pas de contrainte forte au niveau de l'architecture, il peut être interessant d'utiliser un framework permettant de s'abstraire au maximum de ces choix. C'est typiquement ce que propose le framework Spring : il permet de masquer l'utilisation des EJB / DAO au niveau du code du client. Ceci a pour avantage, non seulement de faciliter le codage, mais surtout de permettre un changement de choix technologique (EJB ou non, Web service ou non) avec un impact minimum. Et donc par exemple dans un but de réduire le temps de développement d'un premier lot, de construire la solution entièrement sur des Web services, puis par la suite en cas de problème de perfs, de basculer sur une autre implémentation sans modifier les clients.
    De plus Spring répond à ton besoin d'implémentation de DAO. En effet le framework permet soit de faciliter l'implémentation des couches DAO directement, soit d'intégrer un outil tel que iBatis permettant un niveau d'abstraction par rapport à JDBC (ok si tu ne cible qu'une seule base de données), ou Hibernate pour un mapping complet O/R avec tous les services associés (cache, pas de SQL, mapping déclaratif).
    Si ton modèle de données est relativement complexe la solution Hibernate (ou OJB, TopLink, ...) peut être intéressante en termes de temps de développement et de tests. Par contre, tout système de mapping O/R nécessite d'être mis en oeuvre correctement (vis à vis de l'application), voire tuné pour obtenir les performances optimales. Mais en général ces produits sont plutôt performants.

    Pour la question du choix du conteneur, dans un premier temps je dirais que Spring n'est pas à prendre en ligne de compte à ce niveau. Je te conseillerais plutôt de le mettre en oeuvre quelle que soit la solution retenue (conteneur web, conteneur EJB) principalement pour les raisons évoquée au-dessus.
    Pour ce qui est de l'usage de RMI, personnellement je n'y suis pas favorable (si on fait abstraction de RMI/IIOP pour les EJB) pour des raisons de déploiment et de sécurité (problèmes pour passer les firewalls).

    Pour le choix du conteneur, attention éventuellement à la différence de coût entre un simple conteneur web ou un serveur d'application complet. De même si l'application doit être déployée chez des clients, attention à l'utilisation des EJBs, certains clients ont une aversion pour ceux-ci et leur utilisation peut être redibitoire.

    Question performance, nous avons dans notre société deux applications utilisant chacune une de ces solutions, et en terme de performance nous avons à peu près les mêmes résultats avec et sans EJB. Par contre le déploiement et la portabilité sont meilleurs sans EJB.

    Pour ce qui est de la gestion de version il y a 2 problématiques :
    1 - versionning du code : pour cela CVS, VSN, .. font très bien l'affaire
    2 - la montée de version avec accès à la ou les versions précédentes: pour cela le plus simple est de mettre en frontal de l'application un serveur proxy (Apache fait très bien l'affaire avec le mod_proxy ou mod_rewrite) afin de rediriger les requêtes entrantes vers une version ou une autre, soit sur un même serveur avec des contextes applicatifs différents, soit sur des serveur différents. Ainsi, avec une url donnée le client accède toujours à la dernière version de manière transparente, et pour accéder à une autre version il utilise une url spécifique. Cela permet en plus de faire des retours arrière sans prévenir tous les clients, et avec un temps d'interruption de service minimum.

    N'ayant pas toutes les données, j'aurais tendance à dire fait au plus simple dans la mesure où cela permet de répondre au cahier des charges. Pour la partie Web utilise un framework de présentation tel que Spring+JSF, Struts, ... cela facilitera l'implémentation (surtout dans le cas d'une équipe "jeune" sur J2EE), pour la persistence, repose toi sur un framework tel que Hibernate, et entre les 2 utilise Spring qui fera la glue en plus des différents services offerts (IoC, ...). en partant sur cela je pense que tu devrais avoir le meilleur compromis performance / productivité / maintenabilité.

    Juste une précision sur le clustering / load-balancing : ne pas oublier d'en tenir compte lors des choix d'architecture / de configuration / d'implémentation car cela peut impliquer des choix qui n'auraient pas été faits pour une application simple, par exemple sur la gestion du cache base de données : sur une application distribuée ce point est critique, car le cache doit lui-même être distribué, à moins de choisir de ne pas utiliser de cache au niveau de la persistence, mais de le déporter au niveau de la session utilisateur (ce n'est qu'un exemple).

    Bref, cette phase est l'une des plus intéressante d'un projet, mais aussi une des plus complexe car les choix réalisés peuvent avoir un effet sur la réussite ou non du projet, alors attention de bien prendre en compte tous les paramètres (attention aussi à l'envie d'utiliser la dernière techno qui vient de sortir, juste pour le plaisir, il est parfois plus prdent d'utiliser une techno moins dans le vent mais qui a fait ses preuves )

    Jacques Desmazières

  3. #3
    Membre du Club
    Inscrit en
    Novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 50
    Points : 64
    Points
    64
    Par défaut
    Avant tout chose je te remercie déjà du temps passé pour la rédaction de ta réponse

    Oula, vaste sujet auquel je ne vais pas répondre catégoriquement, car beaucoup de choix dépendent du contexte du projet (donc je risque souvent de faire des réponses de Gascon : p'etre ben qu'oui, t'etre ben que non ) Est-ce une application intranet (lan), extranet (wan) ?
    En fait les deux, web application et web services pour l'utilisateur final (WAN), intranet pour les administrateurs (LAN via VPN).

    L'environnement de l'application est-il figé : OS, SGBD, serveur d'application, contraintes de sécurité
    OS: Linux
    SGBD: MySQL 5.x

    Pour le reste on reste ouvert avec une préférence pour le monde libre.

    contraintes firewall, protocoles sécurisés, authentification
    L'application est-elle interne ou externe (destinée à être déployée chez un client), y a-t-il des contraintes budgétaires ou autres (coût des softwares, favoriser le libre, ...?)
    En ce qui concerne la sécurité, l'application n'est pas destinée à être déployée en clientèle, c'est un développement interne qui sera déployé sur un serveur dédié en dépôt chez un hébergeur.

    Donc si nous permettons l'accès à nos objets métiers à distance, il faudra mettre en place un mécanisme d'authentification, d'autorisation (gestion des rôles) et la sécurisation des données lors de leurs transports.

    Pour l'application web, c'est assez classique comme développement. Pour la sécurisation des données la mise en place de SSL fera l'affaire.

    Ensuite pour l'accès aux objets métiers, cela dépendra des technos que nous utiliserons.

    Pour les services web on utilisera HTTPS en ajoutant dans la couche web service le mécanisme d'authentification / autorisation avant d'appeler la couche métier.

    Pour les EJB, soit on configure un accès VPN et c'est ce qui nous semble le plus simple, soit il est possible d'après nos lectures d'appeler les EJB via RMI/SSL (http://wiki.jboss.org/wiki/Wiki.jsp?page=PooledInvoker).

    En ce qui concerne l'authentification et l'autorisation des EJBs il nous semble que le service JAAS est là pour ça dans le cadre d'un serveur d'applications comme JBoss.

    Si j'ai bien compris tu as 3 modes d'accès : swing, browser et service. Pour des raisons de maintenabilité ces 3 modes doivent utiliser les mêmes services. Par contre pour des raisons de performances le protocole d'accès peut être différent. L'approche Web Services globale peut sembler attrayante dans un premier abord, mais attention à l'overhead généré par les web-services : ils ne sont peut-être pas le meilleur choix pour chacun des modes.
    Les Web Services sont là uniquement pour l'utilisateur final et éventuellement pour l'application Swing en fonction de l'architecture. En aucun cas l'application web n'accèdera à la couche métier via les web services.

    Pour ce qui est de l'usage de RMI, personnellement je n'y suis pas favorable (si on fait abstraction de RMI/IIOP pour les EJB) pour des raisons de déploiment et de sécurité (problèmes pour passer les firewalls).
    Dans le cadre de notre architecture avec un accès via VPN cela ne pose aucun souci, le test a été effectué.

    Question performance, nous avons dans notre société deux applications utilisant chacune une de ces solutions, et en terme de performance nous avons à peu près les mêmes résultats avec et sans EJB. Par contre le déploiement et la portabilité sont meilleurs sans EJB.
    Voila ce que nous attendions justement c'est le retour d'une personne ayant mis en place les différentes architectures et qui peut nous donner un avis objectif.

    Pour ce qui est de la gestion de version il y a 2 problématiques :
    1 - versionning du code : pour cela CVS, VSN, .. font très bien l'affaire
    2 - la montée de version avec accès à la ou les versions précédentes: pour cela le plus simple est de mettre en frontal de l'application un serveur proxy (Apache fait très bien l'affaire avec le mod_proxy ou mod_rewrite) afin de rediriger les requêtes entrantes vers une version ou une autre, soit sur un même serveur avec des contextes applicatifs différents, soit sur des serveur différents. Ainsi, avec une url donnée le client accède toujours à la dernière version de manière transparente, et pour accéder à une autre version il utilise une url spécifique. Cela permet en plus de faire des retours arrière sans prévenir tous les clients, et avec un temps d'interruption de service minimum.
    C'est exactement l’architecture que nous pensions mettre en place pour déployer les différentes versions. Pour la gestion du code source nous utilisons déjà Subversion et la gestion du projet s'effectue via Maven2+Eclipse. Dans le cadre d'un projet J2EE avec packaging dans un EAR, nous aurions aimé savoir il y avait un best practice ou une convention à adopter pour générer les EAR afin de déployer en // les différentes versions des applications.

    N'ayant pas toutes les données, j'aurais tendance à dire fait au plus simple dans la mesure où cela permet de répondre au cahier des charges. Pour la partie Web utilise un framework de présentation tel que Spring+JSF, Struts, ... cela facilitera l'implémentation (surtout dans le cas d'une équipe "jeune" sur J2EE), pour la persistence, repose toi sur un framework tel que Hibernate, et entre les 2 utilise Spring qui fera la glue en plus des différents services offerts (IoC, ...). en partant sur cela je pense que tu devrais avoir le meilleur compromis performance / productivité / maintenabilité.
    L'équipe est effectivement jeune avec aucun a priori sur les technologies existantes. Par contre que ce soit Spring ou JSF, de part leur architecture respective ces frameworks utilisent la réfection et la création de dynamic proxy pour Spring. Est-ce que cela ne rajoute pas une surcharge au niveau du runtime et par conséquence dégrade les performances de l'ensemble.

    Juste une précision sur le clustering / load-balancing : ne pas oublier d'en tenir compte lors des choix d'architecture / de configuration / d'implémentation car cela peut impliquer des choix qui n'auraient pas été faits pour une application simple, par exemple sur la gestion du cache base de données : sur une application distribuée ce point est critique, car le cache doit lui-même être distribué, à moins de choisir de ne pas utiliser de cache au niveau de la persistence, mais de le déporter au niveau de la session utilisateur (ce n'est qu'un exemple).
    L'application doit pouvoir supportée la montée en charge c'est pour cette raison que nous nous sommes tournées naturellement vers un serveur d'applications comme JBoss. Avec l'arrivée des EJB 3 et des annotations qui simplifient le développement cela nous semblait être une bonne solution. En nous documentant et en découvrant les composants disponibles (EJB Statefull, JMS) nous avons vu dans ces services des moyens d'améliorer le design de notre application.

    Pour Spring, j'avais mis de coté ce lien fort intéressant sur la mise en place d'un cache sur une couche DAO (Declarative Caching Services for Spring -- http://dev2dev.bea.com/pub/a/2006/05...-caching.html). Les fournisseurs proposent dans certains cas la réplication des données du cache.

    Question qui a son importance au vu du design de notre application. Dans le cadre de Spring est-il possible de réutiliser des composants tel qu'il est possible de le faire avec les EJBs via l'interface local entre plusieurs applications (avec des performances équivalentes) ? Pour parler plus concrètement, si nous déployons 3 applications Spring sous JBoss, est-il possible d'utiliser des couches métiers d'une application depuis une autre en ayant les mêmes performances qu'un accès à l'interface local d'un EJB ?

    En fait nous avons un composant qui fournit des calculs de factoriels / combinatoires dont les résultats sont mis en cache pour les appels ultérieurs. Ce composant sera utilisé dans cette application mais aussi dans d’autres à venir. Ce module aura son propre cycle de vie, de plus l’encapsulation dans un EJB nous permet de bénéficier du cache de calculs dans toutes les applications qui l’utilisent. D’où notre notre question précédente sur le versionning des composants ?

    Avec ces précisions, la solution Spring+JSF est-elle celle qui te semble toujours être la plus appropriée ?

    attention aussi à l'envie d'utiliser la dernière techno qui vient de sortir, juste pour le plaisir, il est parfois plus prdent d'utiliser une techno moins dans le vent mais qui a fait ses preuves
    Est-ce une allusion aux EJB 3 ?

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    352
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 352
    Points : 445
    Points
    445
    Par défaut
    Avec ton architecture et surtout ce besoin de partage de ton moteur de calcul peut être qu'une solution hybride est envisageable. C'est à dire une architecture autour d'un conteneur web pour la présentation / persistence, plus des EJB session pour les services partagés. Sinon tout développé en EJB est aussi envisageable, par contre je n'ai pas de retour sur les performances EJB 3.

    Dans le cadre d'un projet J2EE avec packaging dans un EAR, nous aurions aimé savoir il y avait un best practice ou une convention à adopter pour générer les EAR afin de déployer en // les différentes versions des applications.
    Je ne connais pas de "best practice" pour cela, il en existe surement, mais ce que nous faisons avec nos applications, c'est de permettre de définir le contexte de la webapp lors de l'installation. Et comme notre application est packagée dans un EAR, il n'y a pas d'interaction entre les différentes versions déployées sur le serveur d'application. Par contre dans ton cas, il faudra faire quelque chose vis à vis des services partagés si tu dois en avoir plusieurs versions en ligne sur le même serveur.

    L'équipe est effectivement jeune avec aucun a priori sur les technologies existantes. Par contre que ce soit Spring ou JSF, de part leur architecture respective ces frameworks utilisent la réfection et la création de dynamic proxy pour Spring. Est-ce que cela ne rajoute pas une surcharge au niveau du runtime et par conséquence dégrade les performances de l'ensemble.
    En effet, tous ces frameworks (JSF, Struts, ...) reposent plus ou moins sur la reflexion, et ceci a un coût en terme de performances, mais en contre partie ils "forcent" les développeurs à programmer un peu plus propre (MVC, ...) et rendent en général le code plus maintenable. De plus il est parfois possible de limiter l'utilisation de la reflexion avec les bons choix de configuration du framework. Comme toujours les choix sont basés sur des compromis.

    Les fournisseurs proposent dans certains cas la réplication des données du cache.
    C'est justement cela que je voulais signaler. Nous avons développé une application (Struts, ORM) générant beaucoup de transactions et pouvant être distribuée. Nous avons donc mis en oeuvre un de ces systèmes de synchronisation de cache et suite à des benchmarks nous nous sommes rendu compte qu'au final cette synchronisation de cache générait un goulet d'étranglement. Nous avons supprimé le cache sur la base de données, et avons plus que doublé la capacité à monter en charge

    En fait nous avons un composant qui fournit des calculs de factoriels / combinatoires dont les résultats sont mis en cache pour les appels ultérieurs. Ce composant sera utilisé dans cette application mais aussi dans d’autres à venir. Ce module aura son propre cycle de vie, de plus l’encapsulation dans un EJB nous permet de bénéficier du cache de calculs dans toutes les applications qui l’utilisent.
    En effet dans ce cas précis l'utilisation d'EJB Session Stateless semble tout indiqué. Par contre déployer ces EJB dans un EAR indépendant afin que leur cycle de vie soit indépendant des applications clientes va compliquer la mise en ligne de plusieurs versions de celui-ci, car il faudra pouvoir préciser aux applications clientes comment accéder à ces EJB (Initial context, nom JNDI, ...).

    Avec ces précisions, la solution Spring+JSF est-elle celle qui te semble toujours être la plus appropriée ?
    Oui surtout vis à vis de l'équipe de développement. La seule chose qui pourrait aller à l'encontre de ce choix serait une interface Web très simple.
    Attention, le choix de Spring ne se limite pas à la couche présentation JSF, il propose d'autres services pour chacune des couches applicatives. De plus il adresse le problème des applications avec plusieurs modes : web, swing, web services : ce qui pourrait être intéressant dans ton cas.

    Est-ce une allusion aux EJB 3 ?
    Entre autre, même si cette remarque est plus générique. C'est souvent un travers que je rencontre parmi mes équipe de développement : se faire plaisir avec les dernière techno, plutôt que de garder en tête avant tout des problématiques opérationnelles, même si je les comprend "quand à coder, autant se faire plaisir". Mais nous avons parfois rencontré des problèmes dûs à de mauvais choix de ce type.

    Mais ton approche me semble saine, ne serait-ce que part le contenu de ce post

    Jacques Desmazières

  5. #5
    Rédacteur

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    4 184
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 184
    Points : 5 059
    Points
    5 059
    Par défaut
    Bonjour,

    le sujet est intéressant et la discussion est pertinente,
    je me permets d'ajouter une petite remarque concernant les best-practices pour les versions des ear..
    Dans le cadre d'un projet J2EE avec packaging dans un EAR, nous aurions aimé savoir il y avait un best practice ou une convention à adopter pour générer les EAR afin de déployer en // les différentes versions des applications
    tu peux utiliser ou s'inspirer de Maven 2, il propose un un bon moyen pour la construction des projets, la gestion et livraison des versions..

    Maven 2

  6. #6
    Membre du Club
    Inscrit en
    Novembre 2005
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 50
    Points : 64
    Points
    64
    Par défaut
    tu peux utiliser ou s'inspirer de Maven 2, il propose un un bon moyen pour la construction des projets, la gestion et livraison des versions.
    Je suis justement en train de lire "Better Builds with Maven, How-to Guide for Maven 2.0" (http://maven.apache.org/articles.html) dont je recommande la lecture. Il semble qu'avec le mécanisme de ressources et de filtering il nous sera assez facile de personnaliser nos descripteurs XML à partir des informations du projet. La configuration des clients se fera à partir d'un fichier de configuration qui indiquera le nom de la ressource EJB à chercher dans l'annuaire JNDI ainsi que les paramètres de connexion à l'annuaire. La modification de la version utilisée par le client (si elle est backward compatible) nous demandera juste une modification de ces fichiers et un redémarrage de l'application. Tout ceci semble être une solution acceptable.

    Nous avons supprimé le cache sur la base de données, et avons plus que doublé la capacité à monter en charge.
    Compte sur nous pour tout benchmarker surtout si on utilise Spring. L'approche de la programmation s'y prete bien.

    Entre autre, même si cette remarque est plus générique. C'est souvent un travers que je rencontre parmi mes équipe de développement : se faire plaisir avec les dernière techno, plutôt que de garder en tête avant tout des problématiques opérationnelles, même si je les comprend "quand à coder, autant se faire plaisir". Mais nous avons parfois rencontré des problèmes dûs à de mauvais choix de ce type.
    Notre plus grand plaisir n'est pas d'utiliser les dernières technos mais d'utiliser la solution qui nous permettra de finaliser le développement en respectant le cahier des charges. Ce qu'on recherche c'est l'efficacité, le reste nous importe peu.

    Avec ton architecture et surtout ce besoin de partage de ton moteur de calcul peut être qu'une solution hybride est envisageable. C'est à dire une architecture autour d'un conteneur web pour la présentation / persistence, plus des EJB session pour les services partagés. Sinon tout développé en EJB est aussi envisageable, par contre je n'ai pas de retour sur les performances EJB 3.
    Ton idée de regrouper les technologies nous semble être une très bonne idée. Application Web + Web Service + Remoting de la couche métier de l'application développés à l'aide de Spring. Moteur de calcul développé sous la forme d'un EJB. Le tout déployé sous un serveur d'applications (JBoss).

Discussions similaires

  1. Réponses: 9
    Dernier message: 16/04/2009, 03h14
  2. Réponses: 7
    Dernier message: 10/11/2005, 14h35
  3. Besoin d'un avis entre un CDD et un CDI...
    Par klereth dans le forum Emploi
    Réponses: 20
    Dernier message: 03/08/2005, 11h46
  4. Réponses: 6
    Dernier message: 28/02/2005, 15h32
  5. optimisation requetes (besoin de votre avis)
    Par seb92 dans le forum Requêtes
    Réponses: 2
    Dernier message: 21/12/2004, 12h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo