-
GEBIET DER ERFINDUNG
-
Die Erfindung betrifft das Gebiet
des verteilten Rechnens in Client-Server-Systemen, in denen eine
Rechnereinheit (der „Client") eine andere Rechnereinheit
(den „Server") anfordert, um einen
Teil der Arbeit des Clients auszuführen. Der Client und der Server
können
sich auch beide in derselben physischen Rechnereinheit befinden.
-
HINTERGRUND
DER ERFINDUNG
-
Das Rechnen in Client-Server-Systemen
hat in der Informationstechnologie in den vergangenen Jahren immer
mehr an Bedeutung gewonnen. Diese Form des verteilten Rechnens ermöglicht es,
dass eine Maschine einen Teil ihrer Arbeit einer anderen Maschine überträgt, die
zum Ausführen
dieser Arbeit zum Beispiel besser geeignet sein kann. Zum Beispiel
kann der Server ein Hochleistungsrechner sein, in dem Datenbankprogramme
laufen, welche die Speicherung von riesigen Datenmengen verwalten, während der
Client einfach ein Personal Computer (PC) ist, der von der Datenbank
Daten zur Benutzung in einem seiner lokalen Programme anfordert.
-
Die Vorteile des Rechnens in Client-Server-Systemen
sind durch die Verwendung eines gut bekannten Computerprogrammierverfahrens
unter der Bezeichnung „Objektorientierte
Programmierung" (OOP)
noch verstärkt
worden, durch das der Client und der Server auf unterschiedlichen
(heterogenen) „Plattformen" agieren können. Eine
Plattform ist eine spezielle Kombination von Hardware/Software-/Betriebssystemprotokoll,
das die Maschine zur Ausführung
ihrer Arbeit benutzt. Durch die OOP sind das Client-Anwendungsprogramm
und das Server-Anwendungsprogramm in der Lage, auf ihren eigenen
Plattformen zu arbeiten, ohne darauf Rücksicht nehmen zu müssen, wie
die Arbeitsanforderungen der Client-Anwendung der Server-Anwendung mitgeteilt
und von dieser empfangen werden. Ebenso braucht auch die Server-Anwendung
nicht Rücksicht darauf
zu nehmen, wie die Verarbeitungsergebnisse der Server-Anwendung
durch das OOP-System empfangen, umgesetzt und zur anfordernden Client-Anwendung zurückgesendet
werden.
-
Einzelheiten dazu, wie OOP-Verfahren
in heterogene Client-Server-Systeme
integriert worden sind, werden in der US-Patentschrift 5 440 744 und in der Europäischen Patentanmeldung
EP 0 677 943 A2 erklärt. Dennoch
wird im Folgenden ein Beispiel der Grundarchitektur angegeben, um
das Verständnis
der Zusammenhänge
in der Umgebung der Erfindung zu erleichtern.
-
Der Client-Computer 10 in 1 (der zum Beispiel ein
Personal Computer mit dem darin installierten Betriebssystem IBM
OS/2 sein kann) hat ein Anwendungsprogramm 40, das in seinem
Betriebssystem läuft
(„IBM" und „OS/2" sind Warenzeichen der
International Business Machines Corporation). Das Anwendungsprogramm 40 fordert
periodisch das Ausführen
von Arbeiten auf dem Server-Computer 20 und/oder das Zurücksenden von
Daten vom Server 20 zur weiteren Verwendung durch das Anwendungsprogramm 40.
Der Server-Computer 20 kann zum Beispiel ein Hochleistungs-Großcomputer sein,
der auf dem IBM-Betriebssystem
MVS läuft („MVS" ist ebenfalls ein
Markenzeichen der IBM Corp.). Im Rahmen der vorliegenden Erfindung
spielt es keine Rolle, ob die Anforderungen nach Ausführung von
Kommunikationsdienstleistungen in dem Server durch Benutzereingabe
in das erste Anwendungsprogramm 40 ausgelöst werden
oder ob das Anwendungsprogramm 40 unabhängig von Benutzereingaben handelt
und die Anforderungen während des
Programmablaufs automatisch erstellt.
-
Wenn der Client-Computer 10 eine
Anforderung nach den Dienstleistungen des Server-Computers 20 erstellen
will, informiert das erste Anwendungsprogramm 40 das erste
Logikmittel 50 über
die gewünschte
Dienstleistung. Dies kann zum Beispiel dadurch erfolgen, dass das
erste Logikmittel den Namen einer fernen Prozedur zusammen mit einer
Liste von Eingabe- und Ausgabeparametern sendet. Dann verarbeitet
das erste Logikmittel 50 die Task zur Herstellung der erforderlichen
Verbindung zu dem zweiten Computer 20 unter Bezug auf die in der
Speichervorrichtung 60 gespeicherten Definitionen der verfügbaren Verbindungsdienstleistungen.
Alle die möglichen
Dienstleistungen sind als einheitliche Rahmendefinition von Objektklassen 70 definiert,
die von einer einzigen Objektklasse abgeleitet sind. Diese Art der
Definition der Dienstleistungen bietet zahlreiche Vorteile hinsichtlich
der Leistungsfähigkeit
und der Wiederverwendbarkeit.
-
Um die erforderliche Verbindung zu
dem Server 20 herzustellen, ermittelt das erste Logikmittel 50, welche
Objektklasse der Rahmendefinition verwendet werden soll, erzeugt
sodann in dem Server ein Exemplar dieses Objekts und sendet eine
Nachricht an das Objekt, damit das Objekt eines seiner Verfahren
aufruft. Dies führt
zur Einrichtung der Verbindung zum Server-Computer 20 über das Verbindungsmittel 80 und
zum anschließenden
Senden einer Anforderung an das zweite Logikmittel 90.
-
Das zweite Logikmittel 90 leitet
dann die Anforderung an das auf dem Server-Computer 20 laufende
zweite Anwendungsprogramm 100 (im Folgenden als Dienstanwendung
bezeichnet) weiter, sodass die Dienstanwendung 100 die
durch die Anforderung angeforderte spezielle Task, wie beispielsweise
das Durchführen
einer Datenabrufprozedur, ausführen kann.
Nach Durchführung
dieser Task kann die Dienstanwendung verlangen, Ergebnisse zum ersten Computer
10 zurückzusenden.
Die Server-Anwendung 100 tritt
mit dem zweiten Logikmittel 90 in Verbindung, während die
angeforderten Tasks ausgeführt
werden und wenn Ergebnisse zum ersten Computer 10 zurückgesendet
werden müssen.
Das zweite Logikmittel 90 erzeugt Exemplare von Objekten und
ruft die passenden Verfahren dieser Objekte auf, wie sie durch die
Server-Anwendung 100 zu einem bestimmten Zeitpunkt benötigt werden,
wobei die Objektexemplare aus der Rahmendefinition der in der Speichervorrichtung 110 gespeicherten
Objektklassen erzeugt werden.
-
Durch die Anwendung des oben genannten Verfahrens
kommt das Client-Anwendungsprogramm 40 nicht mit der Datenübertragungsarchitektur
in Berührung.
Ferner wird die Server-Anwendung 100 durch den Standardmechanismus
für ihre
jeweilige Umgebung aufgerufen; sie erfährt nicht, dass sie von einem
fernen Computer aufgerufen wird.
-
Die Object Management Group (OMG)
ist eine internationale Vereinigung von Organisationen, die sich
wie in 1 gezeigt mit
unterschiedlichen Aspekten des Rechnens in Client-Server-Systemen auf heterogenen
Plattformen mit verteilten Objekten befassen. Die OMG hat Standards
festgelegt und veröffentlicht,
nach denen Client-Computer (z. B. 10) (in Form der OOP) mit Server-Maschinen
(z. B. 20) zusammenarbeiten. Als Teil dieser Standards ist ein Objektanforderungsbroker
(ORB, von: Common Object Request Broker Architecture, CORBA) definiert worden,
der eine objektorientierte Brücke
zwischen den Client- und den Server-Maschinen bereitstellt. Der
ORB befreit die Client- und Server-Anwendungen von den Einzelheiten
der objektorientierten Ausführung
und übernimmt
zumindest einen Teil der Aufgaben des ersten und des zweiten Logikmittels 50 und 90 sowie
des Verbindungsmittels 80.
-
Als Teil der CORBA-Softwarestruktur
hat die OMG Standards zur Durchführung
von „Transaktionen" festgelegt, die
als Objekttransaktionsdienst (Object Transaction Service, OTS) bekannt
sind. Hierzu siehe zum Beispiel auch CORBA Object Transaction Service
Specification 1.0, OMG Document 94.8.4. Transaktionsverarbeitungssysteme
in Computern werden in vielen Industriezweigen für kritische Geschäftsvorgänge verwendet.
Als Transaktion wird eine einzelne Arbeitseinheit definiert, die
entweder vollständig
erledigt werden oder unbearbeitet bleiben muss. Wenn zum Beispiel
ein Kunde am Geldautomaten der Bank Geld abheben will, müssen entweder alle
Schritte der Geldausgabe, der Verringerung des Geldvorrats in der
Maschine und das Belasten des Kundenkontos erfolgen oder überhaupt
keiner. Versagt auch nur einer der untergeordneten Schritte, so stimmen
die Daten und die tatsächlichen
Schritte nicht überein.
-
Zur verteilten Transaktionsverarbeitung
gehört
eine Transaktion, die Ressourcen an mehr als einer physischen oder
logischen Stelle beeinflusst. Bei dem obigen Beispiel nimmt eine
Transaktion Einfluss auf die in dem lokalen Geldautomaten verwalteten Ressourcen
sowie auf die durch den Zentralcomputer der Bank verwalteten Konten.
An solchen Transaktionen ist ein bestimmter Client-Computer (z.
B. 10) beteiligt, der mit einem bestimmten Server-Computer (z. B.
20) über
eine Reihe von Client-Anforderungen kommuniziert, die durch den
Server verarbeitet werden. Der von der OMG festgelegte OTS ist für die Koordinierung
dieser verteilten Transaktionen zuständig.
-
Üblicherweise
startet eine in einem Client-Prozess laufende Anwendung eine Transaktion, mit
der eine Vielzahl verschiedener Server aufgerufen werden kann, die
jeweils einen Serverprozess starten, um gemäß den in der Transaktion enthaltenen
Instruktionen ihre jeweilige lokale Datenbank zu ändern. Die
Transaktion wird entweder durch Ausführen der Transaktion (wobei
alle Server die Änderungen
ihrer lokalen Datenbanken abschließen) oder durch Abbruch der
Transaktion (wobei alle Server die Änderungen ihrer lokalen Datenbanken
annullieren oder ignorieren) beendet. Um die Verbindung zu den Servern
während
der Transaktion aufrechtzuerhalten (z. B. um sie anzuweisen, dass
sie ihren Anteil an der Transaktion erfüllen oder abbrechen sollen),
muss einer der beteiligten Prozesse Statusdaten für die Transaktion
verwalten. Hierzu gehört üblicherweise der
Prozess zum Erstellen einer Reihe von Transaktionsobjekten, von
denen eines als Koordinierungsobjekt dient, welches die Transaktion
für die
verschiedenen Server koordiniert.
-
Eine herkömmliche Realisierung des OTS, die
von der International Business Machines Corporation entwickelt,
in ihr Produkt Komponentenbrokerserie (Component Broker Series,
Warenzeichen der IBM Corp.) aufgenommen und im Mai 1997 bekanntgegeben
wurde, ist in 2 gezeigt.
Ein Client-Prozess 21,
der eine Transaktion (z. B. Geld von einem Bankkonto abheben) starten
will, muss einen Prozess aussuchen, der in der Lage ist, die Transaktionsobjekte
zu erzeugen und zu verwalten, welche den Status der Transaktion
erfassen. Da die aktuelle Tendenz dahin geht, „abgespeckte" Clients zu erzeugen
(die daher nur die notwendigsten Funktionalitäten aufweisen), ist der Client-Prozess 21 normalerweise
nicht in der Lage, die Transaktionsobjekte lokal zu verwalten und
muss zu diesem Zweck nach einem Serverprozess suchen.
-
Gemäß diesem Ansatz nach dem Stand
der Technik macht der OTS (oder ein anderer Dienst wie beispielsweise
der Dienst CORBA-Lifecycle)
einen Server-Prozess ausfindig und erzeugt in dem ermittelten Server-Prozess
die Transaktionsobjekte 221 (zu denen das Koordinationsobjekt,
das Steuerobjekt und das Beendigungsobjekt gehören). Gemäß diesem Stand der Technik
wird immer derselbe Server-Prozess (Server-A-Prozess 22 in 2) ausgewählt. Nach
dem Auswählen
des Server-A-Prozesses 22 sendet der Client-Prozess 21 (Pfeil
mit der Zahl 1 im Kreisfeld) eine Nachricht an den Server-A-Prozess 22,
um den Server-A-Prozess 22 anzuweisen, die Transaktionsobjekte 221 zu
erzeugen. Der Server-A-Prozess 22 erzeugt dann Transaktionsobjekte 221 und
sendet eine Antwort (Pfeil mit der Zahl 2 im Kreisfeld) an den Client 21,
die den Transaktionskontext enthält.
Dann sendet der Client 21 einen Kontoabbuchungsbefehl (Pfeil
mit Zahl 3 im Kreisfeld) an den Server-B-Prozess 23 (den
Prozess, der das Bankkontoobjekt 231 enthält, von
dem der Clientprozess 21 Geld abheben will).
-
Dieser letztere Befehl enthält den Transaktionskontext,
der vom Server-A-Prozess 22 zum Client 21 gesendet
wurde. Auf diese Weise kann sich das Bankkontoobjekt 231 im
Prozess 23 bei den Transaktionsobjekten 221 im
Prozess 22 selbst anmelden (Pfeil mit Zahl 4 im Kreisfeld),
sodass das Bankkontoobjekt 231 durch die Transaktionsobjekte 221 am Ende
der Transaktion angewiesen werden kann (Pfeil mit Zahl 5 im Kreisfeld),
die Aktion zu vollenden oder rückabzuwickeln.
-
Diese Ausführung ist in mindestens zweierlei Hinsicht
untauglich. Erstens wird dieser Server-Prozess, da immer derselbe
Server-Prozess verwendet wird, wenn ein Client einen fernen Prozess
zum Erzeugen und Verwalten der Transaktionsobjekte einrichtet, bald überlastet
und daher seine eigenen Tasks (z. B. den Inhalt der lokalen Ressourcen
zu aktualisieren) nicht mehr wirksam ausführen können. Zweitens fließen zwischen
verschiedenen an der Transaktion beteiligten Prozessen viele Datenströme hin und
her. Selbst wenn die Transaktionsobjekte in einem beliebigen anderen
Server erzeugt und verwaltet werden, bleibt das Problem der großen Anzahl von
Datenströmen
erhalten.
-
Ferner besitzt der Client bei dieser
Ausführung
keine Wahlmöglichkeit
bezüglich
des Servers, in dem die Transaktionsobjekte eingerichtet werden sollen.
Der Client könnte
versuchen, einen Transaktionsgenerator (transaction factory) (CosTransaction::TransactionFactory)
in dem Server zu finden, in dem der Client die Transaktionsobjekte
einrichten will, in dem Transaktionsgenerator ein Erzeugungsverfahren
aufzurufen und schließlich
das Verfahren CosTransactions::Current::resume() aufzurufen, um die
Transaktion „zum
Laufen zu bringen",
jedoch sind hierzu von Seiten des Clients viele Verarbeitungsschritte
erforderlich. wesentlich leichter wäre es, wenn der Client die
viel einfachere Schnittstelle CosTransactions::Current benutzen
könnte
und dennoch in der Lage wäre,
den Server auszuwählen,
in welchem er die Transaktionsobjekte einrichten will, jedoch ist
dies beim gegenwärtigen
Stand der Technik nicht möglich.
-
Wolisz, A. et al. beschreibt in: „Service
provider selection in an open services environment", Proceedings – Second
IEEE Workshop on Future Trends of Distributed Systems, Kairo, Ägypten,
30. September bis 2. Oktober 1990, S. 229 bis 235, ISBN 0-8186-2088-9,
1990, Los Alamitos, CA, USA, IEEE Comput. Soc. Press, USA, einen
Client, der für
einen gewünschten
Dienst einen am besten geeigneten Server auswählt.
-
ÜBERBLICK ÜBER DIE ERFINDUNG
-
Gemäß einem ersten Aspekt stellt
die vorliegende Erfindung eine Client-Verarbeitungsvorrichtung nach
Anspruch 1 bereit.
-
Vorzugsweise ermittelt das Auswahlmittel, welcher
ferne Server über
eine Ressource verfügt, die
bei der Transaktion aktualisiert wird, und wählt diesen fernen Server als
denjenigen Server aus, der zum Erzeugen der Transaktionsobjekte
am besten geeignet ist.
-
Gemäß einem zweiten Aspekt stellt
die vorliegende Erfindung eine Server-Verarbeitungsvorrichtung nach
Anspruch 4 bereit.
-
Gemäß einem dritten Aspekt stellt
die Erfindung ein Verfahren zum Ausführen der oben bei dem ersten
Aspekt beschriebenen Funktionalität des Clients bereit.
-
Gemäß einem vierten Aspekt stellt
die Erfindung ein Verfahren zum Ausführen der oben bei dem zweiten
Aspekt beschriebenen Funktionalität des Servers bereit.
-
Gemäß einem fünften Aspekt stellt die Erfindung
ein Computerprogrammprodukt zum Ausführen der Funktionalität gemäß dem ersten
Aspekt bereit, wenn dieses in einem Computer läuft.
-
Gemäß einem sechsten Aspekt stellt
die Erfindung ein Computerprogrammprodukt zum Ausführen der
Funktionalität
gemäß dem zweiten
Aspekt bereit, wenn dieses in einem Computer läuft.
-
Da der Client leicht auswählen kann,
in welchem Server die Transaktionsobjekte erzeugt werden sollen,
kann er zum Beispiel wählen,
dass solche Objekte in demjenigen Server-Prozess erzeugt werden, der an der Durchführung der,
Transaktion wesentlich beteiligt ist (z. B. über Ressourcen verfügt, die
an der Transaktion beteiligt sind), und die Anzahl der Datenübertragungen
wird stark reduziert. Dies erkennt man deutlich an einem einfachen
Vergleich zwischen 2 (Stand
der Technik) und 3 (bevorzugte
Ausführungsart
der vorliegenden Erfindung). In 2 gibt
es fünf
Datenübertragungen,
in 3 hingegen nur zwei.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Die Erfindung kann durch die folgende
Beschreibung ihrer bevorzugten Ausführungsarten unter Bezug auf
die beiliegenden Figuren besser verstanden werden.
-
1 ist
eine Übersichtsdarstellung
einer gut bekannten heterogenen Client-Server-Architektur, die das
Objektverfahren benutzt und in der bevorzugte Ausführungsarten
der vorliegenden Erfindung angewendet werden kann;
-
2 ist
eine Übersichtsdarstellung,
die eine herkömmliche
OTS-Realisierung zeigt;
-
3 ist
eine Übersichtsdarstellung,
die eine OTS-Realisierung
gemäß einer
bevorzugten Ausführungsart
der vorliegenden Erfindung zeigt;
-
4 ist
ein Flussdiagramm, das die Schritte zeigt, die durchgeführt werden,
wenn ein Client einen Startbefehl gemäß der OTS-Realisierung von 3 sendet;
-
5 ist
eine Übersichtsdarstellung,
die eine OTS-Realisierung
gemäß einer
bevorzugten Ausführungsart-
der vorliegenden Erfindung zeigt; und
-
6 ist
eine Übersichtsdarstellung,
die einen Server-Prozess
gemäß einer
bevorzugten Ausführungsart
der vorliegenden Erfindung zeigt.
-
DETAILLIERTE BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSARTEN
-
Der Objekttransaktionsdienst (OTS)
der CORBA liefert ein Schnittstellenobjekt unter der Bezeichnung „Aktuell", welches ein Verfahren „Start" aufweist, das durch
Client-Anwendungsprogramme (Quellcode)
angewendet wird, um den zugrunde liegenden Softwareschichten den
Beginn einer Transaktion mitzuteilen. Gemäß der bevorzugten Ausführungsart
der vorliegenden Erfindung geht die zugrunde liegende Software entsprechend
dazu über,
die Transaktion durch Einrichten der Transaktionsstatusobjekte in
einem Server zu erzeugen, der wesentlich an der Transaktion beteiligt
ist (z. B. in einem Server, der über
Serverressourcen verfügt,
die an der Transaktion beteiligt sind), wenn die Client-Anwendung
in einer bestimmten Client-Architektur eingerichtet oder ausgeführt wird
und das Verfahren „Start" enthält.
-
Bei der bevorzugten Ausführungsart
der vorliegenden Erfindung startet eine in einem Client-Prozess 31 (siehe 3) laufende Transaktion
wie üblich
mit dem Aufrufen des Verfahrens „Start" in dem Schnittstellenobjekt „Aktuell". Dann registriert
der Client-Prozess die Tatsache, dass er diesen Befehl gesendet
hat, zum Beispiel durch lokales Erzeugen einer Mindestmenge von
Objekten. Dieser Vorgang ist in dem Flussdiagramm von 4 in Schritt 41 veranschaulicht.
In diesem anschaulichen Beispiel wird angenommen, dass die durchgeführte Transaktion
eine Geldabhebung von einem Bankkonto ist; das ist ein üblicher
Vorgang, der täglich
auf der ganzen Welt durchgeführt
wird, wobei als Client ein Geldautomat (Automated Teller Machine,
ATM) dient.
-
Man beachte, dass beim Stand der
Technik an dieser Stelle ein ferner Prozess 22 eingerichtet wurde
und in diesem fernen Prozess 22 die Transaktionsobjekte
(221 in 2)
erzeugt wurden. Die vorliegende Erfindung verschiebt die Erzeugung
dieser Transaktionsobjekte wie später beschrieben auf einen späteren Zeitpunkt.
-
Dann sendet die in dem Client-Prozess 31 laufende
Anwendung einen Abbuchungsbefehl an das Bankkontoobjekt 331 in
dem Server-B-Prozess 33, was den ersten wesentlichen Teil
der Abhebungstransaktion ausmacht. Bei diesem Beispiel stellt der Abbuchungsbefehl
den ersten fernen Datenstrom dar, den der Client-Prozess nach dem
Senden des Befehls „Start" während der
Transaktion sendet. Beim Erteilen dieses Befehls muss der Client-Prozess
einen Transaktionskontext in den Befehl einfügen, damit das Bankkontoobjekt 331 erfährt, dass
der Befehl Bestandteil einer Transaktion ist, und die spezielle
Transaktion erkennen kann.
-
Beim Stand der Technik (2) empfing der Client-Prozess 21 den
Transaktionskontext von den Transaktionsobjekten 221, die
in dem fernen Prozess 22 erzeugt wurden. Bei der bevorzugten
Ausführungsart
der vorliegenden Erfindung sind die Transaktionsobjekte zu diesem
Zeitpunkt jedoch noch nicht erzeugt worden und konnten dem Client-Prozess
den Transaktionskontext nicht zur Verfügung stellen. Deshalb wird
bei der bevorzugten Ausführungsart,
wenn der Client-Prozess 31 in dem fernen Prozess 33 den
Abbuchungsbefehl an das Bankkontoobjekt 331 sendet, in
den Befehl ein spezieller Transaktionskontext (z. B. ein Transaktionskontext NULL)
eingefügt
(Pfeil mit der Zahl 1 in der Kreisfläche in 3). Ein Transaktionskontext NULL bedeutet,
dass alle Felder des Transaktionskontextes auf null gesetzt sind.
Dieser spezielle Transaktionskontext zeigt an, dass eine Transaktion
gestartet worden ist, aber die Transaktionsobjekte noch nicht erzeugt worden
sind. Diese letztere Operation ist in dem Flussdiagramm von 4 in Schritt 42 veranschaulicht.
-
Wenn der Server-B-Prozess 33 diesen
speziellen Transaktionskontext wahrnimmt (z. B. den Transaktionskontext
NULL), ist er davon in Kenntnis gesetzt, dass eine Transaktion gestartet
worden ist, aber die Transaktionsobjekte noch nicht erzeugt worden
sind. Dann erzeugt der Server-B-Prozess 33 lokal die Transaktionsobjekte 332 (Schritt 43).
Jetzt, da die Transaktionsobjekte 332 erzeugt worden sind, hat
die Transaktion einen gültigen
Transaktionskontext, und ein solcher gültiger Transaktionskontext wird
der Transaktion zugewiesen. Dann sendet der Server-B-Prozess eine
Antwort (Pfeil mit der Zahl 2 in der Kreisfläche) an den Client-Prozess 31,
um diesem den gültigen
Transaktionskontext mitzuteilen (Schritt 44 in 4). Jetzt ist der Client-Prozess vollständig über die
erzeugte Transaktion informiert.
-
An dieser Stelle verläuft der
Datenaustausch (Schritt 45) zwischen dem Bankkontoobjekt 331 und den
Transaktionsobjekten 332 in der üblichen Weise mit dem Unterschied,
dass sämtliche
Datenübertragungen
innerhalb desselben Prozesses stattfinden und hierfür keine
Datenübertragungen
erforderlich sind. Bei diesem Beispiel umfasst der Datenaustausch
die Anmeldung des Bankkontoobjektes 331 bei den Transaktionsobjekten 332 sowie
das Senden eines Ausführungs-
oder Rückabwickelbefehls
durch die Transaktionsobjekte 332 an das Bankkontoobjekt 331,
wenn die Transaktion abgeschlossen wird.
-
Der Client kann weitere Server aufrufen,
an der Transaktion teilzunehmen, die sich dann bei den in dem Server-B-Prozess
erzeugten Transaktionsobjekten anmelden müssen, was zu Datenübertragungen
zwischen den Servern führt.
Die Gesamtzahl der Datenübertragungen
wird jedoch durch die Anwendung der, Erfindung durch einen Client
auf ein Minimum verringert, da zumindest der Austausch zwischen
den lokalen Ressourcen im Server-B-Prozess und den Transaktionsobjekten
nicht zu Datenübertragungen
führt.
Auch bei einer Transaktion, an der nur ein Server-Prozess beteiligt
ist, kommt es nur zwischen dem Client-Prozess und diesem einzigen
Server-Prozess zu Datenübertragungen.
-
Bei einer alternativen Ausführungsart braucht
der Server-B-Prozess 33 die
Transaktionsobjekte nicht bereits beim Einfügen des Transaktionskontextes
NULL in den Server-B-Prozess 33 zu erzeugen, sondern kann
dies zu einem späteren
Zeitpunkt tun, z. B. bei der Anmeldung der Ressource.
-
Obgleich bei der anschaulichen Ausführungsart
ein Transaktionskontext NULL (bei dem alle Felder auf null gesetzt
sind) verwendet wurde, können
für den
Transaktionskontext auch andere spezielle Werte verwendet werden.
Zum Beispiel können die
vertraulichen Datenfelder des Transaktionskontextes auf bestimmte
Werte gesetzt werden.
-
Die obigen Darlegungen beschreiben
eine Verbesserung, welche IBM an ihrem in 2 veranschaulichten ursprünglichen
Produkt Component Broker Series vorgenommen hat und die zu einer
intelligenten Einbettung der Transaktionsobjekte in den ersten bei
der Transaktion aufgerufenen Server-Prozess führt. Diese Verbesserung ist
in der gleichzeitig anhängigen,
von IBM am 16. Januar 1998 eingereichten Patentanmeldung des Vereinigten
Königreichs
unter der Nummer 9 800 830.3 beschrieben worden. Es gibt jedoch
viele Transaktionen, bei denen es nicht am günstigsten ist, die Transaktionsobjekte
in dem ersten aufzurufenden Server-Prozess erzeugen zu lassen.
-
Zum Beispiel werde angenommen, dass
der erste Aufruf der Transaktion ein Berechtigungsaufruf an ein
Berechtigungs-Businessobjekt
zum Überprüfen des
Clients ist (z. B. um sicherzustellen, dass der Client zur Ausführung dieser
Transaktionsart berechtigt ist). Durch das Einfügen der Transaktionsobjekte in
den Server-Prozess, der dieses Businessobjekt enthält, würde die
Anzahl der Datenübertragungen nicht
verringert werden, da dieser Server-Prozess über kein Businessobjekt verfügt, das
eine Ressource darstellt, die während
der Transaktion aktualisiert wird. Das heißt, dass am Ende der Transaktion
viele Datenübertragungen
erforderlich sind, wenn die Transaktionsobjekte in diesem Server-Prozess
mit dem Berechtigungs-Businessobjekt erzeugt würden, da sich sämtliche
Businessobjekte, die während
der Transaktion aktualisierte Ressourcen darstellen, in anderen
Server-Prozessen befinden.
-
Ein weiteres Beispiel besteht darin,
dass der erste Aufruf nach einem Businessobjekt in der Transaktion
ein Nur-Lese-Aufruf
nach einem Businessobjekt ist, das eine Ressource darstellt. Zum
Beispiel fordert der erste Aufruf in einer Transaktion nur den Wert
eines Kontostandes des Bankkontos zu lesen, nicht aber eine Aktualisierung
eines Wertes des Businessobjektes durchzuführen, durch welches die Bankkontoressource
dargestellt wird. Auch diesem Fall wäre es nicht von Vorteil, die
Transaktionsobjekte in dem Server-Prozess zu erzeugen, der dieses Businessobjekt
enthält.
-
Um dem Client mehr Entscheidungsfreiheit darüber zu verleihen,
welcher Server-Prozess die Transaktionsobjekte erzeugen soll, ist
die vorliegende Erfindung entwickelt worden, deren bevorzugte Ausführungsart
im Folgenden in Bezug auf die Erläuterung dieser zusätzlichen
Funktionalität
weiter beschrieben wird.
-
In 5 wird
durch den Client-Prozess 51 die Bearbeitung einer Transaktion
angewiesen. Der erste Aufruf an einen fernen Server-Prozess in der Transaktion
ist ein Aufruf an ein Berechtigungs-Businessobjekt 531 in
dem Server-B-Prozess 53, um die Berechtigung des Clients 51 zu überprüfen. Der
zweite Aufruf an den fernen Prozess in der Transaktion ist ein Aufruf
an das Bankkontoobjekt 521 in dem Server-A-Prozess 52,
um einfach den Wert des Kontostandes zu lesen. Der dritte Aufruf
an den fernen Prozess in der Transaktion ist ein Aufruf an das Bankkontoobjekt 541 in
dem Server-C-Prozess 54, um den Zahlenwert des Kontostandes
dieses Bankkontos zu verringern, um eine Geldauszahlung zu bewirken.
-
Bei der oben beschriebenen Transaktion wäre es nicht
von Vorteil, die Transaktionsobjekte in dem Server-A-Prozess 52 oder
in dem Server-B-Prozess 53 zu erzeugen, da in diesen Prozessen
kein Businessobjekt enthalten ist, das eine bei der Transaktion
aktualisierte Ressource darstellt. Es wäre eher sehr vorteilhaft, die
Transaktionsobjekte im Server-C-Prozess zu erzeugen, da dies derjenige
Prozess ist, der über
das bei der Transaktion aktualisierte Bankkontoobjekt 541 verfügt.
-
Die vorliegende Erfindung fügt in die
Server-Prozesse 52, 53 und 54 Pseudo-Businessobjekte 522, 532 bzw. 542 ein.
Jedem dieser Pseudo-Businessobjekte wird ein bekannter Schlüssel zugewiesen
(der zum Beispiel aus dem Namen des Servers erzeugt wurde), sodass
der Client 51 jedes der Pseudo-Businessobjekte leicht einfügen kann.
Den Pseudo-Businessobjekten kann eine beliebige Funktionalität zugewiesen
werden, solange sie sich von dem Objekt CosTransactions::Transactional
herleiten. Diese dienen dazu, ein leicht verfügbares Objekt bereitzustellen,
das in jedem aus einer Vielzahl von Servern verfügbar ist, sodass der Client
jeden aus der Vielzahl von Servern auswählen kann, um die Transaktionsobjekte
dort zu erzeugen. Der Client 51 stellt sicher, dass der
erste Aufruf an einen fernen Prozess in der Transaktion ein Aufruf
an das Pseudo-Businessobjekt
in dem Server-Prozess ist, in welchem der Client die Transaktionsobjekte
erzeugen möchte. wenn
sich ein Pseudo-Businessobjekt in einem Server befindet, kann dieser
durch einen Client ausgewählt
werden, um die Transaktionsobjekt zu erzeugen.
-
Bei dem oben angegebenen Beispiel
in 5 sind die beiden
ersten Aufrufe der Transaktion des Clients Aufrufe an das Berechtigungs-Businessobjekt 531 im
Prozess 53 und an das Bankkontoobjekt 521 im Prozess 52.
Der Client-Prozess 51 verändert die Transaktion jedoch,
sodass der allererste ferne Aufruf (der so eingerichtet wird, dass
er vor diesen beiden Aufrufen erfolgt) ein Aufruf an das Pseudo-Businessobjekt 542 im
Server-C-Prozess 54 ist, da sich hier das bei der Transaktion
zu aktualisierende Bankkontoobjekt 541 befindet und dies
somit der am besten geeignete Prozess ist, in dem die Transaktionsobjekte
unterzubringen sind.
-
Der Client-Prozess 51 richtet
somit, wie in 5 gezeigt,
einen ersten Aufruf (Pfeil mit Zahl 1 im Kreisfeld) an das Pseudo-Businessobjekt 542 im Server-C-Prozess 54.
Dies entspricht in 4 dem Schritt 42,
aber der Client sendet einen Transaktionskontext NULL nicht an das
Bankkontoobjekt, sondern an das Pseudo-Businessobjekt 542.
Die einzige Aufgabe dieses Aufrufs besteht darin, im Server-C-Prozess 54 die
Transaktionsobjekte 543 zu erstellen (siehe 6). Das Pseudo-Businessobjekt
nimmt den Transaktionskontext NULL in diesem ersten Aufruf vom Client
zur Kenntnis und fährt
als Reaktion auf diesen Erkennungsschritt mit dem Erzeugen der Transaktionsobjekte
fort (dies entspricht dem Schritt 43). Zweitens richtet
der Client-Prozess einen zweiten Aufruf (Pfeil mit der Zahl 2 im
Kreisfeld) an das Berechtigungs-Businessobjekt 531 im
Server-B-Prozess 53, um die Berechtigung des Clients zu überprüfen. Drittens
richtet der Client-Prozess einen dritten Aufruf (Pfeil mit Zahl
3 im Kreisfeld) an das Bankkontoobjekt 521 im Server-A-Prozess,
um den Kontostand dieses Bankkontos zu lesen. Viertens richtet der
Client-Prozess einen
vierten Aufruf (Pfeil mit zahl 4 im Kreisfeld) an das Bankkontoobjekt 541 im
Server-C-Prozess, um den Kontostand dieses Kontos zu verringern
(da hiervon Geld abgehoben wird).
-
Nachdem der Server-C-Prozess 54 lokal
die Transaktionsobjekte erzeugt hat, antwortet der Prozess 54 dem
Client mit dem gültigen
Transaktionskontext (dies entspricht Schritt 44).
-
Die bevorzugte Ausführungsart
der vorliegenden Erfindung beinhaltet somit einen Client, der eine
Transaktion durchzuführen
beabsichtigt, den für das
Einrichten der Transaktionsobjekte am besten geeigneten Server-Prozess ermittelt
und zu Beginn der Transaktion einen Aufruf an ein in dem ermittelten Server-Prozess
befindliches Pseudo-Businessobjekt richtet.
Das führt
dazu, dass die Transaktionsobjekte in diesem ermittelten Server-Prozess
erzeugt werden.
-
Alternativ werden keine Pseudo-Businessobjekte
verwendet. Stattdessen werden Pseudoverfahren in vorhandenen Objekten
(z. B. dem Bankkontoobjekt 541) aufgerufen. Bei dieser
zweiten Ausführungsart
wäre der
erste Aufruf in dem obigen Beispiel von 5 ein Aufruf vom Client-Prozess 51 an
das Bankkontoobjekt 541, welches das Pseudoverfahren wie
beispielsweise bankacount.hello() des Objekts 541 aufruft,
wodurch die Transaktionsobjekte in dem Server-Prozess erzeugt werden,
in dem sich das Bankkontoobjekt 541 befindet.