WO1993006548A1 - Verfahren zur adaption einer objektorientierten applikation - Google Patents

Verfahren zur adaption einer objektorientierten applikation Download PDF

Info

Publication number
WO1993006548A1
WO1993006548A1 PCT/DE1992/000538 DE9200538W WO9306548A1 WO 1993006548 A1 WO1993006548 A1 WO 1993006548A1 DE 9200538 W DE9200538 W DE 9200538W WO 9306548 A1 WO9306548 A1 WO 9306548A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
stub
local
objects
remote
Prior art date
Application number
PCT/DE1992/000538
Other languages
English (en)
French (fr)
Inventor
Walter Meyer
Oliver Rothe
Franz Kneissl
Hans-Jürgen HUBMANN
Rüdiger BESS
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to DE59202263T priority Critical patent/DE59202263D1/de
Priority to JP5505672A priority patent/JPH06510874A/ja
Priority to US08/211,110 priority patent/US5684955A/en
Priority to EP92913509A priority patent/EP0604431B1/de
Publication of WO1993006548A1 publication Critical patent/WO1993006548A1/de

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

Definitions

  • the invention relates to a method for adapting an object-oriented application so that it can be distributed over several operating system processes.
  • Object-oriented applications can be implemented by means of object-oriented programming.
  • An object-oriented system does not only consist of functions or procedures that call each other, for example when programming with the programming languages Fortran, Pascal, C, but also objects are provided that are defined by the programming languages Fortran, Pascal, C, but also objects are provided that are defined by the programming languages Fortran, Pascal, C, but also objects are provided that are defined by the programming languages Fortran, Pascal, C, but also objects are provided that are defined by the
  • An example of an object-oriented programming language is the programming language C ++, which was created by an extension of the widely used programming language C.
  • classes of objects are agreed by type definitions.
  • the objects are considered variables of a class type and are called instances of the class.
  • Each object has instance variables as a set of data.
  • the instance variables can only be accessed by means of certain functions which are defined in the respective class definition. These access functions assigned to the class are called methods of the class.
  • sending a message to an object is equivalent to calling a method for this object.
  • the programming language C ++ supports the inheritance of classes.
  • the instance variables and the methods of a class can be inherited from a derived class.
  • Methods of the base class can be declared with the keyword Virtual, so that these methods can be redefined in a derived class.
  • Objects are by pointers Can be referenced and generated dynamically, so that it can only be decided at runtime which implementation of a method is actually carried out.
  • applications are limited to exactly one process in the sense of the operating system.
  • problems can arise if the application exceeds a certain size, since operating system processes can only take on a limited size.
  • the size of a C ++ application is therefore limited without additional measures. From some areas of application, in particular automation technology and telecommunications, there are requirements which require the application to be divided up into a plurality of independent, separately executable and loadable operating system processes.
  • This object is achieved in a method for adapting an object-oriented application, which is based on several
  • Operating system processes can be distributed, a) with a preparation process for code substitution of the application's sources to be compiled according to a stub
  • a preferred method can be carried out with at least one of the following procedural steps of the preparation method: d) a class declaration of the sources is analyzed for the assignment of method identifications, so that methods of the classes of the application used can be clearly identified by means of the method identification, e) es the classes of the application are supplemented with a generic method, by means of which that method can be called locally during the process, which is identified by a parameter of the generic method in the form of the method identification, f) basic classes of the application are redefined.
  • bar-declared stub method added g) each of the calls provided during a run is replaced by a method for an object of the classes by a call of the stub method for the object provided during the run,
  • the method of the object is called up, h) auxiliary definitions for methods are generated, so that at least for each method of the application
  • a further preferred method can be carried out with at least one of the following method steps of the configuration method: k) a specific system configuration of the application is analyzed for a distribution of the objects as the instances of the application to the operating system processes of the application,) it becomes a generic one Instantiation function generated, by means of which a new object of the application can be instantiated during execution,
  • run files are generated by adding modules to the modules for each loadable unit
  • a further preferred method can be carried out with at least one of the following method steps of the communication method: r) the stub method is called locally for one of the objects, and in the event of a negative result, a local method call is made for the object, s) in the case of a positive result for the local call of the stub method for the object, it is made from the bound auxiliary definitions
  • the invention is based on the idea that the sources of the application to be compiled can be modified in a preparation process, in particular by means of a preprocessor, so that code substitution can be used to replace method calls with code sequences by means of which it can be decided during the process whether cross-process sending is possible a message is required or whether a local call should be made.
  • This can be achieved by generating auxiliary definitions for the methods, so that the use of these special files ensures that the system is consistent in the application.
  • This can also be achieved by using a stub concept in which stub methods and stub objects are used.
  • This can also be achieved by using an instantiation function and a delete function in a runtime system.
  • This can also be achieved by using a generic method in the course of a cross-process communication method, in which a method identification can be used to execute the method call identified thereby.
  • the programmer does not have to modify the sources himself.
  • the programmer can create the sources of the application using, for example, the language means of the C ++ programming language.
  • FIG. 1 shows a method according to the invention for adapting an object-oriented application, which can be distributed over several operating system processes.
  • FIG. 2 shows another method for adapting an object-oriented application, which can be distributed over several operating processes.
  • FIG. 3 shows a processing method for the method according to the invention for adapting an object-oriented application, which can be distributed over several operating system processes.
  • FIG. 4 shows a configuration method for the method according to the invention for adapting an object-oriented application, which can be distributed over several operating system processes.
  • FIG. 5 shows a cross-process communication method for the method according to the invention for adapting an object-oriented application, which can be distributed over several operating system processes.
  • FIG. 6 shows a method call.
  • FIG. 7 shows a code sequence after a code substitution of the method call.
  • FIG. 8 shows a cross-process call for a message as part of the code sequence.
  • FIG. 9 shows a call to a stub method as part of the code sequence.
  • FIG. 1 shows, an exemplary embodiment for the method according to the invention for adapting an object-oriented application, which can be distributed over several operating system processes, consists of the method steps V100, V200, V300, V400, V500, V600, and V700.
  • Method step V100 is carried out.
  • the sources of the application to be compiled are created by the programmer.
  • Method step V200 is carried out.
  • a preparation procedure is carried out for the created sources of the application to be compiled.
  • a preprocessor can be provided to carry out the preparation process.
  • Class declarations of the application's sources are analyzed.
  • Method identifications are prepared.
  • the classes of the application are supplemented by the generic method.
  • the method calls in the sources of the application are modified by using code sequences instead of the method calls by means of code substitution. Auxiliary definitions for the methods of the application are generated.
  • Method step V300 is carried out.
  • the sources modified by the processing method are compiled.
  • Method step V400 follows. A configuration tion process carried out. A configuration file is analyzed. An instantiation function is generated. An erase function is generated. Auxiliary definitions for the methods of application are included. Run files are generated.
  • Method step V500 follows. A link procedure is carried out. Executable phases of the operating system processes are bound.
  • Method step V600 follows. The operating system processes of the application are executed.
  • Method step V700 follows. It is examined whether a configuration change is necessary. If this is the case, method step V400 follows. The configuration procedure is carried out again in accordance with the changed system configuration. This is followed by method step V500, in which the link method is carried out again. This is followed by method step V600, in which the application is run according to the changed system configuration.
  • FIG. 2 shows, there is an exemplary embodiment for another method for adapting an object-oriented
  • Method step V10 is carried out.
  • the sources of the application are created by a programmer. Depending on the division of the application into several operating system processes, the programmer explicitly enters the calls for cross-process communication in the sources of the application.
  • Method step V301 follows. The one from the programmer created sources are compiled.
  • Method step V501 follows.
  • the link procedure is carried out for the compiled sources of the application.
  • Method step V601 follows. The application runs.
  • Method step V701 follows. It is checked whether a configuration change is necessary. If this is the case, method step V801 follows. According to a new system configuration, the programmer modifies the sources of the application by explicitly inserting calls for cross-process communication in the sources according to the new distribution of the application to individual operating system processes. Method step V301 then follows again, in which the sources which have just been modified are compiled.
  • step V601 in which the application is run according to the new system configuration.
  • an exemplary embodiment for the preparation process of process step V200 consists of process steps V210, V220, V230, V235, V240, and
  • Method step V210 is carried out.
  • a class declaration of the sources of the application is analyzed for the assignment of method identifications, so that the methods of the classes of the application used can be uniquely identified system-wide by means of the method identification.
  • Method step V220 follows.
  • a protocol information file is prepared, in which auxiliary definitions for the methods of the application are contained, so that for each method of the application at least its class name, its method name, its parameter types, its parameter string for packing and unpacking parameters, and their method identification are defined.
  • Method step V230 follows.
  • the classes of the application are supplemented by the generic method.
  • the method identification can be used to call the method identified thereby.
  • Method step V235 follows.
  • the base classes of the application are supplemented by a redefinable declared stub method.
  • Method step V240 follows.
  • the method calls in the sources are modified by means of a code substitution.
  • Method step V250 follows.
  • the auxiliary definitions for the methods are generated and prepared in an auxiliary definition file.
  • an exemplary embodiment for the configuration method of method step V400 consists of method steps ⁇ V410, V420, V430, V440, and V450.
  • Method step V410 is carried out.
  • a specific system configuration of the application is analyzed using a configuration file, which is used to distribute the objects of the application to the operating system processes of the application.
  • Method step V420 follows. It will be a generic one Instantiation function generated, by means of which the objects of the application can be instantiated during execution.
  • Method step V430 follows. A generic delete function is generated, by means of which the instantiation of the application objects can be deleted.
  • Method step V440 follows. Modules for the auxiliary definitions for the methods of the application are bound.
  • Method step V450 follows. Runfiles are generated by linking modules for the instantiation function, for the delete function and for the auxiliary definitions for the methods of the application to the modules in each loadable unit.
  • FIG. 5 shows, as part of method step V600 there is an exemplary embodiment of method step V605 for a sequence for calling a method for an object of the application from method steps V610 to V680.
  • Method step V610 is carried out in a local process.
  • a local addressee is determined. In the case of a local object, this is the instance itself. In the case of a remote object, the local addressee is the associated stub object.
  • Method step V620 follows.
  • the stub method is called for the local addressee.
  • Method step V621 follows. It is checked whether the result when calling the stub method is positive for the local addressee.
  • method step V680 follows, and the method is called for the local addressee, which in this case is the instantiated local addressee Object.
  • method step V640 follows. The method identification of the method to be called is determined.
  • Method step V641 follows.
  • the remote addressee is determined, which in this case is the remotely instanced object.
  • Method step V642 follows. The parameters for the remote call of the method are packed.
  • Method step V670 follows. Interprocess communication (IPC) takes place between the local process and the remote process.
  • IPC Interprocess communication
  • Method step V650 follows in the remote process.
  • the parameters for calling the method are unpacked.
  • Method step V651 follows.
  • the local addressee is determined in the remote process. In this case, this is the object instantiated in the remote process.
  • Method step V652 follows. The generic method is called, in which the method to be called is determined using the method identification.
  • Method step V660 follows. The method for the object instantiated in the remote process is called.
  • the local process is continued after the remote process by means of the inter-process communication of step V670.
  • an exemplary embodiment for a local call of a method for an object consists of an object pointer, a method name and parameters.
  • the object pointer forms a reference to the object to which a message is being sent.
  • the method name is a name for the message.
  • the parameters form a parameter part for the message.
  • a preprocessor is to replace such a method call by means of a code substitution with a code sequence which also contains implicit calls for cross-process message exchange (IPC).
  • This code sequence should allow both process-local message exchange and extended message exchange across process boundaries.
  • FIG. 7 shows, an exemplary embodiment of such a code sequence consists of a local call to a stub method Vstub, so that if this call is positive, a form of the call which is expanded for interprocess communication (IPC) is provided, and that in the event of a negative result, a local method call is provided which is the same as the method call shown in FIG. 6, which is replaced by the code sequence shown in FIG. 7 for code substitution.
  • IPC interprocess communication
  • ⁇ Parameter string> character string for identifying parameters when packing and unpacking parameters
  • the method identification serves for the system-wide unique identification of methods for classes of the application.
  • a parameter string is provided, which is used in the form of a character string to identify parameters when packing and unpacking parameters.
  • an exemplary embodiment of such an expanded form of the call for interprocess communication contains a call to send the message across processes, an object pointer, a method identification, a parameter string and parameters.
  • IPC interprocess communication
  • Whether this call is actually activated is decided at runtime by evaluating the result, which is determined as a query by calling the stub method.
  • an exemplary embodiment for calling the stub method consists of an object pointer and the method name Vstub.
  • IPC interprocess communication
  • the code substitution is carried out according to simple rules, so that it can be automated and can be carried out, for example, by a tool.
  • stub objects should be present as stub objects instead of the real objects in a distributed application in those operating system processes which do not themselves contain a real object.
  • these stub objects are then available locally as contact persons and can either take over their tasks directly or pass on the required service to the real object.
  • These stub objects should behave exactly like the real objects compared to the other objects.
  • Such a task or a possible service is, for example, information as to whether a particular object is the instance itself or the stub object. If this is the instance itself, the message can be sent directly to the addressed object in the form common, for example, in the programming language C ++. Otherwise the stub object should provide all the necessary information about it in order to meet the corresponding requirements for the real object. to forward. If necessary, each object, including the stub objects, can provide information as to whether or not it is a stub object itself. For this purpose, a method, the stub method VstubO, is provided as a virtual method in the base class of all application classes. The inheritance mechanism automatically gives all objects in the application the ability to provide information about whether they are stub objects or real objects.
  • the stub method is provided in the base class of all application classes, which returns a negative result if activated.
  • the stub method must be redefinable, for example in the programming language C ++ the stub method contains the keyword virtual.
  • the stub method is redefined so that it returns a positive result. Accordingly, stub objects on the request VstubO according to the stub method deliver a different result than the non-stub objects, for which a default implementation comes into play.
  • a system configuration i.e. a distribution of the objects to operating system processes, only needs to be defined after the source programs have been compiled. Only at runtime should it be decided which message mechanism is to be used. This also applies to the process of instantiating classes and removing objects from the running system. This cannot be done statically by the compiler, but should be carried out by the runtime system.
  • the calls NEW and DELETE in the source are replaced by the functions of the preprocessor SX_NEWobj as an instantiation function and SX_DELETE as a delete function. These functions are carried out in the runtime system. These functions are linked to every loadable unit. You incorporate the information about whether an object should be locally or remotely distanced or deleted. Accordingly, during the instantiation, either the operator NEW is used, for example in the programming language C ++, or the instantiation of the object in another operating system process is initiated via the interprocess communication and only one stub object is generated locally.
  • the delete function decides at runtime whether the object to which it is applied is a stub object or a real object.
  • either the operator DELETE is used, for example, in the programming language C ++ or the deletion of the object in another operating system process is initiated via the interprocess communication and the stub object is deleted locally.
  • the implementation of the instantiation function and the delete function is generated on the basis of information in a configuration file.
  • method calls including calls to structures and destructors, go beyond process boundaries, so that these calls are to be converted into data that can be sent.
  • the methods of the classes used are identified by method identifications. These method identifications are, for example, uniquely assigned system-wide using a protocol information file and evaluated using the generic method that each object has.
  • the protocol information file forms a system-wide database of methods and their method identifications. This is evaluated with each code substitution and, if necessary, completed.
  • the protocol information party contains the following data for each method of the application:
  • each class used is expanded to include the generic method. This maps the method identifications to local method calls. Each method call from another process initially leads to a call of the generic method with the method identification as a parameter in the receiver process.
  • the parameters of the method call are packed and sent in a data structure.
  • the functions SX-SEND and the generic method are intended for packing and unpacking the parameters.
  • the function SX-SEND is passed coded information about method parameters, for example in the form of a string. This information string, ie the parameter string, is also prepared by the preprocessor when the code is substituted.
  • a processing method is used when the application is compiled, a configuration method is used when binding, and a communication method is used to call up methods for objects. If the system configuration is changed, it is not necessary to adapt the sources. This also applies to an expansion of the object-oriented application.

Abstract

Es wird bei einer objektorientierten Applikation beim Compilieren der Sourcen 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.

Description

Verfahren zur Adaption einer objektorieπtierten Applikation
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 Objket. Die Programmiersprache C++ unterstützt die Vererbung von Klas¬ sen. Die Instanzvariablen uno 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, sodaß diese Methoden in einer abge- leiteten KLasse redefinierbar sind. Objekte sind durch Zeiger referenzierbar, sowie dynamisch erzeugbar, sodaß 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++ Applikatation 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 weroen 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 Progra - 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 Sourceprogamme 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, sodaß 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 Aufbereitüngsverfahrens: d) es wird eine Klassendeklaration der Sourcen analysiert für eine Vergabe von Methoden-Identifikationen, sodaß 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,
- sodaß 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- rieht, 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, sodaß 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, ) 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, sodaß das negative Ergebnis beim Aufruf der Stub-Methode im Lokal-Prozeß für dieses lokal-instanzierte Objekt vorgesehen ist,
- sowie mit einer re oten 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 Instanzierur.y für ein zu diesem Objekt vorgesehenes lokales Stub-Objekt, dessen Stub-Methode im Lokal-Prozeß redefiniert wird, sodaß 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 Hilfsdefinitioneπ 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, sodaß durch Codesubstitution Methodenaufrufe ersetzbar sind durch Codesequenzen, mittels derer beim Ablauf entscheid¬ bar ist, ob ein prozeßübergreifendes Versenden einer Nach- rieht erforderlich ist, oder ob ein lokaler Aufruf erfolgen soll. Dies ist realisierbar, indem Hilfsdefinitionen für die Methoden generiert werden, sodaß durch den Einsatz dieser speziellen Dateien eine Sicherung der Konsistenz des Systems bei der Applikation gewährleistet ist. Dies ist weiters er- zielbar, indem ein Stub-Konzept angewendet wird, bei welchem Stub-Methoden und Stub-Objekte verwendet werden. Weiters ist dies erzielbar, indem eine Instanzierungsfunktion sowie eine Löschfunktion in einem Runtime-System eingeetzt wird. Dies ist weiters 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, sodaß 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 Figur 1 zeigt ein erfindungsgemäßes Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Be- triebssystemprozesse verteilbar ist.
Die Figur 2 zeigt ein anderes Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebs¬ prozesse verteilbar ist.
Die Figur 3 zeigt ein Aufbereitungsverfahren für das erfin¬ dungsgemäße Verfahren zur Adaption einer objektorientierten Applikation, welche auf mehrere Betriebssystemprozesse ver¬ teilbar ist.
Die Figur 4 zeigt ein Konfigurationsverfahren für oas erfindungsgemäße Verfahren zur Adaption einer objektorien¬ tierten Applikation, welche auf mehrere Betriebssystempro¬ zesse verteilbar ist.
Die Figur 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 Figur 6 zeigt einen Methodeπaufruf. Die Figur 7 zeigt eine Codesequenz nach einer Codesubstitu¬ tion des Methodenaufrufs.
Die Figur 8 zeigt einen prozeßübergreifenden Sendeaufruf für eine Nachricht als einen Teil der Codesequenz.
Die Figur 9 zeigt einen Aufruf einer Stub-Methode als ein Teil der Codesequenz.
Wie die Figur 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 Verfahrεnsschritt 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 Iπstanzierungsfunktion generiert. Es wird eine Löschfunktioπ generiert. Es werden Hilfsdefini¬ tionen für die Methoden der Applikation mitgebundeπ. 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 Figur 2 zeigt, besteht ein Ausführungsbeispiel für ein anderes Verfahren zur Adaption einer objektorientierten
Applikation aus den Verfahrensschritteπ VlOl, V301, V501, V601 , V701, sowie V801.
Es wird der Verfahrensschritt VlOl ausgeführt. Von einem Programmierer werden die Sourcen der Applikation erstellt. Je nach Aufteilung der Applikation auf mehrere Betriebε- 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 modifizierte 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 Systemkoπfiguration erfolgt.
Wie die Figur 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, sodaß die Methoden von den verwendeten Klassen der Applikation system- weit eindeutig mittels der Methoden-Idenifikation 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, sodaß 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 Figur 4 zeigt, besteht ein Ausführungsbeispiel für das Konfigurationsverfahren des Verfahrensschrittes V400 aus den Verfahrensschritteπ 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 Objkete 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 Figur 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 Objket 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 Obj ekt 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 Figur 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 Nachrichtenmechanismusses 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, sodaß 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 Figur 7 zeigt, besteht ein Ausführungsbeispiel für eine derartige Codesequenz aus einem lokalen Aufruf einer Stub-Methode Vstub, sodaß 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 Figur 6 darge¬ stellten Methodenaufruf, welcher durch die in der Figur 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>-XMethodenname>(<Parameter>))
<Methoden-ID>: Methoden-Identifikation zur systemweit ein¬ deutigen Identifizierung von Methoden von Klassen der Applikation
<Parameterstring>: Zeichenstring zur Identifizierung von Parametern beim Einpacken sowie Aus¬ packen 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 Zeichensstrings zur Identifizierung von Para¬ metern beim Einpacken sowie Auspacken von Parametern dient.
Wie die Figur 8 zeigt, enthält ein Austuhrungsbeispiel 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 Figur 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>->VstubO)
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, sodaß 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 Nachrichtenmechanismusses 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 von statten 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 Objket 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 VstubO, 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, sodaß sie ein positives Ergebnis liefert. Demnach liefern Stub- Objekte auf die Anfrage VstubO 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 Objket 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-Objket 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, sodaß 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 Aufbereituπgsverfahren, beim Binden ein Konfigurationsverfahren, sowie beim Ablauf ein Kommunikationsverfahren angewendet zum Aufrufen von Methcαen 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

Patentansprüche
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 co pilierten 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, sodaß 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, - sodaß 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), sodaß 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, sodaß 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, sodaß 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 re ote-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).
PCT/DE1992/000538 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation WO1993006548A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE59202263T DE59202263D1 (de) 1991-09-20 1992-06-30 Verfahren zur adaption einer objektorientierten applikation.
JP5505672A JPH06510874A (ja) 1991-09-20 1992-06-30 オブジェクト指向アプリケーションの適合化方法
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 (2)

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

Publications (1)

Publication Number Publication Date
WO1993006548A1 true WO1993006548A1 (de) 1993-04-01

Family

ID=6441112

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1992/000538 WO1993006548A1 (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 (1)

* 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

Families Citing this family (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5455854A (en) * 1993-10-26 1995-10-03 Taligent, Inc. Object-oriented telephony system
US6249822B1 (en) 1995-04-24 2001-06-19 Microsoft Corporation Remote procedure call method
DE19535519C2 (de) * 1995-09-25 1999-03-04 Ibm Verfahren zur Reduzierung des Umfanges von Computerprogrammen
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 케네쓰 올센 원격 메소드를 식별하는 해시 판정 방법 및 시스템
DE29807670U1 (de) * 1998-04-28 1998-06-18 Siemens Ag Programmiergerät
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

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
9TH INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS, 5.- 9. Juni 1989, NEWPORT BEACH, CA, US Seiten 550 - 559 A. P. BLACK ET AL. 'Implementing Location Independent Invocation' *
ACM TRANSACTIONS ON COMPUTER SYSTEMS Bd. 2, Nr. 1, Februar 1984, NEW YORK, US Seiten 39 - 59 A. D. BIRRELL ET AL. 'Implementing Remote Procedure Calls' *
IEEE SOFTWARE Bd. 2, Nr. 3, Mai 1985, NEW YORK, US Seiten 9 - 19 N. GAMMAGE ET AL. 'XMS: A Rendezvous-Based Distributed System Software Architecture' *

Cited By (1)

* 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

Also Published As

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

Similar Documents

Publication Publication Date Title
WO1993006548A1 (de) Verfahren zur adaption einer objektorientierten applikation
US5410703A (en) System for changing software during computer operation
DE10335989B4 (de) Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung
DE602004006253T2 (de) Vorrichtungen und verfahren zur wiederherstellung der synchronisation für objektorientierte softwareanwendungen in verwalteten laufzeitumgebungen
EP1385071A2 (de) Verfahren zum Austausch von Daten zwischen Steuerungen von Maschinen, insbesondere von Robotern
EP1034475A1 (de) Verfahren zum testen von systemkomponenten eines objektorientierten programms
DE102005010631A1 (de) Interoperabilitäts- und Schnittstellenerzeugungssystem
DE102009027627B3 (de) Simulation von Echtzeit-Software-Komponenten auf Basis der Logischen Ausführungszeit
EP1040414A1 (de) Verfahren zum umsetzen eines systemaufrufs
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
WO2000054188A2 (de) Verfahren zur automatischen wiedergewinnung von engineeringdaten aus anlagen
EP1570346A2 (de) System zur bereitstellung eines standard-frameworks für automatisierungsgeräte
EP0662226B1 (de) Verfahren zur bearbeitung eines anwenderprogramms auf einem parallelrechnersystem
EP0763920A2 (de) Verfahren zur Kodierung oder Dekodierung von Protokolldateneinheiten (PDU)
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
EP4055473B1 (de) Verfahren zum aktualisieren eines steuerprogramms eines automatisierungssystems mit datenmigration eines programmzustands des steuerprogramms
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
DE102021201212A1 (de) Verfahren zum Steuern einer Mehrzahl an Fahrfunktionen in einem automatisierten oder autonomen Fahrzeug
EP1263246B1 (de) Verfahren zum automatischen Programmieren sowie zugehörige Komponenten
DE19840246C2 (de) Datenverarbeitungssystem
DE19807191A1 (de) Programmablaufverfahren und Verfahren zur Erweiterung eines Programmkomponentensystems
EP0684574A2 (de) Verfahren und Service-Personalcomputer zum Administrieren und Warten von Kommunikationssystemen
EP1241544B1 (de) Kompatibles Erweitern einer Bausteinschnittstelle
DE4209541A1 (de) Verfahren zum Betreiben von Mikroprozessoren und Mikrocontrollern für Steuerungen und Regelungen
EP1231536A2 (de) Verfahren und System zur funktionsmässigen Erweiterung einer Telekommunikationsanlage

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IT LU MC NL SE

WWE Wipo information: entry into national phase

Ref document number: 1992913509

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 08211110

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 1992913509

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1992913509

Country of ref document: EP