DE69936744T2

DE69936744T2 - Datenverarbeitungsverfahren

Info

Publication number: DE69936744T2
Application number: DE69936744T
Authority: DE
Inventors: Koichi Shinagawa-ku Moriyama
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1998-03-04
Filing date: 1999-03-04
Publication date: 2008-04-30
Anticipated expiration: 2019-03-05
Also published as: EP0940749B1; CA2264234A1; US6513049B1; JPH11249898A; EP0940749A3; KR19990077560A; CN1237731A; EP0940749A2; DE69936744D1

Description

Die vorliegende Erfindung betrifft ein Datenverarbeitungsverfahren, das angewendet wird, wenn zwischen einem Clientobjekt und mehreren Serverobjekten Botschaften ausgetauscht werden. Die Erfindung betrifft auch ein Aufzeichnungsmedium, auf dem ein das obige Datenverarbeitungsverfahren implementierendes Betriebssystem aufgezeichnet ist, und auch ein Datenverarbeitungsgerät, das mit dem obigen Aufzeichnungsmedium bereitgestellt ist.
Bisher wird Software wie beispielsweise Anwendungsprogramme üblicherweise durch Benutzung eines Funktionsaufrufs beschrieben. Die grundlegende Arbeitsweise des Funktionsaufrufs ist in 1 gezeigt. In 1 ist die Funktionsaufrufsseite als ein Client gezeigt, während die Funktionsaufrufsempfangsseite als ein Server gezeigt ist.
Beim Funktionsaufruf ruft der Client, wie durch den Pfeil A1 in 1 angedeutet, die Funktion des Servers auf und veranlasst dadurch den Server, wie durch die durchgezogene Linie A2 in 1 angedeutet, die Funktion auszuführen. Während dieses Funktionsaufrufs ist der Client, wie durch die gestrichelte Linie A3 in 1 angedeutet, im Wartezustand. Bei Vollendung der vom Server ausgeführten Verarbeitung bringt der Server, wie durch den Pfeil A4 in 1 angedeutet, den Wert zum Client zurück und veranlasst den Client, wie durch die durchgezogene Linie A5 in 1 angedeutet, die Verarbeitung wieder zu starten.
Zusammen mit den jüngsten Fortschritten bei den Softwareprogrammierungstechniken schreitet die Entwicklung von auf der objektorientierten Technik basierender Software fort. Wenn bei Software die objektorientierte Technik angewendet wird, können die Funktionen der Software wie beispielsweise Anwendungsprogramme durch Objekte in Modulen gebildet werden. Durch miteinander Austauschen der erforderlichen Information als Botschaften erfüllen die Objekte ihre Funktionen als Module. Solche Botschaftsaustausche werden als „Botschaftsübergang (message passing)" bezeichnet.
Als ein Verfahren zum Implementieren eines Botschaftsübergangs sind unterschiedliche Techniken vorgeschlagen worden und in praktischen Gebrauch gesetzt worden. Eine der Techniken ist ein in 2 gezeigter „Zukunfts"-basierter Botschaftsübergang und aus Chatterjee, A.: „Futures: A Mechanism for Concurrency Among Objekts", Proceedings of the Supercomputing Confernce RENO, NOV. 13-17, 1989, NEW YORK, IEEE, US, vol. CONF. 2, XP000090924 bekannt.
Bei Zukunfts-basiertem Botschaftsübergang wird von einem Clientobjekt, wie durch den Pfeil B1 in 2 dargestellt, eine Botschaft zu einem Serverobjekt gesendet, um das Serverobjekt zum Ausführen einer vorbestimmten Verarbeitung aufzufordern. Zu dieser Zeit wird ein Datenbereich zum Speichern des Resultats der vom Serverobjekt ausgeführten Verarbeitung reserviert. Der Datenbereich ist ein Bereich zum Speichern des vom Clientobjekt zu empfangenden Resultats und wird als eine „Zukunft (future)" bezeichnet.
Das Serverobjekt führt entsprechend der Aufforderung der vom Clientobjekt gesendeten Botschaft eine durch die durchgezogene Linie B2 in 2 angedeutete Verarbeitung aus. Wenn die Verarbeitung vollendet ist, speichert das Serverobjekt das Verarbeitungsresultat, wie durch den Pfeil B3 in 2 dargestellt, in der Zukunft.
Indessen fährt nach dem Senden der obigen Botschaft zum Serverobjekt das Clientobjekt mit der durch die durchgezogene Linie B4 in 2 angedeuteten Verarbeitung fort. Wenn danach das Clientobjekt das Resultat der vom Serverobjekt ausgeführten Verarbeitung anfordert, liest es, wie durch den Pfeil B5 in 2 dargestellt, die in der Zukunft gespeicherten Daten.
Wenn zu dieser Zeit das Resultat der vom Serverobjekt ausgeführten Verarbeitung noch nicht in der Zukunft gespeichert worden ist, ist das Clientobjekt in dem durch die gestrichelte Linie B6 in 2 dargestellten Wartezustand. Wenn das vom Serverobjekt gesendete Verarbeitungsresultat in der Zukunft gespeichert ist, wird es von der Zukunft, wie durch den Pfeil B7 in 2 dargestellt, an das Clientobjekt ausgegeben,.
Das heißt, wenn das Resultat der vom Serverobjekt ausgeführten Verarbeitung in der Zukunft gespeichert ist, empfängt das Clientobjekt das Verarbeitungsresultat unmittelbar. Wenn jedoch das Resultat der vom Serverobjekt ausgeführten Verarbeitung noch nicht in der Zukunft gespeichert worden ist, bleibt das Clientobjekt im Wartezustand, bevor das Resultat in der Zukunft gespeichert wird. Eine Clientpartition, die für einen Client verfügbare „Ausnahmesituationinformation" macht, wenn ein Resultat nicht verfügbar ist, ist in Gargaro, A: „Towards Distributed Objekts for Real-Time Systems", Parallel and Distributed Real-Time Systems, 1995, Proceedings of the Third Workshop an Santa Barbara, CA, USA, IEEE, COMPUT SOC., XP010148106 beschrieben.
Bei der Entwicklung objektorientierter Software werden die Funktionen der Software wie beispielsweise Anwendungsprogramme wie oben angegeben durch Objekte in Module geformt. In diesem Fall kann Software wie beispielsweise ein Anwendungsprogramm durch ein einzelnes Objekt implementiert werden. Alternativ dazu kann jede Funktion des Anwendungsprogramms weiter in Module gebildet werden, so dass das Anwendungsprogramm durch mehrere Objekte implementiert werden kann.
Bei der Ausführung des oben beschriebenen Botschaftsübergangs führt, wenn das Serverobjekt durch ein einzelnes Objekt implementiert ist, dieses die vom Clientobjekt angeforderte Verarbeitung durch Benutzung des einzelnen Objekts in Reaktion auf die vom Clientobjekt gesendete Botschaft aus und gibt dann das Verarbeitungsresultat an das Clientobjekt aus. Dieser Typ von Botschaftsübergang kann in einer zum Konzept des in 1 dargestellten Funktionsaufrufs auf der Basis der Tatsache, dass die Verarbeitungsanforderung empfangen wird und das Verarbeitungsresultat durch das gleiche Objekt zurückgebracht wird, ähnlichen Weise behandelt werden. Selbst wenn es mehrere Serverobjekte gibt, kann der obige Botschaftsübergang in einer zum Konzept des Funktionsaufrufs ähnlichen Weise behandelt werden, wenn ein Serverobjekt, das die Verarbeitungsanforderung empfängt, das gleiche ist wie ein Serverobjekt, welches das Verarbeitungsresultat zurückbringt.
Wenn es jedoch mehrere Serverobjekte gibt und ein Serverobjekt, das die Verarbeitungsaufforderung empfängt, sich von einem Serverobjekt unterscheidet, welches das Verarbeitungsresultat zurückbringt, kann der oben erwähnte Botschaftsübergang nicht in einer zu der des Funktionsaufrufs ähnlichen Weise behandelt werden. Demgemäss wird es beispielsweise notwendig, dass das Clientobjekt berücksichtigt, dass die Verarbeitungsaufforderung empfangen und das Verarbeitungsresultat durch unterschiedliche Serverobjekte zurückgebracht wird. Jedoch wird ein solches Erfordernis für den Clientserver eine schwere Bürde bei der Programmierung.
Demgemäss ist es im Hinblick auf den obigen Hintergrund der herkömmlichen Technik eine Aufgabe der vorliegenden Erfindung, ein Datenverarbeitungsverfahren bereitzustellen, bei dem, selbst wenn es mehrere Serverobjekte gibt und selbst wenn ein Serverobjekt, das eine Verarbeitungsaufforderung empfängt, und ein Serverobjekt, das ein Verarbeitungsresultat zurücksendet bzw. -bringt, unterschiedlich sind, zwischen dem Clientobjekt und dem Serverobjekt ein Mitteilungsübergang (Botschaftsübergang) ausgeführt werden kann, wobei für das Clientobjekt die Notwendigkeit eliminiert ist, darauf zu achten, dass die Verarbeitungsaufforderung empfangen wird und das Verarbeitungsresultat durch die unterschiedlichen Serverobjekte zurückgebracht wird.
Es ist eine andere Aufgabe der vorliegenden Erfindung, ein Verarbeitungsmedium, auf dem ein das oben beschriebene Datenverarbeitungsgerät implementierendes Betriebssystem aufgezeichnet ist, und ein mit einem solchen Aufzeichnungsmedium versehenes Datenverarbeitungsgerät bereitzustellen.
Um die obigen Aufgaben zu lösen ist gemäß einem Aspekt der vorliegenden Erfindung ein wie im beigefügten Anspruch 1 definiertes Datenverarbeitungsverfahren bereitgestellt.
Bei dieser Konfiguration wird zwischen den Objekten des Serverobjekts eine Autorisierung (Autorisation) zum Zurückbringen des Resultats der vom Serverobjekt ausgeführten Verarbeitung zum Clientobjekt delegiert und das Verarbeitungsresultat des Objekts, an das zum Besitz der Autorisierung zuletzt delegiert wurde, im Datenbereich gespeichert wird. Infolgedessen kann, selbst wenn eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Objekte zurückgebracht wird, das Resultat der vom Serverobjekt ausgeführten Verarbeitung über den oben beschriebenen Datenbereich korrekt an das Clientobjekt ausgegeben werden.
Gemäß einem anderen Aspekt der vorliegenden Erfindung ist ein wie im beigefügten Anspruch 5 definiertes Aufzeichnungsmedium, auf dem ein Betriebssystem aufgezeichnet ist, bereitgestellt.
Bei der obigen Konfiguration speichert das auf dem Aufzeichnungsmedium aufgezeichnete Betriebssystem bei Vollendung der Verarbeitung durch das Serverobjekt in Reaktion auf die vom Mitteilungssendungsmittel (Botschaftssendungsmittel) zum Serverobjekt gesendete Mitteilung (Botschaft) im Datenbereich das Resultat der vom Objekt, an das durch das Autorisierungsdelegierungsmittel zum Besitz der Autorisierung zuletzt delegiert wurde, ausgeführten Verarbeitung. Gleichzeitig ist das Clientobjekt fähig, das Verarbeitungsresultat des Serverobjekts durch Lesen der im Datenbereich gespeicherten Daten zu empfangen, ungeachtet dessen, ob im Serverobjekt eine Autorisierung delegiert ist. Folglich ist es durch Benutzung des oben erwähnten Betriebssystems möglich, das Verarbeitungsresultat des Serverobjekts über den Datenbereich an das Clientobjekt korrekt auszugeben, selbst wenn eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Objekte des Serverobjekts zurückgebracht wird.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein wie im beigefügten Anspruch 8 definiertes Datenverarbeitungsgerät bereitgestellt, das ein Aufzeichnungsmedium aufweist, auf dem ein Betriebssystem aufgezeichnet ist.
Bei dieser Konfiguration speichert das auf dem für das oben erwähnte Datenverarbeitungsgerät bereitgestellten Aufzeichnungsmedium aufgezeichnete Betriebssystem bei Vollendung der Verarbeitung durch das Serverobjekt in Reaktion auf die vom oben beschriebenen Mitteilungssendungsmittel (Botschaftssendungsmittel) zum Serverobjekt gesendete Mitteilung (Botschaft) das Resultat der Verarbeitung im Datenbereich. Folglich ist es durch Benutzung des oben erwähnten Betriebssystems möglich, das Verarbeitungsresultat des. Serverobjekts über den Datenbereich an das Clientobjekt korrekt auszugeben, selbst wenn eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Objekte des Serverobjekts zurückgebracht wird.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Datenverarbeitungsgerät bereitgestellt, das ein Aufzeichnungsmedium aufweist, auf dem ein Betriebssystem aufgezeichnet ist. Das Betriebssystem weist ein Mitteilungssendungsmittel (Botschaftssendungsmittel) zum Senden einer Mitteilung (Botschaft) von einem Clientobjekt zu einem ersten Serverobjekt und ein Autorisierungsdelegierungsmittel zum Delegieren einer Autorisierung an ein zweites Serverobjekt auf, wobei beide Mittel als Anwendungsprogrammschnittstellen zur Beschreibung von Objekten benutzt werden. Das Betriebssystem sendet vom Clientobjekt eine Mitteilung (Botschaft) zum ersten Serverobjekt, indem es aufgefordert wird, das Mitteilungssendungsmittel (Botschaftssendungsmittel) auszuführen, und reserviert auch einen Datenbereich zum Speichern eines Resultats einer vom ersten Serverobjekt ausgeführten Verarbeitung. Das Betriebssystem fordert an, dass das erste Serverobjekt ein Autorisierungsdelegierungsmittel zum Delegieren einer Autorisierung zum Zurückbringen des Resultats der vom ersten Serverobjekt ausgeführten Verarbeitung zum Clientobjekt an das zweite Serverobjekt ausführt. Das Betriebssystem veranlasst das Serverobjekt, an das vom Autorisierungsdelegierungsmittel zum Besitzen der Autorisierung zuletzt delegiert wurde, bei Vollendung der Verarbeitung durch das erste Serverobjekt in Reaktion auf die von der Botschaftssendeeinrichtung zum ersten Serverobjekt gesendete Mitteilung (Botschaft) das Resultat der vom ersten Serverobjekt ausgeführten Verarbeitung zu speichern.
Bei dieser Anordnung speichert das auf dem für das oben erwähnte Datenverarbeitungsgerät bereitgestellten Aufzeichnungsmedium aufgezeichnete Betriebssystem bei Vollendung der Verarbeitung durch das Serverobjekt in Reaktion auf die vom oben beschriebenen Mitteilungssendungsmittel (Botschaftssendungsmittel) zum Serverobjekt gesendeten Mitteilung (Botschaft) das Resultat der von dem Objekt, an das vom Autorisierungsdelegierungsmittel zum Besitzen der Autorisierung zuletzt delegiert wurde, ausgeführten Verarbeitung. Gleichzeitig ist das Clientobjekt fähig, das Verarbeitungsresultat des Serverobjekts durch Lesen der im Datenbereich gespeicherten Daten zu empfangen, ungeachtet dessen, ob im Serverobjekt eine Autorisierung delegiert ist. Folglich ist es durch Benutzung des oben erwähnten Betriebssystems möglich, das Verarbeitungsresultat des Serverobjekts über den Datenbereich an das Clientobjekt korrekt auszugeben, selbst wenn eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Objekte des Serverobjekts zurückgebracht wird.
In dieser Beschreibung wird Software zum Verwalten der Ausführung von Anwendungsprogrammen in einem breiten Sinn als „ein Betriebssystem" bezeichnet. Das heißt, das in dieser Beschreibung beschriebene Betriebssystem umfasst nicht nur grundlegende Software zum Verwalten von Hardware, sondern auch Software, die auf grundlegender Software zum Verwalten von Hardware und Verwalten der Ausführung von Anwendungsprogrammen, die als „Middleware" bezeichnet wird, arbeitet. Außerdem umfasst das in dieser Beschreibung beschriebene Betriebssystem Software, die ein virtuelles Computersystem implementiert, bei dem mehrere Programmausführungsumgebungen durch einen einzelnen Computer implementiert sind und es dem Benutzer so vorkommt, wie wenn mehrere Computer arbeiten würden.
Ausführungsformen der Erfindung werden nun nur beispielhaft anhand der beigefügten Zeichnungen beschrieben, bei denen:
1 die grundlegende Arbeitsweise eines Funktionsaufrufs darstellt;
2 die grundlegende Arbeitsweise eines durch Benutzung einer Zukunft ausgeführten Botschaftsübergangs darstellt;
3 die schematische Konfiguration eines Beispiels eines die vorliegende Erfindung realisierenden Fernsehgeräts darstellt;
4 das in dem in 3 gezeigten Fernsehgerät installierte Betriebssystem darstellt;
5 ein Beispiel eines Szenarios eines durch Benutzung des Verfahrens „SendWithRBox" ausgeführten Botschaftsübergangs, wenn die Verarbeitung in einem normalen Zustand fortfährt, darstellt;
6 ein Beispiel eines Szenarios eines durch Benutzung des Verfahrens „SendWithRBox" ausgeführten Botschaftsübergangs, wenn eine Ausnahmesituation auftritt, darstellt;
7 ein Beispiel eines Szenarios eines Botschaftsübergangs, das in den Serverobjekten, in denen eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, darstellt;
8 ein Beispiel eines Szenarios eines durch Benutzung des Verfahrens „SendWithContinuation" ausgeführten Botschaftsübergangs darstellt;
9 ein Beispiel eines Szenarios eines Botschaftsübergangs, das zwischen unterschiedlichen metaSpaces ausgeführt wird, darstellt; und
10 ein anderes Beispiel eines Szenarios eines Botschaftsübergangs, das in den Serverobjekten, bei denen eine Verarbeitungsaufforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, ausgeführt wird, darstellt.
1. Hardwareumgebung
Ein Beispiel eines die vorliegende Erfindung realisierenden Datenverarbeitungsgeräts Wird zuerst anhand der 3 beschrieben. Als eine Ausführungsform der vorliegenden Erfindung wird ein Fernsehgerät beschrieben, das mit einer die vorliegende Erfindung realisierenden Datenverarbeitungsfunktion geladen ist. Jedoch ist die vorliegende Erfindung bei anderen Typen von Datenverarbeitungsgeräten anwendbar. Das heißt, die vorliegende Erfindung wird breit bei Datenverarbeitungsgeräten, auf denen ein Betriebssystem läuft, beispielsweise audiovisuellen Maschinen (als „AV-Maschinen" bezeichnet) anders als das Fernsehgerät, Büromaschinen und gewöhnlichen Computer benutzt.
Das in 3 gezeigte Fernsehgerät, das als ein die vorliegende Erfindung realisierendes Datenverarbeitungsgerät dient, empfängt von einer Rundfunkstation über eine Antenne oder ein Kabel (keines von beiden ist gezeigt) ein Signal und zeigt auf Basis des Signals ein Bild auf einer Bildanzeigeeinheit wie beispielsweise einer Kathodenstrahlröhre oder einer Flüssigkristallanzeigeplatte an und gibt auch von einem Lautsprecher Ton ab.
Das Fernsehgerät weist nicht nur eine gewöhnliche Fernsehfunktion auf, sondern ist auch zum Empfang von Programmen und Daten aus einer externen Quelle fähig. Das Fernsehgerät ist, wie in 3 dargestellt, aus einer über eine Bus/IO-Brücke 1 (IO = input/output (Eingabe/Ausgabe)) mit einem Bus 2 verbundene Fernsehfunktionseinheit 3, einem über eine Bus/Speicher-Brücke 4 mit dem Bus 2 verbundenen Prozessor 5, einem ROM 6 (ROM = Read Only Memory (Nurlesespeicher)) und einem RAM 7 (RAM = Random Access Memory (Direktzugriffsspeicher)), die über die Bus/Speicher-Brücke 4 mit dem Prozessor 5 verbunden sind, und eine Bedienungsplatte 8, eine externe Speichereinrichtung 9, eine Kommunikationseinheit 10 und eine Grafikeinrichtung 11, die alle mit dem Bus 2 verbunden sind, gebildet.
Die Fernsehfunktionseinheit 3 bedient die Funktion zur Wiedergabe von Bildern und Tönen auf Basis eines von der Antenne oder dem Kabel (keines von diesen ist gezeigt). empfangenen Signals. Die Fernsehfunktionseinheit 3 ist über die Bus/IO-Brücke 1 mit dem Bus 2 verbunden, so dass sie Signale zu anderen Elementen übertragen oder von diesen empfangen kann.
Der Prozessor 5, der als eine Berechnungseinheit 3 zur Steuerung der individuellen Elemente des Fernsehgeräts dient, ist über die Bus/Speicher-Brücke 4 mit dem Bus 2 verbunden. Der ROM 6 und der RAM 7 sind über die Bus/Speicher-Brücke 4 mit dem Prozessor 5 verbunden.
Der ROM 6 speichert ein Betriebssystem und Anwendungsprogramme, die zu der vom Prozessor 5 ausgeführten Steuerung benutzt werden. Das im ROM 6 gespeicherte Betriebssystem ist ein objektorientiertes Betriebssystem, das Objektorientierung implementiert.
Der RAM 7 wird als ein Arbeitsbereich für den Prozessor 5 benutzt. Insbesondere lässt der Prozessor 5 das Betriebssystem und die Anwendungsprogramme, die im ROM 6 gespeichert sind, durch Benutzung des RAM 7 als einen Arbeitsbereich laufen und steuert dadurch die individuellen Elemente des Fernsehgeräts.
Die Bedienungsplatte 8 ist eine Eingabeeinheit zum Empfang der Bedienung, die vom Benutzer eingegeben wird, und von dieser Bedienungsplatte 8 wird ein Signal, das eine Instruktion zum beispielsweise Schalten des Kanals oder zur Lautstärkesteuerung des Fernsehgeräts anzeigt, eingegeben. Insbesondere ist die Bedienungsplatte 8 aus einer Eingabeeinheit, die mehrere Tasten bzw. Knöpfe zur Eingabe unterschiedlicher Signale aufweist, und einer Zeigereinrichtung, beispielsweise einer Maus gebildet. Das Signal, das durch die Bedienungsplatte 8 eingegeben wird, wird über den Bus 2 und die Bus/Speicher-Brücke 4 in den Prozessor 5 eingegeben. Der Prozessor 5 führt dann auf der Basis des durch die Bedienungsplatte 8 eingegebenen Signals eine vorbestimmte Berechnungsverarbeitung aus und steuert dadurch die individuellen Elemente.
Die externe Speichereinrichtung 9, die aus beispielsweise einer Festplattenlaufwerkeinheit gebildet ist, wird zur Aufzeichnung von Daten wie beispielsweise Bildern und Tönen, Steuerungsdaten, die zur Steuerung des Fernsehgeräts erforderlich sind, Anwendungsprogrammen, die über die Kommunikationseinheit 10 extern heruntergeladen werden, usw. benutzt.
Die Kommunikationseinheit 10, die eine Eingabe/Ausgabe-Einheit zur Ausführung von Datenkommunikationen mit einer externen Quelle ist, ist aus einem Modem, einem Endgerät- bzw. Anschlussadapter usw. gebildet.
Die Grafikeinrichtung 11 verarbeitet Daten, die auf der externen Speichereinrichtung 9 aufgezeichnet sind, und Daten, die über die Kommunikationseinheit 10 aus einer externen Quelle empfangen werden, und zeigt die korrespondierenden Bilder an.
Der Fernsehempfänger weist nicht nur eine durch die Fernsehfunktionseinheit 3 bereitgestellte gewöhnliche Fernsehfunktion auf, sondern empfängt auch Daten aus einer externen Quelle über die Kommunikationseinheit 10. Insbesondere ist das Fernsehgerät zum Empfang beispielsweise eines neuen Softwaremoduls von einem externen Netzwerk über die Kommunikationseinheit 10 fähig und rüstet dadurch die Version des Betriebssystems und der Anwendungsprogramme hoch.
Bei diesem Fernsehempfänger lässt der Prozessor 5 das im ROM 6 gespeicherte Betriebssystem laufen und führt auch die im ROM 6 und in der externen Speichereinrichtung 9 gespeicherten Anwendungsprogramme auf dem Betriebssystem aus und steuert dadurch die individuellen Elemente des Fernsehgeräts. Das heißt, das Fernsehgerät weist den ROM 6 auf, der als ein computerlesbares Aufzeichnungsmedium, auf dem das Betriebssystem aufgezeichnet ist, dient.
Das Betriebssystem kann im RAM 7 oder in der externen Speichereinrichtung 9 gespeichert sein, insbesondere wenn gewünscht wird, dass das Betriebssystem überschrieben wird.
2. Softwareumgebung
Es wird nun die Softwareumgebung des oben beschriebenen Fernsehgeräts beschrieben.
2-1 Schematische Konfiguration des Betriebssystems
Das bei dem oben erwähnten Fernsehgerät benutzte Betriebssystem ist ein objektorientiertes Betriebssystem. In anderen Worten ist Software wie beispielsweise ein Anwendungsprogramm, das auf dem Betriebssystem läuft, in Modulen als Objekte gebildet, und eine Objektinteraktion wird durch Botschaftsübergang (message passing) durchgeführt.
Dieses Betriebssystem weist, wie in 4 gezeigt, einen Mikrokern (micro kernel) auf, der die grundlegende Funktion wie das Betriebssystem bereitstellt und es dadurch möglich macht, auf dem Mikrokern mehrere Programmausführungsumgebungen gleichzeitig bereitzustellen. In der folgenden Beschreibung wird die durch das Betriebssystem bereitgestellte Programmausführungsumgebung als ein „metaSpace (metaRaum)" bezeichnet.
Insbesondere stellt das Betriebssystem als seinen metaSpace einen mCOOP metaSpace, der aus mehreren Objekten aufgebaut ist, und einen mDrive metaSpace, der aus mehreren Objekten aufgebaut ist, bereit. Jedem metaSpace ist eine API (= application program interface (Anwendungsprogrammschnittstelle)) zugeordnet, die zur Beschreibung von Objekten eines Anwendungsprogramms benutzt wird. In der folgenden Beschreibung wird ein in einem metaSpace benutztes Objekt als ein „metaObject (metaObjekt)" bezeichnet.
Der mCOOP metaSpace ist ein metaSpace primär zum Betreiben eines objektorientierten Anwendungsprogramms (beispielsweise eines Anwendungsprogramms zum Implementieren einer grafischen Benutzerschnittstelle zur Steuerung der Bedienungsplatte 8) das „m" in mCOOP metaSpace steht für einen metaSpace und „COOP" steht für Concurrent Object Oriented Programming (gleichzeitige objektorientierte Programmierung).
Der mDrive metaSpace ist ein metaSpace zum Betreiben eines Einrichtungstreibers (beispielsweise eines Einrichtungstreibers zur Steuerung der Grafikeinrichtung 11 oder eines Einrichtungstreibers zur Steuerung der Kommunikationseinheit 10 zum Übertragen und Empfangen von Daten über ein Netzwerk) primär zur Steuerung von Hardware. Das „m" bei mDrive metaSpace bezeichnet einen metaSpace, und „Drive" steht für einen metaSpace zum Betreiben des Einrichtungstreibers (Device Driver).
Das heißt, bei diesem Betriebssystem werden der mCOOP metaSpace und der mDrive metaSpace auf dem Mikrokern betrieben. Ein in Modulen als Objekte ausgebildetes Anwendungsprogramm wird im mCOOP metaSpace betrieben, während ein in Modulen als Objekte ausgebildeter Einrichtungstreiber im mDrive metaSpace betrieben wird.
Dieses Betriebssystem ist zur Bereitstellung nicht nur eines mCOOP metaSpace und mDrive metaSpace als der auf dem Mikrokern betriebene metaSpace, sondern auch als metaSpace zum Betrieb beispielsweise eines prozedurorientierten Anwendungsprogramms (beispielsweise eines Anwendungsprogramms zum Bewirken, dass die Fernsehfunktionseinheit 3 Bewegungsbilder anzeigt) fähig.
Das einen mCOOP metaSpace bildende metaObject weist beispielsweise ein Objekt „mCOOPMailer” und ein Objekt „mCOOPFaultHandler" auf. Das Objekt „mCOOPMailer" ist ein metaObject, das zur Ausführung eines Botschaftsübergangs zwischen Anwendungsprogrammen, die im mCOOP metaSpace laufen, benutzt wird. Das Objekt „mCOOPFaultHandler" ist ein metaObject zur Ausführung einer Ausnahmesituationsbehandlung. In der Praxis ist der mCOOP metaSpace nicht nur aus den oben beschriebenen metaObjects, sondern auch aus anderen metaObjects gebildet.
Das mDrive metaSpace bildende MetaObject weist beispielsweise ein Objekt „mDriveMailer" und ein Objekt „mDriveFaultHandler" auf. Das Objekt „mDriveMailer" ist ein zur Ausführung eines Botschaftsübergangs zwischen Einrichtungstreibern, die im mDrive metaSpace laufen, benutztes metaObject. Das Objekt „mDriveFaultHandler" ist ein metaObject zur Ausführung einer Ausnahmesituationbehandlung. In der Praxis sind sowohl der mDrive metaSpace als auch der mCOOP metaSpace nicht nur aus den oben beschriebenen metaObjects, sondern auch aus anderen metaObjects gebildet.
Dieses Betriebssystem stellt die Funktion eines Zukunfts-basierten Botschaftsübergangs bereit, die unten detailliert beschrieben wird. In der folgenden Beschreibung wird beim Zukunfts-basierten Botschaftsübergang das Objekt, das eine Botschaft zu einem anderen Objekt sendet, um es zur Ausführung einer Verarbeitung aufzufordern, als ein „Clientobjekt" bezeichnet. Umgekehrt wird das Objekt, das die Botschaft vom Clientobjekt empfängt und auf Basis der Botschaft eine Verarbeitung ausführt, als ein „Serverobjekt" bezeichnet.
2-2 mCOOP metaSpace API
Um im mCOOP metaSpace einen Zukunfts-basierten Botschaftsübergang auszuführen, stellt das oben erwähnte Betriebssystem als die APIs, die zum Beschreiben der im mCOOP metaSpace arbeitenden Objekte benutzt werden, die folgenden Verfahren bereit. Bei dieser Anmeldung wird die API entsprechend dem Beschreibungsverfahren der OMG IDL (= Objekt Management Group Interface Definition Language (Objektverwaltungsgruppen-Schnittstellendefinitionssprache) angezeigt.

sError SendWithRBox (in OID destObjID, in Selector meth, in any msg, in size_t sizeOfMsg, out RID rBoxID)
sError Receive (in RID rBoxID, in any msg, in size_t sizeOfmsg)
sError Reply (in any resultMsg, in size_t sizeOfResultMsg)
sError Delegate (in OID destObjID, in Selector meth, in any msg, in size_t sizeOfMsg)

Die obigen Verfahren werden unten im Detail beschrieben.
2-2-1 SendWithRBox()

sError SendWithRBox (in OID destObjID, in Selectormeth, in any msg, in size_t sizeOfMsg, out RID rBoxID)

Das Verfahren "SendWithRBox" ist ein Botschaftssendeverfahren zum Senden einer Botschaft von einem Clientobjekt zu einem Serverobjekt. Das heißt, das Verfahren „SendWithRBox" wird angewendet, wenn es für das Clientobjekt notwendig wird, das Resultat der vom Serverobjekt ausgeführten Verarbeitung zu erhalten, nachdem es eine Botschaft zum Serverobjekt gesendet hat.
Das Argument „destObjID" ist ein Argument des „OID"-Typs, der ein Datentyp zum Spezifizieren des Objekts ist. Der das Serverobjekt spezifizierende Wert wird in das Argument „destObjID" gesetzt.
Das Argument „meth" ist ein Argument des „Selector"-Typs, der ein Datentyp zum Bezeichnen des Verfahrens ist. Der das Verfahren des Serverobjekts zum Beschreiben der angeforderten Verarbeitung bezeichnende Wert wird in das Argument „meth" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der an das Serverobjekt auszugebenden Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t" Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der die Größe der an das Serverobjekt auszugebenden Botschaft anzeigende Wert wird in das Argument „sizeOfMsg" gesetzt.
Wenn das Verfahren „SendWithRBox" ausgegeben wird, wird der Datenbereich „RBox" zum Speichern des Resultats der vom Serverobjekt ausgeführten Verarbeitung durch das Objekt „mCOOPMailer" reserviert, was später beschrieben wird. Der Datenbereich „RBox" ist ein Bereich, in welchem das vom Clientobjekt zu empfangende Resultat gespeichert wird, und wird als eine „Zukunft (future)" bezeichnet.
Nach dem Senden der Botschaft zum Serverobjekt erhält das Verfahren „SendWithRBox" den Identifizierer „rBoxID" des „RID"-Typs, der ein Datentyp zum Spezifizieren des Datenbereichs „RBox" ist. Der Identifizierer „RBoxID" ist ein Identifizierer zum Bezeichnen des vom Objekt „mCOOPMailer" reservierten Datenbereichs „RBox", wenn das Verfahren „SendWithRBox" ausgegeben worden ist.
Das Verfahren „SendWithRBox" erfasst den Wert des „sError"-Typs als den Zurückbringwert, der ein Datentyp ist, der den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „SendWithRBox" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der den Fehlergrund anzeigende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-2-2 Receive()

sError Receive (in RID rBoxID, in any msg, in size_t sizeOfMsg)

Das Verfahren "Receive" ist ein Datenleseverfahren zum Lesen von im Datenbereich "RBox" gespeicherten Daten. Das heißt, das Verfahren „Receive" wird benutzt, wenn das Clientobjekt das Resultat der vom Serverobjekt ausgeführten Verarbeitung empfängt, nachdem es das Verfahren „SendWithRBox" ausgegeben hat.
Das Argument „rBoxID" ist ein Argument des „RID"-Typs, der ein Datentyp zum Bezeichnen des Datenbereichs „RBox" ist. Der Identifizierer zum Spezifizieren des Datenbereichs „RBox", der das Resultat der vom Serverobjekt ausgeführten Verarbeitung speichert, wird in das Argument „rBoxID" gesetzt. Das heißt, der bei der Ausgabe des Verfahrens „SendWithRBox" erfasste Wert des Identifizierers „rBoxID" wird in das Argument „rBoxID" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der empfangenen Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der die Größe des Bereichs zum Speichern der empfangenen Botschaft anzeigende Wert wird in das Argument „sizeOfMsg" gesetzt.
Das Verfahren „Receive" erfasst den Wert des sError"-Typs als den Zurückbringwert, der ein Datentyp ist, der den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „Receive" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der Fehlercode, der den Fehlergrund anzeigt, als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-2-3 Reply()

sError Reply (in any resultMsg, in size_t sizeOfResultMsg)

Das Verfahren "Reply" wird benutzt, wenn das Serverobjekt das Verarbeitungsresultat zum Clientobjekt zurückbringt, nachdem das Clientobjekt das Verfahren „SendWithRBox" gesendet hat.
Das Argument „ResultMsg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der zum Clientobjekt zu sendenden Botschaft wird in das Argument „ResultMsg" gesetzt.
Das Argument „sizeOfResultMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Bezeichnen der Größe der Daten ist. Der die Größe der zum Clientobjekt zu sendenden Botschaft anzeigende Wert wird in das Argument „sizeOfResultMsg" gesetzt.
Das Verfahren „Reply" erhält als den Zurückbringwert den Wert des „sError"-Typs, der ein Datentyp ist, der den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „Reply" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der den Fehlergrund anzeigende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-2-4 Delegate()

sError Delegate (in OID destObjID, in Selector meth, in any msg, in size_t sizeOfMsg)

Das Verfahren „Delegate" ist ein Autorisierungsdelegierungsverfahren zum Delegieren einer Autorisierung zwischen Objekten. Insbesondere wird das Verfahren „Delegate" benutzt, wenn die Autorisierung zum Zurückbringen des Resultats der vom Serverobjekt ausgeführten Verarbeitung zum Clientobjekt zwischen mehreren Serverobjekten delegiert ist.
In der folgenden Beschreibung wird die oben erwähnte Autorisierung als die „Antwortautorisierung (reply authorization)" bezeichnet. Unter den Serverobjekten wird das Objekt, das die Antwortautorisierung delegiert, als ein „autorisierungsdelegierendes Objekt (authorization-delegating object)" bezeichnet, während das Objekt, das zum Empfang der Antwortautorisierung delegiert ist, als ein „autorisierungsdelegiertes Objekt (authorization-delegated object)" bezeichnet wird.
Das Argument „destObjID" ist ein Argument des „OID"-Typs, der ein Datentyp zum Spezifizieren des Objekts ist. Der das autorisierungsdelegierte Objekt repräsentierende Wert wird in das Argument „destObjID" gesetzt.
Das Argument „meth" ist ein Argument des „Selector"-Typs, der ein Datentyp zum Spezifizierendes Verfahrens ist. Der das Verfahren des autorisierungsdelegierten Objekts zur Beschreibung der erforderlichen Verarbeitung anzeigende Wert wird in das Argument „meth" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der zum autorisierungsdelegierten Objekt zu sendenden Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t"-Typs, der eine Datengröße zum Bezeichnen der Größe der Daten ist. Der die Größe der zum autorisierungsdelegierten Objekt zu sendenden Botschaft darstellende Wert wird in das Argument „sizeOfMsg" gesetzt.
Das Vefahren „Delegate" erhält den Wert des „sError"-Typs als den Zurückbringwert, der ein Datentyp ist, ser den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „Delegate" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der Fehlercode, der den Fehlergrund anzeigt, als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, ist der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-2-3 mDrive metaSpace API
Um im mDrive metaSpace einen „Zukunfts"-basierten Botschaftsübergang auszuführen, stellt das oben erwähnte Betriebssystem die folgenden Verfahren als die APIs bereit, die zum Beschreiben des im mDrive metaSpace arbeitenden Objekts benutzt werden. Die API wird entsprechend der OMG IDL dargestellt.

sError SendwithContinuation (in OID destObjID, in Selector meth, in any msg, in size_t sizeOfMsg in Selector contMeth)
sError Kick (in ContID contID, in any msg, irr size_t sizeOfMsg)

Die obigen Verfahren werden unten im Detail beschrieben.
2-3-1 SendWithContinuation()

sError SendwithContinuation (in OID destObjID, in Selctor meht, in any msg, in size_t sizeOfMsg, in Selector contMeth)

Das Verfahren „SendwithContinuation" ist ein Botschaftssendeverfahren zum Senden einer Botschaft vom Clientobjekt zum Serverobjekt. Das Verfahren „SendwithContinuation" wird benutzt, wenn es für das Clientobjekt notwendig wird, beim Empfang des Verarbeitungsresultats des Serverobjekts ein spezielles Verfahren (nachfolgend als „Fortsetzungsverfahren (continuation method)" bezeichnet) auszuführen, nachdem das Clientobjekt die Botschaft zum Serverobjekt gesendet hat.
Das Argument „destObjID" ist ein Argument des „OID"-Typs, der ein Datentyp zum Spezifizieren des Objekts ist. Der Wert zum Spezifizieren des Serverobjekts wird in das Argument „destObjID" gesetzt.
Das Argument „meth" ist ein Argument des „Selector"-Typs, der ein Datentyp zum Bezeichnen des Verfahrens ist. Der das Verfahren des Serverobjekts zum Beschreiben der angeforderten Verarbeitung darstellende Wert wird in das Argument „meth" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der an das Serverobjekt auszugebenden Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der Wert, der die Größe der an das Serverobjekt auszugebenden Botschaft anzeigt, wird in das Argument „sizeOfMsg" gesetzt.
Das Argument „contMeth" ist ein Argument des „Selector"-Typs, der ein Datentyp zum Bezeichnen des Verfahrens ist. Der Wert zum Spezifizieren des Fortsetzungsverfahrens wird in das Argument „contMeth" gesetzt.
Bei der Ausgabe des Verfahrens „sendWithContinuation" wird der Datenbereich „Continuation" durch das Objekt „mDriveMailer" reserviert, was später beschrieben wird, und die das Fortsetzungsverfahren betreffende Information wird im Datenbereich „Continuation" gespeichert. Der Datenbereich „Continuation" ist ein Bereich zum Speichern des vom Clientobjekt auszuführenden Fortsetzungsverfahrens und wird als eine „Zukunft (future)" bezeichnet.
Das Verfahren „sendWithContinuation" erfasst als den Zurtickbringwert den Wert des „sError"-Typs, der ein Datentyp ist, ser den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „sendWithContinuation" bei der Ausgabe dieses Verfahrens nicht korrekt vervollständigt wird, wird der Fehlercode, der den Fehlergrund anzeigt, als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt verarbeitet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-3-2 Kick()

sError Kick (in ContID contID, in any msg, in size_t sizeOfMsg)

Das Verfahren "Kick" wird angewendet, wenn das Serverobjekt das Clientobjekt instruiert, das Fortsetzungsverfahren auszuführen, nachdem das Clientobjekt das Verfahren „sendWithContinuation" ausgegeben hat.
Das Argument „contID" ist ein Argument des „contID"-Typs, der ein Datentyp zum Bezeichnen des Datenbereichs „Continuation" ist. Der Identifizierer zum Spezifizieren des Datenbereichs „Continuation", der bei der Ausgabe des Verfahrens „sendWithContinuation" vom Objekt „mDriveMailer" reserviert wird, wird in das Argument „contID" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der an das Clientobjekt auszugebenden Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der die Größe der an das Clientobjekt auszugebenden Botschaft darstellende Wert wird in das Argument „sizeOfMsg" gesetzt.
Das Verfahren „Kick" erhält den Wert des „sError"-Typs als den, Zurückbringwert, der ein Datentyp ist, der den Fehlercode darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „Kick" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der den Fehlergrund anzeigende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-4 Zum Botschaftsübergang benutzter Datenbereich
Bei der Ausführung eines Botschaftsübergangs im mCOOP metaSpace benutzt das oben erwähnte Betriebssystem den Datenbereich „RBox" als eine Zukunft und benutzt auch den Datenbereich „DeliveryBoxA" zur Ausgabe von Information vom Clientobjekt zum Serverobjekt.
Außerdem benutzt das oben erwähnte Betriebssystem bei Ausführung eines Botschaftsübergangs im mDrive metaSpace den Datenbereich „Continuation" als eine Zukunft und benutzt auch den Datenbereich „DeliveryBoxB" zum Übertragen von Information vom Clientobjekt zum Serverobjekt.
Das oben beschriebene Betriebssystem reserviert für jedes Objekt den Datenbereich „Thread", um die zum Verwalten des Ausführungszustands des Objekts benutzte Information zu speichern. Das Betriebssystem speichert auch die Information, welche die Zukunft betrifft, im Datenbereich „Thread". Das Objekt wird im mCOOP metaSpace und im mDrive metaSpace als ein einzelner Teilprozess (single thread) bearbeitet, wobei ein einzelner Teilprozess mit einem einzelnen Objekt korrespondiert. Die Information, die den Teilprozess (thread) betrifft, wird im Datenbereich „Thread" als die Information zum Verwalten des Ausführungszustands des Objekts gespeichert.
Die Datenbereiche „RBox", „DeliveryBoxA", „Continuation", „DeliveryBoxB" und „Thread" sind Datenbereich, die vom Betriebssystem zur Bereitstellung der Funktion des Botschaftsübergangs oder zum Verwalten des Objekts benutzt werden. Diese Datenbereiche werden vom Betriebssystem so verwaltet, dass von den Anwendungsprogrammen oder den Einrichtungstreibern nicht direkt auf sie zugegriffen werden kann. Die oben beschriebenen Datenbereiche werden unten im Detail beschrieben.
2-4-1 RBox
Der Datenbereich „RBox" wird vom Objekt „mCOOPMailer" bei Ausgabe des Verfahrens „SendWithRBox" reserviert. Insbesondere wird die Reservierung des Datenbereichs „RBox" durch das Objekt „mCOOPMailer" durch Erzeugung der Fälle einer Klasse (nachfolgend als die „Klasse ,RBox'" bezeichnet), welche die in Tabelle 1 gezeigten Attribute aufweist, ausgeführt. In der Tabelle 1 sind unter den Attributen der Klasse „RBox" nur eine minimale Anzahl von Attributen, die zum Implementieren der grundlegenden Form eines Botschaftsübergangs im mCOOP metaSpace erforderlich sind, gezeigt. Attribute anders als die in Tabelle 1 gezeigten Attributen können inkludiert sein. Tabelle 1

RBox

ThreadID bool creator ready

void* t_size sError resultMsg sizeOfResultMsg status
Tabelle 1 zeigt, dass die Klasse „RBox" ein Attribut „creator" des „ThreadID"-Typs, der ein Datentyp zum Spezifizieren des für jedes Objekt zu setzenden Datenbereichs „Thread" ist, aufweist.
Die Klasse „RBox" weist auch ein Attribut „ready" des „bool"-Typs, der ein Datentyp für logische Werte ist, ein Attribut „resultMsg des „void*"-Typs, der ein den Zeiger-darstellender Datentyp ist, und ein Attribut „sizeOfResultMsg" des „size_t"-Typs, der eine Datengröße zum Spezifizieren der Größe der Daten ist, auf.
Diese Attribute werden als der Bereich zum Speichern der Resultatsdaten der vom Serverobjekt ausgeführten Verarbeitung benutzt.
Die Klasse „RBox" weist außerdem ein Attribut „status" des „sError-Typs, der ein Datentyp ist, der den Fehlercode anzeigt, als den Bereich zum Speichern der den Status des Serverobjekts darstellenden Daten auf.
Der Identifizierer zum Spezifizieren des Datenbereichs „Thread", der mit, dem Objekt korrespondiert, das den Datenbereich „RBox" erzeugt hat (das heißt das Clientobjekt, welches das Verfahren „SendWithRBox" ausgegeben hat), wird in das Attribut „creator" gesetzt. Im mCOOP metaSpace arbeitet das Objekt wie oben beschrieben als ein einzelner Teilprozess, und ein einzelner Datenbereich „Thread" ist einem einzelnen Objekt zugeordnet. Wenn demgemäss der Datenbereich „Thread" vom Attribut „creator" spezifiziert wird, wird das korrespondierende Clientobjekt bestimmt.
Der Wert, der anzeigt, ob das Verarbeitungsresultat des Serverobjekts zurückgebracht worden ist, wird in das Attribut „ready" gesetzt. In anderen Worten ist das Attribut „ready" ein Kennzeichen, das anzeigt, ob die vom Serverobjekt zum Clientobjekt zurückzubringende Resultatsbotschaft fertig (ready) ist.
Der Zeiger des Bereichs zum Speichern der zum Clientobjekt als das Verarbeitungsresultat des Serverobjekts zu übertragenden Botschaft wird in das Attribut „resultMsg" gesetzt.
Der Wert, der die Größe der zum Clientobjekt als das Verarbeitungsresultat des Serverobjekt zu übertragenden Botschaft darstellt, wird in das Attribut „sizeOfResultMsg" gesetzt.
Der den Status des Serverobjekts als die dem Clientobjekt zu berichtende Information anzeigende Code wird in das Attribut „status" gesetzt. Wenn insbesondere die Verarbeitung des Serverobjekts aufgrund des Auftretens einer Ausnahmesituationunterbrechung der normalen Ausführung des Serverobjekts nicht korrekt vollendet wird, wird dem Objekt „mCOOPMailer" vom Objekt „mCOOPFaultHandler" die Botschaft berichtet, die einen Fehler bei der Ausführung einer normalen Verarbeitung anzeigt. Infolgedessen wird der Fehlercode, der den Status des Serverobjekts anzeigt, vom Objekt „mCOOPMailer" in das Attribut „status" gesetzt. Wenn vom Serverobjekt die Verarbeitung korrekt ausgeführt wird, wird der Wert, der anzeigt, dass das Serverobjekt in einem normalen Status ist, in das Attribut „status" gesetzt.
Wenn vom Clientobjekt das Verfahren „Receive" ausgegeben wird, bezieht sich das Clientobjekt auf das Attribut „ready", um festzustellen, ob das Resultat der vom Serverobjekt ausgeführten Verarbeitung zurückgebracht worden ist. Wenn das Verarbeitungsresultat des Serverobjekts zurückgebracht worden ist, bezieht sich das Clientobjekt auf das Attribut „resultMsg", um den Bereich zum Speichern der zum Clientobjekt als das Verarbeitungsresultat des Serverobjekts zu übertragenden Botschaft zu spezifizieren und dadurch die Daten, welche die vom Attribut „sizeOfResultMsg" angezeigte Größe aufweisen, aus dem oben erwähnten Bereich zu lesen. Als ein Resultat wird die zum Clientobjekt zu übertragende Botschaft gelesen und zum Clientobjekt übertragen.
2-4-2 DeliveryBoxA
Bei Ausgabe des Verfahrens „SendWithRBox" wird vom Objekt „mCOOPMailer" der Datenbereich „DeliveryBoxA" reserviert, um Information vom Clientobjekt zum Serverobjekt zu übertragen. Insbesondere wird die Reservierung des Datenbereichs „DeliveryBoxA" durch das Objekt „mCOOPMailer" durch Erzeugung der Fälle einer Klasse (nachfolgend als die „Klasse ,DeliveryBoxA" bezeichnet), welche die in Tabelle 2 gezeigten Attribute aufweist, ausgeführt. In Tabelle 2 ist unter den Attributen der Klasse „DeliveryBoxA" nur eine minimale Anzahl von Attributen, die zum Implementieren der grundlegenden Form eines Botschaftsübergangs im mCOOP metaSpace erforderlich sind, gezeigt. Attribute anders als die in Tabelle 2 gezeigten Attribute können inkludiert sein. Tabelle 2

DeliveryBoxA

RID Void* t_size rBoxID msg sizeOfMsg
Tabelle 2 zeigt, dass die Klasse „DeliveryBoxA" ein Attribut „rBoxID" des „RID"-Typs, der ein Datentyp zum Spezifizieren des Datenbereichs „RBox" ist, ein Attribut „msg" des „void*"-Typs, der ein den Zeiger anzeigender Datentyps ist, und ein Attribut „sizeOfMsg" des „size_t"-Typs, der eine Datengröße zum Bezeichnen der Größe der Daten ist, aufweist.
Der Identifizierer zum Spezifizieren des zur Ausführung eines den Datenbereich „DeliveryBoxA" benutzenden Botschaftsübergangs wird in das Attribut „rBoxID" gesetzt.
Der Zeiger zum Bereich zum Speichern der vom Clientobjekt an das Serverobjekt auszugebenden Botschaft wird in das Attribut „msg" gesetzt.
Der die Größe der vom Clientobjekt an das Serverobjekt auszugebenden Botschaft darstellende Wert wird in das Attribut „sizeOfMsg" gesetzt.
Durch Benutzung des durch Erzeugung der Fälle der Klasse „DeliveryBoxA" reservierten Datenbereichs „DeliveryBoxA" ist das Betriebsystem fähig, die den Datenbereich „RBox" betreffende Information zusammen mit der vom Clientobjekt zum Serverobjekt gesendeten Botschaft zu senden. In anderen Worten ist das Betriebssystem durch Benutzung des Datenbereichs „DeliveryBoxA" fähig, die Botschaft und die Zukunft im mCOOP metaSpace gleichzeitig zu behandeln.
2-4-3 Continuation
Bei Ausgabe des Verfahrens „SendWithContinuation" wird vom Objekt „mDriveMailer" der Datenbereich „Continuation" reserviert, um darin die Information, die das Fortsetzungsverfahren betrifft, zu speichern. Insbesondere wird die Reservierung des Datenbereichs „Continuation" durch das Objekt „mDriveMailer" durch Erzeugung der Fälle einer Klasse (nachfolgend als die „Klasse" ,Continuation'" bezeichnet), welche die in Tabelle 3 gezeigten Attribute aufweist, ausgeführt. In Tabelle 3 ist unter den Attributen der Klasse „Continuation" nur eine minimale Anzahl von Attributen, die zum Implementieren der grundlegenden Form des Botschaftsübergangs im mDrive metaSpace erforderlich sind, gezeigt. Attribute anders als die in Tabelle 3 gezeigten Attribute können inkludiert sein. Tabelle 3

Continuation

ThreadID Selector creator meth
Tabelle 3 zeigt, dass die Klasse „Continuation" ein Attribut „creator" des „ThreadID"-Typs, der ein Datentyp zum Spezifizieren des für jedes Objekt gesetzten Datenbereichs „Thread" ist, und ein Attribut „meth" des „Selector"-Typs, der ein Datentyp zum Bezeichnen des Verfahrens ist, aufweist.
Der Identifizierer zum Spezifizieren des Datenbereichs „Thread", der mit dem Objekt, das den Datenbereich „Continuation" erzeugt hat (das heißt das Clientobjekt, welches. das Verfahren „SendWithContinuation" ausgegeben hat), korrespondiert, wird in das Attribut „creator" gesetzt. Im mDrive metaSpace arbeitet das Objekt, wie oben beschrieben, als ein einzelner Teilprozess (single thread), und ein einzelner Datenbereich „Thread" korrespondiert mit einem einzelnen Objekt. Wenn demgemäss der Datenbereich „Thread" durch das Attribut „creator" spezifiziert wird, wird das korrespondierende Clientobjekt bestimmt.
Der das Fortsetzungsverfahren des Clientobjekts darstellende Wert wird in das Attribut „meth" gesetzt.
Wenn vom Serverobjekt das Verfahren „Kick" ausgegeben wird, bezieht sich das Clientobjekt auf das Attribut „meth", um das Fortsetzungsverfahren des Clientobjekts zu spezifizieren und dadurch das spezifizierte Fortsetzungsverfahren zu starten.
2-4-4 DeliveryBoxB
Bei Ausgabe des Verfahrens „SendWithContinuation" wird vom Objekt „mDriverMailer" der Datenbereich „DeliveryBoxB" resierviert, um Information vom Clientobjekt zum Serverobjekt auszugeben. Insbesondere wird die Reservierung des Datenbereichs „DeliveryBoxB" durch das Objekt „mDriverMailer" durch Erzeugung der Fälle einer Klasse (nachfolgend als die „Klasse" ,DeliveryBoxB'" bezeichnet), welche die in Tabelle 4 gezeigte Attribute aufweist, ausgeführt. In Tabelle 4 ist unter den Attributen der Klasse „DeliveryBoxB" nur eine minimale Anzahl von Attributen, die zum Implementieren der grundlegenden Form des Botschaftsübergangs im mDrive metaSpace erforderlich sind, gezeigt. Attribute anders als die in Tabelle 4 gezeigten Attribute können inkludiert sein.
Tabelle 4

DeliveryBoxB

ContID void* t_size contID msg sizeOfMsg
Tabelle 4 zeigt, dass die Klasse „DeliveryBoxB"" ein Attribut „contID" des „ContID"-Typs, der ein Datentyp zum Bezeichnen des Datenbereichs „Continuation" ist, ein Attribut „msg" des „void*"-Typs, der ein den Zeiger anzeigender Datentyp ist, und ein Attribut „sizeOfMsg" des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist, aufweist.
Der Identifizierer zum Spezifizieren des Datenbereichs „Continuation", der zu dem den Datenbereich „DeliveryBoxB" anwendenden Botschaftsübergang benutzt wird, wird in das Attribut „contID" gesetzt.
Der Zeiger zum Bereich zum Speichern der vom Clientobjekt zum Serverobjekt auszugebenden Botschaft wird in das Attribut „msg" gesetzt.
Der Wert, der die Größe der vom Clientobjekt zum Serverobjekt auszugebenden Botschaft anzeigt, wird in das Attribut „sizeOfMsg" gesetzt.
Durch Benutzung des durch die Erzeugung der Fälle der Klasse „DeliveryBoxB" reservierten Datenbereichs „DeliveryBoxB" ist das Betriebssystem zum Senden der den Datenbereich „Continuation" betreffenden Information zusammen mit der vom Clientobjekt zum Serverobjekt gesendeten Botschaft fähig. In anderen Worten ist das Betriebssystem durch Benutzung des Datenbereichs „DeliveryBoxB" fähig, die Botschaft und die Zukunft im mDrive metaSpace gleichzeitig zu behandeln.
2-4-5 Thread
Im mCOOP metaSpace und im mDrive metaSpace arbeitet, wie oben beschrieben, das Objekt als ein einzelner Teilprozess (single thread), und einem einzelnen Teilprozess ist ein einzelnes Objekt zugeordnet. Die jeden Teilprozess betreffende Information wird im Datenbereich „Thread" als die Information zum Verwalten des Ausführungszustands des Objekts gespeichert. Das heißt, das Betriebssystem reserviert den Datenbereich „Thread" für jedes Objekt, um die Information zum Verwalten des Ausführungszustands des Objekts darin zu speichern.
Als die Information zum Verwalten des Ausführungszustands des Objekts wird beispielsweise die Information, die anzeigt, ob das Objekt im Wartezustand oder im Ausführungszustand ist, im Datenbereich „Thread" gespeichert. Bei Ausführung eines Zukunfts-basierten Botschaftsübergangs wird die Information, welche die Zukunft betrifft, auch im Datenbereich „Thread" gespeichert.
Insbesondere sei nun angenommen, dass das Objekt im mCOOP metaSpace arbeitet. Bei Ausführung eines Zukunfts-basierten Botschaftsübergangs wird der Identifizierer „rBoxID" zum Spezifizieren des zum Botschaftsübergang benutzten Datenbereichs „RBox" durch das Objekt „mCOOPMailer" als die Information, welche die Zukunft betrifft, in dem mit dem Objekt korrespondierenden Datenbereich „Thread" gespeichert.
Es sei nun angenommen, dass das Objekt im mDrive metaSpace arbeitet. Bei Ausführung eines Zukunfts-basierten Botschaftsübergangs wird der Identifizierer „contID" zum Spezifizieren des zum Botschaftsübergang benutzten Datenbereichs „Continuation" durch das Objekt „mDriveMailer" in dem mit dem Objekt korrespondierenden Datenbereich „Thread" gespeichert.
2-5 Botschaftsübergang
Eine detaillierte Beschreibung wird durch Annahme spezieller Szenarien als Beispiele eines durch Benutzung der oben erwähnten Verfahren und Datenbereiche ausgeführten Botschaftsübergangs gegeben.
Die 5 bis 9 stellen ein Verarbeitungsschalten und einen Botschaftsaustausch, die bei einem Botschaftsübergang ausgeführt werden, dar. In den 5 bis 9 bezeichnen die gestrichelten Pfeile ein Verarbeitungsschalten und einen Botschaftsaustausch im Betriebssystem, während die durchgezogenen Pfeile ein Verarbeitungsschalten und einen Botschaftsaustausch vom Gesichtspunkt des Anwendungsprogramms anzeigen.
2-5-1 SendWithRBox() benutzender Botschaftsübergang
Es wird unten eine Beschreibung eines durch Benutzung des Verfahrens „SendWithRBox" im mCOOP metaSpace ausgeführten Botschaftsübergangs, wenn die Verarbeitung in einem normalen Zustand fortschreitet und wenn eine Ausnahmesituation auftritt, gegeben.
2-5-1-1 Wenn die Verarbeitung in einem normalen Zustand ausgeführt wird
Es wird zuerst anhand der 5 eine Beschreibung eines durch Benutzung des Verfahrens „SendWithRBox" im mCOOP metaSpace ausgeführten Botschaftsübergangs, wenn die Verarbeitung in einem normalen Zustand ohne Auftreten einer Ausnahmesituation ausgeführt wird, gegeben.
5 stellt ein grundlegendes Szenario eines durch Benutzung des Verfahrens „SendWithRBox" ausgeführten Botschaftsübergangs zwischen einem im mCOOP metaSpace als ein Anwendungsprogramm arbeitenden Objekt A und einem im mCOOP metaSpace als ein Anwendungsprogramm arbeitenden Objekt B dar. Das heißt, bei diesem Beispiel ist das Objekt A ein Clientobjekt, während das Objekt B ein Serverobjekt ist.
Wenn, wie durch ST1-1 angedeutet, das Objekt A das Verfahren „SendWithRBox" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST1-2 dargestellt, zum Objekt „mCOOPMailer" geschaltet, und die dem Verfahren „SendWithRBox" entsprechend Verarbeitung wird, wie durch ST1-3 angedeutet, durch das Objekt „mCOOPMailer" ausgeführt.
Das Objekt „mCOOPMailer" reserviert zuerst den Datenbereich „RBox" zum Speichern des Resultats der vom Serverobjekt (bei diesem Beispiel das Objekt B) ausgeführten Verarbeitung und setzt den Identifizierer zum Spezifizieren des mit dem Objekt A korrespondierenden Datenbereichs „Thread" im Attribut „creator" des Datenbereichs „RBox".
Das Objekt „mCOOPMailer" reserviert dann den Datenbereich „DeliveryBoxA" und speichert darin den Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" und die durch das Verfahren „SendWithRBox" gesendete Botschaft.
Der Identifizierer „rBoxID" zum Bezeichnen des Datenbereichs „RBox" wird im Datenbereich „DeliveryBoxA" gespeichert, und insbesondere wird der Wert des Identifizierers „rBoxID" zum Spezifizieren des Datenbereichs „RBox" im Attribut „rBoxID" des Datenbereichs „DeliveryBoxA" gesetzt.
Die durch das Verfahren „SendWithRBox" gesendete Botschaft wird im Datenbereich „DeliveryBoxA" gespeichert, und insbesondere wird der Wert des Arguments „msg" des Verfahrens „SendWithRBox" im Attribut „msg" des Datenbereichs „DeliveryBoxA" gesetzt und auch der Wert des Arguments „sizeOfMsg" des Verfahrens „SendWithRBox" im Attribut „sizeOfMsg" des Datenbereichs „DeliveryBoxA" gesetzt.
Danach gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST1-4 angedeutet, die im Datenbereich „DeliveryBoxA" gespeicherten Daten, das heißt die vom Verfahren „SendWithRBox" gesendete Botschaft, und den Identifizierer „rBoxID" zum Spezifizieren des reservierten Datenbereichs „RBox" an das Objekt B aus und startet dadurch das Verfahren des Objekts B.
In diesem Fall wird nur die Botschaft zum Verfahren des Objekts B ausgegeben, und der Identifizierer „rBoxID” wird in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeichert. In anderen Worten ist der an das Objekt B auszugebende Identifizierer „rBoxID" unter der Verwaltung des Betriebssystems, und es ist vom Gesichtspunkt des Anwendungsprogramms nur die Botschaft, die zum Objekt B gesendet wurde.
Beim Starten des Verfahrens des Objekts B durch Ausgeben der im Datenbereich „DeliveryBoxA" gespeicherten Daten vom Objekt „mCOOPMailer" zum Objekt B wird das Objekt B durch das Argument „destObjID" des Verfahrens „SendWithRBox" spezifiziert, und das Verfahren des Objekts B wird durch das Argument „meth" des Verfahrens „SendWithRBox" bezeichnet.
Bei Vollendung der durch den gestrichelten Pfeil ST1-5 dargestellten oben erwähnten Verarbeitung bringt das Objekt „mCOOPMailer" den Identifizierer „rBoxID" zum Spezifizieren des reservierten Datenbereichs „RBox" zum Objekt A zurück und bringt auch den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert des Verfahrens „SendWithRBox" zum Objekt A zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A die Verarbeitung wieder zu starten. Das Objekt A ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben beschriebenen Verarbeitung wird, wie durch den durchgezogenen Pfeil ST1-6 angedeutet, die Botschaft vom Objekt A an des Objekt B ausgegeben, und es ist vom Gesichtpunkt des Anwendungsprogramms, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
Danach wird, wenn das Objekt, wie durch ST1-7 angedeutet, das Verfahren „Receive" ausgibt, die Verarbeitung, wie durch den gestrichelten Pfeil ST1-8 dargestellt, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Receive" wird, wie durch ST1-9 angedeutet, vom Objekt „mCOOPMailer" ausgeführt. Insbesondere bezieht sich das Objekt „mCOOPMailer" auf den vom Argument „rBoxID" des Verfahrens „Receive" bezeichneten Datenbereich „RBox". Wenn das Resultat der vom Objekt B ausgeführten Verarbeitung im Datenbereich „RBox" gespeichert ist, gibt das Objekt „mCOOPMailer" das Resultat zum Objekt A aus. Wenn das Resultat der vom Objekt B ausgeführten Verarbeitung nicht im Datenbereich „RBox" gespeichert ist, schaltet das Objekt „mCOOPMailer den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Wenn bei diesem Beispiel das Objekt A das Verfahren „Receive" ausgegeben hat, hat das Objekt B nicht das Verfahren „Reply" ausgegeben, und infolgedessen ist das Resultat der vom Objekt B ausgeführten Verarbeitung noch nicht im Datenbereich „RBox" gespeichert. Demgemäss informiert das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST1-10 angedeutet, das Objekt A darüber, dass das Verarbeitungsresultat des Objekts B noch nicht im Datenbereich „RBox" gespeichert ist und schaltet den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Danach wird, wenn das Objekt B, wie durch ST1-11 angedeutet, das Verfahren „Reply" ausgibt die Verarbeitung, wie durch den gestrichelten Pfeil ST1-12 angedeutet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung entsprechend dem Verfahren „Reply" wird, wie durch ST1-13 angedeutet, vom Objekt „mCOOPMailer" ausgeführt. Insbesondere gibt, wenn das Objekt A das Verfahren „Receive" schon ausgegeben hat, das Objekt „mCOOPMailer" das Resultat der vom Objekt B ausgeführten Verarbeitung an das Objekt A aus. Wenn das Objekt A das Verfahren „Receive" noch nicht ausgegeben hat, speichert das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts B im Datenbereich „RBox".
Bei diesem Beispiel hat, wenn das Objekt B das Verfahren „Reply" ausgegeben hat, das Objekt A das Verfahren „Receive" schon ausgegeben. Demgemäss gibt das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts B, wie durch den gestrichelten Pfeil ST1-14 dargestellt, direkt an das Objekt A aus, ohne das Verarbeitungsresultat im Datenbereich „RBox" zu speichern. Bei Vollendung der Verarbeitung in einem normalem Zustand zur Ausgabe des Verarbeitungsresultats des Objekts B an das Objekt A bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST1-15 dargestellt, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Reply" zum Objekt B zurück. Das Objekt mCOOPMailer" ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Das Objekt B ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt B die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung wird das Resultat der vom Objekt B ausgeführten Verarbeitung, wie durch den durchgezogenen Pfeil ST1-16 angedeutet, an das Objekt A ausgegeben, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
Bei dem in 5 gezeigten Beispiel ist das Verfahren „Receive" ausgegeben worden, bevor das Verfahren „Reply" ausgegeben wird. Alternativ dazu kann das Verfahren „Receive" ausgegeben werden, nachdem das Verfahren „Reply" ausgegeben worden ist. In diesem Fall ist das Objekt A zum unmittelbaren Empfang des Resultats der vom Objekt B ausgeführten Verarbeitung ohne Eintritt in den Wartezustand fähig.
Wenn das Objekt A das Verfahren „Receive" ausgibt, nachdem das Objekt B das Verfahren „Reply" ausgegeben hat, führt das Objekt „mCOOPMailer" die folgende Verarbeitung aus. Das Objekt „mCOOPMailer" speichert bei Ausgabe des Verfahrens „Reply" durch das Objekt B das Verarbeitungsresultat des Objekts B im Datenbereich „RBox". Dann liest das Objekt „mCOOPMailer", wenn das Objekt A das Verfahren „Receive" ausgibt, unmittelbar das Verarbeitungsresultat des Objekts B aus dem Speicherbereich „RBox" und gibt es an das Objekt A aus.
Das Resultat der vom Objekt B ausgeführten Verarbeitung wird im Datenbereich „RBox" gespeichert. Insbesondere wird der Wert, der anzeigt, dass das Verarbeitungsresultat des Objekts B zurückgebracht worden ist, in das Attribut „ready" des Datenbereichs „RBox" gesetzt, und der Zeiger zum Bereich zum Speichern der an das Objekt A als das Verarbeitungsresultat des Objekts B auszugebenden Botschaft, das heißt der durch das Argument „resultMsg" des Verfahrens „Reply" dargestellte Zeiger wird in das Attribut „resultMsg" des Datenbereichs „RBox" gesetzt, und auch der Wert, der die Größe der an das Objekt A als das Verarbeitungsresultat des Objekts B auszugebenden Botschaft anzeigt, das heißt der durch das Argument „sizeOfResultMsg" des Verfahrens „Reply" dargestellte Wert wird in das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" gesetzt.
Beim Lesen des Verarbeitungsresultats des Objekts B aus dem Datenbereich „RBox" und seiner Ausgabe an das Objekt A liest das Objekt „mCOOPMailer" zuerst das Attribut „resultMsg" und das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" aus dem Datenbereich „RBox", der durch das Argument „rBoxID" des Verfahrens „Receive" spezifiziert ist, und liest dann die Daten mit der Größe, die vom Attribut „sizeOfResultMsg" angezeigt wird, aus dem durch das Attribut „ResultMsg" dargestellten Bereich. Die gelesenen Daten dienen als eine Botschaft, die vom Objekt B an das Objekt A auszugeben ist. Das Objekt „mCOOPMailer" speichert dann die gelesenen Daten in den vom Argument „msg" des Verfahrens „Receive" angezeigten Bereich. Die Größe des vom Argument „msg" des Verfahrens „Receive" bezeichneten Bereichs ist vom Argument „sizeOfMsg" des Verfahrens „Receive" gesetzt worden.
Gemäß der oben beschriebenen Verarbeitung wird, wenn das Verfahren „Receive" ausgegeben wird, nachdem das Verfahren „Reply" ausgegeben worden ist, sowie wenn das Verfahren „Receive" ausgegeben worden ist, bevor das Verfahren „Reply" ausgegeben wird, das Resultat der vom Objekt B ausgeführten Verarbeitung an das Objekt A ausgegeben, und es ist, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
2-5-1-2 Wenn eine Ausnahmesituation auftritt
Es wird nun unten anhand der 6 eine Beschreibung eines durch Benutzung des Verfahrens „SendWithRBox" im mCOOP metaSpace ausgeführten Botschaftsübergangs, wenn eine Ausnahmesituation, welche die normale Verarbeitung des Serverobjekts unterbricht, auftritt, gegeben.
6 stellt ein grundlegendes Szenario eines durch Benutzung des Verfahrens „SendWithRBox" im mCOOP metaSpace ausgeführten Botschaftsübergangs zwischen einem als ein Anwendungsprogramm im mCOOP metaSpace arbeitenden Objekts A und einem als Anwendungsprogramm im mCOOP metaSpace arbeitenden Objekt B dar. Das heißt, bei diesem Beispiel ist das Objekt A ein Clientobjekt, während das Objekt B ein Serverobjekt ist. Es sei nun bei diesem Szenario angenommen, dass die Ausnahmesituation beim Objekt B auftritt, nachdem vom Objekt A das Verfahren „Receive" ausgegeben worden ist, und das Objekt B betriebsunfähig wird.
Bei diesem Szenario sind die in 6 gezeigten Schritte: ST2-1, ST2-2, ST2-3, ST3-4, ST2-5, ST2-6, ST2-7, ST2-8, ST2-9 und ST2-10 ähnlich zu den in 5 gezeigten jeweiligen Schritten ST1-1, ST1-2, ST1-3, ST1-4, ST1-5, ST1-6, ST1-7, ST1-8, ST1-9 bzw. ST1-10, und ihre Erklärung wird infolgedessen fortgelassen.
Bei diesem Szenario tritt nach einem Weitergehen der Verarbeitung zum Schritt ST2-10, wenn das Objekt A im Wartezustand ist und wenn das Objekt B eine Verarbeitung ausführt, eine Ausnahmesituation auf, die eine normale Verarbeitung des Objekts B unterbricht.
Wenn, wie durch ST2-11 angedeutet, eine Ausnahmesituation, welche die normale Verarbeitung des Objekts B unterbricht, auftritt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST2-12 dargestellt, zum Objekt „mCOOPFaultHandler" geschaltet, und, wie durch ST2-13 angedeutet, vom Objekt „mCOOPFaultHandler" eine vorbestimmte Ausnahmesituationsbehandlung ausgeführt. Dann berichtet das Objekt „mCOOPFaultHandler", wie durch den gestrichelten Pfeil ST2-13 angedeutet, dem Objekt „mCOOPMailer", dass das Objekt B aufgrund des Auftretens einer Ausnahmesituation betriebsunfähig geworden ist.
Zu dieser Zeit ist das Objekt A nach Ausgabe des Verfahrens „Receive" im Wartezustand. Dann bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST2-15 angedeutet, den Fehlercode, der anzeigt, dass das Objekt B aufgrund des Auftretens einer Ausnahmesituation betriebsunfähig geworden ist, als den Zurückbringwert bezüglich des Verfahrens „Receive" zum Objekt A zurück und ermöglicht auch dem Objekt A, wieder eine Verarbeitung zu starten. Das Objekt A ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung empfängt das Objekt A, obgleich es unfähig ist, eine Resultatsbotschaft zu empfangen, bei der angenommen wird, dass sie vom Objekt B erhalten wird, den Fehlercode als den Zurückbringwert, der anzeigt, dass das Objekt B betriebsunfähig geworden ist, und ist zu einer Wiederaufnahme der Ausführung einer Verarbeitung fähig. Das Objekt A führt dann die Verarbeitung in Reaktion auf das Auftreten eines Fehlers aus.
Beispielsweise kann die Botschaft, die anzeigt, dass beim Objekt B eine Ausnahmesituation aufgetreten ist, auf einer Bildanzeigeeinheit angezeigt werden, und der Benutzer kann instruiert werden, die Verarbeitung zurückzusetzen. Alternativ dazu kann als eine Alternative zum Objekt B ein Objekt von einer externen Quelle über ein Netzwerk heruntergeladen werden und wieder ein Botschaftsübergang ausgeführt werden.
Bei dem in 6 gezeigten Szenario tritt beim Objekt B eine Ausnahmesituation auf, nachdem vom Objekt A das Verfahren „Receive" ausgegeben worden ist. Jedoch kann beim Objekt B eine Ausnahmesituation auftreten, bevor das Verfahren „Receive" vom Objekt A ausgegeben wird.
Wenn beim Objekt B eine Ausnahmesituation aufgetreten ist, bevor vom Objekt A das Verfahren „Receive" ausgegeben wird, setzt das Objekt „mCOOPMailer" im Attribut „status" des Datenbereichs „RBox" den Fehlercode, der anzeigt, dass das Objekt B aufgrund des Auftretens einer Ausnahmesituation betriebsunfähig geworden ist.
Dann liest, wenn das Objekt A das Verfahren „Receive" ausgibt, das Objekt „mCOOPMailer" den im Attribut „status" des Datenbereichs „RBox" gesetzten Fehlercode und bringt den Fehlercode als den Zurückbringwert bezüglich des. Verfahrens „Receive" zum Objekt A zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A, wieder eine Verarbeitung aufzunehmen. In einer Weise ähnlich zum vorherigen Szenario ist das Objekt A nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt die Verarbeitung wieder.
Wie oben beschrieben wird der Fehlercode, der anzeigt, dass das Objekt B aufgrund des Auftretens einer Ausnahmesituation betriebsunfähig geworden ist, in das Attribut „status" des Datenbereichs „RBox" gesetzt. Dies verhindert, dass das Objekt A bei einer Ausgabe des Verfahrens „Receive" verschwenderisch in den Wartezustand eintritt, und das Objekt A erkennt unmittelbar, dass das Objekt B aufgrund des Auftretens einer Ausnahmesituation betriebsunfähig geworden ist.
Bei den vorhergehenden Szenarios ist eine Ausnahmesituation beim Objekt B aufgetreten. In anderen Fällen wird, wenn ein Resultatübergang aus irgendeinem Grund nicht zum Objekt A zurückgebracht werden kann, der Fehlercode in das Attribut „status" des Datenbereichs „RBox" gesetzt. Bei dieser Konfiguration wird, selbst wenn ein Resultatübergang aus irgendeinem Grund nicht zum Objekt A zurückgebracht werden kann, der Fehlercode zum Objekt A zurückgebracht, so dass das Objekt A vom Wartezustand wieder in den Betriebszustand aufgenommen werden kann, was andernfalls das Objekt A veranlassen würde, in den Wartezustand einzutreten, und das System stoppen würde.
2-5-2 Delegate() benutzender Botschaftsübergang
Es wird unten anhand der 7 eine Beschreibung eines durch Benutzung des Verfahrens „Delegate" ausgeführten Botschaftsübergangs gegeben, der angewendet wird, wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird.
7 stellt ein Szenario eines im mCOOP metaSpace zwischen einem Objekt A, einem Objekt B und einem Objekt C, von denen alle im mCOOP metaSpace als Anwendungsprogramme arbeiten, ausgeführten Botschaftsübergangs dar. Bei diesem Szenario wird die Antwortautorisierung vom Objekt B an das Objekt C delegiert.
Das heißt, bei diesem Beispiel ist das Objekt A ein Clientobjekt, während das Objekt B und das Objekt C Serverobjekte sind. Das Objekt B delegiert an das Objekt C, das Verarbeitungsresultat zum Objekt A zurückzubringen. Das heißt, das Objekt B dient als ein Serverobjekt und auch als ein autorisierungsdelegierendes Objekt. Das Objekt C dient als ein Serverobjekt und auch als ein autorisierungsdelegiertes Objekt.
Wenn das Objekt A, wie durch ST3-1 angedeutet, das Verfahren „SendWithRBox" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST3-2 dargestellt, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung wird, wie durch ST3-3 angedeutet, entsprechend dem Verfahren „SendWithRBox" durch das Objekt „mCOOPMailer" ausgeführt.
Das Objekt „mCOOPMailer" reserviert zuerst den Datenbereich „RBox" zum Speichern des Resultats der vom Serverobjekt ausgeführten Verarbeitung und setzt dann den Identifizierer zum Spezifizieren des mit dem Objekt A korrespondierenden Datenbereichs „Thread" in das Attribut „creator" des Datenbereichs „RBox".
Danach reserviert das Objekt „mCOOPMailer" den Datenbereich „DeliveryBoxA" und speichert darin den Identifizierer „rBoxID" zum Bezeichnen des Datenbereichs „RBox und die vom Verfahren „SendWithRBox" gesendete Botschaft.
Der Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" wird im Datenbereich „DeliveryBoxA" gespeichert. Insbesondere wird der Wert des Identifizierers „rBoxID" zum Bezeichnen des Datenbereichs „RBox" in das Attribut „rBoxID" des Datenbereichs „DeliveryBoxA" gesetzt.
Die vom Verfahren „SendWithRBox" gesendete Botschaft wird im Datenbereich „DeliveryBoxA" gespeichert. Insbesondere wird der Wert des Arguments „msg" des Verfahrens „SendWithRBox" in das Attribut „msg" des Datenbereichs „DeliveryBoxA" gesetzt, und auch der Wert des Arguments „sizeOfMsg" des Verfahrens „SendWithRBox" wird in das Attribut „sizeOfMsg" des Datenbereichs „DeliveryBoxA" gesetzt.
Danach gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-4 angedeutet, die im Datenbereich „DeliveryBoxA" gespeicherten Daten, das heißt die durch das Verfahren „SendWithRBox" gesendete Botschaft, und den Identifizierer „rBoxID" zum Bezeichnen des reservierten Datenbereichs „RBox" an das Objekt B aus und startet dadurch das Verfahren des Objekts B.
In diesem Fall wird nur die Botschaft zum Verfahren des Objekts B gesendet, und der Identifizierer „rBoxID" wird in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeichert. In anderen Worten ist der zum Objekt B auszugebende Identifizierer „rBoxID" unter der Verwaltung des Betriebssystems, und es ist vom Gesichtspunkt des Anwendungsprogramms nur die Botschaft, die zum Objekt B gesendet worden ist.
Beim Starten des Verfahrens des Objekts B durch Ausgabe der im Datenbereich „DeliveryBoxA" gespeicherten Daten vom Objekt „mCOOPMailer" an das Objekt B wird das Objekt B durch das Argument „destObjID" des Verfahrens „SendWithRBox" spezifiziert, und das Verfahren des Objekts B wird durch das Argument „meth" des Verfahrens „SendWithRBox" bezeichnet.
Bei Vollendung der oben erwähnten Verarbeitung bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-5 bezeichnet, den Identifizierer „rBoxID" zum Spezifizieren des reservierten Datenbereichs „RBox" zum Objekt A zurück und bringt auch den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „SendWithRBox" zum Objekt A zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Das Objekt A ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben beschriebenen Verarbeitung ist die Botschaft, wie durch den durchgezogenen Pfeil ST3-6 dargestellt, vom Objekt A zum Objekt B gesendet worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
Danach wird, wie durch ST3-7 angedeutet, bei einer Ausgabe des Verfahrens „Receive" durch das Objekt A die Verarbeitung, wie durch den gestrichelten Pfeil ST3-8 bezeichnet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung wird, wie durch ST3-9 bezeichnet, in Reaktion auf das Verfahren „Receive" durch das Objekt „mCOOPMailer" ausgeführt. Insbesondere bezieht sich das Objekt „mCOOPMailer" auf den durch das Argument „rBoxID" des Verfahrens „Receive" spezifizierten Datenbereich „RBox". Wenn das Resultat der vom Serverobjekt ausgeführten Verarbeitung im Datenbereich „RBox" gespeichert ist, gibt das Objekt „mCOOPMailer" das Resultat an das Objekt A aus. Wenn das Verarbeitungsresultat des Serverobjekts nicht im Datenbereich „RBox" gespeichert ist, ändert das Objekt „mCOOPMailer" den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Bei diesem Beispiel hat, wenn das Objekt A das Verfahren „Receive" ausgegeben hat, das Serverobjekt das Verfahren „Reply" nicht ausgegeben. Demgemäss ist das Resultat der vom Serverobjekt ausgeführten Verarbeitung noch nicht im Datenbereich „RBox" gespeichert. Infolgedessen berichtet das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-10 angedeutet, dem Objekt A, dass das Verarbeitungsresultat des Serverobjekts nicht im Datenbereich „RBox" gespeichert ist, und ändert den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Danach wird, wenn, wie durch ST3-11 angedeutet, das Objekt B das Verfahren „Delegate" ausgibt, die Verarbeitung, wie durch den gestrichelten Pfeil ST3-12 dargestellt, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung wird, wie durch ST3-13 bezeichnet, vom Objekt „mCOOPMailer" entsprechend dem Verfahren „Delegate" ausgeführt.
Insbesondere reserviert das Objekt „mCOOPMailer" zuerst den Datenbereich „DeliveryBoxA". Das Objekt „mCOOPMailer" liest dann den in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeicherten Identifizierer „rBoxID" und setzt den Wert des Identifizierers „rBoxID" in das Attribut „rBoxID" des Datenbereichs „DeliveryBoxA".
Gleichzeitig wird der in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeicherte Identifizierer „rBoxID" gelöscht und dadurch dem Objekt B die Antwortautorisierung entzogen. Das heißt, das Objekt B verliert die Antwortautorisierung durch Ausgabe des Verfahrens „Delegate" und delegiert die Antwortautorisierung an das Objekt C. Da das Objekt B die Antwortautorisierung verloren hat, ist es unfähig zur Ausgabe des Verfahrens „Reply". In anderen Worten hat das Objekt B das Verfahren „Delegate" anstelle des Verfahrens „Reply" ausgegeben.
Das Objekt „mCOOPMailer" speichert auch die vom Verfahren „Delegate" gesendete Botschaft im Datenbereich „DeliveryBoxA". Insbesondere wird der Wert des Arguments „msg" des Verfahrens „Delegate" in das Attribut „msg" des Datenbereichs „DeliveryBoxA" gesetzt, und der Wert des Arguments „sizeOfMsg" des Verfahrens „Delegate" wird auch in das Attribut „sizeOfMsg" des Datenbereichs „DeliveryBoxA" gesetzt.
Das Objekt „mCOOPMailer" gibt dann, wie durch den gestrichelten Pfeil ST3-14 angedeutet, die im Datenbereich „DeliveryBoxA" gespeicherten Daten, das heißt die vom Verfahren „Delegate" gesendete Botschaft, und den Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" an das Objekt C aus und startet dadurch das Verfahren des Objekts C.
In diesem Fall ist nur die Botschaft zum Verfahren des Objekts C gesendet worden, und der Identifizierer „rBoxID" ist in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeichert. In anderen Worten ist der an das Objekt C auszugebende Identifizierer „rBoxID" unter der Verwaltung des Betriebssystems, und es ist vom Gesichtspunkt des Anwendungsprogramms nur die Botschaft, die zum Objekt B gesendet worden ist.
Beim Starten des Verfahrens des Objekts C durch Ausgabe der im Datenbereich „DeliveryBoxA" gespeicherten Daten vom Objekt „mCOOPMailer" an das Objekt C wird das Objekt C durch das Argument „destObjID" des Verfahrens „Delegate" spezifiziert, und das Verfahren des Objekts C wird durch das Argument „meth" des Verfahrens „Delegate" bezeichnet.
Bei Vollendung der oben erwähnten Verarbeitung bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-15 angedeutet, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Delegate" zum Objekt B zurück und ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Das Objekt B ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt B die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung wird, wie durch den durchgezogenen Pfeil ST3-16 dargestellt, die Antwortautorisierung vom Objekt B an das Objekt C delegiert, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt B und das Objekt C gleichzeitig arbeiten würden.
Danach wird, wenn, wie durch ST3-17 angedeutet, das Objekt C das Verfahren „Reply" ausgibt, die Verarbeitung, wie durch den gestrichelten Pfeil ST3-18 bezeichnet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Reply" wird, wie durch ST3-19 dargestellt, durch das Objekt „mCOOPMailer" ausgeführt. Insbesondere gibt, wenn das Objekt A das Verfahren „Receive" schon ausgegeben hat, das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C unmittelbar an das Objekt A aus. Wenn das Objekt A das Verfahren „Receive" noch nicht ausgegeben hat, speichert das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C im Datenbereich „RBox".
Bei diesem Beispiel hat, wenn das Objekt C das Verfahren „Reply" ausgegeben hat, das Objekt A das Verfahren „Receive" schon ausgegeben. Demgemäss gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-20 angedeutet, das Verarbeitungsresultat des Objekts C, ohne es im Datenbereich „RBox" zu speichern, unmittelbar an das Objekt A aus. Bei Vollendung der Verarbeitung zur Ausgabe des Verarbeitungsresultats des Objekts C an das Objekt A in einem normalen Zustand bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST3-21 dargestellt, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Reply" zum Objekt C zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt C, wieder eine Verarbeitung zu starten. Das Objekt C ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt C die Verarbeitung wieder.
Gemäß der oben beschriebenen Verarbeitung ist, wie durch den durchgezogenen Pfeil ST3-22 dargestellt, das Resultat der vom Objekt C ausgeführten Verarbeitung zum Objekt A gesendet worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Bei dem in 7 gezeigten Beispiel ist das Verfahren „Receive" ausgegeben worden, bevor das Verfahren „Reply" ausgegeben wird. Alternativ dazu kann das Verfahren „Receive" ausgegeben werden, nachdem das Verfahren „Reply" ausgegeben worden ist. In diesem Fall ist das Objekt A fähig, das Resultat der vom Objekt C ausgeführten Verarbeitung ohne Eintritt in den Wartezustand unmittelbar zu empfangen.
Wenn das Objekt A das Verfahren „Receive" ausgibt, nachdem das Objekt C das Verfahren „Reply" ausgegeben hat, führt das Objekt „mCOOPMailer" die folgende Verarbeitung aus. Das Objekt „mCOOPMailer" speichert das Verarbeitungsresultat des Objekts C im Datenbereich „RBox", wenn das Verfahren „Reply" vom Objekt C ausgegeben wird. Dann liest, wenn das Objekt A das Verfahren „Receive" ausgibt, das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C unmittelbar aus dem Datenbereich „RBox" und gibt es an das Objekt A aus.
Das Resultat der vom Objekt C ausgeführten Verarbeitung wird im Datenbereich „RBox" gespeichert. Insbesondere wird der Wert, der anzeigt, dass das Verarbeitungsresultat des Objekts C zurückgebracht worden ist, in das Attribut „Ready" des Datenbereichs „RBox" gesetzt, und der Zeiger zum Bereich zum Speichern der an das Objekt A auszugebenden Botschaft als das Verarbeitungsresultat des Objekts C, das heißt der durch das Argument „resultMsg" des Verfahrens „Reply" dargestellte Zeiger, wird in das Attribut „resultMsg" des Datenbereichs „RBox" gesetzt. Außerdem wird der Wert, der die Größe der an das Objekt A als das Verarbeitungsresultat des Objekts C auszugebenden Botschaft anzeigt, das heißt der durch das Argument „sizeOfResultMsg" des Verfahrens „Reply" dargestellte Wert, wird in das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" gesetzt.
Beim Lesen des Verarbeitungsresultats des Objekts C aus dem Datenbereich „RBox" und seiner Ausgabe an das Objekt A liest das Objekt „mCOOPMailer" zuerst das Attribut „ResultMsg" und das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" aus dem Datenbereich „RBox", der vom Argument „rBoxID" des Verfahrens „Receive" spezifiziert ist, und liest dann die Daten, welche die vom Attribut „sizeOfResultMsg" angezeigte Größe aufweisen, aus dem durch das Attribut „ResultMsg" dargestellten Bereich. Die gelesenen Daten dienen als eine vom Objekt C an das Objekt A auszugebende Botschaft. Das Objekt „mCOOPMailer" speichert dann die gelesenen Daten in dem vom Argument „msg" des Verfahrens „Receive angezeigten Bereich. Die Größe des vom Argument „msg" des Verfahrens „Receive" bezeichneten Bereichs ist durch das Argument „sizeOfMsg" des Verfahrens „Receive" gesetzt worden.
Gemäß der oben beschriebenen Verarbeitung wird, wenn das Verfahren „Receive" ausgegeben wird, nachdem das Verfahren „Reply" ausgegeben worden ist, sowie wenn das Verfahren „Receive" ausgegeben worden ist, bevor das Verfahren „Reply" ausgegeben wird, das Resultat der vom Objekt C ausgegebenen Verarbeitung an das Objekt A ausgegeben, und es ist, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Gemäß der vorhergehenden Beschreibung kann durch Einbringen des Verfahrens „Delegate" als eine zur Beschreibung eines Objekts benutzte API, selbst wenn es mehrere Serverobjekte gibt, die Antwortautorisierung zwischen den Serverobjekten delegiert werden. In anderen Worten kann durch Einbringen des Verfahrens „Delegate", selbst wenn es mehrere Serverobjekte gibt, und selbst wenn ein Serverobjekt, das eine Verarbeitungsanforderung empfängt, von einem Serverobjekt, das ein Verarbeitungsresultat zurückbringt, verschieden ist, ein Botschaftsübergang geeignet ausgeführt werden.
Zusätzlich werden mit dem Einbringen des Verfahrens „Delegate" beim Delegieren der Antwortautorisierung zwischen mehreren Serverobjekten der Datenbereich „RBox" und der Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" für die Anwendungsprogramme transparent. Dies verbessert die Einfachheit der Entwicklung von Anwendungsprogrammen.
Wenn das zum Besitzen der Antwortautorität durch das Verfahren „Delegate" delegierte Objekt (bei diesem Beispiel das Objekt C) aufgrund beispielsweise des Auftretens eines Fehlers betriebsunfähig wird und zum Erfassen eines Resultats unfähig ist, wird eine Ausnahmesituationsbehandlung in einer zu dem in 6 gezeigten Szenario ähnlichen Weise ausgeführt.
Insbesondere wird bei dem in 7 gezeigten Beispiel, wenn das zum Besitzen der Antwortautorität durch das Verfahren „Delegate" delegierte Objekt C aufgrund des Auftretens eines Fehlers während einer Ausführung betriebsunfähig wird und zum Erhalten eines Resultats unfähig ist, die Verarbeitung zum Objekt „mCOOPFaultHandler" geschaltet und vom Objekt „mCOOPFaultHandler" eine vorbestimmte Ausnahmesituationsbehandlung ausgeführt. Das Objekt „mCOOPFaultHandler” berichtet dann dem Objekt „mCOOPMailer", dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist.
In diesem Fall bringt, wenn das Objekt A das Verfahren „Receive" schon ausgegeben hat und im Wartezustand ist, das Objekt „mCOOPMailer" den Fehlercode, der anzeigt, dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist, als den Zurückbringwert bezüglich des Verfahrens „Receive" zum Objekt A zurück und ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Infolgedessen ist das Objekt A zum Ausführen einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Andererseits setzt, wenn beim Objekt C eine Ausnahmesituation aufgetreten ist, bevor das Objekt A das Verfahren „Receive" ausgibt, das Objekt „mCOOPMailer" das Attribut „status" des Datenbereichs „RBox" des Fehlercodes, der anzeigt, dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist. Dann liest, wenn das Objekt A das Verfahren „Receive" ausgibt, das Objekt „mCOOPMailer" den in das Attribut „status" des Datenbereichs „RBox" gesetzten Fehlercode und bringt den Fehlercode als den Zurückbringwert bezüglich des Verfahrens „Receive" zum Objekt A zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Demgemäss ist das Objekt A bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung kann, selbst wenn das zum Besitzen der Antwortautorität delegierte Objekt C aus einem gewissen Grund unfähig ist, eine Resultatsbotschaft zum Objekt A zurückzubringen, das Objekt A den Ausführungszustand aus dem Wartezustand, der andernfalls das Objekt veranlassen würde, in den Wartezustand einzutreten, und das System stoppen würde, wieder aufnehmen.
2-5-3 Botschaftsübergang unter Benutzung von Send WithContinuation()
Es wird nun unten anhand der 8 eine Beschreibung eines durch Benutzung des Verfahrens „SendWithContinuation" im mDrive metaSpace ausgeführter Botschaftsübergang gegeben.
8 stellt ein grundlegendes Szenario eines im mDrive metaSpace zwischen einem im mDrive metaSpace als ein Einrichtungstreiber arbeitenden Objekt A und einem im mDrive metaSpace als ein Einrichtungstreiber arbeitenden Objekt B ausgeführten Botschaftsübergang dar. Das heißt bei diesem Beispiel, dass das Objekt A ein Clientobjekt ist, während das Objekt B ein Serverobjekt ist.
Bei 8 ist das Verfahren des Objekts A, welches das Verfahren „SendWithContinuation" ausgibt, durch „A::A1" angedeutet, während das Verfahren des Objekts B, das durch das Verfahren „SendWithContinuation" gestartet wird und auch das Verfahren „Kick" ausgibt, durch „B::B1" angedeutet ist. Außerdem ist das durch das Verfahren „Kick", das heißt das Fortsetzungsverfahren gestartete Verfahren des Objekts A durch „A::A2" angedeutet.
Wenn, wie durch ST4-1 angedeutet, das Objekt A im Verfahren „A:AA1" das Verfahren „SendWithContinuation" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST4-2 dargestellt, zum Objekt „mDriveMailer" geschaltet, und die dem Verfahren „SendWithContinuation" entsprechende Verarbeitung wird, wie durch ST4-3 angedeutet, vom Objekt „mDriveMailer" ausgeführt.
Das Objekt „mDriveMailer" reserviert zuerst den Datenbereich „Continuation" und speichert darin die das Fortsetzungsverfahren betreffende Information. Insbesondere wird der Wert des Identifizierers zum Spezifizieren des mit dem Objekt A korrespondierenden Datenbereichs „Thread" in das Attribut „creator" des Datenbereichs „Continuation" gesetzt, und der Wert des Arguments „contMeth" des Verfahrens „SendWithContinuation" wird auch in das Attribut „meth" des Datenbereichs „Continuation" gesetzt.
Das Objekt „mDriveMailer" reserviert auch den: Datenbereich „DeliveryBoxB" und speichert darin den Identifizierer „contID" zum Bezeichnen des Datenbereichs „Continuation" und die vom Verfahren „SendWithContinuation" gesendete Botschaft. Der Identifizierer „contID" zum Spezifizieren des Datenbereichs „Continuation" wird im Datenbereich „DeliveryBoxB" gespeichert, und insbesondere wird der Wert des Identifizierers „contID" zum Spezifizieren des Datenbereichs „Continuation" in das Attribut „contID" des Datenbereichs „DeliveryBoxB" gesetzt. Außerdem wird die vom Verfahren „SendWithContinuation" gesendete Botschaft im Datenbereich „DeliveryBoxB" gespeichert, und insbesondere wird der Wert des Arguments „msg" des Verfahrens „SendWithContinuation" im Attribut „msg" des Datenbereichs „DeliveryBoxB" gespeichert und wird auch der Wert des Arguments „sizeOfmsg" des Verfahrens „SendWithContinuation" in das Attribut „sizeOfmsg" des Datenbereichs „DeliveryBoxB" gesetzt.
Danach gibt das Objekt „mDriveMailer", wie durch den gestrichelten Pfeil ST4-4 angedeutet, die im Datenbereich „DeliveryBoxB" gespeicherten Daten, das heißt die vom Verfahren „SendWithContinuation" gesendete Botschaft, und den Identifizierer „contID" zum Spezifizieren des Datenbereichs „Continuation" an das Objekt B aus und startet dadurch das Verfahren „B::B1" des Objekts B.
Beim Starten des Verfahrens „B::B1" des Objekts B durch Ausgabe der im Datenbereich „DeliveryBoxB" gespeicherten Daten vom Objekt mDriveMailer" an das Objekt B wird das Objekt B durch das Argument „destObjID" des Verfahrens „SendWithContinuation" spezifiziert, und das Verfahren „B::B1" des Objekts B wird durch das Argument „meth" des Verfahrens „SendWithContinuation" bezeichnet.
Bei Vollendung der oben beschriebenen Verarbeitung bringt das Objekt „mDriveMailer", wie durch den gestrichelten Pfeil ST4-5 angedeutet, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „SendWithContinuation" zum Objekt A zurück und ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Demgemäss ist das Objekt A zum Ausführen einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die. Verarbeitung wieder: Gemäß der oben erwähnten Verarbeitung ist die Botschaft, wie durch den durchgezogenen Pfeil ST4-6 angedeutet, vom Objekt A zum Objekt B gesendet worden, und es ist vom Gesichtspunkt der Einrichtungstreiber, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
Danach führt das Objekt B das Verfahren „B::B1" aus, und bei Vollendung der vom Objekt A angeforderten Verarbeitung gibt das Objekt B, wie durch ST4-7 angedeutet, das Verfahren „Kick" aus. Bei Ausgabe des Verfahrens „Kick" wird die Verarbeitung, wie durch den gestrichelten Pfeil ST4-8 dargestellt, zum Objekt „mDriveMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Kick" wird, wie durch ST4-9 angedeutet, vom Objekt „mDriveMailer" ausgeführt.
Insbesondere spezifiziert das Objekt „mDriveMailer" zuerst den Datenbereich „Continuation" auf Basis des Arguments „contID" des Verfahrens „Kick" und liest dann die im Datenbereich „Continuation" gespeicherte Information.
Als das Attribut „creator" wird der Wert des den mit dem Objekt A korrespondierenden Datenbereich „Thread" bezeichnenden Identifizierers im Datenbereich „Continuation" gespeichert.
Gemäß dem Identifizierer bezeichnet das Objekt „mDriveMailer" das Objekt A als das in Reaktion auf das Verfahren „Kick" zu startende Objekt. Der Wert des Arguments „contMeth" des Verfahrens „SendWithContinuation", das heißt der das Fortsetzungsverfahren „A::A2" spezifizierende Wert, wird in das Attribut „meth" des Datenbereichs „Continuation" gesetzt. Gemäß dem Argument „contMeth" spezifiziert das Objekt „mDriveMailer" das Verfahren „A::A2" als das in Reaktion auf das Verfahren „Kick" zu startende Fortsetzungsverfahren.
Das Objekt „mDriveMailer" startet dann, wie durch den gestrichelten Pfeil ST4-10 angedeutet, das Verfahren des durch die im Datenbereich „Continuation" gespeicherte Information spezifizierten Objekts, das heißt das Verfahren „A::A2" des Objekts A, als das Fortsetzungsverfahren. Beim Starten des Fortsetzungsverfahrens „A::A2" wird die an das Fortsetzungsverfahren „A::A2" auszugebende Botschaft durch die Argumente „msg" und „sizeOfMsg" des Verfahrens „Kick" bezeichnet.
Bei korrekter Vollendung des Starts des Fortsetzungsverfahrens „A::A2" des. Objekts A bringt das Objekt „mDriveMailer", wie durch den gestrichelten Pfeil ST4-11 angedeutet, den Wert, der anzeigt, dass die Verarbeitung des Verfahrens „Kick" korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Kick" zurück. Das Objekt „mDriveMailer" ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Demgemäss ist das Objekt B bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt B die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung wird das Fortsetzungsverfahren „A::A2" des Objekts A. wie durch den durchgezogenen Pfeil ST4-12 bezeichnet, vom Objekt B gestartet, und es ist vom Gesichtspunkt der Einrichtungstreiber, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
2-5-4 Botschaftsübergang zwischen unterschiedlichen metaSpaces
Unten wird anhand der 9 eine Beschreibung eines zwischen dem mCOOP metaSpace und dem mDrive metaSpace durch Benutzung des Verfahrens „Delegate" ausgeführten Botschaftsübergangs gegeben.
Als ein Szenario eines zwischen unterschiedlichen metaSpaces ausgeführten Botschaftsübergangs stellt 9 einen Botschaftsübergang zwischen einem Objekt A, das im mCOOP metaSpace als ein Anwendungsprogramm arbeitet, und einem Objekt B, das im mCOOP metaSpace als ein Anwendungsprogramm arbeitet, und einem Objekt C, das im mDrive metaSpace als ein Einrichtungstreiber arbeitet, dar. Bei diesem Szenario delegiert das Objekt B die Antwortautorisierung an das Objekt C.
Das heißt bei diesem Beispiel, dass das Objekt A ein Clientobjekt ist, während das Objekt B und das Objekt C Serverobjekte sind. Das Objekt B delegiert an das Objekt C das Zurückbringen des Verarbeitungsresultats zum Objekt A. Das heißt, das Objekt B dient als ein Serverobjekt und auch als ein autorisierungsdelegierendes Objekt. Das Objekt C dient als ein Serverobjekt und auch als ein autorisierungsdelegiertes Objekt.
Bei diesem Szenario sind die in 9 gezeigten Schritte ST5-1, ST5-2, ST5-3, ST5-4, ST5-5, ST5-6, ST5-7, ST5-8, ST5-9 und ST5-10 ähnlich zu den in 3 gezeigten jeweiligen Schritten ST3-1, ST3-2, ST3-3, ST3-4, ST3-5, ST3-6, ST3-7, ST3-8, ST3-9 bzw. ST3-10, und eine Erläuterung von ihnen wird infolgedessen fortgelassen.
Bei diesem Szenario gibt, nachdem die Verarbeitung zum Schritt ST5-10 übergeht, wenn das Objekt A im Wartezustand ist und wenn das Objekt B eine Verarbeitung ausführt, das Objekt B das Verfahren „Delegate" zum Delegieren der Antwortautorisierung aus.
Wenn, wie durch ST5-11 angedeutet, das Objekt B das Verfahren „Delegate" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST5-12 dargestellt, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Delegate" wird, wie durch ST5-13 bezeichnet, vom Objekt „mCOOPMailer" ausgeführt.
In diesem Fall stellt das Objekt „mCOOPMailer" fest, ob das autorisierungsdelegierte Objekt ein im mCOOP metaSpace arbeitendes Objekt ist. Wenn gefunden wird, dass das autorisierungsdelegierte Objekt ein im mCOOP metaSpace arbeitendes Objekt ist, geht die Verarbeitung entsprechend dem in 7 gezeigten Szenario weiter. Bei diesem Beispiel ist jedoch das autorisierungsdelegierte Objekt kein im mCOOP metaSpace arbeitendes Objekt, sondern das im mDrive metaSpace arbeitende Objekt C. Demgemäss wird die Verarbeitung, wie durch den gestrichelten Pfeil ST5-14 dargestellt, vom Objekt „mCOOPMailer" zum Objekt „mDriveMailer" geschaltet.
Ein Schalten der Verarbeitung vom Objekt mCOOPMailer" zum Objekt „mDriveMailer" wird über einen Mikrokern ausgeführt. Insbesondere stellt das Objekt „mCOOPMailer" zuerst auf Basis des Arguments „destObjID" des Verfahrens „Delegate” fest, dass der metaSpace, in welchem das autorisierungsdelegierte Objekt arbeitet, ein mDrive metaSpace ist. Danach fordert das Objekt „mCOOPMailer" durch Benutzung der Funktion des Mikrokerns das Objekt „mDriveMailer", das ein metaObject zur Ausführung eines Botschaftsübergangs zwischen den im mDrive metaSpace arbeitenden Objekten ist, auf, die erforderliche Verarbeitung auszuführen. Infolgedessen wird die Verarbeitung vom Objekt „mCOOPMailer" zum Objekt „mDriveMailer" geschaltet.
Auf diese Weise wird, nachdem die Verarbeitung vom Objekt „mCOOPMailer" zum Objekt „mDriveMailer” geschaltet ist, die Verarbeitung, wie durch ST5-15 dargestellt, durch das Objekt „mDriveMailer" entsprechend dem Verfahren „Delegate" ausgeführt.
Insbesondere reserviert das Objekt „mDriveMailer" zuerst den Datenbereich „DeliveryBoxB". Das Objekt „mDriveMailer" liest dann den in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeicherten Identifizierer „rBoxID" und setzt den Identifizierer „rBoxID" in das Attribut „contID" des Datenbereichs „DeliveryBoxB".
Gleichzeitig wird der in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeicherte Identifizierer „rBoxID" gelöscht und dadurch dem Objekt B die Antwortautorisierung entzogen. Das heißt das Objekt B verliert die Antwortautorisierung durch Ausgabe des Verfahrens „Delegate" und delegiert die Antwortautorisierung an das Objekt C. Da das Objekt B die Antwortautorisierung verloren hat, ist es unfähig, das Verfahren „Reply" auszugeben. In anderen Worten hat das Objekt B das Verfahren „Delegate" anstelle des Verfahrens „Reply" ausgegeben.
Das Objekt „mDriveMailer” speichert auch die vom Verfahren „Delegate" gesendete Botschaft im Datenbereich „DeliveryBoxB". Insbesondere wird der Wert des Arguments „msg" des Verfahrens „Delegate" in das Attribut „msg" des Datenbereichs „DeliveryBoxB" gesetzt, und der Wert des Arguments „sizeOfMsg" des Verfahrens „Delegate" wird auch in das Attribut „sizeOfMsg" des Datenbereichs „DeliveryBoxB" gesetzt.
Das Objekt „mDriveMailer" gibt dann, wie durch den gestrichelten Pfeil ST5-16 angedeutet, die im Datenbereich „DeliveryBoxB" gespeicherten Daten, das heißt die vom Verfahren „Delegate" gesendete Botschaft, und den Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" an das Objekt C aus und startet dadurch das Verfahren des Objekts C.
In diesem Fall ist nur die Botschaft zum Verfahren des Objekts C gesendet worden, und der Identifizierer „rBoxID" wird in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeichert. In anderen Worten ist der an das Objekt C auszugebende Identifizierer „rBoxID" unter der Verwaltung des Betriebssystems, und es ist vom Gesichtspunkt des Anwendungsprogramms nur die Botschaft, die zum Objekt C gesendet worden ist.
Beim Starten des Verfahrens des Objekts C durch Ausgabe der im Datenbereich „DeliveryBoxB" gespeicherten Daten vom Objekt „mDriveMailer" an das Objekt C wird das Objekt C durch das Argument „destObjID" des Verfahrens „Delegate" spezifiziert, und das Verfahren des Objekts C wird vom Argument „meth" des Verfahrens „Delegate" bezeichnet.
Bei Vollendung der oben erwähnten Verarbeitung bringt das Objekt „mDriveMailer", wie durch die gestrichelten Pfeile ST5-17 und ST5-18 angedeutet, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Delegate" über das Objekt „mCOOPMailer" zum Objekt B zurück und ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Das Objekt B ist nun zur Ausführung einer Verarbeitung bereit, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung ist, wie durch den durchgezogenen Pfeil ST5-19 angedeutet, die Antwortautorisierung vom Objekt B an das Objekt C delegiert worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt B und das Objekt C gleichzeitig arbeiten würden.
Danach gibt bei Vollendung der vom Objekt A angeforderten Verarbeitung das Objekt C, wie durch ST5-20 bezeichnet, das Verfahren „Kick" aus. Bei Ausgabe des Verfahrens „Kick" wird die Verarbeitung, wie durch den gestrichelten Pfeil ST5-21 dargestellt, zum Objekt „mDriveMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Kick" wird, wie durch ST5-22 angedeutet, durch das Objekt „mDriveMailer" ausgeführt.
Gleichzeitig liest das Objekt „mDriveMailer" die in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeicherte Information. Wenn der den Datenbereich „Continuation" spezifizierende Identifizierer „contID" im Datenbereich „Thread" gespeichert ist, geht die Verarbeitung zum Starten des Fortsetzungsverfahrens entsprechend dem in 8 gezeigten Szenario weiter. Bei diesem Beispiel wird jedoch nicht der den Datenbereich „Continuation" bezeichnende Identifizierer „contID", sondern der den Datenbereich „RBox" spezifizierende Identifizierer „rBoxID" im Datenbereich „Thread" gespeichert.
Da wie oben angegeben der den Datenbereich „RBox" spezifierende Identifizierer „rBoxID" im Datenbereich „Thread" gespeichert ist, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST-23 angedeutet, eher vom Objekt „DriveMailer" zum Objekt „mCOOPMailer" geschaltet, als dass das Fortsetzungsverfahren durch das Objekt „mDriveMailer" gestartet wird.
Ein Schalten der Verarbeitung vom Objekt „mDriveMailer" zum Objekt „mCOOPMailer" wird über den Mikrokern ausgeführt. Insbesondere prüft das Objekt „mDriveMailer" zuerst, ob der in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeicherte Identifizierer der Identifizierer „contID zum Spezifizieren des im mDrive metaSpace benutzten Datenbereichs „Continuation" ist. Bei diesem Beispiel wird festgestellt, dass der in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeicherte Identifizierer nicht der den Datenbereich „Continuation" bezeichnende Identifizierer „contID" ist.
Die Information zum Bestimmen des metaSpace, in welchem das durch Botschaftsübergang zu kommunizierende Objekt arbeitet, wird auch in dem mit jedem Objekt korrespondierenden Datenbereich „Thread" gespeichert. Der in dem mit dem Objekt C korrespondierenden Datenbereich „Thread" gespeicherte Identifizierer ist nicht der Identifizierer „contID" zum Spezifizieren des Datenbereichs „Continuation". Infolgedessen wird der mit dem Objekt C korrespondierende Datenbereich „Thread" weiter geprüft, um den metaSpace zu bestimmen, in welchem das durch Botschaftsübergang zu kommunizierende Objekt arbeitet. Als ein Resultat wird bei diesem Beispiel festgestellt, dass der metaSpace, in welchem das durch Botschaftsübergang zu kommunizierende Objekt arbeitet, ein mCOOP metaSpace ist.
Dann fordert das Objekt „mDriveMailer" durch Benutzung der Funktion des Mikrokerns das Objekt „mCOOPMailer", das ein metaObject zum Ausführen eines Botschaftsübergangs zwischen den im mCOOP metaSpace arbeitenden Objekten ist, auf, die erforderliche Verarbeitung auszuführen. Infolgedessen wird die Verarbeitung vom Objekt „mDriveMailer" zum Objekt „mCOOPMailer" geschaltet.
Auf diese Weise wird, nachdem die Verarbeitung vom Objekt „mDriveMailer" zum Objekt „mCOOPMailer" geschaltet worden ist, die Verarbeitung, wie durch ST5- 24 angedeutet, durch das Objekt „mCOOPMailer" entsprechend dem Verfahren „Kick" ausgeführt.
Insbesondere gibt, wenn das Objekt A schon das Verfahren „Receive" ausgegeben hat, das Objekt „mCOOPMailer" das Resultat der vom Objekt C ausgeführten Verarbeitung an das Objekt A aus. Wenn das Objekt A das Verfahren „Receive" noch nicht ausgegeben hat, speichert das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C im Datenbereich „RBox".
Bei diesem Beispiel hat, wenn das Objekt C das Verfahren „Kick" ausgibt, das Objekt A das Verfahren „Receive" schon ausgegeben. Demgemäss gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST5-25 angedeutet, das Verarbeitungsresultat des Objekts C, ohne es im Datenbereich „RBox" zu speichern, unmittelbar an das Objekt A aus. Bei korrekter Vollendung der Verarbeitung zur Ausgabe des Verarbeitungsresultats des Objekts C bringt das Objekt „mCOOPMailer", wie durch die gestrichelten Pfeile ST5-26 und ST5-27 dargestellt, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Kick" über das Objekt „mDriveMailer" zum Objekt C zurück. Das Objekt „mCOOPMailer” ermöglicht dann dem Objekt C, wieder eine Verarbeitung zu starten. Das Objekt C ist nun bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt C die Verarbeitung wieder.
Gemäß der oben beschriebenen Verarbeitung ist das Resultat der vom Objekt C ausgeführten Verarbeitung, wie durch den durchgezogenen Pfeil ST5-28 angedeutet, zum Objekt A gesendet worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Bei dem in 9 gezeigten Beispiel ist das Verfahren „Receive" ausgegeben worden, bevor das Verfahren „Kick" ausgegeben wird. Alternativ dazu kann das Verfahren „Receive" ausgegeben werden, nachdem das Verfahren „Kick" ausgegeben worden ist. In diesem Fall ist das Objekt A fähig, das Resultat der vom Objekt C ausgeführten Verarbeitung, ohne in den Wartezustand einzutreten, unmittelbar zu empfangen.
Wenn das Objekt A das Verfahren „Receive" ausgibt, nachdem das Objekt C das Verfahren „Kick" ausgegeben hat, führt das Objekt „mCOOPMailer" die folgende Verarbeitung aus. Das Objekt „mCOOPMailer" speichert das Verarbeitungsresultat des Objekts C im Datenbereich „RBox", wenn vom Objekt C das Verfahren „Kick" ausgegeben wird. Wenn dann das Objekt A das Verfahren „Receive" ausgibt, liest das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C unmittelbar aus dem Datenbereich „RBox" und gibt es an das Objekt A aus.
Das Resultat der vom Objekt C ausgeführten Verarbeitung wird im Datenbereich „RBox" gespeichert. Insbesondere wird der Wert, der anzeigt, dass das Verarbeitungsresultat des Objekts C zurückgebracht worden ist, in das Attribut „ready" des Datenbereichs „RBox" gesetzt, und der Zeiger zum Bereich zum Speichern der an das Objekt A als das Verarbeitungsresultat des Objekts C auszugebenden Botschaft, das heißt der vom Argument „msg" des Verfahrens „Kick" dargestellte Zeiger, wird in das Attribut „resultMsg" des Datenbereichs „RBox" gesetzt. Außerdem wird der Wert, der die Größe der an das Objekt A als das Verarbeitungsresultat des Objekts auszugebenden Botschaft anzeigt, das heißt der vom Argument „sizeOfMsg" des Verfahrens „Kick" dargestellte Wert, wird in das Attribut „sizeOfResultMsg" des Datenbereichs „RBox gesetzt.
Beim Lesen des Verarbeitungsresultats des Objekts C aus dem Datenbereich „RBox" und beim Ausgeben desselben an das Objekt A liest das Objekt „mCOOPMailer" zuerst das Attribut „resultMsg" und das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" aus dem Datenbereich „RBox", der vom Argument „rBoxID" des Verfahrens „Receive" spezifiziert ist, und liest dann die Daten, welche die vom Attribut „sizeOfResultMsg" angezeigte Größe aufweisen, aus dem vom Attribut „ResultMsg" dargestellten Bereich. Die gelesenen Daten dienen als eine vom Objekt C an das Objekt A auszugebende Botschaft. Das Objekt „mCOOPMailer" speichert dann die gelesenen Daten in dem vom Argument „msg" des Verfahrens „Receive" angezeigten Bereich. Die Größe des vom Argument „msg" des Verfahrens „Receive" bezeichneten Bereichs ist vom Argument „sizeOfMsg" des Verfahrens „Receive" gesetzt worden.
Wenn gemäß der oben beschriebenen Verarbeitung das Verfahren „Receive" ausgegeben wird, nachdem das Verfahren „Kick" ausgegeben worden ist, sowie wenn das Verfahren „Receive" ausgegeben worden ist, bevor das Verfahren „Kick" ausgegeben wird, wird das Resultat der vom Objekt C ausgeführten Verarbeitung an das Objekt A ausgegeben, und es ist, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Wenn das vom Verfahren „Delegate" zum Besitzen der Antwortautorisierung delegierte Objekt (bei diesem Beispiel das Objekt C) aufgrund beispielsweise des Auftretens eines Fehlers betriebsunfähig wird und unfähig ist, ein Resultat zu erfassen, wird eine Ausnahmesituationsbehandlung in einer zu der des in 6 gezeigten Szenarios im Wesentlichen ähnlichen Weise ausgeführt.
Wenn insbesondere bei dem in 9 gezeigten Beispiel das vom Verfahren „Delegate" zum Besitzen der Antwortautorisierung delegierte Objekt C aufgrund beispielsweise des Auftretens eines Fehlers während der Ausführung betriebsunfähig wird und zum Erhalten eines Resultats unfähig ist, wird die Verarbeitung zum Objekt „mDriveFaultHandler" geschaltet und vom Objekt „mDriveFaultHandler" eine vorbestimmte Ausnahmesituationsbehandlung ausgeführt.
Das Objekt „mDriveFaultHandler" berichtet dann dem Objekt „mCOOPMailer" über das Objekt „mDriveMailer", dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist.
Wenn in diesem Fall das Objekt A das Verfahren „Receive" schon ausgegeben hat und im Wartezustand ist, bringt das Objekt „mCOOPMailer" den Fehlercode, der anzeigt, dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist, zum Verfahren „Receive" als den Zurückbringwert zurück und ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Infolgedessen ist das Objekt A bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Wenn andererseits beim Objekt C eine Ausnahmesituation aufgetreten ist, bevor das Objekt A das Verfahren „Receive" ausgibt, setzt das Objekt „mCOOPMailer" im Attribut „status" des Datenbereichs „RBox" den Fehlercode, der anzeigt, dass das Objekt C aufgrund des Auftretens eines Fehlers betriebsunfähig geworden ist. Wenn dann das Objekt A das Verfahren „Receive" ausgibt, liest das Objekt „mCOOPMailer" den im Attribut „status" des Datenbereichs „RBox" gesetzten Fehlercode und bringt den Fehlercode zum Objekt A als den Zurückbringwert bezüglich des Verfahrens „Receive" zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Demgemäss ist das Objekt A bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung kann, selbst wenn das zum Besitzen der Antwortautorisierung delegierte Objekt C aus irgendeinem Grund unfähig ist, zum Objekt A eine Resultatsbotschaft zurückzubringen, das Objekt A aus dem Wartezustand in den Ausführungszustand gebracht werden, was andernfalls das Objekt A veranlassen würde, in den Wartezustand einzutreten, und das System stoppen würde.
2-6 Anderes Beispiel
Bei der vorhergehenden Ausführungsform wird, um einen Botschaftsübergang bei den Serverobjekten, bei denen eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, das Verfahren „Delegate" zum Delegieren der Antwortautorisierung in den Serverobjekten benutzt. Es ist jedoch möglich, einen Botschaftsübergang ohne die Notwendigkeit, ein Verfahren zum Delegieren der Antwortautorisierung wie beispielsweise das Verfahren „Delegate" anzuwenden, in den Serverobjekten, bei denen sich ein Serverobjekt, das eine Verarbeitungsanforderung empfängt, von einem Serverobjekt, das ein Verarbeitungsresultat zurückbringt, unterscheidet, zu implementieren.
Unten wird eine Beschreibung eines Verfahrens zur Ausführung eines Botschaftsübergangs durch Bereitstellung eines Identifizierers zum Identifizieren, welche Zukunft zum Ausgeben eines Resultats an das Clientobjekt zu benutzen ist, als ein Beispiel eines Verfahrens zum Implementieren des Botschaftsübergangs ohne die Notwendigkeit zur Anwendung des Verfahrens „Delegate" bei den wie oben beschrieben aufgebauten Serverobjekten gegeben.
2-6-1 mCOOP metaSpace API
Bei diesem Beispiel werden das folgende Verfahren „Send" und das Verfahren „GetReplyID" als APIs eingeführt, die zum Beschreiben der im mCOOP metaSpace arbeitenden Objekte benutzt werden. Auch wird das folgende Verfahren „ReplyWithReplyID" anstelle des oben beschriebenen Verfahrens „Reply" benutzt. Bei diesem Beispiel werden die APIs entsprechend dem OMG IDL angezeigt.

SError Send (in OID destObjID, in Selectormeth, in any msg, in size_t sizeOfMsg)
sError GetReplyID (aus ReplyID replyID),
sError ReplyWithReplyID (in ReplyID replyID, in any resultMsg, in size_t sizeOfResultMsg).

Durch Einführung der oben beschriebenen Verfahren "Send", "GetReplyID" und " ReplyWithReplyID" kann ein Botschaftsübergang ohne die Notwendigkeit zur Benutzung des Verfahrens „Delegate" in den Serverobjekten, bei denen eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, ausgeführt werden. Die obigen Verfahren werden unten im Detail beschrieben.
2-6-1-1 Send()

sError Send (in OID destObjID, in Selector meth, in any msg, in size_t sizeOfMsg)

Das Verfahren „Send" ist ein Botschaftssendeverfahren zur Ausführung einer Verarbeitung zum Senden einer Botschaft von einem Clientobjekt zu einem Serverobjekt. Das Verfahren „Send" wird angewendet, wenn das Clientobjekt das Resultat der vom Serverobjekt ausgeführten Verarbeitung nicht braucht, nachdem es die Botschaft zum Serverobjekt gesendet hat.
Das Argument „destObjID" ist ein Argument des „OID"-Typs, der ein Datentyp zum Spezifizieren des Objekts ist. Der Wert zum Spezifizieren des Serverobjekts wird in das Argument „destObjID" gesetzt.
Das Argument „meth" ist ein Argument des „Selector"-Typs, der ein Datentyp zum Bezeichnen des Verfahrens ist. Der Wert zum Bezeichnen des Verfahrens des Serverobjekts, in welchem die angeforderte Verarbeitung beschrieben wird, wird in das Argument „meth" gesetzt.
Das Argument „msg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der an das Serverobjekt auszugebenden Botschaft wird in das Argument „msg" gesetzt.
Das Argument „sizeOfMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der die Größe der an das Serverobjekt auszugebenden Botschaft anzeigende Wert wird in das Argument „sizeOfMsg" gesetzt.
Das Verfahren „Send" erhält den Wert des „sError"-Typs, der ein Datentyp ist, der den Fehlercode aus dem Zurückbringwert darstellt. Das heißt, wenn die Verarbeitung des Verfahrens „Send" bei der Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der den Grund darstellende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als der Zurückbringwert zurückgebracht.
2-6-1-2 GetReplyID()

sError GetReplyID (aus ReplyID replyID)

Wie oben beschrieben wird bei Ausgabe des Verfahrens „Reply" das Resultat über eine Zukunft (das heißt den Datenbereich „RBox") an das Clientobjekt ausgegeben. Das Verfahren „GetReplyID" wird anstelle des Verfahrens „Reply" benutzt und wird angewendet, um einem Serverobjekt zu ermöglichen, den Identifizierer „ReplyID" zu erhalten. Der Identifizierer „ReplyID" ist ein Identifizierer zum Identifizieren, welche Zukunft bei der nachfolgenden Ausgabe des Resultats von einem anderen Serverobjekt zum Clientobjekt zu benutzen ist.
Insbesondere erfasst das Verfahren „GetReplyID" als den Rückgabewert den Identifizierer „ReplyID" des „ReplyID"-Typs, der ein Datentyp zum Spezifizieren der zur Ausgabe des Resultats benutzten Zukunft ist. Der Identifizierer „ReplyID" ist ein Identifizierer zum Identifizieren, welche Zukunft bei der Ausgabe des Resultats an das Clientobjekt zu benutzen ist. In anderen Worten ist der Identifizierer „ReplyID" ein Identifizierer zum Spezifizieren der vom Objekt „mCOOPMailer" reservierten Zukunft, wenn das Verfahren „SendWithRBox" ausgegeben wird.
Der Identifizierer „ReplyID" ist im Wesentlichen der gleiche wie der oben beschriebene Identifizierer „rBoxID", und die zwei Identifizierer können als die gleichen betrachtet werden. Jedoch unterscheidet sich der Zweck de Benutzung für sen Identifizierer „ReplyID" von dem für den Identifizierer „rBoxID". Demgemäss wird bei diesem Beispiel durch Benutzung eines Datentyps für den Identifizierer „ReplyID", der sich von dem für den Identifizierer „rBoxID" unterscheidet, zwischen den zwei Identifizierern eine Differenz beim Zweck der Benutzung erläutert.
Das Verfahren „GetReplyID" erhält den Wert des „sError"-Typs, der ein den Fehlercode als den Zurückbringwert darstellt. Das heißt, wenn die Verarbeitung für das Verfahren „GetReplyID" bei der Ausgabe dieses Verfahrens nicht in einem normalen Zustand vollendet wird, wird der den Grund darstellende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung in einem normalen Zustand vollendet wird, wird der Wert zurückgebracht, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist.
2-6-1-3 ReplyWithReplyID()

sError ReplyWithReplyID (in ReplyID replyID, in any resultMsg, in size_t sizeOfResultMsg)

Das Verfahren „ReplyWithReplyID" wird angewendet, wenn das Serverobjekt das Verarbeitungsresultat zum Clientobjekt zurückbringt, nachdem das Clientobjekt das Verfahren „SendWithRBox" ausgegeben hat. Das Verfahren „ReplyWithReplyID" wird von einem Serverobjekt anstelle des Verfahrens „Reply" benutzt.
Wie oben angegeben wird bei Ausgabe des Verfahrens „Reply" das Resultat über eine Zukunft (das heißt den Datenbereich „RBox") an das Clientobjekt ausgegeben. Das Verfahren „ReplyWithReplyID" wird anstelle des Verfahrens „Reply" angewendet und zur Ausgabe des Resultats von einem Serverobjekt an das Clientobjekt über die vom Identifizierer „ReplyID" spezifizierte Zukunft benutzt.
Das Argument „ReplyID" ist ein Argument des „ReplyID"-Typs, der ein Datentyp zum Spezifizieren der bei Ausgabe des Resultats zu benutzenden Zukunft ist. Der die vom Objekt „mCOOPMailer" reservierte Zukunft bezeichnende Identifizierer wird, wenn das Verfahren „SendWithRBox" ausgegeben worden ist, in das Argument „ReplyID" gesetzt. In anderen Worten wird der Wert des durch Ausgabe des Verfahrens „GetReplyID" erhaltene Identifizierer „ReplyID" in das Argument „ReplyID" gesetzt.
Das Argument „resultMsg" ist ein Argument des „any"-Typs, der ein beliebiger Datentyp ist. Der Zeiger zum Bereich zum Speichern der an das Clientobjekt auszugebenden Botschaft wird in das Argument „resultMsg" gesetzt.
Das Argument „sizeOfResultMsg" ist ein Argument des „size_t"-Typs, der ein Datentyp zum Spezifizieren der Größe der Daten ist. Der die Größe der an das Clientobjekt auszugebenden Botschaft anzeigende Wert wird in das Argument „sizeOfResultMsg" gesetzt.
Das Verfahren „ReplyWithReplyID" erfasst den Wert des „sError"-Typs, der ein den Fehlercode als den Rückgabewert darstellender Datentyp ist. Wenn insbesondere die Verarbeitung für das Verfahren „ReplyWithReplyID" bei Ausgabe dieses Verfahrens nicht korrekt vollendet wird, wird der den Grund darstellende Fehlercode als der Zurückbringwert zurückgebracht. Wenn die Verarbeitung korrekt vollendet wird, wird der Wert zurückgebracht, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist.
Beim Verfahren „ReplyWithReplyID" gibt es eine größere Anzahl der Argumente „ReplyID" der „ReplyID"-Typen als die beim oben erwähnten Verfahren „Reply". Durch Benutzung des Arguments „ReplyID" ist das Objekt „mCOOPMailer" fähig, die beim Zurückbringen des Resultats zum Clientobjekt zu benutzende Zukunft zu spezifizieren, was später beschrieben wird. Dies ermöglicht dem Serverobjekt, das Resultat durch Benutzung eines sich von dem Objekt, das die Botschaft vom Clientobjekt empfangen hat, unterscheidenden Objekts zum Clientobjekt zurückzubringen.
2-6-2 Botschaftsübergang
Es wird nun unten anhand der 10 eine detaillierte Beschreibung eines Beispiels eines speziellen Szenarios eines durch Anwendung der oben beschriebenen Verfahren „Send", „GetReplyID" und „ReplyWithReplyID" bei den Serverobjekten, bei denen eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, ausgeführten Botschaftsübergangs gegeben.
10, die sich auf die folgende Beschreibung bezieht, stellt so wie die 5 bis 9 ein Schalten einer Verarbeitung und eines Botschaftsaustauschs bei einem Botschaftsübergang dar. Die gestrichelten Pfeile in 10 deuten ein Schalten einer Verarbeitung und eines Botschaftsaustauschs im Betriebssystem an, während durchgezogene Pfeile in 10 ein Schalten einer Verarbeitung und eines Botschaftsaustauschs vom Gesichtspunkt der Anwendungsprogramme bezeichnen.
10 stellt ein Szenario eines zwischen einem Objekt A, einem Objekt B und einem Objekt C, die alle im mCOOP metaSpace als Anwendungsprogramme arbeiten, ausgeführten Botschaftsübergangs im mCOOP metaSpace dar. Bei diesem Szenario empfängt das Objekt B eine Botschaft vom Objekt A, und das Objekt C bringt das Verarbeitungsresultat zum Objekt A zurück. Das heißt bei diesem Beispiel, dass das Objekt A ein Clientobjekt ist, während das Objekt B und das Objekt C Serverobjekte sind.
Wenn das Objekt A, wie durch ST6-1 angedeutet, das Verfahren „SendWithRBox" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST6-2 bezeichnet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung wird, wie durch ST6-3 dargestellt, durch das Objekt „mCOOPMailer" entsprechend dem Verfahren „SendWithRBox" ausgeführt.
Das Objekt „mCOOPMailer" reserviert zuerst den Datenbereich „RBox" zum Speichern des Verarbeitungsresultats des Serverobjekts und setzt dann den mit dem Objekt A korrespondierenden Datenbereich „Thread" im Attribut „creator" des Datenbereichs „RBox".
Das Objekt „mCOOPMailer" reserviert dann den Datenbereich „DeliveryBoxA" und speichert darin den Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" und der vom Verfahren „SendWithRBox" gesendeten Botschaft.
Der Identifizierer „rBoxID" zum Bezeichnen des Datenbereichs „RBox" wird im Datenbereich „DeliveryBoxA" gespeichert, und insbesondere wird der Wert des Identifizierers „rBoxID" zum Spezifizieren des Datenbereichs „RBox" in das Attribut „rBoxID des Datenbereichs „DeliveryBoxA" gesetzt.
Die durch das Verfahren „SendWithRBox" gesendete Botschaft wird im Datenbereich „DeliveryBoxA" gespeichert. Insbesondere wird der Wert des Arguments „msg" des Verfahrens „SendWithRBox" in das Attribut „msg" des Datenbereichs „DeliveryBoxA" gesetzt, und der Wert des Arguments „sizeOfMsg" des Verfahrens „SendWithRBox" wird in das Attribut „sizeOfMsg" des Datenbereichs „DeliveryBoxA" gesetzt.
Danach gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-4 dargestellt, die im Datenbereich „DeliveryBoxA" gespeicherten Daten, das heißt die vom Verfahren „SendWithRBox" gesendete Botschaft, und den Identifizierer „rBoxID" zum Bezeichnen des reservierten Datenbereichs „RBox" an das Objekt B aus und startet dadurch das Verfahren des Objekts B.
In diesem Fall wird nur die Botschaft an das Verfahren des Objekts B ausgegeben, und der Identifizierer „rBoxID" wird in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeichert. In anderen Worten ist der an das Objekt B auszugebende Identifizierer „rBoxID" unter der Verwaltung des Betriebssystems, und es ist vom Gesichtspunkt des Anwendungsprogramms nur die Botschaft, die zum Objekt B gesendet wurde.
Beim Starten des Verfahrens des Objekts B durch Ausgabe der im Datenbereich „DeliveryBoxA" gespeicherten Daten vom Objekt „mCOOPMailer" an das Objekt B wird das Objekt B durch das Argument „destObjID" des Verfahrens „SendWithRBox" bezeichnet, und das Verfahren des Objekts B wird durch das Argument „meth" des Verfahrens „SendWithRBox" spezifiziert.
Bei Vollendung der oben beschriebenen Verarbeitung bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-5 angedeutet, den Identifizierer „rBoxID" zum Spezifizieren des reservierten Datenbereichs „RBox" zum Objekt A zurück und bringt auch den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „SendWithRBox" zum Objekt A zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt A, wieder eine Verarbeitung zu starten. Das Objekt A ist nun bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt A die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung ist die Botschaft, wie durch den durchgezogenen Pfeil ST6-6 dargestellt, vom Objekt A an das Objekt B ausgegeben worden, und vom Gesichtspunkt der Anwendungsprogramme ist es, wie wenn das Objekt A und das Objekt B gleichzeitig arbeiten würden.
Wenn danach das Objekt B, wie durch ST6-8 bezeichnet, das Verfahren „GetReplyID" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST6-9 angedeutet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „GetReplyID" wird, wie durch ST6-10 dargestellt, vom Objekt „mCOOPMailer" ausgeführt.
Insbesondere liest das Objekt „mCOOPMailer" den Identifizierer „rBoxID", der in dem mit dem Objekt B korrespondierenden Datenbereich „Thread" gespeichert ist, und bringt dann den Wert des Identifizierers „rBoxID" als den Zurückbringwert bezüglich des Verfahrens „GetReplyID" zurück.
Bei Vollendung der oben beschriebenen Verarbeitung bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-11 bezeichnet, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „GetReplyID" zum Objekt B zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Infolgedessen ist das Objekt B fähig, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, führt das Objekt B die Verarbeitung aus.
Danach wird, wenn durch das Objekt A, wie durch ST6-12 angedeutet, das Verfahren „Receive" ausgegeben wird, die Verarbeitung, wie durch den gestrichelten Pfeil ST6-13 bezeichnet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung entsprechend dem Verfahren „Receive" wird, wie durch ST6-14 dargestellt, vom Objekt „mCOOPMailer" ausgeführt.
Insbesondere bezieht sich das Objekt „mCOOPMailer" auf den durch das Argument „rBoxID" des Verfahrens „Receive" spezifizierten Datenbereich „RBox".
Wenn das Resultat der vom Serverobjekt ausgeführten Verarbeitung im Datenbereich „RBox" gespeichert wird, gibt das Objekt „mCOOPMailer" das Resultat an das Objekt A aus. Wenn das Verarbeitungsresultat des Serverobjekts nicht im Datenbereich „RBox" gespeichert wird, ändert das Objekt „mCOOPMailer" den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Wenn bei diesem Beispiel das Objekt A das Verfahren „Receive" ausgibt, ist das Resultat der vom Serverobjekt ausgeführten Verarbeitung noch nicht im Datenbereich „RBox" gespeichert. Demgemäss berichtet das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-15 dargestellt, dem Objekt A, dass das Verarbeitungsresultat des Serverobjekts noch nicht im Datenbereich „RBox" gespeichert ist, und ändert den Zustand des Objekts A vom Ausführungszustand in den Wartezustand.
Wenn danach das Objekt B, wie es durch ST6-16 angedeutet, das Verfahren „Send" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST6-17 bezeichnet, zum Objekt „mCOOPMailer" geschaltet, und die Verarbeitung in Reaktion auf das Verfahren „Send" wird, wie durch ST6-18 dargestellt, vom Objekt „mCOOPMailer" ausgeführt.
Insbesondere liest das Objekt „mCOOPMailer" zuerst die Daten, welche die vom Argument „sizeOfMsg" aus dem vom Argument „msg" des Verfahrens „Send" bezeichneten Bereich angezeigte Größe aufweisen. Die gelesenen Daten dienen als eine vom Objekt B an das Objekt C auszugebende Botschaft. Das Objekt mCOOPMailer" gibt dann, wie durch ST6-19 angedeutet, die Botschaft an das Objekt C aus und startet dadurch das Verfahren des Objekts C.
Das Objekt C wird durch das Argument „destObjID" des Verfahrens „Send" spezifiziert, und das Verfahren des Objekts C wird durch das Argument „meth" des Verfahrens „Send" bezeichnet. Bei Ausgabe des Verfahrens „Send" ist die durch die Ausgabe des Verfahrens „GetReplyID" erhaltene Information betreffend den Identifizierer „ReplyID" in der durch das Verfahren „Send" an das Objekt C auszugebenden Botschaft inkludiert. Dies macht es möglich, die zum Spezifizieren der bei der Ausgabe des Resultats an das Clientobjekt zu benutzenden Zukunft erforderliche Information vom Objekt B an das Objekt C auszugeben.
Bei Vollendung der oben erwähnten Verarbeitung bringt das Objekt „mCOOPMailer, wie durch den gestrichelten Pfeil ST6-20 dargestellt, den Wert, der anzeigt, dass die Verarbeitung korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „Send" zum Objekt B zurück und ermöglicht dann dem Objekt B, wieder eine Verarbeitung zu starten. Folglich ist das Objekt B bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt B die Verarbeitung wieder.
Gemäß der oben erwähnten Verarbeitung ist die Botschaft, wie durch den durchgezogenen Pfeil ST6-21 angedeutet, vom Objekt B an das Objekt C ausgegeben worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt B und das Objekt C gleichzeitig arbeiten würden.
Wenn danach das Objekt C, wie durch ST6-22 angedeutet, das Verfahren „ReplyWithReplyID" ausgibt, wird die Verarbeitung, wie durch den gestrichelten Pfeil ST6-23 bezeichnet, zum Objekt „mCOOPMailer" geschaltet. Der Wert des Identifizierers „ReplyID" zum Spezifizieren der bei der Ausgabe des Resultats an das Clientobjekt benutzten Zukunft wird in das Argument „ReplyID" des Verfahrens „ReplyWithReplyID" gesetzt. Gemäß dem Identifizierer „ReplyID" wird der bei Ausgabe des Resultats an das Clientobjekt benutzte Datenbereich „RBox" spezifiziert.
Das Objekt „mCOOPMailer" führt dann, wie durch ST6-24 dargestellt, die Verarbeitung in Reaktion auf das Verfahren „ReplyWithReplyID" aus. Wenn insbesondere das Objekt A das Verfahren „Receive" schon ausgegeben hat, gibt das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C an das Objekt A aus. Wenn das Objekt A das Verfahren „Receive" noch nicht ausgegeben hat, speichert das Objekt „mCOOPMailer" das Verarbeitungsresultat des Objekts C im Datenbereich „RBox".
Wenn bei diesem Beispiel das Objekt C das Verfahren „ReplyWithReplyID" ausgibt, hat das Objekt A das Verfahren „Receive" schon ausgegeben. Demgemäss gibt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-25 angedeutet, das Verarbeitungsresultat des Objekts C unmittelbar an das Objekt A aus, ohne es im Datenbereich „RBox" zu speichern. Bei korrekter Vollendung der Verarbeitung für die Ausgabe des Verarbeitungsresultats des Objekts C an das Objekt A bringt das Objekt „mCOOPMailer", wie durch den gestrichelten Pfeil ST6-26 dargestellt, den Wert, der anzeigt, dass die Arbeit korrekt vollendet worden ist, als den Zurückbringwert bezüglich des Verfahrens „ReplyWithReplyID" zum Objekt C zurück. Das Objekt „mCOOPMailer" ermöglicht dann dem Objekt C, wieder eine Verarbeitung zu starten. Das Objekt C ist nun bereit, eine Verarbeitung auszuführen, und wenn es irgendeine verbleibende Verarbeitung gibt, startet das Objekt C die Verarbeitung wieder.
Gemäß der oben beschriebenen Verarbeitung ist, wie durch den durchgezogenen Pfeil ST6-27 bezeichnet, das Resultat der vom Objekt C ausgeführten Verarbeitung an das Objekt A ausgegeben worden, und es ist vom Gesichtspunkt der Anwendungsprogramme, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Bei dem in 10 gezeigten Beispiel ist das Verfahren „Receive" ausgegeben worden, bevor das Verfahren „ReplyWithReplyID" ausgegeben wird. Alternativ dazu kann das Verfahren „Receive” ausgegeben werden, nachdem das Verfahren „ReplyWithReplyID" ausgegeben worden ist. In diesem Fall ist das Objekt A fähig, das Resultat der vom Objekt C ausgeführten Verarbeitung unmittelbar zu empfangen, ohne in den Wartezustand einzutreten.
Wenn das Objekt A das Verfahren „Receive" ausgibt, nachdem das Objekt C das Verfahren „ReplyWithReplyID" ausgegeben hat, führt das Objekt „mCOOPMailer" die folgende Verarbeitung aus. Das Objekt „mCOOPMailer" speichert das Verarbeitungsresultat des Objekts C im Datenbereich „RBox", wenn das Verfahren „ReplyWithReplyID" vom Objekt C ausgegeben wird. Wenn dann das Objekt A das Verfahren „Receive" ausgibt, liest der „mCOOPMailer" das Verarbeitungsresultat des Objekts C unmittelbar aus dem Datenbereich „RBox" und gibt es an das Objekt A aus.
Der Datenbereich „RBox" zum Speichern des Verarbeitungsresultats des Objekts C wird durch das Argument „ReplyID" des Verfahrens „ReplyWithReplyID" bezeichnet. Insbesondere wird, wie oben beschrieben, der Wert des Identifizierers „ReplyID" zum Spezifizieren der bei der Ausgabe des Resultats an das Clientobjekt zu benutzenden Zukunft in das Argument „ReplyID" des „ReplyWithReplyID" gesetzt und dadurch der bei der Ausgabe des Resultats an das Clientobjekt benutzte Datenbereich „RBox" spezifiziert.
Das Resultat der vom Objekt C ausgeführten Verarbeitung wird im Datenbereich „RBox" gespeichert. Insbesondere wird der Wert, der anzeigt, dass das Verarbeitungsresultat des Objekts C zurückgebracht worden ist, in das Attribut „ready" des Datenbereichs „RBox" gesetzt, und der Zeiger zum Bereich zum Speichern der an das Objekt A als das Verarbeitungsresultat des Objekts C auszugebenden Botschaft, das heißt der durch das Argument „resultMsg" des Verfahrens ReplyWithReplyID" dargestellte Zeiger, wird in das Attribut „resultsMsg" des Datenbereichs „RBox" gesetzt. Außerdem wird der Wert, der die Größe der an das Objekt A als das Verarbeitungsresultat des Objekts C auszugebenden Botschaft, das heißt der Wert, der durch das Argument „sizeOfResultMsg" des Verfahrens ReplyWithReplyID" dargestellt wird, in das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" gesetzt.
Beim Lesen des Verarbeitungsresultats des Objekts C aus dem Datenbereich „RBox" und Ausgeben desselben an das Objekt A liest das Objekt „mCOOPMailer" zuerst das Attribut „resultMsg" und das Attribut „sizeOfResultMsg" des Datenbereichs „RBox" aus dem Datenbereich „RBox", der durch das Argument „rBoxID" des Verfahrens „Receive" spezifiziert ist, und liest dann die Daten, welche die durch das Attribut „sizeOfResultMsg" angezeigte Größe aufweisen, aus dem durch das Attribut „resultMsg" dargestellten Bereich. Die gelesenen Daten dienen als eine vom Objekt C an das Objekt A auszugebende Botschaft. Das Objekt „mCOOPMailer" speichert dann die gelesenen Daten in dem durch das Argument „msg" des Verfahrens „Receive" angezeigten Bereich. Die Größe des durch das Argument „msg" des Verfahrens „Receive" bezeichneten Bereichs ist durch das Argument „sizeOfMsg" des Verfahrens „Receive" gesetzt worden.
Gemäss der oben beschriebenen Verarbeitung wird, wenn das Verfahren „Receive" ausgegeben wird, nachdem das Verfahren „ReplyWithReplyID" ausgegeben worden ist, sowie wenn das Verfahren „Receive" ausgegeben worden ist, bevor das Verfahren „ReplyWithReplyID" ausgegeben wird, das Resultat der vom Objekt C ausgeführten Verarbeitung an das Objekt A ausgegeben, und es ist, wie wenn das Objekt A und das Objekt C gleichzeitig arbeiten würden.
Gemäß der obigen Beschreibung kann durch Einbringen der Verfahren „Send", „GetReplyID" und „ReplyWithReplyID" als die zur Beschreibung der Objekte benutzten APIs ein Botschaftsübergang implementiert werden, selbst wenn es mehrere Servierobjekte gibt und selbst wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Servierobjekte zurückgebracht wird.
2-6-3 Vergleich mit einem Delegate() benutzenden Botschaftsübergang
Wie oben beschrieben kann durch Einbringen der Verfahren „Send", „GetReplyID" und „ReplyWithReplyID" ein Botschaftsübergang implementiert werden, selbst wenn es mehrere Servierobjekte gibt und selbst wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird. Jedoch gibt es bei diesem Verfahren ein Problem, wenn es zum Laufenlassen eines Anwendungsprogramms oder eines Betriebssystems benutzt wird.
Bevor das Verfahren „GetReplyID" und das Verfahren „ReplyWithReplyID" eingebracht werden, wird die Beziehung zwischen dem Clientobjekt, das die Botschaft gesendet hat, und der Zukunft oder die Beziehung zwischen der Zukunft und dem Serverobjekt, das die Botschaft empfangen hat, konstant vom Betriebssystem verwaltet.
Jedoch durch das Einbringen des Verfahrens „GetReplyID" und des Verfahrens „ReplyWithReplyID" kann die Information, welche die Zukunft betrifft, zwischen den das Anwendungsprogramm bildenden Objekten durch Ausgabe der Botschaft zwischen ihnen ohne die Störung des Betriebssystems gesendet und empfangen werden. Das heißt, nach Erhalten des Identifizierers „ReplyID" durch Ausgabe des Verfahrens „GetReplyID" kann die Information, welche die Zukunft betrifft, (das heißt der Identifizierer „ReplyID") als eine Botschaft empfangen und gesendet werden. Es ist infolgedessen möglich, die Information, welche die Zukunft betrifft, zwischen den Objekten des Anwendungsprogramms ohne die Störung des Betriebssystems zu senden und empfangen.
Auf diese Weise wird, wenn die Information, welche die Zukunft betrifft, zwischen den Objekten des Anwendungsprogramms ohne Störung des Betriebssystems gesendet und empfangen wird, es für das Betriebssystem unmöglich, die Beziehung zwischen dem Clientobjekt und der Zukunft oder die Beziehung zwischen der Zukunft und dem Serverobjekt zu verwalten.
Wenn im obigen Zustand ein Botschaftsübergang ausgeführt wird, kann das System nicht wieder gestartet werden, wenn beispielsweise eine Ausnahmesituation auftritt.
Beispielsweise sei nun angenommen, dass beim Objekt „mCOOPMailer" eine Ausnahmesituation auftritt und das Verarbeitungsresultat des Serverobjekts unfähig ist, zum Clientobjekt zurückgebracht zu werden, wenn das Clientobjekt über eine Zukunft auf das Verarbeitungsresultat des Serverobjekts wartet.
Wenn in diesem Zustand die Beziehungen zwischen den Objekten nicht unter der Verwaltung des Betriebssystems sind, kann die Information, die anzeigt, dass beim Objekt „mCOOPMailer" eine Ausnahmesituation aufgetreten ist, nicht dem Clientobjekt, das im Wartezustand ist, berichtet werden. Dies veranlasst das Clientobjekt, im Wartezustand zu bleiben.
Wenn das im Wartezustand bleibende Objekt, wie oben beschrieben, nicht in den Wartezustand gebracht werden kann, sieht es für den Benutzer aus, dass das System aus einem unbekannten Grund gestoppt hat. Es wird gewünscht, dass das Betriebssystem eine Funktion zu einem stabilen Betreiben von auf dem Betriebssystem laufender Software bereitstellt. Demgemäss ist es für den Benutzer ein ernsthaftes Problem, dass das System aus einem unbekannten Grund gestoppt hat.
Das oben beschriebene Problem entsteht aus der Tatsache, dass es für das Betriebssystem unmöglich wird, die Beziehung zwischen dem Clientobjekt und der Zukunft oder die Beziehung zwischen der Zukunft und dem Serverobjekt zu verwalten, wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat von anderen Serverobjekten zurückgebracht wird. Demgemäss kann das oben beschriebene Problem gelöst werden, wenn die Beziehung zwischen dem Clientobjekt und der Zukunft oder die Beziehung zwischen der Zukunft und dem Serverobjekt konstant unter der Verwaltung des Betriebssystems ist.
Insbesondere ist anstelle einer Bereitstellung der APIs, welche die Information der Zukunft direkt behandeln, beispielsweise das Verfahren „GetReplyID" und das Verfahren „ReplyWithReplyID", das Verfahren „Delegate" zum Delegieren der Autorisierung für die Ausgabe des Resultats an ein anderes Objekt bereitgestellt.
Durch eher Benutzen des Verfahrens „Delegate" als des Verfahrens „GetReplyID" und des Verfahrens „ReplyWithReplyID" wird es für das Betriebssystem möglich, die Beziehung zwischen dem Clientobjekt und der Zukunft oder die Beziehung zwischen der Zukunft und dem Serverobjekt konstant zu verwalten, selbst wenn es mehrere Serverobjekte gibt und selbst wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird. Das oben erwähnte Problem kann auf diese Weise gelöst werden.
Durch Einbringen des Verfahrens „Delegate" wird die Information, welche die Zukunft betrifft, nicht durch Ausgeben einer Botschaft zwischen den Objekten des Anwendungsprogramms gesendet und empfangen, sondern wird unter der Verwaltung des Betriebssystems durch Benutzung des Datenbereichs „DeliveryBoxA" gesendet und empfangen.
Demgemäss wird die Information der Zukunft immer unter der Verwaltung des Betriebssystems ausgegeben, was andernfalls das Betriebssystem an der Verwaltung der Beziehung zwischen dem Clientobjekt und der Zukunft oder der Verwaltung zwischen der Zukunft und dem Serverobjekt hindern würde. Als ein Resultat kann verhindert werden, dass das Clientobjekt aufgrund beispielsweise des Auftretens eines Fehlers im Wartezustand bleibt, und dadurch das System weiter konsolidiert werden.
Durch Einbringen des Verfahrens „Delegate" werden beim Delegieren der Antwortautorisierung zwischen den Serverobjekten der Datenbereich „RBox" und der Identifizierer „rBoxID" zum Spezifizieren des Datenbereichs „RBox" für das Anwendungsprogramm transparent. Dies verbessert die Einfachheit der Entwicklung von Anwendungsprogrammen.
Wie der vorhergehenden detaillierten Beschreibung zu entnehmen ist, bietet die vorliegende Erfindung die folgenden Vorteile. Bei der Ausführung eines Zukunftsbasierten Botschaftsübergangs kann die Autorisierung für die Ausgabe des Resultats an ein anderes Objekt delegiert werden. Selbst wenn es infolgedessen mehrere Serverobjekte gibt und selbst wenn eine Verarbeitungsanforderung empfangen wird und ein Verarbeitungsresultat durch andere Serverobjekte zurückgebracht wird, kann ein Botschaftsübergang geeignet ausgeführt werden.

Claims

Datenverarbeitungsverfahren, bei dem von einem Clientobjekt (20) zu einem ersten (30) von zwei oder mehr Serverobjekten eine Mitteilung gesendet (ST3-6) wird und das erste der Server-Objekte in Reaktion auf eine Anforderung (ST3-1) in der Mitteilung eine Verarbeitung ausführt und das gleiche oder ein anderes Serverobjekt ein Resultat der Verarbeitung zum Clientobjekt (20) zurücksendet, wobei das Verfahren die Schritte aufweist: Reservieren eines Datenbereichs zum Speichern des Resultats der Verarbeitung, die vom wenigstens ersten Serverobjekt (30) beim Senden (ST3-6) der Mitteilung (ST3-1) vom Clientobjekt (20) zum ersten Serverobjekt (30) auszuführen ist, das erste Clientobjekt (30) delegiert eine Autorisierung zu einem zweiten Serverobjekt (40), um das Resultat der Verarbeitung, die vom wenigstens ersten Serverobjekt bezüglich des Clientobjekts (20) bei Ausführung der Verarbeitung durch das erste Serverobjekt (30) in Reaktion auf die Anforderung (ST3-1) in der Mitteilung ausgeführt wird, zurückzusenden, das zweite Serverobjekt (40) speichert (ST3-17) im Datenbereich das Resultat der vom wenigstens ersten Serverobjekt (30) ausgeführten Verarbeitung, wobei das zweite Serverobjekt (40) das neuest delegierte (ST3-16) ist, das die Autorisierung aufweist, und Empfangen (ST3-22) des Resultats der vom wenigstens ersten Serverobjekt (30) durch Lesen der im Datenbereich gespeicherten Daten ausgeführten Verarbeitung vom Clientobjekt (20), dadurch gekennzeichnet, dass: das Verfahren außerdem die Benutzung eines Metaobjekts (50) zur Ausführung eines Mitteilungsübergangs zwischen dem Clientobjekt (20) und den Serverobjekten (30, 40) aufweist, wobei das Senden (ST3-6) der Mitteilung aufweist: das Clientobjekt (20) sendet (ST3-2) eine Anforderung zur Verarbeitung zum Metaobjekt (50) und das Metaobjekt (50) gibt die Mitteilung vom Clientobjekt (20) an das erste Serverobjekt (30) ab, wobei das Metaobjekt (50) den Reservierungsschritt (ST3-3) ausführt, wobei das erste Serverobjekt (30) die Verarbeitung in Reaktion auf die Mitteilung startet, wobei der Delegierungsschritt (ST3-16) aufweist: das erste Serverobjekt (30) sendet (ST3-12) eine Autorisierung zu einem Zurücksenden des Verarbeitungsresultats zum Metaobjekt (50) und das Metaobjekt gibt (ST3-14) die vom ersten Serverobjekt (30) gesendete Mitteilung an das zweite Serverobjekt (40) ab, wobei der Speicherschritt (ST3-17) aufweist: das zweite Serverobjekt (40) sendet (ST3-18) das Verarbeitungsresultat zum Metaobjekt (50) und das Metaobjekt (50) speichert (ST3-19) das Verarbeitungsresultat im Datenbereich, und wobei der Empfangsschritt (ST3-22) aufweist: das Metaobjekt (50) gibt (ST3-20) nach Anforderung (ST3-8) durch das Clientobjekt (20) das Verarbeitungsresultat an das Clientobjekt (20) ab.
Datenverarbeitungsverfahren nach Anspruch 1, außerdem aufweisend die Schritte: Steuern des Clientobjekts (20) zu einer Fortsetzung der Verarbeitung, nachdem das Clientobjekt (20) die Mitteilung (ST3-1) zum ersten Serverobjekt (30) gesendet (ST3-6) hat, und zu einem Lesen (ST3-8) der im Datenbereich gespeicherten Daten, wenn das Clientobjekt (20) das Resultat der vom ersten Serverobjekt (30) ausgeführten Verarbeitung anfordert, und Steuern (ST3-10) des Clientobjekts (20) zu einer Eingabe eines Wartezustands, wenn das Resultat der vom ersten Serverobjekt (30) ausgeführten Verarbeitung beim Lesen (ST3-8) der im Datenbereich gespeicherten Daten nicht gespeichert ist, und zu einem Veranlassen des Clientobjekts (20) zu einem Bleiben im Wartezustand, bis das Resultat der vom ersten Serverobjekt (30) ausgeführten Verarbeitung im Datenspeicherbereich gespeichert (ST3-18) ist.
Datenverarbeitungsverfahren nach Anspruch 1 oder 2, wobei das Clientobjekt (20) in einer ersten Programmausführungsumgebung ist und die Serverobjekte (30, 40) jeweils in einer von der ersten und zweiten Programmausführungsumgebung sind und der Datenbereich in der ersten Programmausführungsumgebung ist.
Datenverarbeitungsverfahren nach Anspruch 1, 2 oder 3, wobei der Delegierungsschritt (ST3-16) außerdem eine Autorisierung bezüglich eines zweiten Serverobjekts (40) zu einer Fortsetzung der Verarbeitung entsprechend der Mitteilung (ST3-1) vor einem Zurücksenden (ST3-18) des Resultats der Verarbeitung aufweist.
Aufzeichnungsmedium (6), auf dem ein Betriebssystem aufgezeichnet ist, wobei das Betriebssystem ein Mitteilungssendungsmittel zum Senden (ST3-6) einer Mitteilung von einem Clientobjekt (20) zu einem (30) von wenigstens zwei Serverobjekten und ein Autorisierungsdelegierungsmittel zum Delegieren (ST3-11) einer Autorisierung zum anderen (40) der Serverobjekte aufweist, wobei das Mitteilungssendungsmittel und das Autorisierungsdelegierungsmittel als. Anwendungsprogrammschnittstellen zur Beschreibung von Objekten benutzt werden, wobei das Betriebssystem bei einer Benutzung die Schritte entsprechend einem Verfahren nach einem der Ansprüche 1 bis 4 ausführt.
Aufzeichnungsmedium (6) nach Anspruch 5, wobei das Betriebssystem ein Datenlesemittel zum Lesen der im Datenbereich gespeicherten Daten als eine zur Beschreibung eines Objekts benutzte Anwendungsprogrammschnittstelle (mCOOP meta Space) aufweist.
Aufzeichnungsmedium (6) nach Anspruch 5 oder 6, wobei das Betriebssystem das Clientobjekt (20) veranlasst, in einen Wartezustand einzutreten, wenn das Resultat der vom ersten Serverobjekt (30) ausgeführten Verarbeitung beim Lesen (ST3-8) der im Datenbereich gespeicherten Daten entsprechend dem Datenlesemittel nicht im Datenbereich gespeichert ist, und das Clientobjekt (20) veranlasst, im Wartezustand zu bleiben, bis das Resultat der vom ersten Serverobjekt (30) ausgeführten Verarbeitung vom zweiten Serverobjekt (40) im Datenbereich gespeichert ist (ST3-18).
Datenverarbeitungsgerät, das ein Aufzeichnungsmedium (6) nach einem der Ansprüche 5 bis 7 aufweist.