WebSphere ESB repose sur WebSphere Application Server et prend donc en charge un modèle transactionnel régissant les transactions commerciales.
WebSphere ESB repose sur ce modèle transactionnel, qui permet des applications SOA (architecture orientée services) et BPM (gestion des processus métier) à configuration dispersée.
Techniquement, cela signifie deux choses :
Les transactions sont conformes aux propriétés ACID. Les transactions sont considérées conformes à ACID lorsqu'elles intègrent l'atomicité, la cohérence, l'isolement et la durabilité.
WebSphere ESB utilise des systèmes de bases de données et de messagerie pour obtenir un modèle "à configuration dispersée". WebSphere ESB met à jour une base de données et envoie un message. La mise à jour de la base de données et le message sont validés dans la même transaction.
Une autre caractéristique d'un modèle "à configuration dispersée" est qu'il extrait un message d'une messagerie et met à jour les bases de données. Si un incident se produit pendant ce traitement, l'événement revient à la file d'attente de messages comme s'il n'avait pas été lu. WebSphere ESB comporte un mécanisme de relance, avec lequel, après 5 essais, l'événement est transmis au gestionnaire d'événements ayant échoué. L'expression "à configuration dispersée" renvoie au fait que tout le travail n'a pas à être effectué au cours d'une transaction globale.
Avec la bonne optimisation et une configuration appropriée des gestionnaires de ressources disponibles, aucune donnée n'est perdue en cas de défaillance d'un partie donnée du système. L'intégrité transactionnelle, comprenant des mécanismes d'annulation et de récupération, est l'élément clé de WebSphere qui garantit que les données ne seront pas perdues si des défaillances surviennent.
Pour que les mécanismes WebSphere d'annulation et de récupération fonctionnent, il vous faut paramétrer correctement les gestionnaires de ressources (bases de données et messagerie). Par exemple, l'expiration des verrouillages de bases de données doit être définie correctement, afin que, lorsque le serveur récupère, il puisse accomplir une annulation ou une validation sans rencontrer des conditions de verrouillage.
WebSphere ESB ajoute des fonctionnalités complémentaires enrichissant celles de WebSphere Application Server, afin d'offrir une solution complète de récupération de données après un échec inattendu.
Le modèle central de récupération de WebSphere ESB est basé sur les unités de travail. Le système peut traiter et récupérer des incidents qui se produisent au cours d'opérations du système focalisées sur la réalisation d'une seule unité de travail, offrant ainsi un service ininterrompu. Ce type de récupération survient au travers d'une série de mécanismes de relance et de mise en file d'attente des erreurs. La conception de votre application doit prévoir la capacité de distinguer entre erreurs du système et erreurs de l'application. Les erreurs système sont renvoyées à l'infrastructure qui prend en charge le composant appelant, où une récupération supplémentaire de niveau système peut être tentée ou l'erreur se voir transformée en une exception métier plus générique. Vous pouvez configurer divers mécanismes de reprise pour qu'ils s'exécutent automatiquement. En outre, WebSphere ESB fournit un ensemble de consoles et d'interfaces de programmation correspondantes pour permettre une intervention plus manuelle s'il y a lieu. Nombre de ces fonctionnalités et des défaillances qu'elles traitent peuvent être exploitées tandis que le serveur contenant le travail poursuit le traitement des nouvelles requêtes.
Serveur non disponible - description générale
Cette opération est effectuée à l'aide des fonctions sous-jacentes de gestion de la charge de travail de WebSphere Application Server, qui peuvent varier en fonction du protocole, de la topologie et de la configuration.
Alors que le système dans son ensemble reste actif et disponible, l'administrateur peut effectuer des opérations de récupération.
Les actions de l'administrateur visent à effectuer un triage de base et à redémarrer le serveur défaillant. Ce redémarrage réexécute les journaux de transactions et doit régler la plupart des situations de serveurs en panne.
L'utilisation des mécanismes de traitement d'erreurs offerts par WebSphere ESB est parfois requise pour administrer une récupération intégrale.
Cluster non disponible - description générale
Si la totalité d'un cluster de serveurs devient indisponible ou ne répond plus, une série d'opérations de récupération plus complexes sont nécessaires. Par exemple, si une ressource partagée telle qu'une base de données devient indisponible, tous les serveurs du cluster ont la même difficulté à mener à bien le travail.
Les procédures de récupération des ressources partagées dépendent de la ressource partagée ayant subi une défaillance. Vous pouvez appliquer diverses techniques WebSphere pour réduire à son minimum le temps d'indisponibilité global et redémarrer le travail au point mort.
Incident catastrophique - description générale
Dans les situations de sinistre, des machines entières peuvent devenir indisponibles ou des serveurs sembler irrécupérables. Dans de tels cas, vous pourrez vous reposer sur les fonctions avancées de WebSphere pour que la récupération de l'un des serveurs ayant connu un incident puisse s'accomplir sur un autre serveur du même cluster. Grâce à cette fonction et à la condition préalable de disposer d'un stockage réseau ou de tout autre mécanisme de partage des journaux, ce type de récupération est également envisageable. Pour plus d'informations sur la récupération d'un serveur ayant échoué par un autre membre du même cluster, voir Reprise homologue.