Blog

Hyper-V (anciennement Viridian) est le nouvel outil de virtualisation de Microsoft. Sa date de sortie est prévue pour le mois d’août 2008, mais une version est actuellement disponible en Release Candidate.

Ce produit marque véritablement l’entrée du géant logiciel dans « la bataille de la virtualisation ». Il vient remplacer un Virtual Server 2005 aux performances en deçà des concurrents que sont VMware et Xen. Son approche est d’ailleurs très similaire à ce dernier, car il n'assure que la gestion des ressources processeurs et mémoire, au contraire d’ESX de VMWare, qui prend en plus la gestion des pilotes.

Cette ressemblance s’explique par la collaboration de Microsoft avec XenSource, société dédiée au développement de l’hyperviseur libre, récemment racheté par Citrix. De cette coopération est née une interopérabilité avec les systèmes Linux équipés de Xen, grâce au format Virtual Hard Disk (VHD), qui définit un standard pour les disques durs des machines virtuelles.

Caractéristiques

Hyper-V se présente sous la forme d’un hyperviseur intégré dans les éditions Standard, Enterprise et Datacenter de Windows Serveur 2008. Il nécessite un processeur 64bits avec prise en charge matérielle de la virtualisation (Intel VT ou AMD-V). Chaque machine virtuelle peut supporter jusqu’à 4 processeurs et 64 GO de mémoire.

Les systèmes d’exploitation actuellement testés et supportés par Microsoft sont les suivants:

• Windows Serveur 2008 ;
• Windows Serveur 2003 SP2 ;
• Windows Vista SP1 ;
• Windows XP SP3 ;
• SUSE Enterprise Linux Server 10 SP1.

D’autres systèmes peuvent fonctionner, comme les versions de Linux intégrant Xen, mais ils ne disposent pas (pour l’instant) du support de l’éditeur.

Les fonctionnalités clés du produit sont :

• Quick migration permet de migrer les machines virtuelles d’une machine hôte vers une autre. C’est la solution équivalente aux VMotion et XenMotion de ses concurrents, mais techniquement moins poussée, car elle ne permet pas de migration à chaud et nécessite donc l’arrêt de la machine virtuelle.
• High Availability (Haute disponibilité) ; cette fonctionnalité est en fait le Host Clustering de Windows Serveur 2008.
• Live Backups permet des sauvegardes des machines virtuelles sous forme de cliché (snapshot) à travers le service Volume Shadow Copy (VSS), présent depuis Windows serveur 2003.

Conclusion et perspectives

Avec Hyper-V, Microsoft se pare d’une réelle solution de virtualisation, dont l’hyperviseur affiche une relative stabilité et de bonnes performances, en dépit de sa version non finalisée. Gageons que la jeunesse du produit, ainsi que ses fonctionnalités légèrement en retrait par rapport à ses concurrents, risquent d’être un frein dans son déploiement, surtout au niveau de la production. Mais il reste une véritable alternative dans le domaine du développement et du test.

Les outils de virtualisation ont aujourd’hui tendance à se rapprocher, tant au niveau des performances, qu’au niveau de l’ensemble de l’offre. La prochaine grande bataille se situe au niveau de l’administration de l’ensemble de ces environnements virtualisés, qui, à n’en pas douter, vont devenir de plus en plus hétérogènes. Le géant de Richmond l’a bien compris et sa future version de System Center Virtual Machine Manager (nom de code « Carmine ») gérera l’administration, la configuration et l’optimisation de système virtuels fonctionnant avec Hyper-V, bien sûr, mais également avec Xen ou encore ESX de VMware.

ADO.NET Data Services (nom de code Astoria) est un framework permettant l’exposition de services d’accès au données accessibles à distance.

Ce type de service permet notamment aux applications riches internet (Silverlight, ASP.NET AJAX Framework) et desktop (Windows Forms) d’accéder à des données sans s’adresser directement à la base de données, ce qui est souvent impossible dans de tels scénarios.

La sortie d’ADO.NET Data Services est prévue pour juin ou juillet 2008.

Principes généraux

ADO.NET Data Services fournit un service générique permettant d’exposer des données issues d’ADO.NET Entity Framework, et éventuellement d’autres sources de données. La description des données exposées sont également décrites par des métadonnées publiées par le service. Le service générique est implémenté en s’appuyant sur WCF (Windows Communication Fondation) qui permet le support de JSON et d’Atom dans .NET 3.5.

On communique avec ce service générique en adressant des requêtes qui permettent de :

• Consulter les entités (filtres, tris …)
• Créer des entités
• Mettre à jour des entités
• Supprimer des entités

Ce service générique est fondé sur une architecture REST :

• Utilisation de HTTP et des verbes standards (POST, GET, PUT, DELETE)
• Utilisation de l’URL et de divers paramètres pour exprimer les requêtes de consultation des entités
• Utilisation des attributs du POST pour les requêtes de création, mise à jour, et suppression d’entités
• Utilisation de JSON (JavaScript Object Notation) ou d’Atom pour la réponse.

Le client du service utilise une API différente selon sa nature :

• Pour les clients Windows Forms et Silverlight 2.0, on peut accéder aux données en utilisant LINQ avec le provider LINQ for HTTP.
• Pour les clients Web ou Silverlight 1.0, il existe également un API client JavaScript qui permet d’accéder aux services ADO.NET Data Services.

Sécurité des données

Il est possible de restreindre l’accès aux entités, selon l’utilisateur, et de gérer les droits en consultation, modification, création et suppression. Il est également possible de filtrer les données, selon l’utilisateur, via un système à base d’intercepteur, très similaire à ce celui de Spring Security (ex Spring Acegi) dans le monde Java.

Le filtrage des données est formulé grâce à LINQ avec une rare élégance. C’est bluffant !

En guise de conclusion

ADO.NET Data Services est une technologie très prometteuse, à surveiller de prêt ! Rendez-vous en juin ou juillet, si tout va bien.

ADO.NET est un framework de mapping objet / relationnel similaire à Hibernate ou TopLink, même si Microsoft s’en défend quelque peu. Sa sortie est prévue pour juin ou juillet 2008.

Modélisation

Dans ADO.NET Entity Framework, l’objectif est de modéliser et manipuler les données non plus sous forme de tables, mais sous forme d’entités.

La modélisation est effectuée selon 3 points de vue distincts :

• le Conceptual model (modèle conceptuel), appelé aussi EDM (Entity Data Model), qui décrit les entités (attributs, et opérations) et les associations,
• le Storage model (modèle physique), qui décrit les tables (colonnes, références) et les procédures stockées,
• le Mapping entre conceptual model et le storage model, qui décrit la correspondance (mapping) entre les tables et les entités.

Chacun de ces 3 points de vue est décrit sous forme d’un document XML (ou d’un fragment XML).

À mon sens, l’existence d’un EDM indépendant du code est un atout du framework.

Génération de code

À partir de l’EDM, il est possible de générer des classes représentant les entités sous forme d’objets. Cette génération produit également une classe qui représente le modèle dans son ensemble, et fournit des ensembles permettant d’interroger les différents types d’entité (entity set). Ces classes sont des classes partielles.

Langages de requêtes

L’EDM peut être interrogé en formulant des requêtes :

• en Entity SQL (eSQL), langage de requête textuel de type SQL
• en LINQ, langage de requête fortement typé (donc vérifié à la compilation) et intégré directement au langage de programmation (C#, VB.NET …).

Fonctionnalités de mapping

Les fonctionnalités de mapping sont riches et assez classiques :

• mapping des champs ,
• mapping des associations,
• mapping de l’héritage,
• mapping des types complexes,
• mapping des opérations sur des procédures stockées.

Suivi des modifications

Les changements effectués sur le modèle doivent être déclarés auprès du cache de tracking associé au modèle.

• Les entités nouvellement créé doivent être déclarées auprès du cache.
• Les entités modifiées doivent, semble-t-il, être déclarées auprès du cache, également.

Une méthode du modèle permet de jouer sur la base de données tous les changements déclarés auprès du cache de tracking.

À mon sens, cette séparation claire du suivi des changements semble être un atout de framework.

Optimisation du chargement des données

Dans une requête, il est possible de déclarer les données à charger en même temps que les entités requêtées. Il s’agit en fait d’entités connectées aux entités requêtées via des associations. Par exemple, si l’on requête des clients, il est possible de dire, par la même occasion, que l'on souhaite ramener les commandes de ces clients.

Pour les connaisseurs, à ce jour, il n’y a pas de 'lazy loading''. À la traversée d’une association, les entités ne sont pas chargées automatiquement à la demande. Lorsqu’on accède à la propriété correspondant à un sens de circulation de l’association, tout se passe comme s’il n’y avait pas d’entités associées. Il n’y a aucune erreur. Pour charger les entités associées, il faut le faire explicitement en appelant une méthode sur la propriété. Il y a également une propriété permettant de savoir si l’association a déjà été chargée.

À surveiller de prêt !

Avec l’arrivée de C# 3.0, les équipes de développement Microsoft nous propose un panel généreux de nouveautés. Toutes ces nouveautés sont dans la lignée de celles proposées dans la version 2.0 (types génériques, itérateurs, méthodes anonymes ou encore Nullable), qui, soyons en certains, n’était qu’une étape. Cette version dévoile enfin les intentions de Microsoft, et tous ces nouveaux concepts ont bien une finalité. Mais ne soyons pas trop empressés, et ne dévoilons pas d’ores et déjà la fin.

Pour mémoire, rappelons que C# a été conçu pour révéler au maximum les problèmes à la compilation, ce qui en fait un langage strict mais sûr.

Propriétés simplifiées

Une première nouveauté permet de déclarer une propriété plus simplement. Ainsi, il n’est plus nécessaire de créer le champ privé, puisqu’il est automatiquement généré par le compilateur. Le fait de définir l’une des méthodes get ou set en privée rend respectivement la propriété writeonly ou readonly.

Initialiseurs d’objets

L’initialiseur d’objets est une forme syntaxique permettant de d’initialiser les propriétés d’un objet en passant par le constructeur par défaut. Elle remplace l’appel à un constructeur surchargé que l’on aurait créé. Ainsi, le compilateur va créer de manière sûre l’objet instancié : la référence vers l’objet ne sera attribuée qu’une fois toutes les propriétés initialisées. Pour cela, le compilateur va créer une variable temporaire, dont le développeur ne connait pas l’existence, et va ensuite assigner la référence vers l’objet créé à la variable définitive, déclarée par le développeur. Cette nouveauté permet notamment de simplifier la construction de collections, dont les éléments sont connus.

Inférence de type

Il est très commun d’associer la déclaration d’une variable à son initialisation. Cette dernière étape permet à elle seule et sans ambigüité de déterminer le type de l’instance ainsi créée. Dans C# 3.0, il n’est donc plus nécessaire de préciser le type d’une variable lors de son initialisation. On emploiera alors le mot clé var, lors de la déclaration, indiquant ainsi au compilateur de déterminer lui-même le type. L’IntelliSense est également capable de faire ce travail, et de proposer naturellement toutes les propriétés et méthodes de l’objet créé. Attention, l’inférence de type ne fonctionne que pour les variables locales, puisqu’il est nécessaire de les instancier à la déclaration.

Types anonymes

Il est courant de devoir consolider des données provenant de plusieurs objets pour permettre un traitement. Au-delà de 4 ou 5 paramètres, les normes imposent de passer par une structure (classe ou struct). Cela oblige donc le développeur à créer des structures complémentaires, sans réel intérêt dans le modèle objet. Pour palier à ce problème, il est désormais possible de créer dynamiquement un type anonyme. Par définition, il ne possède pas de nom et n’a donc pas vocation à être réutilisé. L’inférence de type permet de récupérer une instance de ce type anonyme et le manipuler comme n’importe quelle autre instance de classe. Le compilateur crée automatiquement la classe manquante, simplifiant ainsi le travail du développeur, tandis que l’IntelliSense permet sans difficulté d’accéder aux propriétés de l’objet. En effet, il n’est pas prévu d’associer des méthodes à ce nouveau type. Associé à l’inférence de types et à l’initialiseur d’objet, l’utilisation d’un type anonyme permet d’écrire :

var employee = new {Nom="Guacamole", Prenom="Mathilde"};

Méthodes d’extensions

Comme leur nom l’indique, les méthodes d’extensions permettent d’étendre les fonctionnalités d’une classe. L’héritage n’est, en effet, pas toujours très adapté pour une telle utilisation et est d’avantage conçu pour la spécialisation. Étendre une classe est donc désormais possible en passant par une classe statique, dans laquelle on déclare comme statiques un certain nombre de méthodes d’extensions. Le rapport entre une méthode d’extension et la classe qu’elle étend se situe au niveau du premier paramètre de la méthode. Le paramètre est ainsi précédé du mot clé this et son type correspond à la classe étendue. Il est alors possible d’appeler la méthode d’extension directement sur une instance de la classe étendue, en utilisant le point. L’IntelliSense est également capable de proposer les méthodes d’extension. Notons que les méthodes d’extension peuvent également s’appliquer aux interfaces, et pas seulement aux classes.

Lambdas expressions

En C# 2.0, on connaissait les méthodes anonymes. À peine le temps de les apprivoiser, et voici les lambdas expressions : une simplification syntaxique des méthodes anonymes. Les lambdas expressions vont cependant bien au-delà, puisqu’elles permettent de définir de véritables expressions, comportant des paramètres, et évaluables de manière différée. Les lambda expressions peuvent être compilées directement en IL, ou bien encore faire l’objet d’une transformation, par exemple en SQL.

Plus loin ...

En introduction, nous soulignions à la fois la complémentarité entre les nouveautés du langage de C# 2.0 et de C# 3.0, et le fait qu’elles aient toutes une même finalité cachée. Et après toutes les avoir parcourues, nous pouvons enfin révéler ce secret de polichinelle : il ne s’agit ni plus ni moins que de LINQ ! Ce qu’il faut réellement comprendre, donc, c’est que LINQ est l’aboutissement de toutes ces nouveautés. Sans elles, LINQ n’aurait pas été possible. Au risque de perturber, voire de larguer, une majorité des développeurs, Microsoft et ses équipes de développement ont donc investi énormément sur cette nouvelle fonctionnalité du framework. Voici donc la réponse à ceux qui accusaient Microsoft de tout recopier sur Java ! Microsoft a compris qu’il fallait s’inspirer de ce qui se fait de mieux dans les différents langages pour construire sa plateforme. Enfin, gageons que cet investissement important porte ses fruits, en facilitant l’adoption de la plateforme .NET, et en permettant à cette technologie de séduire de nouveaux clients.

Les moteurs de règles ont traditionnellement un positionnement haut de gamme. De fait, ils sont doublement intimidants : d’abord ils sont plutôt chers, ensuite, pour justifier leur prix, ils sont présentés comme une solution à des besoins complexes, finalement pas si répandus que cela.

D’un point de vue académique, celui de l’intelligence artificielle, le principe des moteurs de règles est simple. On décrit d’une part un ensemble de règles, et d’autre part, un ensemble de faits. En appliquant ces règles sur ces faits, on déduit (‘on infère’ dans le jargon de l’IA) de nouveau faits, et ainsi de suite. L’inférence des faits est assurée par un algorithme classique baptisé Rete ou par l’une de ses nombreuses variantes, plus ou moins brevetées.

Bon, tout cela ne nous dit pas trop ce que nous pouvons en faire pour les applications d’entreprise et le système d’informations. Pour cela, essayons de ne pas mettre la charrue avant les bœufs et revenons aux … besoins.

Classiquement, dans une architecture fonctionnelle, on identifie un certains nombres de règles fonctionnelles durables et relativement faciles à formaliser. Il existe aussi souvent un certains nombre de micro règles, que l’on peine à décrire exhaustivement, et qui ne cessent de changer dans le temps. Ces micro règles correspondent en fait fréquemment à des besoins en flexibilité qui découle de la nature même du métier : adaptation fine des politiques tarifaires, traitement particuliers de certaines catégories de clients, individualisation du service à la clientèle …

Deux dangers nous guettent alors. Le premier danger consiste à exclure les cas particuliers et donc à refuser la flexibilité au métier. Le second consiste à construire une architecture fonctionnelle centrée sur les cas particuliers, rapidement minée par la complexité, et finalement peu flexible.

Il existe diverses approches pour maîtriser le foisonnement des variantes de comportement, dont les moteurs de règles. Malheureusement, leur coût les confine aux cas complexes, alors qu’ils sont déjà intéressant pour les cas plus simples.

Le moteur de règles open source Drools (ou JBoss Rules) se présente dans ces conditions comme une possibilité intéressante. Tout d’abord, il a tous les atours des moteurs de règles établis. Ensuite, il offre deux possibilités dignes d’intérêt. Drools propose ainsi une interface web relativement simple pour décrire des règles. D’autre part, il est possible de définir des règles sous une forme beaucoup plus proche du langage naturel. Dans les deux cas, bien sûr, les règles finissent exprimées dans le langage de définition de règle de Drools. En évitant les discours lénifiants, on peut dire que Drools rapproche ainsi le technique du fonctionnel.

Les moteurs de règles offrent un choix supplémentaire dans la palette de l’architecte. Alors, pourquoi ne pas en profiter ?

Il existe une pléthore de framework web, c'est un fait.

Mais, il faut bien avouer que, pour la plupart, ces frameworks sont finalement très proches, et se contentent de "refaire en mieux", sans véritablement innover, ni offrir d'avancées décisives pour les applications d'entreprise.

JBoss Seam choisit lui une approche innovante avec une forte valeur ajoutée pour les applications d'entreprise ; le tout entièrement en open source. D’un point de vue conceptuel, Seam est l’un des premiers framework à supporter non seulement les architectures sans état, mais aussi les architectures avec état, grâce à la notion de conversation. Cette approche permet la mise en œuvre d’applications web présentant des navigations complexes, et assure une forte séparation des couches quelque soit le niveau de complexité de cette navigation.

Seam intègre de multiples technologies, mais contrairement à d’autre frameworks, il ne cherche pas à encapsuler (donc à brider) ces technologies. Au contraire, il se concentre sur une intégration cohérente et unifiée entre les technologies, ainsi que sur les fonctionnalités supplémentaires à valeur ajoutée. En cela, Seam partage philosophiquement certains points communs avec Spring.

Les technologies intégrées par Seam sont principalement les suivantes :

• le standard JavaServer Faces pour la présentation, et son approche composant,
• JBoss RichFaces avec un ensemble de composants graphiques JSF (supportant AJAX),
• JBoss Ajax4JSF avec un ensemble de composants JSF facilitant le support d’AJAX,
• une extension de JSF pour la description de navigation avec état,
• le standard EJB session stateless d’EJB 3 pour les composants non conversationnels (sans état),
• le standard EJB session stateful d’EJB 3 pour les composants conversationnels (avec état),
• le standard Java Persistence API et les entités d'EJB 3 pour la persistance,
• JBoss Drools pour la sécurité déclarative par règles, et plus généralement les règles fonctionnelles,
• JBoss jBPM pour les processus fonctionnels (business process) et les workflows, mais également pour les navigations complexes dans le site web.

Seam s'appuie majoritairement sur des standards, avec notablement Java EE 5 ou bien encore l’approche POJO (Plain Old Java Objects). Il utilise notamment les mécanismes standard d’extensibilité de Java EE 5 pour intégrer diverses extensions d’origine JBoss. En pratique, cela signifie que Seam n’est pas particulièrement lié à JBoss Application Server et peut fonctionner dans la plupart des serveurs d’application.

En guise de conclusion, remarquons que Seam intègre des technologies JBoss, tels que JBoss Drools et JBoss jBPM, particulièrement bien placées sur leur marché respectif.

log4J est une API de log open source bien connue, d'origine Apache. Son usage est quasi systématique dans les projets : le log est une bonne pratique. Puissante et efficace, cette API n'est pas toujours très facile d'abord. Cet extrait d'un support de TechCoaching™ fait le point sur les concepts de base de log4J.

Google propose un nouveau framework d'injection, baptisé Guice (à prononcer juice), et fondé sur des annotations. Un débat très intéressant, initié suite à un blog de Craig Walls, a lieu entre la communauté Spring (le framework d'injection standard de fait) et les créateurs de Guice.

L'argumentaire de Craig Walls en faveur de Spring est, à mon avis, particulièrement convaincant, et l'essentiel des remarques est tout à fait justifié :

• Spring est bien moins intrusif. Guice oblige a annoter les classes, Spring non.
• L’injection de valeurs simples en Spring est beaucoup plus simple qu’avec Guice.
• Spring peut injecter dans des classes quelconques, pas seulement dans des classes annotées comme Guice. Il est vrai que Guice offre la notion d’adaptateur, mais cela nécessite d’écrire du code.

La JSR 308 : Annotations on Java Types a pour objectif d'étendre le système d'annotation de Java SE 6 pour permettre l'annotation des types en général, et plus seulement des méthodes, champs, et des classes. La spécification en version de travail est déjà dans un état relativement avancé. L'ensemble est cohérent et bien construit. Cependant, on est en droit de se demander si la concurrence accrue entre Java et le futur C# 3.0 n'est pas en train d'engendrer des langages chimériques. C++ ne serait-il pas en train de repasser par la porte de derrière.

JDBC est une API pour le moins rudimentaire. À tel point, qu'il ne serait pas très sage de s'aventurer à développer une application sans avoir quelque peu encapsulé les fonctionnalités de JDBC. Il ne faudrait pas cependant oublier le premier commandement des frameworks : "De framework, tu n'écriras point. Les dieux de l'open source pourvoiront à tes besoins".

Plus sérieusement, iBATIS est un framework JDBC open source d'origine Apache, et qui précisément encapsule JDBC. Alors, sachons profiter de la manne divine, et aussi de cet extrait d'un support de TechCoaching™ Neoxia portant sur le dit iBATIS.

Références

• iBATIS (extrait de support de TechCoaching™)

Les frameworks Web pullulent dans le monde Java. Point trop n'en faut.

La majorité d'entre eux sont des frameworks Web à actions tels que Struts, WebWork, Struts 2 (en fait WebWork), et toute une palanquée d'autres ... Malgré le chemin parcouru depuis le spartiate Struts, les "frameworks" à actions atteignent leurs limites : dans leur grande majorité, il ne propose pas de modèle de composant graphique.

C'est justement l'objectif des frameworks Web à composants, parmi lesquels on peut citer JavaServer Faces (JSF) et Millstone. Ces frameworks se focalisent essentiellement sur les applications Web (à mettre en contraste avec les sites Web) et permettent de construire visuellement (mais également de coder) des interfaces Web par assemblage de composants graphiques. Le concept n'est pas nouveau, et il a clairement prouvé son efficacité en terme de productivité. Il existe depuis longtemps pour les interfaces graphiques classiques, et ne date pas non plus d'hier pour les interfaces Web (voir WebObjects d'Apple). Cette approche a été popularisée par Microsoft avec ASP.NET, qui a su développer autour de lui un véritable écosystème de fournisseur de composants. L'approche composant permet également d'encapsuler AJAX et donc d'offrir une grande interactivité aux composants sans subir le surcroit de complexité classiquement imputable à AJAX.

JSF s'inspire clairement d'ASP.NET, et on ne songerait à s'en plaindre. Il reste cependant plutôt léger en terme de composants graphiques standard. Mais, force est de constater que sa flexibilité et son extensibilité sont étonnantes, en témoigne l'intégration des frameworks Seam et Shale.

JSF est maintenant intégré à Java EE 5. Après un retard à l'allumage, l'offre de composants graphiques JSF semble bien être en train de décoller. On peut citer, entre autres :

• RichFaces d'Exadel en open source chez JBoss
• ADF Faces d'Oracle, récemment passé dans le giron d'Apache

Des outils de développement JSF sont d'ores et déjà disponibles ou en vue tels que :

• NetBeans Visual Web Pack 5.5
• Exadel Studio Pro, qui doit devenir un produit open source, Red Hat Developper Studio
• Eclipse WTP 2.0, un ensemble de plug-in Eclipse dont on attend la partie JSF

JSF n'est peut être pas le framework idéal, mais finalement, il faut bien avouer qu'il fait montre de pas mal de qualités. Et puis, il semble bien que JSF soit bien une technologie en cours d'adoption (en tout cas aux États-unis).

Eclipse est, à n'en point douter, un extraordinaire outil de développement, dont le gros point fort est l'édition du code : refactoring, recherche dans le code, auto-completion ... Mais, de base, Eclipse n'offre pas de fonctionnalités de développement Web, Java EE, XML ou de design d'interface graphique. Bien sûr, ces fonctionnalités sont disponibles séparément sous forme de plug-ins, mais leur installation n'est pas toujours simple. Pour être totalement honnête, l'initiative Callisto livre tous les plug-ins compatibles simultanément, et donc simplifie le processus.

NetBeans, c'est un peu l'opposé. De base, il offre toutes les fonctionnalités Web, Java EE, XML ou de design d'interface graphique. Des plug-ins standard supplémentaires apportent le design visuel JSF, le profiler, le support de Java ME ... En revanche, l'édition de code n'est pas trop son fort, bien qu'il reste un éditeur de code tout à fait correct, mais très notablement moins confortable qu'Eclipse.

Cette situation pourrait bien changer, si l'on en croit NetBeans 6.0 en cours de développement. Ainsi, les progrès de l'éditeur de code de NetBeans sont d'ores et déjà énormes, et à terme, l'élève pourrait bien dépasser le maître. Et que dire du support du support de Java SE 6.0 par NetBeans 5.5 qui apporte un look natif à s'y méprendre.

Et puis d'ailleurs, pour InfoWorld, NetBeans 5.5 est bien une technologie de l'année 2007 dans la catégorie outil de développement.

La concurrence a vraiment du bon ! Et si Eclipse dort un peu sur ses lauriers ces derniers temps, un petit électrochoc ne peut pas lui faire de mal.

Références

• Eclipse 3.2 et Calisto
• NetBeans 5.5
• NetBeans 5.5, outil de développement de l'année 2007 pour InfoWorld
• Milestones de NetBeans 6.0
• Documentation de l'éditeur de code de NetBeans 6.0

MySQL est une base de données open source bien connue, mais qui n'a pas encore tout à fait acquis une complète crédibilité pour les très grosses volumétries de données. MySQL 5.1, en cours de développement, pourrait bien changer la donne. En effet, cette version intégrera le partitionnement, mais aussi la réplication des données dans le cadre d'un cluster.

Voilà des nouveautés qui pourraient bien lever un des obstacles à la mise en oeuvre du partionnement : le coût.

Incidemment, pour le Gartner Group, MySQL devrait être un choix crédible pour les applications critiques d'entreprise à horizon 2008. Nous ne sommes pas loin de penser la même chose.

By 2008, MySQL will be a serious choice for mission critical applications

Références

• Roadmap MySQL
• Ce qui est nouveau dans MySQL 5.1
• Ce qui est envisagé dans MySQL 5.2
• L'avis du Gartner sur les bases de données open source

C'est une forte tendance, les applications d'entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d'utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n'est clairement pas le SOA ou la gestion des données de référence (master data management) qui vont infléchir ces tendances !

Résultat : une pression de plus en plus grande s'exerce sur les systèmes de gestion de bases de données.

Face ce phénomène, la force brute peut suffire :

• plus de Mhz,
• plus de processeurs,
• plus de mémoire ...
• Mais pas toujours à des coûts bien raisonnables !

Mais ce serait compter sans une autre conséquence de la volumétrie des données : l'administration des bases de données volumineuses est exigeante.

Ainsi, on n'administre plus une base de données de plusieurs dizaines (ou même centaines) de millions d'enregistrements comme on administre une base de quelques dizaines de milliers d'enregistrements. Avec de tels volumes de données, des opérations naguère brèves peuvent prendre des heures : modification du schéma ou suppression d'un nombre conséquent d'enregistrement ...

Et là, la forte brute ne suffit plus.

Il existe pourtant des solution à ces problèmes : le partionnement et le clustering. Le partitionnement permet essentiellement de faire face aux volumes de données, que ce soit sur le plan de la performance ou de l'administrabilité. Quant au clustering, il rend possible la scalabilité en nombre de clients.

Mais, force est de constater que nombre de bases de données ont d'ores et déjà plié sous la charge, sans jamais avoir pu bénéficier de l'une, ni de l'autre de ces technologies. Pourquoi donc ?

Plusieurs raisons explique l'apparent désintérêt pour ces solutions.

• Tout d'abord le partitionnement et le clustering sont perçus comme des coûts supplémentaires. En effet, la plupart du temps, ce sont des options payantes, ou alors ils ne sont présents que dans des versions avancées et donc plus chères.

• Ensuite, contrairement à ce que prétendent les éditeurs, ces technologies ne sont pas totalement transparentes. Souvent, le code de l'application, et le schéma de la base doivent être modifiés pour tirer partie du partitionnement. Ainsi, si les volumes de données attendus sont très élevés, le schéma devra idéalement être conçu et testé, dès le départ pour être compatible avec la mise en oeuvre ultérieure du partitionnement.

• Et puis, finalement, ces technologies sont mal connues. Elles inspirent une crainte pas toujours bien justifiée. Il est vrai que les problématiques de clustering ne sont pas très simples, mais le partitionnement quant à lui est tout à fait abordable.

Au final, tout cela nous ramène inexorablement au rôle capital de la base de données dans le système d'information, et aussi au rôle de l'architecte projet et à sa collaboration avec le DBA, mais c'était une autre histoire.

On peut lire ça et là, depuis un certain temps, que la base de données n'aurait aucune espèce d'importance. Il suffirait d'utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux.

Pour le compte de ses clients, nos équipes ont effectué plusieurs dizaines d'audits de performances sur diverses applications en grande difficulté de performance. Et les faits sont sans appel !

Dans une majorité des cas, les causes des mauvaises performances se situent au niveau de la base de données !

Pour compléter le tableau, il fautdrait ajouter à cela les problématiques d'entrées / sorties en général :

• accès aux fichiers,
• invocations de composants distants via le réseau (EJB, services Web, .NET remoting ...),
• envois de requêtes SQL (encore la base de données !).

Malheureusement, l'aspect base de données est trop souvent négligé. Ainsi, il n'est pas rare de trouver en production des bases de données qui n'ont d'autres index que les clés primaires, et dont les performances s'écroulent lamentablement à mesure que la volumétrie croît. Ne sont pas rares non plus, ces applications qui assaillent litéralement la base de donnée sous un flot incessant de requêtes SQL (des rafales de requêtes), pour finalement faire très peu de choses. On pourrait aussi évoquer certaines requêtes SQL qui écrasent à elles-seules la base de données, personne n'ayant pris le temps de vérifier leur plan d'exécution. Que dire aussi du refus idéologique des procédure stockées qui sont pourtant, dans certains cas, le seul moyen d'avoir de bonnes performances ?

Une évidence s'impose : il faut prendre en compte et gérer ces problématiques.

Et les développeurs de dire en choeur : "c'est le DBA qui doit s'en occuper !"
Et le DBA de répondre en solo : "je veux bien les aider, mais il ne viennent me voir que quand tout va mal !"

Finalement, ces problèmes fondamentaux, personne ne s'en occupe vraiment !
Le no-man's-land de la base de données sépare deux territoires : developpeur-land et dba-land !

En fait le problème relève de la responsabilité de tous, à la fois des développeurs, du DBA .... et surtout de l'architecte-projet !

• L'architecte projet élabore le schéma de la base avec le DBA ...
• Il évalue les volumétries ... avec le DBA ...
• Il envisage la mise en oeuvre du clustering ou du partitionnement, si les volumétries sont atypiques ... et avec le DBA ...
• Il veille à éviter les rafales de requêtes en sensibilisant les développeurs ...
• Il éveille les développeurs à l'écriture et à l'optimisation des requêtes SQL ...
• Il suggère des index et décide collégialement ... avec le DBA ...
• Il veille à garder une vision claire du schéma et des ses inévitables évolutions au cours du développement ...
• Il prépare la mise en production de l'application ... avec le DBA ...

Bref, il contribue à faire disparaître le no-man's-land de la base de données, dans l'intérêt du projet !