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.
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 Anwendungen
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 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
UpdatedCalculateFinal
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.