-
Gebiet der
Erfindung
-
Die
Erfindung betrifft das Gebiet der Client/Server-Datenverarbeitung (auch als "verteilte" Datenverarbeitung
bekannt), wobei eine Datenverarbeitungseinheit ("der Client") von einer anderen Datenverarbeitungseinheit
("dem Server") die Ausführung eines
Teils ihrer Verarbeitungsvorgänge
anfordert.
-
Grundlagen
der Erfindung
-
Die
Client/Server-Datenverarbeitung hat in den vergangenen Jahren im
Bereich der Informationstechnik zunehmend an Bedeutung gewonnen. Diese
Art von verteilter Datenverarbeitung ermöglicht einer Maschine das Delegieren
eines Teils ihrer Verarbeitungsvorgänge an eine andere Maschine,
die beispielsweise zum Ausführen
dieser Verarbeitungsvorgänge
möglicherweise
besser geeignet ist.
-
Die
Vorteile der Client/Server-Datenverarbeitung wurden durch die Verwendung
einer allgemein bekannten, als objektorientierte Programmierung (OOP)
bezeichneten Computerprogrammiertechnologie noch weiter vergrößert, die
es ermöglicht,
dass der Client und der Server sich in verschiedenen (heterogenen) "Plattformen" befinden. Eine Plattform
ist eine Kombination aus der spezifischen Hardware, der spezifischen
Software, dem Betriebssystem und dem Datenübertragungsprotokoll, die eine
Maschine zum Ausführen ihrer
Verarbeitungsvorgänge
verwendet. Die OOP ermöglicht
es dem Clientanwendungsprogramm und dem Serveranwendungsprogramm,
in ihren eigenen Plattformen zu arbeiten, ohne sich darum zu kümmern, wie
die Verarbeitungsanforderungen der Clientanwendung an die Serveranwendung übertragen
und von dieser empfangen werden. Ebenso muss sich die Serveranwendung
nicht darum kümmern,
wie das OOP-System die Verarbeitungsergebnisse der Serveranwendung
empfängt,
umsetzt und an die anfordernde Clientanwendung rücküberträgt.
-
Einzelheiten
der Art und Weise der Integration von OOP-Verfahren in heterogenen Client-/Serversystemen
werden in der US-Patentschrift Nr. 5 440 744 und in der europäischen Patentanmeldung
0 677 943 A2 erläutert.
An späterer
Stelle wird ein Beispiel der grundlegenden Architektur für ein kontextbezogenes
Verständnis
der Umgebung der Erfindung gegeben.
-
Wie
in 1 gezeigt wird, weist der Clientcomputer 10 (der
zum Beispiel ein Personal Computer mit dem darin installierten Betriebssystem
OS/2 von IBM sein könnte)
ein Anwendungsprogramm 40 auf, das in seinem Betriebssystem
ausgeführt
wird ("IBM" und "OS/2" sind Warenzeichen
der International Business Machines Corporation). Das Anwendungsprogramm 40 benötigt periodisch
Verarbeitungsvorgänge,
die im Servercomputer 20 ausgeführt werden müssen, und/oder
Daten, die zur nachfolgenden Verwendung durch das Anwendungsprogramm 40 vom
Server 20 rückübertragen
werden müssen.
Der Servercomputer 20 kann beispielsweise ein Hochleistungs-Großcomputer
sein, auf dem das Betriebssystem MVS von IBM läuft ("MVS" ist ebenfalls
ein Warenzeichen der IBM Corp.).
-
Wenn
der Clientcomputer 10 eine Anforderung nach den Diensten
des Servercomputers 20 machen möchte, benachrichtigt das erste
Anwendungsprogramm 40 das erste Logikmittel 50 über den benötigten Dienst.
Dies kann beispielsweise erfolgen, indem es den Namen einer fernen
Prozedur zusammen mit einer Liste von Eingabe- und Ausgabeparametern
an das erste Logikmittel überträgt. Das erste
Logikmittel 50 bearbeitet sodann die Task des Einrichtens
der notwendigen Datenaustauschvorgänge mit dem zweiten Computer 20 mit
Bezugnahme auf Definitionen der in der Speichereinheit 60 gespeicherten
verfügbaren
Datenübertragungsdienste. Alle
diese möglichen
Dienste werden als ein zusammenhängendes
Gerüst
von Objektklassen 70 definiert, wobei diese Klassen von
einer einzigen Objektklasse abgeleitet werden. Aus der Definition
der Dienste ergeben sich auf diese Weise eine große Anzahl
von Vorteilen hinsichtlich der Leistungsfähigkeit und der Wiederverwendbarkeit.
-
Zur
Einrichtung des notwendigen Datenaustauschs mit dem Server 20 ermittelt
das erste Logikmittel 50, welche Objektklasse im Gerüst verwendet werden
muss, und erzeugt sodann ein Exemplar dieses Objekts im Server 20,
wobei eine Nachricht an dieses Objekt übertragen wird, um es zum Aufrufen von
einer seiner Methoden zu veranlassen. Dies führt zur Einrichtung der Verbindung
mit dem Servercomputer 20 über das Verbindungsmittel 80 und
das anschließende Übertragen
einer Anforderung an das zweite Logikmittel 90.
-
Das
zweite Logikmittel 90 leitet die Anforderung sodann weiter
an das im Servercomputer 20 ausgeführte zweite Anwendungsprogramm 100 (im Folgenden
als Dienstanwendung bezeichnet), so dass die Dienstanwendung 100 die
von dieser Anforderung benötigte
spezifische Task ausführen
kann, beispielsweise die Ausführung
einer Datenabrufprozedur. Sobald diese Task ausgeführt wurde,
muss die Dienstanwendung die Ergebnisse möglicherweise an den ersten
Computer 10 rückübertragen.
Während der
Ausführung
der angeforderten Tasks und wenn Ergebnisse an den ersten Computer 10 rückübertragen
werden müssen,
steht die Serveranwendung 100 in Wechselwirkung mit dem
zweiten Logikmittel 90. Das zweite Logikmittel 90 richtet
Exemplare von Objekten ein und ruft geeignete Methoden jener Objekte
auf, wenn dies von der Serveranwendung 100 benötigt wird,
wobei die Objektexemplare aus dem in der Speichereinheit 110 gespeicherten
zusammenhängenden
Gerüst
von Objektklassen erzeugt werden.
-
Unter
Verwendung des obigen Verfahrens ist das Clientanwendungsprogramm 40 nicht
der Datenübertragungsarchitektur
ausgesetzt. Außerdem
wird die Dienstanwendung 100 durch den Standardmechanismus
für ihre
Umgebung aufgerufen; sie weiß nicht,
dass sie von einem fernen Standort aufgerufen wird.
-
Die
Object Management Group (OMG) ist ein internationales Konsortium
von Organisationen, die an verschiedenen Aspekten der Client/Server-Datenverarbeitung
in heterogenen Plattformen mit verteilten Objekten beteiligt sind.
Die OMG hat Standards veröffentlicht,
mit deren Hilfe Clientcomputer (z.B. 10) Datenaustauschvorgänge (in
OOP-Form) mit Servermaschinen (z.B. 20) ausführen. Als
Teil dieser Standards wurde ein Object Request Broker (ORB) definiert,
der die objektorientierte Brücke
zwischen den Client- und den Servermaschinen bereitstellt. Der ORB
trennt die Client- und Serveranwendungen von den objektorientierten
Einzelheiten der Ausführung,
wobei mindestens ein Teil der Verarbeitungsvorgänge des ersten und des zweiten
Logikmittels 50 bzw. 90 sowie des Verbindungsmittels 80 ausgeführt wird.
-
Sobald
Clientanforderungen den ORB durchlaufen und in den Servercomputer 20 gelangen, sucht
der ORB ein bestimmtes Serverobjekt, das die Anforderung ausführen kann,
und überträgt die Anforderung
an den Objektadapter (ebenfalls durch OMG-Standard definiert) dieses
Servers, wo sie in der Warteschlange (dem Puffer) des Objektadapters gespeichert
wird, um auf die Verarbeitung durch das Serverobjekt zu warten.
Der Puffer ist eine FIFO-Warteschlange (First-In-First-Out queue), was bedeutet, dass
die erste Anforderung, die an einem Ende des Puffers empfangen wird,
diesen am anderen Ende als erste verlässt. Das Serverobjekt hat eine
Vielzahl von parallelen "Programmausführungssegmenten" ("execution threads"), wobei es in jedem ein
Exemplar von sich selbst ausführen
kann. Auf diese Weise kann das Serverobjekt ähnliche Anforderungen von verschiedenen
Clients gleichzeitig verarbeiten. Der Objektadapter prüft, welcher
der parallelen Programmausführungssegmente
zur Verarbeitung einer weiteren Anforderung bereit ist, und weist die
am Ende des Puffers befindliche Anforderung dem nächsten verfügbaren Programmausführungssegment
zu. Dies wird in der oben erwähnten
US-Patentschrift als "Zuteilungs"-Mechanismus ("dispatching" mechanism) erläutert, wobei
der Server in der Warteschlange befindliche Anforderungen Programmausführungssegmenten
zuteilt.
-
Diese
Architektur war in den Fällen
gut geeignet, bei denen ein Clientcomputer 10 wünscht, dass
ein Servercomputer 20 ein "Einzelschritt"-Verarbeitungselement ("one-shot" work item) ausführt (was
bedeutet, dass der Clientcomputer wahrscheinlich nicht die Ausführung weiterer
Verarbeitungsvorgänge
von diesem bestimmten Server benötigt, nachdem
der Server das Verarbeitungsergebnis rückübertragen hat). Da nicht unbedingt
ein Zusammenhang zwischen den verschiedenen im FIFO-Puffer eines
bestimmten Servers gespeicherten Clientanforderungen bestehen muss,
kann das nächste verfügbare Programmausführungssegment
einfach der nächsten
Ausgabe des Puffers zugeteilt werden.
-
Es
gibt jedoch auch andere Client/Server-Anwendungen, die ihrem Wesen
nach keine "Einzelschrittverarbeitung" sind und einen fortdauernden
Zusammenhang zwischen einer bestimmten Clientmaschine 10 und
einer bestimmten Servermaschine 20 benötigen. Ein Beispiel für solche
Anwendungen ist die Verarbeitung von "Transaktionen".
-
Im
Computer realisierte Transaktionsverarbeitungssysteme werden in
mehreren Industriezweigen für
schwierige geschäftliche
Tasks verwendet. Eine Transaktion definiert eine einzelne Arbeitseinheit,
die entweder vollständig
ausgeführt
oder ohne Verarbeitungsvorgang vollständig gelöscht werden muss. Beispielsweise
müssen
im Falle eines Geldausgabeautomaten einer Bank, aus dem ein Kunde Geld
beziehen möchte,
die Vorgänge
der Geldausgabe, der Bestandsverringerung des in der Maschine vorhandenen
Geldes und der Verringerung des Kontostandes des Kunden allesamt
erfolgen, oder es darf keiner von diesen erfolgen. Wenn einer der
untergeordneten Vorgänge
nicht stattfindet, würde
es zu einer Unstimmigkeit zwischen den Aufzeichnungen und den tatsächlichen
Vorgängen
führen.
-
Eine
verteilte Transaktionsverarbeitung beinhaltet eine Transaktion,
die Ressourcen an mehr als einer physischen oder logischen Position
betrifft. Im obigen Beispiel betrifft eine Transaktion Ressourcen, die
in der lokalen Geldausgabeeinheit verwaltet werden, sowie Kontostände, die
vom Hauptrechner einer Bank verwaltet werden. Solche Transaktionen
beinhalten einen bestimmten Clientcomputer (z.B. 10), der über eine
Reihe von Clientanforderungen, die vom Server verarbeitet werden,
einen Datenaustausch mit einem bestimmten Servercomputer (z.B. 20)
ausführt.
-
Falls
die Client- und Servermaschinen sich in heterogenen Plattformen
befinden, könnte
die objektorientierte Architektur von 1 als verteilte
Verarbeitungsumgebung verwendet werden. Die Standard-OMG-Architektur
des Objektadapter/Object Request Broker, bei der der FIFO-Puffer
verwendet und die älteste
gespeicherte Anforderung dem nächsten verfügbaren Programmausführungssegment
zugeteilt wird, liefert jedoch keine brauchbaren Ergebnisse. Falls
zwei Anforderungen, die bezüglich
einer Transaktion in Zusammenhang stehen, von verschiedenen Programmausführungssegmenten
des Server verarbeitet werden, ist die Ausführungsumgebung für jede Anforderung
unterschiedlich, und folglich können
keine übereinstimmenden
Gesamtergebnisse erzielt werden. Die Ergebnisse der ersten ausgeführten Anforderung
werden während
der Verarbeitung einer nächsten
ausgeführten
Anforderung, die Teil derselben Transaktion ist, nicht zur Verfügung gestellt.
Beispielsweise könnten
diese beiden Anforderungen von zwei verschiedenen Programmausführungssegmenten
im Server gleichzeitig verarbeitet werden.
-
Aufgrund
dieses Problems ist man bei der Verarbeitung verteilter Transaktionen
(und anderer Verarbeitungskontexte, an denen zusammenhängende Anforderungen
beteiligt sind) von der Verwendung heterogener Client/Server-Systeme
abgekommen, wobei die Verarbeitung solcher verteilten Transaktionen
homogenen Client/Serverarchitekturen (beispielsweise Computerendgeräten, die
auf Großcomputer
zugreifen) überlassen
blieb, so dass eine übereinstimmende
Ausführungsumgebung
bereitgestellt wird, um garantierte Ergebnisse zu erzeugen.
-
Die
US-Patentschrift Nr. 5 452 459 lehrt ein System, wie es im vorab
kennzeichnenden Abschnitt von Anspruch 1 dargelegt wird.
-
Beschreibung
der Erfindung
-
Die
Erfindung stellt ein Verfahren bereit, wie es in Anspruch 1 beansprucht
wird.
-
Dementsprechend
können
zusammenhängende
Clientanforderungen im selben Programmausführungssegment verarbeitet werden,
wodurch es ermöglicht
wird, dass zusammenhängende
Anforderungen unter denselben Ausführungsbedingungen verarbeitet
werden, wobei die Vorhersagbarkeit des an den Clientcomputer rückübertragenen
Verarbeitungsergebnisses erheblich gesteigert wird.
-
Vorzugsweise
teilt das Planungsmittel (scheduling means) Clientanforderungen,
die bezüglich
einer Transaktion in Zusammenhang stehen, demselben Programmausführungssegment
zu, und der Puffer ist in einem Objektadapter enthalten. Außerdem steht
das Planungsmittel vorzugsweise in Wechselwirkung mit dem Objekttransaktionsdienst
Object Request Broker des Servercomputersystems, um bei der zeitlichen
Planung von Anforderungen Transaktionsdaten bezüglich jeder Anforderung zu
erhalten.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
ein Blockschaltbild einer allgemein bekannten heterogenen Client/Server-Architektur
unter Verwendung einer Objekttechnologie, in deren Kontext die bevorzugten
Ausführungsformen
der vorliegenden Erfindung angewandt werden;
-
2 ist
eine Übersichtsdarstellung
einer Serverarchitektur gemäß einer
ersten Ausführungsform
der vorliegenden Erfindung;
-
3 ist
eine Übersichtsdarstellung
einer Serverarchitektur gemäß einer
zweiten Ausführungsform
der vorliegenden Erfindung; und
-
4 ist
eine Übersichtsdarstellung
einer Serverarchitektur gemäß einer
dritten Ausführungsform
der vorliegenden Erfindung.
-
Ausführliche
Beschreibung der bevorzugten Ausführungsformen
-
Eine
erste Ausführungsform
der Serverarchitektur (2) beinhaltet das Platzieren
einer Gruppe 21 von FIFO-Warteschlangen 21a bis 21n,
wobei jedem Programmausführungssegment 22a bis 22n eine
Anforderungswarteschlange in einem Eins-zu-eins-Verhältnis zugeordnet
wird. Wenn Clientanforderungen von einem Clientcomputersystem vom
Objektadapter 23 des Server über den Object Request Broker 24 empfangen
werden, prüft
der Objektadapter 23 gemäß dieser Ausführungsform
den Inhalt von jeder in seinem FIFO-Puffer 23a für empfangene
Anforderungen enthaltenen Anforderung. Aufgrund eines solchen Inhaltes
können
die Anforderungen sodann zur geeigneten Anforderungswarteschlange 21a bis 21n weitergeleitet
werden. Falls eine erste empfangene Clientanforderung sich beispielsweise
auf eine bestimmte Transaktion bezieht und eine zweite empfangene
Clientanforderung sich auf eine andere Transaktion bezieht, kann
die erste Anforderung der Warteschlange 21a (und ihrem
entsprechenden Programmausführungssegment 22a) und
die zweite Anforderung der Warteschlange 21b (und ihrem
entsprechenden Programmausführungssegment 22b)
zugeordnet werden. Falls sich anschließend eine dritte empfangene
Transaktionswarteschlange auf dieselbe Transaktion wie die erste
Anforderung bezieht, würde
der Objektadapter 23 dies erkennen und diese dritte Anforderung
zur Verarbeitung durch das Programmausführungssegment 22a der
Warteschlange 21a zuordnen.
-
Auf
diese Weise kann eine vollständige Transaktion,
die aus vielen gesonderten (jedoch zusammenhängenden) Anforderungen besteht,
vom selben Programmausführungssegment
ausgeführt werden,
wodurch für
alle bezüglich
einer Transaktion in Zusammenhang stehenden Anforderungen dieselbe
Ausführungsumgebung
bereitgestellt wird.
-
Gemäß einer
zweiten Ausführungsform (3)
fügt ein
im Objektadapter 33 befindlicher Codierer 331 jeder
Anforderung einen Code hinzu, um Anforderungen als einer bestimmten
Transaktion zugehörig
zu kennzeichnen. Anschließend
werden die codierten Anforderungen vom Ausgang des Codierers 331 an
die Anforderungswarteschlange 23a übertragen. Die Anforderungswarteschlange 23a ist eine
FIFO-Warteschlange. Der Objektadapter 33 entnimmt die Anforderungen
in der Reihenfolge aus der Warteschlange, in der sie empfangen wurden,
und prüft
die Codes. Der Objektadapter 33 überträgt die Anforderungen sodann
aufgrund der Codes an das entsprechende Programmausführungssegment
(22a bis 22n).
-
Falls
beispielsweise eine erste Anforderung von einer Clientmaschine über den
Object Request Broker 24 eingeht und zu einer ersten Transaktion gehört, wird
diese Anforderung vom Codierer 331 durch das Hinzufügen eines
Codes codiert, der die Anforderung als Teil einer spezifischen Transaktion kennzeichnet
(z.B. Transaktionskennung 1). Die codierte Transaktion wird sodann
in der Warteschlange 23a gespeichert. Die nächste vom
Object Request Broker 24 empfangene Anforderung stammt
von einer anderen Clientmaschine und gehört zu einer anderen (zweiten)
Transaktion. Der Codierer 331 codiert diese Anforderung
durch Hinzufügen
eines Codes, der die Anforderung als Teil der zweiten Transaktion
kennzeichnet (z.B. Transaktionskennung 2). Falls eine dritte vom
Object Request Broker 24 empfangene Transaktion von der
ersten Clientmaschine stammt und Teil der ersten Transaktion ist,
erkennt der Objektadapter 33 diese Tatsache aus dem Anforderungsinhalt
und fügt
im Codierer 311 einen Code hinzu, der die Anforderung als
Teil der ersten Transaktion kennzeichnet (z.B. Transaktionskennung
1). Es sei darauf hingewiesen, dass die erste Anforderung und die
dritte Anforderung vom Codierer 331 auf dieselbe Art und
Weise codiert werden, da sie beide zur selben Transaktion gehören.
-
Die
Objektadapterwarteschlange 23a enthält sodann die drei Anforderungen,
und wenn sie den Anfang der Warteschlange erreichen, werden die
Anforderungen bezüglich
ihrer Codes analysiert und an die entsprechenden Programmausführungssegmente übertragen.
Das heißt,
die erste Anforderung wird an das Programmausführungssegment 22a übertragen.
Die zweite Anforderung wird an das Programmausführungssegment 22b übertragen.
Und die dritte Anforderung wird an das Programmausführungssegment 22a übertragen.
Die erste und die dritte Anforderung werden an dasselbe Programmausführungssegment 22a übertragen,
da die Ausführungsumgebung
für diese
beiden Anforderungen gleich sein muss, da sie beide Teil derselben
Transaktion sind. Die zweite Anforderung wird an ein anderes Programmausführungssegment 22b übertragen,
da sie nicht Teil der ersten Transaktion ist und ihre eigene Ausführungsumgebung
im gesonderten Ausführungssegment 22b erzeugt.
Weitere empfangene Anforderungen, die zu der zweiten Transaktion
gehören,
werden ebenfalls diesem Ausführungssegment 22b zugewiesen,
so dass sie in der von der zweiten Anforderung erzeugten Ausführungsumgebung
verarbeitet werden.
-
Gemäß einer
dritten Ausführungsform (4)
wird an Stelle einer FIFO-Warteschlange, wie sie in den vorhergehenden
Ausführungsformen
und nach dem Stand der Technik verwendet wird, ein anderer Typ von
Warteschlange verwendet. Diese Warteschlange 43a kann von
verschiedenen Positionen entlang der Warteschlange gelesen werden,
so dass jede in der Warteschlange gespeicherte Anforderung vor irgendeiner
anderen ausgelesen werden kann. Anforderungen von Clientmaschinen
werden wie üblich
in der Reihenfolge, in der sie empfangen wurden, durch den Object
Request Broker 24 und in die Warteschlange 43a des
Objektadapters 43 geleitet. Eine Warteschlange-Leseauswähleinheit
(Queue Read Selector) 45 empfängt Daten aus den Programmausführungssegmenten 22a bis 22n bezüglich der
Verfügbarkeit
jedes Ausführungssegmentes
zur Verarbeitung einer weiteren Anforderung. Die Auswähleinheit 45 empfängt außerdem Daten
bezüglich
der verschiedenen in der Warteschlange 43a gespeicherten Anforderungen.
Aufgrund dieser Daten überträgt die Auswähleinheit 45 Lesebefehle
an die Warteschlange 43a zur Zuteilung von Anforderungen
an die Programmausführungssegmente.
-
Wie
in den vorhergehenden Beispielen, in denen die erste und die dritte
Anforderung zu einer Transaktionen gehören und die zweite Anforderung zu
einer anderen Transaktion gehört,
entnimmt die Auswähleinheit 45 beispielsweise
aus der Warteschlange 43a die Information, dass die erste
und die dritte in der Warteschlange gespeicherte Anforderung zur
selben Transaktion gehören.
Wenn das Programmausführungssegment 22a sodann
die Auswähleinheit 45 benachrichtigt,
dass es zur Bearbeitung weiterer Verarbeitungsvorgänge bereit
ist, überträgt die Auswähleinheit 45 einen
entsprechenden Lesebefehl an die adressierbare Warteschlange 43a, so
dass die erste Anforderung über
den Bus 44 an das Programmausführungssegment 22a (das
Ausführungssegment,
das gerade nach einer weiteren Anforderung fragte) übertragen
wird. Wenn das Programmausführungssegment 22a wieder
nach einer Anforderung fragt (wodurch angekündigt wird, dass es die Verarbeitung
der ersten Anforderung beendet hat), überträgt die Auswähleinheit 45 einen
Lesebefehl an die Warteschlange 43a, so dass die dritte
Anforderung aus der Warteschlange 43a ausgegeben wird und über den
Bus 44 an das Programmausführungssegment 22a übertragen
wird. Wenn in der Zwischenzeit ein anderes Programmausführungssegment
(22b) bei der Auswähleinheit 45 eine
Anforderung abfordert, überträgt diese
einen Lesebefehl an die Warteschlange 43a, so dass die
zweite Anforderung auf den Bus 44 ausgegeben wird und an
das Programmausführungssegment 22b übertragen wird.
-
Gemäß diesen
verschiedenen Ausführungsformen
stellt ein Planungsmechanismus (der sich nicht unbedingt im Objektadapter
befinden muss) sicher, dass alle Anforderungen, die miteinander
in Zusammenhang stehen (d.h. Teil derselben Transaktion sind), zur
Verarbeitung an dasselbe Programmausführungssegment übertragen
werden. Dies stellt die Übereinstimmung
während
der Verarbeitung eines ganzen Satzes von zusammenhängenden
Anforderungen sicher. Das heißt,
die Clientmaschine, die eine Folge von bezüglich einer Transaktion zusammenhängenden
Anforderungen an die Servermaschine ausgibt, kann erwarten, dieselbe
Antwort zu erhalten, wenn sie dieselbe Folge von Anforderungen zu
einem späteren
Zeitpunkt überträgt. Die
Verarbeitungsbedingungen der Ausführungsumgebung des Server bleiben
aufgrund des Planungsmechanismus gleich. Das heißt, es ist nicht möglich, dass
zwischenzeitliche Anforderungen, die zu einer anderen Transaktion
gehören
(oder überhaupt
nicht mit einer Transaktion zusammenhängen), von dem Programmausführungssegment
verarbeitet werden, das gerade eine Transaktion verarbeitet. Falls
es möglich
wäre, dass
solche zwischenzeitlichen Anforderungen im Programmausführungssegment
einer Transaktion verarbeitet würden,
wäre die
Ausführungsumgebung bei
der Verarbeitung von Teilen der Transaktion zu einem späteren Zeitpunkt
anders, und es wären
keine übereinstimmenden
Ergebnisse zur Rückmeldung
an den Client garantiert.
-
Um
festzustellen, ob eine Anforderung zu einer Transaktion gehört, und
in diesem Falle die Einzelheiten der Transaktion zu ermitteln, fragt
der Object Request Broker (ORB) 24 den Transaktionskontext
von jeder eingehenden Anforderung ab. Der Transaktionskontext einer
Anforderung wird vom ORB unter Verwendung des von der OMG eingerichteten
Objekttransaktionsdienstes (Object Transaction Service, OTS) erhalten
[OMG-Dokument 94 8 4, veröffentlicht
1994]. Der ORB fragt außerdem
den Objektbezug (Object Reference) und alle Dienstkontexte (Service
Contexts) der Anforderung ab, um das spezifische Serverobjekt (und
folglich die Serveranwendung) zu ermitteln, die die Anforderung
aufrufen möchte.
Sobald der Transaktionskontext und der Serverkontext/die Serveranwendung
ermittelt wurden, überträgt der ORB
die Anforderung an die entsprechende Warteschlange des Objektadapters.
von dort stellt der Planungsmechanismus sicher, dass alle bezüglich einer
Transaktion zusammenhängenden
Anforderungen an dasselbe Programmausführungssegment übertragen
werden, wie in den obigen Ausführungsformen
beschrieben wird. Außerdem kann
der Planungsmechanismus das Programmausführungssegment für eine bestimmte
Transaktion isolieren, indem er es nicht zulässt, dass Anforderungen, die
nicht mit dieser Transaktion zusammenhängen, in dem zugeordneten Programmausführungssegment
der Transaktion verarbeitet werden.
-
Folglich
stellt die vorliegende Erfindung für den Kontext der verteilten
heterogenen Plattform die Typen von Auslastungsverwaltungsdiensten
(workload management services) bereit, die von modernen geschäftlichen
Verarbeitungsumgebungen benötigt
werden. Einer großen
Anzahl von Benutzern (Clients) kann folglich eine leistungsfähige Nutzung
der verfügbaren
Ressourcen durch einen Ausgleich der Auslastung im gesamten System
geboten werden. Außerdem
werden einzelnen Benutzern jedes Mal, wenn ein Client eine in einer
heterogenen Plattform befindliche Serveranwendung aufruft, übereinstimmende
Ergebnisse in Form einer garantierten Antwort und einer garantierten
Verarbeitungszeit geliefert.