Softwaretechnische Architektur: Inhalt

Die individuell erstellten Anwendungssysteme der Systemlandschaft müssen technisch gleichartig aufgebaut sein. Daher wird im Folgenden die Referenz-Architektur beschrieben, nach der diese Anwendungssysteme software-technisch in IT-Systeme umgesetzt werden.

In der Persistenzschicht ist alle Funktionalität enthalten, die zum Erzeugen, Suchen, Bearbeiten und Löschen von Datenobjekten benötigt wird. Der Datenzugriff auf das DBMS ist in dieser Schicht vollständig gekapselt. In Richtung Datenbank kommuniziert diese Schicht mittels JDBC und SQL, in Richtung des Anwendungskerns stellt die Schicht Geschäftsobjekte zur Verfügung. Die Persistenz nutzt dazu das Framework Hibernate über die Java Persistence API (JPA).

Der Anwendungskern umfasst die fachliche Logik zur Datenbearbeitung, die mit dem System realisiert werden soll. Dazu gehören zum Beispiel Datenvalidierungen oder Funktionen zum Verarbeiten von Geschäftsobjekten, die über den Datenzugriff geladen wurden.

Die Nutzungsschicht ist eine Erweiterung der klassischen Drei-Schichten Architektur, in der die dritte Schicht als GUI oder Präsentation bezeichnet wird. In der Referenzarchitektur für ein IT-System wird diese Schicht noch zusätzlich erweitert um Batch und Service.

Details zur Konstruktion eines IT-Systems werden im IsyFact Systementwurf festgelegt und für das jeweilige IT-System dokumentiert.

Für den Aufbau eines IT-Systems gelten einige übergreifende technische Regeln, die im Folgenden vorgestellt werden.

Strukturierung des IT-Systems: Aufgrund der durch die Fachlichkeit festgelegten Funktionalität können IT-Systeme sehr komplex werden. Um diese Komplexität beherrschen zu können, wird das IT-System in Komponenten zerlegt, die jeweils genau festgelegte Teilfunktionalitäten erfüllen. Damit die gesamte geforderte Funktionalität erreicht wird, müssen die einzelnen Komponenten miteinander kommunizieren und sich kennen. Dadurch entsteht ein Komponentengeflecht. Für die Verwaltung der Komponenten innerhalb des IT-Systems und deren Kopplung wird ein Framework verwendet. Details hierzu werden im Detailkonzept Komponente Anwendungskern festgelegt. Technisch lässt sich ein IT-System in Schichten unterteilen, fachlich in Teilanwendungen. Details hierzu werden in Kapitel Der Anwendungskern beschrieben.

Transaktionen: Veränderungen am Datenbestand gehören zur Kernaufgabe von Informationssystemen. Diese Veränderungen können jedoch nicht beliebig erfolgen – sie müssen gewisse Eigenschaften haben, damit die Datenbestände nicht an Qualität verlieren: Sie müssen atomar, konsistent, isoliert und dauerhaft sein. In der Fachliteratur sind diese Eigenschaften als ACID-Eigenschaften (atomicity, consistency, isolation, durability) bekannt.

Änderungen am Datenbestand können komplex sein, das heißt es können viele Informationen und Zusammenhänge von den Änderungen betroffen sein. Solche komplexen Änderungen werden vom Informationssystem meist in einzelne, einfache Änderungsschritte zerlegt. Damit die ACID-Eigenschaften der komplexen Änderung erhalten bleiben, muss das Informationssystem entweder alle Änderungsschritte ausführen oder keinen. Damit es dazu in der Lage ist, werden die Änderungsschritte zunächst zu einer logischen Einheit zusammengefasst – einer Transaktion.

Für die Referenzarchitektur wird festgelegt, dass die Nutzungsschicht für die Steuerung der Transaktionen zuständig ist. Der Anwendungskern selbst steuert in der Regel keine Transaktionen. Er bietet der nutzenden Schicht eine Schnittstelle zur Transaktionssteuerung an, d. h. der Anwendungskern wird durch die Nutzungsschicht gesteuert.

Zugriffe auf die Datenbank: Bei Zugriffen auf die Datenbank werden die Objekte des Anwendungskerns auf die relationalen Tabellenstrukturen der Datenbank abgebildet. Dabei müssen folgende Aufgaben erfüllt werden:

Caching: Anwendungsspezifische Caches sind mit Spring Cache Abstraction zu implementieren. Die Caching-Funktionalität wird so mit Spring Cache Abstraction und einem Caching Provider (z.B. EHCache) bereitgestellt. Spring Cache Abstraction bietet eine effiziente und flexible Möglichkeit Caching in Anwendungen zu implementieren. Weitere und detaillierte Informationen sind in der Spring Dokumentation einzusehen. Durch die Verwendung von Spring Cache Abstraction wird, z.B. über die Nutzung von Annotationen, das Hinzufügen von Caching zu bestehenden Methoden erleichtert. Der zugrundeliegende Code ist nicht wesentlich zu verändern. Mit dem abstrahierten Caching ist die Cache-Implementierung unabhängig von dem genutzten Cache-Provider. Die Wahl des Cache-Providers ist gemäß einer notwendigen Skalierung und betrieblichen Gegebenheiten abzustimmen. EHCache wird empfohlen (Vlg. Produktkatalog: Entwicklung). Für weitere Informationen zu EHCache sind in der EHCache Dokumentation einzusehen.

Der Anwendungskern ist der zentrale Baustein eines IT-Systems. Hier werden die fachlichen Funktionen der Anwendung realisiert.

Der Anwendungskern besteht aus zwei wesentlichen Bestandteilen: den Fachkomponenten und dem Anwendungskern-Framework. Weiterhin ist dort dargestellt, dass externe Services als Komponente in den Anwendungskern integriert sind. Diese drei Aspekte werden im Folgenden im Detail beschrieben.

Nicht Teil des Anwendungskerns sind spezielle Dialogabläufe, z.B. dialogspezifische Bearbeitungsverfahren wie die Anwenderführung über Wizards. Diese Prozesse, die nur durch einen einzigen Dialog genutzt werden, sind Teil der Schicht Nutzung. Der Anwendungskern stellt somit im Wesentlichen allgemein nutzbare Services zur Verfügung.

Fachkomponenten setzen die Anwendungskomponenten aus der fachlichen Architektur um. Sie bilden damit den Schnitt der Anwendungskomponenten in die technische Architektur ab. Fachkomponenten beinhalten möglichst wenig Technik und trennen so Anwendungslogik von Technologie.

Eine allgemeine Anwendung enthält die Fachkomponenten Erstellung, Teilnahme und Verwaltung.

Komponenten-Framework: Für querschnittliche Funktionalität innerhalb des Anwendungskerns wird das Spring-Framework genutzt. Hauptaufgabe des Frameworks ist es, die Komponenten zu konfigurieren und miteinander bekannt zu machen. Dadurch wird die Trennung zwischen Fachlichkeit und Technik verbessert. Beispiel für querschnittliche Funktionalität ist die deklarative Steuerung von Transaktionen.

Externe Services: Wenn der Anwendungskern fachliche Services benötigt, die von anderen IT-Systemen innerhalb der Plattform angeboten werden, so werden diese Services als Komponente im Anwendungskern abgebildet. Dadurch ist die Funktionalität sauber gekapselt, was die Wartbarkeit erhöht. Wenn der externe Service ausgetauscht werden soll, ist keine Änderung der gesamten Anwendung notwendig – es ist lediglich eine interne Änderung der externen Service-Komponente notwendig. Für andere fachliche Komponenten des Anwendungskerns ist nicht zu unterscheiden, ob es sich beim Aufruf einer Komponentenschnittstelle um eine in dieser Komponente implementierte Funktion oder um einen Serviceaufruf handelt. Komponenten, die externe Services kapseln, sind im Idealfall von außen nicht von fachlichen Komponenten des Anwendungskerns unterscheidbar. Diese Komponenten haben damit zwei Hauptaufgaben: Sie müssen die technischen Aspekte der Kommunikation umsetzen und sie müssen Schnittstellendaten und Exceptions der aufgerufenen Services in die Datenformate der Anwendung transformieren.

Weitere Details können dem Detailkonzept Komponente Anwendungskern entnommen werden.

In der Persistenz-Schicht sind die Fachkomponenten auch gemäß den Komponenten aus der fachlichen Architektur strukturiert. Die Komponenten des Anwendungskerns besitzen die Datenhoheit auf die Entitäten, die ihnen eindeutig zuzuordnen sind. Diese Entitäten stammen aus den korrespondierenden Komponenten in der Persistenz-Schicht. Nur die korrespondierende Anwendungskern-Komponente darf Änderungen an den entsprechenden persistenten Entitäten vornehmen.

Andernfalls ist nicht sichergestellt, dass andere Komponenten keine Änderungen an den persistenten Entitäten vornehmen. Für den Transfer über Komponentengrenzen hinweg - oder aus dem Anwendungskern hinaus - müssen alle Komponenten des Anwendungskerns die ihnen zugeordneten persistenten Entitäten auf Geschäftsobjekte abbilden. Wenn Entitäten von mehreren Komponenten genutzt werden und keiner einzelnen Komponente zugeordnet werden können, sollten sie in einem eigenen querschnittlichen Package abgelegt werden.

Bei grafischen Benutzeroberflächen (englisch: Graphical User Interface, GUI) gibt es eine Vielfalt unterschiedlichster Komplexitäten: von einfachen Stammdatensystemen über Dialogsysteme mit vielen einfachen Dialogen, die aber intensiv miteinander interagieren, bis zu Clients mit wenigen, aber sehr komplexen Dialogen. Eine gute Architektur muss für alle relevanten Varianten einen tragfähigen Rahmen schaffen.

Im Wesentlichen müssen innerhalb einer GUI verschiedene Aufgaben erledigt werden:

Vorgaben zur konkreten Bedienung sind im Bedienkonzept beschrieben.

Die Validierung auf GUI-Ebene ist optional. Sie wird empfohlen, wenn sie die Benutzererfahrung verbessert. Bei Syntaxfehlern kann die GUI beispielsweise einen Hinweis anzeigen, ohne den Server aufzurufen, wodurch Zeit gespart und die Leistung verbessert wird. Die Abwehr gegen Injection-Angriffen, beispielsweise Cross Site Scripting (XSS), wird in der GUI unabhängig davon dringend empfohlen.

Trotzdem darf sich der Anwendungskern niemals auf die syntaktische Validierung der GUI verlassen und auch potenziell schädliche Eingabewerte berücksichtigen. Die fachliche Validierung der Eingabewerte erfolgt ebenfalls im Anwendungskern, da es sich um Geschäftslogik handelt und oft Datenbankabfragen erforderlich sind.

Ein Batch realisiert eine eigenständige Verarbeitung ohne direkten Benutzereingriff während des Ablaufes. An einen Batch werden verschiedene Anforderungen gestellt: Ausführungszeitpunkt, Abhängigkeiten, Datenvolumen, ausgeführte Funktionalität, Eingaben, Ausgaben usw.

Aus Architektur-Sicht werden diese Anforderungen durch zwei Komponenten abgedeckt: den Batchrahmen und die Batchlogik.

Batchrahmen: Der Batchrahmen stellt die Schnittstelle für den Aufruf der Batchfunktionalität zur Verfügung. Er übernimmt auch die Transaktionssteuerung und die Steuerung für einen Restart.

Batchlogik: Die Batchlogik wird vom Batchrahmen aufgerufen, um die Funktionalität des Batchverarbeitungsprogramms zu aktivieren. Die Funktionalität, das heißt die fachliche Logik und die Arbeitsschritte eines Batches, werden als Anwendungsfälle erfasst. Wenn diese Anwendungsfälle auch von anderen Nutzern benötigt werden, dann sind sie im Anwendungskern implementiert.

Batches werden als eigener Prozess auf einem eigenen Server ausgeführt, das heißt sie laufen nicht in der virtuellen Maschine des Application Servers ab. Batches werden somit in einer eigenen Ablaufumgebung ausgeführt und greifen direkt auf die Datenbank oder auch auf Dateien zu. Die benötigte Funktionalität des Anwendungskerns wird dem Batch als Bibliothek zur Verfügung gestellt und nicht über einen Service-Aufruf genutzt. Der Grund für diese Entscheidung liegt in den Datenmengen, die normalerweise von einem Batch verarbeitet werden: Die Übermittlung dieser Datenmengen über eine remote genutzte Schnittstelle ist ein möglicher Flaschenhals in der Anwendung. Dieser Flaschenhals wird durch die Nutzung der Anwendungskernfunktionalität als Bibliothek vermieden.

Batch-Abläufe bestehen aus einem oder mehreren Batch-Schritten. Die einzelnen Batch-Schritte werden von einem Scheduler aufgerufen und zum vollständigen Batch-Ablauf verbunden. Ein Batch-Schritt wird von einem Programm implementiert, das mit entsprechenden Parametern vom Scheduler aufgerufen werden kann. Die hier beschrieben Batches sind genau diese Batch-Schritte.

Die Batch-Schritte haben eine genormte Schnittstelle für Aufruf und Rückgabewerte. Sie sind in der Regel restart-fähig. Es gibt einen Batch-Rahmen, der dies unterstützt.

Weiterführende technische Details zum Batch sind im Detailkonzept Komponente Batch enthalten.

Services des Anwendungskerns, die vom IT-System zur Verfügung gestellt werden sollen, werden durch die Komponenten von „Service“ innerhalb der Schicht „Nutzung“ angereichert und nach außen gegeben. Dabei können alle Funktionen des Anwendungskerns genutzt werden. Die Service-Komponenten werden entsprechend den Anwendungskern-Komponenten geschnitten, d.h. für jede Komponente des Kerns, die einen Service anbieten soll, wird eine eigene Service-Komponente implementiert. Service-Komponenten werden nicht mehrere Anwendungskern-Komponenten. Dies würde dem Gebot, in den Services keine Logik zu implementieren, widersprechen.

Der Aufbau der Komponente Service ist in Abbildung 4 dargestellt. Intern besteht die Komponente „Service“ aus zwei Teilen: dem Service-Framework und der Service-Logik.

Service-Framework: Das Service-Framework ist die Bezeichnung für die Technologie, mit der die Services des Anwendungskerns zur Verfügung gestellt werden.

In der Regel wird ein extern angebotener Service noch durch zusätzliche Daten oder Logik ergänzt. Diese werden in der Komponente Service-Logik implementiert.

Service-Logik: Die Service-Logik enthält Daten und Funktionalität, die für die Bereitstellung des Services relevant sind. Im Normalfall ist der Funktionsumfang der Komponente Service-Logik viel geringer als der Funktionsumfang der Entsprechungen im Anwendungskern. Dies liegt darin begründet, dass die Komponente Service-Logik die Funktionalität des Anwendungskerns nutzt, um den Service bereitzustellen. Die Kernfunktionalität des Services ist also im Anwendungskern implementiert. Die Schnittstelle zwischen den Komponenten „Service“ und „Anwendungskern“ ist daher eine interne Schnittstelle.

Weiterführende technische Details zu Services sind im Detailkonzept Komponente Service enthalten.

Neben der GUI, Services, Batch, Anwendungskern und Persistenzschicht benötigt ein IT-System mehrere querschnittliche Funktionalitäten. Diese querschnittlichen Funktionalitäten sind in jeweils eigenen Dokumenten beschrieben. Eine Übersicht dazu liefern die Beschreibungen der Bausteine der IsyFact-Standard sowie der IsyFact-Erweiterungen.