Tout d'abord commençons par préciser que Windows Server AppFabric est le regroupement de deux projets Microsoft "Velocity" et "Dublin" qui sont devenus respectivement Caching Services et Hosting Services.
Hosting Services est dédié à améliorer le support pour l'hébergement de services WCF, en particulier ceux utilisant Workflow Fondation. Bien qu'intéressant ce module ne nous intéressera pas pour cet article.
En revanche Caching Services est la solution Microsoft pour répondre aux besoins d'infrastructure pour la mise en place de cache distribuée. Malheureusement vous l'aurez sans doute deviné mais cette solution n'est prévue que pour fonctionner avec les autres produits Microsoft, amis javaïstes et phpïstes passez votre chemin...

Cluster de cache Kézako ?

Un cluster est une entité logique du réseau regroupant plusieurs machines faisant le même travail. L'idée est que les applicatifs ne connaissent que la tête du cluster, cette dernière se chargeant de rediriger la demande sur la machine la plus appropriée et renvoyer l'information. L'avantage est que l'on peut ajouter ou retirer des machines au cluster tout en restant transparent pour les applicatifs consommateurs.

C'est la même idée qu'un répartiteur de charge pour les serveurs web sauf qu'ici il s'agit de renvoyer des informations en cache plutôt que des pages web. La fonction première de Caching Services est donc de pouvoir mettre en place ce cluster de cache mais pas que !

Et je peux faire quoi d'autre avec mon cache ?

Outre l'architecture physique au travers du cluster, Caching Services vous permet également d'avoir une segmentation logique de votre cache sur deux niveaux.
Le premier niveau regroupe les caches nommés, configurés lors de la création du cluster. Si vous gérez une ferme de cache dont vous proposez les services à des clients différents, c'est une bonne idée de créer un cache nommé par client afin que chacun reste séparé des autres.
Le second niveau regroupe les régions au sein d'un cache nommé. Cette fois c'est l'applicatif qui a la charge de les créer ce qui lui permet d'avoir son propre découpage logique, particulièrement pratique pour pouvoir faire expirer en même temps les éléments d'un même groupe. A noter que ce second niveau est facultatif.

Il est également possible d'ajouter une ou plusieurs étiquettes à un objet mis en cache afin de pouvoir faire des recherches d'objets par étiquette via les API de Caching Services. L'inconvénient est qu'il faut placer l'objet à l'intérieur d'une région pour pouvoir lui adjoindre des étiquettes.

Outre les fonctionnalités d'ajout, récupération et retrait d'un objet en cache via une clé ainsi qu'une expiration absolue (mais pas glissante), Caching Services propose un ensemble de notifications assez complet auquel peut s'abonner une application le cache. Le système de dépendance introduit par "HTTP Cache" peut ici être reproduit par les régions, à ceci prêt que c'est à l'application de déterminer quand faire expirer tous les objets d'une région et non en scrutant si un fichier a été modifié.

Les API de Caching Services propose également des solutions pour gérer des mécanismes de verrouillage optimistes et pessimistes des objets mis en cache.

Enfin les applicatifs consommateurs peuvent également activer un cache client qui stocke localement les objets venant du cluster et ce de manière transparente... ou presque car un objet en cache local est du coup coupé de sa version sur le cluster qui peut éventuellement être amenée à être modifié.

Le "mais"

Parce que évidemment il y a un "mais".

Ici le problème n'est pas vraiment Caching Services qui remplit son rôle de mettre en place le cluster et proposer de nombreuses API et fonctionnalités pour interroger le cache. Non le problème est que AppFabric arrive bien tardivement dans un écosystème de sites web utilisant massivement "HTTP Cache" qui était de toute façon la seulement façon de faire jusqu'à présent.

Cela ne serait pas problématique si AppFabric pouvait remplacer silencieusement HTTP Cache sans pour autant modifier le code mais ce n'est pas le cas. Utiliser AppFabric requiert d'utiliser un jeu d'objets et de méthodes complètement différents de ce que l'on utilisait jusqu'à présent.

Pire encore, avec le Framework .NET 4.0 une classe abstraite ObjetCache est apparue avec une implémentation, MemoryCache, avec pour objectif de servir de base pour toute les formes d'implémentation de cache sauf que outre le fait de ne pas supporter non plus "HTTP Cache", AppFabric non plus ne part pas de cette base pour son implémentation, un comble !

Néanmoins

Si jusqu'à présent vous n'utilisiez que Output Cache ou la session alors vous êtes plutôt chanceux car pour le coup AppFabric vient avec un provider pour chacun des deux modules ce qui fait que cette fois l'utilisation d'AppFabric est vraiment transparente sur ces fonctionnalités là tout en amenant des avantages comme la conservation des sessions en cas de recyclage des données ou bien la mutualisation des rendus entre les serveurs web.

En outre la sécurité n'a pas été oubliée avec la possibilité de restreindre l'accès au cache qu'à certains comptes utilisateurs (i.e. l'identité du pool d'application de votre site web). De plus les données échangées peuvent être signées et/ou cryptées (les deux par défaut).

En outre si vos serveurs ont l'option "haute-disponibilité", les données en cache se répliqueront sur les différents serveurs afin de minimiser le risque d'indisponibilité des données en cas de défaillance d'un des serveurs du cluster.