Zurück zum Blog

Bazar – Der etwas andere Marktplatz

Zurück zum Anfang

SOA für den Hausgebrauch

IT-Weisheit:
In der Implementierungsphase verursacht jede falsch oder nicht identifizierte Anforderung bereits sechsmal so hohe Kosten wie zu Projektbeginn.

SOA – der neue Slogan der IT, wunderbar! Alles wiederverwendbar, alles billig und fehlerfrei, beliebig zusammenstopfbar und mühelos an neue Wünsche anpassbar.

Fehlt nur noch der Gehirnscanner, dann ist die Wundertüte fertig.

Das Problem?

Was tun, wenn deine Software kein bisschen Ähnlichkeit mit einem Webservice hat? Wenn deine ganze Erfahrung bisher ohne JMS oder EBS auskommen musste?

Wie willst du dann deinen Job so tun, dass du dein alte Software auf SOA umstellst, ohne dir die neuen Wege vielleicht in J2EE (Framework von Sun^®) oder NET (von Microsoft^®) zu verbauen?

Ein Tipp bereits am Rande: Wer sich zwischen J2EE und NET nicht entscheiden mag, sollte MDA in Betracht ziehen. Warum? Weil MDA Generatoren verwendet, die aus den UML-Modellen Source-Code erzeugt und das ist sowohl für J2EE als auch für NET möglich.

Nun ja, aber was, wenn deine Software gar nichts mit beidem zu tun hat und deine Programmierer die notwendigen Sprachen schon gar nicht beherrschen? Outsourcen nach Indien? Und wie kontrollierst du selbst dann das Ergebnis? Und machst du dann alles alleine beim Kunden, ständig mit dem Handy am Ohr, um die indische Hotline für „dein“ Programm zu Hilfe zu rufen, weil’s wie immer nicht so geht, wie du es dir vorgestellt hast?

Nein, das Schöne an SOA ist, dass es modular ist – und damit auch modular einführbar. Keine Software, die sich verkauft, wird von heute auf morgen weggeworfen und um sie umzustricken, muss nicht sofort alles neu geschrieben werden. Am Anfang genügt eine Art von „Aufsatz“ (Wrapper) für die einzelnen Programme, eine gängige Art in der Informatik, sperrige Dinge ein bisschen aufzupeppen. Für SOA heißt das, dass die Programme dahingehend mit einer Schnittstelle versehen werden müssen, dass sie sich wie ein „Service“ gebärden.

Ein Service ist dabei tatsächlich nicht mehr als ein Programm, das sich auf Zuruf an die Arbeit macht, ohne zu fragen, wer denn da ruft – Hauptsache, das Losungswort war korrekt.

Und das wiederum heißt, dass SOA keinesfalls nur mit Webservices oder J2EE funktioniert – dort ist der Bedarf nur am augenfälligsten, doch mein Kernel hat ebenfalls deutliche SOA-Charakteristiken und stammte aus dem altmodischen monolithischen ERP-Bereich. Da er sich aber an der Notwendigkeit ausrichtete, leicht und einfach Änderungen und Ergänzungen zu ermöglichen, mussten die einzelnen Bausteine voneinander entkoppelt werden. Nur dann wirken sich Änderungen im einen Teil nicht sofort auf einen anderen Teil aus. „Hinge“-Technology ist auch ein passender Begriff aus der bildhaften englischen Sprache: Hinge = Scharnier, Gelenk ist dabei ein wirklich prächtiger Vergleich für die flexible und dennoch geführte Form einer Kraftübertragung.

Und das wiederum heißt, dass jede Software sich auf SOA umorientieren kann. Wenn, ja wenn du weißt, woran du dich orientieren sollst.

Hier aber sind die vielen Schriften nicht mehr so hilfreich, denn wenn es ans Programmieren geht, musst du es sehr genau verstanden haben, so klein und fein gehackt, dass du es in Programmcode zerstückeln kannst.

Aber alles der Reihe nach – zuerst also: Über was sprechen wir hier eigentlich?

Services.

Sehr vager Begriff – ein Ober im Restaurant bietet genauso einen Service an wie die Tankstelle gegenüber. Du musst nur sagen können, was du willst und die Rechnung begleichen, dann ist alles in bester Ordnung.

Das ist auch in der IT nicht anders, ob es sich nun um die Betreuung von Hardware handelt oder die Hilfe für Anwender, die irgendwelche Probleme haben oder eben auch um Programme auf dem Web, die sich um einen Einkaufskorb und dessen Bezahlung kümmern.

Der springende Punkt bei solchen „Services“ ist, dass sie offen feilgeboten werden für alle, die die Adresse oder Telefonnummer kennen. Genau dies sprechen die diversen Definitionen im SOA-Umfeld an.

SOA is based on a systems environment specifically architected to leverage freestanding units of functional code, each of which corresponds to a specific activity. An IT service in this respect is a self-describing software component that is accessible over a network and has a published interface. (“The Enterprise Services Bus Will Revolutionize Information Technology” s. Links)

Services sind „veröffentlichte Schnittstellen“, die einen „transparenten Zugang zu einer Funktionalität/Dienstleistung“ über ein Netzwerk anbieten.

Dabei kann ein einzelner Service beliebig viele Schnittstellen anbieten, um den „transparenten Zugang“ in einer Zeit unterschiedlichster Betriebssysteme und Software für möglichst viele Variationen zu ermöglichen. Weiter bedeutet „veröffentlicht“, dass es irgendwo Verzeichnisse über die Services geben muss – wie die Speisekarten des Obers oder die Anzeigetafel der Tankstelle -, die klar und deutlich die angebotene Dienstleistung beschreiben. Und natürlich müssen diese Verzeichnisse bequem zu finden sein – wie die Speisekarte oder die Anzeigetafel.

Der eindeutige Vorteil dieser freizügigen „Angebotsgestaltung“ ist ebenfalls aus dem Restaurantsbeispiel ableitbar:

Opaqueness: Die Dienstleistung und die Herstellung des Produkts sind sauber getrennt.

Dies hat als unschätzbare Folge, dass das Produkt ausgetauscht werden kann. Wenn die Küche keine Wiener Schnitzel mehr offerieren kann, dann kann entweder ein Rumpsteak angeboten werden oder – bei ganz kundenfreundlichen Restaurants – das Schnitzel sogar vom Konkurrenten besorgt werden, um den angebotenen Service liefern zu können.

Wer jemals programmiert hat, weiß, dass das bei Software keinesfalls die Regel ist. Um Änderungen oder Probleme mit einem Programm in den Griff zu kriegen, werden bis heute meistens die Programme geändert – und das kostet Zeit und Geld. Einfach einen Schalter umdrehen auf ein anderes Programm, ist hier schon lange der Traum. Kein Wunder also, dass alle Welt so begeistert von SOA ist.

Machen wir weiter: Nachdem wir die Bausteine der Service-orientierten Architektur, die Services mit dem dazugehörigen Verzeichnis, kennen gelernt haben, ist die nächste Frage sofort diejenige nach der „Architektur“.

Der einfachste Fall einer solchen SOA ist wieder schön am Beispiel des Obers zu sehen:

Wer etwas essen will, bewegt sich ins Restaurant, lässt sich vom Ober die Speisekarte bringen und sucht dort aus, was er möchte. Den Rest erledigt der Ober.

Auf dem Internet beispielsweise entspricht das Restaurant einem Browser und einer URL als Adresse, die eine Website mit Menüsteuerung, den „Ober mit der Speisekarte“, herbeiruft. Dass der einfache Klick auf einen Button (die „Bestellung“) die Webservices/Server-Applikationen (die „Küche“) dann zu hektischer Betriebsamkeit verleitet und alle möglichen Adapter („Dolmetscher“) für die verschiedenen Sprachen der hilfreichen Geister erforderlich sind...

braucht keinen Anwender („Gast“) zu interessieren.

Der einfachste Fall einer solchen Architektur ist also die Fliege:

Physik der Information, ISBN 3-935031-03-3,
Die Grundkonstruktion der Informationsverarbeitung: die Fliege, S. 208

„Das führt uns zu der Organisation von Informationsverarbeitung als arbeitsteilige Systeme, denn nur so lässt sich einerseits die Masse an externen Informationen, die durch die Verarbeitung geschleust werden kann, erhöhen und gleichzeitig die Machbarkeit dadurch sichern, dass die Belastung einzelner Systembestandteile in Grenzen gehalten wird: zur Fliege...

Der sensorische, auslegende Anteil ist derjenige, der Information von der Situation der Umwelt aufnimmt, aufbereitet und der Entscheidungsstelle zuführt, der motorische, ausführende Anteil ist der, der die eigenen Ressourcen aktiviert, um die Entscheidung dann auch in die Tat umzusetzen...

Sind auslegende und ausführende Teile identisch, wie es bei vielen menschlichen Organisationen der Fall ist, so reduziert sich die Fliegenform auf die bekannte Dreiecksform der Hierarchie: viele Mitarbeiter, ein paar leitende Angestellten und eine einzige Führung.“

Oder mit den Worten der Experten:

Eine SOA baut sich auf aus mehreren Lagen auf (multi-tiered architecture):

1) die Schicht der anfordernden Applikationen
2) eine Schnittstellenschicht
3) die Verzeichnisschicht
4) eine Adapterschicht
5) die eigentlichen Programme

Ganz in der Form der Fliege werden viele Anforderer über die Schnittstellenschicht auf eine einzige Entscheidungsebene geleitet, die dann die Entscheidung wieder über die Adapterschicht auf viele ausführende Organe weiterleitet.

Die Anforderer sind dabei diejenigen, die die Services benutzen möchten, und die ihre Anfragen „in ihrer Sprache“ stellen, also entsprechend ihrer Betriebssysteme, Client- oder Browserprogramme. Die Schnittstellenschicht empfängt diese Anfragen und übersetzt sie, sodass die Verzeichnisschicht etwas mit ihnen anfangen kann. Diese Entscheidungsstelle sucht nun den passenden Service zur Anfrage heraus, liefert ihm die mitgegebenen Informationen mit und lässt sie via Adapterschicht in die jeweilige „Sprache der Dienstprogramme“ übersetzen, die diesen Service dann tatsächlich auszuführen haben.

Um im Beispiel des Restaurants zu bleiben: sogar Touristen, die kein Deutsch verstehen, können von unserem Ober freundlich und korrekt bedient werden, wenn sein Assistent ihre Sprache übersetzen kann. Und dass das Küchenpersonal heutzutage oft ebenfalls die Landessprache kaum beherrscht, ist auch kein Thema, solange und soweit ihm in seiner eigenen Sprache erklärt werden kann, was gewünscht wird. Ähnlich geht es auch den bisherigen SOA-Strukturen: Viele Dienstprogramme stammen noch aus Zeiten, als „Client-Server“ noch ein Modewort war, verstehen also die „moderne Sprache“ ganz und gar nicht. Aber sie lassen sich in ihrer Sprache dazu überreden zu tun, was sie sollen und abzuliefern, was gewünscht wird – das reicht.

Stellt die Verzeichnisschicht auch die anfordernde Applikation und kann sie darüber hinaus auch die Services selbst ausführen, entfallen sowohl Schnittstellen- als auch Adapterschicht – und die Fliege wird richtig deutlich erkennbar:

viele Anforderer, eine Entscheidung, viele Dienstleistungen

So einfach ist also der einfachste Fall.

Doch unser Ober im Restaurant zeigte uns bereits eine Komplikation auf, die unser einfaches Geschäft vereiteln könnte: Die gewünschte Bestellung kann nicht geliefert werden. Da er die Gäste dann nicht einfach im Regen stehen lassen will, muss er ihnen das Problem mitteilen und am besten einen Ersatz vorschlagen, der ihnen entgegenkommt.

Genau das muss auch eine SOA können – gerade auf dem Internet gibt es immer wieder unvorhergesehene Störungen, sodass der gewünschte Dienst nicht ausgeführt werden kann. Dann muss nach Umleitungen gesucht werden oder, nach einer angemessenen Zeit, ein Fehler gemeldet werden, sodass die Anforderer wenigstens Bescheid wissen.

Und noch eine weitere Komplikation lässt sich in unserem Restaurant demonstrieren: Ärger. Ein paar randalierende Jugendliche dringen ins Lokal ein und pöbeln die Gäste an, ein Zechpreller versucht, heimlich zu entkommen oder ein paar Bauchladen-Unternehmer werden so aufdringlich, dass die Kunden entfliehen. Auch das Problem kennt das Internet nur zu gut: Viren, Hacker, Denial-Of-Access-Attacken, Betrugsmanöver, Schnüffelsoftware - alles wird geboten.

Unsere Struktur muss also nicht nur Anforderungen empfangen, mit den passenden Dienstleistern verknüpfen und das Ergebnis wieder zurückgeben können, sie muss auch, wenn möglich, Alternativen kennen und Fehlermeldungen weiterleiten können. Und zu guter Letzt muss überall noch der Sheriff aufpassen, dass nichts schief geht, nichts verloren geht und nichts in falsche Hände gerät.

Grundstruktur der SOA

Die folgende Grundstruktur einer SOA wurde am 26.10.2004 in einer Patentanmeldung vorgestellt, bei der ein Service „Universalfenster“ das zentrale Thema war. Dies erklärt die Gewichtung in der Ausführlichkeit der Beschreibung von Einzelfunktionalitäten und ist nicht dahingehend zu verstehen, dass diese Grundstruktur nur für einen solchen Dienst geeignet ist.

Die oberste Ebene der Hierarchie, der Wurzelknoten, ist das System:

System

• ImExport

• Änderungsdienst

• SystemBefehl

• Kommunikation

o Liste

o Inhalt

o Fenster-API

o Anwender

- Auswahl

- Meldung

- Rechte

- Sprache

- Selektion

- Vorlaufparameter

o Text

o Suche

- SuchAufbereitung

- SuchErgebnisse

- Suchkriterien

- Suchverfahren

- Datei

• Fortschreibung

• Vorbelegung

• Check

• Feldaufbau

• Feldaufbereitung

Die einzelnen Bestandteile weisen dabei folgendes Verhalten auf.

0) System = Basis für Ressourcen und Verarbeitung

Das System stellt die Grundlage der gesamten Architektur dar. Von der Anbindung an das Stromnetz zur Hardware (Computer, Monitor, Tastatur, Akku etc.), den Netzwerkverbindungen und den jeweiligen Betriebssystemen bis hin zu den Software-Produkten, die zur Interaktion aller beteiligten Einheiten erforderlich sind, wird die gesamte Infrastruktur als „System“ benötigt, um die Realisierung von Software zu ermöglichen. Diese Funktionen sind jedoch in aller Regel vor den ausführenden Subsystemen einer Software-Applikation verborgen.

Folgende Dienste des Systems müssen dagegen den Subsystemen offen zugänglich gemacht werden:

1) ImExport = Übertragung von „Inhalten“ an Ressourcen außerhalb des „Systems“

Diese Funktionalität ist für die Anbindung an externe Systeme mit den entsprechenden Sicherheitskontrollen beim Austausch von Inhalten zuständig. Die Anbindung hat dabei nicht nur als technische Schnittstelle zu funktionieren, sondern muss auch einen gezielten methodischen Zugriff für die jeweils erforderlichen Aufgaben zur Verfügung stellen wie beispielsweise bei einem Drucker die Schachtauswahl.

Externe Systeme können dabei neben Peripheriegeräten wie Drucker, Disketten oder CD/DVDs auch mobile Endgeräte am lokalen Netzwerk, virtuelle Netzwerke, die das Internet zur Kommunikation verwenden (VPN Virtual private networks), das Internet selbst oder angebundene Fremdsysteme sein.

Sicherheitsfunktionen drehen sich dabei um Firewall, Virenprüfung, Verschlüsselung, aber auch um Fehleraufspürung in übermittelten Daten.

2) Änderungsdienste = „SystemBefehle“ im Zusammenhang mit der „Fortschreibung“

Änderungsdienste beschäftigen sich insbesondere mit Überwachungsaufgaben für die Datenhaltung, deren Aufgabe die Aufbereitung, Prüfung und Speicherung von Inhalten in Dateien zur späteren Wiederverwendung ist. Änderungsdienste verfolgen diese Vorgänge, um sie nachvollziehbar und leichter auffindbar zu machen. So werden wichtige Veränderungen in den Dateien protokolliert, die Daten werden prioritätsgemäß archiviert, zur Kategorisierung und firmenweiten Navigation beschlagwortet und sie lassen sich über Kalenderfunktionen zu späteren Zeiten wieder zur Bearbeitung vorschlagen.

3) SystemBefehl = zur Verfügung gestellte „System“methoden

Da jegliche offen gelegte Schnittstelle des Systems letztendlich ein SystemBefehl ist, sind hier insbesondere solche Funktionalitäten angesprochen, die je nach Kontext und Berechtigung den angebundenen Komponentenprogrammen zur Verfügung stehen wie beispielsweise Kalenderfunktionen. Oft werden sie als Systembibliotheken oder –module bezeichnet.

4) Subsystem Kommunikation = Austausch von „Inhalten“ zur Verarbeitung innerhalb des „Systems“

Die Kommunikation dient der Gewährleistung der sicheren Interaktion der verschiedenen Komponenten im System. Interaktion bedeutet den ereignisgesteuerten Austausch von Nachrichten zwischen den verschiedenen Subsystemen und muss deshalb sowohl die Subsysteme als auch deren Schnittstellen kennen, um diese Nachrichten nicht nur korrekt weiterleiten zu können (dynamisches Routing), sondern auch sicherzustellen, dass diese Nachrichten tatsächlich ausgeführt werden (transactional guaranteed delivery).

Die Kenntnis über Subsysteme und deren Schnittstellen wird zumeist über Verzeichnisse (Repositories) gestellt.

Neben der Sicherung der Befehlsausführung ist es darüber hinaus in modernen Softwaresystemen üblich, proaktive Sicherungsstrategien anzubieten, um mögliche Fehlerquellen oder vorsätzliche Schäden frühzeitig zu erkennen und zu beheben.

Die oben genannten Systemfunktionen liegen als interne Basis jedem der Kommunikationsdienste zugrunde, die den Anwendungskomponenten wie dem Fenster zur Verfügung gestellt werden, sind aber für die Aufgabenstellung der Anforderer nicht von eigenständigem Interesse. Sie werden deshalb nach dem objektorientierten Prinzip vom „Verbergen von Ausführungsdetails“ als Blackbox gehandhabt. Folgende Dienste der Kommunikation müssen dagegen den Subsystemen offen zugänglich gemacht werden:

4,1) Liste = Normierung von „Inhalten“, vorgegeben von der jeweiligen Verarbeitung

Normierte Inhalte sind nicht frei wählbar, hängen deshalb immer von dem Subsystem ab, das sie verwendet. So stellt ein modernes System nicht nur verschiedene Sprachen, sondern immer auch Kalenderfunktionen zur Verfügung, die lokale und religiöse Vorgaben enthalten können, die das System dann beispielsweise Datei-Subsystemen für Plausibilitätsprüfungen (wie Feiertage) anbietet. Dateien dagegen können für die von ihnen bearbeiteten Inhalte ebenfalls Normierungen verlangen wie Ja/Nein-Felder, oder Felder, deren Werte von anderen abhängen.

Solche Abhängigkeiten können berechenbar sein, sie können jedoch auch auf anderen, dem System bekannten Dateien beruhen.

Listen sind, ähnlich wie Texte, ein Angebot des Systems, solche Normierungen in einfachen Standard-Dateien unterzubringen, da viele Programme Steuer- und Arbeitsdaten benötigen, die mehrfach verwendet werden müssen wie beispielsweise Länderkennzeichen. Doch nicht nur der Inhalt muss konsistent für alle Nutzerprogramme sein, auch die Darstellung von solchen Normierungen, um für die Anwender einen einheitlichen Eindruck (Look&Feel) zu gewährleisten.

Die Speicherung dieser Inhalte kann dabei im selben Datei-Subsystem erfolgen wie die Arbeitsdaten, muss es aber, ebenso wie bei den Texten, nicht notwendig tun.

4,2) Inhalt = für „Anwender“ und „System“ bedeutsamer Gegenstand der Verarbeitung

Inhalte sind alles, was sich speichern und dadurch auch transportieren lässt und was irgendeinen Nutzen bringt. Einfache normierte Inhalte werden über Listen abgearbeitet, sprachenabhängige über Texte, strukturierte Inhalte über Dateien, Inhalte, die auf Papier oder an sonstige Verwendungsstellen außerhalb des Systems gelangen müssen, werden über die ImExport-Funktionalität des Systems (Druck) behandelt und die Veränderung von Inhalten wird durch die Änderungsdienste beaufsichtigt.

Inhalte müssen deshalb vom Kommunikationssystem nicht nur ihrem Typ gemäß eingeordnet werden können, sie müssen auch unabhängig vom Typ übertragbar und abrufbar sein, um individuelle Interaktion zwischen Komponenten zu erlauben und somit übergreifende Prozesse zwischen einzelnen Subsystemen zu ermöglichen.

Auch die Änderungsdienste müssen bei Bedarf Inhalt ungeachtet seiner spezifischen Verarbeitung verfolgen und Sicherheitsfunktionen müssen erforderlichenfalls auf Inhalte ungeachtet ihrer späteren Verwendung zugreifen können, um Fehler oder vorsätzliche (interne) Schäden aufspüren zu können, die von Anwendern oder angebundenen Komponenten in das Gesamtsystem einfließen könnten.

4,3) Subsystem FensterAPI = Präsentation der bekannten Funktionen durch das „Fenster“

Das FensterAPI stellt den Zugang zum Fenster als Schnittstelle zwischen System und Anwendern dar.

Die genaue Konstruktion dieses Fensters ist für die Grundstruktur der SOA nicht weiter erforderlich. Wichtig ist nur, dass Fenster über eine definierte Schnittstelle mit dem System kommunizieren und welche Vorleistungen sie vom System erwarten dürfen.

4,4) Subsystem Anwender = Person mit „Rechten“ zur Steuerung des „Systems“

Das Anwender-Subsystem bindet Anforderer wie Menschen oder Fremdsysteme an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs (siehe unten).

4,5) Text = „SystemBefehle“, die Abhängigkeiten von „Sprache“ regeln

Die Textfunktionen dienen somit der Koordination, Verwaltung und Speicherung von Inhalten, die von Anwendern abhängen. Solche Abhängigkeiten (Lokalisierung) sind durch die Sprache oder Formatierungen von Zahlen oder Datumsangaben gegeben und müssen bei jeder Form von Präsentation gegenüber Anwendern berücksichtigt werden.

Texte werden in sehr vielen Komponenten genutzt und sind deshalb vom System anzubieten. Die Speicherung dieser Inhalte kann dabei im selben Datei-Subsystem erfolgen wie die Arbeitsdaten, muss es aber nicht.

4,6) Subsystem Suche = Zugriff auf „Inhalte“ durch die „Datei“ für das „Fenster“

Das Suche-Subsystem bindet Dateien an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs (siehe unten).

Für ein Fenster als Schnittstelle zu den Anwendern sind dabei folgende Aufgabengebiete der Kommunikation von speziellem Interesse:

4,4) Subsystem Anwender = Person mit „Rechten“ zur Steuerung des „Systems“

Das Anwender-Subsystem gewährleistet eine flexible Zugangsmöglichkeit für Menschen oder Fremdsysteme, die letztendlich wieder Zugänge für Menschen offerieren.

Ein solcher Zugang zeigt deutlich die zwei grundsätzlichen Problembereiche jeder Informationsverarbeitung, die auf der Natur der Information, gerichtete Wirkung zu sein, basieren: einerseits muss Information von Anwendern in das System integriert werden, andererseits muss Information an die Anwender geliefert werden.

Im ersten Fall muss der Informationsaustausch kontrolliert werden hinsichtlich der Anwender. Die von den Systemfunktionen ImExport bzw. Kommunikation geleisteten Dienste sind dabei hierarchisch vorgeschaltet, sodass die dem Subsystem Anwender überlassenen eingegangenen Information bereits korrekt aufbereitet und unter Sicherheitsaspekten unbedenklich sind.

Im zweiten Fall werden den Anwendern Informationen angeboten, die den Anforderungen der jeweiligen Anwender gemäß präsentiert werden müssen.

4,4,1) Auswahl = Ressource des „Systems“ zur Entscheidungsfindung durch die „Anwender“

Das System benötigt im Lauf seiner Verarbeitung Klarstellungen, für die es Informationen seitens der Anwender in einheitlicher Form anfordert. Auch die Präsentation der Auswahl hinsichtlich Lokalisierung und Text obliegt dieser Funktionalität, die anfordernden Subsysteme müssen deshalb nur die jeweiligen formalen Aspekte für die spezifische Auswahl zur Verfügung stellen. Die von den Anwendern empfangenen Informationen sind hinsichtlich Korrektheit der mitgegebenen formalen Aspekte zu berücksichtigen und im positiven Fall an die Verarbeitung weiterzureichen. Im negativen Fall erfolgt eine Meldung.

Plausibilitätsprüfungen der Inhalte müssen dagegen von den die Auswahl-Funktionalität anfordernden Subsystemen selbst durchgeführt werden.

4,4,2) Meldung = Übergabe von „Inhalten“ an die „Anwender“

Meldungen sind standardisierte Informationen des Systems an die Anwender, die für diese von Interesse sind, sie können Hinweise sein oder sich als Fehler bemerkbar machen. Die Präsentation der Meldung hinsichtlich Lokalisierung und Text obliegt dabei ebenfalls dieser Funktionalität, die anfordernden Subsysteme müssen deshalb nur die jeweiligen Schlüsselwerte für die spezifische Meldung zur Verfügung stellen.

4,4,3) Rechte = Umfang der „Kommunikation“

Anwender können zwar das System steuern, jedoch nicht in unbeschränktem Maß. Rechte regeln dabei nicht nur die Zugänge zu Funktionen, sondern auch zu Daten und sind deshalb Filter, die über jede Interaktion von Anwendern mit dem System gelegt werden. Bei modernen Systemen geschieht dies nicht nur bei der Prüfung der eingehenden Signale seitens der Anwenders, sondern bereits bei Angeboten an Anwender, da es psychologisch positiver ist, eine Verbot nicht offen zu legen, sodass Anwender nur das auswählen dürfen, was sie auch berechtigungsgemäß tatsächlich ausführen dürfen.

4,4,4) Sprache = „Kommunikations“mittel für „Anwender“

Das Aufgabengebiet „Sprache“ umfasst die Koordination, Verwaltung und Speicherung von denjenigen Steuerungselementen hinsichtlich der Präsentation von Inhalten für die Anwender (Lokalisierung), die dem System zur Verfügung stehen. Insbesondere regelt es die Umstellung aller zu präsentierenden Elemente auf die neuen Lokalisierungsgegebenheiten bei Sprach- oder Länderwechsel.

Seine Aufgabe ist letztendlich, das System für die Anwender nutzbar zu machen, denn Inhalte, die Anwendern angeboten werden, müssen von diesen verstanden werden können. Ihre Bedeutung (ihre Menge an Information) muss von ihnen aus den angebotenen Daten (Zuständen) korrekt reproduziert (interpretiert) werden, um Missverständnisse und damit Fehler zu vermeiden.

Sie sind also nicht nur aus der für das technische System nützlichen Struktur in eine Form zu bringen, die für die Gehirne menschlicher Anwender verarbeitbar ist wie Worte oder Bilder, sie sollten es auch in einer Weise tun, die diese Interpretationsarbeit möglichst einfach hält. Jede zusätzliche Arbeit, die Anwendern durch fehlende Übersetzung oder falsche Formatierung aufgebürdet wird, ist zusätzlicher Aufwand für ihre Gehirne und damit auch eine zusätzliche Fehlerquelle, ohne dass diese zusätzlich aufgebrachte Wirkung einen Nutzen hätte.

Die eigene Sprache (und Schrift) der Anwender ist dabei die bequemste Art, Worte verständlich zu machen, die eigenen Formatierungen von Tausendertrennungen lassen Zahlen leichter zugänglich werden und die korrekte Anordnung von Monat, Jahr und Tag hilft dabei, die richtige und rasche Erfassung der Zeitangabe zu fördern.

4,4,5) Selektion = Spezifizierung von „Suchkriterien“ durch die „Anwender“

Dieses Aufgabengebiet umfasst die Konservierung und Wiederauffindung des vom Anwender-Subsystem zu bearbeitenden Anteils an Selektionen (siehe Suche) zur späteren Verwendung durch dieselben Anwender, dieselbe Präsentationsumgebung (Fenster) und dieselben Daten.

4,4,6) Vorlaufparameter = Steuerparameter für die Verarbeitung (hier: des „Fensters“)

Der vom Anwender-Subsystem zu bearbeitende Anteil an den Vorlaufparametern ist die Speicherung und Wiederherstellung dieser Auswahl hinsichtlich der Einstellungen für globale Steuerungen der Verarbeitung (Customizing) im Falle, dass dieselben Anwender das System wieder benutzen. Dann ist eine erneute Anfrage nicht mehr erforderlich.

Für ein Fenster als Schnittstelle zu den Anwendern ist dabei nur der fensterspezifische Satz an Vorlaufparametern von Interesse wie beispielsweise (falls vom System angeboten) die Oberflächengestaltung.

4,6) Subsystem Suche = Zugriff auf „Inhalte“ durch die „Datei“ für das „Fenster“

Das Suche-Subsystem bindet Dateien an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs.

Gespeicherte Inhalte sind ohne Wert, solange sie nicht wieder aufgefunden werden können, um weiterer Verarbeitung zur Verfügung zu stehen. Das Subsystem Suche zeigt wieder deutlich die zwei grundsätzlichen Problembereiche jeder Informationsverarbeitung, die auf der Natur der Information, gerichtete Wirkung zu sein, basieren: einerseits muss Information abgegeben werden, andererseits muss Information in das System integriert werden. Im ersten Fall muss der Informationsaustausch kontrolliert werden hinsichtlich der Schnittstellen-Passgenauigkeit zum Datenträger-System, im zweiten Fall, muss der eingehende Datenstrom korrekt aufbereitet werden, um vom verarbeitenden System, ob Mensch oder Maschine, „verstanden“ zu werden, wobei Technik und Sicherheit wieder dem Kommunikationssubsystem und bei Bedarf dem ImExport-Dienst des Systems obliegen, die Berechtigung dagegen dem Anwender-Subsystem.

Auch hier gilt wie bei der Funktionalität „Fortschreibung“ der Datei, dass die Suche als Blackbox sowohl den Ort des Dateisystems als auch dessen Aufbau verbirgt.

4,6,1) SuchAufbereitung = Präsentation der „Suche“

Die vom Datenträger eingegangenen Ergebnisse einer Suche werden gemäß den Aufbereitungsvorschriften („Feldaufbereitung“) für die auf Fenstern, Drucken oder Ähnlichem benötigte Darstellung unter Berücksichtigung von „Sprache“-Diensten des Anwender-Subsystems aufgearbeitet. Auch Klartexte und normierte Werte („Listen“) für die anzuzeigenden Feldern werden über „Feldaufbau“ und „Feldaufbereitung“ der Datei sowie „Sprache“ inklusive „Text“ ermittelt und mitgeführt.

Dies erfolgt jedoch nicht nur für die reine Darstellung der Suchliste, sondern vorzugsweise auch so umfassend, dass das Fenster die vollständige Information über alle gefundenen Datensätze vorfindet, sodass keine weiteren Zugriffe des Fensters auf Datensätze und ihre Metadaten erforderlich sind.

4,6,2) SuchErgebnisse = Resultat der „Suche“

Diese Funktionalität nimmt die vom Datenträger-System übermittelten Ergebnisse über die Dateifunktion „Feldaufbau“ auf. Dies bedeutet, dass die den Suchkriterien entsprechenden Datensätze technisch insoweit überarbeitet sind, dass sie vom Kommunikationssystem übertragen werden können und die Form haben, die die Fortschreibungs-Funktionalität des Datei-Subsystems erfordert, um bei Bedarf eine korrekte Anpassung der gespeicherten Daten an die aktuellen Werte zu erzielen.

4,6,3) Suchkriterien = Einschränkung der „Suche“

Suchkriterien erlauben es, je nach Datenbanksystem und individueller Datei, Inhalte gezielt nach den Werten einzelner Bestandteile (Feldern) einzukreisen. Die erforderlichen Beschreibungen werden gemäß den Aufbereitungsvorschriften („Feldaufbereitung“) für die auf Fenstern, Drucken oder Ähnlichem benötigte Darstellung auch unter Berücksichtigung von „Sprache“-Diensten des Anwender-Subsystems aufgearbeitet. Klartexte und normierte Werte („Listen“) für die anzuzeigenden Feldern werden ebenfalls über „Feldaufbau“ und „Feldaufbereitung“ sowie „Sprache“ und „Text“ ermittelt und mitgeführt, sodass verwendende Subsysteme keinen weiteren Ermittlungsbedarf mehr im Zusammenhang mit diesen Daten haben.

4,6,4) Suchverfahren = verschiedene Formen der „Suche“

Je nach Datenbanksystem sind die Möglichkeiten, Suche durchzuführen, verschieden vielfältig, wobei es sich bei der angebotenen Funktionalität nicht um die technische Realisierung der Suche handelt, sondern um den Zugang für die anwendenden Subsysteme, um die Ausführung der technisch möglichen Datenbeschaffungsvorgänge mit den gewünschten Vorgaben zu initiieren.

4,6,5) Subsystem Datei = Ressource des „Systems“ zur Ansammlung von gleichartigen „Inhalten“

Eine Datei ist die koordinierte Konservierung von dauerhaften Inhalten zur späteren Wiederverwendung (Persistenz). Sie ist jedoch nicht nur der reine Datenspeicher, sondern auch das Managementsystem zu seiner Verwaltung. In modernen Systemen wird diese Funktion immer stärker von den Anwendungsprogrammen isoliert, um diese unabhängig von den Datenformaten und den technischen Ausführungen zu machen (Grundsatz der losen Kopplung). Die Basis-Architektur des Realisierungsbeispiels verwirklicht diesen Grundsatz durch metadatengesteuerte Objekte für den generalisierten Dateizugriff, wobei die dateispezifischen Elemente in eigenen ausführbaren Komponentenobjekten abgearbeitet werden. Als Teil der Metadaten versieht diese Kombination von dateitypspezifischen und dateiindividuellen Methoden den Gesamtkomplex einerseits mit einer einheitlichen Schnittstelle für den Datenzugriff und die -fortschreibung, andererseits mit den geforderten individuellen Charakteristik für Prüfung und Aufbereitung. Patent DE 69627522 T2 realisiert die isolierte Dateifunktionalität durch Schnittstellen (Front-End-Klassen), die die generalisierten Funktionalitäten analog dem Entwurfsmuster Facade sammeln und zu den jeweiligen tatsächlich betroffenen Objekten weiterleiten, und auch die diversen Java-Frameworks zur Datenhandhabung kapseln Datenzugriff und -fortschreibung in immer umfangreicherem Maße, wie die jüngste Entwicklung der SDO (Service Data Objects) demonstriert.

Die Funktionen einer Datei betreffen dabei die Strukturierung der Inhalte und deren Abhängigkeiten sowie die Speicherung und Wiederauffindung in zeitüberdauernden Medien. Wie beim Anwender-Subsystem gilt, dass die vorgeschalteten Systemfunktionen für die korrekte technische und unter Sicherheitsaspekten unbedenkliche Aufbereitung des Datenflusses gesorgt haben.

4,6,5,1) Fortschreibung = Änderung von „Inhalten“ in der „Datei“

Diese Funktionalität sorgt je nach Art und Mächtigkeit des dahinter stehenden Datenbank-Managementsystems für die Konsistenz der gespeicherten Daten mit ihrem Abbild im Anwendungssystem, das von den Anwendern manipuliert wurde.

Als Blackbox verbirgt sie sowohl den Ort des Dateisystems als auch dessen Aufbau. Ob die Datei also physikalisch im selben Rechnersystem vorhanden ist, im Netzwerk oder im Internet, ob sie kompakt oder verteilt ist, ob sie flach, relational oder objektorientiert ist, spielt für das Anwendungssystem keine Rolle, weil das Subsystem Datei dies über die Funktionalität „Fortschreibung“ abkapselt. Wie viele Arbeitsschritte dahinter stehen, ob Leitungen aufgebaut oder Filter benutzt werden müssen, ist interne Sache dieser Aufgabe und für die Handhabung durch anwendende Systeme ohne Belang. Auch die bei Bedarf von dieser Funktion aufgerufene Kennwortbestimmung durch den „Rechte“-Dienst des Anwendersystems sowie die Versendung von Daten, die durch die Exportfunktion und/oder die Kommunikation technisch und sicherheitsbezogen nachgearbeitet werden, liegen im Zuständigkeitsbereich dieser Funktion „Fortschreibung“ verborgen.

4,6,5,2) Vorbelegung = Unterlassungswerte für neue „Inhalte“

Neue Inhalte sind nicht immer vollständig bestimmt. Um fehlende Werte zu definieren, werden für jeden Typus von Inhalt Unterlassungswerte angegeben, die einen klaren Zustand des Inhalts gewährleisten. Dies können einfache Werte sein, aber auch ausgewählte Datensätze, die als besonders typisch gekennzeichnet wurden oder Berechnungsmethoden, mit denen die neuen Inhalte aus der aktuellen Situation bestimmt werden.

4,6,5,3) Check = Prüfung von „Inhalten“ durch die „Datei“

Die Inhalte werden dabei nicht nur auf Korrektheit hinsichtlich der eingegebenen Datenformate, sondern auch hinsichtlich der vorhandenen Abhängigkeiten wie Normierungen oder Berechnungen aus anderen Dateifeldern kontrolliert.

4,6,5,4) Feldaufbau = Struktur der „Datei“ in Felder

Da eine Datei gleichartige Inhalte verwaltet, kann sie diese nach deren Gleichartigkeit (Typ) katalogisieren. Lässt sich ein Inhalt zergliedern, so dienen Felder als diejenigen Dateielemente, die die einzelnen Bestandteile des Inhaltes aufnehmen.

Die Beschreibung dieser Bestandteile über Metadaten wie Feldtyp, Feldanordnung, Bereich der Feldwerte, Priorität der Feldwerte (Muss/Kannfelder), Normierung der Feldinhalte oder spezielle Prüfungsmethoden mit ihren Meldungen sind dabei erforderlich, um die gespeicherten Werte wieder zu den Inhalten mit Bedeutung zu machen, die der Datei übergeben wurden. Inhalt mit Bedeutung heißt dabei nichts anderes als Information (Zustände, verbunden durch regelmäßiges Verhalten), weshalb die gespeicherten Daten erneut in ihren Kontext von Abhängigkeiten und Methoden gestellt werden müssen, damit aus Daten Information wird (Interpretation).

Um Sprachenabhängigkeit zu gewährleisten, sind die Meldungen der Prüfungsmethoden gemäß der Meldungsschnittstelle des Anwender-Subsystems als Schlüsselwerte im Textsystem zu hinterlegen.

4,6,5,5) Feldaufbereitung = Präsentation von Feldern durch die „Datei“

Dieses Aufgabengebiet der Datei umfasst alle Funktionalitäten, die sich um die Präsentation der Felder dreht, wie die Anzeige/Verwaltbarkeit in Fenstern, Drucken, Editoren (Browsern), Export-Dateien oder Ähnlichem. Die Anzeige bzw. Verwaltbarkeit kann dabei noch in verschiedene Unterarten der jeweiligen Präsentationsobjekte gegliedert sein, die auch für das Anwender-Subsystem hinsichtlich der Berechtigungen maßgeblich sein können. Auch die Frage, ob die Werte von Sprache (Lokalisierung) abhängen, ist Bestandteil der Feldaufbereitung, da in solch einem Fall der endgültige Wert über die Anwenderschnittstelle „Sprache“ aufbereitet werden muss. Im Falle von Texten sind deshalb die Schlüsselwerte des Textsystems zu verwenden, die auf die jeweiligen Sprachausgaben und Versionen wie „de/Kurztext“ oder „de/Langtext“ verweisen.

Die ausführenden Services vom System angebotenen Schnittstellen sind deshalb:

ImExport (1), Änderungsdienste (2), SystemBefehle (3) und Kommunikation (4).

Kommunikation bietet weiterhin die Schnittstellen zu Anwendern (4,4), Suche (4,6) und dem Fenster-API (4,3) sowie zu Texten (4,5), Listen (4,1) und Inhalten (4,2). Die Anwenderschnittstelle (4,4) regelt Auswahlen (4,4,1), Meldungen (4,4,2), Rechte (4,4,3) und Sprache (4,4,4) sowie die Informationen über die Selektionen (4,4,5) und Vorlaufparameter (4,5,6), die Suche (4,6) bietet den flexiblen und kontrollierten Zugang zu den Dateien (4,6,5) mit der Prüfung von Inhalten (4,6,5,3), ihrem Aufbau (4,6,5,4), Unterlassungswerten (4,6,5,2) und der Präsentation (4,6,5,5) an sowie deren Speicherung (4,6,5,1). Die Suche (4,6) gliedert sich für das Fenster noch weiter auf in Suchkriterien (4,6,3), Suchverfahren (4,6,4), Suchergebnis (4,6,2) und Suchpräsentation (4,6,1).

Die Anordnung, die Suche vor die Datei zu schalten, begründet sich in der Tatsache, dass Suchen meist über mehrere Datenquellen hinweg erfolgen können.

Kommunikation – Rückgrat der SOA

Wie die Grundstruktur der SOA zeigt, ist Kommunikation eines der Top-Themen der Service-Orientierung. Bei genauerem Hinsehen ist es sogar das Top-Thema überhaupt.

Denn wenn das System auch fähig sein muss, mit der Außenwelt Inhalte auszutauschen oder das Schicksal dieser Inhalte im Auge zu behalten, wenn es auch diverse Möglichkeiten bieten muss, seine Kapazitäten zu nutzen, so ist das, was die Kommunikation zu leisten hat, letztendlich der Lebensnerv der gesamten Architektur.

Physik der Information, ISBN 3-935031-03-3,
Die Realität als Maßstab: Messen, Vergleichen, Speichern, S. 151

„Der Mechanismus nun, eine Gruppe aufzubauen und zu erhalten, ist immer Kommunikation, ob es nun ein Zellverband oder eine Dorfgemeinschaft ist. Und Kommunikation ist Informationsaustausch. Dieser Austausch erfolgt freilich immer gemäß den Richtlinien des eigenen Systems, sein Aufkommen steigt mit der inneren Bindung der Systembausteine, ihrer Anpassung aneinander und an die gemeinsame Aufgabe, und fällt mit ihrer Eigenständigkeit und Unabhängigkeit oder mit anderen Worten: Die „Verkehrsdichte“ der Kommunikation hängt von der Systemstruktur ab.

Warum?

Je unabhängiger ein Teil ist, umso mehr kann er aus eigener Kraft ein Problem bearbeiten, umso weniger Information muss er von außen aufnehmen, umso weniger Kommunikation ist mit anderen Systemelementen erforderlich – die umgekehrten Verhältnisse gelten für hoch integrierte Teile. Das wiederum heißt, dass die Kommunikationsrate beziehungsweise ihr Anstieg oder Abfall Schnittstellen erkennen lässt und damit einerseits die Grenzen der einzelnen Subsysteme untereinander als auch die des Gesamtsystems zur Außenwelt markiert.“

Und diese Gruppendynamik trifft längst nicht nur für Zellgemeinschaften oder Dörfer zu, sondern auch für „Programmgemeinschaften“, wie sie eine SOA zu regeln hat.

Sie muss nicht nur die Stimmen der einzelnen Akteuren des Spiels, einerseits die Programme oder Services und andererseits die Anwender, zu einem wohlklingenden Konzert vereinen, sie muss die gesamten verborgenen Fähigkeiten des gesamten Komplexes auch zur richtigen Zeit und am richtigen Ort einsetzen, wie da wären die verschiedenen Formen von Sicherheitsvorkehrungen oder Ausweichmöglichkeiten in Fehlerfällen oder einfach nur: den richtigen Service überhaupt finden zu können.

Aus Sicherheitsgründen gewinnt deshalb ein Subsystem der Kommunikation ständig an Ansehen: die Anwenderschnittstelle (4,4). Sie kontrolliert den Zugang und die Einflussmöglichkeiten von außerhalb des Systems und muss deshalb diese notwendige Offenheit nicht nur auf schädliche Eindringlinge hin überwachen, sondern auch auf die unterschiedlichen Befugnisse derjenigen, für die das System überhaupt zur Verfügung steht. Single sign-on und rollenbasierte Berechtigung sind hier die Stichworte.

Doch das ist nur die eine Seite der Medaille. Diese unterschiedlichen Befugnisse müssen nun jeden Befehl, jede Aufforderung der Anwender begleiten, denn der Service, der sie ausführen soll, muss wissen, inwieweit die Anwender überhaupt dürfen, was sie wollen. Und wenn sie dürfen, was sie wollen, muss das Ergebnis wieder an sie zurückgeliefert werden.

Alles eine Frage der Kommunikation.

Und der Sicherheit. Denn an jeder System-Schnittstelle kann ein Fehler lauern. Diese Fehler können von Viren oder Würmern stammen, die es durch die Sicherheitsbarrieren schafften, sie können von vorsätzlichen oder fahrlässigen Aktionen der eigenen Mitarbeiter hervorgerufen sein oder sie können einfach nur Software- oder Hardware-Defekten entspringen, die wertvolle Daten vernichten oder in unbefugte Hände gelangen lassen könnten. Deshalb ist letztendlich jeder Kommunikationsvorgang zu bewachen und je offener das System ist, umso durchgängiger muss die Bewachung werden.

Deshalb muss Kommunikation als eine einheitliche Aufgabe behandelt werden. Während früher so genannte Message brokers oder auch ETL-Produkte (extract/transform/load) dem Datenaustausch zwischen verschiedenen Programmen und Speichermedien genügten oder mehr oder minder spezielle BPM-Produkte zur Koordination von betriebswirtschaftlicher Software eingesetzt wurden, muss heute einen Schritt weitergegangen werden, nicht nur wegen der Frage der steigenden Sicherheitsbedürfnisse.

Welcher Schritt?

Die früheren Kommunikationssysteme waren einzelfallorientiert. „Für jedes Fällchen ein Ställchen“. Sie koordinierten zwar die Interaktion von Programmen, doch mussten sie diese Programme und ihr Zusammenwirken kennen oder wenigstens verstehen – und zwar zumeist in deren eigener Logik und Sprache.

Das kann sich die Kommunikationsschiene einer SOA nicht leisten. Sie kann nicht für jedes exotische Programm die exakte Ansprache kennen, also muss sie sich auf allgemeine Richtlinien zurückziehen – auf eine gemeinsame Sprache von Standards. Im Ausgleich für diesen „Rückzug“ kann sie dann jegliche alte und neue Applikation, die diese Standards kennt und sich in ihrem Mitgliederverzeichnis eintragen kann, bedienen.

Eine solche Kommunikationsschiene ist der ESB (Enterprise Service Bus, siehe Links): Er stammt aus der Java-Welt und beruht auf deren grundlegendem Kommunikationssystem JMS (Java Messaging Service), beherrscht somit neben direkten Benachrichtigungen auch die Behandlung von Anfragen (publish/subscribe). Der ESB ist weiterhin nicht nur in der Lage, Befehle aller Art zu erkennen und anzunehmen (event notification), er kann auch feststellen, wer sie ausführen soll und sie dementsprechend weiterleiten (dynamic routing) und last not least sorgt er auch dafür, dass der Befehl nicht irgendwo im Nirvana verschwindet, sondern garantiert dort ankommt, wo er hingeschickt wurde (guaranteed delivery). Und natürlich stellt er die „gemeinsame Sprache“, über die sich die unterschiedlichsten Anwendungen verständigen können.

Er bietet jedoch noch mehr: die Inhalts-Schnittstelle (4,2). Um Inhalte im System zu transportieren, arbeitet er mit einem Teilsystem (intelligent data fabric), das auf JCache basiert, um die Belastung durch den Datenverkehr verteilen zu können und bietet dabei mehrere Formen an, mit diesen Daten zu jonglieren. Neben der praktischen Eigenschaft, Daten im Zwischenspeicher (Cache) unabhängig von der eigentlichen Datenbank zu verarbeiten, können sie direkt abgerufen werden oder erst dann, wenn sie tatsächlich anfallen und „geordert“ wurden (publish/subscribe). Dafür benutzt der ESB ein interessantes „Topf“-Verfahren: Datenobjekte werden von Prozessen in diesen Topf gestellt, um von einem oder mehreren anderen entnommen oder auch nur gelesen zu werden, wobei diese Prozesse völlig unabhängig voneinander sein können. Nur die Art und der Inhalt des jeweiligen Datenobjektes entscheiden, wie und wer es verwenden kann. Da hier eine Kopplung der beteiligten Programme nur über diesen Datenpool erfolgt und sich der Client somit nur an den Anforderungen des Datentopfs ausrichten muss, nicht jedoch an denjenigen Programmen, die die Daten beschaffen oder verarbeiten, ist deren Unabhängigkeit nicht gefährdet – eine Grundvoraussetzung für eine SOA, die freilich auch anderen Virtualisierungsrealisierungen entgegenkommt: Stichworte sind distributed shared memory, generic clustering, parallel computing oder distributed workflow.

Doch das ist noch nicht alles. Der ESB sorgt natürlich auch für Sicherheit. Dafür bietet er die Möglichkeit, Sicherheitsrichtlinien (security polices) zu bestimmen, also zu sagen, welche Berechtigung für welche Ressource erforderlich ist und wie die Verarbeitungsprozesse zu laufen haben. Dabei lässt er einerseits die Überwachung (Monitoring) des gesamten Systems zu und bietet andererseits Optionen für automatische Reaktionen an, um Störfälle zu beheben oder auch nur den Arbeitsablauf zu optimieren. Aus der Überwachung lassen sich Statistiken über Vorkommnisse und Komponentenverhalten gewinnen, um Fehler zu bereinigen oder Engpässe zu beheben und es lassen sich Simulationen erstellen, wie sich das System unter geänderten Bedingungen verhalten würde. Die Optionen für automatische Reaktionen lassen über heuristische Analysen, dynamische Regeln oder flexiblen Workflow die automatische Verwaltung und Kontrolle der gesamten Abläufe zu und bieten damit auch die Möglichkeit, automatische Fehlerbehebungen durchzuführen oder Anwendungen zu optimieren.

Damit liefert der ESB die Voraussetzung dessen, was das Realtime Enterprise benötigt, um jederzeit die richtige Hard- und Software im richtigen Umfang zu nutzen: die Kenntnis, wo und wie ein benötigtes Element zu finden ist (location transparency, discovery), die Möglichkeit, es zu steuern (remote control) und die Datensammlung über Nutzung, Leistung und Probleme (resource usage, performance monitoring and alert notification).

Zentrale Komponenten des ESB sind deshalb:

• Router und Filter, um die Transportwege der Kommunikation zu stellen und entsprechend zu kontrollieren,

• das Management der Kommunikation,

• die Prüfung und Aufbereitung der übertragenen Inhalte

• Standards, um Inhalte entgegenzunehmen, Bridges, um zwischen verschiedenen Standards zu übersetzen sowie Adapter, um Individualprogrammierung in Standards zu übertragen.

Diese Virtualisierungsstrategie, über Standards und schnittstellenorientierte, einzelfallunabhängige Prozesse der Nachrichtenübertragung die Kommunikation zwischen weitgehend autarken Objekten zu regeln, verschafft dem System tatsächlich die gewünschte Interoperabilität zwischen grob granulierten Applikationen, die die Standards für ihre In- und Output-Vorgänge beherrschen. Der Bus funktioniert dabei sowohl als Transportmedium als auch als Aufbereitungskomponente, um die Inhalte je nach Anforderungen nicht zur zu befördern, sondern auch in geeigneter Form zur Weiterverarbeitung anzubieten.

Der ESB ist deshalb ein MOM, eine message-oriented middleware, die asynchrone Verarbeitung erlaubt, weil sich eine anfordernde Applikation nicht mehr direkt an die ausführende Applikation koppeln muss, sondern sie nur noch soweit kennen muss, um deren „richtige Adresse und Anschrift“ für die Nachricht verwenden zu können „Tu’ dies und das für mich“. Programme sind also in der Lage, wie über ein „Schwarzes Brett“ miteinander kommunizieren. Die meisten verfügbaren ESB-Lösungen bieten deshalb auch weitgehend die Funktionalitäten der JMS-basierten MOM-Technologie an, wobei besonders die asynchronen „store-and-forward“-Fähigkeiten zu betonen sind. Denn genau diese erlauben es, Nachrichten sozusagen auf der Kommunikationsschiene „ESB“ abzulegen, ohne dass die Anwendung, die die Nachricht versendet, sich um das weitere Vorgehen kümmern muss. Dass sie nicht in direktem Kontakt zum ausführenden Programm stehen muss, bedeutet schließlich nichts weiter, als dass sie an ganz anderen Orten und sogar zu anderen Zeiten aktiv sein kann als dasjenige, das die Nachricht erhalten soll und dass es sie auch nicht interessieren muss, ob und wie und wann die Nachricht ankommt und verarbeitet wird. Nur das, was der ESB am Schluss zurückliefert, geht sie noch etwas an und dass er etwas zurückliefert, darauf kann sie sich verlassen (guaranteed message delivery) – selbst wenn es die Fehlermeldung ist, dass die Nachrichtenversendung nicht funktionierte.

Genau diese Unabhängigkeit der Programme voneinander, diese lose Kopplung nur über die allgemeinen Fähigkeiten der Kommunikationsschiene sind Voraussetzung für eine SOA. Nur so können unterschiedlichste Programme in wechselseitige und vor allem veränderbare Zusammenarbeit treten.

Ein paar Hinweise zur Realisierung

Diese Unabhängigkeit, die die einzelnen Programme voneinander haben dürfen, erlaubt nun einen sehr pragmatischen Zugang zur Realisierung auch in vorhandenen Software-Systemen.

Denn obwohl die Grundlagen der SOA-Architektur nicht ohne weiteres aus den Altsystemen abgeleitet werden sollten, weil diese zumeist weder den modernen Anforderungen an Sicherheit noch an lose Kopplung genügen, so ist es doch nicht notwendig, die gesamte, möglicherweise Abertausende von Statements umfassenden Programme auf einen Schlag umzustellen.

Stichwort: non-invasive Service Enablement.

Der erste Schritt:

Non-invasive heißt dabei nichts weiter, als dass die Alt-Systeme (praktisch) nicht verändert werden müssen, weil sie über eine „Wrapper“-Technologie auf den neuen Stand gebracht werden. Und dies heißt nichts weiter, als dass eine Art von „Dolmetscher“-Programm vor das bisherige Programm geschaltet wird, das sowohl die alte Sprache spricht als auch die neuen Standards der SOA kennt und deshalb zwischen beiden vermitteln kann, ohne sich natürlich einzumischen. Weder dürfen Eingaben noch Ausgaben in ihrem Inhalt verändert werden – nur in der Form darf sich ein solches Dolmetscher-Programm austoben, die Funktionalität sollte es nicht verändern. Warum nicht praktischerweise einen Wrapper auch um neue Anforderungen ergänzen? Weil solche Zusatzkompetenz „eigenen“ Programmen vorbehalten bleiben sollte, wenn die Service-Orientierung ernst genommen wird, das heißt, wenn Funktionalität so sauber granuliert werden soll, dass sie als „eigenständiges Objekt“ je nach Bedarf zu größeren Funktionseinheiten zusammenkomponiert werden kann.

Als allererster Schritt zur Umstellung selbst der altertümlichsten Anwendungen genügt es deshalb bereits, zwischen seine eigenen, alten Programme solche Wrapper zu schalten.

Auf den ersten Blick ist dabei nichts gewonnen?

Doch.

Denn auch, wenn diese Wrapper nichts anderes tun, als alte Programme mit alten Programmen zu verknüpfen, stellen sie eine Schnittstelle dar.

Information wird immer wesentlich durch Anfangs- und Endzustände bestimmt, deshalb sind Schnittstellen so informativ für ein System. Sie zeigen den Fluss der Information auf, die Kommunikationswege und gewähren deshalb einen umfassenden Überblick über die gesamte bestehende Architektur.

Das ist aber nur der eine Vorteil.

Der andere ist oben bereits angesprochen worden, bei der „Neutralität“ der Wrapper. Sind nämlich neue Funktionen wünschenswert, so können sie nun bereits in der modernen Entwicklungsumgebung entwickelt werden und müssen nicht mehr im Altsystem integriert werden, das zumeist sehr viel umständlicher ist und darüber hinaus noch in Strukturen erstellt wurde, die weit vor der Objektorientierung programmiert wurden.

Und noch ein Vorteil weist ein solcher Wrapper-Übergang auf: das „Service Enablement“. Die Funktionen, die der Wrapper anfordern und entgegennehmen kann, können nun auch ganz anderen Software-Systemen zur Verfügung gestellt werden. Selbst wenn das Programm ein Spaghetti-Riese aus Assembler-Code wäre, könnte ein Wrapper, der imstande ist, mit ihm zu kommunizieren, seine Arbeit sogar auf dem Internet zur Verfügung stellen. Nicht, weil der Assembler-Gigant plötzlich modern geworden wäre, sondern einfach, weil der Wrapper das „Black-Box“-Prinzip realisiert, das die Ausführung des Befehls von seiner Verwendung trennt. Deshalb sollte der Wrapper auch so viele Standards (XML, WSDL, UDDI, SOAP) als möglich beherrschen, um mit soviel als möglich anderen Systemen in Verbindung treten zu können.

Gerade der letzte Vorteil zeigt jedoch, dass ein Fehler, der gerne von Programmierern alter Software gemacht wird, auf gar keinen Fall vorkommen darf: die „schnelle Anpassung“, das „kostenbeschränkte Denken“.

Was das heißt?

Die Standards, die als Kommunikationsbasis der neuen SOA ausgewählt wurden, müssen völlig unverändert verwendet werden. Und wenn es den einzelnen Programmierern zu umständlich scheint, weil sie „ja wissen, wo was steht und wie was aufgerufen werden kann“, dann dürfen diese Programmierer diesem Trieb unter keinen Umständen folgen, denn genau das ist es schließlich, was überwunden werden muss: der „Programmbaustein Mensch“, die Kopplung über die Köpfe der Menschen. Denn diese „Kopplung“ ist keinesfalls virtualisierbar und damit unmöglich als Bestandteil einer SOA verwendbar.

Wer eine SOA zumindest zukünftig anstrebt, muss somit das Prinzip der losen Kopplung vor das Prinzip „ich kann es doch schnell so mal machen“ stellen, denn nur die lose Kopplung erlaubt es, Programme auszutauschen, um im Fehlerfall einen Ersatz zu aktivieren oder im Falle von neuen Wünschen weitergehende Programme anzukoppeln. Und die lose Kopplung erfordert strikte Einhaltung von Standards, denn diese Standards enthalten selbst Information, eine Information, die bei der Verletzung der Standards, sprich der „Anpassung an Einzelfälle“, eben auch verloren geht.

Der zweite Schritt:

Die Übersicht über die gesamte vorhandene Software, die sich aus der reinen Existenz und Beschaffenheit der Wrapper ergibt, erlaubt es nun, das erste Verzeichnis der SOA anzulegen: welche Programme mit welchen Parametern über Wrapper zur Verfügung stehen.

Der dritte Schritt:

Ausgehend von diesem Verzeichnis der vorhandenen Programme und ihrer Fähigkeiten kann dann bestimmt werden, wo neue Funktionen untergebracht werden und es kann eine Zerlegung der Altprogramme in Angriff genommen werden, da diese selten in der fein granulierten Art konstruiert sind, die der Idealfall der SOA kennzeichnet.

Ein solcher Idealfall basiert auf einer Menge diverser, sehr grundlegender Funktionalitäten, die je nach Bedarf zu immer größeren, immer gröber granulierten Einheiten zusammengefügt werden können, um letztendlich eine hochkomplexe Anwendung zu ergeben, die dennoch sowohl übersichtlich als auch flexibel anpassbar ist.

Der letzte Schritt:

Sind die Altanwendungen in Verzeichnissen aufgeführt und in praktische Einheiten zerlegt, können sie eine nach dem anderen in die neue Entwicklungsumgebung übersetzt werden, da das Re-Engineering kleinerer Programmbausteine mit vorgegebenen Ein- und Ausgabeparameter eine machbare Aufgabe darstellt. Auch bei dieser „Übersetzung“ der Altprogramme sollte darauf geachtet werden, so fein granulierte Bestandteile als möglich zu erzeugen.

Die Entscheidung, was getrennt werden kann und was in einem Bauteil enthalten sein muss, wird dabei durch die Kommunikationsdichte geliefert: Brauchen Funktionalitäten sehr viel Interaktion mit anderen, so ist eine lose Kopplung nicht möglich. Damit ist ein Kommunikationsaustausch auf Nachrichtenebene ungeeignet, da er eine Unmenge an Nachrichteninhalt zur Bearbeitung mitführen müsste. Solche Funktionalitäten sollten also in einem gemeinsamen Service bearbeitet werden

Dabei ist jedoch die Frage negativ zu beantworten, dass diese Interaktion über Regeln erfolgen kann. Können nämlich Regeln verwendet werden, so kann die Identifizierung der verwendeten Regel als Nachricht dienen, solange sich die Regel die gesamte erforderliche Information selbst zusammentragen kann. Andererseits ist es für Programmierer, die es gewohnt sind, in Altsystemen zu arbeiten, gelegentlich schwierig, in Regeln zu denken, sodass es für sie einfacher werden kann, zuerst die Funktionalitäten in einen gemeinsamen Service auszulagern und sie erst später in Regeln und Basis-Objekte zu zerlegen. Auch hier ist also ein mehrstufiges, allmähliches Herangehen an die neue Architektur möglich.

Das sich durch diese Vorgehensweise ständig vertiefende Verständnis der Abläufe im Programmsystem erlaubt es nun auch, falls noch nicht vorhanden, eine geeignete Transaktionskontrolle (commit und rollback) einzuführen.

Erst in diesem vierten Schritt, bei dem nun die Legacy-Anwendungen langsam überwunden werden, kann die Frage nach der Verwendung längst erprobter Strategien und vorhandener Basislösungen von MOM oder Komponentensoftware berücksichtigt werden (Stichworte: MQSeries, CORBA, BEA Tuxedo, TIBCO, JMS), wobei die Erstellunge der Wrapper und die ersten kleineren Zusatzprogrammierungen längst als Gehversuche in der neuen Programmierumgebung gedient haben, sodass der Berg des neu zu Erlernenden nicht mehr ganz zu groß erscheint.

Auch der Problemkreis „Sicherheit“ muss nun unter modernen Gesichtspunkten überarbeitet werden. Zwar besitzen Altwendungen oft sehr tief greifende Berechtigungssysteme, doch sind diese in aller Regel nicht auf einen allgemeinen Datenaustausch ausgelegt, da die Daten innerhalb der Altanwendung auf wohlbekannten Pfaden transportiert werden und letztlich nur die Anbindung an Fremdsysteme berücksichtigt werden musste. Auch das Berechtigungssystem ist zumeist nur für die eigenen Bedürfnisse zugeschnitten.

Das moderne Konzept, das Berechtigungen an Personen bzw. die Rollen, die sie zu spielen haben, aufhängt und nicht an der Software, für die diese Berechtigungen gültig sein soll, muss deshalb als Architekturmerkmal behandelt werden, da ein „Single Sign-on“, wie er heutzutage über Portallösungen vorangetrieben wird, im Prinzip eine eigenständiger Service ist. Dieser Service ist nicht nur imstande, Benutzer zu erkennen und sie vorhandenen Berechtigungsschemata zuzuordnen, er muss auch die diversen benutzten Berechtigungsstrategien aller zur Verfügung stehenden Programme bedienen können.

Für eine Umstellung eines Altsystems heißt dies deshalb, dass die Berechtigung möglichst separiert werden sollte, zumal die Benutzerverwaltung nicht mehr Aufgabe des Altsystems sein sollte.

Im Auge zu behalten

Eclipse Pollinate: Das ist der Name eines neuen Open-Source-Projektes, das Eclipse erlauben soll, Apache Beehive zu nutzen, um service-orientierte und J2EE-basierte Anwendungen einfacher entwickeln zu können. (Quelle 31.01.2005)

Apache Beehive ist ein Open-Source-Framework für SOA auf Java-Basis, das den Anspruch stellt, einfach zu benutzen zu sein. (Quelle 31.01.2005)

Ein paar interessante Links zu diesem Thema

"Hinge" Technologies that Support Dynamic IT (Quelle 23.06.2004)

Service-Oriented Integration: An Evolutionary Step for IT - Start small, and experiment (Quelle 27.06.2004)

An Introduction to Service-oriented Integration (Quelle 20.06.2004)

ESB Technology & Innovation (Quelle 14.04.2004, 717 KB)

The Enterprise Services Bus Will Revolutionize Information Technology (Quelle 01.04.2004, 178 KB)

Ein paar Begriffsbestimmungen

MOM (message-oriented middleware): Ein Basisprogramm, das irgendwo zwischen Betriebssystem und den Anwendungsprogrammen angesiedelt ist und generelle Aufgaben für letztere übernimmt. Zu solchen generellen Aufgaben gehört immer auch Kommunikation und diese wird bei einem MOM über „Nachrichten“ (messages) ausgeführt. Nachrichten sind dabei nichts anderes als Daten, die einen „Befehl“, also eine Identifizierung einer Aktion, enthalten sowie die für deren Ausführung notwendigen Eingaben.

Doch Information ist nicht nur Zustand, sie ist vor allem Dynamik, das, was Zustände verändert, also muss jegliche Informationsverarbeitung imstande sein, genau das zu tun: Zustände zu verändern und zwar so, dass die Information nicht verloren geht. Jede Informationsverarbeitung muss also Prozesse, wiederholbare, identifizierbare Regelkreise, beherrschen. MOM tut dies auch und es steuert diese Prozesse über „Ereignisse“ (events) – genau wie im „echten Leben“ sind dies letztlich Vorkommnisse aus der „Welt da draußen“, außerhalb des Systems, die sich in Reaktionen des Systems niederschlagen. Events können also von Anwendern ausgelöst werden oder auch von Fremdsystemen, sie können wiederkehrend sein wie die tägliche Sicherung oder von besonderen Bedingungen abhängen wie ein kritischer Zustand, den das System schnellstmöglich bearbeiten muss. Die Kommunikationsvorgänge, die in solchen Fällen notwendig sind, um von den Events zu erfahren, die aktuellen Bedingungen für die Bearbeitung festzustellen und die notwendigen Komponenten zu aktivieren, können dabei synchron verlaufen, soll heißen, anfordernde und ausführende Stelle sind direkt aneinander gekoppelt, oder asynchron, soll heißen, dass die anfordernde Komponente ihren Bedarf und die Bedingungen an eine dritte Einheit sendet, dann aber den Fall vorläufig als „erledigt“ betrachtet, während diese dritte Einheit dafür sorgt, dass irgendwann und irgendwo die Anforderung bearbeitet wird, um dann irgendwann ein Ergebnis zurück an die anfordernde Komponente zu schicken.

Cache: Ein Zwischenspeicher, der dafür benutzt wird, Verarbeitungsschritte unabhängiger voneinander zu machen, da Verarbeitungsergebnisse in Datenform zeitweise „zwischengelagert“ werden können. Diese Technik ist deshalb auch dafür geeignet, arbeitsintensive Kommunikationsvorgänge wie umfangreichen Datentransfer über Netzwerke besser zu organisieren, sodass andere Vorgänge nicht behindert werden. JCache ist eine Variante aus dem Java-Sektor, die als Standard JSR-107 eine Schnittstelle für alle möglichen Datentransporte aus allen möglichen Quellsystemen bietet und mit einer solchen Zwischenspeicher-Strategie arbeitet.

Web service: Ein Web service ist ein Service, der internetfähig ist, soll heißen, dass er über eine URI (Uniform Resource Identity) aufgefunden werden kann und seine „veröffentlichten Schnittstellen“ und die „transparenten Zugänge“ zur seiner Funktionalität den Standards der üblichen Internetprotokolle genügen.

Framework: Als Frameworks wird üblicherweise eine Sammlung von Programmobjekten mit definierter Aufgabenverteilung bezeichnet, die als eine Art von „Musterlösung“ für ein bestimmtes Problemgebiet dienen und für die eigenen speziellen Bedürfnisse angepasst werden müssen. „Integration Frameworks“ sind solche „vorgefertigten Programmsysteme“, die als Aufgabe haben, zwischen den unterschiedlichsten Programmen zu übersetzen, um unabhängig von Betriebssystem oder Bauweise eine übergeordnete Zusammenarbeit zu gewährleisten. Dafür müssen sie wie jede Informationsverarbeitung dafür sorgen, dass Information nicht verloren geht, sie müssen die Daten, die sie erhalten, entsprechend den Anforderungen sowohl der auftraggebenden als auch der auftragnehmenden Programmteile aufbereiten (consistency of information). SOA’s sind ein Beispiel solcher „integration frameworks”, da sie erlauben, weitgehend autarke Objekte zu größeren Programmeinheiten zusammenzukoppeln, solange sie nur die SOA-bekannten Standards erfüllen.

Zurück zum Anfang

© bussole IV 2004 (außer Zitate)

Zurück zum Blog