DE4131380A1 - Verfahren zur adaption einer objektorientierten applikation - Google Patents

Verfahren zur adaption einer objektorientierten applikation

Info

Publication number
DE4131380A1
DE4131380A1 DE4131380A DE4131380A DE4131380A1 DE 4131380 A1 DE4131380 A1 DE 4131380A1 DE 4131380 A DE4131380 A DE 4131380A DE 4131380 A DE4131380 A DE 4131380A DE 4131380 A1 DE4131380 A1 DE 4131380A1
Authority
DE
Germany
Prior art keywords
application
stub
local
call
remote
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.)
Withdrawn
Application number
DE4131380A
Other languages
English (en)
Inventor
Walter Dipl Ing Meyer
Oliver Rothe
Franz Dr Kneissl
Hans Dipl Ing Hubmann
Ruediger Bess
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE4131380A priority Critical patent/DE4131380A1/de
Priority to DE59202263T priority patent/DE59202263D1/de
Priority to JP5505672A priority patent/JPH06510874A/ja
Priority to PCT/DE1992/000538 priority patent/WO1993006548A1/de
Priority to US08/211,110 priority patent/US5684955A/en
Priority to EP92913509A priority patent/EP0604431B1/de
Publication of DE4131380A1 publication Critical patent/DE4131380A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]
    • 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/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G06F9/449—Object-oriented method invocation or resolution

Description

Die Erfindung betrifft ein Verfahren zur Adaption einer objektorientierten Applikation, so daß diese auf mehrere Betriebssystemprozesse verteilbar ist.
Objektorientierte Applikationen sind mittels einer objekt­ orientierten Programmierung realisierbar. Ein objektorien­ tiertes System besteht nicht nur aus Funktionen oder Pro­ zeduren, welche einander aufrufen, etwa bei einer Program­ mierung mit den Programmiersprachen Fortran, Pascal, C, sondern es sind auch Objekte vorgesehen, die durch den Austausch von Nachrichten miteinander kommunizieren. Ein Beispiel für eine objektorientierte Programmiersprache ist die Programmiersprache C++, welche durch eine Erweiterung der weit verbreiteten Programmiersprache C entstanden ist. In der Pro­ grammiersprache C++ werden Klassen von Objekten durch Typde­ finitionen vereinbart. Die Objekte gelten als Variablen eines Klassentyps und werden als Instanzen der Klasse bezeichnet. Jedes Objekt hat Instanzvariable als einen Satz von Daten. Auf die Instanzvariablen kann nur mittels bestimmter Funk­ tionen zugegriffen werden, die in der jeweiligen Klassendefi­ nition festgelegt werden. Diese der Klasse zugeordneten Zu­ griffsfunktionen heißen Methoden der Klasse. In der Program­ miersprache C++ ist das Senden einer Nachricht an ein Objekt gleichbedeutend mit dem Aufruf einer Methode für dieses Objekt. Die Programmiersprache C++ unterstützt die Vererbung von Klas­ sen. Die Instanzvariablen und die Methoden einer Klasse können von einer abgeleiteten Klasse durch Vererbung übernommen wer­ den. Es können Methoden der Basisklasse mit dem Schlüsselwort virtual deklariert werden, so daß diese Methoden in einer abge­ leiteten Klasse redefinierbar sind. Objekte sind durch Zeiger referenzierbar sowie dynamisch erzeugbar, so daß erst zur Lauf­ zeit entscheidbar ist, welche Implementierung einer Methode tatsächlich ausgeführt wird. In der Programmiersprache C++ sind Applikationen auf genau einen Prozeß im Sinne des Be­ triebssystems begrenzt. Bei einer realen Anwendung kann es zu Problemen führen, wenn die Applikation eine bestimmte Größe überschreitet, da Betriebssystemprozesse nur eine begrenzte Größe annehmen können. Somit ist ohne zusätzliche Maßnahmen auch die Größe einer C++ Applikation begrenzt. Aus einigen Anwendungsbereichen, insbesondere der Automatisierungstechnik sowie der Telekommunikation, bestehen Anforderungen, welche eine Aufteilung der Applikation auf mehrere unabhängige, ge­ trennt ausführbare und ladbare Betriebssystemprozesse ver­ langen. Eine derartige Aufteilung auf mehrere Betriebs­ systemprozesse, also keine light-weight Prozesse, ist mit den Sprachmitteln von C++ alleine nicht formulierbar. Eine derar­ tige Aufteilung einer Applikation auf mehrere Betriebssystem­ prozesse bedingt eine wesentliche Erweiterung der Funktionali­ tät, indem Mechanismen des Betriebssystems genutzt werden sol­ len, die die Kommunikation zwischen den Betriebssystemprozessen herstellen. Es ist denkbar, daß explizit vom Programmierer in die Applikation Aufrufe für eine Interprozeßkommunikation (IPC) eingefügt werden, sowie daß eigene IPC-Klassen verwendet werden. Der Softwareersteller hat in diesem Fall die Program­ mierung der IPC-Mechanismen selbst vorzunehmen. Die Auftei­ lung der Applikation auf die einzelnen Betriebssystemprozesse ist fest im Sourceprogramm eincodiert. Bei einer erforderli­ chen Änderung der Prozeßaufteilung sind vom Programmierer die Sourceprogramme zu modifizieren und erneut zu compilieren.
Es ist Aufgabe der Erfindung, ein Verfahren anzugeben, zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist, so daß insbesondere der Programmierer die zu compilierenden Sourcen der Applikation nicht selbst modifizieren muß.
Diese Aufgabe ist gelöst bei einem Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist,
  • a) mit einem Aufbereitungsverfahren zur Codesubstitution von zu compilierenden Sourcen der Applikation gemäß einem Stub-Konzept,
  • b) mit einem Konfigurationsverfahren zur Verteilung von In­ stanzen der Applikation als Objekte oder Stub-Objekte für zu bindende Module aus compilierten Sourcen der Applikation,
  • c) mit einem beim Ablauf vorgesehenen Kommunikationsverfahren zum Aufrufen von Methoden für Objekte der Applikation mit Hilfe einer Stub-Methode.
Ausführbar ist ein bevorzugtes Verfahren mit zumindest einem von folgenden Verfahrensschritten des Aufbereitungsverfahrens:
  • d) es wird eine Klassendeklaration der Sourcen analysiert für eine Vergabe von Methoden-Identifikationen, so daß Methoden von verwendeten Klassen der Applikation eindeutig mittels der Methoden-Identifikation identifizierbar sind,
  • e) es werden die Klassen der Applikation mit einer generi­ schen Methode ergänzt, mittels welcher jene Methode beim Ablauf lokal aufrufbar ist, welche durch einen Parameter der generischen Methode in Form der Methoden-Identifikation identifiziert wird,
  • f) es werden Basisklassen der Applikation um eine redifinier­ bar deklarierte Stub-Methode ergänzt,
  • g) es wird jeder von bei einem Ablauf vorgesehenen Aufru­ fen von einer Methode für ein Objekt der Klassen ersetzt durch einen beim Ablauf vorgesehenen Aufruf der Stub- Methode für das Objekt,
  • - so daß bei einem positiven Ergebnis des Aufrufs der Stub- Methode für das Objekt beim Ablauf ein Aufruf vorgesehen ist zu einem prozeßübergreifenden Versenden von einer Nach­ richt, durch welche in einem Remote-Prozeß der Aufruf der Methode des Objektes veranlaßt wird, indem die Methoden- Identifikation in der Nachricht enthalten ist,
  • - sowie daß bei einem negativen Ergebnis des Aufrufs der Stub-Methode für das Objekt beim Ablauf im Lokal-Prozeß der Aufruf der Methode des Objektes erfolgt,
  • h) es werden Hilfsdefinitionen für Methoden generiert, so daß zu jeder Methode der Applikation zumindest,
  • - ihr Klassenname,
  • - ihr Methodenname,
  • - ihre Parametertypen,
  • - ihr Parameterstring für ein Einpacken sowie Auspacken von Parametern, sowie,
  • - ihre Methoden-Identifikation definiert sind.
Ausführbar ist ein weiteres bevorzugtes Verfahren mit zumin­ dest einem von folgenden Verfahrensschritten des Konfigura­ tionsverfahrens:
  • k) es wird eine bestimmte Systemkonfiguration der Applikation analysiert für eine Verteilung der Objekte als die Instanzen der Applikation auf die Betriebssystemprozesse der Applikation,
  • m) es wird eine generische Instanzierungsfunktion generiert, mittels welcher beim Ablauf ein neues Objekt der Applikation instanzierbar ist,
  • - mit einer lokalen Instanzierung im Lokal-Prozeß bei einem gemäß der Systemkonfiguration lokal zu instanzierenden Objekt, so daß das negative Ergebnis beim Aufruf der Stub-Methode im Lokal-Prozeß für dieses lokal-instanzierte Objekt vorgesehen ist,
  • - sowie mit einer remoten Instanzierung bei einem gemäß der Systemkonfiguration remote zu instanzierenden Objekt, indem im Lokal-Prozeß ein prozeßübergreifender Anstoß vorgesehen ist zur Instanzierung dieses remote zu instanzierenden Objektes im Remote-Prozeß, sowie mit einer lokalen Instanzierung für ein zu diesem Objekt vorgesehenes lokales Stub-Objekt, dessen Stub-Methode im Lokal-Prozeß redefiniert wird, so daß das posi­ tive Ergebnis beim Aufruf der Stub-Methode für dieses als Stub- Objekt lokal instanzierte Objekt im Lokal-Prozeß vorgesehen ist,
  • n) es wird eine generische Löschfunktion generiert, mittels welcher beim Ablauf die Instanzierung von einem der Objekte der Applikation löschbar ist,
  • - mit einem lokalen Löschen im Lokal-Prozeß bei einem gemäß der Systemkonfiguration lokal-instanzierten Objekt,
  • - sowie mit einem remoten Löschen bei einem gemäß der System­ konfiguration remote instanzierten Objekt, indem im Lokal- Prozeß ein prozeßübergreifender Anstoß vorgesehen ist zum Löschen dieses remote-instanzierten Objektes im Remote-Pro­ zeß, sowie ein lokales Löschen von dem zu diesem Objekt vor­ gesehenen lokalen Stub-Objekt,
  • p) es werden Runfiles erzeugt, indem zu den Modulen bei jeder ladbaren Einheit Module,
  • - für die Instanzierungsfunktion,
  • - für die Löschfunktion sowie
  • - für die Hilfsdefinitionen für die Methoden der Applikation dazugebunden werden.
Ausführbar ist ein weiteres bevorzugtes Verfahren mit zumindest einem von folgenden Verfahrensschritten des Kommunikationsver­ fahrens:
  • r) es wird die Stub-Methode für eines der Objekte lokal auf­ gerufen, sowie im Falle des negativen Ergebnisses erfolgt ein lokaler Methodenaufruf für das Objekt,
  • s) es wird im Falle des positiven Ergebnisses für den lokalen Aufruf der Stub-Methode für das Objekt, aus den gebundenen Hilfsdefinitionen,
  • - die Methoden-Identifikation,
  • - das remote-instanzierte Objekt sowie
  • - Methodenparameter ermittelt,
  • t) es wird anhand des Parameterstrings eine Nachricht verpackt im Lokal-Prozeß,
  • u) es wird die Nachricht im Remote-Prozeß empfangen,
  • v) es wird im Remote-Prozeß nach dem Auspacken der Parameter das lokal instanzierte Objekt ermittelt,
  • w) es wird mittels der generischen Methode anhand der Methoden-Identifikation der Aufruf der dadurch identifizierten Methode ausgeführt.
Der Erfindung liegt die Idee zugrunde, daß die zu compilie­ renden Sourcen der Applikation in einem Aufbereitungsverfah­ ren insbesondere mittels eines Präprozessors modifizierbar sind, so daß durch Codesubstitution Methodenaufrufe ersetzbar sind durch Codesequenzen, mittels derer beim Ablauf entscheid­ bar ist, ob ein prozeßübergreifendes Versenden einer Nach­ richt erforderlich ist, oder ob ein lokaler Aufruf erfolgen soll. Dies ist realisierbar, indem Hilfsdefinitionen für die Methoden generiert werden, so daß durch den Einsatz dieser speziellen Dateien eine Sicherung der Konsistenz des Systems bei der Applikation gewährleistet ist. Dies ist weiterhin er­ zielbar, indem ein Stub-Konzept angewendet wird, bei welchem Stub-Methoden und Stub-Objekte verwendet werden. Weiterhin ist dies erzielbar, indem eine Instanzierungsfunktion sowie eine Löschfunktion in einem Runtime-System eingesetzt wird. Dies ist weiterhin erzielbar, indem bei einem prozeßübergreifenden Kom­ munikationsverfahren beim Ablauf insbesondere eine generische Methode eingesetzt wird, von welcher anhand einer Methoden -Identifikation der dadurch identifizierte Methodenaufruf ausführbar ist.
In einer vorteilhaften Weise braucht der Programmierer die Sourcen nicht selbst modifizieren.
In einer vorteilhaften Weise kann der Programmierer die Sourcen der Applikation beispielsweise mit den Sprachmitteln der Programmiersprache C++ erstellen.
In einer vorteilhaften Weise ist mittels der Codesubstitu­ tion beim Aufbereitungsverfahren nur eine einmalige Modifi­ kation der Sourcen mit deren anschließender Compilierung ausreichend. Bei einer Änderung der Systemkonfiguration, also bei einer Änderung der Verteilung der Applikation auf mehrere Betriebssystemprozesse, ist eine Änderung der Sourcen der Applikation nicht erforderlich, so daß auch eine neue Compilierung nicht erforderlich ist.
In einer vorteilhaften Weise wird mittels der Hilfsdefini­ tionen für eine bestimmte Systemkonfiguration die Konsistenz des Gesamtsystems der objektorientierten Applikation sicher­ gestellt.
Die Erfindung wird anhand der Figuren, in welchen Ausführungs­ beispiele enthalten sind, näher erläutert.
Die Fig. 1 zeigt ein erfindungsgemäßes Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Be­ triebssystemprozesse verteilbar ist.
Die Fig. 2 zeigt ein anderes Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebs­ prozesse verteilbar ist.
Die Fig. 3 zeigt ein Aufbereitungsverfahren für das erfin­ dungsgemäße Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse ver­ teilbar ist.
Die Fig. 4 zeigt ein Konfigurationsverfahren für das erfindungsgemäße Verfahren zur Adaption einer objektorien­ tierten Applikation, welche auf mehrere Betriebssystempro­ zesse verteilbar ist.
Die Fig. 5 zeigt ein prozeßübergreifendes Kommunikations­ verfahren für das erfindungsgemäße Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist.
Die Fig. 6 zeigt einen Methodenaufruf.
Die Fig. 7 zeigt eine Codesequenz nach einer Codesubstitu­ tion des Methodenaufrufs.
Die Fig. 8 zeigt einen prozeßübergreifenden Sendeaufruf für eine Nachricht als einen Teil der Codesequenz.
Die Fig. 9 zeigt einen Aufruf einer Stub-Methode als ein Teil der Codesequenz.
Wie die Fig. 1 zeigt, besteht ein Ausführungsbeispiel für das erfindungsgemäße Verfahren zur Adaption einer objektorientier­ ten Applikation, welche auf mehrere Betriebssystemprozesse verteilbar ist, aus den Verfahrensschritten V100, V200, V300, V400, V500, V600, sowie V700.
Es wird der Verfahrensschritt V100 ausgeführt. Vom Program­ mierer werden die zu compilierenden Sourcen der Applikation erstellt.
Es wird der Verfahrensschritt V200 ausgeführt. Für die zu compilierenden erstellten Sourcen der Applikation wird ein Aufbereitungsverfahren durchgeführt. Dabei kann ein Präpro­ zessor vorgesehen sein zur Durchführung des Aufbereitungs­ verfahrens. Es werden Klassendeklarationen der Sourcen der Applikation analysiert. Es werden Methoden-Identifikationen aufbereitet. Die Klassen der Applikation werden um die gene­ rische Methode ergänzt. Es werden die Methodenaufrufe in den Sourcen der Applikation modifiziert, indem mittels Codesub­ stution Codesequenzen eingesetzt werden anstelle der Metho­ denaufrufe. Es werden Hilfsdefinitionen für die Methoden der Applikation generiert.
Es wird der Verfahrensschritt V300 ausgeführt. Die vom Aufbe­ reitungsverfahren modifizierten Sourcen werden compiliert.
Es folgt der Verfahrensschritt V400. Es wird ein Konfigura­ tionsverfahren ausgeführt. Es wird eine Konfigurationsdatei analysiert. Es wird eine Instanzierungsfunktion generiert. Es wird eine Löschfunktion generiert. Es werden Hilfsdefini­ tionen für die Methoden der Applikation mitgebunden. Es wer­ den Runfiles erzeugt.
Es folgt der Verfahrensschritt V500. Es wird ein Linkverfah­ ren ausgeführt. Es werden ablauffähige Phasen der Betriebs­ systemprozesse gebunden.
Es folgt der Verfahrensschritt V600. Es wird ein Ablauf der Betriebssystemprozesse der Applikation ausgeführt.
Es folgt der Verfahrensschritt V700. Es wird untersucht, ob eine Konfigurationsänderung erforderlich ist. Falls dies der Fall ist, folgt der Verfahrensschritt V400. Gemäß der geänderten Systemkonfiguration wird das Konfigurationsverfahren erneut durchgeführt. Danach folgt der Verfahrensschritt V500, bei welchem das Linkverfahren erneut durchgeführt wird. Danach folgt der Verfahrensschritt V600, bei welchem der Ablauf der Applikation gemäß der geänderten Systemkonfiguration erfolgt.
Wie die Fig. 2 zeigt, besteht ein Ausführungsbeispiel für ein anderes Verfahren zur Adaption einer objektorientierten Applikation aus den Verfahrensschritten V101, V301, V501, V601, V701 sowie V801.
Es wird der Verfahrensschritt V101 ausgeführt. Von einem Programmierer werden die Sourcen der Applikation erstellt. Je nach Aufteilung der Applikation auf mehrere Betriebs­ systemprozesse werden vom Programmierer explizit die Auf­ rufe für eine prozeßübergreifende Kommunikation in den Sourcen der Applikation eingetragen.
Es folgt der Verfahrensschritt V301. Die vom Programmierer erstellten Sourcen werden compiliert.
Es folgt der Verfahrensschritt V501. Für die compilierten Sourcen der Applikation wird das Linkverfahren durchgeführt.
Es folgt der Verfahrensschritt V601. Es erfolgt der Ablauf der Applikation.
Es folgt der Verfahrensschritt V701. Es wird geprüft, ob eine Konfigurationsänderung erforderlich ist. Falls dies der Fall ist, folgt der Verfahrensschritt V801. Gemäß einer neuen Systemkonfiguration werden vom Programmierer die Sourcen der Applikation modifiziert, indem gemäß der neuen Verteilung der Applikation auf einzelne Betriebssystemprozesse in den Sourcen explizit Aufrufe für eine prozeßübergreifende Kommunikation eingefügt werden. Danach folgt erneut der Verfahrensschritt V301, bei welchem die soeben modifizierten Sourcen compiliert werden.
Danach folgt der Verfahrensschritt V501, bei welchem das Linkverfahren erneut durchgeführt wird.
Danach folgt der Verfahrensschritt V601, bei welchem der Ablauf der Applikation gemäß der neuen Systemkonfiguration erfolgt.
Wie die Fig. 3 zeigt, besteht ein Ausführungsbeispiel für das Aufbereitungsverfahren des Verfahrensschrittes V200 aus den Verfahrensschritten V210, V220, V230, V235, V240 sowie V250.
Es wird der Verfahrensschritt V210 ausgeführt. Es wird eine Klassendeklaration der Sourcen der Applikation analysiert für eine Vergabe von Methoden-Identifikationen, so daß die Methoden von den verwendeten Klassen der Applikation system­ weit eindeutig mittels der Methoden-Identifikation identifi­ zierbar sind.
Es folgt der Verfahrensschritt V220. Es wird eine Protokoll- Informations-Datei aufbereitet, in welcher Hilfsdefinitionen für die Methoden der Applikation enthalten sind, so daß zu je­ der Methode der Applikation zumindest ihr Klassenname, ihr Methodenname, ihre Parametertypen, ihr Parameterstring für ein Einpacken sowie Auspacken von Parametern sowie ihre Metho­ den-Identifikation definiert sind.
Es folgt der Verfahrensschritt V230. Es werden die Klassen der Applikation um die generische Methode ergänzt. Mittels der generischen Methode ist anhand der Methoden-Identifika­ tion ein Aufruf der dadurch identifizierten Methode ausführbar.
Es folgt der Verfahrensschritt V235. Es werden die Basisklassen der Applikation um eine redefinierbar deklarierte Stub-Methode ergänzt.
Es folgt der Verfahrensschritt V240. Es werden in den Sourcen die Methodenaufrufe modifiziert mittels einer Codesubsti­ tution.
Es folgt der Verfahrensschritt V250. In einer Hilfsdefini­ tionsdatei werden die Hilfsdefinitionen für die Methoden generiert und aufbereitet.
Wie die Fig. 4 zeigt, besteht ein Ausführungsbeispiel für das Konfigurationsverfahren des Verfahrensschrittes V400 aus den Verfahrensschritten V410, V420, V430, V440 sowie V450.
Es wird der Verfahrensschritt V410 ausgeführt. Es wird eine bestimmte Systemkonfiguration der Applikation anhand einer Konfigurationsdatei analysiert, mittels welcher eine Verteilung der Objekte der Applikation auf die Betriebssystemprozesse der Applikation vorgenommen wird.
Es folgt der Verfahrensschritt V420. Es wird eine generische Instanzierungsfunktion generiert, mittels welcher beim Ablauf die Objekte der Applikation instanzierbar sind.
Es folgt der Verfahrensschritt V430. Es wird eine generische Löschfunktion generiert, mittels welcher beim Ablauf die Instanzierung der Objekte der Applikation löschbar ist.
Es folgt der Verfahrensschritt V440. Es werden Module für die Hilfsdefinitionen für die Methoden der Applikation gebunden.
Es folgt der Verfahrensschritt V450. Es werden Runfiles er­ zeugt, indem zu den Modulen bei jeder ladbaren Einheit Module für die Instanzierungsfunktion, für die Löschfunktion sowie für die Hilfsdefinitionen für die Methoden der Applikation da­ zugebunden werden.
Wie die Fig. 5 zeigt, besteht als ein Teil des Verfahrens­ schrittes V600 ein Ausführungsbeispiel von einem Verfahrens­ schritt V605 für einen Ablauf zum Aufrufen einer Methode für ein Objekt der Applikation aus den Verfahrensschritten V610 bis V680.
In einem Lokal-Prozeß wird der Verfahrensschritt V610 aus­ geführt. Es wird ein lokaler Adressat ermittelt. Dieser ist im Falle eines lokalen Objektes die Instanz selbst. Im Falle eines remoten Objektes ist der lokale Adressat das zugehörige Stub-Objekt.
Es folgt der Verfahrensschritt V620. Es wird für den lokalen Adressaten die Stub-Methode aufgerufen.
Es folgt der Verfahrensschritt V621. Es wird überprüft, ob das Ergebnis beim Aufruf der Stub-Methode für den lokalen Adressaten positiv ist.
Falls das Ergebnis negativ ist, folgt der Verfahrensschritt V680, und es erfolgt der Aufruf der Methode für den lokalen Adressaten, welcher in diesem Fall das instanzierte lokale Objekt ist.
Bei einem positiven Ergebnis folgt der Verfahrensschritt V640. Für die aufzurufende Methode wird deren Methoden-Identifika­ tion ermittelt.
Es folgt der Verfahrensschritt V641. Es wird der remote Adressat ermittelt, welcher in diesem Fall das remote instan­ zierte Objekt ist.
Es folgt der Verfahrensschritt V642. Es werden die Parameter für den remoten Aufruf der Methode verpackt.
Es folgt der Verfahrensschritt V670. Es erfolgt eine Interpro­ zeßkommunikation (IPC) zwischen dem Lokal-Prozeß und dem Re­ mote-Prozeß.
Im Remote-Prozeß folgt der Verfahrensschritt V650. Es werden die Parameter für den Aufruf der Methode ausgepackt.
Es folgt der Verfahrensschritt V651. Es wird der lokale Adressat im Remote-Prozeß ermittelt. Dieser ist in diesem Fall das im Remote-Prozeß instanzierte Objekt.
Es folgt der Verfahrensschritt V652. Es erfolgt ein Aufruf der generischen Methode, bei welcher mittels der Methoden- Identifikation die aufzurufende Methode ermittelt wird.
Es folgt der Verfahrensschritt V660. Es erfolgt der Aufruf der Methode für das im Remote-Prozeß instanzierte Objekt.
Mittels der Interprozeßkommunikation des Verfahrensschrittes V670 wird nach dem Remote-Prozeß der Lokal-Prozeß fortgesetzt.
Wie die Fig. 6 zeigt, besteht ein Ausführungsbeispiel für einen lokalen Aufruf einer Methode für ein Objekt aus einem Objektpointer, einem Methodennamen sowie aus Parametern. Der Objektpointer bildet dabei eine Referenz auf das Objekt, an welches eine Nachricht gesendet wird. Der Methodenname bildet dabei eine Bezeichnung für die Nachricht. Die Para­ meter bilden dabei einen Parameterteil für die Nachricht.
Gemäß vereinbarter Notation gilt beispielsweise folgende Schreibweise:
<Objektpointer< → <Methodenname< (<Parameter<)
<Objektpointer<:
Referenz auf das Objekt, an das die Nachricht gesendet wird
<Methodenname<: Bezeichnung der Nachricht
<Parameter<: Parameterteil für die Nachricht
Beispielsweise bei der Programmiersprache C++ ist deren Nachrichtenmechanismus so ausgelegt, daß nur die Adressie­ rung von Objekten innerhalb eines Betriebssystemprozesses unterstützt wird. Applikationen, welche auf mehrere unab­ hängige Betriebssystemprozesse verteilt werden sollen, be­ nötigen daher einen erweiterten Nachrichtenmechanismus. Diese Erweiterung des Nachrichtenmechanismus soll nicht durch eine Erweiterung der Programmiersprache erfolgen, da auf diese Weise eine Portabilität eingeschränkt ist. Diese Erweiterung des Nachrichtenmechanismus soll in einer solchen Weise vorgenommen werden, daß eine Portabilität gewährleistet ist. Zusätzlich zu dem in der Programmiersprache verankerten prozeßlokalen Nachrichtenmechanismus soll noch ein Mechanis­ mus für einen prozeßübergreifenden Nachrichtenaustausch in Form einer Interprozeßkommunikation (IPC) bereitgestellt wer­ den. Dabei sollen keine neuen Sprachmittel benötigt werden, so daß eine Compilererweiterung nicht erforderlich ist. Von einem Präprozessor soll in einem Aufbereitungsverfahren für die zu compilierenden Sourcen der Applikation ein derartiger Methodenaufruf mittels einer Codesubstitution ersetzt wer­ den durch eine Codesequenz, in welcher zusätzlich implizite Aufrufe für den prozeßübergreifenden Nachrichtenaustausch (IPC) enthalten sind. Mittels dieser Codesequenz soll sowohl der prozeßlokale Nachrichtenaustausch als auch ein erweiterter Nachrichtenaustausch über Prozeßgrenzen hinweg erlaubt werden.
Wie die Fig. 7 zeigt, besteht ein Ausführungsbeispiel für eine derartige Codesequenz aus einem lokalen Aufruf einer Stub-Methode Vstub, so daß bei einem positiven Ergebnis die­ ses Aufrufs eine für die Interprozeßkommunikation (IPC) er­ weiterte Form des Aufrufs vorgesehen ist, sowie daß bei einem negativen Ergebnis ein lokaler Methodenaufruf vor­ gesehen ist, welcher gleich ist dem in der Fig. 6 darge­ stellten Methodenaufruf, welcher durch die in der Fig. 7 dargestellte Codesequenz bei der Codesubstitution ersetzt wird.
Gemäß vereinbarter Notation gilt beispielsweise folgende Schreibweise:
((<Objektpointer< → Vstub())?(SX_SEND((_CSXobj*)
<Objektpointer<, <Methoden-ID<, <Parameterstring<, <Parameter<):
(<Objektpointer< → <Methodenname< (<Parameter<))
<Methoden-ID<:
Methoden-Identifikation zur systemweit eindeutigen Identifizierung von Methoden von Klassen der Applikation
<Parameterstring<: Zeichenstring zur Identifizierung von Parametern beim Einpacken sowie Auspacken von Parametern
Dabei dient die Methoden-Identifikation zur systemweit eindeutigen Identifizierung von Methoden für Klassen der Applikation. Es ist ein Parameterstring vorgesehen, welcher in Form eines Zeichenstrings zur Identifizierung von Para­ metern beim Einpacken sowie Auspacken von Parametern dient.
Wie die Fig. 8 zeigt, enthält ein Ausführungsbeispiel einer derart erweiterten Form des Aufrufs für die Interprozeß­ kommunikation (IPC) einen Aufruf zum prozeßübergreifenden Versenden der Nachricht, einen Objektpointer, eine Methoden­ Identifikation, einen Parameterstring sowie Parameter.
Gemäß vereinbarter Notation gilt beispielsweise folgende Schreibweise:
(SX_SEND((_CSXobj*) <Objektpointer<, <Methoden-ID<, <Parameterstring<, <Parameter<)
Ob dieser Aufruf tatsächlich aktiviert wird, wird zur Laufzeit entschieden durch eine Auswertung des Ergebnisses, welches als eine Abfrage mittels des Aufrufs der Stub-Methode er­ mittelt wird.
Wie die Fig. 9 zeigt, besteht ein Ausführungsbeispiel für einen Aufruf der Stub-Methode aus einem Objektpointer sowie aus dem Methodennamen Vstub.
Gemäß vereinbarter Notation gilt beispielsweise folgende Schreibweise:
(<Objektpointer< → Vstub())
Vor dem Versenden der Nachricht gemäß des Methodennamens an das referenzierte Objekt wird jedesmal ermittelt, ob ein prozeßlokaler Methodenaufruf stattfinden soll, oder ob ein mittels der Interprozeßkommunikation (IPC) erweiterter Auf­ ruf durchgeführt wird. Im Falle eines IPC-Aufrufes kommt die Funktion SX-SEND zum Tragen, welche mit den geeigneten Parametern zu versorgen ist. Diese Parameterversorgung soll bei der Codesubstitution automatisiert vom Präprozessor vor­ genommen werden.
In einer vorteilhaften Weise erfolgt die Codesubstitution nach einfachen Regeln, so daß diese automatisierbar ist, und beispielsweise von einem Tool durchgeführt werden kann.
Zusammen mit der Codesubstitution für die Nachrichtenauf­ rufe sollen auch noch diejenigen Codeteile substituiert wer­ den, welche die Instanzierung von Klassen sowie das Entfer­ nen von Objekten aus dem System betreffen.
Die Entscheidung, welche Form des Nachrichtenmechanismus jeweils zum Tragen kommt, also ein prozeßlokales Versenden der Nachricht oder ein prozeßübergreifendes Versenden der Nachricht, soll zur Laufzeit des Programmes getroffen werden, und zwar in Abhängigkeit von einer aktuellen Systemkonstel­ lation, welche bei objektorientierten Softwaresystemen dyna­ misch veränderbar ist. Um eine hohe Performanz zu gewährlei­ sten, soll diese Abfrage sehr schnell vonstatten gehen und deshalb prozeßlokal erfolgen. In jedem Betriebssystemprozeß soll jeweils eine Instanz existieren, welche darüber Auskunft geben kann, ob sich ein adressiertes Objekt gerade im jeweili­ gen Betriebssystemprozeß des Nachrichtensenders befindet, oder falls es in einem anderen Betriebssystemprozeß existiert, eine Wegeinformation bereitstellen zur Ermöglichung der Adressie­ rung. Dies soll mittels eines Stub-Konzeptes erfolgen.
Bei einem derartigen Stub-Konzept sollen in einer verteilten Applikation in denjenigen Betriebssystemprozessen, welche nicht selbst ein reales Objekt enthalten, Stellvertreter- Objekte als Stub-Objekte anstelle der realen Objekte vor­ handen sein. Diese Stub-Objekte stehen dann im Falle einer Anforderung an das reale Objekt als Ansprechpartner lokal zur Verfügung und können entweder dessen Aufgaben direkt über­ nehmen oder die geforderte Dienstleistung an das reale Objekt weitervermitteln. Diese Stub-Objekte sollen sich gegenüber den anderen Objekten exakt wie die realen Objekte verhalten.
Eine derartige Aufgabe oder eine mögliche Dienstleistung ist beispielsweise die Auskunft darüber, ob es sich bei einem bestimmten Objekt um die Instanz selbst handelt oder um das Stub-Objekt. Falls es sich dabei um die Instanz selbst handelt, kann die Nachricht in der beispielsweise bei der Programmiersprache C++ üblichen Form direkt an das adressierte Objekt gesendet werden. Anderenfalls soll das Stub-Objekt alle notwendigen Informationen darüber bereit­ stellen, um die entsprechende Anforderung an das reale Ob­ jekt weiterzuleiten. Im Bedarfsfall kann jedes Objekt, ein­ schließlich der Stub-Objekte, darüber Auskunft geben, ob es selbst ein Stub-Objekt ist oder nicht. Zu diesem Zweck wird eine Methode, die Stub-Methode Vstub(), als virtuelle Me­ thode in der Basisklasse aller Applikationsklassen bereitge­ stellt. Durch den Vererbungsmechanismus erhalten alle Objekte der Applikation automatisch die Fähigkeit, Auskunft darüber zu geben, ob sie Stub-Objekte sind oder reale Objekte. Es wird in der Basisklasse aller Applikationsklassen die Stub- Methode bereitgestellt, welche im Falle einer Aktivierung ein negatives Ergebnis liefert. Die Stub-Methode ist redefi­ nierbar zu deklarieren, indem die Stub-Methode beispielsweise bei der Programmiersprache C++ das Schlüsselwort virtual ent­ hält. Für Stub-Klassen wird die Stub-Methode redefiniert, so daß sie ein positives Ergebnis liefert. Demnach liefern Stub- Objekte auf die Anfrage Vstub() gemäß der Stub-Methode ein anderes Ergebnis als die Nicht-Stub-Objekte, bei welchen eine Default-Implementierung zum Tragen kommt.
Eine Systemkonfiguration, also eine Aufteilung der Objekte auf Betriebssystemprozesse, braucht erst nach dem Übersetzen der Quellprogramme festgelegt werden. Erst zur Laufzeit soll entschieden werden, welcher Nachrichtenmechanismus jeweils zum Tragen kommt. Dies gilt auch für den Vorgang der Instan­ zierung von Klassen sowie das Entfernen von Objekten aus dem laufenden System. Dies kann nicht statisch vom Compiler er­ ledigt werden, sondern soll vom Laufzeitsystem ausgeführt werden.
Ebenso wie bei der Codesubstitution für die Nachrichten­ aufrufe werden auch die Aufrufe NEW und DELETE in der Source vom Präprozessor durch die Funktionen SX-NEWobj als Instanzierungsfunktion und SX-DELETE als Löschfunktion ersetzt. Diese Funktionen werden im Laufzeitsystem ausge­ führt. Diese Funktionen werden zu jeder ladbaren Einheit dazugebunden. Sie inkorporieren die Informationen darüber, ob ein Objekt lokal oder remote indistanziert oder gelöscht werden soll. Bei der Instanzierung wird demzufolge entweder der Operator NEW beispielsweise bei der Programmiersprache C++ verwendet, oder es wird über die Interprozeßkommunikation die Instanzierung des Objektes in einem anderen Betriebssystem­ prozeß angestoßen und lokal wird dabei nur ein Stub-Objekt erzeugt. Die Löschfunktion entscheidet zur Laufzeit, ob das Objekt, auf das sie angewendet wird, ein Stub-Objekt oder ein reales Objekt ist. Abhängig davon wird entweder der Opera­ tor DELETE beispielsweise bei der Programmiersprache C++ ver­ wendet oder es wird über die Interprozeßkommunikation das Löschen des Objektes in einem anderen Betriebssystemprozeß angestoßen und lokal wird das Stub-Objekt gelöscht. Die Imple­ mentierung der Instanzierungsfunktion und der Löschfunktion wird aufgrund von Angaben in einer Konfigurationsdatei gene­ riert.
Beim prozeßübergreifenden Kommunikationsmechanismus gehen Methodenaufrufe, also auch Aufrufe von Konstrukturen und Destruktoren, über Prozeßgrenzen hinweg, so daß diese Aufrufe in versendbare Daten umzuwandeln sind. Dabei werden die Metho­ den der verwendeten Klassen durch Methoden-Identifikationen identifiziert. Diese Methoden-Identifikationen werden bei­ spielsweise mittels einer Protokoll-Informations-Datei system­ weit eindeutig vergeben und mittels der generischen Methode ausgewertet, welche jedes Objekt besitzt. Die Protokoll- Informations-Datei bildet eine systemweite Datenbasis über Methoden und ihre Methoden-Identifikationen. Diese wird bei jeder Codesubstitution ausgewertet und soweit erforderlich ver­ vollständigt. Die Protokoll-Informations-Partei enthält für jede Methode der Applikation folgende Daten:
  • - Klassenname,
  • - Methodenname,
  • - Typen der Parameter der Methode (diese Angabe ist notwendig, da beispielsweise in der Programmiersprache C++ Methoden nicht allein aufgrund von Klassennamen und Methodennamen, sondern erst durch die Parametertypen eindeutig identifiziert werden können),
  • - Parameterstring (beispielsweise verwendet für das Einpacken sowie Auspacken der Parameter),
  • - Methoden-Identifikation.
Bei der Codesubstitution wird die Definition jeder verwende­ ten Klasse um die generische Methode erweitert. Diese bildet die Methoden-Identifikationen auf lokale Methodenaufrufe ab. Jeder Methoden-Aufruf aus einem anderen Prozeß führt im Em­ pfängerprozeß zunächst zu einem Aufruf der generischen Methode mit der Methoden-Identifikation als Parameter.
Beim prozeßübergreifenden Versenden der Nachricht werden die Parameter des Methodenaufrufs in einer Datenstruktur verpackt und verschickt. Die Funktionen SX-SEND und die generische Me­ thode sind für das Einpacken sowie Auspacken der Parameter vorgesehen. Dazu werden der Funktion SX-SEND Informationen über Methodenparameter codiert übergeben, beispielsweise in Form eines Strings. Dieser Informationsstring, also der Parameter­ string, wird bei der Codesubstitution ebenfalls vom Präpro­ zessor aufbereitet.
Somit wird bei einer objektorientierten Applikation beim Compilieren der Applikation ein Aufbereitungsverfahren, beim Binden ein Konfigurationsverfahren sowie beim Ablauf ein Kommunikationsverfahren angewendet zum Aufrufen von Methoden für Objekte. Bei einer Änderung einer Systemkonfiguration ist eine Adaption der Sourcen nicht erforderlich. Dies gilt auch bei einer Erweiterung der objektorientierten Applikation.

Claims (4)

1. Verfahren zur Adaption einer objektorientierten Applika­ tion, welche auf mehrere Betriebssystemprozesse verteilbar ist,
  • a) mit einem Aufbereitungsverfahren (V200) zur Codesubsti­ tution von zu compilierenden Sourcen der Applikation, ge­ mäß einem Stub-Konzept,
  • b) mit einem Konfigurationsverfahren (V400) zur Verteilung von Instanzen der Applikation als Objekte oder Stub-Objekte für zu bindende Module aus compilierten Sourcen der Applikation,
  • c) mit einem beim Ablauf vorgesehenen Kommunikationsverfahren (V605) zum Aufrufen von Methoden für Objekte der Applikation mit Hilfe einer Stub-Methode.
2. Verfahren nach Anspruch 1, mit zumindest einem von folgenden Verfahrensschritten des Aufbereitungsverfahrens (V200):
  • d) es wird eine Klassendeklaration der Sourcen analysiert (V210) für eine Vergabe von Methoden-Identifikationen, so daß Methoden von verwendeten Klassen der Applikation eindeutig mittels der Methoden-Identifikation identifizierbar sind,
  • e) es werden die Klassen der Applikation mit einer generi­ schen Methode ergänzt (V230), mittels welcher jene Methode beim Ablauf lokal aufrufbar ist, welche durch einen Parameter der generischen Methode in Form der Methoden-Identifikation identifiziert wird,
  • f) es werden Basisklassen der Applikation um eine redifinier­ bar deklarierte Stub-Methode ergänzt (V235),
  • g) es wird jeder von bei einem Ablauf vorgesehenen Aufru­ fen von einer Methode für ein Objekt der Klassen ersetzt (V240) durch einen beim Ablauf vorgesehenen Aufruf der Stub- Methode für das Objekt,
  • - so daß bei einem positiven Ergebnis des Aufrufs der Stub- Methode für das Objekt beim Ablauf ein Aufruf vorgesehen ist zu einem prozeßübergreifenden Versenden von einer Nach­ richt, durch welche in einem Remote-Prozeß der Aufruf der Methode des Objektes veranlaßt wird, indem die Methoden­ Identifikation in der Nachricht enthalten ist,
  • - sowie daß bei einem negativen Ergebnis des Aufrufs der Stub-Methode für das Objekt beim Ablauf im Lokal-Prozeß der Aufruf der Methode des Objektes erfolgt,
  • h) es werden Hilfsdefinitionen für Methoden generiert (250), so daß zu jeder Methode der Applikation zumindest
  • - ihr Klassenname,
  • - ihr Methodenname,
  • - ihre Parametertypen,
  • - ihr Parameterstring für ein Einpacken sowie Auspacken von Parametern, sowie
  • - ihre Methoden-Identifikation definiert sind.
3. Verfahren nach Anspruch 2 mit zumindest einem von folgenden Verfahrensschritten des Konfigurationsverfahrens (V400):
  • k) es wird eine bestimmte Systemkonfiguration der Applikation analysiert (V410) zur Verteilung der Objekte als die Instanzen der Applikation auf die Betriebssystemprozesse der Applikation,
  • m) es wird eine generische Instanzierungsfunktion generiert (V420), mittels welcher beim Ablauf ein neues Objekt der Applikation instanzierbar ist,
  • - mit einer lokalen Instanzierung im Lokal-Prozeß bei einem gemäß der Systemkonfiguration lokal zu instanzierenden Objekt, so daß das negative Ergebnis beim Aufruf der Stub-Methode im Lokal-Prozeß für dieses lokal-instanzierte Objekt vorgesehen ist,
  • - sowie mit einer remoten Instanzierung bei einem gemäß der Systemkonfiguration remote zu instanzierenden Objekt, indem im Lokal-Prozeß ein prozeßübergreifender Anstoß vorgesehen ist zur Instanzierung dieses remote zu instanzierenden Objektes im Remote-Prozeß, sowie mit einer lokalen Instanzierung für ein zu diesem Objekt vorgesehenes lokales Stub-Objekt, dessen Stub-Methode im Lokal-Prozeß redefiniert wird, so daß das posi­ tive Ergebnis beim Aufruf der Stub-Methode für dieses als Stub- Objekt lokal instanzierte Objekt im Lokal-Prozeß vorgesehen ist,
  • n) es wird eine generische Löschfunktion generiert (V430), mittels welcher beim Ablauf die Instanzierung von einem der Objekte der Applikation löschbar ist,
  • - mit einem lokalen Löschen im Lokal-Prozeß bei einem gemäß der Systemkonfiguration lokal-instanzierten Objekt,
  • - sowie mit einem remoten Löschen bei einem gemäß der System­ konfiguration remote instanzierten Objekt, indem im Lokal- Prozeß ein prozeßübergreifender Anstoß vorgesehen ist zum Löschen dieses remote-instanzierten Objektes im Remote-Pro­ zeß, sowie ein lokales Löschen von dem zu diesem Objekt vor­ gesehenen lokalen Stub-Objekt,
  • p) es werden Runfiles erzeugt (V450), indem zu den Modulen bei jeder ladbaren Einheit Module
  • - für die Instanzierungsfunktion,
  • - für die Löschfunktion sowie
  • - für die Hilfsdefinitionen für die Methoden der Applikation dazugebunden werden.
4. Verfahren nach Anspruch 3 mit zumindest einem von folgenden Verfahrensschritten des Kommunikationsverfahrens (V605):
  • r) es wird die Stub-Methode für eines der Objekte lokal auf­ gerufen (V620), sowie im Falle des negativen Ergebnisses erfolgt ein lokaler Methodenaufruf für das Objekt (V680),
  • s) es wird im Falle des positiven Ergebnisses für den lokalen Aufruf der Stub-Methode für das Objekt, aus den gebundenen Hilfsdefinitionen
  • - die Methoden-Identifikation (V640),
  • - das remote-instanzierte Objekt (V641) sowie
  • - Methodenparameter ermittelt,
  • t) es wird anhand des Parameterstrings eine Nachricht verpackt im Lokal-Prozeß (V642),
  • u) es wird die Nachricht im Remote-Prozeß empfangen (V670),
  • v) es wird im Remote-Prozeß nach dem Auspacken der Parameter (V650) das lokal instanzierte Objekt ermittelt (V651),
  • w) es wird mittels der generischen Methode anhand der Methoden-Identifikation (V652) der Aufruf der dadurch identifizierten Methode ausgeführt (V660).
DE4131380A 1991-09-20 1991-09-20 Verfahren zur adaption einer objektorientierten applikation Withdrawn DE4131380A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE4131380A DE4131380A1 (de) 1991-09-20 1991-09-20 Verfahren zur adaption einer objektorientierten applikation
DE59202263T DE59202263D1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation.
JP5505672A JPH06510874A (ja) 1991-09-20 1992-06-30 オブジェクト指向アプリケーションの適合化方法
PCT/DE1992/000538 WO1993006548A1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation
US08/211,110 US5684955A (en) 1991-09-20 1992-06-30 Process for distributing an object-oriented program over a plurality of operating system processes of a computer system
EP92913509A EP0604431B1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE4131380A DE4131380A1 (de) 1991-09-20 1991-09-20 Verfahren zur adaption einer objektorientierten applikation

Publications (1)

Publication Number Publication Date
DE4131380A1 true DE4131380A1 (de) 1993-03-25

Family

ID=6441112

Family Applications (2)

Application Number Title Priority Date Filing Date
DE4131380A Withdrawn DE4131380A1 (de) 1991-09-20 1991-09-20 Verfahren zur adaption einer objektorientierten applikation
DE59202263T Expired - Fee Related DE59202263D1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation.

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE59202263T Expired - Fee Related DE59202263D1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation.

Country Status (5)

Country Link
US (1) US5684955A (de)
EP (1) EP0604431B1 (de)
JP (1) JPH06510874A (de)
DE (2) DE4131380A1 (de)
WO (1) WO1993006548A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995012267A1 (en) * 1993-10-26 1995-05-04 Taligent, Inc. Object-oriented telephony system
DE19535519A1 (de) * 1995-09-25 1997-03-27 Ibm Verfahren zur Reduzierung des Umfanges von Computerprogrammen
DE29807670U1 (de) * 1998-04-28 1998-06-18 Siemens Ag Programmiergerät

Families Citing this family (101)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994011810A1 (en) * 1992-11-13 1994-05-26 Microsoft Corporation A method and system for marshalling interface pointers for remote procedure calls
US6249822B1 (en) 1995-04-24 2001-06-19 Microsoft Corporation Remote procedure call method
US5864862A (en) * 1996-09-30 1999-01-26 Telefonaktiebolaget Lm Ericsson (Publ) System and method for creating reusable components in an object-oriented programming environment
GB9600823D0 (en) * 1996-01-16 1996-03-20 British Telecomm Distributed processing
GB9600854D0 (en) * 1996-01-16 1996-03-20 British Telecomm Distributed processing
US6182083B1 (en) 1997-11-17 2001-01-30 Sun Microsystems, Inc. Method and system for multi-entry and multi-template matching in a database
US6247026B1 (en) 1996-10-11 2001-06-12 Sun Microsystems, Inc. Method, apparatus, and product for leasing of delegation certificates in a distributed system
US6272559B1 (en) 1997-10-15 2001-08-07 Sun Microsystems, Inc. Deferred reconstruction of objects and remote loading for event notification in a distributed system
US6466947B2 (en) 1998-03-20 2002-10-15 Sun Microsystems, Inc. Apparatus and method for dynamically verifying information in a distributed system
US6138238A (en) 1997-12-11 2000-10-24 Sun Microsystems, Inc. Stack-based access control using code and executor identifiers
US6446070B1 (en) 1998-02-26 2002-09-03 Sun Microsystems, Inc. Method and apparatus for dynamic distributed computing over a network
US6438614B2 (en) 1998-02-26 2002-08-20 Sun Microsystems, Inc. Polymorphic token based control
US6708171B1 (en) 1996-04-23 2004-03-16 Sun Microsystems, Inc. Network proxy
US6938263B2 (en) 1996-04-23 2005-08-30 Sun Microsystems, Inc. System and method for facilitating dynamic loading of “stub” information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space
US6463446B1 (en) 1998-02-26 2002-10-08 Sun Microsystems, Inc. Method and apparatus for transporting behavior in an event-based distributed system
US6487607B1 (en) 1998-02-26 2002-11-26 Sun Microsystems, Inc. Methods and apparatus for remote method invocation
US6393497B1 (en) 1998-03-20 2002-05-21 Sun Microsystems, Inc. Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system
US6598094B1 (en) 1998-03-20 2003-07-22 Sun Microsystems, Inc. Method and apparatus for determining status of remote objects in a distributed system
US6237024B1 (en) 1998-03-20 2001-05-22 Sun Microsystem, Inc. Method and apparatus for the suspension and continuation of remote processes
US6560656B1 (en) 1998-02-26 2003-05-06 Sun Microsystems, Inc. Apparatus and method for providing downloadable code for use in communicating with a device in a distributed system
US6226746B1 (en) 1998-03-20 2001-05-01 Sun Microsystems, Inc. Stack-based system and method to combine security requirements of methods
US6185611B1 (en) 1998-03-20 2001-02-06 Sun Microsystem, Inc. Dynamic lookup service in a distributed system
US6578044B1 (en) 1997-11-17 2003-06-10 Sun Microsystems, Inc. Method and system for typesafe attribute matching
US6421704B1 (en) 1998-03-20 2002-07-16 Sun Microsystems, Inc. Method, apparatus, and product for leasing of group membership in a distributed system
US6832223B1 (en) 1996-04-23 2004-12-14 Sun Microsystems, Inc. Method and system for facilitating access to a lookup service
US6282652B1 (en) 1998-02-26 2001-08-28 Sun Microsystems, Inc. System for separately designating security requirements for methods invoked on a computer
US6434598B1 (en) * 1996-07-01 2002-08-13 Sun Microsystems, Inc. Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system
GB9620196D0 (en) * 1996-09-27 1996-11-13 British Telecomm Distributed processing
US5832529A (en) 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
US6237009B1 (en) 1996-10-11 2001-05-22 Sun Microsystems, Inc. Lease renewal service
US6728737B2 (en) 1996-10-11 2004-04-27 Sun Microsystems, Inc. Method and system for leasing storage
US6015348A (en) * 1996-10-18 2000-01-18 Starwave Corporation Scalable game server architecture
US5996012A (en) * 1996-12-10 1999-11-30 International Business Machines Corporation Application development process for use in a distributed computer enterprise environment
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
US6157960A (en) * 1997-05-07 2000-12-05 International Business Machines Corporation Technique for programmatically creating distributed object programs
US6253256B1 (en) 1997-10-15 2001-06-26 Sun Microsystems, Inc. Deferred reconstruction of objects and remote loading in a distributed system
US6957427B1 (en) 1997-10-15 2005-10-18 Sun Microsystems, Inc. Remote object activation in a distributed system
US6604127B2 (en) 1998-03-20 2003-08-05 Brian T. Murphy Dynamic lookup service in distributed system
KR20010034514A (ko) 1998-02-26 2001-04-25 케네쓰 올센 원격 메소드를 식별하는 해시 판정 방법 및 시스템
US6351843B1 (en) * 1998-08-31 2002-02-26 International Business Machines Corporation Dynamically inserting a function into an application executable at runtime
US6260140B1 (en) * 1998-11-30 2001-07-10 Micron Electronics, Inc. Operating system multi boot integrator
US6330669B1 (en) 1998-11-30 2001-12-11 Micron Technology, Inc. OS multi boot integrator
US6421739B1 (en) * 1999-01-30 2002-07-16 Nortel Networks Limited Fault-tolerant java virtual machine
US6901518B1 (en) 1999-04-08 2005-05-31 Sun Microsystems, Inc. Method and system for establishing trust in downloaded proxy code
US6877163B1 (en) 1999-06-14 2005-04-05 Sun Microsystems, Inc. Method and system for dynamic proxy classes
US6845393B1 (en) 1999-06-14 2005-01-18 Sun Microsystems, Inc. Lookup discovery service in a distributed system having a plurality of lookup services each with associated characteristics and services
US6789126B1 (en) 2000-05-09 2004-09-07 Sun Microsystems, Inc. Addressing message gates in a distributed computing environment
US8082491B1 (en) 2000-05-09 2011-12-20 Oracle America, Inc. Dynamic displays in a distributed computing environment
US7065574B1 (en) 2000-05-09 2006-06-20 Sun Microsystems, Inc. Messaging system using pairs of message gates in a distributed computing environment
US6643650B1 (en) 2000-05-09 2003-11-04 Sun Microsystems, Inc. Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US7395333B1 (en) 2000-05-09 2008-07-01 Sun Microsystems, Inc. Method and apparatus to obtain negotiated service advertisement
US7716492B1 (en) 2000-05-09 2010-05-11 Oracle America, Inc. Method and apparatus to obtain service capability credentials
US6898618B1 (en) 2000-05-09 2005-05-24 Sun Microsystems, Inc. Client-specified display services in a distributed computing environment
US7010573B1 (en) 2000-05-09 2006-03-07 Sun Microsystems, Inc. Message gates using a shared transport in a distributed computing environment
US6917976B1 (en) 2000-05-09 2005-07-12 Sun Microsystems, Inc. Message-based leasing of resources in a distributed computing environment
US7188251B1 (en) 2000-05-09 2007-03-06 Sun Microsystems, Inc. System and method for secure message-based leasing of resources in a distributed computing environment
US7080078B1 (en) 2000-05-09 2006-07-18 Sun Microsystems, Inc. Mechanism and apparatus for URI-addressable repositories of service advertisements and other content in a distributed computing environment
US7577834B1 (en) 2000-05-09 2009-08-18 Sun Microsystems, Inc. Message authentication using message gates in a distributed computing environment
US6973493B1 (en) 2000-05-09 2005-12-06 Sun Microsystems, Inc. Mechanism and apparatus for security of newly spawned repository spaces in a distributed computing environment
US7200848B1 (en) 2000-05-09 2007-04-03 Sun Microsystems, Inc. Migrating processes using data representation language representations of the processes in a distributed computing environment
US7072967B1 (en) 2000-05-09 2006-07-04 Sun Microsystems, Inc. Efficient construction of message endpoints
US7243356B1 (en) 2000-05-09 2007-07-10 Sun Microsystems, Inc. Remote method invocation with secure messaging in a distributed computing environment
US7370091B1 (en) 2000-05-09 2008-05-06 Sun Microsystems, Inc. Method and apparatus for obtaining space advertisements
US7016966B1 (en) 2000-05-09 2006-03-21 Sun Microsystems, Inc. Generating results gates in a distributed computing environment
US6950875B1 (en) 2000-05-09 2005-09-27 Sun Microsystems, Inc. Message conductors in a distributed computing environment
US8135796B1 (en) 2000-05-09 2012-03-13 Oracle America, Inc. Mechanism and apparatus for accessing and addressing services in a distributed computing environment
US8001232B1 (en) 2000-05-09 2011-08-16 Oracle America, Inc. Event message endpoints in a distributed computing environment
US6862594B1 (en) 2000-05-09 2005-03-01 Sun Microsystems, Inc. Method and apparatus to discover services using flexible search criteria
US6792466B1 (en) 2000-05-09 2004-09-14 Sun Microsystems, Inc. Trusted construction of message endpoints in a distributed computing environment
US6970869B1 (en) 2000-05-09 2005-11-29 Sun Microsystems, Inc. Method and apparatus to discover services and negotiate capabilities
US7260543B1 (en) 2000-05-09 2007-08-21 Sun Microsystems, Inc. Automatic lease renewal with message gates in a distributed computing environment
US6918084B1 (en) 2000-05-09 2005-07-12 Sun Microsystems, Inc. Spawning new repository spaces using information provided in advertisement schema messages
US6789077B1 (en) 2000-05-09 2004-09-07 Sun Microsystems, Inc. Mechanism and apparatus for web-based searching of URI-addressable repositories in a distributed computing environment
US6868447B1 (en) 2000-05-09 2005-03-15 Sun Microsystems, Inc. Mechanism and apparatus for returning results of services in a distributed computing environment
US6850979B1 (en) 2000-05-09 2005-02-01 Sun Microsystems, Inc. Message gates in a distributed computing environment
US6957237B1 (en) 2000-06-02 2005-10-18 Sun Microsystems, Inc. Database store for a virtual heap
US6865657B1 (en) 2000-06-02 2005-03-08 Sun Microsystems, Inc. Garbage collector for a virtual heap
US6854115B1 (en) 2000-06-02 2005-02-08 Sun Microsystems, Inc. Process persistence in a virtual machine
US6941410B1 (en) 2000-06-02 2005-09-06 Sun Microsystems, Inc. Virtual heap for a virtual machine
US6760815B1 (en) 2000-06-02 2004-07-06 Sun Microsystems, Inc. Caching mechanism for a virtual heap
US6763440B1 (en) 2000-06-02 2004-07-13 Sun Microsystems, Inc. Garbage collection using nursery regions for new objects in a virtual heap
JP2002116917A (ja) * 2000-10-05 2002-04-19 Fujitsu Ltd オブジェクト指向型プログラミング言語によるソース・プログラムをコンパイルするコンパイラ
US7194506B1 (en) 2000-12-21 2007-03-20 Vignette Corporation Method and system for cache management of locale-sensitive content
US6892377B1 (en) * 2000-12-21 2005-05-10 Vignette Corporation Method and system for platform-independent file system interaction
US7296275B2 (en) 2001-01-04 2007-11-13 Sun Microsystems, Inc. Method and system for passing objects in a distributed system using serialization contexts
WO2003013675A1 (en) * 2001-08-07 2003-02-20 Rebel Arts Llc Distributed and fault tolerant server system and method
US7756969B1 (en) 2001-09-07 2010-07-13 Oracle America, Inc. Dynamic provisioning of identification services in a distributed system
US7660887B2 (en) 2001-09-07 2010-02-09 Sun Microsystems, Inc. Systems and methods for providing dynamic quality of service for a distributed system
US7225431B2 (en) * 2002-10-24 2007-05-29 International Business Machines Corporation Method and apparatus for setting breakpoints when debugging integrated executables in a heterogeneous architecture
US7213123B2 (en) * 2002-10-24 2007-05-01 International Business Machines Corporation Method and apparatus for mapping debugging information when debugging integrated executables in a heterogeneous architecture
US7243333B2 (en) * 2002-10-24 2007-07-10 International Business Machines Corporation Method and apparatus for creating and executing integrated executables in a heterogeneous architecture
US7200840B2 (en) * 2002-10-24 2007-04-03 International Business Machines Corporation Method and apparatus for enabling access to global data by a plurality of codes in an integrated executable for a heterogeneous architecture
US7222332B2 (en) * 2002-10-24 2007-05-22 International Business Machines Corporation Method and apparatus for overlay management within an integrated executable for a heterogeneous architecture
US7082600B1 (en) * 2002-11-04 2006-07-25 Savaje Technologies, Inc. Method and apparatus for integrating a computer application programming language runtime environment with an operating system kernel
US7086048B1 (en) 2002-11-04 2006-08-01 Savaje Technologies, Inc. Method and apparatus for combining operating system resource data and application program resource data in a shared object
US7792874B1 (en) 2004-01-30 2010-09-07 Oracle America, Inc. Dynamic provisioning for filtering and consolidating events
US9606846B2 (en) 2005-07-29 2017-03-28 Sap Se System and method for dynamic proxy generation
US20070027877A1 (en) * 2005-07-29 2007-02-01 Droshev Mladen I System and method for improving the efficiency of remote method invocations within a multi-tiered enterprise network
US7971209B2 (en) 2007-05-18 2011-06-28 Sap Ag Shortcut in reliable communication
US7873951B1 (en) * 2007-08-01 2011-01-18 Oracle America, Inc. Automated object delegation
US9201709B2 (en) * 2011-05-20 2015-12-01 Citrix Systems, Inc. Shell integration for an application executing remotely on a server

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4553205A (en) * 1982-09-21 1985-11-12 Salvatore Porchia Flexible macro expansion process
JPS647231A (en) * 1987-06-30 1989-01-11 Toshiba Corp Parallel processing device for object directional system
AU639802B2 (en) * 1990-08-14 1993-08-05 Oracle International Corporation Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment
AU628753B2 (en) * 1990-08-14 1992-09-17 Digital Equipment Corporation Method and apparatus for implementing server functions in a distributed heterogeneous environment
CA2048306A1 (en) * 1990-10-02 1992-04-03 Steven P. Miller Distributed configuration profile for computing system
US5265206A (en) * 1990-10-23 1993-11-23 International Business Machines Corporation System and method for implementing a messenger and object manager in an object oriented programming environment
US5347633A (en) * 1991-04-30 1994-09-13 International Business Machines, Inc. System for selectively intercepting and rerouting data network traffic
US5305461A (en) * 1992-04-03 1994-04-19 International Business Machines Corporation Method of transparently interconnecting message passing systems

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995012267A1 (en) * 1993-10-26 1995-05-04 Taligent, Inc. Object-oriented telephony system
US5455854A (en) * 1993-10-26 1995-10-03 Taligent, Inc. Object-oriented telephony system
DE19535519A1 (de) * 1995-09-25 1997-03-27 Ibm Verfahren zur Reduzierung des Umfanges von Computerprogrammen
DE19535519C2 (de) * 1995-09-25 1999-03-04 Ibm Verfahren zur Reduzierung des Umfanges von Computerprogrammen
DE29807670U1 (de) * 1998-04-28 1998-06-18 Siemens Ag Programmiergerät
US6820270B1 (en) 1998-04-28 2004-11-16 Siemens Aktiengesellschaft Programming device

Also Published As

Publication number Publication date
DE59202263D1 (de) 1995-06-22
EP0604431B1 (de) 1995-05-17
US5684955A (en) 1997-11-04
WO1993006548A1 (de) 1993-04-01
EP0604431A1 (de) 1994-07-06
JPH06510874A (ja) 1994-12-01

Similar Documents

Publication Publication Date Title
DE4131380A1 (de) Verfahren zur adaption einer objektorientierten applikation
DE69924857T2 (de) Programm-kode-umwandlung
DE69727381T2 (de) Verfahren zum transportieren von in einer schnittstellendefinitionssprache definierten datenstrukturen zwischen heterogenen systemen
DE69533148T2 (de) Verfahren und Gerät zur Erzeugung und Verwendung kurzer Operationsidentifizierer in objektorientierten Systemen
DE10335989B4 (de) Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung
DE69931540T2 (de) Fernprozeduraufrufe mit Um- und Rückwandlung von beliebigen, nicht-übereinstimmenden Zeigergrössen
EP0432802A2 (de) Verfahren für die automatische Syntaxanalyse (Parsen) des Textes von Computer-Programmen in Kompilierern
DE19928980A1 (de) Codeerzeugung für einen Bytecode-Compiler
DE602004006253T2 (de) Vorrichtungen und verfahren zur wiederherstellung der synchronisation für objektorientierte softwareanwendungen in verwalteten laufzeitumgebungen
EP2517105B1 (de) Verfahren zum komprimieren von bezeichnern
DE102005010631A1 (de) Interoperabilitäts- und Schnittstellenerzeugungssystem
DE19625195A1 (de) Synchronisationsverfahren
EP1034475A1 (de) Verfahren zum testen von systemkomponenten eines objektorientierten programms
WO1994014117A1 (de) Verfahren zum testen mindestens einer klasse eines objektorientierten programmes auf einem rechner
EP0807883A2 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
EP1040414B1 (de) Verfahren zum umsetzen eines systemaufrufs
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE4104568A1 (de) Verfahren und vorrichtung zur programmverarbeitung
DE69911660T2 (de) Laden von objektorientierten rechnerprogrammen
EP0836721B1 (de) Anlaufsystem eines rechnersystems
WO2004027608A2 (de) System zur bereitstellung eines standard-frameworks für automatisierungsgeräte
EP3935489A1 (de) Verfahren zum erzeugen einer darstellung einer programmlogik, dekompiliervorrichtung, rekompiliersystem und computerprogrammprodukt
EP0662226B1 (de) Verfahren zur bearbeitung eines anwenderprogramms auf einem parallelrechnersystem
WO2019120630A1 (de) Computerprogrammprodukt zur erstellung einer schnittstellensoftware für einen virtuellen bus
DE10105729C1 (de) Verfahren und System zur funktionsmäßigen Erweiterung einer Telekommunikationsanlage

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee