Discussion :

[Alesque]

Bonjour,

Savez vous s'il est prévu par Spring DM Server de proposer des archetypes Maven2 pour adresser les différents profils d'architecture qu'on peut rencontrer en J2EE.

Voir la figure 1 de l'article : http://www.javaworld.com/javaworld/j...1-tomcat6.html

Si vous connaissez un projet Open Source qui correspond à cela configuré en Maven2 je suis également intéressé.

Question sous jacente, vaut il mieux commencer avec un véritable serveur d'applications (Glassfish, JBoss, etc.) ou passer par Spring DM Server sachant que l'on risque au final de recosntruire ce que fait JBoss ou Glassflish (JMS, JTA, etc.).

Cordialement,
Alexandre

[julien.dubois]

Je comprends mal ta question :
- Si tu veux faire des WARs ou des bundles OSGi (qui ne sont que des JARs au final), les archetypes Maven existants fonctionnent bien entendu sans problème. Et les deux (JARs et WARs) se déploient sur dm Server sans souci.
- Le seul archetype qui risque de te manquer est pour faire un PAR, mais étant donné qu'il s'agit juste d'un zip de bundles OSGi, cela devrait également être faisable.

Pour des exemples de projets Open Source, le mieux est de regarder le PetClinic et le Spring Travel qui sont les applis d'exemple fournis avec dm Server. Sinon j'ai mon propre projet mais il n'est pas finalisé (sur Tudu Lists, http://tudu.sf.net , regarder sur SVN dans trunk/sandbox )

Sinon je ne comprends pas vraiment ton dernier point : dm Server propose des choses assez différentes des serveurs d'app classique (OSGi en particulier), mais sinon il a des fonctionnalités similaires pour un développeur Spring (qui ne fait pas d'EJB, évidemment).

[Alesque]

Bonsoir Julien,

Je me suis sans doute mal exprimé. Je vais essayer d'être plus précis.

Je souhaitais savoir si l'équipe Spring ou autres fournissaient des projets templates selon le type d'architecture J2EE que l'on souhaite réaliser.

Exemple, pour ma prochaine application je sais que je vais avoir besoin de :

• D'une couche service (logique + jpa + jms + jta)
• D'un front end réalisé par exemple avec Wicket
• D'un back end réalisé avec GWT
• D'une couche Web Service fuornissant un subset de ma couche service

From scratch, il y a un effort important à réaliser d'autant plus si on débute avec Spring ce qui est mon cas.

D'où ma question initiale : existe t'il des outils pour créer la configuration les projets selon un profil d'architecture voulu permettant l'adoption rapide de Spring même si l'on débute ?

J'ai déjà fait un checkout du projet tudu2 que je trouve très bien structuré et c'est en regardant ton projet que je me suis demandé si une telle initiative n'existait pas déjà. Je vais jeter un oeil sur les autres exemples que tu cites mais je doute que JTA soit utilisée.

Sachant que pour une telle architecture, si l'on souhaite utiliser JTA pour coordonner les datasources de JPA & JMS on en revient à développer ce qu'il y existe dans un serveur d'applications J2EE (e.g. JBoss, Glassfish, ...). Tu imagines le gain de temps que l'on peut réaliser si un outil configure déjà l'ensemble.

D'ailleurs à ce sujet j'ai lu la spec pour OSGi 4.2, on note que JTA pointe le bout de son nez... est ce que l'on pourra espérer un jour a de la transaction distribuée en remoting sur Spring ?

Cordialement,
Alexandre

[julien.dubois]

Bonsoir,

Je vois mieux ce que tu veux dire, et il y a à mon sens deux questions différentes :

- Avoir moyen de créer rapidement un squelette d'application, qui intègre un certain nombre de technologies. SpringSource propose quelque chose dans ce style avec Grails, mais pour ce que tu recherches le mieux est peut-être d'aller voir du côté de Appfuse.
Il s'agit là d'une demande récurrente de la part de nos clients, cependant : 1) il y a un tel nombre de technologies que c'est quasi impossible à réaliser et 2) c'est là qu'un intégrateur a effectivement une plus-value

- Faire des transactions. Déjà, il faut préciser que Spring gère très bien les transactions (voir l'utilisation de @Transactionnal), par contre il le délègue effectivement à un transaction manager. Ce que propose Spring est de gérer les transactions de manière déclarative, ce qui est plus intéressant que de faire du JTA directement (il gère les transactions à ta place, un peu comme il gère les connections à la base de données quand on fait du JDBC).
Ton vrai problème est que tu veux faire du XA, et là effectivement nous ne proposons pas de gestionnaire de transaction XA avec Spring. A ceci plusieurs éléments de réponse :
1) on peut utiliser un gestionnaire de transaction XA avec Spring, de type JOTM ou Atomikos. A noter que je déconseille personnellement JOTM, il n'est clairement pas prêt pour la prod.
2) nous déconseillons de manière générale l'utilisation de XA, essentiellement pour des raisons de perf.
A ce propos, voici un article que nous venons de publier à ce sujet :
http://www.javaworld.com/javaworld/j...nsactions.html

Une note très intéressante de cet article : on voit que l'on peut faire des transactions locales entre ActiveMQ et une base de données. Cela fait exactement ce que tu veux faire, sans faire de XA. Il s'agit d'une "astuce" qui marche avec une configuration spéciale d'ActiveMQ, mais cela résout ton problème et n'aura pas les défauts de XA.

[Alesque]

Bonsoir Julien,

1/ C'est pour cette raison que je faisais référence à cet article http://www.javaworld.com/javaworld/j...1-tomcat6.html, car il ne parle jamais de frameworks (hibernate, etc) mais uniquement de profils d'applications plus ou moins évoluées mettant en oeuvre différentes API de J2EE (voir page 3).

2/ Tout à fait, quand je parlais de JTA je parlais de transactions 2PC/XA.

Une note très intéressante de cet article : on voit que l'on peut faire des transactions locales entre ActiveMQ et une base de données. Cela fait exactement ce que tu veux faire, sans faire de XA. Il s'agit d'une "astuce" qui marche avec une configuration spéciale d'ActiveMQ, mais cela résout ton problème et n'aura pas les défauts de XA.

J'ai lu l'article avec attention. Je me dis très bien... mais qu'en est-il si demain j'ai besoin de monter un second serveur pour répartir la charge ? Est-ce que je pourrais me passer encore de transactions distribuées avec mon bus JMS ? Si ce n'est pas le cas, ne vais-je pas au final reconstruire ce que propose un serveur J2EE out-of-the-box ? à mon humble avis oui, et je risque donc de me détourner de Spring pour me dire, en fait ce qu'il me faut c'est un véritable serveur J2EE.

C'est dommage, car je suis persuadé que Spring peut répondre au problème tout en proposant de la programmation POJO et en permettant le déploiement des couches middleware de l'application sous forme de bundle OSGi. Ce qui est un énorme avantage pour la maintenance des applications sur la durée.

Pour en revenir à cette fameuse page 3, je pense que Spring a tout à gagner à fournir des squelettes pour chacun des profils référencés. Afin de démontrer aux personnes qui seront en charge de faire un choix lors du démarrage d'un projet, que Spring répond à leur besoin d'aujourd'hui et de demain.

N'hésitez pas à réagir et à donner votre point de vue sur la question...

Cordialement,
Alexandre

[julien.dubois]

Si tu veux à tout prix faire du XA, tu peux le faire sans souci avec Spring : Spring intègre le gestionnaire de transaction de ton serveur d'app (Weblo, Websphere, etc), voire même un gestionnaire externe (Atomikos par exemple).
L'intérêt d'utiliser Spring est d'être indépendant de ces APIs : tu déclares juste un méthode transactionnelle (avec @Transactionnal par exemple), et ensuite tu configures ton gestionnaire de transaction dans ton fichier de contexte Spring. Tu peux ainsi utiliser en dév un gestionnaire de transaction simple, et en prod utiliser le gestionnaire de transaction de Websphere, via JNDI.

- Il ne faut pas limiter J2EE au gestionnaire de transaction
- Spring te facilitera l'utilisation de gestionnaire de transaction

Quoi qu'il en soit, je ne comprends pas bien ton souci de montée en charge : ton gestionnaire XA ne doit pas être là pour t'aider à monter en charge. Ce n'est pas son boulot du tout, et d'ailleurs c'est quelque chose qu'il fera très mal : avoir à synchroniser plusieurs ressources transactionnelles, c'est très gourmand! C'est d'ailleurs pour cela que nous déconseillons généralement d'en utiliser un : tes perfs seront obligatoirement moins bonnes qu'avec une transaction simple.
Puisque tu as l'air de faire du JMS et de la base de données, et que tu veux avoir des messages transactionnels, je pense que tu vas rapidement connaitre ce type de problème...

[Alesque]

Julien,

Je ne veux pas à tout prix faire du XA, si je peux m'en passer je serais intéressé de connaître la façon d'y arriver.

J'al l'habitude d'utiliser JBoss et le couple EJB3 / JMS. Et comme je suis feinéant et que je veux m'abstraire des pbs techniques, la solution de facilité c'est d'utiliser XA, et de déléguer la gestion des transactions au container. Je me concentre sur la logique métier.

L'intérêt d'utiliser Spring est d'être indépendant de ces APIs : tu déclares juste un méthode transactionnelle (avec @Transactionnal par exemple), et ensuite tu configures ton gestionnaire de transaction dans ton fichier de contexte Spring. Tu peux ainsi utiliser en dév un gestionnaire de transaction simple, et en prod utiliser le gestionnaire de transaction de Websphere, via JNDI.

C'est pour cette raison que je souhaiterais monter en compétence sur Spring, je le trouve très flexible sur beaucoup de points. Aujourd'hui j'ai un projet à démarrer qui n'a pas besoin des EJB3 au sens que je n'ai pas besoin de faire de propager le contexte transactionnel sur de l'invocation à distance.

J'ai très bien intégré le fait que je pourrais refaire avec Spring ce qu'il est possible de faire dans un serveur d'applications.

Le gestionnaire XA, il me facilite bien la vie quand je dois persister des données dans une db et envoyer des messages dans un bus JMS de façon atomique. Si je peux avoir le même service avec des performances plus élevées j'achète

J'ai bien compris qu'il y avait un trick pour ne pas utiliser XA et avoir cette atomicité avec une config de ActiveMQ. Mais est ce que cela restera valable si demain je dois déployer l'appli Spring sur un autre serveur pour répartir la charge (sachant qu'il faudra à mon avis modifier la config d'ActiveMQ pour le configurer en cluster) ?

Cordialement

[julien.dubois]

Si je résume :

- Si tu le souhaites, tu peux continuer à faire exactement comme avant, en utilisant le gestionnaire de transactions XA de ton serveur d'appli
- Spring te propose de le faire sans dépendre de ce gestionnaire de transactions. C'est utile si tu ne fais pas de XA et pense peut-être l'introduire plus tard, mais c'est également utile en dévelopement et en test (inutile de lancer le gros serveur d'app)
- Nous te proposons en effet un certain nombre d'astuces (par exemple dans l'article de Dave Syer), pour éviter de faire du XA
- Faire du XA est de manière générale une mauvaise idée : les perfs seront obligatoirement mauvaises (à cause de l'écriture du log entre autres), et tu augmentes considérablement tes problèmes potentiels en prod.
- Sur ce dernier point, et pour prendre ta configuration spécifique : vas juste faire un tour sur le Jira de JBoss et tape "XA"... JBoss est incapable de faire du XA correctement entre une base de données et un serveur JMS - c'est la raison principale à mon sens pour laquelle un serveur d'appli commercial est intéressant par rapport à JBoss. Note qu'ils changent ces deux sous-systèmes dans JBoss 5. J'ai déjà passé plusieurs mois sur ce sujet, et je peux t'assurer que mon équipe a bien souffert (précision supplémentaire : nous étions clients du support JBoss).

[Alesque]

- Si tu le souhaites, tu peux continuer à faire exactement comme avant, en utilisant le gestionnaire de transactions XA de ton serveur d'appli

Tout à fait, mais si je peux me passer de XA en ayant le même service rendu je prends.

- Spring te propose de le faire sans dépendre de ce gestionnaire de transactions. C'est utile si tu ne fais pas de XA et pense peut-être l'introduire plus tard, mais c'est également utile en dévelopement et en test (inutile de lancer le gros serveur d'app)

+1

- Nous te proposons en effet un certain nombre d'astuces (par exemple dans l'article de Dave Syer), pour éviter de faire du XA

+1

- Faire du XA est de manière générale une mauvaise idée : les perfs seront obligatoirement mauvaises (à cause de l'écriture du log entre autres), et tu augmentes considérablement tes problèmes potentiels en prod.

- Sur ce dernier point, et pour prendre ta configuration spécifique : vas juste faire un tour sur le Jira de JBoss et tape "XA"... JBoss est incapable de faire du XA correctement entre une base de données et un serveur JMS - c'est la raison principale à mon sens pour laquelle un serveur d'appli commercial est intéressant par rapport à JBoss. Note qu'ils changent ces deux sous-systèmes dans JBoss 5. J'ai déjà passé plusieurs mois sur ce sujet, et je peux t'assurer que mon équipe a bien souffert (précision supplémentaire : nous étions clients du support JBoss).

Je ne te contredirais absolument pas sur ce point, mais j'en profiterais pour mettre en avant un article :

http://www.jboss.org/feeds/post/tran...ery_in_jbossas

First, let me say this - if you think your application deployed in JBossAS can recover from transaction failures, I would recommend you read this blog and double check your configuration.