WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Présentation de l'isolement des modules et des cibles

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.

Modèle d'appel simple

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.

Figure 1. Modèle d'appel simpleMyModule invoque un service : ServiceA. L'appel pointe vers une interface d'importation figurant dans MyModule, lui-même connecté à une interface d'exportation dans ServiceA.

Modèle d'appel isolé

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.

Exemple d'isolement d'applications

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.

Figure 2. Appel de service unique par des applications multiplesLa figure illustre l'appel direct de CalculateFinalCost par plusieurs modules.
Le service fourni par CalculateFinalCost nécessite une mise à jour, de sorte que les nouveaux coûts soient reflétés dans tous les modules exploitant ce service. L'équipe de développement met au point et teste un nouveau service (UpdatedCalculateFinal) visant à incorporer les modifications. Le nouveau service est dès lors prêt à entrer en phase de production. Si aucun isolement n'est effectué, vous devez mettre à jour l'ensemble des modules appelant CalculateFinalCost, afin de définir l'appel de UpdateCalculateFinal. Grâce à l'isolement, la seule modification nécessaire porte sur la liaison entre le module tampon et la cible.
Remarque : En utilisant cette méthode pour modifier le service, vous pouvez continuer à fournir le service d'origine aux autres modules ayant besoin de l'exploiter.

L'isolement permet de créer un module tampon entre les applications et la cible (voir Modèle d'appel isolé du service UpdateCalculateFinal).

Figure 3. Modèle d'appel isolé du service UpdateCalculateFinalTrois modules appellent CalculateFinalCost. L'appel est résolu dans l'application BufferMod qui pointe vers CalculateFinalCost dans l'application ActualMod.

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).

Figure 4. Modèle d'appel isolé du service UpdatedCalculateFinalCette figure, similaire à la précédente, présente une liaison entre l'entité CalculateFinalCost de BufferMod pointant vers UpdateFinalCost.

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.


concept Rubrique concept

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cdev_ovwisolatingapplsandtargs.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).