-
Die Erfindung betrifft die Rechnerarchitektur
für den
Ablauf von Software Applikationen und vorzugsweise ein Verfahren
und ein System zur Steuerung und/oder Organisation eines Applikationsprozesses
in einem verteilten System mit mindestens einem Client und mindestens
einem Server, bei dem das System nach einem sogenannten Multi-Tier-Modell
organisiert ist und zumindest eine erste Präsentationsschicht, eine zweite
Schicht und eine dritte Datenschicht umfaßt.
-
Da die Entwicklung von Software grundsätzlich teuer
und schnellen Änderungen
unterworfen ist, sollte eine Architektur gewählt werden, die folgende Punkte
berücksichtigt:
- – eine
Modularisierung in Form von kleinen Software Komponenten unterstützt,
- – einfache
Kommunikation zwischen den Komponenten erlaubt,
- – Ausrichtung
an Industriestandards mit dem Ziel Drittsoftware mit verwenden zu
können,
- – Skalierung über eine
variable Anzahl von Rechnern nur mit Administrationsaufwand und
- – Anpassbarkeit
an spezifische Kundenprofile nur mit Administrationsaufwand ist
möglich,
- – Sicherstellung
der Funktion und Benutzbarkeit alten Codes und
- – Unterstützung eines
leistungsfähigen
Patching-Konzepts.
-
Deshalb sind bisher im Stand der
Technik Architekturen vorgeschlagen worden, die diese Punkte möglichst
weitgehend berücksichtigen.
-
Als ein älterer Ansatz ist hier die
reine Client Server Struktur zu nennen. Die Darstellungsschicht
stellt hier den Datenbank Client und die Datenschicht das Datenbank
Management System (DBMS) dar. Hier führte die Trennung (Modularisierung)
von Grafik und Datenverarbeitung dazu, dass in der Darstellungsebene
mit SQL Statements gearbeitet wird und in der Datenebene mit Hilfe
von Stored Procedures und Pass Through Techniken problemspezifischer
Code implementiert werden muss.
-
Obwohl dies sehr schnelle Lösungen erlaubt,
hat man bei Software Änderungen
viele verschiedene Orte in den Programm Sourcen, an denen die Konsequenzen
der Änderung
(sogenannte side effects) beachtet werden müssen. Dies erweist sich als
sehr fehleranfällig.
-
Als unvorteilhaft erweist es sich
in der Praxis nämlich,
daß die
jeweils miteinander kommunizierenden Prozesse von Client einerseits
und Server andererseits sehr viel voneinander wissen müssen, so
daß ein
problemloser Datentransfer ermöglicht
wird. Dies führt
nachteiligerweise wiederum zu einer hohen Anzahl von expliziten
Eingriffen bei Änderungen
oder Anpassungen etwa hinsichtlich der Gültigkeit oder Zugriffsrechten.
-
Die asynchrone Rückantwort für eine Datenbank Anfrage kann über in diesem
Modell nach dem Stand der Technik über eine Callback Schnittstelle
realisiert werden. Hierbei wird über
den client-seitigen Aufruf dem DBMS der Aufrufpunkt der Funktion
mitgegeben, die dann die Ergebnisse erhält. Vorher muss aber das DBMS dem
Aufrufer Informationen über
den Typ der erwarteten Callback Schnittstelle liefern. Als nachteilig
erweist es sich jedoch, dass das Einrichten einer Callback Funktion
einen erheblichen Aufwand darstellt, der dann anwächst, falls
es sich um eine verteilte Applikation handelt und Verweise bzw.
Pointer noch über
Rechnergrenzen hinweg verwaltet werden müssen.
-
Alle diese Probleme führten in
Stand der Technik zu einem weiteren Ansatz, dem Multi Tier Ansatz, der
es erlaubt auf Callbacks zu verzichten.
-
Eine Multi Tier Architektur enthält mindestens
3 Schichten (hier Tiers genannt):
- – eine erste
Schicht, die Darstellungs- bzw. Präsentationsschicht mit den Grafikkomponenten,
- – eine
zweite, mittlere Schicht (auch Middle Tier genannt) mit der Business
Logik und
- – eine
dritte Datenschicht mit den Datenbanken.
-
Die drei Schichten kommunizieren über Schnittstellen,
indem sie Aufrufe von "oben
nach unten" – also von
der ersten bis zur dritten Schicht – bearbeiten. Die jeweiligen
Rückantworten
werden nach Bearbeitung wieder als sogenannte Return Values von
unten nach oben weitergereicht.
-
Als problematisch hat es sich hier
erwiesen, daß der
aktive Teil des Prozesses der aufrufenden Komponente (ein sogenannter
Thread) der ersten Schicht so lange blockiert bleibt, bis das Ergebnis
aus der dritten Schicht, nämlich
meistens das Ergebnis einer Datenbankabfrage, vorliegt.
-
Hier werden alle Prozesse, die die
dritte Schicht betreffen, nämlich
Datenbank spezifischer Code, in die mittlere Schicht herausgezogen
und somit eine Entkopplung von dem DBMS zu erreichen.
-
Der Nachteil ist, dass Änderungen
beim Zugriff auf die Datenbank, nun in mehreren Komponenten vorgenommen
werden müssen.
-
Ein weiterer Ansatz für eine Betriebssystem
Architektur ist das theoretischen Arbeiten an der Carnegie Mellon
University entstammende MACH Modell. Dieses Modell basiert auf einem
Micro Kernel Ansatz und erfordert eine konsequente Client Server
Struktur. Dabei enthält
der Kernel bzw. Kern nur Clients, während die Peripherie die vollen
Dienstleistungen, also die Server umfaßt. Benötigt ein Server die Dienstleistung
eines anderen Servers, so sendet er eine Anfrage durch den Micro
Kernel.
-
Dieses Konzept wird für Betriebssysteme
und deren Prozesse, wie beispielsweise die Interprozess-Kommunikation
oder Dateiverwaltungs-Strategien eingesetzt. In Hinblick auf die
Organisation von Applikationsprozessen unterstützt es bislang allerdings nicht
die erforderliche Entkopplung zwischen den verschiedenen Schichten.
-
Zur Vermeidung der genannten Nachteile
und unter Beibehaltung der vorteilhaften und gewünschten Entkopplung der jeweiligen
Schichten des Multi-Tier-Modells, ist es wünschenswert, dieses insofern
weiter zu entwickeln, als daß die
mittlere Schicht über
gleichrangige Software Komponenten dezentral organisiert ist.
-
Aufgabe der Erfindung ist es deshalb,
eine Software Architektur für
einen Applikationsprozess zu schaffen, die die Vorteile des Multi-Tier-Konzeptes
und die des Micro Kernel-Prinzips
vereint.
-
Diese Aufgabe wird durch ein Verfahren
der eingangs genannte Art gelöst,
bei dem die zweite Schicht vorzugsweise zumindest einen Server umfaßt und vollständig als
microkernel-basiertes Client/Server-System organisiert ist und bei
dem zwischen der ersten und zweiten Schicht eine Schnittstelle in
Form einer Message festgelegt ist, wobei ein Serverauftrag zumindest
folgende Schritte umfaßt:
- – der
Client übersetzt
den Serverauftrag in eine Message mit den jeweiligen Argumenten,
- – der
Client sendet die Message an den Server vorzugsweise aus der mittleren
Schicht,
- – der
Auftrag wird gegebenenfalls weitergeleitet und vollständig abgearbeitet
und
- – das
Ergebnis des Auftrages wird anhand der Message zurückgesendet.
-
Weiterhin wird diese Aufgabe gelöst durch
ein Client/Server-System nach Anspruch 18, ein Computerprogramm
gemäß Anspruch
19, ein Computerprogrammprodukt gemäß Anspruch 20 und eine Vorrichtung nach
Anspruch 21.
-
Entsprechend der erfindungsgemäßen Struktur
ist die zweite Schicht bzw. das Middle-Tier ausschließlich für ein Routing
des Serverauftrages ausgelegt und benötigt kein clientspezifisches
Wissen.
-
Der Serverauftrag, der im allgemeinen
in einer Anfrage (an eine Datenbank) und in einer Antwort (Ergebnis
der Datenbank Query) besteht ist erfindungsgemäß in eine "Frage-Transaktion" – ausgehend
von dem Client an den Server – und
in eine "Antwort-Transaktion" – ausgehend von dem Server
an den Client – zerlegt. Diese
sind physikalisch voneinander entkoppelt, so dass die Messages vollständig asynchron
zueinander gehalten werden.
-
In einer bevorzugten Ausführungsform
der Erfindung gehört
der Client der ersten Schicht und der Server der zweiten und/oder
dritten Schicht an.
-
Der Server liefert nach Abarbeitung
des Auftrages ein Ergebnis des Auftrages an den aufrufenden Client
oder eine andere Zieladresse.
-
Dabei ist die Rücksendeadresse des Serverauftrages
in der Message enthalten.
-
Erfindungsgemäß wird das Middle-Tier vollständig im
Micro Kernel realisiert. Die Server realisieren alle Dienstleistungen
des Systems.
-
Die Message eines Clients aus der
ersten Schicht wird stets unmittelbar an eine Wurzelkomponente des
Micro Kernels der zweiten Schicht gesendet, der die Message dann
an eine Verarbeitungskomponente weiterleitet.
-
Bevorzugterweise umfaßt der Micro
Kernel der zweiten Schicht mehrere Subsysteme, die ihrereits in eine
oder mehrere Komponenten aufgeteilt sind. Dies führt vorteilhafterweise zu einem
hohen Grad an Modularität
und macht das System insofern flexibel, da die Dienstleistung eines
Servers auf mehrere Komponenten aufgeteilt werden kann, ohne daß der Verwaltungsaufwand
hinsichtlich der Adressen steigt.
-
Ein wesentlicher Vorteil ist auch
darin zu sehen, daß Dienstleistungen
bzw. Dienstleisungsserver auch während
des Betriebs entfernt, verändert
oder hinzugefügt
werden können
und daß alter
Applikations-Code ohne Einschränkungen
in das System eingebunden werden kann.
-
Ein Vorteil liegt in der transparenten
Inter Modul Kommunikation. Durch das erfindungsgemäße Festlegen
einer Schnittstelle, muß sich
beispielsweise ein beteiligter Entwickler nicht um die Kommunikation
mit anderen Modulen kümmern.
Die einzige übergreifende
Plattform ist die Spezifikation der Messages. Diese ist umgangssprachlich
orientiert und verlangt kein zusätzliches
Wissen.
-
Ein wichtiger Punkt ist die Nutzung
aller Vorteile der Asynchronität
bei der Kommunikation untereinander, ohne auf Callbacks zurückgreifen
zu müssen.
Sie stellen einen fehlerträchtigen
Bereich dar, der dann auch immer nur mit tiefem Wissen und komplizierten
Entwicklungswerkzeugen bearbeitet werden kann.
-
Bedingt durch die Asynchronität der Messages,
sind viele Message Passing Aktionen gleichzeitig möglich, um
die Reaktivität
des Systems zu erhöhen.
Dies führt
aber zum gleichzei tigen Aufruf der Komponenten durch verschiedene
Threads. Diese müssen
im Normalfall synchronisiert werden.
-
Da in den Komponenten der zweiten
Schicht bzw. in den sogenannten Business Logik Komponenten nur eine
lesende Anfrage bei der Datenbank, der sogenannte Routing Datenbank,
und das Umkopieren der Argumente durchgeführt wird, ist in diesem Fall
keine Thread Synchronisierung nötig.
Es werden nur funktionslokale Daten verwendet, die zu einem Thread
Kontext gehören.
Dies erlaubt in Windows-basierten Systemen den Einsatz von COM Objekten
im Multi Threaded Apartement (MTA).
-
Durch das Festlegen des Message-Ziels
schon im sendenden Dienstleistungsserver, ist keine weitere Stelle
mehr involviert, was die Zielplanung anbetrifft. Es ist von jedem
Server aus möglich
eine Kommunikation zwischen zwei anderen Server auszulösen, da
diese Informationen mit der Message transparent durch das System
kopiert werden.
-
Durch das späte Routing wird die Verteilbarkeit
und Skalierbarkeit der Multi Tier und Micro Kernel Ansätze verbessert.
Es ist Administratoren ohne Kenntnisse des Innenlebens der Dienstleistungsserver
jederzeit möglich,
die Verteilung der Komponenten über
verschiedene Server zu verändern.
-
Ein weiterer Vorteil des Message-Pfades,
liegt in dem potentiellen Einsatz identischer Befehle für unterschiedliche
Dienstleistungsserver oder mit unterschiedlichen Datenfeldern.
-
Mit der Zeit können neue Dienstleistungsserver
hinzukommen. Diese können
dann über
die existierende Infrastruktur alle Dienstleistungen der anderen
Server nutzen, ohne dass die Entwickler im Detail die Sourcetexte
kennen müssen.
Mit Anwendung der existierenden Messages, passen sie die Neuerungen
nahtlos ins Gesamtsystem ein.
-
Die verbindliche Interface Spezifikation
in Form einer Message ist in einer bevorzugten Ausführungsform
der Erfin dung vom Typ "String" und wird durch die
Argumente der Funktionen der Interfaces weitergegeben. Eine Message
wird immer übergeben,
in dem die entsprechenden Argumente der Funktion des aufgerufenen
Interfaces vom Aufrufer versorgt werden. Dadurch ist aus der Sicht
des Aufrufers das Message-Passing vollständig durchgeführt und
abgeschlossen.
-
Der Inhalt der Messages ist Gegenstand
der Spezifikation der jeweiligen Applikation. Diese muss aber nicht
nur den Inhalt des Befehls und des Datenfeldes festlegen, sondern
auch deren Syntax beschreiben. In dieser Ausführungsform hat die Message
folgende Struktur:
"Kategorie+Subsystem+Befehlsgruppe+Befehl+Zeitstempel+Steuerfeld+
Ursprung+Quellname+Zielname+Nutzdaten"
-
Jeder String, getrennt durch das
Pluszeichen, ist ein eigenes Argument der Interface-Funktionen.
So ist gewährleistet,
dass sich die Stringmanipulationen zum Gewinnen der Informationen
auf ein Minimum reduzieren.
-
Weitere Vorteile, Merkmale und alternative,
nicht einschränkend
zu verstehende Ausführungsformen der
Erfindung sind in der nachfolgenden, detaillierten Figurenbeschreibung
zu finden, die in Zusammenhang mit der Zeichnung zu lesen ist und
in der:
-
1 eine
schematische Darstellung einer bekannten Multi Tier Architektur
aus dem Stand der Technik,
-
2 eine
schematische Darstellung von verschiedenen Komponenten einer zweiten
Schicht eines erfindungsgemäßen Micro
Kernels,
-
3 eine
schematische Darstellung einer erfindungsgemäßen Organisation,
-
4 eine
beispielhafte Darstellung einer Frage- und Antwort-Transaktion eines
Dienstleistungs-Server-Auftrages
und
-
5 ein
Ablauf Diagramm des erfindungsgemäßen Verfahrens zeigen.
-
1 zeigt
das grundlegende, aus dem Stand der Technik bekannte Mulit Tier
Modell, das hier aus drei Schichten (auch Tiers genannt) besteht:
einer ersten Präsentationsschicht 10,
einer zweiten bzw. mittleren Schicht 12 und einer dritten
Datenschicht 13. Die Aufrufe der ersten in die zweite Schicht
erfolgen bei Microsoft-basierten Systemen über COM oder DCOM Schnittstellen.
Die Rückantworten
erfolgen über
Return Values des jeweiligen COM oder DCOM Aufrufes. Die zweite
Schicht 12 dient zur Generierung von Datenbank-Abfragen,
z.B. SQL Queries, und muß daher
die Struktur der dritten Schicht kennen. Die dritte Schicht 13 beinhaltet
die Daten und ein Datenbank Management System. Nachteilig bei diesem
Aufbau aus dem Stand der Technik ist, daß ein aktiver Teil eines Client-Prozesses,
ein sogenannter Thread, solange blockiert bleibt, bis der Datenbank
Zugriff abgeschlossen ist. Dies führt zu langen Wartezeiten und
zu verminderter Leistungsfähigkeit
des Gesamtsystems.
-
Bei der erfindungsgemäßen Lösung ist
die Entkopplung der Prozesse zwischen den jeweiligen Tiers 10, 12, 13 ebenfalls
beibehalten worden. Doch das Middle Tier bzw. die mittlere Schicht 12 ist
anders – nämlich nach
einem Micro Kernel Prinzip – organisiert.
Dafür ist
eine feste Schnittstelle in Form einer Message 14 für das Middle
Tier 12 entwickelt worden. Weiterhin werden erfindungsgemäß (modulare)
Komponenten eingesetzt, die zumindest Teile einer Server-Dienstleistung realisieren.
-
Unter Bezugnahme auf 2 wird nachstehend die grundlegende erfindungsgemäße Struktur
erläutert.
Die Verbindung des Multi Tier Ansatzes und des Micro Kernel Prinzips
nutzt einen kurzzeitigen Rollenwechsel (vom Empfänger zum Sender) zwischen Client
C und Server S. Das Middle Tier 12 wird komplett im Micro
Kernel realisiert, wobei die Satteliten darum herum sowohl aus der
erster. Schicht 10 als auch aus der Datenschicht 13 stammen
können
und auch Subsysteme genannt werden. Allgemein gesprochen realisieren sie
alle Dienstleistungen.
-
Wie in 3 gezeigt,
beruht der Micro Kernel auf strikter Client Server Architektur.
Der Client C gibt einen Auftrag in Form einer Message 14 und
beendet dann den Aufruf. Danach ist der Client C wieder frei und kann
weitere Prozesse bearbeiten.
-
Der Auftrag wird vom ausgewählten Subsystem
bearbeitet, ohne dass das fragende Subsystem oder die mittlere Schicht 12 noch
blockieren, da der Auftrag ja an das ausführende Subsystem abgegeben
wurde. Ist das angefragte Subsystem mit der Bearbeitung der Message 14 fertig,
wird es nun seinerseits zum Frager bzw. Client C und ruft ein Zielsubsystem
auf die genau gleiche Art und Weise auf (z.B. den ursprünglichen
Frager), um seine Ergebnisse ebenfalls über ein Message Passing abzusenden.
Damit ist ein Informationsrundlauf beendet, der erfindungsgemäß in zwei
Transaktionen – einer
Frage-Transaktion
und eine Antwort-Transaktion – zerlegt
ist. Eine Transkation ist bildlich als Stichleitung vorstellbar.
-
Die erfindungsgemäße Flexibilität kommt
daher, dass die Gesamtkommunikation aus diesen zwei Stichleitungen/Transaktionen
besteht, der Frage-Transaktion und der Antwort-Transaktion. Zwischen
beiden besteht nur eine logische Kopplung.
-
Die Antwort-Transkation geht üblicherweise
an den ursprünglichen
Client Client C, der die Frage-Transaktion abgesetzt hat. Es ist
jedoch auch möglich,
die Antwort-Transkation an eine andere Zieladresse zu senden.
-
Das Routing wird vollständig vom
Micro Kernel durch die Business Logik erledigt, die konsequent durch
Komponenten realisiert wird. Das Routing wird auf der Basis einer
Datenbank, der Routing Datenbank, durchgeführt. So ist sogar eine Anpassung
oder Erweiterung des Message Passing während des Betriebs möglich.
-
Eine Stichleitung/Transaktion muss
bis zum deklarierten Ende bestehen bleiben. Durch die Zweiteilung
in eine Frage/Antworttransaktion entstehen zwei Transaktionen. Deren
Blockadezeit hängt
vorteilhafterweise nicht von der angefragten Dienstleistung ab,
sondern nur von technischen Gegebenheiten wie z.B. den Netzwerkverbindungen,
der Anzahl der Rechner oder der Rechenleistung.
-
In 5 ist
ein Flow Chart gezeigt, das den grundlegenden Ablauf des erfindungsgemäßen Verfahrens
erläutert:
Dabei sind auf der linken Seite dieser Figur die Aktionen von Client
C, einem Programmteil und dem Server S dargestellt, die die Frage-Transaktion
betreffen, während
auf der rechten Seite die Aktionen gezeigt sind, die die Antwort-Transaktion
betreffen.
-
Ein Client C benötigt nun bestimmte Daten aus
der Datenschicht 13 und generiert mit diesen aktuellen Argumenten
eine Message 14. Diese Message betrifft zu diesem Zeitpunkt
die Frage-Transaktion. Daraufhin schiebt der Client C die Message 14 in
die Sende-Queue des Client C, die nach dem FIFO (First-In-First-Out) Prinzip
organisiert ist und kehrt zurück.
Der angesprochene Programmteil holt nun das oberste Element der Queue
ab und leitet die Message 14 mit den codierten Routing
Informationen durch die zweite Schicht von Server S zu Server S
bis in eine Empfangs-FIFO des Server S und kehrt dann zurück. Nun
kann der Server S die Message 14 bzw. den Frage-Teil aus der Empfangs-Queue
auslesen und diese bearbeiten. Damit ist der erste Abschnitt des
erfindungsgemäßen Serverauftrages
erledigt. Nun muß das
Ergebnis wieder an den ursprünglichen
Client C oder eine andere Zieladresse zurück gesendet werden. Hierzu
generiert der Server S wiederum eine Message 14 nach dem
gleichen Prinzip, die in diesem Fall die Antwort-Transaktion codiert
und stellt sie in die Sende-FIFO des Server Server S, um danach
zurück
zu kehren. Nun kann der Programmteil die Antwort-Transaktion aus
der Sende-FIFO auslesen und anhand der Routing Informationen bis
zur Empfangs-FIFO des Client C innerhalb der zweiten Schicht 12 weiter
routen, um danach zurück
zu kehren.
-
Der Client C holt die Message 14 nun
aus der Empfangs-FIFO des Client C und erfaßt den Zeitstempel, der die
Message 14 eineindeutig identifiziert. Über den Zeitstempel im Millisekunden
Bereich kann er eindeutig die dazugehörige Frage-Transaktion bestimmen und sozusagen
die zweiteilige Struktur (Frage-Antwort) in eine einteilige (Auftrag)
zusammensetzen. Der gesamte Auftrag ist nun abgeschlossen.
-
Die Kommunikation hinsichtlich der
Aufrufe ist mit der Komponententechnik realisiert. Hierbei ruft
ein Komponenten Client einen Komponenten Server nur über dessen öffentliches
Interface auf. Das Programm wird dann durch eine angehängte und
abgekapselte Komponentenklasse realisiert. Der Begriff "Öffentlichkeit" im Zusammenhang
mit dem Interface bedeutet, dass es eine Definition erfährt, die
in jedem Rechner global einsehbar, es eineindeutig identifiziert
und auch über
Rechnergrenzen erfragbar ist. Erreicht wird dies durch Verwendung
von GUIDs (Globally Unique Identifier) für das Interface, die Komponentenklasse,
Ressourcen und vieles mehr.
-
Ein Interface bzw. die Schnittstelle
stellt eine Sammlung von Funktionen mit Aufrufparametern dar. Diese
können
grundsätzlich
jeden Typ annehmen. In der bevorzugten Ausführungsform wird "String" als genereller Standardtyp
verwendet. Damit steht ein generischer Typ zur Verfügung, der
ein Message Passing für alle
nur denkbaren Entwicklungen erlaubt. Dies wird realisiert durch
den Aufruf einer Komponente über
eine ihrer Funktionen, der dann bis zu seiner Beendigung blockiert.
Innerhalb dieser Funktion wird die mitgegebene Message umgewandelt
und interpretiert. Erst nachdem dies geschehen ist, gibt sie den
Programmfluss wieder an den Aufrufer zurück.
-
Das Message Passing wird realisiert
durch „textuelle
Messages". Es wird
durch denjenigen Textcode realisiert, der für die jeweilige Zielplattform
nativ ist. Bei Windows und vielen UNIX Plattformen ist dies UNICODE.
-
Eine Message setzt sich aus mehreren
Bereichen zusammen, die sich darin unterscheiden, dass sie entweder
als eigenes Argument auftauchen, oder zu einem String mit definiertem
Trennzeichen wie folgt zusammengesetzt werden:
"Kategorie.Subsystem.Befehlsgruppe.Befehl
+ Datenfeld".
-
Das Datenfeld setzt sich im allgemeinen
aus den folgenden Stringbereichen zusammen:
Quellname|Steuerfeld|Nutzdaten.
-
Abkürzend wird folgendes vereinbart:
Der "Kategorie.Subsystem.Befehlsgruppe" Teil der Message wird
Message Pfad genannt. Der Teil "Befehl
+ Datenfeld" bekommt
den Namen Token, da er unverändert durch
das System durchgereicht wird.
-
Eine Message 14 setzt sich
also immer aus Message Pfad und Token zusammen.
-
Der Message Pfad realisiert eine
Hierarchie, die eine relationale Beziehung festlegt, die das Routing eindeutig
von der Wurzel bis zum Ziel ermöglicht.
Wie bei relationalen Beziehungen üblich, gilt die Eindeutigkeit
nur von links nach rechts im Message Pfad bzw. oben nach unten.
-
Der Message Pfad bezeichnet ein Ziel,
das mit einem Subsystem identisch ist. An dieses wird der Token
abgeliefert.
-
Diese Hierarchie identifiziert die
Schlüssel
einer Routing Datenbank.
-
Der Schlüssel Kategorie stellt die erste
Ebene der Hierarchie dar. Ist er identifiziert, wird in der zweiten Ebene
durch den Schlüssel
Subsystem eine weitere Verzweigung festgelegt. Die Befehlsgruppe
verzweigt als dritte Ebene und ermöglicht die letzte Verzweigung,
die durch den Befehl im Token selbst festgelegt wird.
-
So ergibt sich in Anlehnung an ein
hierarchisches Filesystem eine Art Directory, das eine eindeutige Identifizierung
eines Files erlaubt, das in dieser Analogie dem Token entspricht.
Die eindeutig identifizierbaren Schlüssel dienen zum Abspeichern
der jeweiligen Aufrufinformationen der verschiedenen Komponenten
der jeweils nächst
tieferen Ebene.
-
Der Vorteil des Hinzufügens eines
Message Pfades liegt in dem potentiellen Einsatz gleicher Befehle für unterschiedliche
Subsysteme oder solche mit unterschiedlichen Datenfeldern. Der Message
Pfad kann über
eine externe Datenbank realisiert werden.
-
Jede Ebene wird durch eine Komponente
im Middle Tier 12 oder Micro Kernel realisiert. Unter einem identifizierten
Schlüssel
sind alle Informationen abgelegt, die für einen Aufruf einer Software
Komponente nötig sind.
Für jeden
Schlüssel
gibt es eine Komponente. Die Gesamtheit dieser Routing Komponenten
stellt die Business Logik im Micro Kernel oder Middle Tier 12 dar.
Diese Komponenten müssen
nur einmal entwickelt werden. Es bieten sich mehrere Tools dazu
an. Im Fall von MS Com gibt es Visual Basic oder Visual C++ und ATL.
-
Da parallel mehrere Stichleitungen
betrieben werden, können
einige Routing Komponenten potentiell in verschiedenen Threads gleichzeitig
aufgerufen werden. Dies ist ein klassischer Fall für eine Threadsynchronisierung.
Im Falle der erfindungsgemäßen Architektur
entfällt
sie komplett, indem zum einen lokal erzeugte Daten und Ressourcen
genutzt und globale Daten nur gelesen werden. In C++ wären dies
die automatischen Variablen und die Klassenattribute. Dies hat die
Folge, dass bei MS Com der Multi Threaded Appartement (MTA) Typ
verwendet wird. Hierbei liegt es in der Verantwortung der Komponente,
ob sie ihre Attribute (komponenten-globale Daten) synchronisiert,
da jeder Thread auf jeden Fall in die Komponente eintritt. Im Falle
dieser Architektur werden sie maximal lesend verwendet, also wird
der eintretende Thread nirgends blockiert. Dies führt zu einer optimalen
Granularität,
die bis in die Threadwechselzeiten hinabreicht.
-
Um die Arbeit von Object Request
Broker wie MTS/Com+ oder CORBA nutzen zu können, müssen die Komponenten des Micro
Kernel sich der „Just
In Time Aktivierung" dieser
Broker bewusst sein. Dies hat zur Folge, dass die oben erwähnten automatischen
Variablen oder Ressourcen besonders erzeugt und freigegeben werden
müssen.
Dies unterscheidet sich grundsätzlich
vom Konstruktor/Destruktor Ansatz des Klassenkonzepts.
-
Falls neue Routen hinzugefügt werden
sollen, ist kein Programmtext zu ändern, da erst zur Laufzeit der
Komponenten die Aufrufe über
die Routing DB aufgelöst
werden. Dies setzt eine gelungene Absprache zwischen den Subsystemen
voraus, da der Token ganz konkrete Daten enthält, durch die Fehler ausgelöst werden
können.
Aber auch hier kann die Middle Tier 12 mithelfen, Fehler
zu visualisieren. Da die ganze Message 14 aus dem Datentyp
Text besteht, ist sie zu jedem Zeitpunkt und in jeder Ebene im Klartext,
also unverschlüsselt,
zu kontrollieren. Belegt man z.B. das Datenfeld eines Tokens, der
eine Anfrage an eine Datenbank per "Select" durchführen soll, mit dem kompletten
Select String, so ist dieser aktuell erzeugte dadurch im Klartext
einzusehen.
-
Neue Befehle werden hinzu gefügt, indem
ein neuer Eintrag in der Routing Datenbank vorgenommen wird. Die
Realisierung findet dann komplett in den beiden Subsystemen statt,
die über
die Messages 14 miteinander reden wollen.
-
Im folgenden soll im Zusammenhang
mit 4 beispielhaft gezeigt
werden, wie das Message Passing bei der erfindungsgemäßen Architektur
durchgeführt
wird.
-
Der Startpunkt ist ein fragendes
Subsystem Grafik, das eine Maske realisieren soll. Diese Maske erfragt
alle Informationen, die zur Darstellung einer gewissen Treffermenge
notwendig sind. Das Subsystem Grafik nutzt sie um einen SQL Select String
für das
Datenfeld zu erzeugen und verbindet ihn mit einem zuvor spezifizierten
Befehl zu einem Token "Get.Grafik.0.SELECT
...", wobei "Grafik" der Name des sendenden
Subsystems und „0" der Inhalt des Steuerfeldes
ist. Um den Token zum richtigen Ziel führen zu können wird nun der Message Pfad
festgelegt: "Beispiel.Visual.Holen". Auch dieser ist
Gegenstand der vorausgehenden Spezifikationen. Diese sind unabhängig von
der hier beschriebenen Architektur.
-
Der komplette Aufruf lautet also "Beispiel.Visual.Holen.Get.Grafik.0.SELECT
...".
-
Mit diesen Strings wird eine Wurzel
Komponente des Micro Kernel aufgerufen. Dies ist die Standard Interprozesskommunikation,
die bei allen Übergängen zwischen
den Schichten bzw. von einem Subsystem zum Micro Kernel immer gleich
ist. Es wird immer dieselbe Wurzel Komponente aufgerufen, die immer
der Standard Einsprungpunkt einer Aufruf kette oder Stichleitung
ist, wie sie im folgenden beschrieben wird. Auch ist sie die sogenannte
Transaktionswurzel, d.h. hier fängt
die Transaktion an.
-
Ihre erste Aktion besteht im Interpretieren
des Message Pfades. Hier dient die Kategorie "Beispiel" als Schlüssel, um aus der Routing Datenbank
die Aufrufinformationen für
die nächst
tiefere Komponente erfragen zu können.
Diese wird dann auch sofort aufgerufen, wobei der Message Pfad und
der Token einfach durchgereicht werden.
-
Diese Komponente der Ebene Kategorie
arbeitet nach demselben Prinzip wie die Wurzel Komponente: Interpretation
des Message Pfades („Visual"), Heraussuchen des
Schlüssels
aus der Routing Datenbank und Gewinnen der Aufrufinformationen.
Das Ergebnis ist der Aufruf einer Komponente, aus der um eins tiefer gelegenen
Ebene namens Subsystem.
-
Diese Komponente arbeitet nun wiederum
nach dem selben Prinzip und ruft seinerseits eine Komponente „Holen" aus der Ebene Befehlsgruppe
auf.
-
Insgesamt wird eine Auftrag in rekursive
Aufrufe an die jeweiligen Server S umgesetzt. Jede Ebene kann beliebig
viele Komponenten enthalten. Deshalb ist der Aufrufpfad auch nur
von oben nach unten eindeutig und nicht umgekehrt.
-
Die Ebene Befehlsgruppe ist die direkte
Aufrufschicht der Subsysteme. Sie enthält die Clients C der Subsysteme
und ist die Grenze des Middle Tier (oder Micro Kernel) 12 zu
einem Subsystem.
-
In diesen Komponenten, im Gegensatz
zu den obigen, wird der Befehl nicht mehr weiter interpretiert. Der
Token im Beispiel „Get.Grafik.0.SELECT
..." wird so an
das Subsystem weitergegeben. Der Message Pfad muss deshalb sicherstellen,
dass mehrere, gleichartige Befehle von dem selben Subsystem abgearbeitet
werden. Diese letzte Komponente des Micro Kernel weiß implizit,
oder holt explizit die Information (GUID), wie das spezielle Subsystem
aufgerufen werden muss. Dies bedeutet, dass es sinnvoll ist für jedes
Subsystem nur eine korrespondierende Komponente in der Ebene Befehlsgruppe
zu implementieren, da sie sich dann nicht mit einer Anfrage bei
der Routing Datenbank beschäftigen
muss. In diesem Fall ist implizites Wissen nötig, da im Token selbst keine
Information über
das Ziel Subsystem enthalten ist. Diese steckt alleine im Message
Pfad. Deshalb ist bei der Implementierung einer neuen Message in
der mittleren Schicht 12 kein Code und in den Subsystemen
der ganze Code zu implementieren.
-
Der Befehl „Get.Grafik.0.SELECT ..." mit seinem Select
String im Datenfeld wird nun an das entsprechende Subsystem Data
weitergereicht. Falls es das falsche Subsystem sein sollte, so liegt
der Fehler im Message Pfad, der das Routing leistet. Das Senden
an das Subsystem läuft
wieder über
einen Komponenten Aufruf ab. Aus der Komponente der Ebene Befehlsgruppe
wird das Subsystem als Server aufgerufen.
-
Dazu muss das Subsystem eine Komponente
mit Interface sein. Um eine Entkopplung zum Middle Tier 12 herzustellen,
dient die Komponenten Klasse, die über das Interface direkt aufgerufen
wird. Sie dient nur dazu, die empfangenen Informationen in eine
Queue abzulegen und dem restlichen Subsystem seine Ankunft zu signalisieren.
-
Das restliche Subsystem läuft in mindestens
einem Worker Thread, um einen eigenen Ausführungspfad zu besitzen. Dadurch
kann die Komponenten Klasse sofort terminieren und die Transaktion
damit erfolgreich beenden.
-
Einmal im Subsystem Data angekommen,
ist die Stichleitung oder Transaktion abgeschlossen und die beteiligten
Komponenten terminieren auch erfolgreich.
-
Da dies nur die halbe Aktion für die Abarbeitung
des Auftrages ist, muss nun eine Antwort wieder zurück geroutet
werden. Dies geschieht nun auf die exakt gleiche Weise wie die Frage
abgeliefert wurde.
-
An dieser Stelle kommt das Micro
Kernel Prinzip zur Anwendung. Im Gegensatz zum Multi Tier Modell kann
hier jedes Subsystem zum Top Level werden und per Message Passing
einen Befehl an den Bottom Level schicken. In dem vorstehend unter
Bezugnahme auf 4 beschriebene
Beispiel ist es das ehemals fragende Subsystem Grafik. Die Frage
ging von Grafik nach Data über
eine Transaktion und die Antwort soll nun von Data nach Grafik geschickt
werden. Ist diese zweite Transaktion ebenfalls beendet, so sollte
im Subsystem Grafik der Recordset der Ergebnismenge angekommen sein
um visualisiert zu werden. Dabei wurde nirgends eine Festlegung
notwendig, dass das Quellsubsystem auch wieder das endgültige Zielsystem
sein muss. Vielmehr muss es als befehlsinhärente Information bei Implementierung
dieses Befehles abgesprochen und spezifiziert worden sein. Als allgemeingültige Zusatzinformation
steht im Frage Token die Quelle zur Verfügung. Daraus kann eine Bedingung
abgeleitet werden, ob wieder zurück
geroutet werden soll, oder ein neues Ziel nötig wird. Daraus ist zu erkennen,
dass die Befehle genau die Stelle in dieser Architektur sind, wo
die Applikationsspezifika adressiert werden. Deshalb ist es sinnvoll,
für den
Einsatz von Debugging oder Case Tools, unter den Befehlsschlüsseln auch
eine Spezifikation mit abzulegen. Da der Datentyp String verwendet
wird, fällt
es sehr leicht auch diese Information beim Aufruf der Routing Datenbank
weiterzuleiten.
-
Da die Zeit, in der die Stichleitung
existiert, im überwiegendem
Maße von
der Zugriffsgeschwindigkeit auf die Routing Datenbank abhängt, ist
hier ein weites Feld für
Design Entscheidungen. Bei nicht so kostspieligen Systemen, kann
man z.B. einfache Files verwenden oder bei Windows 2000 die InMemoryDataBase
des Com+ Systems einsetzen. Geht es um komplexe Befehlsstrukturen
auf High Performance Systemen, so kann auch eine Oracle DB eingesetzt
werden.
-
Auf jeden Fall ist es von Bedeutung,
dass der gesamte Ablauf der Informationsbeschaffung durch das Middle
Tier 12 streng zweigeteilt ist. Es sind dann zwar auch
zwei Transaktionen beteiligt, aber keine von beiden ist in ihrer
Blockadedauer vom befehls-spezifischen Problem abhängig. Diese
Zeit liegt komplett zwischen den beiden Transaktionen und garantiert
somit die Asynchronität
zwischen Frage und Antwort. Dies verlagert die Aufgabe der Synchronisierung
der beiden Transaktionen komplett in die Subsysteme. Nur hier können zum Beispiel
gegenseitige Überholungen
von Antworten wieder bereinigt werden.
-
Dies ist sehr günstig für die Forderung nach hoher
Skalierbarkeit. Durch viele, kleine und determinierte Blockadezeiten
ist i. a. eine viel bessere Skalierung möglich, als durch die wenigen
und lang anhaltenden, die bei dem bekannte Multi Tier Modell aus
dem Stand der Technik auftreten. Dazu kommt noch die Tatsache, dass die
unterschiedlichen Leistungsanforderungen immer mit ein und derselben
Software erfüllt
werden, da ja die Architektur unverändert bleibt und nur die Rechenleistung
durch den Einsatz einer höheren
Anzahl von Rechnern erhöht
wird.
-
Vorteilhafterweise ist eine Verteilung
auf verschiedene Rechner von Teilen des Gesamtsystems bis herunter
zu den Komponenten möglich.
-
Die Frage/Antwort-Transkationen müssen jedoch
nicht notwendigerweise, wie hier im Beispiel geschildert, zeitlich
nacheinander ablaufen. In jedem Moment kann jedes Subsystem von jedem
anderen Dienste anfordern. Genau hier hat diese Architektur ihre
Stärken.
Durch die Zweiteilung der Transkationen, werden innerhalb einer
Transaktion keine Daten gesperrt. Dies geschieht komplett in der
Zeit dazwischen und nur im dienstleistenden Subsystem und nicht
im Micro Kernel. Die Frage der Sicherung muss auf einer höheren Protokoll Ebene
zwischen den Subsystemen ausgehandelt werden. Dazu sind spezielle
Messages vorstellbar, die z.B. einen Drei Wege Handshake realisieren.
Da aber keine Daten gegen andere Aufrufe geschützt werden müssen, darf
jede Komponente mehrere Instanzen gleichzeitig aktiv halten.
-
Ist, unter der Annahme eines linearen
Anwachsens des Ressourcenverbrauchs mit der Anzahl der Messages,
ein Engpass zu erwarten, so ist ein Objekt Broker wie MTS, COM+
oder CORBA einzusetzen. Sie reduzieren diese lineare Abhängigkeit
mit der Hilfe von Just In Time Aktivierung, Objekt Pooling, Thread
Pools und Load Balancing.
-
Da der wichtigste Teil, die Kommunikation
zwischen den Subsystemen, mit dem Message Passing unverändert bleibt,
bleibt es für
die Komponenten transparent, ob sie eine Dienstleistung im selben
Rechner erfragen, oder über
Rechnergrenzen hinaus (Bsp.: COM/DCOM). Der gleichzeitig verwendete
Micro Kernel erlaubt diesen skalierenden Ansatz sogar bis ins Subsystem
hinein. Da alle Features hier implementiert werden, sind auch hier
Performance Verbesserungen über
den Ansatz der Verteilung auf mehrere Rechner zu erreichen. Neue
Features, die meistens mit höherer
Rechenzeitanforderungen einhergehen, sind so ohne Neukompilierung
anfügbar.
-
Eine Forderung nach leichter Anpassbarkeit
ist durch das Herausführen
der spezifischen Befehle in die Routing Datenbank erfüllt. Die
unterschiedlichen Anforderungsprofile werden durch die jeweilige
Anpassung der Routing Datenbank realisiert. Es ist auch vorstellbar
ein eigenes Tool zu entwickeln, das die abstrakte Information in
der Routing Datenbank visualisiert. Somit sind Erweiterungen und
Wartungen am System ohne Programmierkenntnisse möglich.
-
Da nur Komponenten als tragende Software
Elemente verwendet werden, und alle spezifischen Dinge wie Features
und Algorithmen in den Subsystemen konzentriert vorliegen, ist eine
evolutionäre
Weiterentwicklung einfach möglich.
Im jeweiligen Subsystem liegen alle Software Module vor, die mit
dem jeweiligen Problemkreis zu tun haben. Also kann immer der alte
Code weiterverwendet werden, indem er vom neuen innerhalb des Subsystems
einfach direkt aufgerufen wird. Anschließend wird das neue Subsystem
ins System eingefügt,
das ja wegen der Beibehaltung der Architektur von den Änderungen
nichts bemerkt.
-
Eine weitere Variante, alten Code
weiter zu verwenden ist, dass komplette Applikationen von einer Komponenten
Hülle umgeben
werden, die für
alle Daten Anpassungen sorgt, die diese Applikation erwartet. Durch
dieses Vorgehen ist sichergestellt, dass die alte Applikation nach
außen
eine Komponente darstellt und nach innen immer noch arbeitet, als
ob sie direkt vom Betriebssystem aufgerufen werden würde. Wenn
man nun diese Komponente mit dem Standard Interface der Architektur
für Subsysteme
versieht, kann sie als solche auch standardmäßig eingebunden werden. Dadurch
erhält
die alte Applikation alle Messages von den anderen Subsystemen,
auch wenn diese viel später
und deshalb optimaler abgestimmt entwickelt wurden. Aufgrund des
Micro Kernel ist auch keine Positionierung dieser alten Applikation
in der starren Multi Tier Struktur nötig.
-
Auf diese Art und Weise könnte der
NetManager vor der Version 5.X nachträglich eine mittlere Schicht bekommen,
die er als Objekt Broker (MTS,COM+) nutzen kann.
-
Aufgrund der Verwendung von Komponenten
ist ein Patching leicht durchführbar.
Ist eine Komponente als fehlerhaft erkannt, so wird sie als einziges
Objekt verändert
und neu compiliert. Der entscheidende Punkt ist, dass man darauf achtet
die eineindeutigen Charakteristika einer Komponente, ihre GUIDs,
dabei nicht zu ändern.
Wieder eingefügt
wird sie durch einfaches Überschreiben
des Zugriffpfades in der Komponentenverwaltung ( bei Windows in
der Registry) oder durch Überschreiben
der Komponente auf der Festplatte. Falls es sichergestellt ist,
dass sie in diesem Moment nicht aufgerufen wird, kann dies auch
im laufenden Betrieb geschehen.
-
In der erfindungsgemäß realisierten
mittleren Schicht
12 werden die Argumente der Funktionen
nur kopiert oder dazu verwendet Routing Informationen abzuleiten.
Die empfangende Funktion kann mit einem C Pseudo Code wie folgt
dargestellt werden:
wobei
BSTR ein MS COM spezifischer Datentyp ist, der einen String bestimmter
Länge darstellt.
-
Es sei betont, dass die Beschreibung
der für
die Erfindung relevanten Komponenten des Netzes grundsätzlich nicht
einschränkend
zu verstehen ist. Für
einen einschlägigen
Fachmann ist insbesondere offensichtlich, dass die verwendeten Begrif fe
funktional und nicht physikalisch zu verstehen sind. Somit können die Komponenten
auch teilweise oder vollständig
in Software und/oder über
mehrere physikalische Einrichtungen verteilt realisiert werden.
