[AppFabric] Mais c'est quoi au fait?

Depuis un poste récent où je déplorais la présence de l’AppFabric sur Server Core R2, j’e me suis aperçu que très peu de monde connaissait vraiment l’AppFabric et ses bénéfices. Je vais donc tenter ici de combler ces quelques lacunes.

Premier point ; Je vais égratigner quelques légendes urbaines :

L’AppFabric Server n’est pas :

• Une version de BizTalk.
• Une partie d’Azure qui n’existe donc que dans le Cloud.
• Compliquée à mettre en place.
• Destinée qu’à faire fonctionner des workflows.
• Sans intérêt pour les administrateurs du Business Process Management (BPM) .
• Sans intérêt pour les administrateurs système.
• Sans intérêt pour les développeur .net.
• Juste un partage de cache entre serveurs.

L’AppFabirc Server est :

• Un produit Serveur qui se greffe sur IIS (on parle souvent d’extension à IIS). Il facilite grandement la gestion des services contrairement au WAS IIS de base qui n’est pas toujours facile à déployer.
• Un produit dont les fonctionnalités devraient converger avec celles de l’Azure AppFabric; mais qui a encore beaucoup de différences avec celles-ci.
• Facile à installer et à étendre.
• Capable de manager des services WCF, WF.
• Très pratique pour suivre un BPM : on sait où l’on en est et pourquoi, on peut envisager un tracking compréhensible par tous, et donc une meilleure compréhension des implications des changements que l’on fait dans le cadre de son BPM.
• Indispensable à un administrateur qui a besoin d’un monitoring de son système (fonctionne aussi avec SCOM). Il permet aussi d’avoir la main dessus sans tout demander aux développeurs des services (consoles+PowerShell). Il peut même faire le lien entre le BPM et le système.
• En parfaite compatibilité avec .net 4 et il étant même certaines fonctionnalités comme le tracking, la configuration des services. Il facilite même leur configuration et l’uniformisation de celle-ci (en deux clics on peut passer d’une plateforme en mode test (retour de messages d’erreurs complets au client et MetaData pour le découverte de services) à un mode de production normal (sécurité, authentifications… etc).
• Capable de réduire le temps de développement, car les outils de gestion de base existent déjà.
• Parfaitement mangeable et extensible avec des outils développés en interne.
• Capable de fournir un cache entre serveurs, mais aussi de fournir une plateforme de haute disponibilité pour nos services.

Et surtout pour les développeurs, il ne nécessite pas de mettre à la corbeille nos développements existants! On peut reprendre ce que l’on a fait et exposer nos services dans une AppFabric sans que les clients ne voient de différence. Ceci est le plus indéniable.

Personnellement : Outre ces avantages, l’AppFabric m’a permis de mieux faire comprendre à certain développeurs :

• Les notions d’instances des services, appels concurrents, files d’appels, qui ne sont pas toujours faciles à assimiler avec WCF.
• La notion de cycle de vie des workflows.

Comment cela se matérialise-t-il?

L’AppFabirc étendant le comportement de IIS, elle est entièrement mangeable via la console IIS (que l’on ait une ferme très étendue ou un seul serveur). Pour la persistance de la configuration, on reste sur du .net. Ce qui est fait dans l’AppFabric, se reporte donc sur nos fichiers *.config.

Du côté de la persistance, cracking, monitoring, cache… on utilise une ou plusieurs instances SQL. Chaque rôle de l’AppFabric peut être configuré différemment.

Voilà, maintenant il ne reste plus qu’à installer la bête sur votre première ferme