Transaction déclarative dans Spring & RuntimeException

L'un des avantages de Spring est sa capacité de gérer les transactions de façon déclarative! évident !

J'ai eu (encore une autre fois) un appel d'urgence d'un client à ce propos.

L'urgence était au stade panique : « … le transactionnel de Spring avec Hibernate et JdbcTemplate, ça marche pas !, L'application a fait un débit d'un compte, a eu un problème lors du l'inscription du crédit, et n'a pas fait un « roll back » sur le débit, …

Conclusion : Spring ne sait pas gérer les transactions !! »

Un blasphème selon la communauté des « Springiens »

Une fois sur place, je commence par vérifier la « règle numéro 1 » de bon voisinage dans une transaction : l'information en cas de problème !

Je commence par la couche DAO, et je remonte petit à petit, et patiemment...

Premier constat : l'un des développeurs « catch » des exceptions sql et ne lève pas à la place une RuntimeException, il fait du log...

Second constat : un autre développeur « catch » des exceptions et lève à la place des exceptions simple de type Exception.

Une fois ces deux points corrigés, le miracle se produit : Spring gère très bien les transactions déclaratives

Morale de l'histoire : il ne suffit pas de bien faire les déclarations, que ce soit par des annotations ou bien par l'ajout de ce tag XML comme suit

<bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager" lazy-init="true">

<property name="sessionFactory" ref="sessionFactory" />

</bean>

<bean id="txProxyTemplate" abstract="true"

class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">

<property name="transactionManager" ref="transactionManager"/>

<property name="transactionAttributes">

<props>

<prop key="save*">PROPAGATION_REQUIRED</prop>

<prop key="remove*">PROPAGATION_REQUIRED</prop>

//

</props>

</property>

</bean>

Mais, le plus important c'est de savoir que dans ce mode Spring va réaliser le rollback si une des méthodes lève une exception non gérée de type RuntimeException

(Cela rappelle les débuts des EJB et des arguments avancés par leurs défenseurs)

Rappelons que cette façon de faire pourra être modifiée, mais ceci est un autre sujet ...

NB du 07/02/2009 : un article à lire : Transaction strategies: Understanding transaction pitfalls

Maîtriser son environnement de développement, le premier pas vers une plus grande productivité

J'ai eu l'occasion en l'espace d'une journée d'intervenir dans deux environnements différents, mais dans le cadre de la phase pré-production : assister 2 équipes dans la résolution de problèmes de dernières minutes avant le lancement !

Le premier cas : le matin, auprès d'une équipe de jeunes développeurs motivés maitrisant Eclipse version ganymade, l'outil de gestion de version Subversion intégré à Spring, l'outil Jira pour le suivi des bugs, cruisecontrol pour le build continue, … tous les plugins nécessaires ont été installés (SVN, Maven, SpringIde, Hibernate tools, ).

Le second cas : l'après midi, une équipe exploitant l'IDE Jdeveloper 11g, pas d'outil de suivi de bugs …

Les équipes avaient le même niveau d'un point de vue conceptuel, la maitrise même du langage Java et de la plateforme Java EE,

Dans les 2 cas on trouve les mêmes sujets: application de gestion en mode web, exploitant les framworks classiques Spring, Hibernate, pour l'un c'est du JSF et pour l'autre c'est du JSP/Struts, il ne s'agit ni de SOA, ni de SaaS, ni de PaaS ou d'un autre Buzz, les choses s'articulaient simplement autour de la notion de CRUD.

De point de vue productivité, le contraste, était frappant :

• la première équipe a réalisé plus du double du travail que la seconde (et ça ne pourrait pas être expliqué par la lenteur de Jdeveloper),

Cela m'a permit de prendre valider, encore une autre fois, les constats suivants :

- Maitriser les raccourcis clavier (shortcut keys) de votre IDE , connaitre toutes les techniques de navigation efficace dans votre code, trouver un élément à la vitesse de la pensé ! ,

- Lier directement l'IDE à l'outil de gestion de version permet de gagner un temps appréciable (surtout en temps de crise)

- Automatiser les tâches répétitives (pas seulement la compilation, mais aussi le transfert de fichiers du développent vers de la pré-prod par exemple, rend le travail des équipes plus fluides en éliminant les phases d'hésitations et de vérifications …

- Dans le développement du code source, observer scrupuleusement la règle des 30secondes (on doit être capable de comprendre la logique d'une méthode en mois de 30s) permet d'aller plus vite pour fixer un bugs (même sous le stress)!

En plus, lorsque l'équipe est habituée à la responsabilité collective "du code source", les choses vont mieux..

En théorie, il n'y pas de différence entre pratique et théorie

Dans la pratique si.

PC payable à l'usage : est que Microsoft va pouvoir Breveter le concept

Il parait que non (pour l’instant) :
L'USPTO (office américain des brevets) a rejeté la demande de brevet concernant : « la facturation à l’usage des PC », déposée par Microsoft
La décision définitive n’est pas encore prononcée,
Que va faire Microsoft pour rendre « brevetable » ce concept,
Mais surtout qu’est ce qui se cache derrière cette manœuvre
A suivre ...

Java: Quelles « résolutions technologiques » pour 2009

La question de proposer des « résolutions technologiques » de l’année 2009 est la suivante :

Quelles sont les technologies java qui ont atteint une certaine maturité nous permettant de les utiliser dans des projets réels, et d’investir du temps à les connaitre et les maitriser

Sans regretter ce choix quelques mois après

J’avoue que la question est difficile, mais la tentation est grande de se lancer des résolutions en ce début d’année (ça serait plus facile à faire le 31 décembre)

Je propose :

1) OSGI (SpringDM) en préparation d’un monde "dynamique"

2) Groovy/grails sous l’égide de Spring

3) Android

4) JavaFX

5) EclipseLink en remplacement de Hibernate qui stagne

6) RAP (Eclipse)

7) SCA vers un monde de services (Spring est présent là aussi)

8) JBPM 4 & BPMN

9) GoogleAPPs (s’il adopte java, c'est fait depuis début Avril 2009)

10) SCALA (si j’ai encore du courage en fin d'année...)


Mais, tout dépendra des projets, du temps, de la détermination et de la fameuse crise...

Groovy et Grails dans le giron de SpringSource : Un bel avenir pour les langage dynamique

SpringSource a mis la main sur Groovy (un language dynamique pour la JVM), et Grails(un framework de développement « rapide » Web, de type Ruby), en achetant la société G2One.
Je pense que cela va booster Groovy, bien qu'il soit déjà le langage dynamique pour la JVM le plus populaire.

Cela va booster l’idée d’utiliser un langage dynamique, avant l’arrivée de java 7 qui pousse vers la même direction

En ce qui concerne Grails, les choses sont peu plus compliquées,je lui prédit un bon avenir du coté des maquettes, des sites d’administration et des applications web « éphémères » ou à
usage unique.

Attendons, un peu de voire la direction que va
donner SpringSource (ex interface 21) à ce type de langage où ce qui est simple
devient presque implicite….

mais ceci est un autre sujet ...

-----------------

autres sujets : Grails

Groovy & Grails : L’instabilité en vue du coté JRuby, une opportunité de plus pour Groovy & Grails



Groovy et Grails dans le giron de SpringSource : Un bel avenir pour les langage dynamique

Utiliser les Intercepteurs et l'AOP de Spring pour mesurer les temps de réponses de vos méthodes

J'ai eu une question de la part d'un client qui souhaite mesurer les temps de réponse de certaines méthodes dans une moulinette de calcul d'échéance de prêts bancaire, développé en Java.

Heureusement, le batch exploite le framework Spring.

Le travail devient alors assez simple,

combiner les intercepteurs de Spring et ses capacités AOP (Aspect Programming).

Il s'agit de mesurer, par exemple, les temps de réponses de toutes les méthodes qui réalisent des calculs et qui

commencer par prépare les « outils » de mesure, il s'agit du ben offert par Spring : le PerformanceMonitorInterceptor

<bean id="performanceInterceptor" class="org.springframework.aop.interceptor.PerformanceMonitorInterceptor"/>

il s'agit d'un Advice, dans le jargon AOP

Ensuite, associer cet Advice à un pattern particulier : ici toutes les méthodes de type .*calcul.*

<bean id="performanceAdvisor" class= "org.springframework.aop.support.RegexpMethodPointcutAdvisor"> <property name="advice" ref="performanceInterceptor"/> <property name="patterns"> <list> <value>.*calcul*.*value> list> property> bean>

L'étape suivante, consiste en la transformation du bean service en Taget dans l'optique de l'exposer indirectement à travers le ProxyFactoryBean de Spring.

<bean id="calculEcheanceServiceTarget" class="com.netprogress.spring.perf.CalculEcheanceServiceImpl"> <property name="echeanceDao" ref="echeanceDao"/> bean> <bean id="echeanceDao" class="com.netprogress.spring.perf.EcheanceDaoImpl"> bean>

<bean id="calculEcheanceService" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyInterfaces"> <value>com.netprogress.spring.perf.CalculEcheanceServicevalue> property> <property name="target"> <ref bean="calculEcheanceServiceTarget"/> property> <property name="interceptorNames"> <list> <value>performanceAdvisorvalue> list> property> bean>

Une fois ce fichier Spring terminé,

vérifier que votre fichier log4j.properties présente la ligne suivante

… log4j.logger.org.springframework.aop.interceptor. PerformanceMonitorInterceptor=TRACE ….

Lancer l'exécution :

[2009-01-05 23:19:44,406] DEBUG : org.springframework.aop.interceptor.PerformanceMonitorInterceptor. invokeUnderTrace (PerformanceMonitorInterceptor.java:63) - StopWatch 'com.netprogress.spring.perf.CalculEcheanceService.getCalculEcheance' : running time (millis) = 16

Ne pas oublier de supprimer cette configuration en production

autre facçon de faire :

  <bean id="performanceInterceptor" class="org.springframework.aop.interceptor.PerformanceMonitorInterceptor" />   

 - <aop:config>  

  <aop:advisor pointcut="execution(* com.netprogress..*.*(..))" advice-ref="performanceInterceptor" />   

  </aop:config>  

La version 4 de JBPM prend le virage de BPMN

La version Alpha 1 de JBPM 4 prend clairement le virage de la notation BPMN,

Business Process Modeling Notation (BPMN) est une notation graphique standardisée pour modéliser des processus métiers dans un workflow très utile dans une architecture SOA.

Le choix de BPMN est judicieux puisqu’il est langage de prédilection de la communauté BPM et se trouve mappé directement à BPEL.

Cela permettra d’unifier à terme les langages de modélisation et de notations des BP

Ce qu’il faut observer c’est le composant PVM (Process Virtual Machine) qui a pour but de fournir un moteur de processus générique sur lequel on va construire des extensions de langages (ex: XPDL, BPEL, JPDL, et d’autres langages spécifiques).

Jboss s'active vivement à offrir tout le stack de la plateforme SOA dans une perspective PaaS / SaaS.

Il faut tester rapidement cette version et surtout valider la compatibilité ascendante avec la version 3.x

A suivre …

articles sur le BPM

1. Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )

2. Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”

3. Quelle est la différence entre JBPM et Intalio ?

4. Graph Oriented Programming (GOP) avec JBPM

5. La version 4 de JBPM prend le virage de BPMN

6. BPM & Moteur de workflow : l’offre open source

Plateforme as a Service, PaaS: le modèle SaaS a besoin d'une plateforme spécifique pur exister

L'informatique vit au rythme du changement, des annonces et des Buzz,

ce qui rend difficile de différencier une vraie révolution d'une simple évolution,

A un certain moment on a pensé qu'un progiciel intégré, avec une vision monolithique, permettra de satisfaire les besoins de l'entreprise, et voilà que les leaders de l'ERP de SAP à Oracle en passant par Miscorsoft, nous "gavent" d'exposés sur les vertus du modèle SaaS, voir même lancer des offres "réelles" selon ce modèle (SAP, …)

SaaS, est l'acronyme de Software as a Service. Il s'agit d'une technologie consistant à fournir des services ou des logiciels informatiques par le biais du Web et non plus dans le cadre d'une application de bureau ou client-serveur.

Le concept SaaS, apparu au début des années 2000, se trouve promu pour prendre la place de celui d'Application Service Provider (ASP).

SaaS va nous offrir une nouvelle génération de progiciel, modulaire et souple, organisé en services métiers réutilisables, configurables, accessibles via le web (ou plus simplement via le réseau de l'entreprise), le tout en respectant contractuellement un SLA et un Qos.

SaaS va permettre de libérer les entreprises des contraintes d’infrastructures informatiques messagerie, portail documentaire, bureautique, CRM, applications métier… seront disponibles par internet, en mode mutualisé, et facturables selon l’usage

Selon le rapport de McKinsey, "emerging platform wars in enterprise software", la taille du marché pour SaaS pourrait atteindre 37 Billion de dollars au cours des 5 prochaines années.

D'autres études de Forrester et du Gartner confirment qu'il s'agit d'un mouvement de fond accompagné d'un changement de paradigme : La vision monolithique et rigide d'un progiciel ne correspond plus aux besoins actuelles d'agilité, de changement et d'évolution perpétuels des SI des entreprises.

Le passage vers le SaaS, qui selon le rapport Mckensy est inéluctable, le mouvement est amorcé, la course entre les éditeurs est lancé, reste à connaître (malin qui pourra le deviner …) le temps que ça va prendre pour s'établir en régime permanent et la liste des "heureux survivants", ainsi que le prétendant au trône

Selon McKinsey, Saas a impact important sur les éditeurs de logiciels, qui n'auraient qu'une "fenêtre de tire" limitée pour migrer leurs offres vers un modèle SaaS ou risquent d'être effacés par la concurrence des nouveaux arrivants.

"La rue vers le SaaS", du déjà vue :

cela rappelle, les annonces à l'époque du passage du mainframes vers le client/serveur à deux niveaux,

ou bien la longue transition du client/serveur vers les architectures n-tiers, que ce soit à client riche ou léger, longtemps avant l'apparition d'AJAX et des mashups

alors, qu'est ce qui va caractérise cette "nouvelle version de changement de paradigme"

l'un des points importants de la réussite de l'ère SaaS, est le besoin d'une plateforme supportant le nouveau paradigme,

lé passage vers le client/serveur à été favorisé par l'émergence des IDE facilitant la mise en ouvre des langages de types Visual Basic et Forms

les architectures n-tiers ont eu besoin d'une infrastructure logicielle, qu'on s'accord tous à appeler serveur d'application, pour pouvoir réellement exister, on imagine pas un éditeur réaliser un logiciel métier et écrire en même temps toute la "plomberie" nécessaire à soutenir les différents tiers (gestion de session, transaction déclarative, pool de connexion, serveur web, …)

c'est la maturité de l'offre de plateformes "serveur d'application" qui a rendu viable un développement selon le modèle n-tiers,

Besoin d'une plateforme pour soutenir le développement des applications en mode de SaaS :

Reste que , le modèle d'application, JEE ou .Net, selon une architecture classique, est un frein pour le passage à SaaS,

en effet, le SaaS nécessité des nouveaux besoins qui perturbent les offres classiques d'hébergement, le SaaS a besoin de sa propre suite d'infrastructure avec sa "plomberie spécifique" ou plutôt sa plateforme approprié :

- des plateformes contenant des éléments de bases, telque les Web Service, la sécurité, les outils de facturation à l'usage,

- des plateformes conçue pour un usage multi-utilisateurs, multi-modes, avec une capacité de virtualisation et de cloisonnement des données des différents utilisateurs

- des plateformes ayant une capacité de personnalisation et d'intégration on-demande

Certains des fournisseurs de solutions, s'apparentant à du SaaS (la forme finale du SaaS est loin d'être connue à ce jour) comme SalesFoces, ont eu besoin de réaliser en interne, une plateforme propriétaire que l'entreprise devra maintenir et faire évoluer toute seule,

cela reviendrait à développer des Portlets sans avoir de Portail, ou à faire du JEE sans serveur d'application !

C'est acceptable lorsqu'on est précurseur, et qu'on n'a pas d'autres solutions,

mais lorsqu'on parle d'un mouvement de fond de l'industrie du "progiciel", qui va perturber l'ordre établi des éditeurs de logiciels, on imagine difficilement la migration massive des ces éditeurs vers le modèle SaaS, sans l'existence d'une offre de Plateforme,

une offre mature capable de soutenir les développement, simplifier le déploiement et diminuer les investissement, bref permettant de se concentrer sur la valeur ajouté

on va s'accorder à appeler cette nouvelle offre des plates-formes SaaS, la Plateforme as a Service, sous le sigle PaaS,

Pour les éditeurs de logiciels, une offre PaaS à faible coût initial, offrant des outils de production pré-construit comme éléments de facturation est nécessaire, permettra de réduire les temps de mise sur le marché des logiciels au mode SaaS.

Un projet SOA réussi, facilite le passage vers le mode SaaS

SaaS ne tue pas SOA, pas plus que SOA ne rend SaaS inutile, puisqu'il s'appui sur les mêmes principes : focus sur l'architecture, interopérabilité grâce à l'usage des standards, la nécessité d'une gouvernance à tout les niveaux

ainsi les éditeurs qui auraient négociés l'évolution vers le n-tiers selon une approche SOA, avec un niveau de maturité adéquat, auront beaucoup plus de chance de pérenniser leurs investissement, lorsque l'ère du SaaS s'établira,

Notons, au passage la contradiction dans laquelle se trouve les fournisseurs de matériel traditionnels comme IBM et HP, puisque le phénomène SaaS / PassS, prônent une offre sur demande, pas de plateforme sur site.

Notons au passage que le mode open source, s'intéresse à la notion de PaaS, en témoigne, l'offre WaveMaker, une solution, basée sur java EE, pouvant être classé dans la catégorie PaaS,

Mais ceci est une autre histoire …

SOA : les 5 piliers de la sagesse

IBM a publié récemment un livre blanc résumant les "5 best practices" à respecter pour réussir le déploiement des projets SOA (Service Oriented Achitecture).

Ce livre blanc est d'autant plus important que le Gartner groupe prévoit qu'à partir de cette année (2008), 80% des projets auront une composante (ou bien une coloration) SOA

IBM recommande de se focaliser sur les cinq priorités suivantes:

• Se concentrer sur la définition de l'architecture cible, et développer cette architecture en intégrant une vision claire de l'avenir : ne pas réduire le SOA à une simple affaire de connectivité à déployer en toute urgence.
• Prévoir dès le début le lien entre l'IT et les processus métiers de l'entreprise, afin de réussir la transformation du "département IT" en fournisseur de "service métier".
• Créer une structure organisationnelle pour soutenir l'approche SOA dans tous ses aspects : culture, compétences, formations, structure des équipes, structure organisationnelle, mode de prise de décision, cycle de vie des services, systèmes de rémunération, la collaboration et surtout la Gouvernance.
• S'assurer de la capacité de montée en charge (Scalability) de l’infrastructure – prévoir l'étude systématique des performances de l'infrastructure déployée et fixer une ligne de base pour chaque service.
• Activer la visibilité opérationnelle - se concentrer sur la gouvernance et la gestion des services.

Ainsi, après plusieurs années d'expérience dans la mise en place, la vente d'infrastructure, la vente de technologies, la commercialisation d'outils, IBM distille des recommandations, pleines de bon sens, sans qu'aucune référence technologique n'y apparaisse.

Ce livre blanc, sonne comme une réponse aux détracteurs de l'approche SOA, qui la réduisent à une simple affaire de technologie (et la confondant souvent à des web services) et qui ne cessent de rappeler qu'un grand nombre de projets, assimilés à du SOA, échouent.

De part notre expérience, à OXIA, nous avons pu constater, chez les éditeurs de logiciels et les grands comptes avec qui nous avons implanté l'approche SOA, qu'elle montre, effectivement ses fruits, à partir du moment où les organes du "comité de gouvernance" ont bien fonctionné.

Dans tous ces projets, le "comité de gouvernance" a été dirigé par des Hommes/Femmes métiers ayant un fort pouvoir de décision, et ce indépendamment du niveau de maturité SOA de l'entreprise.

L'élément fondamental dans le SOA, en plus de l'architecture, reste la Gouvernance.

En effet, Il est très dangereux d'oublier, en cours de route, que l'approche SOA est là pour aligner le IT et le métier, et qu'il ne s'agit pas d'une nouvelle affaire d'achat d'une nouvelle "technologie parfaite".