public Blog<Benwit> monblog;

Un article de benwit    Commentaires fermés

Je ne vais pas vous parler de ma dépendance à GAE (Je m’arrête quand je veux !) mais de la dépendance d’une application Java à cette offre de Cloud Computing.

Je vous propose de vous montrer ce qui peut vous rendre dépendant et je vous suggère des pistes pour éviter ou minimiser ces dépendances. D’ailleurs, certains conseils sont valables en dehors de GAE et même en dehors de Java …

=> La dépendance, c’est quoi ?

Puisqu’il peut y avoir des points de vues différents, entendons nous d’abord sur ce que j’appelle dépendance.

• Prenons n’importe quelle application web Java existante, peut-on la porter sur GAE sans aucune modifications ?
  Répondre par l’affirmative signifierait qu’on a une application complètement indépendante.
  Malheureusement, ce n’est pas le cas puisque GAE n’implémente qu’une « partie » de Java.
  Le point positif dans l’histoire, c’est que si vous ne pouvez pas déployer votre application dans GAE, le problème de la dépendance à Google ne se pose plus vraiment.

• Prenons une application web Java existante potentiellement compatible GAE (qui n’utilise pas du code incompatible ou du code qui pourrait être remplacé). Peut être aurez vous à faire quelques adaptations mais si votre application est assez modulaire, cela devrait pouvoir se faire sans trop de problèmes.
  Là encore, la dépendance à Google ne devrait plus se poser car si vous avez réussi à rendre une application compatible GAE, vous pourrez quand vous voudrez prendre le chemin inverse, n’est-ce pas ?

• Il reste donc un dernier cas, le développement d’une nouvelle application destinée à être déployée sous GAE. C’est bien là que réside le risque de dépendance, c’est à dire de vous lier tellement à cet environnement que vous ne pourriez plus en sortir (sans mal).

=> Qu’est ce qui peut vous rendre dépendant et comment l’éviter ou le minimiser ?

• Faut-il utiliser les services de GAE ?.
  Les services de GAE, c’est justement fait pour nous rendre service alors c’est très tentant …
  Une solution pourraît consisté à dire qu’il faut les éviter à tout prix mais c’est une attitude un peu extrémiste quand même. Il serait dommage de ne pas s’en servir au nom de la sacrosainte compatibilité. Et en plus, il n’est même pas dit que dans certains cas, vous pussiez vous en passer ?
  Je pense qu’il faut être pragmatique, mettre le service sur la balance et peser le pour et le contre un peu comme je l’ai fait pour le « UserService » dans mon billet sur l’authentification Google

• Comment éviter un couplage fort avec un service de GAE ?
  Le couplage fort pointe le bout de son nez dès que vous allez utiliser directement les API GAE du service en question dans le code de votre application métier. Il faut éviter que votre code soit trop lier à leur code. Ceci est un problème général et n’est pas spécifique à GAE, il revient à chaque fois que vous utilisez une librairie tierce. Par chance, qui dit problème général dit solution générale : Le découplage, l’injection de dépendance, …
  Mais concrètement, comment fait-on ? Je peux seulement vous dire comment je fais et c’est à vous, esprit libre, de faire ce qui vous convient …
  Voici quelques principes tirés de mon expérience :
  1. Etre libre, c’est choisir ses propres chaînes :
     Pour ne pas tomber dans l’extrême inverse, il faut choisir les librairies dont vous acceptez de dépendre : Celles du JRE, celles des spécifications des standards (JDO, JPA, Servlet, …) et les vôtres (bien entendu) semblent un bon début.

  2. Ne mélangez pas les torchons et les serviettes :
     Séparez le code spécifique (le code métier, celui de votre application) du code générique (le code transversal, réutilisable entre diverses applications). Pour cela, créez différents projets (un par application, un par librairie indépendante).
     Ne tombez pas dans l’excès inverse de vouloir tout prévoir d’entrée de jeu, vous ne pouvez pas !!!
     Et même si vous êtes très fort, dites vous bien que vous deviendrez encore plus fort … ;o)
     Vous faites du Java, alors utilisez la puissance du refactoring pour retravailler votre code dès que le besoin s’en fera sentir.

  3. LA solution : Des solutions :
     Face à un besoin, il y a souvent plusieurs solutions. Lorsque vous imaginez plusieurs implémentations possibles, essayez donc de monter l’échelle de l’abstraction … Créez des interfaces, des squelettes d’implémentation, … Et coder une ou plusieurs implémentations concrètes. Si une implémentation particulière dépend de librairies tierces, créez un nouveau projet de librairie. Comme ça, si cette implémentation n’est pas utilisée dans un de vos projets d’application, vous ne serez pas obliger de traîner la ribambelles de librairies liées.

  Si on reprend l’exemple de l’authentification Google. Si vous voulez limiter la dépendance, n’appeler pas directement leur service dans votre application.
  Créez par exemple votre service d’authentification qui sera utilisé par vos applications et écrivez dans des librairies séparées différentes implémentations possibles (DB, LDAP, CAS, GAE, …). L’utilisation d’une implémentation concrète créera au pire un unique point de couplage dans le code (à la construction), et au mieux aucun dans le code si vous utilisez l’injection de dépendance (par un simple fichier de propriété avec le nom de la classe concrète ou par la génération initiale du graphe d’objets de votre application avec Spring)

• Suis-je lié à Google avec mes données ?
  Pour l’accès au datastore, si vous pensez utiliser l’API de bas niveau, encapsulez là comme n’importe quelle autre API Google dans une implémentation spécifique d’un de vos services.
  Sinon, comme GAE propose les standards JDO/JPA, ne vous en privez pas, vous ne créerez pas de dépendance de ce côté là (mise à part les quelques différences qu’on observe en pratique entre les diverses implémentations de ces standards)
  Le point noir actuel concerne les données à proprement parler et c’est ce point qui vous fera peut être réfléchir …
  Pour ne pas être lier à Google si vous voulez sortir votre application de GAE, il faut que vous pussiez exportez vos données. Et pour l’instant, à moins de le coder soi même, il n’y a rien de prévu.
  De plus, comme le datastore de GAE repose sur une architecture spécifique à Google (BigTable), tout traitement d’export de vos entités devra s’accompagner d’un traitement d’import pour les réintégrer dans le nouveau système.
  Si je développai aujourd’hui une application GAE, je prévoirai sans plus attendre un mécanisme d’import/export de mes données.

=> Bonus : La dépendance cachée ?!

Tout au long de ce billet, il était question de conseils pour éviter d’être trop dépendant de Google si l’envie nous prenait de faire fonctionner votre application en dehors de GAE.

Ironie de l’histoire, j’ai été confronté à une dépendance à l’implémentation GAE des Sessions HTTP mais c’est une autre histoire …