Denis Dollfus' Blog

NoSQL : les SGBDR remis en question

L'adoption naissante du Cloud et surtout le buzz qui l'entoure apportent aux développeurs et architectes de nouvelles idées qui secouent certaines habitudes qu'on croyait aller de soi.

Le composant qui souffre le plus est un de ceux qui semble pourtant le mieux installé dans la durée : la base de données relationnelle. 

A peu près tous les fournisseurs de cloud proposent en effet un service de stockage dans lequel le côté "relationnel" a disparu en même temps que le langage de requête SQL. C'est le cas entre autres de SimpleDB d'Amazon, BigTable de Google et Azure Storage de Microsoft (et non le très relationnel MS SQL Data Service), qui ont en commun de booster la disponibilité et la partitionabilité au dépend de la consistance des données, conformément au théorème de CAP (cf. USI-2009/Le Touilleur Express).

Evidement, constater que tous ces grands du Web convergent vers le même type de solution a de quoi faire réfléchir, surtout quand on sait que ce type de stockage, simple d'emploi et capable de monter en puissance sans explosion des coûts ("scalable", à proposer d'urgence à l'Académie Française), est déjà utilisé avec succès en interne par Amazon et Google.

"Faire réfléchir" c'est peu dire. Avec la création récente de NoSQL, le Cloud semble agir comme un catalyseur suceptible de déclencher un tsunami anti-base de données relationnelle. NoSQL rassemble des acteurs désireux de faire connaitre leurs systèmes de stockage open-source non relationnels, parfois très proche d'un simple dictionnaire constitué de paires clé-valeur. On y trouve CouchDB, Voldemort (j'aime bien le nom), Cassandra, Dynomite, HBase, HyperTable, VPork (joli aussi) et MongoDB. 

Si ces systèmes de gestion des données gagnent du terrain, il faudra sans doute oublier ou en tout cas repenser l'approche centrée sur le modèle relationnel qui caractérise la grande majorité des architectures des applications de gestion de données. Certains mots-clés comme "SGBDR", voire "ORM" et "Hibernate" pourraient devenir aussi datés que le WAP (oouuouuh, tremblez).

Tous les liens vers les solutions de persistance NoSQL sont sur le compte-rendu de la première rencontre NoSQL qui a eu lieu le 12 juin 2009 et a rassemblé 150 personnes à San Francisco :

• Compte-rendu de la rencontre NoSQL : NoSQL Debrief
• ComputerWorld : No to SQL? Anti-database movement gains steam

Le Cloud va-t-il réussir là où les bases de données orientées objets ont échoué ?

 

ALT.NET : Slides de la présentation AOP à voir

Romain a mis en ligne sa présentation sur la programmation orientée aspect en .NET. Je la trouve excellente tant sur le fond que sur la forme, je vous recommande chaudement de la parcourir, vous allez passer un bon moment.

Présentation de Romain Verdier

Sortie de Unity 1.0, le container IoC de Microsoft

La version 1.0 de Unity est disponible sur Codeplex depuis vendredi. Au menu, un projet au code source ouvert aux regards qui permet de construire ses objets par injection des dépendances. Au final, quelque chose d'assez proche de Castle Windsor dans les grandes lignes, mieux documenté que les autres projets du groupe Pattern & Practices de Microsoft.

Les dépendances y sont spécifiées soit par attributs (ce qui entraine une dépendance souvent indésirable entre les classes et le container Unity) soit par fichier de configuration soit encore de façon dynamique dans le code.

Pour fixer les idées, voilà un fichier de config minimal :

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <configSections>

    <section name="unity"

            type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,

                  Microsoft.Practices.Unity.Configuration" />

  </configSections>

  <unity>

    <containers>

      <container>

        <types>

          <type type="UnitySamples.ILogger,UnitySamples"

                mapTo="UnitySamples.ConsoleLogger,UnitySamples"

                lifetime="Singleton"/>

        </types>

      </container>

    </containers>

  </unity>

</configuration>

Et un exemple d'injection plus complexe via le constructeur, un setter et une méthode :

<type type="IMyService" mapTo="MyDataService" name="DataService">

  <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement,

                             Microsoft.Practices.Unity.Configuration">

    <constructor>

      <param name="connectionString" parameterType="string">

        <value value="AdventureWorks"/>

      </param>

      <param name="logger" parameterType="ILogger">

        <dependency />

      </param>

    </constructor>

    <property name="Logger" propertyType="ILogger" />

    <method name="Initialize">

      <param name="connectionString" parameterType="string">

        <value value="contoso"/>

      </param>

      <param name="dataService" parameterType="IMyService">

        <dependency />

      </param>

    </method>

  </typeConfig>

</type>

Certains douteront surement de l'intérêt de sortir un nième container IoC quelques années après les pionniers Spring.Net et Castle (et d'autres... Cf. liens ci-dessous), d'autres argueront qu'à qualités égales, mieux vaut choisir la solution supportée par une grosse structure.

Mais pour juger de la différence de qualité et de fonctionnalité il faut mettre en oeuvre et comparer. Un bon article de Matthew Podwysocki (membre de ALT.NET) amorce la comparaison : http://weblogs.asp.net/podwysocki/archive/2008/02/26/ioc-and-the-unity-application-block-once-again.aspx

Liens :

• Download : http://www.codeplex.com/unity
• Liste de containers IoC/DI : http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

Microsoft aborde enfin l'inversion de control (IoC)

L'IoC proposée par Microsoft à travers les Enterprise Library Blocks (EntLib) présentait  jusqu'à maintenant deux inconvénients majeurs. D'un part l'objet au centre du mécanisme de construction des composants, ObjectBuilder, était insuffisamment documenté, et d'autre part et surtout les dépendances à injecter aux modules étaient spécifiées par des attributs définis dans EntLib (par exemble [ServiceDependency] et [CreateNew]). Un module développé pour l'IoC d'EntLib était donc définitivement lié à celui-ci au lieu d'être "container-agnostic".

Un système IoC qui implique une dépendance entre le module et son conteneur manque l'objectif de couplage faible. Le couplage fort entre modules et conteneur ruine tout espoir de réutilisation des modules hors EntLib. C'était une approche clairement inadaptée à la variété des applications et des socles techniques en entreprise.

Au final, les approches open-source telles que Castle Windsor, Spring.Net et StructuredMap étaient largement supérieures à l'approche ObjectBuilder dès que la réutilisation pesait dans la balance.

La nouveauté c'est que Enterprise Library 4.0 à travers Unity (ex DIAB pour Dependency Inject Application Block) et le framework ASP.NET MVC distribué en tant qu'extensions de .Net 3.5 vont permettre d'assembler des composants sans leur imposer de dépendance un conteneur Microsoft.

Enfin.

ScottGu :

"[ASP.NET MVC] is highly extensible and pluggable.  Everything in the MVC framework is designed so that it can be easily replaced/customized (for example: you can optionally plug-in your own view engine, routing policy, parameter serialization, etc).  It also supports using existing dependency injection and IOC container models (Windsor, Spring.Net, NHibernate, etc)."

Grigori Melnik (Patterns & Practices):
"Once refactored, the EntLib blocks can be used as a la carte with other DI containers – some updating of the façade would be necessary and we invite the EntLib enthusiasts to port the EntLib façade to individual containers. Swapping DI containers means organizations can leverage their existing infrastructure."   

Castle ActiveRecord et les objets "transients"

Pour ceux qui connaissent le projet open-source .Net Castle, ActiveRecord va faire pour sa prochaine version une amélioration intéressante concernant la gestion des objets "transients".

Pour rappel, Castle comprend plusieurs projets, dont :
•    un container IoC (Inversion of Control) , MicroKernel
•    un container plus élaboré qui repose sur le précédent et y ajoute des fonctions de configuration et d'interception
•    un framework MVC pour le Web, MonoRail (qui n'a rien à voir avec Mono)
•    un framework de programmation orienté aspect, Aspect#
•    un framework de persistance, ActiveRecord.

Castle ActiveRecord est une surcouche à NHibernate dont la particularité est de permettre la description du mapping entre classes et database et entre classes directement dans le code sous forme d'attributs.

Une des limitations d'ActiveRecord était de ne pas exposer de moyen de faire des Update sur des objets détachés de la session NHibernate courante, c.-à-d. sur des objets créés hors contexte NHibernate et doté d'un clé primaire valide.

Or ce scenario est commun quand on utilise la classe ObjectDataSource pour le databinding de l'UI : en cas d'update lors d'un postback, le framework .Net crée "dans notre dos", par reflection, une instance de la classe de la source de données, lui assigne toutes ses propriétés (éventuellement modifiées par l'utilisateur via l'UI) et la passe en paramètre de la fonction d'update spécifiée dans la déclaration de l'ObjectDataSource.

On se retrouve donc face à la session nhibernate avec un objet inconnu de la session, peut-être même copie d'un objet présent en session. Appeler Update() sur cet objet lance une exception. NHibernate sait gérer ce cas grâce à la méthode SaveOrUpdateCopy de l'interface ISession (remplacé par merge en v3), pas ActiveRecord qui ne donnait pas d'accès à cette méthode.

Et bien dans la prochaine release de Castle ActiveRecord, l'équivalent fonctionnel de SaveOrUpdateCopy est disponible via la méthode SaveCopy de ActiveRecordBase. Pour l'instant disponible seulement depuis le repository Subversion de castle ou depuis leur serveur de build.

[ActiveRecord or not ActiveRecord ? This is another question…]

Linq to MyEnterpriseServices

Linq apporte une syntaxe structurante pour les développeurs. En entreprise, cacher les appels aux services métier derrière Linq est un facteur de productivité par l'homogénéité apportée par la syntaxe et par l'abstraction de la logique d'appel. Mais comment développer une couche d'interprétation d'une requête Linq dédiée à l'appel d'un service spécifique ?

Fabrice Marguerie, un des auteurs de Linq in Action et fondateur du site ShapToolbox.com, y répond en trois articles et le code source associé en prenant pour exemple de service Amazon Web Service.  Un article didactique qui nous fait comprendre en 10mn quels sont les points importants : implémenter IQueryable et parser l'abre d'expressions généré par Linq.

Derrière cet exemple apparaît l'idée de systématiser cette approche en entreprise. Les architectes mettraient à disposition des dévelopeurs les accès aux services métier (état d'une chaine de production, données de marché, etc.) sous forme de couches "Linq to MyEnterpriseService" en charge de valider les accès et de fournir une API de requêtage identique pour tous les services.

La fin des APIs dédiées, le règne des entités du domaine ?

Liens :

• Partie 1 : http://weblogs.asp.net/fmarguerie/archive/2006/06/26/Introducing-Linq-to-Amazon.aspx
• Partie 2 : http://linqinaction.net/blogs/main/archive/2006/06/28/Linq_to_Amazon_implementation_fore_steps.aspx
• Partie 3 : http://linqinaction.net/blogs/main/archive/2006/09/07/Linq_to_Amazon_source_code.aspx

Simplicité versus design patterns

J'ai récemment eu une discussion assez serrée avec un responsable de développement d'un grand compte de la finance qui soutient qu'il est préférable de se passer des design patterns, facteurs de complication, et qu'il vaut mieux miser sur la simplicité des développements.

On peut effectivement reprocher aux design patterns de conduire parfois à des logiciels surchargés en héritage, interfaces et autres factories. Les design patterns, quand ils ne sont pas nécessaires, ressemblent un peu à des fioritures inutiles ou à des figures de style pompeuses. La lisibilité du système, sa maintenance et son évolution sont alourdies par leur usage intensif et superflu, un peu comme les documents conçus par ceux qui découvrent la diversité des fontes et couleurs disponibles dans Word. Certains en ont d’ailleurs fait un anti-pattern baptisé "pattern oriented architecture".

Mais en y regardant de plus près, ce n’est pas directement les design patterns que ce responsable met en cause, mais leur raison d’être. Il sait que quand les fonctions d'un système s'accumulent et que le nombre de sous-systèmes augmente, l'ensemble, si on n'y prend garde, tend vers une complexité qui nuit au système lui-même. Mais pour lui, le remède consiste à choisir la solution la plus simple à chaque étape de conception et de développement. Implémenter simplement chaque fonctionnalité est une garantie suffisante pour que l’ensemble reste simple. Sans design pattern.

Dans le fond nous sommes d'accord : la simplicité est un objectif pertinent. Mais nous divergeons sur les moyens à mettre en oeuvre pour l'atteindre. Lui pense que mettre simplement un pied devant l'autre est suffisant, alors que je pense que cette image de la marche tranquille vers un système opérationnel est trompeuse. Il est plus réaliste de penser en termes de marais à contourner, de rivières à franchir, de gouffres à survoler… La simplicité n'est pas additive. Le chemin vers un système simple n'est généralement pas linéaire, il demande souvent des sauts qualitatifs (le refactoring) qui modifient profondément la structure du système.

Essayons quand même. Prenons une "simple" interface graphique (GUI) et connectons la à une "simple" base de donnée. Allons-y pas à pas, en ajoutant du code simplement quand on en a besoin, c'est à dire dans les handlers des évènements de la GUI : on obtient un code complexe parce que chaque handler devient un petit logiciel à lui tout seul, qui contient l'accès au SGBD, la logique de traitement et la gestion des éléments graphiques. Maintenir le tout requiert de découvrir et de comprendre ces mini programmes. Le coût de correction de bug et d'ajout de fonction est alourdi. Pour ne rien arranger le nombre ou la taille des mini programmes augmente plus vite que les fonctionnalités. Les interactions entre fonctions garantissent, sauf en cas de simple juxtaposition de fonctions, une combinatoire défavorable à l'approche "un pied devant l'autre". A un moment ou un autre, il nous faudra investir dans un moyen de nous sortir de là… et le plus tôt sera le moins cher.

Donc, autant investir dans le refactoring dès que nécessaire, par exemple en regroupant toutes les fonctions d'accès à la base de données au sien d'un objet dédié qui fait "façade" – on est déjà dans les design patterns…

Autrement dit les design patterns, loin d'apporter la complexité, sont des outils au service de la simplicité. Et, comme tous les outils, on les choisit en fonction du besoin, pas l'inverse ("Tiens, une scie à onglet électrique, c'est pas mal ça, voyons ce que je vais faire avec…").

Les méfaits d’XML (ou gare à la programmation orientée XML)

XML est devenu envahissant. Au lieu de rester à sa place dans des rôles qui lui vont bien (persistance en format lisible, intéropérabilité des systèmes et patois métiers standardisés), XML s’impose de plus en souvent en tant que socle logiciel, technologie autour de laquelle le reste se construit, hélas au détriment de la maintenabilité du système.

D'abord XML s’infiltre facilement côté data, puisque la plupart des SGBD proposent au moins une méthode d’extraction XML. Il est alors tentant, pour aller vite, de se passer de couche(s) d'objets intermédiaires (objets métiers ou conteneurs non typés genre DataSet) pour n’avoir à gérer que des collections de nœuds XML (voire des chaînes de caractères XML) et à les communiquer à la couche de présentation.

Côté interface graphique, XML peut là encore être central, puisqu’une transformation XSLT peut générer HTML et Javascript à la volée. Ajax est la dernière avancée dans cette voie.
XML derrière, XML devant et pas d’objets intermédiaires, le mal est fait :

• D’abord parce que chemin faisant on a perdu quelques années de progrès en design logiciel. Exit la programmation orientée objets, son approche intuitive, ses design patterns et bonnes pratiques, bonjour la programmation orientée XML, pour laquelle tout reste à réinventer.
• Parce qu’ XSLT est l’une des technologies les plus coûteuses (car pénible) à débugger et une des moins adaptée à la monté en complexité.
• Parce que l’intuition du monde « objets » et de la logique procédurale (« s’il pleut alors je sors mon parapluie ») est remplacé en XSLT comme en XPath par une approche déclarative moins immédiate à appréhender (« il ne pleut pas ou je sors mon parapluie »). La productivité des développeurs en prend probablement un coup.
• Enfin parce que l’emploi intensif d’XML aboutit souvent à des performances décevantes. Substituer des objets typés et spécialisés (les objets métiers) par des objets génériques et versatiles (les nœuds XML) se paye forcément en performance. Notamment dès qu’un peu de code est nécessaire, on paiera le prix d’un selectSingleNode sur un nœud XML au lieu de l’appel d’une propriété sur un objet. Le pire c’est ensuite de tenter de gagner en performance en travaillant sur le back-end, généralement pour augmenter la part de logique prise en charge par le SGBD. Dans ce cas d’une part le problème n’est pas réglé – le coût d’XSLT, même diminué, demeure – et d’autre part le coût de la maintenance croît encore puisque aux difficultés de débuggage  XSL s’ajoutent celles du débuggage des procédures stockées.

Evidement cela n'enlève rien au charme d'XML, mais il n'est charmant que s'il est invité. Et c'est encore mieux s'il reste discret.