Übersicht über die Isolation von Modulen und Zielen

Bei der Entwicklung von Modulen stellen Sie in der Regel fest, dass bestimmte Services von mehreren Modulen genutzt werden können. Eine solche Wiederverwendung von Services verringert den Entwicklungszyklus und die Kosten. Wenn Sie über einen Service verfügen, der von vielen Modulen verwendet wird, sollten Sie die aufrufenden Module vom Ziel isolieren, damit bei einem Upgrade des Ziels der Wechsel auf den neuen Service für das aufrufende Modul transparent ist. Das vorliegende Thema stellt dem einfachen Aufrufmodell das isolierte Aufrufmodell gegenüber und enthält ein Beispiel für die Nützlichkeit einer Isolierung. Das spezielle Beispiel, anhand dessen die Isolierung beschrieben wird, stellt jedoch nicht die einzige Methode dar, mit der Module von Zielen isoliert werden können.

Einfaches Aufrufmodell

Beim Entwickeln eines Moduls können Sie Services verwenden, die in anderen Modulen vorhanden sind. Hierzu importieren Sie den Service in das Modul und rufen anschließend diesen Service auf. Der importierte Service ist mit dem durch das andere Modul exportierten Service entweder in WebSphere Integration Developer oder durch die Bindung des Services in der Administrationskonsole "verbunden". Dieses Modell ist in der Abbildung Einfaches Aufrufmodell dargestellt.
Abbildung 1. Einfaches AufrufmodellDie Abbildung zeigt die Anwendung MyModule, die den Service ServiceA aufruft. Der Aufruf zeigt auf eine Importschnittstelle in der Anwendung, die mit einer Exportschnittstelle im Service ServiceA der Anwendung DifferentModule verbunden ist.

Isoliertes Aufrufmodell

Um das Ziel eines Aufrufs zu ändern, ohne hierbei die aufrufenden Module zu stoppen, können Sie die aufrufenden Module vom Ziel des Aufrufs isolieren. Hierdurch können die Module die Verarbeitung fortsetzen, während Sie das Ziel ändern. Dies liegt daran, dass Sie nicht das Modul selbst, sondern das nachgelagerte Ziel ändern. Die Abbildung Beispiel für die Isolation von Anwendungen macht deutlich, wie Sie mit der Isolation das Ziel ändern können, ohne den Status des aufrufenden Moduls zu beeinflussen.

Beispiel für die Isolation von Anwendungen

Bei Verwendung des einfachen Aufrufmodells würden mehrere Module, die denselben Service aufrufen, in etwa der Abbildung Aufruf eines Services durch mehrere Anwendungen entsprechen. MODA, MODB und MODC rufen den Service CalculateFinalCost auf.
Abbildung 2. Aufruf eines Services durch mehrere AnwendungenDie Abbildung zeigt mehrere Module, die den Service CalculateFinalCost direkt aufrufen.
Der von CalculateFinalCost bereitgestellte Service muss aktualisiert werden, damit neue Kosten in allen Modulen wiedergegeben werden, die diesen Service verwenden. Das Entwicklerteam erstellt und testet den neuen Service UpdatedCalculateFinal, um die Änderungen zu integrieren. Danach kann der neue Service in der Produktion eingesetzt werden. Ohne eine Isolation müssten Sie alle Module, die den Service CalculateFinalCost aufrufen, so aktualisieren, dass der Service UpdateCalculateFinal aufgerufen wird. Bei einem Einsatz der Isolation müssen Sie lediglich die Bindung ändern, die das Puffermodul mit dem Ziel verbindet.
Anmerkung: Wenn Sie den Service auf diese Weise ändern, können Sie weiterhin den ursprünglichen Service für andere Module bereitstellen, die ihn möglicherweise benötigen.
Bei Verwendung der Isolation erstellen Sie zwischen den Anwendungen und dem Ziel ein Puffermodul (siehe Isoliertes Aufrufmodell mit Aufruf von UpdateCalculateFinal).
Abbildung 3. Isoliertes Aufrufmodell mit Aufruf von UpdateCalculateFinalDie Abbildung zeigt die Module ModA, ModB und ModC, die den Service CalculateFinalCost aufrufen. Der Aufruf wird in die Anwendung BufferMod aufgelöst, die einen Service namens CalculateFinalCost enthält. Dieser Service zeigt lediglich auf den eigentlichen Service CalculateFinalCost in der Anwendung ActualMod.
Bei diesem Modell werden die aufrufenden Module nicht geändert, und Sie müssen lediglich die Bindung vom Puffermodulimport an das Ziel ändern (siehe Isoliertes Aufrufmodell mit Aufruf von UpdatedCalculateFinal).
Abbildung 4. Isoliertes Aufrufmodell mit Aufruf von UpdatedCalculateFinalDie Abbildung entspricht der vorherigen Abbildung mit der Bindung von CalculateFinalCost in BufferMod und dem Verweis auf UpdateFinalCost.
Falls das Puffermodul das Ziel synchron aufruft, stammen die Ergebnisse, die an die Ursprungsanwendung zurückgegeben werden, vom neuen Ziel, sobald das Puffermodul (ein Mediationsmodul oder ein Service für Business-Module) erneut gestartet wurde. Ruft das Puffermodul das Ziel asynchron auf, stammen die Ergebnisse, die an die Ursprungsanwendung zurückgegeben werden, beim nächsten Aufruf vom neuen Ziel.
Zugehörige Informationen
Ziele ändern

(c) Copyright IBM Corporation 2005, 2006.
Dieses Information Center basiert auf Eclipse-Technologie. (http://www.eclipse.org)