DE69837825T2 - Datenübertragungsverfahren - Google Patents

Datenübertragungsverfahren Download PDF

Info

Publication number
DE69837825T2
DE69837825T2 DE69837825T DE69837825T DE69837825T2 DE 69837825 T2 DE69837825 T2 DE 69837825T2 DE 69837825 T DE69837825 T DE 69837825T DE 69837825 T DE69837825 T DE 69837825T DE 69837825 T2 DE69837825 T2 DE 69837825T2
Authority
DE
Germany
Prior art keywords
meta
message
future
tag
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69837825T
Other languages
English (en)
Other versions
DE69837825D1 (de
Inventor
Koichi Shinagawa-ku Moriyama
Seiji Shinagawa-ku Murata
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of DE69837825D1 publication Critical patent/DE69837825D1/de
Application granted granted Critical
Publication of DE69837825T2 publication Critical patent/DE69837825T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Description

  • Diese Erfindung bezieht sich auf ein Verfahren für eine Datenkommunikation zwischen Objekten in einem objektorientierten Programmiersystem, wie einem objektorientierten Betriebssystem (BS).
  • Unter jüngeren Systemverfahren gibt es ein sogenanntes objektorientiertes Verfahren. Bei einem System, das die Systemverfahren anwendet, sind verschiedene Funktionen in dem System als Objekte in Module gebildet.
  • Die WO 95/27248 , auf der der Oberbegriff des beigefügten Anspruchs 1 basiert, beschreibt ein objektorientiertes nachrichtbeförderndes System zum Übertragen von Nachrichten zwischen einer Client-Aufgabe (engl.: client task) und einer Server-Aufgabe (engl.: server task), das eine Objektdatenbank, eine Objektverwaltungseinheit, eine Nachrichtenabwicklungseinheit und eine Verriegelungseinheit aufweist. Die Objektverwaltungseinheit erzeugt ein Torobjekt (engl.: port object) und ein oder mehrere zugeordnete Nachrichtenobjekte. Die Nachrichtenabwicklungseinheit vergleicht eine Sendenachrichtenanfrage, die durch eine Client-Aufgabe ausgegeben wird, mit einer Annahmefunktion oder mit einer Empfangsnachrichtenanfrage, die durch eine Server-Aufgabe ausgegeben wird. Ansprechend auf eine Sendenachrichtenanfrage erzeugt die Nachrichtenabwicklungseinheit einen Sendenachrichten-Steuerblock. Ansprechend auf eine Empfangsnachrichtenanfrage erzeugt die Nachrichtenabwicklungseinheit, wenn die Empfangsnachrichtenanfrage mit dem Sendenachrichten-Steuerblock übereinstimmt, einen Lieferungsnachrichten-Steuerblock, oder erzeugt einen Empfangsnachrichten-Steuerblock, wenn die Empfangsnachrichtenanfrage mit dem Sendenachrichten-Steuerblock nicht übereinstimmt. Die Verriegelungseinheit verriegelt ein Nachrichtenobjekt derart, dass Sendenachrichtenanfragen, die an das Nachrichtenobjekt gerichtet sind, nicht berechtigt sind, um mit Empfangsnachrichtenanfragen verglichen zu werden, bis das Nachrichtenobjekt entriegelt wird. Ein objektorientiertes nachrichtbeförderndes Verfahren weist folgende Schritte auf: Erzeugen eines Torobjekts; Erzeugen eines Nachrichtenobjekts, das dem Torobjekt zugeordnet ist; Erzeugen einer eindeutigen Nachrichten-ID ansprechend auf eine Nachrichtenabwicklung, die durch eine Sendenachrichtenanfrage initialisiert wird; Erzeugen eines Sendenachrichten-Steuerblocks; und Vergleichen des Sendenachrichten-Steuerblocks mit einer entsprechenden Empfangsnachrichtenanfrage.
  • Zum Realisieren der Funktionen des Systems als Ganzes hat jedes Objekt eine Kommunikation mit einem anderen Objekt(en).
  • Im Hinblick auf Synchronisation- oder Nachrichtenverwaltungsverfahren kann an verschiedene Kommunikationssysteme zwischen Objekten gedacht werden. Diese Systeme müssen ansprechend auf verschiedene Anfragen von speziellen Anwendungen übernommen werden. Zum Erfüllen dieser Anfragen ist es notwendig, eine Kommunikationseinrichtung zwischen Objekten mit Eigenschaften, die den Anwendungen zugeordnet sind, wie Semantik, und zugeordnete Schnittstellen (Anwendungsprogrammierschnittstellen oder APIs; API = Application Programming Interface) vorzusehen. Die eben erörterten APIs bedeuten unterdessen Schnittstellen, die die BS-Funktionen verwenden, oder Schnittstellen als Programmiersystemfunktionen.
  • Auf die Anwesenheit einer Kommunikationseinrichtung zwischen Objekten mit Eigenschaften oder Schnittstellen wird als eine Anwesenheit einer „Umgebung" Bezug genommen. In einer Ausrüstung oder einem Host kann lediglich eine Umgebung realisiert sein oder mehrere unterschiedliche Umgebungen können gleichzeitig realisiert sein. Vor allem ist die Kommunikation zwischen Objekten, die in unterschiedlichen Umgebungen existieren, bei einer Realisierung von einander entsprechenden Operationen von unterschiedlichen Umgebungen entscheidend.
  • Es gibt zwei wesentliche Konzepte, die die Funktionen eines Sendens von Nachrichten zu Objekten, die in unterschiedlichen Umgebungen existieren, einrichten. Das heißt,
    • 1. das Konzept, dass Schnittstellen oder Prozeduren, die eingerichtet sind, um Nachrichten zu einem Objekt(en), das (die) in unterschiedlichen Umgebungen anwesend ist (sind), zu senden, sich von denen, die bei einem Senden von Nachrichten zu einem Objekt(en), das (die) in der gleichen Umgebung anwesend ist (sind), unterscheiden; und
    • 2. das Konzept, das die gleichen Schnittstellen oder Prozeduren, die eingerichtet sind, um Nachrichten zu einem Objekt(en), das (die) in unterschiedlichen Umgebungen anwesend ist (sind), zu senden, bei einem Senden von Nachrichten zu einem Objekt(en), das (die) in der gleichen Umgebung anwesend ist (sind), verwendet werden können.
  • Das erstere Verfahren kann relativ leicht realisiert werden, da ein Programmierer sich nicht über alle Umgebungen bewusst sein muss, derart, dass Unterschiede bei den Schnittstellen oder den Prozeduren durch Einrichten von unterschiedlichen Funktionen abhängig von den Unterschieden in Umgebungen getilgt sein können.
  • Eine sogenannte Transparenz, das heißt eine Indifferenz eines Programmcodes von unterschiedlichen Umgebungen, ist jedoch für Programmierer wünschenswerter.
  • Eine Aufgabe der vorliegenden Erfindung besteht daher darin, ein Datenkommunikationsverfahren, das ermöglicht, dass eine Transparenz für unterschiedliche Umgebungen für Programmierer eingerichtet wird, zu schaffen.
  • Gemäß der vorliegenden Erfindung ist ein Datenkommunikationsverfahren zum Realisieren der Kommunikation zwischen einer Mehrzahl von Objekten eines objektorientierten Systems geschaffen, dadurch gekennzeichnet, dass die Kommunikation zwischen Objekten von jeweiligen Umgebungen stattfindet, wobei die Umgebungen eine Kommunikationseinrichtung, die auf entweder Zukünften oder Fortsetzungen basiert, verwenden, wobei das Verfahren folgende Schritte aufweist:
    Erzeugen von Markierungen für jeweilige Kommunikationsnachrichten zwischen Objekten, wobei jede Markierung die Umgebung gemäß der verwendeten Kommunikationseinrichtung identifiziert, um eine Synchronisation einer Ausführung der Kommunikation zwischen den Objekten, die in unterschiedlichen Umgebungen existieren, durch die Lieferung der jeweiligen Markierungen zu steuern; und Senden von jeweiligen Markierungen zusammen mit den Kommunikationsnachrichten.
  • Das System kann ein Software-System sein, derart, dass eine Kommunikation zwischen Software-Elementen mit einer Transparenz realisiert sein kann.
  • Durch Einführen der Markierung sind ein System, das eine Kommunikationseinrichtung mit einer Transparenz zwischen unterschiedlichen Umgebungen realisiert hat, und ein System zur Realisierung desselben realisiert. Gemäß der vorliegenden Erfindung wird eine Kommunikation möglich, selbst wenn sich ein Gegenstand, der zum Steuern der Synchronisation oder der Parallelität der Kommunikation zwischen Objekten, die einer Kommunikationseinrichtung eigen ist, notwendig ist, von Umgebungen ohne die Notwendigkeit, dass sich die Objekte, die in den unterschiedlichen Umgebungen anwesend sind, der Unterschiede bewusst werden, unterscheidet.
  • Durch Einführen der Markierung zum Steuern der Synchronisation oder der Parallelität der Kommunikation zwischen Objekten, die der Kommunikationseinrichtung mit unterschiedlichen Eigenschaften oder Schnittstellen eigen ist, kann insbesondere die Kommunikation zwischen Objekten zwischen unterschiedlichen Umgebungen mit einer Transparenz ohne Weiteres realisiert werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockschaltungsdiagramm, das eine schematische Struktur einer VCR-Vorrichtung zeigt, die auf ein Datenkommunikationsverfahren, das die vorliegende Erfindung ausführt, angewendet ist.
  • 2 stellt die Art und Weise einer Kommunikation durch eine VCR-Vorrichtung, die die vorliegende Erfindung ausführt, ein BS für eine Kommunikation, ein BS für ein AV und eine API dar.
  • 3 stellt eine Metaraum-(mLokal-)Kommunikationseinrichtung (bei einem Fall, bei dem ein WartenAuf vor einer Antwort ausgeführt wird) dar.
  • 4 stellt eine Metaraum-(mLokal-)Kommunikationseinrichtung (bei einem Fall, bei dem eine Antwort vor einem WartenAuf ausgeführt wird) dar.
  • 5 stellt die Art und Weise einer Kommunikation der Anwendungssoftware mit Versenderobjekten oder Zeitplanerobjekten über eine API dar.
  • 6 stellt Zukunfts-Attribute dar.
  • 7 stellt eine Metaraum-(mAnsteuer-)Kommunikationseinrichtung dar.
  • 8 stellt Attribute einer Fortsetzung dar.
  • 9 stellt den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender) und dem Zeitplaner (für eine Realisierung eines Sendens in einem Metaraum (mLokal)) dar.
  • 10 stellt den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender) und dem Zeitplaner (für eine Realisierung einer Antwort in einem Metaraum (mLokal)) dar.
  • 11 stellt den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender) und dem Zeitplaner (bei einem Fall, bei dem eine Antwort vor einem WartenAuf in einem WartenAuf in dem Metaraum (mLokal) ausgeführt wird) dar.
  • 12 stellt den Fluss einer Prozedur der Beziehung zwischen dem Metaobjekt (mLokalerVersender) und dem Zeitplaner (bei einem Fall, bei dem ein WartenAuf vor einer Antwort in einem WartenAuf in dem Metaraum (mLokal) ausgeführt wird) dar.
  • 13 stellt eine Nachrichtenwarteschlange dar.
  • 14 stellt den Fluss einer Prozedur eines Sendens in einem Metaobjekt (MAnsteuerVersender) dar.
  • 15 stellt den Fluss einer Prozedur eines Startens in einem Metaobjekt (MAnsteuerVersender) dar.
  • 16 stellt den Fluss einer Prozedur dar, die aufgerufen wird, wenn ein Basisobjekt in einem Metaraum (mAnsteuer) zu der Zeit einer Beendigung (Ausstieg) des Metaobjekts (MAnsteuerVersender) ein Verarbeiten beendet.
  • 17 stellt den Fluss eines Verarbeitens der Prozedur, die bei einem Fall eines Senden des Metaobjekts (MAnsteuerVersender) in einer Tabelle einer verzögerten Ausführung (VerzögerungsAusführungsTabelle) registriert wird, dar.
  • 18 stellt den Fluss eines Verarbeitens der Prozedur, die bei einem Fall eines Anstoßes des Metaobjekts (MAnsteuerVersender) in einer Tabelle einer verzögerten Ausführung (VerzögerungsAusführungsTabelle) registriert wird, dar.
  • 19 stellt die Struktur einer MetaNachricht dar.
  • 20 stellt die Operation bei einem Fall einer Unterbrechung eines Objekts II während einer Ausführung eines Basisobjekts I dar.
  • 21 stellt die Beziehung zwischen einer Markierung, einer Zukunft und einer Fortsetzung und dieselbe zwischen einer Markierung (Markierung) und der Markierungs-ID (MID) durch ein Objektmodell des OMT-Verfahrens dar.
  • 22 stellt den Fluss eines Vorwärtsweges bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem Metaraum (mLokal) zu einem Metaraum (mAnsteuer)) dar.
  • 23 stellt den Fluss eines Rückwärts- oder Rückweges bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem Metaraum (mLokal) zu dem Metaraum (mAnsteuer)) dar.
  • 24 stellt den Fluss eines Vorwärtsweges bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem Metaraum (mAnsteuer) zu dem Metaraum (mLokal)) dar.
  • 25 stellt den Fluss eines Rückwärts- oder Rückweges bei einem Fall einer Kommunikation zwischen unterschiedlichen Metaräumen über ein Objekt (einen Lieferanten) (bei einem Fall einer Kommunikation von dem Metaraum (mAnsteuer) zu einem Metaraum (mLokal)) dar.
  • 26 stellt ein Beispiel eines Systems zum Verifizieren von Markierungstypen durch die Markierungs-ID dar.
  • 27 stellt ein OMT, das Markierungsattribute in dieser Markierungs-ID (MID) umfasst, dar.
  • 28 zeigt ein Statusübergangsdiagramm eines Programmfadens.
  • BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
  • Bezug nehmend auf die Zeichnungen ist ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung detailliert erklärt.
  • Das Datenkommunikationsverfahren, das die vorliegende Erfindung ausführt, kann auf ein Software-System, das fähig ist, mehrere unterschiedliche Umgebungen zu realisieren, angewendet sein. Bei dem Ausführungsbeispiel der vorliegenden Erfindung ist auf jede Umgebung als ein Metaraum Bezug genommen. Bei dem Ausführungsbeispiel der vorliegenden Erfindung können Metaräume unterschiedliche „Umgebungen" in Verbindung mit anderen Funktionen als die Kommunikationseinrichtung zwischen Objekten einrichten. Ein Beispiel eines Software-Systems, das fähig ist, die im Vorhergehenden erwähnten unterschiedlichen Umgebungen zu realisieren, ist das Datenverarbeitungsverfahren und die Datenverarbeitungsvorrichtung, die in der japanischen Patentanmeldung 8-67881 beschrieben sind. Das Datenverarbeitungsverfahren wird durch ein Datenverarbeitungssystem ausgeführt, das ein Anwendungsprogramm, das durch eine Mehrzahl von Objekten gebildet ist, eine Ausführungsumgebung, die den Betrieb des Anwendungsprogramms, das durch die Mehrzahl von Objekten gebildet ist, vorschreibt, einen Server mit einer Anwendungsprogrammschnittstelle, die die Schnittstelle zwischen dem Anwendungsprogramm und der Ausführungsumgebung vorschreibt, und einen Client, der das Anwendungsprogramm von dem Server herunterlädt, umfasst. Bei einem Herunterladen des Anwendungsprogramms in den Client prüft der Server, ob der Client die Ausführungsumgebung für das heruntergeladene Anwendungsprogramm hat oder nicht, und spricht auf die Resultate dieser Prüfungen, um das Programm in den Client herunterzuladen, an.
  • 1 zeigt ein Beispiel einer Vorrichtungsstruktur zum Ausführen des Datenkommunikationsverfahrens, das die vorliegende Erfindung ausführt.
  • Die Vorrichtung von 1 ist ein Videokassettenrekorder (eine VCR-Vorrichtung) zum Aufzeichnen/Wiedergeben von Signalen unter Verwendung einer Videokassette, die eine Kassette und ein Videoband, das in derselben gehaust ist, aufweist. Die vorliegende Erfindung kann selbstverständlich auf eine andere audiovisuelle Ausrüstung (AV-Ausrüstung) als die VCR-Vorrichtung, Büroausrüstungen oder auf eine Computervorrichtung allgemein angewendet sein.
  • Bei der VCR-Vorrichtung von 1 hat eine VCR-Funktionseinheit 14 die Hauptfunktionen eines Videokassettenrekorders zum Aufzeichnen/Wiedergeben von Daten unter Verwendung der Videokassette. Die Daten, die durch die VCR-Funktionseinheit 14 auf der Videokassette aufgezeichnet/wiedergegeben werden, werden über eine Bus-/IO-Brücke 15 zu anderen Komponenten der Vorrichtung gesendet und werden ferner über einen Anschluss 23 nach außen ausgesendet. Die Zentralverarbeitunsgeinheit (engl.: Central Processing Unit; CPU) 12 ist eine Steuerung, die über eine Bus-/Speicher-Brücke 13 verschiedene Teile steuert. Ein Direktzugriffspeicher (engl.: Random Access Memory; RAM) 10 hat eine kleinere Kapazität und hat einen Arbeitsbereich. In einem Nur-Lese-Speicher (engl.: Read-Only Memory; ROM) 11 ist ein Programm betreffend die Basisfunktionen und ein Programm für das BS, wie es so bei der vorliegenden Erfindung bezeichnet ist, gespeichert sind. Das heißt, die CPU 12 steuert verschiedene Teile basierend auf dem Programm, das in dem ROM 11 gespeichert ist, und verwendet den RAM 10 als einen Arbeitsbereich.
  • Das IC-Kartenlaufwerk 16 hat einen Schlitz, in den eine IC-Karte als ein Aufzeichnungsmedium mit einer integrierten Schaltung (engl.: Integrated Circuit; IC) in einem kartenförmigen Gehäuse eingeführt wird, und eine IC-Karten-Ansteuereinheit zum Schreiben/Lesen von Daten auf oder von der IC-Karte. Ein Laufwerk für eine flexible Platte umfasst eine Drehantriebseinheit zum drehenden Antreiben der flexiblen Platte und eine Kopfeinheit zum Aufzeichnen/Wiedergeben von Daten auf oder von der flexiblen Platte. Das Laufwerk 17 für eine flexible Platte (engl.: floppy disc) ist für ein Aufzeichnen von verschiedenen Daten und eine Installation einer Anwendungssoftware verantwortlich. Das Festplattenlaufwerk 18 umfasst eine Drehantriebseinheit zum drehenden Antreiben der Festplatte und einen Kopf zum Aufzeichnen/Wiedergeben von Daten auf oder von der Festplatte. Ein Busschlitz 19 ist ein Erweiterungsanschluss zum Hinzufügen einer Erweiterungsplatine, während ein serielles Tor 20 ein Eingang/Ausgang zum Vorsehen einer Datenkommunikation mit dem Äußeren über ein MODEM ist.
  • Die VCR-Vorrichtung ist entworfen, um eine zusätzliche Anwendungssoftware zusätzlich zu den üblichen VCR-Funktionen zu geben. Wenn beispielsweise ein Benutzer beabsichtigt, die Version zu erweitern, das heißt der VCR-Vorrichtung neue Funktionen hinzuzufügen, können zusätzliche Funktionseinheiten über eine IC-karte, eine flexible Platte oder ein Netz, wie das Internet, installiert werden. Dies gestattet dem Benutzer, die Vorrichtungsfunktion zu erweitern, ohne ein Hauptkörper-Bauglied der VCR-Vorrichtung neu zu erwerben. Das Anwendungsprogramm wird durch den Programmierer vorbereitet, um dem Benutzer zugeführt zu werden. Es wird angenommen, dass die vorhergehende Software durch eine sogenannte objektorientierte Programmier-Software aufgebaut wird.
  • Bei dem vorhergehenden Fall ist gelegentlich eine Kommunikation zwischen mehreren unterschiedlichen Umgebungen (Metaräumen) erforderlich.
  • Bezug nehmend auf 2 sind die Anwendungssoftwareelemente, die über ein MODEM und ein serielles Tor von außen gesendet werden, in einer Umgebung (einem Metaraum) platziert, die sich von der Anwendungssoftware, die in der VCR-Vorrichtung von Anfang an anwesend ist, unterscheidet. Diese Anwendungssoftware-Elemente können über ein Kommunikation-BS (einen Metaraum (mLokal) oder einen Metaraum (mAnsteuer), wie im Folgenden erklärt ist), ein BS für ein AV und eine API (Senden oder Antwort, wie im Folgenden erklärt ist) miteinander kommunizieren.
  • Zu erklärende Themen
  • Zuerst ist ein Fall erklärt, bei dem die „zwei spezifizierten Beispiele der unterschiedlichen Kommunikationseinrichtungen", die im Vorhergehenden beschrieben sind, mit dem Datenkommunikationsverfahren der vorliegenden Erfindung realisiert wurden. Die vorliegenden Beispiele sind auf einen Metaraum (mLokal), der eine Kommunikationssemantik (Eigenschaften oder eine Struktur von Bedeutungen) realisiert hat, die einen Gegenstand verwendet, der als eine Zukunft bezeichnet ist, und einen Metaraum (mAnsteuer), der eine Kommunikationssemantik realisiert hat, die einen Gegenstand verwendet, der als eine Fortsetzung bezeichnet ist, gerichtet.
  • Bei dem vorliegenden Ausführungsbeispiel sind die im Vorhergehenden erwähnten „spezifizierten Beispiele der unterschiedlichen Kommunikationseinrichtungen" in der Folge von
    „Metaraum-(mLokal-)Kommunikationseinrichtung";
    „Metaraum-(mAnsteuer-)Kommunikationseinrichtung";
    „Vergleich zwischen einer Metaraum-(mLokal-)Kommunikationseinrichtung und einer Metaraum-(mAnsteuer-)Kommunikationseinrichtung";
    „System zum Realisieren der Kommunikationseinrichtung bei dem erfinderischen Verfahren";
    „System zum Realisieren einer Zukunft und einer Metaraum-(mLokal-)Kommunikationseinrichtung” und
    „System zum Realisieren einer Fortsetzung und einer Metaraum-(mAnsteuer-)Kommunikationseinrichtung"
    erklärt.
  • Als Nächstes ist die „Basiserklärung der Kommunikationseinrichtung, die eine Markierung verwendet," vorgenommen. Der Metaraum (mLokal) und der Metaraum (mAnsteuer) sind hier wieder als Beispiele genommen. Der Metaraum (mLokal) und der Metaraum (mAnsteuer) können unterdessen als ein BS oder ein Programmiersystem begriffen werden. Bei dem vorliegenden Ausführungsbeispiel sind, indem die vorhergehende „Basiserklärung der Kommunikationseinrichtung, die die Markierung verwendet," angegeben wird,
    ein Fall, bei dem ein Objekt A, Verfahren (A::A1), ein Senden und ein Warten-Auf (Senden + WartenAuf) an dem Objekt B, Verfahren B1 (B::B1), durchführt, und
    ein Fall, bei dem das Objekt B, Verfahren B1 (B::B1), ein Senden an dem Objekt A, Verfahren (A::A1), durchführt und das Objekt B, Verfahren B2 (B::B2), als ein Fortsetzungsverfahren bestimmt,
    in dieser Reihenfolge erklärt.
  • Ein Fall eines Realisierens der Kommunikationseinrichtung bei dem Verfahren der vorliegenden Erfindung ist dann detailliert erklärt. Bei dem vorliegenden Ausführungsbeispiel ist der „Fall eines Realisierens der Kommunikationseinrichtung, die eine Markierung verwendet, bei dem Verfahren der vorliegenden Erfindung" in der Reihenfolge von
    „Zukunft, Fortsetzung und Markierung";
    „Ein System zum Verwalten einer Markierungs-ID und eines Objekts, das die Markierungs-ID liefert (eines Lieferanten)"; und
    „Tatsächliche Kommunikation zwischen unterschiedlichen Metaräumen"
    erklärt.
  • Schließlich sind „andere denkbare Systeme, die sich in unbedeutender Hinsicht unterscheiden,” erklärt. Bei dem vorliegenden Ausführungsbeispiel sind diese „anderen denkbaren Systeme" in der Reihenfolge „eines Systems eines Erkennens des Markierungstyps durch die Markierungs-ID"; und „eines Markierungsverwaltungssystems" erklärt.
  • „Spezifizierte Beispiele von unterschiedlichen Kommunikationseinrichtungen"
  • Diese Beispiele bei dem Verfahren der vorliegenden Erfindung sind nun erklärt.
  • In dem vorliegenden Kapitel sind als die „spezifizierten Beispiele von unterschiedlichen Kommunikationseinrichtungen" spezifizierte Entwurfsanweisungen und das System für eine Realisierung der Kommunikation zwischen unterschiedlichen Objekten bei dem Datenkommunikationsverfahren der vorliegenden Erfindung erklärt. Bei einem spezifizierten Beispiel der vorliegenden Erfindung, das auf das vorliegende Kapitel folgt, ist das System zum Realisieren der Kommunikation zwischen Objekten zwischen zwei unterschiedlichen Umgebungen (die die Kommunikationseinrichtung einrichten), die in dem vorliegenden Kapitel erörtert sind, erklärt.
  • „Metraraum-(mLokal-)Kommunikationseinrichtung"
  • Der Metaraum (mLokal) ist eine Umgebung und unterstützt die Kommunikationseinrichtung, die auf einer Zukunft (Zukunft) (Kommunikationseinrichtung zwischen Objekten) basiert. Dieser Metaraum (mLokal) beschriebt die Anwendung. Von den Entwurfsanweisungen der Metaraum-(mLokal-)Kommunikationseinrichtung ist im Folgenden die Schnittstelle erklärt.
  • Der Basisbetrieb der Kommunikation zwischen Objekten ist hierin erörtert. Das System zum Realisieren dieser Kommunikationseinrichtung und die in der Erklärung verwendeten Attribute einer Zukunft sind anschließend erklärt.
  • 3 und 4 stellen den Basisbetrieb einer Kommunikation zwischen Objekten, die die Metaraum-(mLokal-)Kommunikationseinrichtung verwendet, dar. 3 zeigt einen Fall, bei dem in der mLokal-Metaraum-Kommunikationseinrichtung ein WartenAuf vor einer Antwort ausgeführt wurde, während 4 einen Fall zeigt, bei dem in der mLokal-Metaraum-Kommunikationseinrichtung eine Antwort vor einem WartenAuf ausgeführt wurde. In diesen Figuren geben A, B Objekte an, und A::A1 und B::B1 geben ein Verfahren A1 des Objekts A beziehungsweise ein Verfahren B1 des Objekts B an. Vertikale Volllinienpfeile geben eine Ausführung der Verfahren an, vertikale Strichlinienpfeile geben Wartezustände der Verfahren an, und schräge Volllinienpfeile geben eine Nachrichtenlieferung an. Ein WartenAuf ist unterdessen eine der APIs (Anwendungsprogrammschnittstellen) in dem Metaraum mLokal und wird für einen Fall, bei dem das Objekt A auf das Resultat des Objekts B wartet, verwendet. Bei einem WartenAuf sind als Argumente eine Zukunfts-ID, eine Antwortnachricht (&Nrt), die von der Antwort (Antwort) gesendet wird, und ihre Größe (Größevon(Nrt)) vorgesehen. Die Antwort (Antwort) ist eine der APIs in dem Metaraum mLokal und wird bei dem vorliegenden Ausführungsbeispiel für das Objekt B verwendet, um ein Ansprechen auf das Objekt A durchzuführen. In einer Antwort ist als ein Argument die Antwortnachricht (Nrt), die als das Resultat einer Ausführung des Verfahrens B1 erhalten wird, und ihre Größe (Größevon(Nrt)) vorgesehen.
  • In 3 und 4 sendet das Objekt A eine Nachricht zu dem Objekt B und empfangt eine Antwort von demselben. Das Objekt A sendet zuerst unter Verwendung eines Senden eine Nachricht zu dem Objekt B. Das Verfahren B1 (B::B1) ist ein Verfahren, das dadurch gestartet wird. In der Zeichnung ist eine Nrt eine gelieferte Nachricht, genauer gesagt, ihr Zeiger. Dies startet das Verfahren B1 (B::B1). Die Verfahren A::A1 und B::B1 sind parallel in Betrieb. Es ist nicht sicher, welches/welcher von einem WartenAuf des Verfahrens A1 (A::A1) und einer Antwort des Verfahrens B1 (B::B1) zuerst ausgeführt wird. Ein Senden ist eine der APIs in dem mLokal-Metaraum und wird bei dem momentanen Ausführungsbeispiel zum Senden einer Post verwendet. In einem Senden sind als Argumente eine Adresse (B), ein Auswahlverfahren (B1), eine Nachricht (Nrt) und ihre Größe (Größevon(Nrt)) und eine Zukunfts-ID (ZukunftsID) vorgesehen.
  • Wenn das Objekt A eine Nachricht zu dem Objekt B sendet, empfangt das Objekt A eine Zukunfts-ID (ZukunftsID). Die ZukunftsID ist eine ID, die einem Gegenstand entspricht, der als eine Zukunft bezeichnet ist und der in dem Betriebssystem (BS), das eine Nachricht liefert, intern erzeugt wird. Die Bezeichnung „Erzeugen" bedeutet Sichern eines Speicherbereichs, der für Attribute, die ein Objekt bilden, notwendig ist, und Initialisieren des Attributs. Bezug nehmend auf 5 ist die Anwendungssoftware angepasst, um über eine API mit einem Versenderobjekt (beispielsweise einem Objekt eines Metaobjekts, das mLokalerVersender genannt ist, wie im Folgenden erklärt ist, oder einem Objekt eines Zeitplaners, ähnlich im Folgenden erklärt) zu kommunizieren. Der Versender wird basierend auf dem Ausführungscode in dem Objekt durch die CPU ausgeführt. Die CPU sichert einen Speicherbereich, der für eine Zukunft in dem BS-Bereich erforderlich ist. Wenn das Objekt A später eine Antwort auf die Lieferung der Nachricht empfangt, wird die Zukunfts-ID (ZukunftsID) zum Identifizieren, welche Nachrichtensendung der empfangenen Antwortnachricht zugeordnet ist, verwendet.
  • 6 zeigt die Attribute einer Zukunft. Diese Attribute umfassen eine ID zum Spezifizieren des Objekts, das eine Zukunft erzeugt hat (des ProgrammfadenID-Erzeugers), eine Flag zum Prüfen, ob eine Antwort gegeben wurde oder nicht (Bool istAntwortGegeben), und einen Bereich zum Aufbewahren einer Antwortnachricht (Leerraum·AntwortNachricht). Bei den Beispielen von 3 und 4 ist das Objekt A in der ID (dem ProgrammfadenID-Erzeuger) aufbewahrt, und die Nachricht (Nrt) von einem Objekt B ist in der Antwortnachricht (Leerraum* AntwortNachricht) aufbewahrt.
  • 3 zeigt einen Fall, bei dem ein WartenAuf vor einer Antwort ausgeführt wurde. Bei diesem Fall ist eine ZukunftsID als ein Argument eines WartenAuf angegeben. Da das Verarbeiten eines Verfahrens B1, das auf eine bestimmte ZukunftsID antworten muss, nicht durchgeführt wurde, befindet sich eine Ausführung des Verfahrens A1 (A::A1) in dem Bereitschaftszustand. Während dieser Zeit fährt das Verfahren B1 (B::B1) mit einem Verarbeiten fort. Das Verfahren B1 führt eine Antwort aus, wenn dasselbe die Prozedur zum Geben einer Antwort nimmt. Wenn eine Antwort ausgeführt wird, wird der Zustand einer Zukunft, die bei einem Starten des Verfahrens B1 (B::B1) durch das BS erzeugt wird, beobachtet. Da das BS einschließen kann, dass es ein Verfahren in dem Bereitschaftszustand für eine Zukunft gibt, wird das Verfahren A1 (A::A1) wieder in den Ausführzustand versetzt. Die Verfahren A1 (A::A1) und B1 (B::B1) sind wieder parallel in Betrieb.
  • 4 zeigt einen Fall, bei dem eine Antwort vor einem WartenAuf ausgeführt wird. Wenn eine Antwort ausgeführt wird, wird der Zustand einer Zukunft, die erzeugt wird, wenn das Verfahren B1 (B::B1) durch das BS gestartet wird, beobachtet. Da das BS umfassen kann, dass sich der Sender der Nachricht, die einer Zukunft (hierin dem Objekt A) entspricht, noch nicht in dem Bereitschaftszustand befindet, fügt das BS ein Zeichen für eine Zukunft bei, dass eine Antwort gegeben wurde. Das Verfahren B1 (B::B1) fährt mit einem Ausführen des verbleibenden Anschnitts fort. Benötigt das Verfahren A1 (A::A1) die Antwort von dem Verfahren B1 (B::B1), gibt das Verfahren A1 (A::A1) eine ZukunftsID als ein Argument eines WartenAuf an. Da ein Verarbeiten zum Geben einer Antwort zu einer bestimmten ZukunftsID bereits durchgeführt wurde, kann das Verfahren A1 (A::A1) seine Ausführung fortsetzen.
  • Auf diese Art und Weise führt eine Zukunft die Rolle eines Vermittlers zum Synchronisieren von zwei Objekten, die parallel in Betrieb sind, durch. Da es in den Entwurfsanweisungen der mLokal-Metaraum-Kommunikationseinrichtung für die Nachrichtensendeseite notwendig ist, zu klären, für welche Nachricht die Antwort erwartet wird, wird eine Zukunft durch eine ZukunftsID identifiziert. Der Nachrichtenempfänger ist so angeordnet, dass derselbe sich nicht bewusst sein muss, für welchen Sender seine Antwort bestimmt ist. Eine Zukunfts-ID manifestiert sich daher in keiner genau festgesetzten Form.
  • „Metarraum-(mAnsteuer-)Kommunikationseinrichtung"
  • Der Metaraum mAnsteuer ist eine Umgebung, die die Kommunikationseinrichtung, die auf einer Fortsetzung basiert, unterstützt. Dieser Metaraum beschreibt einen Gerätetreiber.
  • Der Basisbetrieb der Kommunikation zwischen Objekten, die die mAnsteuer-Metaraum-Kommunikationseinrichtung verwendet, ist hier erklärt. Das System zum Realisieren dieser Kommunikationseinrichtung und die Attribute oder der Statusübergang, der für die Fortsetzung geeignet ist, die in der Erklärung verwendet wird, sind anschließend detailliert erklärt.
  • 7 zeigt den Basisbetrieb der Kommunikation zwischen Objekten, die in der mAnsteuer-Metaraum-Kommunikationseinrichtung verwendet wird. Wie in 3 und 4 geben A, B Objekte an, A::A1, A::A2 und B::B1 geben Verfahren A1, A2 und B1 des Objekts A und des Objekts B an, ein vertikaler Volllinienpfeil gibt eine Ausführung eines Verfahrens an, und ein schräger Volllinienpfeil gibt eine Nachrichtenlieferung an.
  • Das Objekt A sendet unter Verwendung des Sendens eine Nachricht zu dem Objekt B. Bei dem Beispiel von 7 liefert das Objekt A die Nachricht (Nrt) zu dem Verfahren B1 (B::B1) des Objekts B. Das Objekt A gibt zu dieser Zeit ein ununterbrochenes Verfahren A2 (A::A2) und eine ununterbrochene Nachricht (UnunterbrNrt)) zu dem Senden als ein fünftes beziehungsweise ein sechstes Argument ab. Das Verfahren (A::A2) ist zu dieser Zeit ein Verfahren eines Empfangen einer Antwort von dem Verfahren (B::B1) für eine Ausführung nach dem Ende des Verarbeiten des Verfahrens A1 (A::A1). Die Nachricht (UnunterbrNrt)) ist eine Nachricht, die ein Verarbeiten des ununterbrochenen Verfahrens A2 (A::A2) unterstützt, und ist eine Nachricht, die den Inhalt, der durch das Verfahren A1 (A::A1) zu dem ununterbrochenen Verfahren A2 (A::A2) geliefert wird, enthält.
  • Das BS erzeugt intern einen Gegenstand, der als eine Fortsetzung bezeichnet ist, der ein ununterbrochenes Verfahren und eine ununterbrochene Nachricht enthält. Durch Erzeugen einer Fortsetzung hier ist, wie bei dem Fall einer Zukunft, der unter Bezugnahme auf 5 erklärt ist, ein Bereich, der für eine Fortsetzung notwendig ist, in dem Speicher gesichert, indem das Versenderobjekt, wie das Metaobjekt, mAnsteuerVersender, das anschließend erklärt wird, ausgeführt wird.
  • 8 zeigt die Attribute einer Fortsetzung. Eine Fortsetzung definiert die Bereiche zum Speichern der ID (des ProgrammfadenID-Erzeugers), die das Objekt spezifiziert, das die Fortsetzung erzeugt hat, des ununterbrochenen Verfahrens (Wählerverfahren) und der ununterbrochenen Nachricht (Leerraum·Nachricht). Wenn das Objekt A, das Verfahren A::A2 und die Nachricht (UnunterbrNrt)) bei dem Beispiel von 7 durch das Senden gesendet werden, erzeugt das BS eine Fortsetzung mit dem Objekt A, das Verfahren A::A2 und die Nachricht (UnunterbrNrt)), die in der ID (dem ProgrammfadenID-Erzeuger) gespeichert sind, ein ununterbrochenes Verfahren (ein Wähler-Verfahren) beziehungsweise eine ununterbrochene Nachricht (Leerraum·Nachricht).
  • Das Verfahren B1 (B::B1) empfängt zusätzlich zu dem Inhalt der Nachricht, die von dem Verfahren A1 (A::A1) geliefert wird, die Fortsetzungs-ID (FortID), die durch das BS erzeugt wird, als die ID, die die Fortsetzung spezifiziert. Bei dem Beispiel von 7 empfangt das Verfahren B1 (B::B1) die ID als eine FortID. Diese Fortsetzungs-ID (FortID) wird als ein Argument eines Anstoßens (engl.: Kick) verwendet. Ein Anstoßen ist eine der APIs in dem Metaraum mAnsteuer. Bei dem vorliegenden Ausführungsbeispiel wird diese Fortsetzungs-ID (FortID) zu dem Objekt A gesendet, um die Informationen des Inhalts der Fortsetzung zu erhalten. Ein Anstoßen hat als sein Argument die im Vorhergehenden erwähnte Fortsetzungs-ID (FortID). Durch Anstoßen der Fortsetzung kann das Objekt des Metaraums mAnsteuer unbewusst das ununterbrochene Verfahren starten, ohne sich der in einer Fortsetzung enthaltenen Information bewusst zu werden. Bei dem Beispiel von 7 stößt das Verfahren B1 (B::B1) selbst die empfangene FortsetzungsID (FortID) an, wodurch das ununterbrochene Verfahren A2 (A::A2), das durch das Verfahren A1 (A::A1) bestimmt ist, bei der Übergabe der Resultate des Verfahrens B1 (B::B1) und der ununterbrochenen Nachricht (UnunterbrNrt)) gestartet wird.
  • Auf diese Art und Weise kann die Fortsetzung das ununterbrochene Verfahren ohne die Notwendigkeit, dass sich das Objekt, das die Anfangsnachricht empfangt, bewusst sein muss, wer diese Nachricht gesendet hat oder zu wem die Antwort gesendet wird (die Antwort kann zu dieser Zeit gesendet werden), starten. In den Entwurfsanweisungen der mAnsteuer-Metaraum-Kommunikationseinrichtung manifestiert sich, da das BS die Fortsetzungs-ID (FortID) zusammen mit der Nachricht zu der Nachrichtenempfangsseite sendet, die Fortsetzungs-ID (FortID) auf der Sendeseite nicht.
  • Vergleich einer Metaraum-(mLokal-)Kommunikationseinrichtung und einer Metaraum-(mAnsteuer-)Kommunikationseinrichtung
  • In den Entwurfsanweisungen der mLokal-Metaraum-Kommunikationseinrichtung bleibt eine Verfahrensausführung lediglich von dem Start eines Verfahrens bis zu seinem Ende parallel. Obwohl diese Semantik verglichen mit den Entwurfsanweisungen der mAnsteuer-Metaraum-Kommunikationseinrichtung hinsichtlich der Parallelität nicht hoch ist, hat dieselbe die Vorteile, dass dieselbe durch einen Programmierer intuitiv verstanden werden kann, während das Volumen der Codes, die beschrieben werden müssen, ohne Weiteres reduziert werden kann. Es ist jedoch bei diesen Entwurfsanweisungen für ein asynchrones Ereignis, wie einen Gerätetreiber, der eine Unterbrechung verwendet, nicht möglich, effizient beschrieben zu sein.
  • In den Entwurfsanweisungen der mAnsteuer-Metaraum-Kommunikationseinrichtung kann das ununterbrochene Verfahren, das nach einem Beenden eines gegenwärtigen Verfahrens auszuführen ist, bestimmt sein. Wenn eine Antwort zu einem Objekt zurückgesendet wird, das das gegenwärtige Verfahren in Verbindung mit einem asynchronen Ereignis, wie einer Unterbrechung, ausführt, kann das vorher bestimmte ununterbrochene Verfahren durch Anstoßen der Fortsetzung gestartet werden. Das asynchrone Ereignis, wie ein Gerätetreiber, kann daher effizient beschrieben sein. Obwohl es möglich ist, ein Programm zu beschreiben, das verglichen mit den Entwurfsanweisungen der mLokal-Metaraum-Kommunikationseinrichtung hinsichtlich der Parallelität hoch ist, hat die mAnsteuer-Metaraum-Kommunikationseinrichtung dahingehend Mängel, dass dieselbe durch den Programmierer nicht intuitiv verstanden werden kann und dass die Menge eines Codes, der beschrieben werden muss, dazu tendiert, groß zu sein.
  • System zum Realisieren einer Kommunikationseinrichtung
  • Bei diesem Verfahren wird die Funktion, die durch den Metaraum eingerichtet wird, durch das Objekt, das den Metaraum bildet, realisiert. Ein solches Objekt ist im Gegensatz zu dem Objekt, das die Funktion, die durch den Metaraum eingerichtet wird, verwendet, als ein Meta-Ebenen-Objekt oder ein Metaobjekt bezeichnet. Das Objekt, das die Funktion, die durch den Metaraum angeboten wird, verwendet, ist andererseits als das Basisebenen-Objekt oder als ein Basisobjekt bezeichnet.
  • Als ein Objekt, das die gemeinsamen Funktionen der Meta-Räume einrichtet, kann ein sogenannter Zeitplaner (engl.: scheduler) (als ein bildendes Element zum Realisieren von jeder Kommunikationseinrichtung, wie nun erklärt ist) verwendet sein. Das Objekt Zeitplaner ist ein Metaobjekt, das den Zustand eines Objekts verwaltet. Die Entwurfsanweisungen des Zeitplaners, die bei dem vorliegenden Ausführungsbeispiel erforderlich sind, sind anschließend erklärt.
  • Da sich die Kommunikationseinrichtung des Metaraums mLokal von derselben für den Metaraum mAnsteuer unterscheidet, kann das Metaobjekt, das die Funktionen, die die relevante Kommunikationseinrichtung realisieren, einrichtet, getrennt definiert sein. Das Metaobjekt zum Realisieren der Nachrichtenlieferung in der mLokal-Metaraum-Kommunikationseinrichtung ist als das Metaobjekt MLokalerVersender bezeichnet, während dasselbe zum Realisieren der Nachrichtenlieferung in der mAnsteuer-Metaraum-Kommunikationseinrichtung als ein Metaobjekt MAnsteuer-Versender bezeichnet ist.
  • Die mLokal-Metaraum-Kommunikationseinrichtung ist durch das Metaobjekt MLokalerVersender, den Zeitplaner und andere Module, die die Ausführung derselben unterstützen, realisiert. Die mAnsteuer-Metaraum-Kommunikationseinrichtung ist durch das Metaobjekt MAnsteuer-Versender, den Zeitplaner und andere Module, die die Ausführung derselben unterstützen, realisiert. Der Beziehung zwischen dem Metaobjekt MLokalerVersender und dem Zeitplaner und derselben zwischen dem Metaobjekt MAnsteuer-Versender und dem Zeitplaner sind ein Szenario gegeben, und das System zum Realisieren von jeder Kommunikationseinrichtung ist gezeigt. Die Zukunft und die Fortsetzung sind ebenfalls gegebene Attribute und der Zustandsübergang derselben ist durch das Szenario gezeigt.
  • System zum Realisieren einer Kommunikationseinrichtung für die Zukunft und derselben für einen Metaraum mLokal
  • 9 bis 12 zeigen die Beziehung zwischen dem Metaobjekt MLokalerVersender und dem Zeitplaner durch ein Szenario (ein Flussdiagramm).
  • 9 zeigt die Prozedur des Sendens für den Metaraum mLokal.
  • Wenn das Basisobjekt in dem Metaraum mLokal in 9 das Senden ausführt, geht ein Verarbeiten zu dem Metaobjekt MLokalerVersender für die Kommunikationseinrichtung, die den Metaraum mLokal bildet, über, wobei das Basisobjekt in einem Zustand Wartend (Warten) ist, wie bei einem Schritt ST7 gezeigt ist. Auf einen solchen Übergang des Verarbeitenszustands von dem Basisobjekt zu dem Metaobjekt ist im Folgenden als eine M (Metaberechnung) Bezug genommen.
  • Bei einem solchen Verarbeitensübergang erzeugt das Metaobjekt MLokalerVersender bei einem Schritt ST1 eine Zukunft (Zukunft).
  • Bei einem Schritt ST2 wird dann der Zustand der Nachrichtenwarteschlange (des Nachrichtenarrays) für das Objekt mit der Adresse, zu der die Nachricht (AktiveNachricht) zu liefern ist, bestimmt. Wenn es zu dieser Zeit keine Nachricht in der Nachrichtenwarteschlange gibt (FALSCH), ist das Zielobjekt in dem Ruhezustand (schlafend, wenn der Zeitplaner in dem Überwachungszustand ist). Eine API BereitMachen wird daher bei einem Schritt ST5 zu dem Zeitplaner ausgegeben, um einen Zustand einer möglichen Ausführung für das Objekt (einen Bereit-Zustand, wenn der Zeitplaner überwacht) einzustellen.
  • Die Nachrichtenwarteschlange ist hier kurz erklärt. Bezug nehmend auf 13 verwertet die CPU die gelieferte Nachricht, wenn einer der Programmfäden (engl.: threads) in dem Objekt ausgeführt wird. Die Nachrichtenwarteschlange stellt das Nachrichtenarray dar und ist zum folgenden Verwerten der Nachrichten in der Nachrichtenwarteschlange aufgebaut. Die API BereitMachen wird verwendet, um das Objekt ausführbar zu machen, während ein Bereit und ein Schlafend den Zustand einer möglichen Ausführung beziehungsweise den Zustand Schlafend des Objekts anzeigen. In dem Zustand Schlafend ist das Objekt leer laufend und bereit, eine Nachricht zu empfangen. Die API BereitMachen hat das Verfahren und die Nachricht (Nrt), die das Objekt als ein Argument (Programmfaden der Basis) spezifiziert (Objekt B bei dem vorliegenden Ausführungsbeispiel). Bei dem vorliegenden Ausführungsbeispiel wird daher ein Überwachungsbefehl zum Spezifizieren des Basisobjekts B zum Senden der Nachricht (Nrt) zu dem Verfahren B zu dem Zeitplaner gesendet.
  • Wenn es andererseits bei einem Schritt ST2 eine Nachricht in der Nachrichtenwarteschlange gibt (WAHR), wurde eine Nachricht zu dem Objekt mit der Adresse bereits geliefert und das Objekt befindet sich in dem Zustand einer möglichen Ausführung (Bereit), während das Objekt im Laufe einer Ausführung ist (Laufend). Bei einem Schritt ST4 wird die Nachricht daher an das hintere Ende der Nachrichtenwarteschlange gestellt, um das Verarbeiten zu beenden. Die Zukunfts-ID, die die Zukunft, die einer Nachrichtensendung entspricht, identifizieren kann, wird durch die Nachrichtenwarteschlange gleichzeitig verwaltet. Diese Zustände sind anschließend unter Bezugnahme auf 2 erklärt.
  • Ein Rückgabewerterfolg (sErfolg), der den Lieferungsende-Zustand anzeigt, wird dann in die Metanachricht (MetaNachricht) platziert und ein Zustandsübergang wird wieder zu dem Basisobjekt versetzt. Das Basisobjekt befindet sich dann in dem Zustand einer Ausführung oder in dem Zustand einer möglichen Ausführung, wie bei einem Schritt ST8. Die Metanachricht (MetaNachricht) ist eine Nachricht mit einem Parameter (einem Argument), das für ein Senden erforderlich ist, wenn das Basisobjekt in dem Metaraum (mLokal) das Senden durchführt.
  • Die im Vorhergehenden erwähnten M (Metaberechnung) und W (Wiederaufnehmen) sind in der japanischen Patentanmeldung 89-67881 , auf die im Vorhergehenden Bezug genommen ist, detailliert gezeigt.
  • 10 zeigt die Prozedur betreffend einer Antwort durch das Metaobjekt (den MLokalerVersender).
  • Bezug nehmend auf 10 bestätigt das Metaobjekt (der MLokalerVersender) zuerst bei einem Schritt ST11, welches Basisobjekt die Antwort (Antwort) gegeben hat. Bei den Beispielen von 3 und 4 wird bestätigt, dass das Basisobjekt B die Antwort ausgegeben hat. Für diese Bestätigung wird die Funktion LetztenHolen, beispielsweise von der API, bei dem vorliegenden Ausführungsbeispiel verwendet. Jedes gewünschte Verfahren kann jedoch verwendet sein. Das Basisobjekt befindet sich bei einem Schritt ST24 in dem Zustand Wartend.
  • Bei einem Schritt ST12 bis zu einem Schritt ST14 wird dann geprüft, ob die Zukunfts-ID, die gleichzeitig mit dem Starten des Basisobjekts gesendet wird, tatsächlich die Zukunft (Zukunft) des Metaraums (mLokal) ist. Wenn die Resultate der Schritte ST12 und ST14 falsch sind, wird angenommen, dass ein Fehler aufgetreten ist, und ein Verarbeiten geht zu einem Schritt ST22 über. Wenn das Resultat einer Prüfung bei einem Schritt ST13 falsch ist, ist der Zustand einer Kommunikation mit einem anderen Metaraum durch eine Kommunikationseinrichtung, die die Markierung als ein Merkmal der vorliegenden Erfindung verwendet, gleichbedeutend, und das Metaobjekt (Lieferant), wie im Folgenden erklärt ist, wird aufgefordert, das Verarbeiten zu übernehmen.
  • Wenn das Resultat einer Prüfung bei den Schritten ST12 bis ST14 JA ist, wird das Attribut (Erzeuger) der Zukunft (Zukunft) bei einem Schritt ST15 geprüft. Das Attribut (Erzeuger) umfasst zu dieser Zeit das Objekt, das die Nachricht zu dem Basisobjekt, das die Antwort (Antwort) gegeben hat, gesendet hat. Bei dem Beispiel von 3 und 4 ist das Objekt, das die Nachricht zu dem Basisobjekt B, das die Antwort gegeben hat, gesendet hat, A und ist in einem Bereich Programmfaden-ID-Erzeuger aufbewahrt.
  • Bei einem Schritt ST16 wird als Nächstes geprüft, ob das Objekt in dem Zustand Wartend (Warten) ist. Wenn das Objekt in dem Zustand Wartend (Warten) ist, führt das Objekt das WartenAuf wie bei einem Schritt ST17 aus. Bei einem Ausführen des WartenAuf sind eine Zukunfts-ID (ZukunftsID), eine Antwortnachricht (&Nrt) und eine Größe (Größevon(Nrt)) Argumente, die gegenwärtig behandelte Zukunfts-ID (ZukunftsID) ist gleich einer Zukunfts-ID (ZukunftsID), die dem WartenAuf gegeben ist, und der Nachricht (Nrt), die durch die Antwort (Antwort) gesendet wird, wird das Argument (&Nrt) gegeben, wie unter Bezugnahme auf 3 und 4 erklärt ist. Das Objekt in dem Zustand Wartend befindet sich durch die API BereitMachen wieder in dem Zustand einer möglichen Ausführung. Das heißt, das Objekt A bei den Beispielen von 3 und 4 wird wieder in den Zustand einer möglichen Ausführung versetzt.
  • Da das Verfahren der Adresse in dem Zustand Wartend ist, ist eine Bestimmung und daher ein NICHT-DEFINIEREN (Nicht-Definieren) oder eine Nachricht nicht notwendig und sind daher NULL.
  • Wenn andererseits bei einem Schritt ST16 das Attribut Erzeuger nicht in dem Zustand Wartend ist, wird ein WartenAuf noch nicht ausgeführt. Das Metaobjekt (MLokalerVersender) stellt daher zu dieser Zeit bei einem Schritt ST19 das Attribut (istAntwortGegeben) der Zukunft (Zukunft) ein, um ein Markierzeichen für einen Antwortabschluss einzugeben. Wenn notwendig, wird die Antwortnachricht in der Nachricht (Nachricht), wie bei einem Schritt ST18, vorübergehend aufbewahrt.
  • Die Zukunft (Zukunft) wird anschließend bei einem Schritt ST20 gelöscht und ein Rückgabewerterfolg (sErfolg) eines Lieferungsabschlusses wird bei einem Schritt ST21 in eine Metanachricht (MetaNachricht) eingegeben. Bei einem Schritt ST22 wird ein Rückgabewert, der einen Fehler spezifiziert, in die Metanachricht (MetaNachricht) eingegeben, und bei einem Schritt ST23 wird ein Rückgabewerterfolg (sErfolg) für einen Lieferungabschluss in die Metanachricht (MetaNachricht) eingegeben. Das Basisobjekt tritt dann in einen Ausführzustand oder einen Zustand einer möglichen Ausführung, wie bei einem Schritt S25, ein.
  • 11 und 12 stellen die Prozedur für ein WartenAuf dar. 11 zeigt insbesondere einen Fall, bei dem eine Antwort vor einem WartenAuf ausgeführt wird (der Fall von 4), während 12 den umgekehrten Fall (das heißt, einen Fall von 3) in Verbindung mit der Erklärung von 10 zeigt. Der anschließende Fluss des Basisobjekts ist um einer Einfachheit willen nicht gezeigt.
  • In 11 wird die Zukunft (Zukunft) bei einem Schritt ST31 bestätigt. Bei einem Schritt ST32 wird geprüft, ob das Attribut (istAntwortGegeben) der Zukunft (Zukunft) eingestellt wurde oder nicht, das heißt, ob die Antwort (Antwort) gegeben wurde oder nicht. Wenn die Resultate dieser Schritte ST31, ST32 beide WAHR sind, wird die Nachricht als ein Resultat der Resultatsnachricht, die bei einem Schritt ST33 in der Zukunft (Zukunft) eingestellt wird, in der Nachricht (&Nrt) eines WartenAuf eingestellt. Die Zukunft (Zukunft) wird anschließend bei einem Schritt ST31 gelöscht, und bei einem Schritt ST35 wird ein Lieferungsenderfolg (sErfolg) in eine Metanachricht (MetaNachricht) eingegeben. Wenn das Resultat eines Schritts ST31 FALSCH ist, wird bei einem Schritt ST36 der Fehlercode in die MetaNachricht eingegeben, um ein W (Wiederaufnehmen) durchzuführen. Wenn das Resultat eines ST32 FALSCH ist, geht ein Verarbeiten zu einem in 12 gezeigten Schritt ST43 über.
  • In 12 wird die Zukunft (Zukunft) bei einem Schritt ST41 bestätigt, und bei einem Schritt ST42 wird bestätigt, ob das Attribut (istAntwortGegeben) eingestellt wurde oder nicht. Wenn die Resultate der Schritte ST41 und ST42 beide WAHR sind, wird bei einem Schritt ST43 der Zustand Wartend eingestellt. Ein Erfolg (sErfolg) wird anschließend in eine Metanachricht (MetaNachricht) eingegeben und bei einem Schritt ST45 von einem MetaAufruf ausgesendet. Wenn das Resultat des Schritts ST41 FALSCH ist, wird bei einem Schritt ST46 ein Fehlercode in die Metanachricht (MetaNachricht) eingegeben, um ein W (Wiederaufnehmen) durchzuführen. Wenn das Resultat des Schritts ST42 FALSCH ist, geht das Verarbeiten zu dem Schritt ST33 von 11 über. Bei den Beispielen von 11 und 12 fragt das Basisobjekt bei dem Metaobjekt (MLokalerVersender) an, einen Zustand Wartend (Warten) bis zu einem W (Wiederaufnehmen) einzustellen.
  • System zum Realisieren einer Fortsetzung und einer Metaraum-(mAnsteuer-) Kommunikationseinrichtung
  • In 14 bis 18 ist die Beziehung zwischen dem Metaobjekt mAnsteuerVersender und dem Zeitplaner durch ein Szenario angegeben. Da das Metaobjekt mAnsteuerVersender ein Metaraum für einen Gerätetreiber ist, ist die Prozedur etwas komplexer als dieselbe für das Metaobjekt mLokalerVersender. Ein erläuterndes Beispiel ist eine Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle). Die Prozedur des Sendens und des Anstoßens in dem Metaobjekt MAnsteuer-Versender ist derart, dass, wenn das Objekt in dem Metaraum mAnsteuer das Senden oder Anstoßen anfragt, lediglich eine Registrierung in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) ausgeführt wird, während eine Lieferung von tatsächlichen Nachrichten zu der Zeit eines Aussteigens aus dem Verfahren gemeinsam ausgeführt wird.
  • 14 zeigt die Prozedur des Sendens in dem Metaobjekt MAnsteuer-Versender.
  • Bezug nehmend auf 14 wird das Senden-Verarbeiten bei einem Schritt ST51 in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registriert, wie im Vorhergehenden erklärt ist. Das heißt, das Argument für eine verzögerte Ausführung in der Metanachricht wird in der Tabelle registriert. Wenn das Basisobjekt in dem Metaraum mAnsteuer ein Senden durchführt, wird die Metanachricht (MetaNachricht) als ein Gegenstand, der Parameter, die für das Senden erforderlich sind, enthält, in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registriert. Bei einem Schritt ST52 wird anschließend ein Erfolg (sErfolg) in die Metanachricht (MetaNachricht) eingegeben, um das W (Wiederaufnehmen) durchzuführen.
  • Die Struktur der im Vorhergehenden erwähnten Metanachricht (MetaNachricht) ist kurz erklärt.
  • Bezug nehmend auf 19 hat die Metanachricht (MetaNachricht) zwei Bereiche, nämlich einen Bereich A für die zum Ausführen der API des Metaaufrufs (Metaaufruf) erforderlichen Informationen, wie ein Argument, und einen Bereich B für Fehlercodes. Die Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) wird durch das Objekt des Versenders (Versender), der einen Bereich für die Tabelle in dem Speicher sichert, erzeugt, wie bei dem in 5 gezeigten Fall eines Erzeugen der Zukunft (Zukunft).
  • 15 zeigt die Prozedur des Anstoßens in dem Metaobjekt (MAnsteuerVersender). In dieser Figur wird wie in 14 bei einem Schritt ST61 das Anstoßen-Verarbeiten in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registriert. Ein Erfolg (sErfolg) wird anschließend bei einem Schritt ST62 in die Metanachricht (MetaNachricht) eingegeben, um das W (Wiederaufnehmen) durchzuführen.
  • 16 zeigt ein Verfahren, bei dem das Basisobjekt in dem Metaraum mAnsteuer ein Verarbeiten zu der Zeit eines Austeigens des Metaobjekt MAnsteuer-Versenders beendet. Die in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registrierte Prozedur wird hier in der Folge ausgeführt, in der ein Verarbeiten angefragt wurde, und die Prozedur wird schließlich zum Beenden des Objektverfahrens genommen.
  • In 16 wird zuerst der Schritt ST71 eingestellt, und das Basisobjekt, das die Ausstiegs-Prozedur angefragt hat, wird (unter Verwendung von beispielsweise einer Funktion LetztenHolen) identifiziert.
  • Bei einem Schritt ST72 wird als Nächstes geprüft, ob das Basisobjekt durch eine Unterbrechung gestartet wurde oder nicht. Das heißt, es wird geprüft, ob das Ausstiegs-Verfahren aufgrund einer Basisobjekt-Unterbrechung gestartet wurde. Wenn das Verfahren durch eine Unterbrechung gestartet wurde, ist es wahrscheinlich, dass nach der Unterbrechung, die ein Starten des Verfahrens bewirkt hat, eine andere Unterbrechung anwesend ist. Bezug nehmend auf 20 wird, wenn das Basisobjekt II während einer Ausführung des Basisobjekts I unterbrochen hat, bei einem Schritt ST73 geprüft, ob der anwesende Ausstieg den Ausstieg der Unterbrechung des Basisobjekts II bedeutet. Wenn sich die Resultate einer Prüfung bei einem Schritt ST72 und ST73 beide als WAHR herausstellen, kehrt ein Verarbeiten bei einem Schritt ST74 zu der im Vorhergehenden erwähnten getrennten Unterbrechung (Wiederaufnahmeunterbrechung) zurück. Wenn die Resultate der Prüfung bei den Schritten ST72 und ST73 beide FALSCH sind, wird die in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registrierte Prozedur durchgeführt. Hinsichtlich dieses Verarbeitens zeigen 17 und 18 ein Senden beziehungsweise ein Ansstoßen.
  • Nachdem das Verarbeiten für die Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) bei einem Schritt ST75 zu Ende geht, wird bei einem Schritt ST76 wieder geprüft, ob das Basisobjekt durch eine Unterbrechung gestartet wurde oder nicht. Dieser Schritt ST76 ist im Wesentlichen der gleiche wie der Schritt ST72. Wenn das Objekt durch eine Unterbrechung gestartet wurde, wird die Prozedur zum Zurückkehren von derselben (AusstiegAusUnterbrechung) ausgeführt, um die erste Unterbrechung zu beenden. Wenn das Objekt durch keine Unterbrechung gestartet ist, wurde das Objekt durch eine übliche Kommunikation zwischen Objekten gestartet. Bei einem Schritt ST78 wird die Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) initialisiert, und eine Nachricht wird zu einem Zeitplaner gesendet, um denselben schlafend zu machen (Schlafendmachen). Das Argument (Basis-Programmfaden) ist ein Basisobjekt, das bei dem Schritt ST71 spezifiziert wird. Bei einem Schritt ST79 wird die so weit ausgeführte Nachricht aus der Nachrichtenwarteschlange des Basisobjekts entfernt.
  • Wenn die Nachrichtenwarteschlange leer geworden ist, geht das Verarbeiten zu Ende. Wenn die Nachrichtenwarteschlange nicht leer ist, wird ein BereitMachen mit der Nachricht, die als Nächste zu liefern ist, als ein Argument zu dem Zeitplaner ausgegeben, so dass das Objekt wieder durch die Nachricht, die durch das Argument angegeben ist, gestartet wird. Dies stellt das Objekt in einen Zustand einer möglichen Ausführung (bereit) für die nächste Nachricht.
  • 17 und 18 zeigen ein Szenario zum Verarbeiten einer der in der Tabelle einer verzögerten Ausführung (VerzögerteAusführungTabelle) registrierten Prozeduren. Wenn beispielsweise 10 in die Tabelle eingegeben wird, werden 10 Operationen ausgeführt. Der Inhalt der Anfrage zu dem Zeitplaner durch die Anwesenheit oder die Abwesenheit der Nachricht ist demselben bei dem Fall des Metaobjekts MLokalVersender ähnlich.
  • Bei einem Fall des Sendens in dem Metaobjekt MLokalerVersender in 17 wird zuerst bei einem Schritt ST81 eine Fortsetzung erzeugt.
  • Bei dem nächsten Schritt ST82 wird geprüft, ob die Adresse der Nachricht der Metaraum mAnsteuer ist. Wenn das Resultat einer Prüfung FALSCH ist, wird ein Metaobjekt Lieferant aufgefordert, ein Verarbeiten durchzuführen, und übernimmt dann eine Markierungskommunikation. Bei einem Schritt ST83 wird der Zustand der Nachrichtenwarteschlange des Objekts der Adresse einer Lieferung einer Nachricht (AktiveNachricht) geprüft. Wenn es in der Nachrichtenwarteschlange keine Nachricht gibt, ist das Objekt in dem Ruhezustand (schlafend, wenn der Zeitplaner eine Überwachung übernimmt). Bei einem Schritt ST85 wird daher ein BereitMachen zu dem Zeitplaner ausgegeben, um den Zustand einer möglichen Ausführung des Objekts einzustellen oder den Zustand einer möglichen Ausführung des Objekts einzustellen, wenn der Zeitplaner in dem Überwachungszustand ist.
  • Wenn bei einem Schritt ST82 und ST83 die Resultate einer Prüfung WAHR sind, wurde die Nachricht zu dem Objekt eines Ziels bereits geliefert, so dass sich das Objekt in dem Zustand einer möglichen Ausführung, im Laufe einer Ausführung (LAUFEND) oder einem ausgesetzten Zustand befindet. Bei einem Schritt ST84 wird daher die entsprechende Nachricht in den hinteren Anschnitt der Nachrichtenwarteschlange eingegeben, um das Verarbeiten zu beenden. Eine Fortsetzung, die der Nachrichtensendung und einer MID zum Spezifizieren derselben entspricht, wird, wie im Folgenden erklärt ist, zu dieser Zeit ferner in der Nachrichtenwarteschlange überwacht.
  • Bei einem Fall des Anstoßens des Metaobjekts MAnsteuer-Versender in 18 wird bei einem Schritt ST91 geprüft, ob eine Fortsetzung, wie angegeben ist, eine Fortsetzung des Metaobjekts MAnsteuer-Versender ist oder nicht. Wenn das Resultat einer Prüfung bei einem Schritt ST91 WAHR ist, wird bei einem Schritt ST92 die Anwesenheit einer Fortsetzung geprüft. Wenn eine Fortsetzung bestätigt wird, wird dieselbe bei einem Schritt ST93 geöffnet und Attribute in der Fortsetzung (Adresse, Verfahren oder Nachricht) werden geprüft, so dass demgemäß das Senden ausgeführt wird. Bei dem nächsten Schritt ST94 wird die Nachricht bestätigt. Bei einem Schritt ST95 wird die Nachricht in den letzten Abschnitt der Nachrichtenwarteschlange eingegeben, um das Verarbeiten zu beenden. Die Markierungs-ID (MID), die einer Nachrichtensendung zugeordnet ist, wie im Folgenden erklärt ist, wird zu dieser Zeit in der Nachrichtenwarteschlange gleichzeitig überwacht.
  • Wenn die Resultate einer Prüfung der Schritte ST92 und ST94 anders sind, wird bei einem Schritt ST96 ein BereitMachen zu dem Zeitplaner ausgegeben, um den Zustand einer möglichen Ausführung des Objekts einzustellen. Die Schritte ST94, ST95 und ST96 sind Funktionen, die denselben der Schritte ST83, ST84 und ST85 ähnlich sind. Wenn das Resultat einer Prüfung bei dem Schritt ST91 FALSCH ist, ist dieser Fall mit dem Fall einer Kommunikation mit anderen Metaräumen durch eine Kommunikationseinrichtung, die die Markierung verwendet, gleichbedeutend, und das Metaobjekt wird aufgefordert, ein Verarbeiten durchzuführen (Lieferant).
  • Basiserklärung der Kommunikationseinrichtung, die eine Markierung verwendet
  • Für eine Kommunikation zwischen Objekten, ist es notwendig, neben einer einfachen Nachrichtensendung eine Synchronisation mit einer Ausführung von anderen Verfahren oder einem Empfang einer Antwort zu erreichen. Die Zukunft und die Fortsetzung sind zu dieser Zeit erforderlich. Die Datenstruktur, die eine Synchronisation und eine Parallelität, die bei einer Kommunikation zwischen mehreren Objekten erforderlich sind, steuert, wie der Zukunft oder der Fortsetzung bei dem vorliegenden Ausführungsbeispiel, ist als eine Markierung bezeichnet. Die Datenstruktur hat eine Struktur wie eine Struktur in der Sprache C oder PASCAL oder eine Klasse in C++. Diese Markierung bezieht unterschiedliche Strukturen auf eine gemeinsame Datenstruktur. Diese gemeinsame Datenstruktur ist zum Umfassen einer Identifizierung (Attribute: wie ein AusfRaumID-Versender) zum Unterscheiden dieser unterschiedlichen Datenstrukturen konfiguriert. Die gemeinsame Datenstruktur ist ferner zum Umfassen einer Identifizierung (Attribute: wie ein Langwort-ZeitStempel) zum Unterscheiden von Datenstrukturen des gleichen Typs konfiguriert, wie unter Bezugnahme auf 21 detailliert erklärt ist. Die zum Unterscheiden der Markierungen notwendige ID ist als eine MarkierungsID (MID) bezeichnet.
  • Für Markierungsattribute sind Markierungstypen erforderlich. Der Markierungstyp muss fähig sein, zu spezifizieren, in welcher Umgebung die Markierung verwendet wird. Der Markierungstyp muss jedoch nicht fähig sein, eine globale Erkennung zu erreichen. Es ist ausreichend, wenn bei einem Fall, dass der Markierungstyp nicht identifiziert werden kann, der Markierungstyp durch Auffordern eines anderen unabhängigen Objekts, das fähig ist, den Markierungstyp zu spezifizieren, identifiziert wird.
  • Indem eine Zukunft (Zukunft) und eine Fortsetzung (Fortsetzung) in dem Metaraum mLokal und dem Metaraum mAnsteuer als Beispiel genommen werden, wird die Kommunikation zwischen unterschiedlichen Metaräumen, die Markierungen verwenden, erklärt. Bei dem vorliegenden Ausführungsbeispiel ist angenommen, dass das Objekt A und das Objekt B in dem Metaraum mLokal beziehungsweise dem Metaraum mAnsteuer anwesend sind, wie im Vorhergehenden erörtert ist, und die folgenden Verfahren sind definiert.
    Objekt A
    Verfahren A1 (A::A1)
    Objekt B
    Verfahren B1 (B::B1)
    Verfahren B2 (B::B2)
  • Der Basisbetrieb der Kommunikation zwischen unterschiedlichen Metaräumen, die Markierungen verwenden, ist für die folgenden zwei Fälle erklärt.
    • 1. Das Objekt A, Verfahren A1 (A::A1) veranlasst das Senden und das WartenAuf (Senden + WartenAuf) für das Verfahren B1 (B::B1).
    • 2. Das Objekt B, Verfahren A1 (A::A1) veranlasst das Senden und das WartenAuf für das Verfahren A1 (A::A1) und bestimmt ein Senden für das Verfahren A1 (A::A1) und bestimmt das Verfahren B2 (B::B2) als ein ununterbrochenes Verfahren.
  • „Falls das Objekt A, Verfahren A1 (A::A1), das Senden und das WartenAuf (Senden + WartenAuf) für das Verfahren B1 (B::B1) veranlasst"
  • Das Verfahren A1 (A::A1) führt das Senden (Objekt B, Verfahren B1, Nachricht (Nrt), Funktion Größevon(Nrt) und Zukunfts-ID (ZukunftsID)) aus. Das Metaobjekt MLokalerVersender zum Durchführen dieses Verarbeiten erzeugt zu dieser Zeit die Zukunft (Zukunft). Es ist ausreichend, wenn die Zukunft (Zukunft) die folgenden Bedingungen erfüllt:
    Die Zukunft (Zukunft) muss ein eindeutiger Gegenstand sein, der fähig ist, die Markierungs-ID zu identifizieren,
    der Markierungstyp zeigt die Zukunft (Zukunft) des Metaraums mLokal an, und
    die Zukunft (Zukunft) hat Attribute der in 6 gezeigten Zukunft (Zukunft).
  • Das Metaobjekt MLokalerVersender fordert das Metaobjekt MAnsteuer-Versender auf, durch eine Einrichtung die Nachricht (Nrt) zu dem Objekt B zu liefern, während dasselbe ferner ein Starten des Verfahrens B1 (B::B1) anfragt. Die Markierungs-ID, die fähig ist, die Zukunft (Zukunft) zu spezifizieren, wird zu dieser Zeit gleichzeitig geliefert. Die Zukunfts-ID (ZukunftsID) wird zum anschließenden Spezifizieren der Zukunft empfangen. Die Variable des Typs ist hier eine Zukunfts-ID (ZukunftsID). Diese ID ist geplant, um die Markierungs-ID unter Erfüllen der Entwurfsanweisungen des Metaraums mLokal abzubilden.
  • Das Objekt B kann nicht wissen oder sollte nicht wissen, woher die Nachricht geliefert wurde, wenn das Verfahren B1 (B::B1) durch seine Nachricht (Nrt) gestartet wird. Dies ist bei der Realisierung einer transparenten Kommunikation zwischen Objekten erforderlich. Wenn das Verfahren B1 (B::B1) gestartet wird, wird gleichzeitig mit der Nachricht (Nrt) eine Fortsetzung gestartet. Die Fortsetzung (Fortsetzung) wird als ein Typ einer Fortsetzungs-ID (FortID) behandelt. Die Variable ist FortID. Diese Variable identifiziert die gleiche Markierung wie die vorhergehende ZukunftsID.
  • Bei einem Fortschritt einer Ausführung des Verfahrens B1 (B::B1) wird das Anstoßen (FortID) ausgeführt. Das Metaobjekt MAnsteuer-Versender prüft zu dieser Zeit den Markierungstyp, der durch die Fortsetzungs-ID (FortID) spezifiziert werden kann. Es gibt zu dieser Zeit von dem Standpunkt des Markierungs-ID-Verwaltungssystems aus zwei Möglichkeiten.
    • 1. Ein System, bei dem ein Metaobjekt MAnsteuer-Versender erkennen kann, dass der mit einer Fortsetzungs-ID (FortID) identifizierbare Markierungstyp die Zukunft (Zukunft) eines Metaraums mLokal ist (Markierungs-ID-Verwaltungssystem (1)).
    • 2. Ein System, bei dem das Metaobjekt MAnsteuer-Versender den mit einer Fortsetzungs-ID (FortID) identifizierbaren Markierungstyp nicht erkennen kann (Markierungs-ID-Verwaltungssystem (2)).
  • Bei dem ersteren System kann das Metaobjekt MAnsteuer-Versender durch eine Einrichtung eine MarkierungsID direkt zu dem Metaobjekt liefern. Wenn die MarkierungsID geliefert wird, kann das Metaobjekt MLokalerVersender ein Verarbeiten auf die gleiche Weise durchführen, als wenn die Antwort (Antwort) in dem Metaraum mLokal durchgeführt wird. Das heißt, eine Ausführung des Verfahrens A1 (A::A1) kann für die Zukunft (Zukunft), die einer MarkierungsID (= Zukunfts-ID (ZukunftsID)) entspricht, auf die gleiche Weise wie das in 10 gezeigte Szenario wieder eingeleitet werden, oder die Antwortnachricht kann vorübergehend in der Zukunft (Zukunft) aufbewahrt werden.
  • Bei dem letzteren Fall kann das folgende Verfahren als ein Verfahren zum Liefern der MarkierungsID zu dem Metaobjekt MLokalerVersender geplant sein.
    • 1. Es gibt ein anderes Objekt, das einen Markierungstyp überwacht. Wenn demselben die MarkierungsID gegeben ist, untersucht dieses Objekt den Typ der MarkierungsID und bereitet ein Verfahren vor, das einen Versender als eine API zeigt, die fähig ist, die Markierung zu verarbeiten. Das Metaobjekt MAnsteuer-Versender verwertet dieses Verfahren, um zu wissen, dass es ausreicht, die MarkierungsID zu dem Metaobjekt MLokalerVersender zu liefern, und liefert die MarkierungsID direkt zu dem Metaobjekt MLokalerVersender (Markierungs-ID-Verwaltungssystem (2A)).
    • 2. Es gibt ein anderes Objekt, das einen Markierungstyp überwacht, und das Objekt liefert die angegebene MarkierungsID direkt zu dem Versender (Versender), der fähig ist, die zugeordnete Markierung zu verarbeiten (Markierungs-ID-Verwaltungssystem (2B)).
  • Bei diesen Fällen wird die MarkierungsID schließlich zu dem Metaobjekt MLokalerVersender geliefert, um eine Ausführung des Verfahrens A1 (A::A1) auf die gleiche Weise wie das in 10 gezeigte Szenario neu zu starten oder die Antwortnachricht vorübergehend in der Zukunft (Zukunft) aufzubewahren.
  • „Das Objekt B, Verfahren A1 (A::A1) veranlasst das Senden und WartenAuf für das Verfahren A1 (A::A1) und bestimmt das Verfahren B2 (B::B2) als ein ununterbrochenes Verfahren"
  • Das Verfahren B1 (B::B1) führt das Senden (Objekt A, Verfahren A1, Nachricht (Nrt), Funktion (Größevon(Nrt)), Verfahren B2 und Nachricht (UnunterbrNrt))) durch. Das Metaobjekt (MAnsteuerVersender), das diese Prozedur ausführt, erzeugt zu dieser Zeit eine Fortsetzung (Fortsetzung), die den folgenden Erfordernissen genügt:
    dass die Fortsetzung (Fortsetzung) ein eindeutiger Gegenstand ist, der durch die MarkierungsID identifiziert werden kann;
    dass der Markierungstyp anzeigt, dass sie eine Fortsetzung (Fortsetzung) des Metaraums (mAnsteuer) ist; und
    dass es das Attribut der in 8 gezeigten Fortsetzung (Fortsetzung) gibt.
  • Das BS, das das Metaobjekt MAnsteuer-Versender umfasst, liefert durch eine Einrichtung die Nachricht (Nrt) zu dem Metaobjekt mLokalerVersender und fragt ein Starten des Verfahrens A1 an. Die MarkierungsID, die fähig ist, die Fortsetzung (Fortsetzung) zu identifizieren, wird gleichzeitig geliefert.
  • Bei der üblichen Kommunikation zwischen Objekten des Metaraums mAnsteuer wird diese MarkierungsID als die Fortsetzungs-ID (FortID) behandelt. Bei diesem Fall ist es jedoch nicht notwendig, das Metaobjekt MLokalerVersender als die Fortsetzungs-ID (FortID) zu behandeln, derart, dass dasselbe als eine MarkierungsID behandelt wird. Wenn bei der üblichen Kommunikation zwischen Objekten des Metaraums mLokal eine Nachricht zum Starten eines Verfahrens geliefert wird, wird derselben eine Markierungs-ID, die von dem Metaobjekt MAnsteuerVersender geliefert wird, auf die gleiche Weise zugeordnet, wie derselben die Zukunft (Zukunft) oder die Zukunfts-ID (ZukunftsID) zugeordnet wird.
  • Bei einem Fortschritt einer Ausführung des Verfahrens A1 (A::A1) wird die Antwort (Antwort() oder Antwort (Antwort Nrt)) ausgeführt. Das Metaobjekt MAnsteuerVersender prüft zu dieser Zeit die Markierungs-ID, die zugeordnet wird, wenn das Verfahren A1 (A::A1) gestartet wird, und prüft den durch die Markierungs-ID identifizierten Markierungstyp. Bei diesem Fall gibt es auf die gleiche Weise, wie bei einer Kommunikation von dem Objekt A in dem Metaraum mLokal zu dem Objekt B in dem Metaraum mAnsteuer, von dem Standpunkt des MarkierungsID-Verwaltungssystems aus zwei Möglichkeiten, nämlich
    • 1. ein System, bei dem ein Metaobjekt MLokalerVersender den Markierungstyp, der als eine Fortsetzung (Fortsetzung) eines Metaraums mLokalerVersender identifizierbar ist, erkennen kann (MarkierungsID-Verwaltungssystem (1)).
    • 2. Ein System, bei dem das Metaobjekt MAnsteuer-Versender den mit einer Markierungs-ID (FortID) identifizierbaren Markierungstyp nicht erkennen kann (MarkierungsID-Verwaltungssystem (2)).
  • Bei diesen beiden Systemen kann, wie bei dem Fall einer Kommunikation von dem Objekt A in dem Metaraum mLokal zu dem Objekt B in dem Metaraum mAnsteuer, die MarkierungsID durch eine Einrichtung zu dem Metaobjekt MAnsteuerVersender geliefert werden. Bei einem Empfang der MarkierungsID führt das Metaobjekt MAnsteuerVersender ein Verarbeiten wie bei dem in 18 gezeigten Szenario durch. Das heißt, die Fortsetzung (Fortsetzung), die der Markierungs-ID zugeordnet ist, wird zuerst zum Erhalten des ununterbrochenen Verfahrens und der ununterbrochenen Nachricht geöffnet. Ansprechend auf den Zustand der Nachrichtenwarteschlange des Objekts, zu dem das ununterbrochene Verfahren geliefert werden sollte (Erzeuger einer Fortsetzung), wird zum schließlichen Starten des Verfahrens B2 (B::B2) auf den Zeitplaner zugegriffen.
  • „Fall einer Realisierung einer Kommunikationseinrichtung bei dem vorliegenden Ausführungsbeispiel, die eine Markierung verwendet"
  • In dem vorliegenden Kapitel ist ein System einer Realisierung, das eine Kommunikation mit einer Transparenz von in dem Metaraum mLokal und in dem Metaraum mAnsteuer anwesenden Objekten unter Verwendung der Markierung ermöglicht, erklärt. Es ist angenommen, dass lediglich zwei Kommunikationseinrichtungen, nämlich eine mLokal-Metaraum-Kommunikationseinrichtung und eine mAnsteuer-Metaraum- Kommunikationseinrichtung, als unterschiedliche Kommunikationseinrichtungen existieren.
  • Zukunft, Fortsetzung und Markierung
  • In dem BS können die Zukunft in einem Metaraum mLokal und eine Fortsetzung in einem Metaraum mAnsteuer als Markierungen behandelt werden. Bei diesem Fall ist es für das BS notwendig, zu unterscheiden, ob die Markierung (Markierung) die Zukunft (Zukunft) oder die Fortsetzung (Fortsetzung) ist. Als ein Typ, um eine Unterscheidung zu machen, wird die ID des Versenders (Versenders) der API verwendet. Wenn die Versender-ID, die als ein Markierungstyp verwendet wird, ein Metaobjekt MLokalerVersender oder ein Metaobjekt MAnsteuer-Versender ist, kann die Markierung identifiziert werden, um die Zukunft (Zukunft) beziehungsweise die Fortsetzung (Fortsetzung) zu sein.
  • 21 zeigt durch ein Objektmodell-Diagramm des Objektmodellierverfahrens (OMT-Verfahrens) die Beziehung zwischen der Markierung, der Zukunft und der Fortsetzung und dieselbe zwischen der Markierung (Markierung) und der Markierungs-ID (MID). Die Klasse Zukunft C1 und die Klasse Fortsetzung C2 können als Unterklassen, die von der Klasse Markierung C3 abgeleitet werden, definiert sein. Die Markierung (Markierung) verwendet einen Ort einer Ausführung (AusfRaumID) als eine Identifizierungs-ID. Bei diesem Fall wird die ID des Orts der Ausführung (AusfRaumID) als äquivalent zu der objektidentifizierenden ID verwendet. Die Markierung (Markierung) kann als eine Markierungs-ID (MID) identifiziert sein. Der in der Markierung (Markierung) enthaltene Zeitstempel wird verwendet, um sicherzustellen, dass die Markierung (Markierung), die unter Verwendung der MarkierungsID (MID) spezifiziert wird, hinsichtlich der Zeitachse eindeutig ist. Wenn die Zukunft (Zukunft) und die Fortsetzung (Fortsetzung) identifiziert werden können, muss der Zeitstempel nicht notwendigerweise verwendet werden.
  • In der mLokal-Metaraum-Kommunikationseinrichtung und in der mAnsteuer-Metaraum-Kommunikationseinrichtung werden die Zukunfts-ID (ZukunftsID) und die Fortsetzungs-ID (FortID) zum Identifizieren einer Zukunft (Zukunft) beziehungsweise einer Fortsetzung (Fortsetzung) verwendet. Wenn die Markierung (Markierung) eingeführt wird, kann diese als eine MarkierungsID (MID), die gemeinsam spezifiziert werden kann, identifiziert werden.
  • Bei dem vorliegenden Ausführungsbeispiel wird eine Typ-Neudefinition in einer Kopfdatei (MLokal.k und MAnsteuer k), die eine Schnittstelle definiert, ausgeführt, so dass der Programmierer die Schnittstelle, die den Metaraum mLokal oder den Metaraum mAnsteuer einrichtet, direkt verwenden kann. Das heißt, in der Kopfdatei des Metaraums mLokal kann die Zukunfts-ID (ZukunftsID) zu der MarkierungsID neu definiert werden. Dies kann durch beispielsweise die Sprache C oder das C++-Definitionsverfahren als eine Typdef-MID-ZukunftsID gezeigt sein; wobei eine Typdef eine Definition eines neuen Typs bedeutet. In der Fortsetzungs-Kopfdatei einer Kopfdatei Mansteuer.k des Metaraums mAnsteuer wird die FortsetzungsID (FortID) zu einer MarkierungsID neu definiert. Dies kann ähnlich als eine Typdef-MID-FortID gezeigt sein.
  • MarkierungsID-Lieferungssystem und ein Objekt, das die MarkierungsID liefert
  • Bei dem vorliegenden Ausführungsbeispiel ist das im Vorhergehenden erwähnte MarkierungsID-Verwaltungssystem (2B) angewendet. Als ein Objekt, das die Kommunikationseinrichtung zwischen unterschiedlichen Metaräumen unterstützt, ist ein Lieferant eingeführt. Das Objekt hat hauptsächlich zwei Schnittstellen (Verfahren oder APIs).
  • Eine derselben, das heißt eine Schnittstelle sFehlerLieferObjekt, liefert die Nachricht (Nrt) zu einem bestimmten Zielobjekt (das durch das Argument Objekt-ID (OID) und ein Adressenverfahren (Sel) dargestellt ist) und fragt bei dem Versender (Versender) des Metaraums, in dem das Zielobjekt existiert, an, das Verfahren des Zielobjekts schließlich zu starten. Diese Schnittstelle sFehlerLieferObjekt wird ferner verwendet, wenn das Zielobjekt auf die MarkierungsID (MID), die als eines der Argumente geliefert wird, anspricht.
  • Die andere Schnittfläche (sFehlerLieferMarkierung) sendet eine MarkierungsID (MID) zurück. Das Objekt Lieferant prüft den Typ der Markierung (Markierung), die der MarkierungsID (MID) entspricht, um zu wissen, zu welchem Versender (Versender) die MarkierungsID (MID) zurückgesendet werden kann. Wenn notwendig, liefert die Schnittstelle (sFehlerLieferMarkierung) ferner die Antwortnachricht (AntwortNrt).
  • Unter den Verfahren, durch die der Versender (engl.: mailer) (Versender) des Metaraums, in dem das Zielobjekt (Lieferantenziel) existiert, zu erkennen ist, gibt es
    • 1. ein Verfahren, bei dem ein Objekt, wenn dasselbe erzeugt wird, vorher in einem Objekt Lieferant registriert wird und das Objekt Lieferant unter Verwendung einer Tabelle oder dergleichen den Inhalt steuert, und
    • 2. ein Verfahren, bei dem ein Metaraum, dem ein Objekt angehört, oder eine ID, die diesen Metaraum identifizieren kann, in einer Datenstruktur enthalten ist, die direkt von dem Objekt verfolgt werden kann. Bei dem vorliegenden Ausführungsbeispiel wird das letztere Verfahren verwendet.
  • Tatsächliche Kommunikation zwischen unterschiedlichen Metaräumen
  • Betreffend die Kommunikation zwischen den unterschiedlichen Metaräumen sind die folgenden zwei Fälle einer Kommunikation zwischen zwei unterschiedlichen Metaräumen (einer in unterschiedlichen Metaräumen anwesenden Kommunikation zwischen Objekten) geplant.
    • A. Der Fall einer Kommunikation, bei der das Metaraumobjekt mLokal eine Kommunikation mit dem Metaraumobjekt mAnsteuer hat oder eine solche Kommunikation hat, um die Antwort zu empfangen; und
    • B. der Fall einer Kommunikation, bei der der Metaraum mAnsteuer eine Kommunikation mit dem Metaraumobjekt mLokal hat oder eine solche Kommunikation hat, um die Antwort zu empfangen.
  • Für die Fälle einer Kommunikation zwischen unterschiedlichen Metaräumen Metaraum mLokal und Metaraum mAnsteuer über ein Objekt Lieferant (Lieferant) zeigen 22 und 23 den ersteren Fall einer Kommunikation A, während 24 und 25 den letzteren Fall einer Kommunikation B zeigen.
  • Bezug nehmend auf 22 ist das Verarbeiten von einer Annahme der Anfrage für eine Prozedur das Senden des Basisobjekts durch das Metaobjekt MLokalerVersender bis zu einer Erzeugung der Zukunft (Zukunft) (Schritt ST101) ähnlich zu demselben, das in 9 gezeigt ist. Die Zukunft (Zukunft) wird jedoch als eine Markierungs-Unterklasse erzeugt.
  • Bei einem Schritt ST102 wird das Lieferungsziel der Nachricht bestätigt. Wenn das Ziel einer Lieferung der Nachricht kein Metaraumobjekt mLokal ist, wird eine Nachricht zu dem Verfahren (Lieferobjekt) des Objekts Lieferant gesendet.
  • Da das Objekt Lieferant das Ziel einer Lieferung durch das Argument des Verfahrens (Lieferobjekt) wissen kann, wird dasselbe weiter zu dem mAnsteuerVersender geliefert, wie bei einem Schritt ST103 gezeigt ist. Die bei einem Schritt ST106 und folgenden Schritten (Schritten ST106, ST107 und ST108) gezeigte Prozedur, nachdem die Lieferung über die Schnittstelle durch das Metaobjekt mAnsteuer-Versender angefragt wurde, ist der Prozedur (Schritte ST83, ST84 und ST85), die das Metaobjekt MAnsteuer-Versender zu der Zeit eines Ausstiegs für das Senden durchführt, ähnlich. Bei diesem Fall wird jedoch die MarkierungsID (MID) bei einem Schritt ST107 der Nachrichtenwarteschlange hinzugefügt.
  • 23 zeigt die Prozedur, wenn die Markierungs-ID (MID), die zu dem Metaraum mAnsteuer geliefert wurde, in dem Metaraum mAnsteuer als die Fortsetzungs-ID (FortID) behandelt wird und angestoßen wird.
  • Bezug nehmend auf 23 weiß das Metaobjekt mAnsteuer-Versender, dass die Fortsetzungs-ID (FortID), die zu der Zeit eines Verarbeiten für ein Anstoßen bei einem Ausstieg bei einem Schritt ST111 bestimmt wird, nicht die Fortsetzung des Metaraums mAnsteuer ist. Die Markierungs-ID (MID) wird daher unter Verwendung der Markierung (LieferMarkierung) des Objekts Lieferant geliefert.
  • Das Objekt Lieferant identifiziert bei einem Schritt ST112 die Markierung (Markierung) von der Markierungs-ID (MID), um aus dem Attribut (AusfRaumID-Versender) zu wissen, dass die Markierung (Markierung) die Markierung des Metaobjekts MLokalerVersender (die Zukunft (Zukunft) des Metaraums (mLokal)) ist. Die Markierungs-ID (MID) wird daher zu dem Metaobjekt MLokalerVersender geliefert.
  • Die Prozedur seit der Zeit, zu der das Metaobjekt MLokalerVersender die Markierungs-ID (MID) angenommen hat, ist der Antwort (Antwort) des Metaobjekts MLokalerVersender von 10 ähnlich. Die anschließende Prozedur sind die Schritte ST14, ST15, ST16, ST17 und ST20, wenn das Resultat eines Schritts ST13 WAHR ist.
  • 24 und 25 zeigen ein Szenario, bei dem eine Nachricht von dem Metaraum mAnsteuer zu dem Metaraum mLokal gesendet wird und eine Antwort empfangen wird. Der Betrieb des Objekts Lieferant ist demselben, der in 22 und 23 gezeigt ist, ähnlich.
  • Das heißt, bei dem Beispiel von 24 ist die Prozedur seit der Zeit, zu der das Metaobjekt MLokalerVersender die Anfrage für eine Prozedur des Sendens des Basisobjekts angenommen hat, bis zu der Zeit einer Erzeugung der Fortsetzung (Fortsetzung) derselben, die in 17 gezeigt ist, ähnlich.
  • Bei einem Schritt ST122 wird das Ziel einer Lieferung der Nachricht bestätigt. Wenn das Ziel einer Nachrichtenlieferung kein Metaraumobjekt mAnsteuer ist, wird die Nachricht zu dem Verfahren (Lieferobjekt) des Objekts Lieferant gesendet.
  • Da das Objekt Lieferant das Ziel einer Lieferung wissen kann, wird die Nachricht weiter zu ihrem Versender (Versender) geliefert, wie bei einem Schritt ST123 gezeigt ist. Die Prozedur nach einer Lieferungsanfrage für das Metaobjekt MLokalerVersender über die Schnittstelle, wie bei Schritten ST126, ST127, ST128 gezeigt ist, ist der Prozedur ähnlich, die das Metaobjekt MLokalerVersender bei einem Ausstieg des Metaobjekts MLokalerVersender von 18 für das Senden durchführt (Schritte ST94, ST95 und ST96).
  • Das Metaobjekt MLokalerVersender weiß andererseits bei Schritten ST131 bis ST134, dass die ZukunftsID (ZukunftsID), die zu der Zeit eines Verarbeitens für ein Anstoßen zu der Zeit eines Ausstiegs bestimmt wird, nicht die Zukunft (Zukunft) des Metaraums mLokal ist, wie bei den Schritten ST11, ST12 und ST13 von 10. Die Markierungs-ID (MID) wird daher unter Verwendung der Markierung (LieferMarkierung) des Objekts Lieferant geliefert. Das ist das Gleiche, wie der Fall, bei dem das Resultat des Schritts ST13 FALSCH ist.
  • Das Objekt Lieferant spezifiziert bei einem Schritt ST135 aus der Markierungs-ID (MID) und weiß aus ihren Attributen, dass die Markierung (Markierung) die Fortsetzung (Fortsetzung) des Metaraums mAnsteuer ist. Die Markierungs-ID (MID) wird daher zu dem Metaobjekt MAnsteuer-Versender geliefert.
  • Die Prozedur seit der Zeit einer Annahme der Markierungs-ID (MID) durch das Metaobjekt MAnsteuer-Versender ist dem Verarbeiten (Schritte ST93, ST94, ST95 und ST96) des Metaobjekts MAnsteuer-Versender, das unter Bezugnahme auf 18 erklärt ist, ähnlich.
  • Andere denkbare Systeme für eine Realisierung
  • In dem vorliegenden Kapitel sind andere denkbare Systeme für eine Realisierung der „Kommunikationseinrichtung, die die Markierung verwendet," als dieselben, die so weit erklärt sind, erklärt.
  • „System für ein Erkennen des Markierungstyps durch die MarkierungsID"
  • Das vorliegende Ausführungsbeispiel hat eine ID des Versenders (Versender) als ein Attribut der Markierung (Markierung). Dies ermöglicht eine Unterscheidung des Typs der Markierung (Markierung). Ein anderes Verfahren ist ein System eines Beifügens der Informationen zum Erkennen des Markierungstyps zu dem Markierungs-ID. Wenn die Markierungs-ID eine ganze Zahl ist, die durch zwei Bits dargestellt ist, kann dieselbe geplant sein, um ein System zu verwenden, bei dem zwei niedrigere Bits für den Typ der Markierung (Markierung) verwendet werden. 26 zeigt ein Beispiel des Systems zum Verifizieren des Markierungstyps durch die MarkierungsID. Das heißt, wenn die Kombination der niedrigeren zwei Bits in 26 00 ist, stellt die Markierungs-ID die Zukunft (Zukunft) des Metaraums mLokal dar. Wenn andererseits die Kombination der niedrigeren zwei Bits 01 ist, stellt die Markierungs-ID die Fortsetzung (Fortsetzung) des Metaraums mAnsteuer dar. Im Gegensatz zu 21 zeigt 27 ein OMT, bei dem lediglich die Markierungs-ID (MID) erzeugt wird, ohne den Gegenstand der Markierung zu verwenden, und die Markierungsattribute in dieser Markierungs-ID (MID) umfasst sind. In 27 sind C1 und C2 die gleichen wie dieselben, die in 21 gezeigt sind. Bei diesem Fall besteht keine Notwendigkeit, einen Markierungsbereich in dem Speicher zu sichern, wodurch Speicherbereich gespart wird. Obwohl bei dem vorliegenden Ausführungsbeispiel die niedrigeren zwei Bits verwendet werden, können selbstverständlich ein einziges Bit oder höhere oder optionale Zwischenbits verwendet sein.
  • Markierungsverwaltungssystem
  • Bei dem vorliegenden Ausführungsbeispiel wurde, wie im Vorhergehenden beschrieben ist, die Möglichkeit eines Verwendens der Markierungsverwaltungssysteme (1), (2) und (3) gezeigt. Bei jedem dieser Systeme wurde gezeigt, dass die Markierung einen Typ als ihr Attribut hat, und der Versender (Versender) den Typ prüft, um eine Entscheidung zu treffen, ob mindestens der Versender (Versender) selbst die Markierung verarbeiten kann oder nicht. Im Unterschied zu diesem Ausführungsbeispiel kann ein solches System geplant sein, bei dem der Typ in den Markierungsattributen nicht umfasst ist und in dem die Markierung, die durch den Versender (Versender) verarbeitet werden kann, in dem Inneren des Versenders (Versenders) verwaltet wird.
  • Bei diesem System werden, wenn die Zukunft (Zukunft) der Fortsetzung (Fortsetzung) durch den Versender (Versender) erzeugt wird, die so erzeugten Informationen in einer Tabelle aufbewahrt, die dem Versender (Versender) selbst gehört. Wenn die Antwort (Antwort) oder das Anstoßen (Anstoßen) durch die Markierung geliefert wird, tastet der Versender (Versender) die Tabelle ab. Wenn die Markierung durch den Versender (Versender) verarbeitet werden kann, wird die übliche Operation der Antwort (Antwort) und des Anstoßens (Anstoßen) durchgeführt. Sonst ist es möglich, wie in dem Markierungsverwaltungssystem (2A), eine Abfrage durchzuführen, zu welchem Versender (Versender) die Markierung geliefert werden kann, oder bei anderen Objekten anzufragen, das folgende Verarbeiten fortzusetzen.
  • Bei diesem Fall muss ein anderes Objekt als der Versender (Versender), das die Markierungs-ID und die zugeordnete Markierung verarbeiten kann, wie das Objekt Lieferant, beispielsweise eine Tabelle bewältigen, wenn der Typ als das Markierungsattribut fehlt.
  • 28 zeigt das Zustandsübergangsdiagramm des Programmfadens (Programmfaden) in dem Zeitplaner. Eine erläuterte Entwurfsanweisung des Zeitplaners ist nun gezeigt.
  • Jeder Programmfaden (Programmfaden) stellt jeden Zustand für eine Ausführungssteuerung dar. Der Zeitplaner überwacht einen Zustandsübergang dieser Programmfaden (Programmfäden) und bestimmt basierend auf dem Attribut, wie einer Prioritätsreihenfolge, welcher Programmfaden als Nächstes ausgeführt wird.
  • Der Zustand Schlafend (Schlafend) zeigt an, dass es in Verbindung mit dem Programmfaden (Programmfaden) nichts auszuführen gibt. Die Nachricht (Nachricht) befindet sich zu dieser Zeit in dem Zustand eines möglichen Empfangs.
  • Der Zustand einer möglichen Ausführung (Bereit) zeigt an, dass sich der Programmfaden (Programmfaden) in dem Zustand einer möglichen Ausführung befindet und in die Warteschlange für Programmfäden (Programmfäden) in dem Zustand einer möglichen Ausführung (BereiteWarteschlangen) in dem Zeitplaner gestellt (eingereiht) wird. Das Objekt, das dem Programmfaden (Programmfaden) in dem Zustand einer möglichen Ausführung (Bereit) zugeordnet ist, wird durch eine M (Metaberechnung) aufgerufen.
  • Der Ausführzustand (Laufend) zeigt an, dass der Programmfaden (Programmfaden) läuft.
  • Der Zustand Wartend (Warten) zeigt den Ausführungsunterbrechungszustand an und wird erzeugt, wenn ein WartenAuf durch die im Vorhergehenden erwähnte Kommunikationsfunktion des Metaraums (mLokal) vor einer Antwort ausgegeben wird.
  • Mehrere Beispiele der Schnittstelle (API) sind im Folgenden erklärt. sFehler.BereitMachen (Programmfaden, Sel, Nrt)
  • Diese Schnittstelle (API) wird durch ein Metaobjekt Versender, wie das im Vorhergehenden erwähnte Metaobjekt (MLokalerVersender), zum Senden der Nachricht (Nrt) zu dem Verfahren, das durch den Wähler (Sel) des Adressenobjekts, das durch den Programmfaden (Programmfaden) verbunden ist, bestimmt ist, verwendet.
  • Der Zeitplaner (Zeitplaner) bewirkt einen Übergang des Zustands des Programmfadens (Programmfadens) aus dem Zustand Schlafend (Schlafend) in den Zustand einer möglichen Ausführung (Bereit), um den Zustand in die Bereiten Warteschlangen einzugeben (einzureihen).
  • Das Adressenobjekt wird aufgerufen, wenn der Programmfaden (Programmfaden) zeitlich geplant wird, das heißt, wenn der Programmfaden (Programmfaden) in dem Zustand einer möglichen Ausführung (Bereit) durch den Zeitplaner (Zeitplaner) ausgeführt wird.
  • Ein sFehler zeigt unterdessen den Zustand des Resultats einer Ausführung an und, wenn ein BereitMachen korrekt in Betrieb gewesen ist, sendet derselbe einen Rückgabewert (sErfolg) zurück, der diese Wirkung anzeigt. Sonst sendet ein sFehler verschiedene Fehler zurück.
  • sFehler-BereitMachen (Programmfaden)
  • Diese Schnittstelle (API) wird durch einen Versender zum Starten einer Ausführung des Programmfadens (Programmfadens) verwendet. Der Zeitplaner (Zeitplaner) bewirkt einen Übergang des Zustands des Programmfadens (ProgrammfadensP) von dem Zustand Wartend (Warten) in den Zustand einer möglichen Ausführung (Bereit), um denselben in die bereiten Warteschlangen (Bereite Warteschlangen) zu stellen (einzureihen). Diese Schnittstelle wird verwendet, wenn ein Objekt, das ein WartenAuf durch die im Vorhergehenden erwähnte Metaraum-(mLokal-)Kommunikationsfunktion ausgegeben hat und sich in dem Zustand Wartend (Warten) befindet, durch die Antwort (Antwort), die durch ein anderes Objekt ausgegeben wird, die Resultatsnachricht empfängt, um in einen Zustand Bereit versetzt zu werden.
  • sFehler-WartenLassen (Programmfaden)
  • Diese Schnittstelle (API) wird zum Stoppen einer Ausführung des Programmfadens (Programmfaden) verwendet. Der Zeitplaner (Zeitplaner) bewirkt einen Übergang des Programmfadens (Programmfaden) von dem Zustand einer möglichen Ausführung (Bereit) in den Zustand Wartend (Warten), um denselben aus den Warteschlangen in den Bereiten Warteschlangen zu entfernen (auszureihen). Jeder Versender muss unterdessen diese Schnittstelle nicht aufrufen, um eine Ausführung des Basisobjekts zu stoppen. Dies liegt daran, dass der Zustand bereits in den Zustand Wartend (Warten) geändert wurde, wenn das Basisobjekt unter Verwendung der im Vorhergehenden erwähnten M (Metaberechnung) den Versender aufruft.
  • sFehler-SchlafendMachen (Programmfaden)
  • Diese Schnittstelle (API) wird durch den Versender zum Stoppen einer Ausführung des Programmfadens (Programmfadens) verwendet. Der Zeitplaner (Zeitplaner) bewirkt einen Übergang des Programmfadens (Programmfadens) von dem Zustand einer möglichen Ausführung (Bereit) in den Zustand Schlafend (Schlafend), um denselben aus den Warteschlangen in den Bereiten Warteschlangen zu entfernen (auszureihen).
  • Der Zustand des Objekts, wie von dem Versender aus gesehen, oder des zugeordneten Programmfadens wird unterdessen in einen Zustand Schlafend (Schlafend), einen Zustand einer möglichen Ausführung (Bereit) und einen Zustand Wartend (Warten) klassifiziert. Dies liegt daran, dass der Versender nicht wissen muss, welches von mehreren Objekten in dem Zustand einer möglichen Ausführung in der CPU läuft.

Claims (11)

  1. Datenkommunikationsverfahren zum Realisieren der Kommunikation zwischen einer Mehrzahl von Objekten eines objektorientierten Systems, dadurch gekennzeichnet, dass die Kommunikation zwischen Objekten von jeweiligen Umgebungen stattfindet, wobei die Umgebungen eine Kommunikationseinrichtung, die auf entweder Zukünften oder Fortsetzungen basiert, verwenden, wobei das Verfahren folgende Schritte aufweist: Erzeugen von Markierungen für jeweilige Kommunikationsnachrichten zwischen Objekten, wobei jede Markierung die Umgebung gemäß der verwendeten Kommunikationseinrichtung identifiziert, um eine Synchronisation einer Ausführung der Kommunikation zwischen den Objekten, die in unterschiedlichen Umgebungen existieren, durch die Lieferung der jeweiligen Markierungen zu steuern; und Senden von jeweiligen Markierungen zusammen mit den Kommunikationsnachrichten.
  2. Datenkommunikationsverfahren nach Anspruch 1, bei dem, wenn eine jeweilige Markierung erzeugt wird, mindestens eine Markierungs-ID zum Identifizieren der Markierung und ein Attribut für die Markierung, das einen Markierungstyp zum Identifizieren einer Umgebung spezifiziert, erzeugt werden.
  3. Datenkommunikationsverfahren nach Anspruch 2, bei dem eine Markierung durch ein Liefern einer Markierungs-ID zu einem Zielobjekt durch ein Lieferobjekt zusammen mit der Kommunikationsnachricht gesendet wird.
  4. Datenkommunikationsverfahren nach Anspruch 3, bei dem. wenn eine Rücknachricht geliefert wird, das Lieferobjekt, das die Rücknachricht und die Markierungs-ID liefert, das Ziel der Rücknachricht basierend auf dem Markierungstyp bestimmt.
  5. Datenkommunikationsverfahren nach Anspruch 4, bei dem das Objekt, das die Markierungs-ID liefert, eine Tabelle von Zielen und jeweiligen Markierungstypen hat.
  6. Datenkommunikationsverfahren nach einem vorhergehenden Anspruch, bei dem ein Objekt zum Liefern des Ziels einer Lieferung basierend auf dem Markierungstyp vorgesehen wird.
  7. Datenkommunikationsverfahren nach Anspruch 1, bei dem eine Markierungs-ID, die mindestens die Markierung identifiziert, erzeugt wird, und ein Attribut, das einen Markierungstyp zum Identifizieren einer Umgebung spezifiziert, erzeugt wird.
  8. Datenkommunikationsverfahren nach Anspruch 7, bei dem die Markierungs-ID aus einer Mehrzahl von Bits gebildet wird und der Markierungstyp unter Verwendung einiger der Bits dargestellt wird.
  9. Computerlesbares Speichermedium, auf dem Codeeinrichtungen aufgezeichnet sind, die, wenn dieselben in einen Computer geladen und ausgeführt werden, bewirken, dass der Computer gemäß einem der vorhergehenden Ansprüche in Betrieb ist.
  10. Computerprogramm, das Codeeinrichtungen umfasst, das, wenn dasselbe in eine Datenverarbeitungseinheit geladen und ausgeführt wird, bewirkt, dass die Datenverarbeitungseinheit gemäß einem der Ansprüche 1 bis 8 in Betrieb ist.
  11. Vorrichtung für ein In-Betrieb-Sein gemäß einem der Ansprüche 1 bis 8, die eine Einrichtung zum Erzeugen der jeweiligen Markierungen und eine Einrichtung zum Senden der jeweiligen Markierungen zusammen mit den Kommunikationsnachrichten aufweist.
DE69837825T 1997-04-10 1998-04-08 Datenübertragungsverfahren Expired - Lifetime DE69837825T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP09244697A JP3817823B2 (ja) 1997-04-10 1997-04-10 データ通信方法
JP9244697 1997-04-10

Publications (2)

Publication Number Publication Date
DE69837825D1 DE69837825D1 (de) 2007-07-12
DE69837825T2 true DE69837825T2 (de) 2008-01-31

Family

ID=14054644

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69837825T Expired - Lifetime DE69837825T2 (de) 1997-04-10 1998-04-08 Datenübertragungsverfahren

Country Status (5)

Country Link
US (1) US6466991B1 (de)
EP (1) EP0871119B1 (de)
JP (1) JP3817823B2 (de)
KR (1) KR19980080985A (de)
DE (1) DE69837825T2 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030079046A1 (en) * 1996-11-27 2003-04-24 Sony Europa B.V. Data communication method using typed continuation
EP1041485A1 (de) 1999-03-31 2000-10-04 Sony Service Center (Europe) N.V. Objekt mit Polymorphismus
KR20000050238A (ko) * 2000-05-30 2000-08-05 김호광 다수의 운영시스템에서 실행 가능한 프로그램 제작 시스템및 방법
KR20020031511A (ko) * 2000-10-20 2002-05-02 김영돈, 정춘보 다수의 하드웨어에서 실행가능한 ｐｄａ 어플리케이션제작방법
US7480909B2 (en) * 2002-02-25 2009-01-20 International Business Machines Corporation Method and apparatus for cooperative distributed task management in a storage subsystem with multiple controllers using cache locking
US20040003007A1 (en) * 2002-06-28 2004-01-01 Prall John M. Windows management instrument synchronized repository provider
US7124414B2 (en) * 2002-10-31 2006-10-17 International Business Machines Corporation Method, system and program product for routing requests in a distributed system
JP5150116B2 (ja) * 2006-03-31 2013-02-20 パナソニック株式会社 Ｉｃカード及び読み書き装置
US8775651B2 (en) * 2008-12-12 2014-07-08 Raytheon Company System and method for dynamic adaptation service of an enterprise service bus over a communication platform
US8891411B2 (en) 2011-09-23 2014-11-18 Avaya Inc. System and method for a conference foyer
KR101389534B1 (ko) * 2013-06-24 2014-04-28 액세스모바일 (주) Ｉｄ 태그 서비스 제공 시스템 및 방법
CN104063285B (zh) * 2014-01-13 2017-06-23 惠州华阳通用电子有限公司 一种基于车载软件平台进程内模块间的消息广播通信方法

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1989002129A1 (en) * 1987-09-04 1989-03-09 Digital Equipment Corporation Session control in network for digital data processing system which supports multiple transfer protocols
US5124909A (en) * 1988-10-31 1992-06-23 Hewlett-Packard Company Software program for providing cooperative processing between personal computers and a host computer
DE69228621T2 (de) * 1991-02-25 1999-07-22 Hewlett Packard Co Objektorientiertes verteiltes Rechnersystem
SE500673C2 (sv) * 1991-11-27 1994-08-08 Icl Systems Ab Förfarande och arrangemang för att åstadkomma en förenklad dialog mellan en central datorenhet och minst en användarenhet
DE69327448T2 (de) * 1992-12-21 2004-03-04 Sun Microsystems, Inc., Mountain View Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
US5566302A (en) * 1992-12-21 1996-10-15 Sun Microsystems, Inc. Method for executing operation call from client application using shared memory region and establishing shared memory region when the shared memory region does not exist
JP3238788B2 (ja) * 1993-03-30 2001-12-17 株式会社エヌ・ティ・ティ・データ オブジェクト通信方式
AU1747395A (en) 1994-03-30 1995-10-23 Apple Computer, Inc. Object oriented message passing system and method
US5724503A (en) * 1995-03-31 1998-03-03 Sun Microsystems, Inc. Method and apparatus for interpreting exceptions in a distributed object system
US5615351A (en) * 1995-07-07 1997-03-25 Bell Communications Research, Inc. Method and system for correlating usage data in a distributed architecture
WO1997022925A1 (en) * 1995-12-15 1997-06-26 Object Dynamics Corp. Method and system for constructing software components and systems as assemblies of independent parts
JP3622313B2 (ja) * 1996-01-29 2005-02-23 株式会社日立製作所 ドキュメント管理システム
US6032199A (en) * 1996-06-26 2000-02-29 Sun Microsystems, Inc. Transport independent invocation and servant interfaces that permit both typecode interpreted and compiled marshaling
US6044409A (en) * 1996-06-26 2000-03-28 Sun Microsystems, Inc. Framework for marshaling and unmarshaling argument object references
US5966663A (en) * 1997-01-14 1999-10-12 Ericsson Messaging Systems Inc. Data communications protocol for facilitating communications between a message entry device and a messaging center
US5999988A (en) * 1997-03-31 1999-12-07 Sun Microsystems, Inc. Method and apparatus for generating and employing a run-time generated stub to reference an object in object oriented systems
US6157959A (en) * 1997-07-03 2000-12-05 Tandem Computers, Incorporated Method and apparatus for providing portable kernel-mode support for fast interprocess communication

Also Published As

Publication number Publication date
DE69837825D1 (de) 2007-07-12
US6466991B1 (en) 2002-10-15
EP0871119A1 (de) 1998-10-14
JPH10283205A (ja) 1998-10-23
JP3817823B2 (ja) 2006-09-06
EP0871119B1 (de) 2007-05-30
KR19980080985A (ko) 1998-11-25

Similar Documents

Publication Publication Date Title
DE69837825T2 (de) Datenübertragungsverfahren
DE69827747T2 (de) Druckersystem und Übertragungsvorrichtung um Druckersteuerungsprogramm zu übertragen
DE69936627T2 (de) In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen
DE69838756T2 (de) Die verarbeitung von eingabe/ausgabeanforderungen von mehreren treibern ermöglichen dateisystem-primitivroutine in einem mehrschicht-treiber-e/a-system
DE69815946T2 (de) Informationsverarbeitungsvorrichtung
DE69630329T2 (de) Verfahren zur Verwaltung des Deaktivierens und Ausschaltens eines Servers
DE69811148T2 (de) Mitgliedschaft in einem unzuverlässigen verteilten Rechnersystem
DE3908459C2 (de) Netzwerkserver
DE602005004166T2 (de) Vorrichtung, system und verfahren zur reinitialisierung einer serialisierung von dateisystemen
DE69630480T2 (de) Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung
US6662202B1 (en) Data management system of a real-time system
DE69628965T2 (de) Verfahren und Gerät zum Verwalten von Beziehungen zwischen Objekten in einer verteilten Objektumgebung
DE69834579T2 (de) Http- sitzung- überwachung
DE69734432T2 (de) Verfahren und Vorrichtung zur Absendung von Clientverfahrenanrufen in einem Server Rechnersystem
DE60013658T2 (de) Fehlertolerante virtuelle Javamaschine
EP1456742B1 (de) Verfahren, gerätesystem und computerprogramm zum speichern und abrufen von druckdaten in einem netzwerk
DE602005004334T2 (de) Nms zur Verarbeitung von Multi-Server Ereignissen
DE19708021C1 (de) Verfahren zur Regelung eines Zugriffs von Rechnern auf Daten eines zentralen Rechners
DE10311082B4 (de) Elektronikdokumentmanagementverfahren
DE4033336A1 (de) Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung
DE10003015A1 (de) Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen
DE69913375T2 (de) Anzeige eines fehlers in einem transaktionsverarbeitungssystem
DE4216871A1 (de) Ausfuehrungsordnen zum sicherstellen der serienherstellbarkeit verteilter transaktionen
DE19955004A1 (de) Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows
WO2001027806A1 (de) Integriertes datenbank-verbundsystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition