Migrer vers un nouveau serveur d’applications ou vers une nouvelle version majeure d’un même serveur d’application apporte souvent son lot de contrariétés. Avec JBoss AS 7, c’est le cas même si je trouve personnellement beaucoup moins compliqué de faire tourner ses applications web existantes (on verra pour les EJB avec JBoss AS 7.1 plus tard) que lors de migration précédentes. Si vous tentez de déployer brutalement une application WAR basée sur Seam 2, ça ne fonctionnera pas, vous aboutirez à un problème du type

Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.Log

Lorsque l’on tombe sur un problème de ce type, on se dit que les problèmes vont s’enchaîner et qu’on va y passer des heures, no stress voici les étapes à suivre pour s’en sortir très rapidement, prenons l’exemple d’un WAR.

Pré-requis: assurez que votre source de données est bien configurée dans votre instance d’AS7. Niveau JNDI, choisissez java:jboss/ plutôt que java: pour éviter toute surprise.

• Se pose le problème de JSF. AS7 contient JSF 2.0 mais Seam 2 tourne avec JSF 1.2. Pour notifier à AS7 que votre application ne veut pas de JSF 2.0 mais requiert JSF 1.2, créez un fichier jboss-deployment-structure.xml dans META-INF et remplissez-le comme suit:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
 <deployment>
  <exclusions>
   <module name="javax.faces.api&quot; slot=&quot;main">
   <module name="com.sun.jsf-impl&quot; slot=&quot;main">
  </exclusions>
  <dependencies>
   <module name="javax.faces.api" slot="1.2"/>
   <module name="com.sun.jsf-impl" slot="1.2"/>
   <module name="org.apache.commons.logging"/>
   <module name="org.apache.commons.collections"/>
   <module name="org.apache.log4j"/>
   <module name="org.dom4j"/>
  </dependencies>
 </deployment>
</jboss-deployment-structure>

• Vous remarquez de suite que l’on en profite pour régler son sort à commons-loggins ainsi qu’aux autres dépendances qui vous auraient posé problème.
• Hibernate va lui aussi poser problème. Votre application Seam2 est probablement aussi basée sur Hibernate 3.x, hors AS7 est livré avec Hibernate 4. En théorie pas de problème de rétro compatibilité si ce n’est quelques classes qui ont disparues dans la version 4… oui bon ok c’est un problème de rétro compatibilité. Pour y parer, ajoutez simplement les jars suivants dans votre archive. Pour notre webapp, cela se passe dans WEB-INF/lib et vous trouverez les bonnes versions dans votre distribution de Seam 2 ou dans la version de JBoss AS qui la contenait (JBOSS_HOME/seam/lib)
• slf4j-api.jar
• slf4j-log4j12.jar
• hibernate-entitymanager.jar
• hibernate-core.jar
• hibernate-annotations.jar
• hibernate-commons-annotations.jar
• hibernate-validator.jar
• mais aussi gwt-servlet.jar, … selon ce que vous utilisez de Seam 2
• Un dernier soucis lié à AS 7.0.1 subsiste quant à JNDI,
• dans persistence.xml , soyez sûrs de définir jboss.entity.manager.factory.jndi.name dans java:jboss/ et non java: (ceci devrait être corrigé très prochainement)
• dans components.xml , idem pour <persistence:managed-persistence-context/>
• redeployez votre war (s’il est explosé, touch mywar.dodeploy)

Pour toi développeur, technicien, archi avec la tête dans le guidon, ça peut être encore pire, tu peux te voir dé crédibilisé par un autre alors que tu es persuadé qu’il a tord, oui mais voilà, c’est un client, ou un concurrent qui est mieux vu. Le but ici n’est pas d’avoir raison mais bien de faire avancer le projet au mieux.

Que dire du directeur de marché, d’équipe ou responsable RH qui ne peut pas s’y connaître en technique (ce n’est pas son métier) qui va embaucher une personne selon le nombre de mots compliqués ou buzzables qu’il y aura sur son CV et qui, au premier projet livré, devra faire face à une montagne de bugs techniques plus bloquants les uns que les autres et à des réclamations en tout genre. La processus d’embauche mériterait un débat complet tellement il relève d’une problématique complexe: embaucher une personne compétente sur un domaine précis ça peut être très aléatoire. Pour tester un candidat il faut avoir soit même la compétence et/ou le test, le temps, bref ça coûte de l’argent tout ça et c’est une réelle stratégie de l’entreprise, un investissement, voire un risque si on embauche n’importe comment.

Il existe pourtant un moyen simple d’apporter des garantie de crédibilité: les certifications. Attention toutefois, il existe 2 types de certifications. La première s’apparente au code de la route, à savoir un QCM. A vrai dire, il n’y a que très peu d’intérêt à une telle formation, une bonne mémoire, la lecture d’un bouquin ou deux et hop, nous voilà certifiés. La seconde est plutôt semblable à l’examen de conduite, comment le candidat utilise t’il sa connaissance (et surtout son expérience) face à des cas réels ? Ces certifications là valent de l’or, aussi bien pour la personne certifiée que pour la personne qui va l’employer où faire appel à ses services. Pour l’employeur c’est la garantie de ne pas se tromper, pour le certifié c’est une garantie de pouvoir se faire respecter dans ses choix, ses développements, c’est un argument de taille, c’est aussi l’occasion de valoriser son CV et prétendre à un salaire plus élevé.

Chaque année des études sont faites pour lister les certifications les plus remarquables, généralement cela se traduit en % supplémentaire de salaire que l’on peut négocier si l’on a telle ou telle certification. Par exemple: http://www.reseaux-telecoms.net/fichiers/dossierpdf/la-grille-des-remunerations.jpg. Deux paramètres influent sur le résultat: la compétence testée bien sûr mais aussi indéniablement la qualité de l’examen. Etre certifié sur une technologie pointue, rare, très demandée mais via un examen QCM bateau est facile, ne sera pas reconnu et n’apportera rien à personne. Dans le tableau évoqué précédemment vous noterez la présence des certifications Red Hat sur l’OS entreprise RHEL. Depuis plusieurs années, les certifications Red Hat sont reconnues parmi les meilleures, souvent même au top 10 des certifications IT. Pourquoi?

Bien sûr car la compétences est recherchés mais aussi pour la qualité de l’examen lui même. Imaginez que l’on vous teste sur l’installation, le tuning, la réparation d’un système existant, sur des aspects utilisés par toutes les entreprises. Et bien c’est ce que propose Red Hat: que du cas réel, pas de piège. Tout son savoir faire sur la création de certification a été décliné sur les technologies JBoss. D’abord sur le serveur d’application, puis sur JPA, maintenant sur Seam 2, bientôt sur Portal, JPA 2, …

Conclusion, une certification s’est

• pour le certifié,
• valider ses compétences,
• se faire reconnaître pour ses compétences,
• valoriser son CV,
• avoir plus de poids dans les débats et prise de décisions
• pour l’employeur,
• limiter les risques lors d’une embauche,
• valider son investissement dans une formation pour un collaborateur,
• une valeur ajoutée certaine chez le client dans le cadre de prestations, c’est décliner la garantie chez le client

Après un long sommeil, je ne peux m’empêcher d’avoir envie de blogger sur JBoss Application Server 7.

Peut-être êtes-vous sur une autre planète et ne l’avez pas entendu mais cette dernière version du serveur d’application est tout simplement étonnante, bluffante, décoiffante. Habitué depuis des années à travailler sous JBoss AS, je connais sa robustesse, son sérieux mais j’en reconnais aussi sa lourdeur, taille au téléchargement, délai de démarrage, emprunte mémoire. Cette lourdeur m’avait même motivé à exploiter Arquillian, que je recommande toujours chaudement, lors de mes phases de développement.

Lorsqu’une équipe de costauds de la technique décide qu’il est temps, après des années, de revoir l’intégralité d’un serveur d’application, de plonger de trois niveaux dans les couches de bas niveau, d’appliquer des optimisations sur le moindre bloc, d’exploiter de nouvelles normes, techniques, frameworks, d’en créer lorsque l’existant ne donne pas 200% satisfaction et bien lorsqu’une dream team comme celle de l’engineering JBoss se met en marche, ça donne JBoss Application Server 7. Peut-être pensez-vous que j’en fais des montagnes, que je prêche pour ma paroisse, mais il faut le vivre de l’intérieur pour comprendre le travail que cela représente, la passion, que dis-je, la foie en une constellation de compétences au service d’un produit, qui plus est open source, c’est ce que je trouve génial, moi qui suis dans ce domaine depuis 8 ans (là je prends un coup de vieux). Alors, oh toi grand développeur au niveau de geekitude avancée, toi dont on ne distingue plus les doigts lorsque tu libères ton code, toi qui hot-déploies plus vite que ton ombre et qui redémarre ton serveur plus de 10 fois par heure, sache que JBoss a pensé à toi.

Stop au bavardages, voici quelques chiffres, je ne compare pas avec la concurrence, je ne suis pas là pour casser un concurrent juste pour montrer l’écart avec la génération d’AS précédentes. Jusqu’à ce jour j’utilisais EAP 5.1 (comprenez la version ‘product’ de JBoss AS 5). Je compare le profil standalone d’AS7 et le profil default d’AS5.

• Emprunte mémoire: 350M contre 900M
• Démarrage à vide: 1,8 secondes (je ne mens pas) contre 20 secondes
• Démarrage avec la même application web basée sur Seam 2 et Hibernate 3: 7,8 secondes contre 28 secondes
• Taille disque 126M contre 535M
• Une console d’administration, pas trop tôt certains diront, oui ok je suis d’accord.

Certains me diront que la concurrence (tout du moins un AS concurrent très respectable au demeurant) sait faire depuis un petit moment déjà. A ces personnes je dis que l’intérêt ici est de pouvoir utiliser le même serveur d’app en dev et prod car il faut être réaliste, JBoss AS est très largement employé en production, comme en dev d’ailleurs. (attention je n’ai pas dit que le concurrent en question n’était pas utilisé en prod, ne me faites pas dire ce que je n’ai pas dit.)

Evidemment, tout ceci ne fait pas tout, il faudra juger et attendre pour prendre le recul et juger de la robustesse mais je ne m’en fais pas du tout pour ce point. Qui dit nouvelle génération, refonte totale, dit “j’arrive à rien déployer dans ce foutu AS de m….”. Je confirme c’est ce que je me suis dit à ma première tentative de déploiement d’une appli que j’avais créée avec Seam 2 et Hibernate 3. Pour info AS7 fournit Hibernate 4. Un article prochain expliquera comment déployer une telle appli et cerise sur le gâteau l’article devrait être très court car il n’y a pas grand chose à faire au final.

Je te laisse l’essayer, sisi, download, unzip ./standalone.sh , tu en as pour 5 minutes dont 2 secondes pour le démarrer.

Ca se passe là: http://www.jboss.org/as7.html

Vous utilisez Hibernate? oui
Vous utilisez les annotations pour définir vos méta données? oui
Vous ne connaissez pas Hibernate Search? honte à vous!

R.O.I. HB-Search

Il y a des frameworks qui proposent des ROI assez impressionnants, Hibernate Search en fait partie.

Comme vous l’avez probablement deviné Hibernate Search permet d’implémenter un moteur de recherche fulltext efficace. Il s’appuie sur Lucene, Hibernate et les annotations.

Lucene est une technologie java d’indexation et de recherche très mature, aboutie et efficace. L’intérêt d’HB Search réside en son intégration avec Hibernate, il en résulte une facilité de mise en œuvre impressionnante.

Nous sommes régulièrement confronté au problème d’implémentation de moteur recherche dans nos applications d’entreprise. Plusieurs soucis:

• niveau conception : nous sommes très forts pour proposer des formulaires de recherche ciblant toutes les données imaginables de nos modèles, allant parfois implémenter des formulaires de recherche comportant 36 champs. Le problème de ces formulaires étant leur inaccessibilité pour la ménagère de moins de 50 ans –> pour le grand public

• niveau pertinence: nous savons être pertinents et précis sur des numériques, des dates, des booléens mais lorsque l’on nous demandes de prendre en compte les fautes d’orthographes ou les synonymes sur les chaînes de caractères, on se retrouve généralement démunie

Avec HB Search vous pouvez proposer à vos clients, pour un coût moindre, une ouverture vers un moteur fulltext user-friendly (typiquement champ de formulaire unique “à la google”). Ils seront agréablement surpris et n’auront aucun mal à élargir le spectre des spécifications pour consolider ce moteur.

L’exemple

Imaginez une classe Produit avec diverses propriétés de type String comme le libellé et la marque ou libellePrincipal et libelleSecondaire.

Vous souhaitez que la recherche cible ces deux propriétés.

Ci-dessous l’entité annotée comme vous en avez l’habitude:

@Entity
public class Produit {

	@Id
	private int codeProduit;

	private String libellePrincipal;

	private String libelleSecondaire;
 	...
}

Et effectuer une recherche, par exemple, via HQL:

javax.persistence.Query q =
	em.createQuery(
		"select produit " +
		"from Produit produit " +
		"where produit.libellePrincipal = :param");
q.setParameter("param", "café");
List results = q.getResultList();

Méta données

Que faut-il ajouter pour que l’entité et ses 2 champs soient puissent être ciblées par le moteur fulltext?

@Entity
@Indexed
public class Produit {

	@Id
	@DocumentId
	private int codeProduit;

	@Field
	private String libellePrincipal;

	@Field
	private String libelleSecondaire;
	...
}

@org.hibernate.search.annotations.Indexed stipule que l’entité annotée peut être indexée. Grâce à cette annotation, l’intégration Lucene/Hibernate est activée.

Parmi tant d’autres fonctionnalités gérées, l’indexation automatique vous simplifie la vie: lorsque vous agissez sur une entité de ce type, l’index lucene est automatiquement géré.

org.hibernate.search.annotations.Field déclare qu’une propriété est indexée. L’annotation propose divers leviers pour définir comment la propriété est indexée. Pour le moment appliquons le paramétrage par défaut.

Plutôt facile non? Attardons nous maintenant à l’aspect API

API de recherche

Avant de commencer, notez que des APIs équivalentes existent pour la session Hibernate.

Ici, plusieurs étapes sont nécessaires. Il faut d’abord obtenir un EntityManager fulltext, puis créer une requête Lucene. Enfin, la création d’une requête de recherche JPA depuis la requête Lucene nous permettra de retomber sur une API familière et pratique pour manipuler les entités retournées par la recherche.

Voici ce que ça donne:

// expression littérale de la requête Lucene</pre>
String searchQuery = "cafe~";

org.hibernate.search.jpa.FullTextEntityManager fullTextEm =
	Search.getFullTextEntityManager(entityManager);
SearchFactory sf = fullTextEm.getSearchFactory();

// Construction d'un QueryParser, définition du champ par défaut
// récupération de l'analyseur lié à l'entité
org.apache.lucene.queryParser.QueryParser parser = new QueryParser(
	"libellePrincipal",
	sf.getAnalyzer( Produit.class )
);

// construction de la requête lucene
org.apache.lucene.search.Query luceneQuery = parser.parse(searchQuery);

// création de la requête JPA fulltext
org.hibernate.search.jpa.FullTextQuery ftq =
	fullTextEm.createFullTextQuery(luceneQuery, Produit.class);

// exécution de la requête
List results = ftq.getResultList();

La subtilité ici réside en la recherche Lucene «~cafe ». Le tilde active une recherche par approximation. Ce type de recherche permet d’éviter les problèmes d’accent et de typo que l’on rencontre très souvent. De même si les utilisateurs saisissent des fautes d’orthographes, cette recherche s’en sortira facilement.

Bien plus de fonctionnalités

Cette article n’a pas l’ambition de couvrir toute la puissance d’Hibernate Search, simplement de démontrer la facilité et rapidité de mise en œuvre. L’exploitation d’un graph d’objet (et de ses associations) pour la recherche, la pondération de certains champs, la pertinence de la recherche sont possibles et faciles à utiliser.
Bien entendu, d’autres aspects doivent être pris en compte, notamment l’utilisation des analyseurs (approximation, phonétique, synonymes,…) et la gestion / maintenance des index.
Je vous recommande donc la lecture du guide de référence mais surtout du livre d’Emmanuel Bernard et John Griffin.

Teiid

On ne peut être plus clair: les données que vous voulez à partir de celles dont vous disposez.

Teiid vous permet d’agréger plusieurs sources de données en une seule. Imaginez plutôt, vous disposez de 2 bases de données relationnelles, 3 services web et de fichiers plats, vous mettez tout dans le mixeur et à la fin vous ne manipulez plus qu’une seule source de données.

Si l’appli cliente est en Java, vous exploiterez cette source de données via JDBC ou encore mieux via Hibernate ou JPA puisque la dernière release incluse un dialect Hibernate.

Bien entendu, Teiid dispatchera chaque ordre vers les sources de données finales.

La force de Teiid réside, à mon sens en 3 points:

• la maturité, Teiid est en fait fondé sur MetaMatrix
• l’outillage, tout simplement impressionnant
• une liste de fonctionnalités bien plus riche et subtile que le résumé de cet article

Rendez-vous au plus vite le blog et sur les sites Teiid et Teiid designer.

On développait avec JSP, struts et hibernate, le tout en stateless bien sûr, et on était contents, super contents. Grâce à struts, on passait 1h45 heure au lieu de 2 à concevoir notre JSP, la plugger à notre logique de navigation, coder nos validations de surface. Ahhh ce que c’était chia….

Tous ces aspects m’ont vite persuadé de me focaliser sur la persistance, le développement côté serveur, bref TOUT sauf les vues.

Quelques années ont passé, EJB3 est arrivé et j’ai retrouvé les beans session et le stateful et toute sa puissance. C’est Seam, un next generation framework imaginé par Gavin King, qui a d’ailleurs redoré le blason du stateful.

Les annotations nous ont délivrés de l’enfer du XML et struts, après tant de bons et loyaux services, a doucement passé la main à JSF et là… c’est le bonheur surtout avec RichFaces.

J’espère avoir assez de temps libre pour partager des avis/exemples sur toutes ces technologies, EJB3, JPA, Seam, RichFaces mais aussi Hibernate Search qui marquent un pas décisifs dans le monde des applications Java.

Il en va différemment lorsque les auteurs s’exposent eux-mêmes en lançant une information agressive et fausse (aka F.U.D) avec d’autres produits.

C’est ce qu’il s’est passé ici où l’on nous ressort un DataMapper basé sur des patterns anciens voire du millénaire passé comme commenté sur la page:

Honestly, the approach is old. I know that I’ve used similar approach going back to 1999 and it was old back then.

Reprenons depuis le début, le produit présenté n’a rien d’un ORM (Object Relationnal Mapping) dès lors qu’il impose d’énormes limitations au modèle objet, comme la non prise en charge de l’héritage et surtout qu’il ne propose pas de mapping… ben oui forcément. Ici il s’agit en fait d’imposer, via un framework, une organisation/une structuration du code dans des classes stéréotypées. L’idée est louable, toujours meilleures que d’avoir du JDBC pur non organisé et explosé partout dans un projet.

Cependant, c’est assez préhistorique et très franchement pénalisant sur beaucoup de points, lisons entre les lignes :

No lazy loading. Just eager loading because you can expect whatever you want during coding. Eager loading removes n + 1 queries.

Mouais, c’est un peu beaucoup n’importe quoi. Le lazy loading peut effectivement entraîner un soucis de n + 1 requêtes mais uniquement si le développeur est un lazy développeur (= développeur fainéant). Avec un ORM et hibernate en particulier, tout est fait pour pouvoir optimiser les modes de récupération de graphe d’objets. En passant “just eager loading” tend à forcer le chargement entier des graphes d’objets. Ceci est purement unitle et simplement consommateur de ressources. D’où l’existence d’une fonctionnalité comme le lazy loading qui permet de charger uniquement la portion de graphe nécessaire à un cas d’utilisation. Le lazy loading bouchonne le reste du graphe avec des proxies qui permettront eux-même le chargement transparent du reste du graphe en cas de nécessité, comprende? … la boucle est bouclée

an entity object which extends POJO

Comme le dirait un de mes bons amis:  “namuf ?” (= quoi?, kékidi? ou encore C’est une blague?). Pour faire court, simple et pour ceux qui n’ont pas tilté, un POJO est un objet pur, qui ne dépend d’aucun framework, encore moins technique. Un POJO est libre et peut être exploité par un client sans que l’on ait besoin de déployer une quelconque armada de jars de frameworks techniques au risque de se prendre une ClassNotFoundException.

Notre ami nous explique donc que les classes persistantes utilisées avec son framework doivent étendre une classe technique, présente dans son framework, classe qui se nomme très intelligemment POJO. C’est fantastique! Forcément et probablement sans même savoir pourquoi, il a du compléter son framework de convertisseurs:

built-in converter that can be used to convert a Java Object into a frontend String or a frontend String into a backend Java Object. The converter prevents data conversion from scattering different pages and layers.

Beh oui, les objets n’étant pas des POJOS, ils deviennent difficilement manipulables d’une couche à l’autre. Il faut passer par le bon vieux DTO, à savoir un POJO destiné essentiellement à des fins de manipulation de données. Et pour automatiser la transposition d’un “truc” (désolé ses trucs ne sont pas des POJOS pour moi) vers un DTO, que faut-il? Des convertisseurs, bravo. Il va forcément falloir gérer ces conversions de manière systématique, typiquement entre la couche service et la couche web.

Ces traitements sont coûteux en terme de développement et de maintenance, complètement inutile car ne contenant aucune plu value métier et forcément c’est vraiment contre productif. Mais non puisque notre ami nous affirme gratuitement:

High productivity compared to Hibernate.

Sans exagérer 70% de ce que dit l’auteur est faux et je vais arréter là, … euh, … aller une dernière pour la route, lisez attentivement le titre est les premiers mots du commentaire ici (écrit par l’auteur du framework lui-même. ):

No limitation

suivi de

There are no polymorphic queries

Comme c’est beau, il m’a convaincu!

Tout ceci ne veut pas dire que le framework est inutile ou mauvais, il ne répond simplement pas à un outil du spectre d’un ORM. En le aisant délibérement, l’auteur s’est tiré une balle dans le pied.

J’ai connu et connais encore plusieurs décideurs qui se laissent berner par ce type d’argumentation. Résultat: des applications qui utilisent des technos d’un autre millénaire (ce qui n’est pas grave) mais qui passent aussi à côté de technos pouvant résuire sensiblement les coûts de développement, de maintenance et d’évolution. Prenez une application de 50 tables avec 1000 requêtes SQL codées en dure, forcément pas le choix avec un DataMapper, il faut en coder une par cas d’utilisation. Ajoutez une colonne par ci par là lors d’une évolution, vous m’en direz des nouvelles…

Apprenez à lire entre les lignes et si vous êtes décideur sans être expert sur un sujet en particulier, déléguez à un de vos petits gars passionnés. Il vous fera gagner beaucoup d’argent à terme, croyez-moi. De même, méfiez-vous toujours des software marabous qui vous vendent une bidouille propriétaire  sortie du chapeau et qui vous certifie qu’elle est bien meilleure que les frameworks les plus robustes, matures et éprouvés.

Cette phrase amplement utilisée pour signifier que deux sujets ne peuvent être comparés entre eux est-elle réellement pertinente? Pour ma part, les affirmations absolues n’ont pas leur place dans ce monde, tout est question de contexte. Il est ainsi intéressant de comparer des pommes avec des oranges dans différents contextes comme la nutrition ou le goût.

Il y a quelques semaines, j’ai vérifié et corrigé une application destinée à comparer des outils de persistance d’objets java. Il y avait trois produits: un ORM mystérieux couplé à une BDD relationnelle et 2 Bases Objet.

Cette expérience fût l’objet de longs débats plus sémantiques et méthodologiques que techniques entre l’étudiant (préparant son doctorat) et moi-même qui devais valider son code et ses mappings. Au delà des résultats des tests, ce qui m’intéressait était de permettre à l’étudiant de prendre du recul et si cela ressortait dans sa dissertation alors mon objectif serait atteint. Pour lui faire entendre raison il m’a fallu ruser et utiliser une autre comparaison, place aux engins motorisés.

S’il fallait comparer une moto, une formule 1 et un 4×4, beaucoup de questions me viendraient à l’esprit, et malheureusement l’étudiant en question a foncé tête baissée dans le code sans se les poser:

Qui pilote les engins?

• une personne sans permis

• une personne avec une expérience significative pour chacun des véhicules

L’expérience semble nécessaire, malheureusement l’étudiant n’avait pas de réelle expérience pratique et, oh mon dieu!, n’a fait que survoler les guides de référence. Résultats: des erreurs graves un peu partout. Après une première passe sur ces erreurs grossières, les performances étaient déjà 2 à 3 fois meilleures.

Où tester les véhicules ?

• sur un terrain neutre, très difficile à définir ?
• sur un circuit ?

Tout dépend de l’objectif du test et de l’utilisation attendue par les destinataires du test. Admettons dans notre cas un test sur piste pour tester la vitesse pure des engins, en ligne droite, courbe, blah blah. Ici, le modèle Java utilisé avait du sens, tous les types d’associations étaient présents, ainsi que l’héritage. Petite chose irritante cependant, au lieu de se pencher sur un listing des fonctionnalités de chaque outil, le test cible les performances dans des cas d’utilisation de type batch. Les connaisseurs comprendront de suite le soucis: on ne choisit pas ce type d’outil pour faire des insertions/extractions massives de données mais bien pour permettre de concevoir une application qui nécessite une modélisation orientée objet.

Autorisation de prendre des raccourcis ?

• Seul le 4×4 est capable de couper à travers champ pour le test
• Alors que la formule 1 n’y survivrait pas.

Dans ce cas il semble nécessaire d’expliquer que le 4×4 dispose d’un avantage certains, non négligeable sur ces concurrents.

Si tous les véhicules peuvent prendre le raccourcis, la question se pose aussi, tout dépend de l’exhaustivité et de la lisibilité souhaitées. Ainsi un des deux fournisseurs de base objet a essayé de forcer l’étudiant à configurer son architecture autour du mode « stockage in-memory ». Oui mais voilà, des BDD relationnelles in-memory existent aussi, permettant des performances virtuellement explosives. L’étudiant a fait preuve d’impartialité et n’a pas accepté cette requête.

Quels pneus utiliser ?

Certainement l’aspect pouvant impacter le plus les résultats. Utiliser des pneus en mousse pour la formule 1 invaliderait l’ensemble des tests. De nombreux points techniques relevant de ce domaine ont du être rectifiés dans le code. Dans le cas ORM + BDD relationnelle, ce n’est pas l’ORM qui est testé, c’est bien l’ensemble. Il semble donc intéressant de comparer les résultats avec 2 BDD relationnelles différentes.

Épilogue: après différentes corrections et optimisations de bon sens (pas de triche genre cache de second niveau expressément tunné pour les cas d’utilisation), tous les tests (une 15ene) tournent entre 4 fois et 40 (oui 40!!!) fois plus vite.

Conclusion: même si la solution ORM/BDD relationnelle s’en sort une fois de plus grandie, je persiste à penser que, comme la quasi totalité des comparatifs axés uniquement sur la performance, ce test est un nième benchmark peu utile. Posez-vous toujours et en priorité la question de votre contexte d’applications d’entreprise. Pensez d’abord fonctionnalités, pérennité et réputation des produits. Si un produit est réputé et massivement utilisé, c’est déjà un gage de sécurité.