Lors du développement de modules, vous êtes amené à identifier des services exploités par plusieurs modules. Cette méthode d'optimisation des services permet de raccourcir le cycle de développement et de réduire les coûts. Lorsqu'un service est utilisé par de nombreux modules, il convient d'isoler les modules appelants de la cible afin que, dans le cas où la mise à niveau d'une cible est effectuée, le basculement sur le nouveau service puisse s'effectuer de manière transparente vis-à-vis du module appelant. La présente rubrique compare le modèle d'appel simple et le modèle d'appel isolé, en illustrant par un exemple les avantages offerts par la technique d'isolement. Bien que l'exemple décrit soit spécifique, il existe d'autres méthodes pour isoler les modules et les cibles.
Lors du développement d'un module, vous pouvez être amené à utiliser des services situés dans d'autres modules. Pour ce faire, vous devez importer le service dans le module, puis appeler ce service. Le service importé est "connecté" au service exporté via l'autre module, soit sous WebSphere Integration Developer, soit par l'établissement d'une liaison avec le service via la console d'administration. Le modèle d'appel simple illustre cette configuration.
Pour changer la cible d'appel sans impliquer l'arrêt des modules d'appel, vous pouvez isoler ces derniers de la cible concernée par l'appel. Ceci permet aux modules de poursuivre le traitement durant le changement de cible, puisque le changement affecte non pas le module lui-même, mais la cible située en aval. La figure Exemple d'isolement d'applications indique comment l'isolement permet de modifier la cible sans influer sur l'état du module appelant.
Lorsque le modèle d'appel simple est appliqué, l'appel d'un même service par plusieurs modules équivaut pratiquement à un Appel de service unique par des applications multiples. Les modules MODA, MODB et MODC appellent conjointement CalculateFinalCost.
L'isolement permet de créer un module tampon entre les applications et la cible (voir Modèle d'appel isolé du service UpdateCalculateFinal).
Suivant ce modèle, les modules d'appel restent inchangés, la seule modification portant sur la liaison entre l'interface d'importation du module tampon et la cible (voir Modèle d'appel isolé du service UpdatedCalculateFinal).
Si le module tampon procède à l'appel synchrone de la cible, le résultat renvoyé vers l'application d'origine lors du redémarrage du module tampon (qu'il s'agisse d'un module de médiation ou d'un service pour module métier) provient de la nouvelle cible. En cas d'appel asynchrone de la cible par le module tampon, les résultats renvoyés vers l'application d'origine proviendront de la nouvelle cible dès l'appel suivant.