Referenzarchitektur
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
1. Einleitung
Die IsyFact ist eine freie allgemeine Software Factory zum Bau von IT-Systeme, die vom Bundesverwaltungsamt bereitgestellt wird. Sie wurde entwickelt, um unterschiedliche Geschäftsanwendungen effizient entwerfen, realisieren und betreiben zu können. Der Begriff Factory steht für die schnelle Erzeugung neuer Anwendungen durch Anpassung und Ausgestaltung vorgefertigter Elemente, die in eine standardisierte Plattform integriert werden können.
Die IsyFact besteht aus den IsyFact-Standards und IsyFact-Erweiterungen:
Die IsyFact-Standards bilden das architektonische, technologische und methodische Fundament der IsyFact.
Sie umfassen allgemeingültige und wiederverwendbare Konzepte und Komponenten, die für die Entwicklung beliebiger Geschäftsanwendungen relevant und verpflichtend sind.
Beispiele: Allgemeine Softwarereferenzarchitektur, Vorgaben zur Fehlerbehandlung, Logging.
Die IsyFact-Erweiterungen sind optionale wiederverwendbare Lösungen für verschiedene Problemstellungen, die aufgrund spezifischer Anforderungen des BVA oder seiner
Kunden entwickelt wurden und
auf den IsyFact-Standards aufbauen.
Beispiele: Protokollierung, Regelwerk.
Die in diesem Dokument beschriebene Referenzarchitektur ist ein zentraler Teil der IsyFact-Standards und erläutert auf einer allgemeinen Ebene, wie eine Anwendungslandschaft zu beschreiben und umzusetzen ist.
1.1. Kurzüberblick
Dieser Abschnitt gibt einen zusammenfassenden Überblick über die wesentlichen Inhalte der Referenzarchitektur, die in späteren Kapiteln noch einmal ausführlich dargestellt werden. Dabei wird die Architektur aus drei verschiedenen Sichten betrachtet, die zunächst eingeführt werden.
Die Referenzarchitektur unterscheidet zwischen den folgenden Architektursichten:
Fachliche Referenzarchitektur: Dies umfasst eine fachliche Beschreibung der Anwendungslandschaft. Diese wird in fachliche Komponenten zerlegt, die miteinander über fachliche Schnittstellen interagieren.
Software-Referenzarchitektur: Dies ist eine software-technische Beschreibung der Systemlandschaft. Die gesamte Systemlandschaft wird in technische Komponenten mit technischen Schnittstellen zerlegt.
Referenzarchitektur der technischen Infrastruktur: Hierunter fällt eine Beschreibung der Systemlandschaft aus dem Blickwinkel der technischen Infrastruktur. Es wird beschrieben, welche technischen Systeme existieren und welche technischen Komponenten auf ihnen laufen.
Diese Architektursichten werden im Folgenden beschrieben.
1.1.1. Fachliche Referenzarchitektur
Eine Anwendungslandschaft baut sich aus Anwendungsdomänen, Anwendungssystemen (Geschäftsanwendungen und Querschnittsanwendungen), dem Portal und den Service-Gateways auf. Dies ist in Abbildung 1 dargestellt.
Anwendungsdomänen: Eine Anwendungsdomäne gruppiert fachlich zusammengehörende Anwendungssysteme zur Unterstützung von Geschäftsprozessen, die als eine Einheit angesehen werden können.
Anwendungssysteme: Ein Anwendungssystem ist eine zusammengehörende, logische Einheit aus Funktionen, Daten und Schnittstellen. Anwendungssysteme unterstützen Geschäftsprozesse. Stellt ein Anwendungssystem eine Fachlogik dar, so handelt es sich um eine Geschäftsanwendung. Ein Anwendungssystem ist Bestandteil der A-Architektur. Aus Sicht der T-Architektur bildet ein IT-System die software-technische Umsetzung eines Anwendungssystems ab.
Ein häufig anzutreffendes Beispiel hierfür ist die Trennung in ein Anwendungssystem zur Bestandsverwaltung (Register) und einem Anwendungssystem für die Benutzerinteraktion, die auf die Bestandsverwaltung zugreift. Im Zuge einer solchen Aufgabenteilung werden auch weitergehende Regeln definiert, wie Anwendungssysteme aufeinander zugreifen dürfen. Derartige Strukturierungsprinzipien und Regeln sind jedoch immer spezifisch für den jeweiligen Kontext der Anwendungslandschaft und können nicht allgemeingültig festgelegt werden. Im vorliegenden Dokument verwenden wir daher den neutralen Begriff Geschäftsanwendung für alle Arten von Anwendungssystemen, die eine bestimmte fachliche Funktionalität innerhalb einer Anwendungsdomäne realisieren.
Querschnittsanwendungen: Eine Querschnittsanwendung ist ein Anwendungssystem, das Services für mehrere Geschäftsanwendungen bereitstellt. Diese Services sind oft technisch motiviert.
Portal: Das Portal stellt den Benutzern eine einheitliche Dialogoberfläche für den Zugriff auf die Services der Anwendungslandschaft zur Verfügung. Einzelne Geschäftsanwendungen stellen Nutzerschnittstellen zur Verfügung, das Portal integriert diese, bildet einen zentralen Einstiegspunkt für alle Web-Anwendungen und übernimmt die Aufgabe der Authentifizierung und der Autorisierung auf Anwendungsebene.
Service-Gateway: Im Service-Gateway werden alle Services der Anwendungssysteme bereitgestellt, die externe Nutzer direkt nutzen dürfen. Dazu führt das Service-Gateway die Authentifizierung und Autorisierung der Service-Aufrufer auf Anwendungsebene durch. Weiterhin transformiert das Service-Gateway das interne Kommunikationsprotokoll einer IsyFact-Systemlandschaft in das vom Service-Aufrufer erwartete Protokoll. Dies sind in der Regel Web Service-Aufrufe.
1.1.2. Software Referenzarchitektur
Die individuell erstellten Anwendungssysteme der Anwendungslandschaft sind technisch gleichartig aufgebaut. Daher wird eine Referenzarchitektur aufgestellt, nach denen Anwendungssysteme (Geschäftsanwendungen und Querschnittsanwendungen) software-technisch in IT-Systeme umgesetzt werden. Das Dokument Referenzarchitektur IT-Systeme beschreibt diese Referenzarchitektur.
Skalierbarkeit und Hochverfügbarkeit sind wichtige Anforderungen an die Referenzarchitektur. Dies wird unterstützt durch eine zustandslose Serverarchitektur. Der Zustand einer Anwendung wird in der Datenbank persistiert und bei jedem eintreffenden Service-Aufruf aus dieser gelesen und bei Beendigung des Service-Aufrufs wieder in die Datenbank geschrieben.
In der Referenzarchitektur erfolgt die Anpassung an steigende Anforderungen durch horizontale Skalierung auf der Ebene der Anwendungsserver. Ein (Hardware- oder Software-)Loadbalancer verteilt die eingehenden Anfragen auf die vorhandenen Anwendungsserver. Im Falle eines Serverausfalls kann die Aufgabe des ausgefallenen Servers durch einen anderen Server übernommen werden. Die Skalierung des Systems ist in Abbildung 2 dargestellt.
Die Referenzarchitektur ist die Umsetzung einer Serviceorientierten Architektur. Im Design des Anwendungskerns (siehe Detailkonzept Komponente Anwendungskern) finden sich explizit Komponenten und Services. Der Anwendungskern unterscheidet dabei noch zwischen Anwendungs-internen Services, die nur innerhalb der Anwendung aufgerufen werden und Anwendungs-externen Services, die über eine Nutzungsschnittstelle als Service anderen Anwendungen zur Verfügung gestellt werden.
Der Entwurf der Services leitet sich in der Referenzarchitektur aus fachlichen Kriterien her. Services werden in der fachlichen Referenzarchitektur identifiziert und finden sich dann auch in der technischen Implementierung wieder.
Die in diesem Dokument beschriebene Referenzarchitektur ist eine vollwertige JEE-Architektur. Jedoch wird eine zentrale Spezifikation von JEE nicht genutzt: die EJB-Spezifikation aus dem Bereich Enterprise Application. Dies hat vor allem Performance- und Komplexitätsgründe. Es hat zur Folge, dass als Application Server ein Servlet-Container ausreichend ist.
1.1.3. Referenzarchitektur der technischen Infrastruktur
Im Bereich der technischen Infrastruktur (IT-Architektur) werden folgende Umgebungen beschrieben:
-
Produktionsumgebung,
-
Staging-Umgebung,
-
Schulungs- und externe Testumgebung,
-
Entwicklungs- und Abnahme-Testumgebung.
Die Aufteilung in Zonen leitet sich aus dem SAGA 4-Standard ab.
| Wir orientieren uns hier nach wie vor am SAGA 4-Standard, da SAGA 5 kein Zonenmodell mehr enthält. Leider gibt es zu SAGA 4 keine offizielle Quelle mehr. |
Abbildung 3 skizziert die Referenzarchitektur der technischen Infrastruktur für die Produktionsumgebung. Die anderen Umgebungen sind vereinfachte und verkleinerte Abbilder der Produktionsumgebung.
Um die Sicherheit in der Datenkommunikation zu gewährleisten, sind die Server unterschiedlichen Sicherheitszonen des Netzwerks zugeordnet. In Abbildung 3 ist eine Sicherheitszone durch ein gestricheltes Rechteck dargestellt. Zonenübergreifende Kommunikationsverbindungen werden von den Firewalls kontrolliert.
Für die Datenhaltung wird ein auf einem relationalen Datenbank-Management-System (RDBMS) basierender Datenbank-Cluster im Hot-Standby eingesetzt. Um Auswertungen auf Stichtagsbeständen durchführen zu können, wird ein dedizierter Datenbankserver vorgesehen.
1.2. Inhaltsübersicht
Nachdem in Kapitel Kurzüberblick die drei Sichten der Referenzarchitektur für eine Anwendungslandschaft kurz vorgestellt wurden, erfolgt nun eine Detaillierung der einzelnen Sichten:
-
Die fachliche Sicht wird durch die fachliche Referenzarchitektur beschrieben.
-
Die software-technische Sicht wird durch die software-technische Referenzarchitektur beschrieben.
-
Die Sicht der technischen Infrastruktur wird durch die Referenzarchitektur der technischen Infrastruktur beschrieben.
Im Rahmen dieser Referenzarchitektur werden auch betriebliche Aspekte betrachtet, da diese Auswirkungen auf Designentscheidungen haben können. Diese Aspekte werden in Kapitel "Betriebliche Aspekte" beschrieben.
2. Übersicht über die IsyFact
Dieses Kapitel führt in die grundlegenden Ideen der IsyFact ein. Dazu wird zunächst die IsyFact selbst vorgestellt, danach die Referenzarchitektur in die IsyFact eingeordnet und Ideen und Ziele der Referenzarchitektur beschrieben.
2.1. Die IsyFact
Dieses Dokument und die enthaltene Referenzarchitektur sind Bestandteile der IsyFact. Im Folgenden wird beschrieben, was die Idee hinter der IsyFact ist und welche inhaltlichen Bereiche die IsyFact insgesamt abdeckt.
2.1.1. Die Idee der IsyFact
Beschäftigt man sich mit dem Entwurf und der Implementierung von Anwendungslandschaften, so stellt man fest, dass sich die einzelnen Geschäftsanwendungen im Allgemeinen sehr ähnlich sind. Viele Problemstellungen müssen nur einmal gelöst werden und können dann wiederverwendet werden.
Die IsyFact wurde entwickelt, um unterschiedliche Geschäftsanwendungen effizient entwerfen, realisieren und betreiben zu können. Sie umfasst Konzepte, Software-Bausteine, eine Betriebsplattform, Werkzeuge und eine Methodik, auf deren Basis Geschäftsanwendungen schneller, preiswerter und sicherer umgesetzt werden können. Der Begriff Factory steht für die schnelle Erzeugung neuer Anwendungen durch Anpassung und Ausgestaltung vorgefertigter Elemente, die in eine standardisierte Plattform integriert werden können.
Die Vorteile des IsyFact-Ansatzes sind vielfältig: Die zügige und effiziente Einrichtung neuer Geschäftsanwendungen erhöht die Wirtschaftlichkeit. Durch Homogenisierung der Anwendungslandschaft werden Administration und Wartung vereinfacht. Weitere Vorteile sind höhere Sicherheit und Softwarequalität durch Einsatz erprobter Komponenten und Services sowie mehr Nachhaltigkeit durch eine zukunftssichere, weitgehend herstellerneutrale Software-Architektur und Plattform.
2.1.2. Durch die IsyFact abgedeckte Bereiche
Die IsyFact bietet standardisierte Lösungen zu wichtigen Themen beim Bau von Geschäftsanwendungen. Der Entwickler kann sich dadurch ganz auf die strukturellen und operativen Besonderheiten seiner Geschäftsanwendung konzentrieren.
Die Lösungen decken fünf Bereiche ab: Blaupausen, Bausteine, Betriebsplattform, Methodik und Werkzeuge.
Blaupausen: Blaupausen beschreiben die vorgegebene Architektur und Konzepte einer Anwendungslandschaft für den Betrieb von Geschäftsanwendungen aus drei verschiedenen Sichten: der fachlichen Sicht, der Sicht der softwaretechnischen Umsetzung und der Sicht der technischen Infrastruktur.
Bausteine: Bausteine sind konkrete, strukturierte Lösungen zur Umsetzung der in den Blaupausen beschriebenen Architektur und Konzepte. Bausteine sind wieder verwendbare Softwarelösungen, z.B. ein Regelwerk für fachliche Konsistenzprüfungen oder Komponenten zur Protokollierung. Diese Bausteine liegen in unterschiedlichen Formen vor: Es gibt fachliche und technische Services im Sinne einer serviceorientierten Architektur (SOA) und wieder verwendbare Bibliotheken und Programmiervorlagen. Dazu gehören auch am Markt verfügbare Fertigprodukte, für die detaillierte Nutzungsvorgaben erstellt wurden.
Betriebsplattform: Die Plattform definiert allgemeine Vorgaben und Rahmenbedingungen für den Betrieb von Anwendungslandschaften, die sich aus der Verwendung der IsyFact ergeben. Es werden Rechner-, Unterstützungsprogramm- und Netzwerkstrukturen beschrieben. Die Betriebsplattform besteht aus Hardware und Netzen sowie der benötigten Middleware mit Anwendungsserver oder Datenbankserver und ist hochverfügbar. Diese Plattform ist über alle Geschäftsanwendungen einheitlich und ermöglicht so einen standardisierten und effizienten Systembetrieb.
Methodik: Im Rahmen einer Software-Factory bildet die Methodik die Grundlage für die Umsetzung von Geschäftsanwendungen. Die Methodik der IsyFact bietet verschiedene Vorschläge zu allen Phasen des Software-Entwicklungsprozesses, wie z. B. Vorlagen für die Spezifikation oder die Programmierung. Dieses Dokument ist V-Modell®-XT konform.
Werkzeuge: Die IsyFact setzt auf Automatisierung und Werkzeugunterstützung bei der Erstellung von Registern. Dazu bietet sie Konfigurationsanleitungen ausgewählter Werkzeuge, z. B. für die Modellierung, die Programmierung, Tests oder die Fehlerverfolgung.
2.2. Einordnung der Referenzarchitektur in die IsyFact
Die in diesem Dokument beschriebene Referenzarchitektur ist ein zentraler Teil der IsyFact und erläutert auf einer hohen Ebene, wie eine Anwendungslandschaft zu beschreiben und umzusetzen ist. Die weiteren Blaupausen der IsyFact detaillieren Teile dieser Referenzarchitektur und werden im vorliegenden Dokument referenziert.
2.3. Die Idee der Referenzarchitektur
Die Referenzarchitektur definiert einen Strukturierungsrahmen für die Anwendungslandschaft und legt Prinzipien für die softwaretechnische Realisierung fest.
Der konkrete Aufbau einer Anwendungslandschaft mit der IsyFact orientiert sich an dieser Referenzarchitektur. Dabei wird die Referenzarchitektur als Ausgangspunkt genommen und an den Stellen modifiziert und konkretisiert, die im konkreten Kontext nicht direkt anwendbar sind.
Im Rahmen der Referenzarchitektur wird eine solche Anwendungslandschaft aus der fachlichen Sicht, der Sicht der softwaretechnischen Umsetzung und der Sicht der technischen Infrastruktur betrachtet. Für jede Sicht wird eine Referenzarchitektur definiert:
Fachliche Referenzarchitektur: Hierunter fällt eine fachliche Beschreibung der Anwendungslandschaft. Die gesamte Anwendungslandschaft wird in fachliche Komponenten zerlegt, die miteinander über fachliche Schnittstellen interagieren. Jegliche technischen Aspekte sind dabei nicht von Belang. Die fachliche Referenzarchitektur wird in Kapitel Die fachliche Referenzarchitektur definiert.
Software-Referenzarchitektur: Hierunter fällt eine software-technische Beschreibung der Systemlandschaft. Die gesamte Systemlandschaft wird in technische Komponenten zerlegt, die miteinander über technische Schnittstellen interagieren. Jegliche Abbildung auf physikalische Systeme und deren Infrastruktur sind dabei nicht von Belang. Die Software-Referenzarchitektur wird in der Referenzarchitektur IT-Systeme definiert.
Referenzarchitektur der technischen Infrastruktur: Ist eine Beschreibung der Systemlandschaft aus dem Blickwinkel der technischen Infrastruktur. Es wird beschrieben, welche technischen Systeme existieren und welche technischen Komponenten auf ihnen laufen. Die Referenzarchitektur der technischen Infrastruktur wird in Kapitel Die Referenzarchitektur der technischen Infrastruktur definiert.
2.4. Die Ziele der Referenzarchitektur
Mit der Einführung und Verwendung der Referenzarchitektur werden unter anderem die folgenden Ziele verfolgt:
Einheitlichkeit: Durch die Vorgaben der Referenzarchitektur wird eine Gleichartigkeit der verschiedenen Systeme in Hinblick auf ihre fachliche Strukturierung, ihre technologische Strukturierung und Umsetzung, die verwendeten Produkte, ihre Dokumentation und die Art ihres Betriebs erreicht. Hierdurch verbessert sich die Verständlichkeit, Wartbarkeit und Betreibbarkeit der Systeme.
Effizienz: Durch die Verwendung vorhandener Querschnittsanwendungen, Bibliotheken, Generatoren, Beispielanwendungen und die Vorgaben der Referenzarchitektur können die Anwendungssysteme effizienter entwickelt und gewartet werden. Durch die infrastrukturelle und betriebliche Gleichartigkeit der Anwendungssysteme können diese effizienter betrieben werden.
Sicherheit: Die Referenzarchitektur sieht bewährte Technologien und Produkte, eine Infrastruktur nach der Architekturrichtlinie für die IT des Bundes, und nach klaren architektonischen Vorgaben erstellte Anwendungssysteme vor. Die Risiken für Ausfälle, Fehler oder Sicherheitslücken wird hierdurch reduziert und die Zukunftssicherheit der Anwendungssysteme erhöht.
Erfahrung: In die Definition der Referenzarchitektur sind wertvolle Erfahrungen zur Umsetzung großer und verteilter Softwaresysteme im Allgemeinen und Registern im Speziellen eingeflossen. Diverse Geschäftsanwendungen wurden mit der Referenzarchitektur umgesetzt und die Referenzarchitektur kontinuierlich verbessert. Durch die Verwendung der Referenzarchitektur wird diese Erfahrung nutzbar gemacht. Die mit dieser Referenzarchitektur erstellten Geschäftsanwendungen sind hierdurch äußerst effizient umsetzbar, wartbar, betreibbar und zukunftssicher.
Standards: Durch die Referenzarchitektur werden Standards wie V-Modell XT, XML / XÖV oder Webservices genutzt und die Architekturrichtlinie für die IT des Bundes umgesetzt.
2.5. Tailoring der Referenzarchitektur
Die IsyFact-Referenzarchitektur hat das Ziel, eine möglichst große Bandbreite von Systemen abzudecken. Daher trifft sie zunächst kaum Annahmen über die Struktur der Systemlandschaft oder die Art der darin enthaltenen Systeme. Auf einer allgemeinen Ebene unterscheidet die IsyFact-Referenzarchitektur lediglich zwischen Geschäftsanwendungen, welche die Geschäftsprozesse innerhalb der Systemlandschaft implementieren einerseits, und andererseits den Querschnittsanwendungen, Service-Gateways und dem Portal, die als unterstützende Systeme wesentliche Strukturkonzepte der IsyFact umsetzen.
In einem spezifischen Anwendungskontext wird man in der Regel jedoch viel weitergehende Festlegungen innerhalb der Anwendungsarchitektur treffen, die die Fachlichkeit des Kontexts abbilden. Diese kontextspezifischen Festlegungen können in einem eigenen Tailoring-Dokument festgehalten werden. Es soll beschreiben, wie die IsyFact im betreffenden Anwendungskontext eingesetzt wird. Insbesondere soll ein Tailoring-Dokument die Arten von kontextspezifischen Anwendungen und ihre Beziehungen untereinander.
Gemeinsam mit dem vorliegenden Dokument definiert ein Tailoring Dokument die Referenzarchitektur für eine spezifische Fachlichkeit in einem Anwendungskontexts (Kontext-Fachlichkeit). Dadurch ist es möglich, die Software-Architektur und die Architektur der technischen Infrastruktur in unterschiedlichen Kontexten zu verwenden und auf eine spezifische Fachlichkeit anzupassen. Dies ist in Abbildung 5 dargestellt.
3. Die fachliche Referenzarchitektur
Zu den Aufgaben einer öffentlichen oder privatwirtschaftlichen Organisation gehört die Durchführung verschiedener fachlicher Verfahren. Wenn solche Verfahren vollständig oder teilweise automatisiert werden sollen, so erfolgt dies in der Regel mit Anwendungssystemen, die zunächst aus fachlicher Sicht beschrieben, dann mit softwaretechnischen Mitteln umgesetzt und schließlich auf einer technischen Infrastruktur betrieben werden.
Bei einer großen Zahl von vollständig oder teilweise automatisierten Verfahren entsteht eine entsprechende Anzahl von Anwendungssystemen. Hier kann schnell der Überblick verloren gehen, sodass Prinzipien zur Strukturierung benötigt werden, die Ordnung schaffen.
Die Menge aller Anwendungssysteme einer Organisation und deren Nutzungsbeziehungen untereinander bilden eine Anwendungslandschaft. Die fachliche Architektur einer Anwendungslandschaft gibt hier die Strukturierung aus fachlicher Sicht vor und legt fest, wie Anwendungssysteme in die Anwendungslandschaft integriert werden.
Diese fachliche Architektur einer Anwendungslandschaft ist in Abbildung 6 dargestellt.
3.1. Die Strukturierung der Anwendungslandschaft
Zur Strukturierung der Anwendungslandschaft werden drei fachliche Hierarchieebenen festgelegt:
Anwendungsdomäne: Auf der obersten Hierarchieebene werden Anwendungsdomänen gebildet: Anwendungsdomänen sind fachlich eng zusammengehörige Mengen von Anwendungssystemen zur Unterstützung von Geschäftsprozessen, die als eine Einheit angesehen werden können. In Abbildung 6 wurden zwei Domänen gebildet, erkennbar an den unteren schwarzen Kästen mit der Beschriftung „Domäne“.
Zwischen den Anwendungssystemen unterschiedlicher Anwendungsdomänen sollten nur wenige, klar definierte Nutzungsbeziehungen existieren.
Anwendungssystem: Ein Anwendungssystem ist eine zusammengehörende, logische Einheit aus Funktionen, Daten und Benutzungsschnittstellen. Geschäftsprozesse werden durch Anwendungssysteme unterstützt. Anwendungssysteme sind einer Anwendungsdomäne zugeordnet. Anwendungssysteme setzen sich aus Anwendungskomponenten zusammen. Im Rahmen der allgemeinen Referenzarchitektur werden zunächst nur Geschäftsanwendungen und Querschnittsanwendungen als Typen von Anwendungssystemen unterschieden. Eine weitergehende Unterscheidung der Geschäftsanwendungen muss im Rahmen des Tailoring der Referenzarchitektur erfolgen.
-
Geschäftsanwendung: Eine Geschäftsanwendung implementiert für sich genommen oder im Zusammenspiel mit anderen Geschäftsanwendungen einen oder mehrere Geschäftsprozesse einer Anwendungsdomäne. Sie implementiert entweder die gesamte hierfür notwendige Funktionalität (monolithisch), von der Benutzerschnittstelle über die fachliche Logik, die Prozesse bis hin zur Datenhaltung. Oder die Geschäftsanwendung implementiert nur einen Teilbereich der Funktionalität und greift für den Rest über Schnittstellen auf benachbarte Geschäftsanwendungen zu.
-
Querschnittsanwendungen sind Anwendungssysteme, die Services für mehrere Geschäftsanwendungen bereitstellen, wie z. B. ein Behördenverzeichnis oder ein Outputmanagement.
Anwendungskomponenten: Eine Anwendungskomponente beschreibt eine Menge funktional zusammenhängender Anwendungsfälle. Anwendungskomponenten sind Bestandteile von Anwendungssystemen. Im Rahmen weitergehender Architekturvorgaben beim Einsatz der IsyFact in einem konkreten Anwendungskontext wird man in der Regel auch vorgeben, welche Arten von Anwendungssystemen es in diesem Kontext geben soll und aus welchen Komponenten sie bestehen.
In Abbildung 6 werden Anwendungskomponenten nicht dargestellt: Sie wären die Bestandteile der blauen und gelben Kästen.
3.2. Fachliche Referenzarchitekturen für Anwendungssysteme
Die fachliche Referenzarchitektur muss beim Einsatz der IsyFact innerhalb des jeweiligen Anwendungskontexts definiert werden. Die IsyFact dient hier als allgemeiner konzeptioneller Rahmen und macht keine Vorgaben über die Arten von Anwendungssystemen, die in einem bestimmten Kontext vorkommen.
Als Teil der fachlichen Architektur ist unter anderem folgendes zu definieren:
-
Die verschiedenen Arten von Geschäftsanwendungen, die es innerhalb des Anwendungskontexts geben soll.
-
Die Aufgaben und Verantwortlichkeiten der einzelnen Arten von Geschäftsanwendungen.
-
Der daraus resultierende interne Aufbau der Geschäftsanwendungen aus Komponenten.
-
Die Interaktion und die Abhängigkeiten zwischen den Geschäftsanwendungen, insbesondere die zulässigen Kommunikationsbeziehungen.
4. Die Software-Referenzarchitektur
Eine Software-Architektur beschreibt, wie die in einer fachlichen Architektur definierten Elemente (Anwendungssysteme, Anwendungskomponenten, fachliche Entitäten, Anwendungsfälle etc.) software-technisch in Form von IT-Systemen, Komponenten, Klassen, physischen Datenmodellen etc. umgesetzt werden.
Die Besonderheit der Software-Referenzarchitektur ist, dass sie nicht zwischen Systemarten (Geschäftsanwendungen, Querschnittsanwendungen, usw.) unterscheidet. Obwohl unterschiedliche Systeme stark unterschiedliche Fachlichkeit umsetzen können, sind die Anforderungen an ihre technische Architektur gleich.
Der Begriff der Anwendungslandschaft ist fachlich motiviert. Die technische Entsprechung hierfür ist der Begriff der Systemlandschaft. Eine Systemlandschaft, die eine Anwendungslandschaft nach den IsyFact-Standards umsetzt, wird im Folgenden als IsyFact-Systemlandschaft bezeichnet. Eine solche IsyFact-Systemlandschaft beinhaltet alle software-technisch umgesetzten Anwendungssysteme der Anwendungslandschaft sowie technische Systeme zur Unterstützung (z. B. Datenbanken, Web-Server, usw).
Die technische Architektur eines IT-Systems wird in Referenzarchitektur IT-Systeme definiert. Im Folgenden wird, aufbauend auf diesem Konzept, beschrieben:
-
welche Eigenschaften bezogen auf die technische Referenzarchitektur die Typen von Anwendungssystemen in einer IsyFact-Systemlandschaft besitzen (Kapitel Strukturierung der Systemlandschaft),
-
welche Vorgaben für die Verwendung von Produkten existieren (Kapitel Verwendung von Produkten).
4.1. Strukturierung der Systemlandschaft
Wichtige Grundlagen für die Software-Referenzarchitektur sind die Schnittstellen und Aufruf-Beziehungen der IT-Systeme vom Typ Geschäftsanwendung, Querschnittsanwendung sowie Portal und Service-Gateway. Aufruf-Beziehungen werden stets unterschieden in interne Aufrufe, in welchen ein IT-System einer IsyFact-Systemlandschaft mit einem anderen IT-System derselben IsyFact-Systemlandschaft kommuniziert, und externe Aufrufe, in welchen ein IT-System der IsyFact-Systemlandschaft mit einem Anwender oder einem IT-System außerhalb dieser IsyFact-Systemlandschaft kommuniziert: Interne und externe Aufrufe unterscheiden sich sowohl in ihrer Authentifizierung und Autorisierung als auch (bei automatisierten Schnittstellen) in der verwendeten Technologie.
Im Folgenden werden die Schnittstellen und Aufrufbeziehungen pro Anwendungssystemtyp erläutert.
Das Service-Gateway: Service-Gateway-Systeme haben die Aufgabe, Aufrufe von internen Anwendungssystemen an externe Systeme und Aufrufe von externen Systemen an interne Anwendungssysteme weiterzuleiten und dabei unterschiedliche Schnittstellentechnologien zu überbrücken.
Für die Weiterleitung von Aufrufen enthält ein Service-Gateway die folgenden Funktionalitäten:
-
Es bildet die Aufrufe zwischen der für externe Systeme verwendeten Webservice-Technologie und der für interne Schnittstellen verwendeten Technologie aufeinander ab. Es kapselt die Webservice-Technologie vor den internen Systemen.
-
Bei Aufrufen durch externe Systeme führt es die Authentifizierung und eine erste Autorisierung des Aufrufs durch.
Ein Service-Gateway-System besitzt weder eine eigene Datenhaltung noch eigene Fachlichkeit.
Die Geschäftsanwendung: Eine Geschäftsanwendung implementiert allgemein die Geschäftsprozesse einer Domäne. Geschäftsanwendungen können monolithisch strukturiert sein und alle Schichten der Software-Architektur umfassen, von der Benutzeroberfläche über Prozesse und Geschäftslogik bis hin zur Datenspeicherung. Sie können aber auch jeweils nur Teile davon implementieren, sodass z.B. eine Geschäftsanwendung eine GUI bereitstellt, eine weitere die Fachlogik implementiert und eine dritte schließlich die Persistierung der Daten realisiert. In diesem Fall würde die Gesamtfunktionalität durch das Zusammenwirken der drei Geschäftsanwendungen erbracht.
Die Geschäftsanwendungen einer IsyFact-Systemlandschaft können sich intern gegenseitig über ihre Service-Schnittstellen aufrufen. In einem konkreten Anwendungskontext einer IsyFact-Systemlandschaft wird man in der Regel die Arten von Geschäftsanwendungen noch genauer definieren und dabei auch die möglichen Aufrufbeziehungen zwischen ihnen geeignet einschränken.
Für die Kommunikation mit externen Systemen muss eine Geschäftsanwendung ein Service-Gateway-System verwenden, egal in welche Richtung die Kommunikation verläuft.
Geschäftsanwendungen, die eine Benutzeroberfläche bereitstellen, dürfen aus Sicherheitsgründen nicht direkt vom Benutzer aufgerufen werden, sondern werden in das Portal (siehe unten) der IsyFact-Systemlandschaft eingebunden.
Das Portal: Die Referenzarchitektur sieht keinen Portal-Server im klassischen Sinne vor: Es gibt weder einen systemübergreifenden Rahmen noch eine systemübergreifende Navigation.
Ein Portal im Sinne der Referenzarchitektur besteht aus:
-
Einem Web-Server-Cluster, der Aufrufe entgegennimmt und an die Application-Server der Geschäftsanwendungen weiterleitet.
-
Einer zentralen Startseite, welche den eingeloggten Benutzern die Geschäftsanwendungen der Anwendungslandschaft, für welche sie berechtigt sind, präsentiert.
Der Zweck eines Portals ist die gemeinsame Authentifizierung und Autorisierung für alle Geschäftsanwendungen und die Indirektion des Zugriffs von Nutzern auf die Geschäftsanwendungen.
Die Querschnittsanwendung: Eine Querschnittsanwendung bietet Geschäftsanwendungen querschnittlich genutzte Funktionalitäten an, etwa für die Bereitstellung von Schlüsseldaten. Querschnittsanwendungen können eine eigene Datenhaltung besitzen.
Querschnittsanwendungen werden nur von internen Benutzern oder anderen IT-Systemen derselben Systemlandschaft aufgerufen. Sie rufen selbst nur andere Querschnittsanwendungen auf. Eine Ausnahme bilden Querschnittsanwendungen, wie z.B. ein Mail-Gateway für den Versand von E-Mails an externe Empfänger.
4.2. Servicekommunikation
Wie in Strukturierung der Systemlandschaft beschrieben, kommunizieren IT-Systeme auf Basis von Services (s. Abbildung 7). Wenn ausschließlich IT-Systeme innerhalb der Systemlandschaft miteinander kommunizieren, spricht die Referenzarchitektur von interner Servicekommunikation. Wenn die Kommunikation auch IT-Systeme einschließt, die außerhalb liegen, verwendet die Referenzarchitektur den Begriff externe Servicekommunikation.
IT-Systeme tauschen in der Kommunikation untereinander Daten aus. Diese lassen sich in Metadaten und Nutzdaten unterteilen.
Metadaten können technischer oder fachlicher Natur sein. Sie sind nicht mit einer konkreten Anfrage verknüpft und werden in der Regel mit jedem Aufruf einer Schnittstelle übertragen. Zu den Metadaten gehören u.a.:
-
Daten zu übergreifenden Aspekten der Servicekommunikation wie z.B. Caching oder das Aushandeln von Formaten,
-
IDs zum Tracing von Service-Aufrufen,
-
Daten zur Authentifizierung und Autorisierung, oder
-
Metadaten dritter Systeme, die durchgeschleift werden.
Metadaten werden in der Regel in Klartext übertragen und nicht verschlüsselt oder anderweitig kodiert.
|
Die Verwendung von externen Standards bleibt davon unberührt. So überträgt der Standard OAuth 2 beispielsweise Informationen zur Autorisierung einer Anfrage BASE64-kodiert. |
Die IsyFact standardisiert den Teil der Metadaten, der über fachliche Domänen hinweg dieselbe Bedeutung besitzt.
Nutzdaten auf der anderen Seite beinhalten alle Daten, die zur Verarbeitung eines konkreten Service-Aufrufs benötigt werden. Sie bilden die eigentliche, fachliche Schnittstelle und beschreiben sowohl die Daten der Anfrage sowie der Antwort.
Die IsyFact standardisiert die Art und Weise, wie Nutzdaten spezifiziert, dokumentiert und technisch verarbeitet werden.
4.2.1. Synchrone Service-Aufrufe
Synchrone Service-Aufrufe bieten die Möglichkeit der direkten Kommunikation zwischen zwei IT-Systemen (s. Abbildung 8). Hierbei schickt der Sender eine Anfrage (engl. request) an den Empfänger. Der Empfänger bearbeitet die Anfrage und schickt eine Antwort (engl. response) an den Sender zurück. Der Sender wartet auf die Antwort, bevor er seine Verarbeitung fortsetzt.
Deswegen sind synchrone Service-Aufrufe in der Regel eine vergleichsweise zeitintensive Operation. Häufig ist es sinnvoll, Service-Aufrufe nach Möglichkeit einzusparen. Das Sparen von Aufrufen kann jedoch auch Nachteile in Bezug auf Wartbarkeit bedeuten, wenn beispielsweise Redundanzen oder komplexe Caches implementiert werden müssen. Die Abwägung darüber muss während der Erstellung des Systementwurfs geschehen.
Synchrone Service-Aufrufe finden über das Protokoll HTTP statt und werden sowohl zur internen als auch externen Servicekommunikation genutzt. HTTP-Anfragen bzw. HTTP-Antworten (s. Abbildung 9) erlauben es an drei Stellen, anwendungsspezifische Daten zu übertragen: in der URL, in den Headern sowie im Body.
Header enthalten Metadaten.
Der Body enthält Nutzdaten.
Bei Anfragen mittels GET und DELETE, die keinen Body erwarten, enthalten URL-Parameter Nutzdaten.
Allerdings gilt zu beachten, dass URLs (und damit auch die URL-Parameter) an vielen Stellen aufgezeichnet und in Logs geschrieben oder in Caches gehalten werden.
Hierbei sind z.B. datenschutzrechtliche Aspekte zu prüfen, wenn URL-Parameter personenbezogene Daten enthalten.
Im Zweifelsfall ist die Methode POST eine gangbare Alternative, um solche Nutzdaten im Body zu übertragen.
4.2.2. Asynchrone Service-Aufrufe
Für asynchrone Service-Aufrufe gelten dieselben Vorgaben wie für synchrone Service-Aufrufe. Sie unterscheiden sich im Ablauf dahingehend, dass der Sender nicht aktiv auf die Antwort des Empfängers wartet. Stattdessen wird die Verarbeitung erst durch die Antwort des Empfängers wieder aufgenommen, z.B. in Form eines Callbacks.
Asynchrone Service-Aufrufe können z.B. dann eingesetzt werden, wenn eine länger dauernde Verarbeitung durch den Empfänger eine direkte Rückmeldung unmöglich macht.
4.2.3. Queueing
Beim Queueing baut ein Message-Broker eine Punkt-zu-Punkt-Verbindung zwischen zwei IT-Systemen auf. Dies geschieht in Form einer Queue. Ein IT-System tritt fest als Sender auf, eines als Empfänger. Der Sender ist nun in der Lage, dem Empfänger über die Queue Nachrichten zu schicken. Die Nachrichten sind anhand eines zentral definierten Formats strukturiert. Der Sender enthält keine direkte Antwort vom Empfänger.
Für das Queueing infrage kommende Message-Broker müssen JMS (Jakarta Messaging, ehemals Java Message Service) unterstützen. Queueing wird ausschließlich in der internen Servicekommunikation eingesetzt.
JMS-Nachrichten bestehen aus Header, Properties und einem Body (s. Abbildung 12). Die Properties unterteilen sich noch einmal in applikationsspezifische Properties, die nur für Publisher und Subscriber Bedeutung haben, sowie provider-spezifische und Standard-Properties, die zur Verarbeitung der JMS-Nachrichten durch den Message-Broker gedacht sind.
Applikationsspezifische Properties enthalten Metadaten. Der Body enthält Nutzdaten. Nutzdaten werden im XML-Format übertragen und mittels XSD spezifiziert.
Diese Vorgabe steht vollständig in Einklang mit der JMS-Spezifikation.
Für die Übertragung von Nutzdaten sieht die JMS-Spezifikation fünf Formate vor.
Die Architekturvorgabe sieht die alleinige Nutzung der Ausprägung TextMessage vor, die Nutzdaten als Zeichenkette erwartet.
|
Weitere Details zu JMS-Nachrichten finden sich in der JMS-Spezifikation im Kapitel 3. Jakarta Messaging message model. Besonders relevant für die Referenzarchitektur sind die Abschnitte 3.3. Jakarta Messaging messages sowie 3.11. Jakarta Messaging message body. |
4.2.4. Kommunikation mit externen IT-Systemen
Die Kommunikation mit externen IT-Systemen basiert auf Web-Services. Hierbei muss man zwischen zwei Fällen unterscheiden:
Externes IT-System ruft internes IT-System auf: Durch die Systemlandschaft wird externen IT-Systemen die Schnittstelle eines internen IT-Systems in Form eines Web-Services zur Verfügung gestellt. Hierbei definiert das interne IT-System selbst keinen Web-Service. Vielmehr definiert das interne IT-System wie bei der internen Kommunikation lediglich eine Schnittstelle. Diese Schnittstelle wird dann durch ein eigenständiges IT-System als Web-Services exportiert. Dieses IT-System wird als Service-Provider bezeichnet. Für jede Schnittstelle, die als Web-Services exportiert werden soll, muss ein eigener Service-Provider definiert werden.
Internes IT-System ruft externes IT-System auf: Die Grundvoraussetzung hierfür ist, dass das externe IT-System einen Web-Service definiert. Ähnlich wie im vorigen Fall ruft das interne IT-System diesen Web-Service nicht direkt auf. Es ruft ein eigenständiges IT-System auf, welches den Web-Service des externen IT-Systems als Schnittstelle in die Systemlandschaft importiert. Dieses IT-System wird als Service-Consumer bezeichnet. Das interne IT-System ruft dann lediglich die Schnittstelle des Service-Consumers auf. Für das interne IT-System ist dieser Aufruf nicht von einem Aufruf zu einem anderen internen IT-System zu unterscheiden. Für jeden Web-Service, der in die Systemlandschaft importiert werden soll, muss ein eigener Service-Consumer definiert werden.
Die Gesamtheit aller Service-Provider und Service-Consumer eines internen IT-Systems wird als Service-Gateway bezeichnet. Die Service-Gateways stellen somit die zentrale Schnittstelle einer IsyFact-Systemlandschaft zur Außenwelt dar.
Wird ein Service von einem externen IT-System angeboten, wird er als „externer Service“ bezeichnet. Ein Service-Consumer macht diesen „externen Service“ als „inneren Service“ der Systemlandschaft verfügbar. Wird ein Service von einem internen IT-System angeboten, so ist das ebenfalls ein „innerer Service“. Wenn ein Service-Provider diesen „inneren Service“ einer Anwendung außerhalb der Plattform zugänglich macht, ist dies ein „äußerer Service“ der Systemlandschaft. Dies ist in Abbildung 13 dargestellt. Die Unterscheidung zwischen „innere“ und „äußere“ ist analog für die Begriffe „Request“ und „Response“ zu verwenden.
4.3. Nutzungsarten eines Anwendungssystems
Nachdem im Dokument Referenzarchitektur IT-Systeme die technische Architektur vorgestellt wurde, soll in diesem Abschnitt konkret vorgestellt werden, wie auf Basis dieser Architektur Anwendungen entworfen werden.
Die Nutzungsschicht eines IT-Systems bietet anderen IT-Systemen über Services, dem Betrieb über Batches und menschlichen Nutzern über eine GUI Schnittstellen zur Nutzung der implementierten Fachlichkeit an. Im Folgenden wird ein Beispiel-Szenario zur Nutzung eines IT-Systems vorgestellt.
Beispiel: Es soll eine Geschäftsanwendung erstellt werden, die sowohl manuell über eine Weboberfläche als auch automatisiert über eine SOAP-Schnittstelle nutzbar sein soll.
Für eine zur Architektur konforme Umsetzung dieser Anforderungen müssen verschiedene IT-Systeme umgesetzt werden:
Die Geschäftsanwendung: Die Geschäftsanwendung soll in diesem Beispiel die Präsentationslogik, die Geschäftslogik und die Datenhaltung in einem Anwendungssystem realisieren. Sie implementiert dazu drei software-architektonische Schichten:
-
Die Präsentationsschicht, in der die Webseiten der GUI erzeugt und die Eingaben interpretiert werden.
-
Der Anwendungskern, in dem die Geschäftslogik abgebildet ist.
-
Die Persistenzschicht, in der sowohl die Anwendungsdaten als auch der Zustand der Anwendungssitzung abgespeichert werden.
Zur Implementierung der Geschäftslogik kann die Geschäftsanwendung auch Services anderer Geschäftsanwendungen aufrufen.
Das Portal: Wie in Kapitel Strukturierung der Systemlandschaft beschrieben, nimmt das Portal die Anwender-Aufrufe entgegen und leitet sie an die Geschäftsanwendung weiter.
Das Service-Gateway-System: Wie in Kapitel Strukturierung der Systemlandschaft beschrieben, dient das Service-Gateway-System als Schnittstelle für die Kommunikation mit bzw. der Annahme der Aufrufe von externen Systemen. Im vorliegenden Fall wird nur ein Service-Provider benötigt, da nur Aufrufe entgegengenommen werden. Diese werden authentifiziert, autorisiert, und an das zugehörige IT-System weitergeleitet.
Damit ergeben sich die in Abbildung 14 dargestellten IT-Systeme und Aufruf-Beziehungen. Die in dieser Abbildung angedeuteten Schichten eines IT-Systems (GUI, Batch, Service, Anwendungskern, Datenzugriff und Querschnitt) werden im Dokument Referenzarchitektur IT-Systeme erläutert. Wichtig in Hinblick auf diese Schichten sind folgende Punkte:
-
Die Komponente Batch der Geschäftsanwendung wird im obigen Beispiel nicht implementiert, da die Geschäftsanwendung keine Schnittstelle für Batchläufe anbietet.
-
Alle externen Aufrufe an die Geschäftsanwendung werden durch eine Service-Komponente verarbeitet: Keine andere Komponente darf externe Schnittstellen bereitstellen, insbesondere nicht in den Anwendungskern.
-
Es wurden keine Aufrufe von Querschnittsanwendungen eingezeichnet. Für derartige Aufrufe gibt es keine Vorgaben: Sie können aus beliebigen Schichten von Geschäftsanwendungen und Service-Gateways aus aufgerufen werden.
4.4. Verwendung von Produkten
Bei der Umsetzung einer Architektur für eine Anwendung oder eine Anwendungslandschaft können an vielen Stellen fertige Produkte Dritter eingesetzt werden. Das beschleunigt die Entwicklung und reduziert die Kosten.
Bei der Produktentscheidung sind zwei Seiten zu berücksichtigen: Auf der einen Seite bietet die Konzentration auf projektübergreifend einheitliche Produkte die Möglichkeit, die Fähigkeiten der Mitarbeiter zu bündeln und diese übergreifend einzusetzen. Auf der anderen Seite besteht die Gefahr, durch einen zu engen Fokus die Möglichkeiten eines Projekts zu sehr zu beschränken. Eine Lösung kann dann auch Gefahr laufen, zu allgemein zu werden, was letztlich die Komplexität steigert und größeren Aufwand verursacht.
Die für die Umsetzung der Architektur verwendeten Produkte lassen sich in die Kategorien Basistechnologien, Systemsoftware und Bibliotheken für die Anwendungsentwicklung unterteilen.
Basistechnologien: Basistechnologien legen grundlegende technische Entscheidungen fest, wie z.B. die Programmiersprache und die verwendete Web-Technologie.
Systemsoftware: Die Systemsoftware legt die technische Ablaufumgebung für die Software fest und bietet grundlegende Services für eine IsyFact-Systemlandschaft an. Hierzu gehören z.B. das Betriebssystem, der Web-Server, der Application-Server, das IAM-System und die Datenbank.
Bibliotheken für die Anwendungsentwicklung: Die Anwendungsentwicklung wird durch den Einsatz von Frameworks und entsprechenden Bibliotheken vereinfacht und beschleunigt. Die IsyFact verwendet insbesondere Spring, Hibernate und Angular.
Eine detaillierte Liste der verbindlichen und empfohlenen Produkte ist im Produktkatalog zu finden.
5. Die Referenzarchitektur der technischen Infrastruktur
Die Referenzarchitektur der technischen Infrastruktur, auch TI-Architektur genannt, beschreibt den Aufbau der Betriebsumgebung für die IT-Systeme einer IsyFact-Systemlandschaft. Dazu gehören die physischen Geräte (Rechnersysteme, Netzwerkverbindungen und -komponenten, Drucker etc.), die installierte Systemsoftware (Betriebssystem, Applikationsserver, Middleware, Datenbanksystem) und das Zusammenspiel von Hardware und Systemsoftware.
Auf der Ebene der technischen Infrastruktur können mehrere Instanzen einer Komponente aus der technischen Architektur betrieben werden. Auch können mehrere Komponenten auf einem gemeinsamen Rechnersystem laufen.
5.1. Umgebungen
Um neben dem operativen Betrieb einer IsyFact-Systemlandschaft parallel neue Versionen von Anwendungen entwickeln, testen und schulen zu können, sind mehrere Systemumgebungen notwendig, die in Abbildung 15 vereinfacht dargestellt sind.
Die IsyFact unterscheidet sechs Systemumgebungen:
-
Produktionsumgebung
-
Staging-Umgebung
-
externe Schulungsumgebung
-
externe Testumgebung
-
Abnahmetestumgebung
-
Entwicklungstestumgebung
Von internen Arbeitsplätzen sind prinzipiell alle Umgebungen erreichbar, sofern entsprechende Zugangsberechtigungen existieren. Die Administrationsarbeitsplätze befinden sich im Admin-Netz, von dem ebenfalls zu Administrationszwecken auf alle Systemumgebungen zugegriffen werden kann. Externe Anwender können nur bei entsprechender Berechtigung auf die Produktionsumgebung, die Schulungsumgebung und die externe Testumgebung zugreifen. Der Zugriff auf die Staging- sowie auf die Abnahmetestumgebung sowie die Entwicklungstestumgebung ist von Extern nicht zugelassen.
Die technischen Aspekte der gesamten Systemumgebungen werden nachfolgend erläutert. Für eine bessere Übersichtlichkeit in den Abbildungen der einzelnen Systemumgebungen werden die Verbindungen mit dem Admin-Netz nicht dargestellt.
5.1.1. Produktionsumgebung (PRU)
Mit dem Begriff „Produktionsumgebung“ wird die technische Infrastruktur bezeichnet, auf der der Wirkbetrieb einer IsyFact-Systemlandschaft abläuft. Alle nichtfunktionalen Anforderungen müssen von dieser Systemumgebung vollständig erfüllt werden.
Um die Sicherheit in der Datenkommunikation zu gewährleisten, sind die Server unterschiedlichen Sicherheitszonen des Netzwerks zugeordnet. In Abbildung 16 ist eine Sicherheitszone durch ein gestricheltes Rechteck dargestellt. Zonenübergreifende Kommunikationsverbindungen werden von den Firewalls kontrolliert. Damit entspricht die TI-Architektur der Produktionsumgebung den SAGA-Vorgaben.
Der Zugriff durch die Anwender (Clients) und die über externe Systeme angeschlossener Anwender erfolgt über das WAN bzw. das interne LAN. Die Kommunikation erfolgt per Secure HTTP (HTTPS) mit einem Browser oder ebenfalls per HTTPS oder SMTP via XML- oder Web-Service-Schnittstelle direkt aus der externen Anwendung über ein Service-Gateway-System. Innerhalb der Produktionsumgebung sollten die Anwendungssysteme ebenfalls verschlüsselt miteinander kommunizieren.
Interne Drittsysteme, die aus dem internen LAN mit der IsyFact-Systemlandschaft kommunizieren, tun dies genau wie externe Anwendungen per HTTPS oder SMTP via XML- oder Web-Service-Schnittstellen über ein Service-Gateway-System. Die Authentifizierung geschieht über einen Identity & Access Management (IAM) Cluster, bzw. ein IAM-System.
Administratoren greifen aus dem Admin-Netz direkt mittels Secure-Shell auf die Serversysteme der IsyFact-Systemlandschaft zu (Betriebssystem-Ebene). Aus dem Admin-Netz ist der Zugriff auf die Anwendungen nicht möglich.
Web-Server und Service-Gateway-Systeme kommunizieren mit den Applikationsservern der Logik- und Verarbeitungszone. In Abbildung 16 wird aus Gründen der Vereinfachung davon ausgegangen, dass je Rechnersystem ein Applikationsserver betrieben wird. Zu empfehlen ist allerdings generell die Nutzung eines Rechnersystems mit mehreren Applikationsservern.
Für die Datenhaltung wird i.d.R. ein auf einem relationalen Datenbank-Management-System (RDBMS) basierender Datenbank-Cluster eingesetzt. Bei Bedarf ist dieser ausfallsicher zu skalieren, z.B. durch die Bildung von zwei Clustern. Eine Ausprägung steuert die Primärdatenbank, die für die operative Bearbeitung von Auskünften und Meldungen zuständig ist. Der operative Datenbestand wird permanent in eine Standby-Datenbank auf dem zweiten Cluster gespiegelt, die für die Datensicherung und für die Erstellung von Auswertungen und Statistiken verwendet wird. Um Auswertungen auf Stichtagsbeständen durchführen zu können, wird ein dedizierter Datenbankserver vorgesehen.
5.1.2. Staging-Umgebung (STU)
Mit dem Begriff „Staging-Umgebung“ werden die Komponenten der technischen Infrastruktur bezeichnet, die zum internen Test verwendet werden und auf denen Probleme des Wirkbetriebs nachgestellt werden können. Eine solche Umgebung ist notwendig, um Problemanalysen durchzuführen und Lösungen für bekannte Probleme vor dem Einsatz im Wirkbetrieb auf ihre Funktionsfähigkeit hin zu prüfen. Die Staging-Umgebung dient auch zu Last- und Performance-Tests, zur Überprüfung der Installationsroutinen und zur Überprüfung der Ausfallsicherheit. Daher muss sie so ausgelegt sein, dass verlässliche Aussagen in Bezug auf die Produktionsumgebung möglich sind.
Idealerweise ist die Staging-Umgebung eine exakte Kopie der Produktionsumgebung. Häufig ist dies jedoch aufgrund der sehr großen Anzahl Server und den damit verbundenen Investitionskosten für die benötigte Hardware und Software aus Wirtschaftlichkeitsaspekten nicht sinnvoll.
Daher ist die Staging-Umgebung eine in Bezug auf die Anzahl der Cluster-Knoten kleinere Kopie der Produktionsumgebung. Das heißt, an Stellen, in denen in der Produktionsumgebung ein Cluster mit mehr als zwei Knoten verwendet wird, wird in der Staging-Umgebung ein Cluster mit 2 Knoten eingesetzt. In der Staging-Umgebung wird auch auf die Datenspiegelung verzichtet. Die Staging-Umgebung einer IsyFact-Systemumgebung ist in Abbildung 17 dargestellt.
Die Server der Staging-Umgebung stehen in eigenen Sicherheitszonen. Die Zonenaufteilung sollte vergleichbar zur Produktionsumgebung sein, da sonst Engpässe in der Netzwerkkommunikation (Bandbreite, Komponentendurchsatz) bei Tests nicht erkannt werden können.
5.1.3. Externe Testumgebung (XTU)
Die externe Testumgebung wird für Tests externer Nutzer verwendet. Damit ist diese Umgebung neben der Produktionsumgebung und der externen Schulungsumgebung die einzige von außen zugängliche Systemumgebung. Abbildung 18 gibt einen Überblick.
Im Vergleich zur Produktionsumgebung ist die Leistungsfähigkeit dieser Umgebung bei vollständiger Funktionalität deutlich reduziert. Da auch an die Verfügbarkeit der Umgebung geringere Anforderungen gestellt werden, wird auf die Aufteilung in verschiedene Netzwerkzonen und auf den Betrieb der Rechnersysteme im Cluster aus wirtschaftlichen Gründen verzichtet. Die Anwendungssysteme laufen dann auf einzelnen Rechnerknoten ab.
5.1.4. Externe Schulungsumgebung (XSU)
Die externe Schulungsumgebung wird für die Durchführung von Schulungen verwendet, wobei auch externe Nutzer auf diese Umgebung zugreifen können. Sie ist eine Kopie der externen Testumgebung.
5.1.5. Entwicklungstestumgebung (ETU)
Die Entwicklungstestumgebung (ETU) wird zur Durchführung von technischen Tests genutzt. An diese Umgebung sind keine Anforderungen an hohe Ausfallsicherheit und Leistungsfähigkeit gestellt. Die Leistungsfähigkeit kann sogar noch unter der externen Test- und Schulungsumgebung liegen, da davon auszugehen ist, dass die Tests nur von sehr wenigen gleichzeitig aktiven Benutzern durchgeführt werden.
Die Rechnersysteme der Entwicklungstestumgebung werden nur vom internen LAN aus genutzt. Es gibt keine weitere Unterteilung in Sicherheitszonen. Abbildung 19 gibt einen Überblick.
5.1.6. Abnahmetestumgebung (ATU)
Die Abnahmetestumgebung wird zur Durchführung von funktionalen, d.h. fachlichen, Abnahmetests genutzt. Sie ist eine Kopie der Entwicklungstestumgebung.
5.2. Minimalanforderungen an die Ablaufumgebung
Als Ablaufumgebung benötigen die gemäß der Referenzarchitektur (siehe Kapitel Die Software-Referenzarchitektur) erstellten IT-Systeme einen Tomcat Servlet-Container.
Service-Gateway-Systeme und das Portal benötigen zusätzlich noch einen Apache-Webserver.
5.3. TI-Architektur einer Anwendung
Auf der Ebene einzelner Anwendungen beschreibt die TI-Architektur:
-
in welchen Zonen sich die IT-Systeme einer Anwendung befinden,
-
welche Kommunikationsverbindungen und -protokolle sie zu welchen Nachbarsystemen benötigen,
-
ob eine Skalierung vorgesehen bzw. möglich ist und
-
welche Anforderungen an die Systemumgebung (z.B. ein Applikationsserver) bestehen.
Die konkrete Ausprägung der TI-Architektur wird im IsyFact Systemhandbuch (Vorlage) beschrieben. Abbildung 20 zeigt die TI-Architektur einer beispielhaften Geschäftsanwendung.
6. Betriebliche Aspekte
In diesem Abschnitt wird auf wichtige Aspekte des Betriebs einer Systemlandschaft eingegangen. Dazu gehören Verfügbarkeit, Ausfallsicherheit, Performance, Lastverteilung, Auslieferung, Installation, Versionswechsel, Monitoring und Datensicherung.
6.1. Verfügbarkeit und Ausfallsicherheit
Die Verfügbarkeit wird über einen Prozentwert gemessen, der unter Berücksichtigung von definierten Betriebs- und Wartungsfenstern angibt, wie ausfallsicher ein System sein soll und tatsächlich ist. Abbildung 21 gibt einen Überblick, was bei der Messung der Verfügbarkeit zu berücksichtigen ist.
Der Aufbau der Produktionsumgebung ist so zu gestalten, dass die angestrebte Verfügbarkeit erreicht werden kann.
| Dies kann beispielsweise eine Verfügbarkeit von 7x24 Stunden und eine auf den Monat berechnete Verfügbarkeit von über 99 % sein. Eine Beispielrechnung findet sich im Detailkonzept Service. |
In der Produktionsumgebung einer IsyFact-Systemlandschaft wird die geforderte Verfügbarkeit über das Mittel der Redundanz realisiert. Jede Komponente der technischen Infrastruktur ist mehrfach vorhanden. Bei einem Ausfall einer Komponente kann der Wirkbetrieb immer noch über die andere Komponente abgewickelt werden (Failover). Die Zustandslosigkeit der Applikationsserver (siehe Kapitel Die Software-Referenzarchitektur) unterstützt diese Redundanz und das Failover. Beim Ausfall eines Applikationsservers gehen die notwendigen Informationen, um den Betrieb über einen anderen Applikationsserver abzuwickeln, nicht verloren.
Neben der technischen Redundanz sollte auch eine räumliche Redundanz gegeben sein. Die Komponenten der technischen Infrastruktur sollten über mehrere Rechenzentren redundant verteilt sein. Dadurch ist die Verfügbarkeit auch in Katastrophen-Szenarien (z.B. einem Brand in einem Rechenzentrum) sichergestellt.
6.2. Performance
Ein weiterer wichtiger Aspekt der technischen Infrastruktur ist die Performance der IT-Systeme in einer IsyFact-Systemlandschaft. Auf der Ebene der technischen Infrastruktur wird die Performance vor allem durch die folgenden Aspekte limitiert:
Leistungsfähigkeit eines Serverknotens: Die Leistungsfähigkeit eines Serverknotens wird bestimmt durch seine Rechenleistung (Anzahl und Taktung der Prozessoren) und Größe des Hauptspeichers.
Netzwerk-Durchsatz: In einem verteilten System erfolgt die Verarbeitung von Informationen innerhalb einer Geschäftsfunktion meist durch die Zusammenarbeit von verschiedenen Knoten der Infrastruktur. Dazu müssen die Knoten miteinander kommunizieren. Ist die Obergrenze des Netzwerk-Durchsatzes erreicht, so führt dies zu einem Performance-Verlust.
Bringt ein IT-System einen Serverknoten an seine Leistungsgrenzen, so existieren grundsätzlich zwei Möglichkeiten der Skalierung: Horizontale Skalierung und Vertikale Skalierung.
Bei der vertikalen Skalierung wird die Hardware eines Serverknotens durch leistungsfähigere Hardware oder durch einen leistungsfähigeren Serverknoten ersetzt. Bei der horizontalen Skalierung werden zusätzliche Serverknoten eingesetzt, um die Last besser verteilen zu können. Vertikale Skalierung tritt im Laufe der Zeit von selbst auf – da die Entwicklung von leistungsfähigerer Hardware in kurzen Zyklen abläuft. Bei der Beschaffung eines Servers wurde das ursprüngliche Modell vom Hersteller häufig durch ein Leistungsfähigeres ersetzt. Im Rahmen des Prozesses der gezielten Erneuerung der Hardware (zum Beispiel alle fünf Jahre) bietet die Veränderung der Leistungsparameter dann in der Regel auch Chancen zur Konsolidierung (weniger Server), vorausgesetzt der Ressourcenbedarf der Anwendungen wächst nicht durch neue oder geänderte Anforderungen.
Voraussetzung für die Möglichkeit der horizontalen Skalierung ist eine Software-Architektur, bei der es keine Rolle spielt, welcher Serverknoten einen Verarbeitungsschritt durchführt. Die Referenzarchitektur unterstützt durch den zustandslosen Anwendungsserver den Ansatz der horizontalen Skalierung optimal. Sie bietet für die Zukunft maximale Flexibilität.
6.3. Lastverteilung
Für die horizontalen Skalierung und die Ausfallsicherheit wird eine Lastverteilung notwendig. Lastverteilung (engl. Loadbalancing) kann entweder durch dedizierte Hardware-Komponenten (Hardware-Lastverteilung) oder durch eine Software-Lösung (Software-Lastverteilung) implementiert werden.
In der Hardware-Lastverteilung werden die eingehenden Anfragen von einer Hardware-Komponente entgegengenommen. Diese Hardware-Komponente ist für die Verteilung der Anfragen auf die dahinterliegenden Server zuständig.
Analog arbeitet die Software-Lastverteilung. Hier übernimmt eine Software-Komponente wie z.B. ein Http-Server mit entsprechendem Plugin die Verteilung der Anfragen.
6.4. Auslieferung, Installation und Versionswechsel
Durch die Auslieferung und Installation einer neuen Version eines IT-Systems wird die Konfiguration der Systemlandschaft verändert. In diesem Abschnitt wird auf diese Aspekte eingegangen. Dazu werden zunächst die Begriffe Konfiguration und Auslieferung definiert. Im Anschluss daran werden die organisatorischen Verantwortlichkeiten betrachtet.
Konfiguration: Mit dem Begriff „Konfiguration“ wird die Betriebsumgebung zu einem bestimmten Zeitpunkt beschrieben. Alle Komponenten der Betriebsumgebung, das heißt Hardware-Komponenten, Systemsoftware-Komponenten, Anwendungssoftware-Komponenten und ihre Konfigurationsparameter haben eine Version. Eine Konfiguration beschreibt die Betriebsumgebung durch die Angabe der Versionen der einzelnen Komponenten zu einem Zeitpunkt. Wird an der Betriebsumgebung eine Änderung zum Beispiel durch Austausch einer Hardware-Komponente durchgeführt, dann erhält diese Hardware-Komponente eine neue Versionsnummer. Gleichzeitig hat sich die Konfiguration der Betriebsumgebung verändert und wird ebenfalls mit einer neuen Versionsnummer bezeichnet. Gleiches gilt, wenn sich zum Beispiel die Parameter eines Anwendungsservers ändern: Eine neue Version der Parameter liegt vor und damit liegt auch eine neue Konfiguration der Betriebsumgebung vor. Um nachvollziehen zu können, was sich wann warum geändert hat, ist es empfehlenswert, dass jede Veränderung an der Betriebsumgebung genehmigt und nachvollziehbar dokumentiert wird.
-
Auslieferung: Mit dem Begriff „Auslieferung“ wird die Übergabe von Liefergegenständen aus der Hoheit der Software-Entwicklung in die Hoheit des Betriebs bezeichnet. Dabei werden im allgemeinen Software, Parameter und eine Dokumentation ausgeliefert. Bei der Software wird eine ablauffähige Einheit (RPM-Paket) ausgeliefert. Dieses RPM-Paket wird durch das Installationsprogramm unter Angabe der Parameter installiert. Anschließend wird die installierte Software gemäß der in der Auslieferungsdokumentation angegebenen Parameter konfiguriert. Die Auslieferungsdokumentation besteht aus einem Releaseletter, einem Betriebshandbuch und ggf. einem Benutzerhandbuch. Im Releaseletter werden Inhalt und Version der Pakete in Form einer Stückliste beschrieben. Weiterhin wird beschrieben, welche bekannten Fehler und Probleme es mit diesem Paket gibt. Im Releaseletter sind auch die Installationsanleitung inklusive der Parameter der Installation und die Aufstellung der mit dem Release geschlossenen Fehler-Meldungen enthalten. Eine Auslieferung umfasst ebenfalls Ergänzungen und Anpassungen der betroffenen Betriebshandbücher.
Wie oben bereits erwähnt bezeichnet der Begriff Auslieferung einen Verantwortungsübergang zwischen zwei Organisationseinheiten. Die Entwicklung erstellt und testet die Software-Pakete und erzeugt die zugehörigen Dokumentationen. Der Betrieb übernimmt diese Artefakte. Für die Installation der Software ist der Betrieb verantwortlich. Insbesondere liegt die Sicherstellung der Rücksetzbarkeit nach einer fehlgeschlagenen Installation eines Pakets in der Verantwortung des Betriebs. Treten Fehler auf, so informiert der Betrieb die Entwicklung über ein geregeltes Verfahren über das Problem. Auf Anfrage des Betriebs unterstützt die Entwicklung direkt bei der Fehleranalyse. Der Betrieb ist auch für die Dokumentation der Konfigurationsänderungen durch die Installation der neuen Anwendungssoftware-Pakete zuständig.
6.5. Betriebsüberwachung
Um den Gesamt-Status eines Systems zu überwachen, sind die Überwachung der IT-Systeme sowie das Monitoring der Komponenten der technischen Infrastruktur notwendig. Auf die Überwachung der IT-Systeme wird im Dokument Konzept Überwachung im Detail eingegangen. Hier wird unter anderem festgelegt, welche Informationen ein nach der Referenzarchitektur erstelltes IT-System für die Überwachung mindestens bereitstellen muss. Hierfür wird das Framework Micrometer verwendet, das sich an eine Vielzahl gängiger Überwachungstools anbinden kann.
Zum Monitoring der technischen Infrastruktur können für das zentrale Überwachungstool verfügbare Client-Programme verwendet werden. Diese Programme ermitteln den Status und die Leistungsparameter (zum Beispiel CPU-Auslastung, Hauptspeicher-Auslastung, Netzwerk-Auslastung) eines Server-Knotens und senden diese Informationen an das zentrale Überwachungstool. Zusätzlich ist auch ein Betriebsmonitoring der Netzwerkkomponenten (Router, Switches und andere) notwendig.
Beim Über- oder Unterschreiten bestimmter Schwellwerte oder bei einem Totalausfall von Komponenten kann vom zentralen Überwachungstool ein Alarm ausgelöst und der zuständige Systembetreuer informiert werden. Es müssen Abhängigkeitsgrafen für die Rechnersysteme und Anwendungen erstellt werden, an Hand derer das zentrale Überwachungstool sinnvolle Alarmierungen vornehmen kann. Auch müssen darüber hinaus – am besten bereits während der Entwicklung – sicherheitskritische Ereignisse definiert werden, deren Auftreten explizit überwacht werden soll.
Aus Sicherheitsgründen kommunizieren die Client-Programme des zentralen Überwachungstools nicht direkt mit dem zentralen Überwachungstool, sondern mit einem Satelliten-System. Damit benötigt nicht jeder Server der Betriebsumgebung eine direkte Verbindung zum plattformübergreifenden zentralen Überwachungstool.
6.6. Daten und Datensicherungen
Die Datensicherung (Backup) für eine IsyFact-Systemlandschaft erfolgt durch den Betrieb. Bei der Datensicherung muss zwischen der Sicherung der Software inklusive der Konfigurationsdateien, der Sicherung der Logdateien und der Sicherung der Datenbank unterschieden werden.
6.6.1. Software und Konfigurationsdateien
Mit Ausnahme des Betriebssystems wird die Software selbst inklusive zugehöriger Konfigurationen über ein Konfigurationsmanagement verwaltet. Dieses hat nichts mit den Systemen zum Betrieb der Anwendungen zu tun und wird unabhängig betrieben und gesichert. Jeder Stand ist über das Konfigurationsmanagement vollständig reproduzierbar. Im Falle von Datenverlust können die Software-Pakete in den entsprechenden Versionen neu gebaut und neu installiert werden. Dies wird aber in der Regel nur dann notwendig, wenn auch die Systemsicherungen vom Verlust betroffen sind. Der Betrieb muss jedoch in der Lage sein, bei Ausfall eines Server-Knotens eine Neuinstallation in kurzer Zeit durchführen zu können (zum Beispiel durch Einspielen zuvor gesicherter Images).
6.6.2. Log-Dateien
Die verschiedenen Server der Betriebsumgebung schreiben Log-Dateien in das Dateisystem auf dem jeweiligen Server. Die Log-Dateien enthalten wichtige Informationen, um bei Problemen das Verhalten der Anwendung nachzuvollziehen oder Nachweise zu erbringen. Sie müssen daher gesichert werden. Gemäß einer Anforderung des Bundesamtes für Sicherheit in der Informationstechnik (BSI), die im behördlichen Umfeld verbindlich ist, müssen die Log-Dateien zentral gesichert werden.
Die Log-Dateien eines Servers werden regelmäßig von einem Scheduler-Job auf einen zentralen Log-Server transferiert, von wo aus sie gesichert werden. Der Betrieb ist für die Datensicherung der Log-Dateien verantwortlich. Durch die Vorgaben zum Logging wird sichergestellt, dass Log-Dateien zusammengeführt werden können, und dass der technische Ablauf auch über verschiedene Log-Dateien hinweg nachvollzogen werden kann. Die Grundidee dabei ist, dass alle Log-Dateien in einem einheitlichen Format vorliegen und zusätzlich jeder Anfrage an das Gesamtsystem eine Korrelations-ID zugeordnet wird, mit der sich zusammen gehörende Einträge unterschiedlicher Log-Files einander zuordnen lassen.
6.6.3. Datenbank
Die Geschäftsdaten aller Anwendungen einer IsyFact-Systemumgebung werden in relationalen Datenbanken gehalten. Der Verlust dieser Daten wäre mit erheblichem Schaden verbunden. Eine angemessene Datensicherung ist daher unerlässlich.
Da nur die Produktionsumgebung Echtdaten verarbeitet, beschränken wir uns nachfolgend auf die Datensicherung in der Produktionsumgebung. Die Sicherung der Daten in den anderen Systemumgebungen muss nicht regelmäßig erfolgen, sondern kann punktuell je nach Bedarf durchgeführt werden. Der durchgängige Einsatz eines Datenbanksystems vereinfacht dabei die Datensicherung. Neben den in der Datenbank gespeicherten Daten müssen auch andere Datenspeicher, wie z.B. die Sourcen bei der Datensicherung berücksichtigt werden.
Alle Geschäftsdaten werden redundant in Primär- und Standby-Datenbanken gehalten. Zu jeder Primärdatenbank wird mindestens eine Standby-Datenbank eingerichtet.
| Für besonders ausfallsichere Systeme wird ein Primär- und Sekundär-Datenbank-Cluster verwendet, z.B. ein Oracle RAC. |
Die Primärdaten werden in einem SAN in einem Rechenzentrum abgelegt, die Standby-Daten im besten Fall in einem SAN eines anderen Rechenzentrums. Fällt die Primärdatenbank aus, kann ihre Aufgabe von der Standby-Datenbank übernommen werden (Failover). Die Verfügbarkeit der Anwendungen wird dadurch deutlich erhöht, denn das Failover dauert nur Sekunden oder Minuten, während das Zurückspielen einer Datensicherung (Restore) in der Regel deutlich länger dauern wird. Ein Restore wird nur dann notwendig sein, wenn die Datenbestände aufgrund von Softwarefehlern oder menschlichem Versagen korrumpiert wurden. Ein Restore aufgrund von technischen Gründen ist sehr unwahrscheinlich. Auch ein Komplettausfall der Primärdatenbank ist durch den Einsatz eines über Rechenzentren verteilten Datenbank-Clusters sehr unwahrscheinlich.
Die Replikation der Daten aus den Primärdatenbanken in die Standby-Datenbanken erfolgt über die Weitergabe der ReDo-Informationen. Die Datensicherung auf Bänder erfolgt online ausschließlich auf den Standby-Datenbanken und belastet die Primärdatenbank nicht. Die Datensicherung der Produktionsdaten wird vom Betrieb durchgeführt und verantwortet.
7. Vereinfachte Varianten der Referenzarchitektur
In diesem Kapitel wird vorgestellt, wie sich die Referenzarchitektur der IsyFact in Anwendungsszenarien mit reduzierten Anforderungen nutzen lässt. Dazu wird zunächst motiviert, welche Szenarien das sind und warum eine Nutzung der IsyFact-Referenzarchitektur dort möglich ist. Anschließend werden die Vereinfachungen – der Verzicht auf einen SOA-Ansatz und eine vereinfachte TI-Architektur – vorgestellt. Danach wird kurz vorgestellt, wie eine vereinfachte Architekturform zu einer kompletten Plattform ausgebaut werden kann. Abschließend werden die Vereinfachungen am Beispiel von Kleinverfahren dargestellt.
7.1. Einführung
In der bisher vorgestellten Form ist die Referenzarchitektur für die Umsetzung großer Systemlandschaften ausgelegt, also für den Einsatz in großen Anwendungen mit hohem Funktionsumfang und hohen Anforderungen an Verfügbarkeit, Performance und Lastverhalten. Deshalb folgt sie einem serviceorientierten Plattformansatz. Bei geringeren Anforderungen an die Ausbaufähigkeit und geringeren nichtfunktionalen Anforderungen können hier Vereinfachungen vorgenommen werden, die im Folgenden dargestellt werden: Der Verzicht auf eine SOA-Plattform und eine vereinfachte technische Infrastruktur.
7.2. Vereinfachung durch Verzicht auf eine SOA-Plattform
Die vorgestellte Plattform-Architektur der IsyFact bietet verschiedene Vorteile:
-
Bereitstellen zentraler Services, z.B. der Druck auf einer Druckstraße oder alphanumerische Suche. Diese Services können einfach aus verschiedenen Anwendungen heraus genutzt werden. Sie werden oft durch Produkte umgesetzt und werden in der Regel als separate Prozesse betrieben. Hier vereinfacht die Referenzarchitektur die Nutzung dieser Services.
-
Nutzung zentraler Datenbestände, z. B. durch ein zentrales Schlüsselverzeichnis.
-
Bessere Handhabbarkeit der einzelnen Anwendungen: Die in den Anwendungen umgesetzte Fachlichkeit ist in der Regel sehr umfangreich. Daher bietet die Auflösung in Services ein wichtiges Mittel, um die Komplexität der einzelnen Systeme zu reduzieren und sie somit langfristig wartbar und veränderbar zu halten.
-
Flexibilität und Erweiterungsfähigkeit: Services einer Geschäftsanwendung können durch die serviceorientierte Architektur leicht in andere Geschäftsanwendungen eingebunden werden.
In einigen Fällen bestehen diese Anforderungen nicht, daher wäre dann der Aufbau und Betrieb einer SOA-Plattform nicht angemessen. In diesem Fall können Anwendungen auch in einer kompakten Form gebaut werden. Dies ist sinnvoll, wenn der Funktionsumfang der Anwendung beschränkt ist, keine zentralen Services oder Datenbestände genutzt werden sollen und keine größeren Erweiterungen in der Zukunft zu erwarten sind. Dieses Szenario ist in Abbildung 22 dargestellt.
Links ist eine typische Umsetzung einer Geschäftsanwendung in der IsyFact-Systemlandschaft zu sehen. Sie ist über ein Portal in eine Unternehmenslandschaft integriert, hat Außenschnittstellen zu anderen Organisationen, die über ein Service-Gateway angeboten werden und sie nutzen die zentralen Services „Output Management“, „Alphanumerisches Suchverfahren“ und das zentrale Schlüsselverzeichnis.
In der Mitte ist dargestellt, dass es Anwendungen gibt, die diese Anforderungen nicht haben:
-
Sie werden stand-alone genutzt und sind nicht in ein Portal integriert.
-
Sie haben keine externen Schnittstellen.
-
Sie greifen nicht auf zentrale Schlüsseldaten zu.
-
Sie benötigen kein alphanumerisches Suchverfahren.
-
Das Output Management wird lediglich dazu benötigt, PDF-Dokumente zu erzeugen. Ein Ausdruck über eine zentrale Druckstraße erfolgt nicht.
In einem solchen Fall kann eine kompakte Anwendung erstellt werden, die die Querschnittsanwendung „Output Management“ nicht via Service-Aufruf anspricht, sondern dieses als Bibliothek einbindet. Die Software-Referenzarchitektur der Anwendung (vgl. Kapitel Die Software-Referenzarchitektur) bleibt trotzdem unverändert.
7.3. Vereinfachungen in der technischen Infrastruktur
Die technische Infrastruktur kann an zwei Stellen vereinfacht werden. Zum einen ist es möglich, auf den Betrieb eines Clusters zu verzichten, zum anderen kann die Aufteilung in SAGA-konforme Zonen weggelassen werden. Dies wird im Folgenden ausgeführt.
7.3.1. Installation ohne Clustering
Bei geringeren nicht-funktionalen Anforderungen kann auch nur eine Anwendungsinstanz zum Einsatz kommen und kein Cluster für die Datenbank verwendet werden. Dies ist in Abbildung 23 dargestellt.
7.3.2. Verzicht auf das SAGA-Zonenmodell
Weiterhin sieht die Referenzarchitektur der technischen Infrastruktur ein Zonenmodell gemäß SAGA vor. Dieses Zonenmodell unterstützt eine klare Sicherheitsarchitektur und ist in Kapitel Die Referenzarchitektur der technischen Infrastruktur beschrieben. Durch die Aufteilung in Informations- & Dienstezone, Logik- & Verarbeitungszone sowie Datenzone sind die Grundlagen geschaffen, um z.B. E-Government-Anwendungen sicher betreiben zu können.
Der SAGA-Standard in der Version 4 gilt grundsätzlich für E-Government-Anwendungen. In anderen Bereichen wird der SAGA-Standard nur dann empfohlen, wenn die Kosten/Nutzen-Betrachtung positiv ausfällt. In den Situationen, wo dies nicht der Fall ist, steht damit der Architekt eines Systems vor der Entscheidung, eine andere Architektur für die technische Infrastruktur zu wählen. Die Referenzarchitekturen der IsyFact ermöglichen auch eine solche, nicht SAGA-konforme Umsetzung. Sinnvoll ist dies allerdings nur, wenn die Anwendung mit einer vereinfachten Software-Architektur konzipiert ist, d. h. wenn sie nicht als SOA-Plattform konzipiert ist.
Mögliche, alternative Architekturen für die technische Infrastruktur sind:
-
Stand-Alone-Anwendung auf einem Nutzerrechner: Hierbei wird die Anwendung wie jedes andere Programm auch lokal auf einem Rechner installiert.
-
Zentral auf einem nur intern zugreifbaren Server: Hier wird die Anwendung auf einem zentralen Server bereitgestellt, der z. B. nur für die Nutzer einer bestimmten Abteilung zugreifbar ist.
7.4. Erweiterungsmöglichkeiten einer vereinfachten Architektur
Wenn eine Anwendung nach einer vereinfachten Architektur entwickelt wurde, ist die Erweiterung zu einer SAGA-konformen, serviceorientierten Anwendung möglich, wenn vorher gewisse Randbedingungen beachtet wurden.
7.4.1. Installation innerhalb eines Clusters
Um eine Anwendung innerhalb eines Clusters von Anwendungsservern zu betreiben, ist es notwendig, den Bearbeitungszustand nicht im Hauptspeicher des Serverprozesses zu halten, sondern ihn bei jedem Request in der Datenbank zu persistieren. Dies ist in den GUI-Referenzarchitekturen der IsyFact vorgegeben, allerdings werden Verletzungen dieses Prinzips nicht auffallen, wenn man eine vereinfachte Anwendung auf nur einem Serverknoten betreibt. Daher ist vor dem Umzug auf einen Cluster die Anwendung durch geeignete Tests oder Code-Inspektionen zu überprüfen, ob konform zu den Vorgaben entwickelt wurde. Alternativ kann natürlich auch auf die Persistierung des Anwendungszustands verzichtet werden, wenn man bewusst auf die Installation in einem Cluster verzichten will.
7.4.2. Installation innerhalb einer SOA
Der Nutzung einer Anwendung innerhalb einer SOA ist problemlos möglich. Falls Services der Plattform genutzt werden sollen, können Aufrufe dieser Services ohne weitere Vorkehrungen implementiert werden. Genauso ist es möglich, innerhalb der Plattform Services anzubieten.
7.5. Anwendungsbeispiel: Kleinverfahren
Unter einem Kleinverfahren versteht man im öffentlichen Sektor Anwendungen, die nur geringe Anforderungen an nichtfunktionale Eigenschaften haben. Typisch für solche Anwendungen sind:
-
Sie werden in der Praxis oft durch Implementierungen auf Excel- oder Access-Basis umgesetzt.
-
Sie haben nur wenige Nutzer
-
Sie werden nur intern innerhalb einer Organisation genutzt.
-
Sie haben nur geringe Anforderungen an die Sicherheitsarchitektur.
-
Sie stehen von ihrer Funktionalität her für sich selbst und sind nicht Bestandteil einer Plattform.
Ein solches Kleinverfahren kann mit einer vereinfachten Architektur umgesetzt werden. Dies umfasst:
-
Verzicht auf die SOA-Plattform (Abschnitt Vereinfachung durch Verzicht auf eine SOA-Plattform)
-
Verzicht auf Clustering (Abschnitt Installation ohne Clustering)
-
Verzicht auf das SAGA-Zonenmodell (Abschnitt Verzicht auf das SAGA-Zonenmodell)
Diese Vereinfachungen sind für ein Kleinverfahren nicht zwingend, sondern sie dienen dazu, das Verfahren in einem angemessenen Kosten-Nutzen-Verhältnis zu erstellen. Falls die Kosten-Nutzen-Betrachtung es erlaubt, kann auf die Vereinfachungen natürlich auch verzichtet werden.