info@enpit.de +49 5251 20277 91

Durch die Einführung von agilen Vorgehensweisen sind Ergebnisse aus der Softwareentwicklung früher sichtbar und auch nutzbar geworden. Aus Architektur- und Betriebssicht zeigen sich jedoch neue Hindernisse: einmal der Anwendungsschnitt einer Applikation und die Bereitstellung von neuen Features oder Modulen mit minimaler Unterbrechung der im Einsatz befindlichen Anwendung.

Im Artikel „Production Redeployment von ADF Anwendungen“ in der aktuellen DOAG News Nr. 3/2014 beschreiben Ulrich Gerkmann-Bartels und Andreas Koop, welche Voraussetzungen und Vorgehensweisen im Deployment von ADF-Anwendungen eingeführt werden können, um ein Production Redeployment zu etablieren.

Dabei treffen in der Softwareentwicklung unterschiedliche Zielvorstellungen aufeinander: Flexibilität, Granularität der Softwareentwicklung kombiniert mit der Bereitstellung und Verfügbarkeit einer Anwendung im Betrieb. Neben der methodischen Vorgehensweise „DevOps“ einzuführen, gibt es die Möglichkeit mit dem Oracle Fusion Middleware – Stack eine sichere und modulare Anwendungsbereitstellung umzusetzen.

Um u.a. die Flexibilität in der Anwendungsentwicklung zu nutzen, ist es hilfreich einen Blick auf die Applikation und die beinhalteten Module zu werfen.

Mit Hilfe der Pillar Architektur können fachliche Module zu einem Enterprise Archiv (EAR) gebündelt und durch eine entsprechende ADF Library mit allgemeinen nicht fachlichen Komponenten versorgt werden. (Detaillierte Informationen zur Pillar-Architektur erfahren Sie unter https://www.youtube.com/watch?v=0CicgZffzqg

ADF Architecture
Quelle: Oracle ADF Architecture Square

 

Enterprise Archive sind unabhängig von einander bereitstellbar – mit einem eigenen Lebenszyklus. Durch einen ContextStore oder Coherence Cluster kann jedoch ein gemeinsamer Kontext zwischen den Modulen abgebildet werden.

Production Redeployment ermöglicht es im WebLogic Server zwei Versionen einer Anwendung gleichzeitig durch die Angabe von unterschiedlichen und aufsteigenden Versionsnummern auszuführen. Neben versionierten Deployments von Applikationen erlaubt der WebLogic Server auch die Versionierung von sog. Shared Libraries. Bibliotheken können somit in einer WebLogic Domain zur zentralen Verwendung durch mehrere Applikationen bereit gestellt werden.

Production Redeployment / Side-by-Side Deployment

Im Kontext von ADF Anwendungen lassen sich damit einzelne fachliche Module oder auch Module mit Querschnittsfunktionalitäten als Shared ADF Library bereitstellen. Ähnlich den versionierten Deployments von EARs bzw. WARs können auch die Bibliotheken versioniert bereitgestellt werden.

Optional können Spezifikations- und Implementierungsversionsnummern mitgegeben werden. Werden die Versionsangaben weggelassen, bedeutet dies, dass die Applikation stets die Bibliothek mit der höchsten Versionsnummer verwenden soll.
Neue Versionen werden als paketiertes WAR mit dem Standard-Library-Deployment-Befehl bereitgestellt. So ist es möglich mehrere Versionen einer Shared Library zu installieren.

Kombiniert man jetzt die Möglichkeiten, so ist die Realisierung von fachlichen Modulen möglich, die Anwendungen von außen integrieren. Die Pillar Architektur kommt an dieser Stelle an Ihre Grenzen. Möglich ist dies jedoch mit ADF Task Flows, verpackt in einer ADF Library, die durch eine WebLogic Shared Library der konsumierenden Anwendung zur Verfügung gestellt wird. Die entsprechende WebLogic Shared Library dient als Proxy für die nutzende Anwendung. Durch einen abgestimmten Build- und Deployment – Prozess kann eine modulare und flexible Bereitstellung durchgeführt werden. Anwendung findet dieses Verfahren im Übrigen bei der Entwicklung von eigenen ADF Task Flows für WebCenter Portal ab der Version 11.1.1.8.

Die Herausforderung zwei gleiche Versionen einer Software für einen bestimmten Zeitraum zur Verfügung zu stellen oder ggfs. das Zurückfahren auf eine vorherige Version kann erhebliche Komplexität beinhalten. Die Grenzen beginnen bei der Integration (im Backend). Insbesondere wenn es sich um eine Anwendungen handelt, die Datenbank weitreichend für Logik und Verarbeitung nutzen.

Basieren die neuen Versionen der einzelnen Bausteine und Applikationen auf entsprechenden Datenbank-Schema – Änderungen im Backend, so sind diese entsprechend in eine Rollback-Strategie mit einzuplanen. Unter Umständen kann eine gleichzeitige Nutzung von verschiedenen Versionen bei einer Änderung im Backend auch ausgeschlossen sein. In diesem Fall bleibt immer noch die Möglichkeit eine entsprechende Bereitstellung in einem Wartungsfenster durchzuführen. Die Vorteile die Artefakte durch die eingeführte Versionsnummer identifizieren zu können bleiben bestehen.

Bestehen Abhängigkeiten zu WebServices- oder Rest-Schnittstellen werden diese mit entsprechenden Konzepten bzgl. der Versionierung und Lifecycle berücksichtigt und ermöglichen eine Verfügbarkeit von verschiedenen Versionen zur Nutzung in den jeweiligen Modulen.

Nicht zuletzt sollte man sich gut überlegen in wieweit man die Modularisierung der einzelnen Module in eigene WebLogic Shared Libraries treibt, sonst hat man sich eines Tages eine eigene DLL-Hell erschaffen.

Den ausführlichen Artikel können Sie der aktuellen Ausgabe der DOAG News entnehmen oder als Download im Dokumentenarchiv auf der DOAG Homepage.

Referenzen und weitere Hinweise: