Aufgabe: Architekturmachbarkeitsstudie erstellen (SOA)
Diese Aufgabe definiert, wie eine Architekturmachbarkeitsstudie für eine SOA-Lösung basierend auf Architekturanforderungen und einem Risikoprofil entwickelt wird.
Disziplinen: Analyse und Design
Erweiterung: Architekturmachbarkeitsstudie erstellen
Zweck

Wenn es darum geht, synthetisch eine Musterlösung zu erstellen, die den kritischen Architekturanforderungen gerecht wird, kann dieses Muster in gewisser Weise beschränkt sein. Beispiele:

  • Die resultierende Lösung kann eine rein konzeptionelle Lösung sein.
  • Die resultierende Lösung illustriert möglicherweise nur einen kritischen Aspekt der Gesamtanforderungen.
Beziehungen
Hauptbeschreibung

Für die Architekturmachbarkeitsstudie werden vorrangig Eingaben von der Aufgabe Analyse vorhandener Assets verwendet. Berücksichtigt wird das Konzept Serviceportfolio, das von der Aktivität Servicespezifikation erstellen definiert wird.

  • Diese Aufgabe sollte parallel zu anderen Schritten ausgeführt werden, mit denen (während der Aktivität Servicespezifikation erstellen) Services identifiziert werden, die verfügbar gemacht werden sollen.
  • Die Transaktionen, die in Form von Komponenten verfügbar gemacht werden müssen, sind im Rahmen der Aufgabe Analyse vorhandener Assets zu identifizieren, aber auch im Kontext der Analyse vorhandener Assets als Gesamtprozess. Später werden sie dann während der Aktivität Servicespezifikation erstellen weiterentwickelt.
  • Elemente dieser Entscheidungen und Betrachtungen zur Architekturmachbarkeitsstudie haben einen direkten Bezug zu funktionalen und Operationsaspekten der Architektur.

Beim Umgang mit vorhandenen Anwendungen müssen außerdem die folgenden Punkte untersucht und berücksichtigt werden:

  • Ausnahmebehandlung: Es muss Klarheit über die Funktionsweise der modernen Ausnahmebehandlung bestehen. Wenn bei der Stapelverarbeitung eine Ausnahme eintritt, wird das Programm abgebrochen (abnormal beendet) und ein Kernspeicherauszug erstellt. Der Programmierer muss sich den Kernspeicherauszug ansehen und daraus ableiten, was zu tun ist. Möglicherweise ist das nicht akzeptabel. Es müsste ermittelt werden, welche Vorgehensweise notwendig ist, z. B. wie eine Integration in das Framework für Ausnahmebehandlung erfolgen kann.
  • Prozess- und Datenverteilung: Sie müssen untersuchen, wo die Daten und Prozesse ausgeführt werden. Auf einer Maschine ausgeführte CICS-Anwendungen können eine Anfrage an eine andere Maschine senden (was in CICS auch als Function Shipping bezeichnet wird) oder per Fernaufruf Daten auf einer anderen Maschine aufrufen. Eine direkte Verbindung zu einer fernen Maschine, auf der sich die Daten befinden oder der Prozess ausgeführt wird (über JDBC zur DB), könnte sich gegenüber dem indirekten Weg bei Verwendung eines Konnektors über JDBC zur DB als vorteilhafter erweisen.
  • Datenverfügbarkeit: Nehmen wir an, eine Kundendatei in VSAM erfordert ein Verwaltungsfenster von vier Stunden. In diesem Fall kann kein Kundendienst rund um die Uhr unterstützt werden. Es müsste über eine neue Speicherlösung nachgedacht werden.
  • Berechtigung/Authentifizierung: Bei vielen herkömmlichen Anwendungen sind die Berechtigungs- und Authentifizierungsverfahren im Anwendungscode enthalten. Dies würde eine Migration der Benutzerzugriffsverwaltung auf eine eingebundene verwaltete und von Best Practices unterstützte Umgebung erfordern.
  • Bereitstellungsverzug: Stapelverarbeitungsprogramme werden in der Regel einmal täglich in den Nachtstunden ausgeführt. Falls es erforderlich ist, ein solches Programm öfter auszuführen, muss das Terminplanungsprogramm modifiziert werden, um die Häufigkeit zu ändern.

Die obige Liste erhebt keinen Anspruch auf Vollständigkeit. Sie wird hier lediglich als Anleitung zur Verfügung gestellt.

Beispiel

Beim Beispiel der Autovermietung müssen für die Servicerealisierung die folgenden Anforderungen berücksichtigt werden:

  • Reibungslose Schnittstelle zwischen fernem Client/Server, Workstationanwendungen und den IMS-Großrechneranwendungen
  • Vermeidung des "Screen Scraping" aus Sicht der fernen Anwendung. Auf diese Weise wird verhindert, dass die Verarbeitung der fernen Anwendung geändert werden muss, nur weil eine Nachricht zu einer Anzeige hinzugefügt wurde oder ein Feld eine andere Position in einer Anzeige einnimmt.
  • Unterstützung für Ein- und Ausgabenachrichten von IMS-Anwendungen, die vordefiniert sind und ein festes Format haben
  • Die mit der Nachrichtenformatierung verbundene Verarbeitung muss für die IMS-Anwendung transparent sein. Auf diese Weise kann für das Entwickeln und Testen neuer ferner Anwendungen notwendige Zeit deutlich reduziert werden.
  • Unterstützung einer zeitnahen Integration neuer IMS-Anwendungsfeatures und neuer Datenfelder in ferne Systeme, was eine Verkürzung der für die funktionale Erweiterung vorhandener Systeme benötigten Zeit bedeutet

Elemente dieser Entscheidungen und Betrachtungen zur technischen Durchführbarkeit haben einen direkten Bezug zu funktionalen und Operationsaspekten der Architektur. Die folgende Strategie wurde gewählt, um den oben genannten Anforderungen gerecht zu werden:

  • Nachrichtenbroker/Integrationsbroker für die Formatierung von Nachrichten an und von IMS-Anwendungen. Der Nachrichtenbroker führt die folgenden Funktionen aus:
    • Neuformatierung ankommender Nachrichten (von XML in ein Format mit fester Länge). Die Nachrichten werden in ein vordefiniertes Format konvertiert, das von IMS-Großrechneranwendungen akzeptiert wird.
    • Neuformatierung der abgehenden IMS-Antwortnachrichten (vom Format mit fester Länge in XML). Die Nachrichten werden in ein IMF-Schlüsselwortformat konvertiert, damit sie von der ursprünglichen sendenden Anwendung verarbeitet werden können.
    • Abfragen einer ankommenden Nachricht, um festzustellen, ob sie ein IMS-Format hat. Dazu wird der Nachrichten-Header überprüft, der den Nutzdaten vorangestellt ist. Der Header hat ein positionsgebundenes Format und enthält mehrere wichtige Abschnitte mit wichtigen Informationen für eine korrekte IMF-Verarbeitung.
    • Routing und Transformation ausgehend vom Nachrichten-Header und vom IMS-Transaktionscode. Dieser IMS-Transaktionscode ist für die Ausführung der richtigen Transaktion innerhalb des IMS-Großrechnersystems erforderlich.
  • IMS MQ Bridge als Übertragungskanal zwischen dem Nachrichtenbroker und dem IMS-System

Durch die Verwendung des Nachrichten-/Integrationsbrokers entfällt weitgehend oder vollständig die Notwendigkeit, jede IMS-Anwendung an die Handhabung von Transaktionsanfragen von verschiedenen fernen Systemen anzupassen. Da die mit der Nachrichtenformatierung verbundene Verarbeitung für die IMS-Anwendung größtenteils transparent ist, kann die für das Entwickeln und Testen neuer ferner Anwendungen notwendige Zeit deutlich reduziert werden. Darüber hinaus stehen fernen Systemen neue IMS-Anwendungsfeatures und neue Datenfelder zeitnah zur Verfügung, was eine Verkürzung der für die funktionale Erweiterung vorhandener Systeme benötigten Zeit bedeutet. Diese Strategie resultiert in einer losen Verbindung von Anwendungen, einem der Kernprinzipien der SOA.

Schritte
Konstruktionsansatz festlegen

Wählen Sie die Techniken für die Konstruktion der Architekturmachbarkeitsstudie aus, z. B.:

  • Konzeptionelle Modellierung
  • 'Schnelle' Prototyperstellung
  • Simulation
  • Automatische Übersetzung der Spezifikationen in Code
  • 'Ausführbare' Spezifikationen
  • Konstruktion von so genannten 'Spikes' als Prototypen (vertikale Schnitte durch Schichten)

Der Softwarearchitekt muss sich Gedanken über diese Modelle machen können, wenn er im Problem- oder Lösungsraum etwas feststellt.

Assets und Technologien für Architekturmachbarkeitsstudie auswählen

Der Softwarearchitekt muss aus den Assets und Technologien, die mit der Aufgabe "Architekturanalyse" ermittelt wurden, die auswählen, die für die Konstruktion der Architekturmachbarkeitsstudie verwendet werden.

Architekturmachbarkeitsstudie erstellen

Unter Verwendung der für die Konstruktion ausgewählten Techniken erstellt der Softwarearchitekt die Architekturmachbarkeitsstudie. Er verwendet die ausgewählten Assets und Technologien, um dem Risikoprofil des Projekts entsprechend die architektonisch relevanten Anforderungen zu erfüllen, die in Standardanwendungsfallrealisierungen, dem Übersichtsdesign, Deployment-Modellen und dem Softwarearchitekturdokument erfasst wurden.



Weitere Informationen
Konzepte