Architecture logicielle de la haute disponibilité

dialoguer avec de nombreuses applications. Il convient donc dès la conception, de prendre en compte la disponibilité (et donc la possibilité de non disponibilité) des applications interagissant avec BizTalk.

L’application doit être conçue pour être un maximum de tolérance aux pannes des applications avec lesquelles elle dialogue tout en s’appuyant sur les mécanismes standards de BizTalk. En effet, BizTalk fournit en standard plusieurs fonctionnalités utiles pour gérer l’indisponibilité temporaire d’une application :

• Les ports de sorties permettent un paramétrage.
• De la stratégie de réessai d’envoi.
• De la plage horaire de fonctionnement.
• D’un protocole de communication alternatif.
• BizTalk permet d’implémenter des processus asynchrones à l’aide des orchestrations.

Ce deuxième point est souvent négligé et permet pourtant de découpler les différentes interactions entre les applications et donc de limiter l’impact d’une indisponibilité temporaire de l’une d’elle.
Ceci peut être illustré par l’exemple suivant :

Un site de commerce électronique appelle un Web Service BizTalk pour chaque commande. BizTalk a la charge de réserver le stock correspondant et de transmettre la commande au système informatique de l’administration des ventes.

 Une implémentation synchrone de ce scénario ressemblerait à la figure 5 et impliquerait une haute disponibilité au niveau de la gestion des stocks et de l’administration des ventes. L’implémentation asynchrone, peut elle s’appuyer sur les services de BizTalk pour gérer l’indisponibilité de l’une ou l’autre des applications mobiles.

Cet exemple est certes très simpliste mais fait apparaître le besoin de ne pas induire inutilement des dépendances en termes de haute disponibilité. Dans tous les cas, il conviendra de valider la solution par des tests afin de vérifier son bon comportement lors d’une défaillance d’une des applications.