DE19617381A1

DE19617381A1 - Objektumwandlungsverfahren von einem flachen Objektraum in einen Klassen - strukturierten Raum

Info

Publication number: DE19617381A1
Application number: DE19617381A
Authority: DE
Inventors: Toni Atkinson; Steve J Constant
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1995-09-13
Filing date: 1996-04-30
Publication date: 1997-03-20
Anticipated expiration: 2016-05-01
Also published as: FR2738649B1; DE19617381C2; JPH09179733A; FR2738649A1; US5732257A

Description

Die vorliegende Erfindung bezieht sich allgemein auf eine Objekt-Bewegung und -Umwandlung und insbesondere auf ein Sy stem zur Umwandlung klassenloser Objektdaten in auf Klassen basierende Objektdaten, um die Koexistenz von Anwendungspro grammen, die auf Modellen mit klassenlosen Objekten basie ren, mit Anwendungsprogrammen, die auf Modellen mit auf Klassen basierenden Objekten basieren, zu ermöglichen, und zur Verwendung bei der Bewegung von klassenlosen Objektdaten zu auf Klassen basierenden Objektdaten.

Datenbewegung (Datenwanderung) und Rückwärtskompatibilität sind Sachverhalte, die bei jeder Entwicklung einer Software anwendung angetroffen werden. Ein geeigneter Zusammenhang, um die Probleme zu veranschaulichen, die durch die Entwick lung von Software angetroffen werden, ist der Bereich der Netzwerk- und System-Verwaltung. Jedoch ist die vorliegende Erfindung in keiner Weise auf das Gebiet der Netzwerk- und System-Verwaltung begrenzt, wobei der folgende Hintergrund nur zur Veranschaulichung dienen soll.

Die Netzwerk- und System-Verwaltung wurde von der einfachen Netzwerk-Geräteverwaltung zu vollständig gemeinsamen Unter nehmensumgebungen zunehmend komplex, als sich die Systeme weiterentwickelten. Angesichts Budgetzwängen, dem Fehlen von Mitarbeitern und Fachkenntnisbegrenzungen arbeiten Netzwerk- und System-Verwalter heute, um schnell eine zunehmend kom plexe Technologie zu assimilieren. Die beinahe grenzenlose Wahl von Anschlußmöglichkeits-Optionen führte zu einer Kom plexität und Zersplitterung von Netzwerk- und System-Verwal tungsverantwortungen. Die integrierten Netzwerk- und Sy stem-Verwaltungslösungen, die auf den Markt gekommen sind, lieferten eine ökonomische Alternative zu der anhaltenden Konfusion, die durch die Wucherungen alleinstehender her stellerspezifischer Netzwerk- und System-Verwaltungslösungen bewirkt wird. Eine derartige integrierte Netzwerk- und Sy stem-Verwaltungslösung ist das HP OpenView, entwickelt und freigegeben von der Hewlett-Packard Company, das eine voll ständige Familie von Netzwerk- und System-Verwaltungs-Werk zeugen und -Diensten für lokale und weiträumige Multiven dor-Netzwerke für eine Integration auf einer Industrie-Stan dardplattform liefert.

Integrierte Netzwerk- und System-Verwaltungslösungen sind im allgemeinen als eine verteilte Aktivität wirksam, indem das Netzwerk- und System-Verwaltungsproblem in mehrere Komponen ten zerlegt wird, wobei jede Komponente eine unterschiedli che Funktion handhabt. Die Architektur HP OpenView weist beispielsweise getrennte Module auf, die eine Kommunika tionsinfrastruktur, eine graphische Benutzerschnittstelle, Verwaltungsanwendungen, Verwaltungsdienste und verwaltete Objekte einschließen.

Verwaltungsdienste sind die architektonische Komponente, die als eine Brücke zwischen der Netzwerkverwaltungs-Kommunika tionsinfrastruktur und dem verwalteten Objekt wirkt. Bei der Architektur HP OpenView sind Verwaltungsdienste durch meh rere Elemente realisiert: die Kommunikations-Protokolle und -Schnittstellen, die für Kommunikationen mit realen Be triebsmitteln notwendig sind, Ereignis-Weiterleitungs- und -Filterungs-Dienste, einen Verwaltungsdaten-Verwahrungsort mit einem strukturierten Abfragesprachenzugriff (SQL-Zu griff; SQL = structured query language) und Datendienste.

Netzwerksysteme müssen sich mit der Zeit entwickeln, um sich an neue Benutzerbedürfnisse anzupassen. Eine derartige Ent wicklung erfordert häufig bedeutende Änderungen der System plattform, die Änderungen der inneren Systemarchitektur, der Implementierung der Systeminterna und der Modellierung der Systemdaten einschließen. Wenn sich eine Plattform ent wickelt, sind Änderungen der Implementierung der Vielzahl von Anwendungen, die die Plattform verwenden und sich auf derselben für eine Integration von Daten, Diensten und eine Darstellung entwickeln, erforderlich. Häufig sind diese An wendungen Produkte unterschiedlicher und unabhängiger Ver käufer.

Eine Plattformentwicklung, die immer häufiger verwendet wird, schließt die Bewegung von einer Plattform für klassen lose Objekte zu einer Plattform für auf Klassen basierende Objekte ein. Bei einem System, das auf einem klassenlosen Objektraum und klassenlosen Datenmodell basiert, weist ein einzelnes Objekt eine dynamische Ansammlung von Feldern auf, und wird verwendet, um alle unterschiedlichen Perspektiven einer "Realwelt"-Entität zu modellieren. Beispielsweise kann ein einzelner Personalcomputer sowohl als eine Personalwork station als auch als ein Server für ein lokales Netz dienen. Folglich kann ein einzelnes Objekt in der Datenbank bei dem klassenlosen Objektmodell sowohl die Workstation-Perspektive als auch die Perspektive des Servers des lokalen Netzes dar stellen. Jede Perspektive wird durch eine unterschiedliche Anwendung verwaltet.

Jede Anwendung definiert ihre eigenen Felder und stellt Wer te für diese Felder ein, jedoch alle auf dem gleichen Ob jekt. Wenn eine andere Anwendung einen unterschiedlichen As pekt des gleichen Personalcomputers verwaltet, kann dieselbe ebenfalls Felder definieren und Werte auf denselben für die ses gleiche Objekt einstellen.

Zwei Nachteile der klassenlosen Objektstruktur sind jedoch deren Begrenzung auf dem Gebiet der Erweiterbarkeit und ihre Anpassung an Standards. In den letzten wenigen Jahren haben sich Netzwerksysteme technologisch weiterentwickelt, um große Netze zu ermöglichen, um viele Gigabyte von Daten, die über viele Kunden verteilt sind, zu verwalten. Viele Anwen dungen erfordern die Verwendung einer großen Datenbank, um zu ermöglichen, daß Benutzer auf Informationen, die von vie len Benutzern gemeinsam verwendet werden, zugreifen, diesel ben aktualisieren und bewahren. Das herkömmliche Verfahren, das eines ist, das weit verbreitet von kommerziell erhältli chen Datenbankverwaltungs-Anwendungsprogrammprodukten ver wendet wird, ist eine relationale Datenbank. Eine relatio nale Datenbank weist Tabellen von Zeilen und Spalten auf. Jede Tabelle definiert eine Relation zwischen den verschie denen Posten in jeder Zeile. Jede relationale Datenbank be sitzt eine Abfragesprache zum Speichern von Befehlen, um Da ten zu speichern und wiederzugewinnen. Die am häufigsten verwendete Abfragesprache zum Zugreifen auf relationale Da tenbank unter kommerziell erhältlichen Produkten ist die SQL (Structured Query Language).

Das Problem bei der Verwendung einer SQL bei einem klassen losen Modell ist die variierende Anzahl von Attributen, die einem Objekt zugeordnet sein kann. Es ist schwierig, ein Schema aufzubauen, das eine effiziente Suche auf einem dyna mischen Satz von Spalten ermöglicht. Kommerziell erhältliche relationale SQL-Datenbankprodukte sind am besten für eine feste Anzahl von Klassenattributen geeignet, um für jedes erzeugte Objekt einen Raum zuzuweisen. Der Raum wird sta tisch in einer Tabelle von Zeilen und Spalten zugewiesen, wodurch ein effizientes Indizierungsverfahren für eine schnelle Suche erleichtert ist. Folglich sind klassenlose Objekte mit SQL-Produkten ineffizient. Netzwerkverwaltungs systeme, die auf einem auf Klassen basierenden Objektraum modelliert sind, ermöglichen eine Kompatibilität mit kommer ziell erhältlichen SQL-Produkten.

Das auf Klassen basierende Objektmodell ist eine zentrale Komponente der Objekt-orientierten Architektur, die benötigt wird, um Marktanforderungen nach einer System-Erweiterbar keit und einer -Verteilbarkeit zu unterstützen. Das klassen lose Objektmodell war für die frühere Architektur ausrei chend, die eine kleinere Anzahl von Objekten in einer einfa cheren lokalen Konfiguration unterstützte. Für das System ist eine Objekt-orientierte Architektur erwünscht, um die neue Umgebung mit Tausenden von Objekten, auf die gleichzei tig von zahlreichen Konsolen in einer verteilten Umgebung zugegriffen wird, zu handhaben. Es wird ferner eine Kompati bilität mit dem Trend zu Objekt-orientierten, kommerziell erhältlichen Anwendungsprogrammen benötigt. Die Objekt orientierte Architektur erfordert ein auf Klassen basieren des Objektmodell als einen Ersatz für das klassenlose Ob jektmodell, das verwendet worden sein kann, um verwaltete Objekte in der ursprünglichen Architektur darzustellen.

Ein Problem, das bei der Bewegung von Daten und Anwendungen von einer Plattform für klassenlose Objekte zu einer Platt form für auf Klassen basierende Objekte angetroffen wird, tritt auf, wenn zwei oder mehr Anwendungen in eine Daten- Hersteller/Verbraucher-Beziehung treten. Bei dieser Bezie hung veröffentlicht eine Anwendung, der Hersteller, die klassenlose Objektdatenbank. Eine zweite Anwendung, der Ver braucher, liest diese Daten, wobei er nach spezifischen Fel dern sucht. Das Finden eines bestimmten Feldwerts, der auf einem Objekt eingestellt ist, zeigt der Verbraucheranwendung an, daß dieses Objekt von Interesse ist. Die Verbraucheran wendung kann weitere Daten zu dem Objekt hinzufügen oder kann einfach weitere Felder des Objekts lesen. Eine Herstel leranwendung kann beispielsweise der Network Node Manager (Netzwerkknotenverwalter) sein, dessen Funktion darin be steht, IP-Vorrichtungen auf dem Netzwerk zu entdecken und zu verwalten. Verbraucheranwendungen können dann Objekte, die durch den Network Mode Manager erzeugt werden, durchstöbern und nachfolgend den interessierenden Objekten zusätzliche Felder hinzufügen. Die Funktionalität der Verbraucheranwen dung wird durch Daten ausgelöst, die durch die Herstelleran wendung erzeugt werden, wobei eine starke Abhängigkeit des Verbrauchers von dem Hersteller erzeugt wird. Dieser Abhän gigkeit muß genügt werden, damit die Verbraucheranwendungen laufen. In der Vergangenheit konnten sich bewegende Herstel leranwendungen nicht bewegen, bis alle Verbraucheranwendun gen ebenfalls bereit waren, um sich zu bewegen.

Wenn sich eine Netzwerk- und System-Verwaltungsplattform von einem klassenlosen Objektraum in einen auf Klassen basieren den Objektraum entwickelt, müssen die Anwendungsentwickler die Anwendung aktualisieren, um zu ermöglichen, daß dieselbe auf der neuen Plattform läuft. Zusätzlich müssen die Daten, die der Anwendung zugeordnet sind, von dem klassenlosen Ob jektmodell in das auf Klassen basierende Objektmodell um gewandelt werden. Wie oben bemerkt wurde, können jedoch meh rere Anwendungen allgemeine Objekte gemeinsam verwenden. Wenn sich eine dieser Anwendungen bewegt, existiert unter solchen Umständen die Möglichkeit des Datenverlustes für die andere. Eine Möglichkeit, um keinen Datenverlust durch ir gendeine Anwendung sicherzustellen, besteht darin, daß sich alle Anwendungen mit gemeinsamen Objekten gleichzeitig be wegen. Dies ist jedoch bei der gegebenen Realität mehrerer Verkäufer, von denen jeder seine eigenen Fahrplanbeschrän kungen und Anwendungsfreigabepläne besitzt, schwierig. Folg lich wäre es erwünscht, ein Verfahren zu schaffen, um zu er möglichen, daß sich Anwendungsprogramme, die die gleichen Objekte verwenden, zu unterschiedlichen Zeiten bewegen; in anderen Worten heißt das, um zu ermöglichen, daß sich Her stelleranwendungen von einer klassenlosen zu einer auf Klas sen basierenden Plattform bewegen, ohne die Notwendigkeit der gleichzeitigen Bewegung aller ihrer Verbraucheranwendun gen.

Eine Lösung, um zu ermöglichen, daß sich Anwendungen bewe gen, wenn sie bereit dazu werden, besteht darin, zwei Sätze von Daten zu bewahren; nämlich die ursprünglichen klassenlo sen Objekte für die Verwendung mit der nicht-bewegten Anwen dung und die bewegten, auf Klassen basierenden Objekte zur Verwendung mit der bewegten Anwendung. Jedoch wird diese Raum-Ineffizienz, während sie in einem kleinen Netzwerksy stem, das weniger Objekte verwaltet, nur ein Ärgernis ist, in einem großen System mit Zehntausendenden von Objekten kritisch. Diese Speicherraumanforderungen und die Verwal tungskomplexität nehmen proportional zu, wenn sich die An zahl von Anwendungsprogrammen, die von den gleichen Objekten abhängen, in einem Netzwerkverwaltungssystem zu unterschied lichen Zeiten bewegt. Folglich wäre es erwünscht, ein System zu schaffen, um auf eine einzelne Version von Objektdaten, die für nicht-bewegte klassenlose Objektmodellanwendungen erforderlich sind, zuzugreifen, ungeachtet dessen, ob sich die Herstelleranwendung, die die Objekte erzeugte, zu einer Plattform für auf Klassen basierende Objekte bewegt hat, wo durch eine unnötige und lästige Objekt-Vervielfältigung und -Verwaltung vermieden wird.

Entsprechend den vorher genannten Problemen, die auf dem Ge biet der Softwareverwaltung angetroffen werden, welche die Bewegung (Wanderung) von Anwendungsprogrammen und die Unter stützung von Anwendungsprogrammen, die auf dem klassenlosen Objektdatenmodell basieren, und Anwendungsprogrammen, die auf dem auf Klassen basierenden Objektdatenmodell basieren, besteht ein Bedarf nach einem System für die Bewegung von Objekten von einem klassenlosen Objektraum zu einem auf Klassen basierenden Objektraum.

Es ist die Aufgabe der vorliegenden Erfindung, ein Objekt umwandlungssystem zu schaffen, das die gemeinsame Existenz von Daten und Anwendungen, die auf klassenlosen Objektmodel len basieren, und Daten und Anwendungen, die auf auf Klassen basierenden Objektmodellen basieren, ermöglicht, wobei fer ner ermöglicht ist, daß Anwendungsprogramme, die die glei chen Objekte verwenden, sich zu unterschiedlichen Zeiten be wegen, und wobei eine unnötige und schwerfällige Objekt-Ver vielfachung und -Verwaltung vermieden ist.

Diese Aufgabe wird durch ein Objektumwandlungssystem gemäß Anspruch 1 gelöst.

Gemäß einem Vorteil der vorliegenden Erfindung wird ein automatisches Objektumwandlungssystem geschaffen, um einen transparenten Zugriff auf Objekte in dem auf Klassen basie renden Objektraum durch Anwendungen, die auf klassenlosen Objekten basieren, zu schaffen.

Die Erfindung, die hierin beschrieben wird, löst das Problem des Erforderns einer gleichzeitigen Bewegung aller Anwendun gen, die allgemeine Daten gemeinsam verwenden, von einer Plattform für klassenlose Objektmodelle zu einer Plattform für auf Klassen basierende Objektmodelle. Klassenlose Objek te und auf Klassen basierende Objekte bestehen nebeneinan der, wobei durch nicht-bewegte, klassenlose Verbraucher-Ob jektmodellanwendungen, die sich auf Objekte stützen, die durch eine bewegte Herstelleranwendung erzeugt werden, tran sparent auf dieselben zugegriffen werden kann.

Das Objektumwandlungssystem, das hierin geschaffen wird, er möglicht die Koexistenz von Daten und Anwendungen, die auf einem klassenlosen Objektmodell basieren, und Daten und An wendungen, die auf einem auf Klassen basierenden Objektmo dell basieren. Ein Objekt, das auf dem klassenlosen Objekt modell basiert, weist zumindest eine klassenlose Objekt-ID (ID = Identität) und eine Mehrzahl von Feldern auf. Jedes Feld ist durch eine Felddefinition definiert und wird durch das Einstellen eines Werts für das Feld erzeugt. Ein Objekt, das auf dem auf Klassen basierenden Objektmodell basiert, weist einen Satz von Attributen und Verfahren, die auf einer definierten Klasse basieren, auf. Das bevorzugte Ausfüh rungsbeispiel, das hierin beschrieben ist, erfordert ferner eine auf Klassen basierende Objekt-ID. Das Objektumwand lungssystem weist einen Satz von Prozeduren auf, die auf ei nem Satz von vier Tabellen arbeiten, denselben aktualisieren und halten. Der Satz der vier Tabellen umfaßt (1) eine Feld orttabelle zur Verwendung bei der Bestimmung, ob ein Feld durch eine Anwendung für ein klassenloses Objektmodell oder eine Anwendung für ein auf Klassen basierendes Objektmodell erzeugt wurde; (2) eine Feldverfahrenstabelle zum Speichern von Abbildungen von Feldern für einen Zugriff sowohl auf ihre entsprechende Klasse als auch ihr Verfahren; (3) eine Identifikationstabelle zum Speichern der Abbildung zwischen einer klassenlosen Objekt-ID und ihrer entsprechenden auf Klassen basierenden Objekt-ID; und (4) eine Objektbeschrei bungstabelle zum Speichern der Abbildung zwischen einer klassenlosen Objekt-ID in jedem Feld, das der klassenlosen Objekt-ID zugeordnet ist.

Der Satz von Prozeduren umfaßt zumindest: (1) eine Felder zeugungseinrichtung zum Erzeugen eines Felds; (2) eine Feld wiedergewinnungseinrichtung zum Wiedergewinnen des Werts eines Felds; (3) eine Feldeinstellungseinrichtung zum Ein stellen des Werts eines Felds; (4) eine Objektfeld-Wieder gewinnungseinrichtung z;um Wiedergewinnen der Werte jedes Felds für eine gegebene klassenlose Objekt-ID; (5) eine Ver tretungsobjekt-Erzeugungseinrichtung zum Erzeugen einer klassenlosen Objekt-ID für ein neu erzeugtes, lokales, auf Klassen basierendes Objekt; (6) eine Vertretungsobjekt- Löscheinrichtung zum Beseitigen der klassenlosen Objekt-ID für ein gelöschtes oder bewegtes auf Klassen basierendes Objekt; und (7) eine Objektorteinrichtung zum Lokalisieren der klassenlosen Objekt-IDs für alle Objekte, die einen ge gebenen Wert für eine gegebene Feld_ID aufweisen.

Ferner ist ein Verfahren zum Bewegen von klassenlosen Objek ten in einen auf Klassen basierenden Objektraum in Verbin dung mit dem Objektumwandlungssystem geschaffen.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich nungen näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm eines Objektumwandlungssystems gemäß der vorliegenden Erfindung;

Fig. 2 ein typisches klassenloses Objektmodell;

Fig. 3 ein typisches auf Klassen basierendes Objektmodell;

Fig. 4A eine typische lokale, klassenlose Objektdatenbank vor der Bewegung einer Anwendung;

Fig. 4B die lokale klassenlose Objektdatenbank von Fig. 4A nach der Bewegung einer Anwendung, speziell der Be wegung der Anwendung2;

Fig. 5A mehrere klassenlose Objektbeispiele;

Fig. 5B mehrere auf Klassen basierende Objektbeispiele;

Fig. 6 eine beispielhafte Feld-Auf-Attribut-Abbildung;

Fig. 7 die Erzeugung eines neuen auf Klassen basierenden Objekts;

Fig. 8 die bevorzugte Implementierung der Feldorttabelle;

Fig. 9 das bevorzugte Ausführungsbeispiel der Feldverfah renstabelle;

Fig. 10 das bevorzugte Ausführungsbeispiel der Identifika tionstabelle;

Fig. 11 das bevorzugte Ausführungsbeispiel der Objektbe schreibungstabelle;

Fig. 12 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Felderzeugungseinrichtung;

Fig. 13 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Feldwiedergewinnungseinrichtung;

Fig. 14 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Feldeinstelleinrichtung;

Fig. 15 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Objektfeld-Wiedergewinnungseinrichtung;

Fig. 16 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Vertretungsobjekt-Erzeugungseinrichtung;

Fig. 17 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Vertretungsobjekt-Löscheinrichtung;

Fig. 18 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Objektorteinrichtung; und

Fig. 19 ein Flußdiagramm des bevorzugten Ausführungsbei spiels der Bewegungseinrichtung.

Ein System und ein Verfahren, die die vorher genannten Auf gaben gemäß einem gegenwärtig bevorzugten, exemplarischen Ausführungsbeispiel der Erfindung lösen, wird nachfolgend bezugnehmend auf die Fig. 1 bis 19 beschrieben.

Fig. 1 zeigt ein Objektumwandlungssystem 100 gemäß der vor liegenden Erfindung, das die Koexistenz von Daten und Anwen dungen, die eine Plattform 101 für ein klassenloses Objekt modell verwenden, und Daten und Anwendungen, die eine Platt form 105 für ein auf Klassen basierendes Objektmodell ver wenden, ermöglichen. Das typische System, in dem sich die Erfindung befindet, liefert zwei unterschiedliche Plattfor men - nämlich eine Plattform 101 für klassenlose Objekte und eine Plattform 105 für auf Klassen basierende Objekte. Jede Plattform liefert eine Schnittstelle zum Zugreifen auf lokale Daten, die durch ihre eigenen Plattform-residenten Anwendun gen erzeugt werden. Folglich liefert die Plattform 101 für klassenlose Objekte eine Plattformschnittstelle 102 für klassenlose Objekte und eine lokale Datenbank 114 für klas senlose Objekte. In gleicher Weise liefert die Plattform 105 für auf Klassen basierende Objekte eine Plattformschnitt stelle 106 für auf Klassen basierende Objekte und eine lo kale Datenbank 115 für auf Klassen basierende Objekte. Plattform-residente Anwendungen können lokal in ihren jewei ligen Plattformen auf die Datenbank zugreifen. Die vorlie gende Erfindung ermöglicht einen Zugriff auf den Inhalt der Datenbanken beider Plattformen durch die Anwendungen 103 der Plattform für klassenlose Objekte. Bei dem bevorzugten Aus führungsbeispiel ist die Plattformschnittstelle 102 für klassenlose Objekte unter Verwendung einer herstellerspezi fischen Anwendungsprogrammschnittstelle (API; API = Applica tions Programmatic Interface) implementiert, während die Plattformschnittstelle 106 für auf Klassen basierende Objek te unter Verwendung von Verfahrensaufrufen (für die gesamte Kommunikation und den Datenzugriff) implementiert ist.

Ein klassenloses Objekt 205, das auf dem klassenlosen Ob jektmodell 200 basiert, wie in Fig. 2 gezeigt ist, ist aus einem Satz von Feldwerten gebildet. Ein Feldwert 224 kann nur für Felder 220 eingestellt sein, die vorher über eine Felddefinition 225 definiert wurden. Bei dem klassenlosen Objektmodell 200 werden Objekte nicht durch eine Klassen spezifikation definiert. Statt dessen weist ein klassenloses Objekt 205, das durch seine klassenlose Objekt-ID 210 be zeichnet ist, eine willkürliche Sammlung von Feldern 220 auf. Folglich ist ein klassenloses Objekt 205 irgendetwas, für das einem oder mehreren Feldern 220 ein Wert gegeben wurde. Die Anzahl von Feldern, die ein beliebiges klassen loses Objekt 205 aufweisen kann, kann dynamisch sein und kann frei variieren. Die Struktur eines klassenlosen Objekts 205 ist nur durch die Anzahl und den Typ der Felder 220, die für dasselbe definiert wurden, begrenzt. Bei dem klassenlo sen Objektmodell 200 kann ein einzelnes klassenloses Objekt 205 viele unterschiedliche Charakteristika einer einzelnen Realwelt-Entität darstellen (beispielsweise kann ein klas senloses Objekt, das mit PC bezeichnet ist, die Workstation einer Person und ein Dateiserver sein).

Bei dem bevorzugten Ausführungsbeispiel weist jedes klas senlose Objekt 205 zumindest eine klassenlose Objekt-ID 210 und eine Mehrzahl von Feldern 220 auf. Eine eindeutige klas senlose Objekt-ID 210 wird in der lokalen Datenbank 114 für klassenlose Objekte zu der Zeit der Erzeugung des Objekts durch die Plattform 101 für klassenlose Objekte zugewiesen. Wie in Fig. 1 in Verbindung mit Fig. 2 gezeigt ist, erzeugen Anwendungen 103 des klassenlosen Objektmodells anwendungs spezifische Daten, indem eine Felddefinition 225 für ein Feld 220 erzeugt wird, und danach für das Feld 220 auf den interessierenden klassenlosen Objekten ein Feldwert 224 zu gewiesen wird. Das bevorzugte Ausführungsbeispiel einer Felddefinition 225 ist ferner in Fig. 2 gezeigt, die Feld_ID 221, Feld_Name 222 und Feld_Typ 223 einschließt. Feld_ID 221 wird durch das Objektumwandlungssystem 100 zum Verweisen auf ein Feld 220 verwendet.

Fig. 3 zeigt ein auf Klassen basierendes Objekt 305, das auf dem auf Klassen basierenden Objektmodell 300 basiert. Auf Klassen basierende Objekte 305 sind durch eine Klasse 315 definiert, die Definitionen für Attribute 320 und Verfahren 330 aufweist. Ein auf Klassen basierendes Objekt 305 ist ein Beispiel einer Klasse 315, deren Attribute 320 durch die Klassendefinition 305 statisch gemacht sind und einen festen Typ und eine feste Nummer aufweisen. Diese Eigenschaften des auf Klassen basierenden Objekts erleichtern die Vorhersag barkeit für eine Raumzuweisung und sind folglich mit kommer ziell erhältlichen SQL-Datenbankanwendungsprogrammen kompa tibel. Bei dem auf Klassen basierenden Objektmodell 300 stellt eine beliebige gegebene Klasse 315 oder ein auf Klas sen basierendes Objekt 305 nur einen einzelnen Aspekt einer Realweltentität dar.

Die Manipulation eines auf Klassen basierenden Objekts 305 wird durch die definierten Verfahren 330 desselben durchge führt. Wie Fachleuten bekannt ist, sind die Verfahren eines Objekts Prozeduren, die als ein Teil der Objektklasse 315 definiert sind, welche als die Objektschnittstelle zum Mani pulieren der Objektattribute 320 wirken. Die Verfahren, die durch ein auf Klassen basierendes Objekt 305 freigesetzt werden, ermöglichen einen gesteuerten Zugriff auf die Attri butdaten.

Die Manipulation von Daten in dem klassenlosen Objektmodell 200 wird unterschiedlich wie die in dem auf Klassen basie renden Objektmodell 300 gehandhabt. Bei dem klassenlosen Objektmodell 200 ist der Satz von Feldern 220, der für eine gegebene Anwendung 103 für ein klassenloses Objektmodell verfügbar ist, nicht nur auf seine eigenen definierten Fel der 220 begrenzt. Vielmehr kann eine Anwendung 103 für ein klassenloses Objektmodell Felder 220 verwenden, die durch eine beliebige Anwendung 103 für ein klassenloses Objektmo dell definiert sind. Folglich kann eine beliebige Anwendung 103 für ein klassenloses Objektmodell die Werte von Feldern 202 auf einem beliebigen klassenlosen Objekt 205 in der lo kalen Datenbank 114 für klassenlose Objekte unabhängig da von, welche Anwendung 103 für ein klassenloses Objektmodell die Daten erzeugt hat, manipulieren (d. h. einstellen oder löschen (set or unset)). Bei dem bevorzugten Ausführungsbei spiel verwendet die Plattform 101 für klassenlose Objekte herstellerspezifische API-Aufrufe als ihre Plattformschnitt stelle 102 für klassenlose Objekte, um ein klassenloses Ob jekt 205, das sich in der lokalen Datenbank 114 für klassen lose Objekte befindet, zu manipulieren (d. h. zu erzeugen, zu löschen, Daten einzustellen und wiederzugewinnen).

Bei dem auf Klassen basierenden Objektmodell 300 erfolgt ein Zugriff auf die Attributdaten 320 durch die Verfahren 330, die für die Klasse 315 definiert sind, von der ein gegebe nes, auf Klassen basierendes Objekt 305 ein Beispiel ist. Bei dem bevorzugten Ausführungsbeispiel ist die Plattform schnittstelle 106 für auf Klassen basierende Objekte mit ei ner Verfahrensschnittstelle implementiert, die Verfahren freisetzt, um auf Daten zuzugreifen. Die Attributdaten bei dem bevorzugten Ausführungsbeispiel sind privat. Die einzige Möglichkeit, auf ein Attribut 320 zuzugreifen, ist durch das Verfahren 330, das für dasselbe freigesetzt ist. Dies ermög licht, daß eine Anwendung 107 für ein auf Klassen basieren des Objektmodell nur die Attribute 320 der auf Klassen ba sierenden Objekte 305, für die dieselbe ein Verfahren 330 definiert hat, steuert und manipuliert.

Im allgemeinen bewegt sich eine Anwendung 103 für ein klas senloses Objektmodell von einer Plattform 101 für klassen lose Objekte zu einer Plattform 105 für auf Klassen basie rende Objekte und wird zu einer Anwendung 107 für ein auf Klassen basierendes Objektmodell. Wie vorher beschrieben wurde, kann eine beliebige Anwendung 103 für ein klassenlo ses Objektmodell die Werte der Felder 220 eines beliebigen klassenlosen Objekts 205 in der lokalen Datenbank 114 für klassenlose Objekte manipulieren, unabhängig davon, welche Anwendung 103 für ein klassenloses Objektmodell die Daten erzeugte. Ferner kann eine beliebige gegebene Anwendung 103 für ein klassenloses Objektmodell weitere Anwendungen 103 für ein klassenloses Objektmodell aufweisen, die von den klassenlosen Objekten 205 abhängen, die dieselbe erzeugte. Aufgrund der möglichen Zwischenabhängigkeiten der Anwendun gen 103 für ein klassenloses Objektmodell und ihrer entspre chenden klassenlosen Objekte 205 kann sich folglich eine ge gebene Anwendung für ein klassenloses Objektmodell nicht zu einer unterschiedlichen Plattform bewegen, bis alle mögli chen abhängigen (d. h. Verbraucher-) Anwendungen 103 für ein klassenloses Objektmodell ebenfalls bereit sind, um sich zu bewegen. Um diese Anforderung zu beseitigen, ist es sowohl erwünscht als auch notwendig, daß Anwendungen, die auf dem klassenlosen Objektmodell 200 basieren, und Anwendungen, die auf dem auf Klassen basierenden Objektmodell 300 basieren, nebeneinander existieren, wobei die vorliegende Erfindung dieses Problem löst.

Für die Bewegung von Daten/Anwendungen von dem klassenlosen Objektmodell 200 zu dem auf Klassen basierenden Objektmodell 300 muß eine Einmal-Datenabbildung verwendet werden. Da für ein klassenloses Objekt 205 keine Klassendefinition 315 exi stiert, ist eine Bestimmung dessen, welcher Satz von Feldern 220 eine einzelne Perspektive eines klassenlosen Objekts 205 definiert, ohne die Unterstützung der Anwendungsentwickler bei den folgenden Bestimmungen nicht möglich: 1) welche Ob jekte bewegt werden müssen, 2) welche neuen Attribute 320 äquivalent zu den alten Feldern 220 sind, und 3) die defi nierte Klasse 315, zu der die Anwendungsdaten bewegt werden müssen. Wenn sich eine Anwendung bewegt, muß der Entwickler dieser Anwendung folglich eine Einmal-Feld-Auf-Attribut-Ab bildungsdatei unterstützen, die spezifiziert, wie ein Zu griff auf jedes Attribut, das ein vorher definiertes Feld ersetzt, erhalten werden kann. Sobald eine Feld-Auf-Attri but-Abbildung der alten Felder 220 auf die neuen Klassen attribute 320 geliefert ist, kann das Verfahren des Bewegens der Felder 220 einer Anwendung 103 für ein klassenloses Ob jektmodell zu den Attributen 320 einer Anwendung 107 eines auf Klassen basierenden Objektmodells durch einen automati sierten Prozeß erreicht werden, beispielsweise einen Sta pelprozeß, der durch ein Computerprogramm implementiert ist. Die vorliegende Erfindung ermöglicht, daß sich Anwendungen 103 für ein klassenloses Objektmodell von einer Plattform 101 für klassenlose Objekte zu der Zeit zu einer Plattform 105 für auf Klassen basierende Objekte bewegt, zu der die Feld-Auf-Attribut-Abbildung von dem Entwickler einer her stellerspezifischen Anwendung 103 für ein klassenloses Ob jektmodell verfügbar wird, ohne auf die gleichzeitige Bewe gung jeder Verbraucheranwendung 103 für ein klassenloses Ob jektmodell warten zu müssen, die möglicherweise allgemeine Felder 220 gemeinsam verwendet. Folglich ermöglicht die vor liegende Erfindung die gleichzeitige Koexistenz von Anwen dungen 103 für ein klassenloses Objektmodell und Anwendungen 107 für ein auf Klassen basierendes Objektmodell, die Daten gemeinsam verwenden.

Die Fig. 4A und 4B zeigen die Wirkung des Bewegens einer An wendung 103 für ein klassenloses Objektmodell von der Platt form 101 für klassenlose Objekte zu der Plattform 105 für auf Klassen basierende Objekte auf der lokalen Datenbank 114 für klassenlose Objekte. Bei dieser Figur bewegt sich eine Anwendung2 420 von der Plattform 101 für klassenlose Objekte zu der Plattform 105 für auf Klassen basierende Objekte. Fig. 4A zeigt eine beispielhafte lokale Datenbank 401 für klassenlose Objekte vor der Bewegung der Anwendung2 420. Die beispielhafte lokale Datenbank für klassenlose Objekte 401 nach der Bewegung ist in Fig. 4B gezeigt. Während der Bewe gung der Anwendung wird die Anwendung 103 für ein klassenlo ses Objektmodell durch die Anwendung 107 für ein auf Klassen basierendes Objektmodell ersetzt, wobei die anwendungsspezi fischen Feldwerte in der lokalen Datenbank 114 für klassen lose Objekte durch die Anwendung2 420 gelöscht werden. Wenn sich immer weitere Anwendungen 103 für ein klassenloses Ob jektmodell bewegen, werden die anwendungsspezifischen Daten kontinuierlich aus der lokalen Datenbank 114 für klassenlose Objekte entfernt, bis die lokale Datenbank 114 für klassen lose Objekte schließlich nur die klassenlosen Objekt-IDs 210 für alle klassenlosen Objekte 205 enthält. Während sich die Anwendung2 420 von der beispielhaften lokalen Datenbank für klassenlose Objekte 401 in Fig. 4A zu der lokalen Datenbank 115 für auf Klassen basierende Objekte bewegt, löscht die selbe folglich ihre zugeordneten Felder F4 421 und F5 422 der klassenlosen Objekte Obj1 406, Obj2 407, Obj3 408 und Obj4 409 in der lokalen Datenbank 401 für klassenlose Objek te in Fig. 4B. Obwohl die Feldwerte von F4 421 und F5 422 nach der Bewegung gelöscht werden, verbleiben die Definitio nen für F4 421 und F5 422 noch, da nicht-bewegte Anwendungen noch von diesen Felddefinitionen abhängen können. Infolge der Bewegung werden F4 421 und F5 422 in der Feldverfahrens tabelle 111 dargestellt.

Fig. 5A zeigt einen beispielhaften Satz von Felddefinitionen 500 und mehreren beispielhaften klassenlosen Objekten. Wie oben bemerkt wurde, ist ein klassenloses Objekt 205 eine dy namische Ansammlung von Feldern 220. Wie in Fig. 5A gezeigt ist, wurden acht Felder f1 bis f8 (501 bis 508) durch ver schiedene Anwendungen jeweils durch Felddefinitionen 511 bis 518 definiert. Ein beliebiges Objekt kann einen Wert für ein beliebiges Feld annehmen. Wie in Fig. 5A gezeigt ist, defi niert Objekt1 551 Werte für Felder f1, f2 und f6 (501, 502 und 506). Objekt2 552 definiert Werte für f1 und f3 (501 und 503). Objekt3 553 definiert Werte für f2, f5 und f7 (502, 505 und 507). Objekt4 554 definiert Werte für ein einzelnes Feld f4 (504). Schließlich definiert Objekt5 555 Werte für Felder f7 und f8 (507 und 508). Wie aus Fig. 5A offensicht lich ist, verwenden einige klassenlose Objekte 205, die durch die Anwendungen 103 für ein klassenloses Objektmodell definiert sind, allgemeine Felder gemeinsam. Beispielsweise definieren sowohl das Objekt1 551 als auch das Objekt2 552 Werte für das Feld f1 504. In gleicher Weise definieren so wohl das Objekt1 551 als auch das Objekt3 553 Werte für das Feld f2 502.

Fig. 5B zeigt mehrere beispielhafte auf Klassen basierende Objekte. Wie aus Fig. 5B offensichtlich wird, ist die Struk tur einer Klasse durch ihre definierten Attribute bestimmt; jedoch existiert ein auf Klassen basierendes Objekt nicht, bis die Klasse instantiiert (instantiated) ist. Wie bei spielsweise in Fig. 5B gezeigt ist, ist eine Klasse A 561 durch ihre Attribute x, y und z (571, 572 und 573) defi niert. Die Klasse A 561 ist nur eine Schablone für ein auf Klassen basierendes Objekt 305, ist jedoch selbst kein auf Klassen basierendes Objekt 305. A1 581 und A2 582 wurden auf Klassen basierende Objekte 305 durch eine Instanzbildung (instantiating) der Klasse A 561. Bei dem auf Klassen basie renden Objekt A1 581 sind für die Attribute x, y bzw. z Wer te v1, v2 und v3 eingestellt. In gleicher Weise sind bei dem Objekt A2 582 für die Attribute x, y bzw. z Werte v4, v5 und v6 eingestellt. Wie ebenfalls in Fig. 5B gezeigt ist, ist ein Objekt B1 583 eine Instanz einer Klasse B 562, die Attribute q, r und s (574, 575 und 576) mit Werten v7, v8 bzw. v9 aufweist. In gleicher Weise ist ein Objekt C1 584 eine Instanz einer Klasse C 563, die Attribute m und n (577 und 578) mit Werten v10 bzw. v11 aufweist.

Gemäß der vorliegenden Erfindung soll der Entwickler der sich bewegenden Anwendung 103 für ein klassenloses Objektmo dell einen Satz von Abbildungen von den Klassenattributen 320 auf die klassenlosen Objektfelder 220 liefern, wo immer dieselben äquivalent sind. Beispielsweise zeigt Fig. 6 ein Beispiel einer Feld-Auf-Attribut-Abbildung der Klasse C 563 von Fig. 5B, wobei das klassenlose Objektfeld f5 505 von Fig. 5A auf das Attribut m 577 in der Klasse C 563 abbildet. In gleicher Weise bildet das Feld f3 503 auf das Attribut n 578 in der Klasse C 563 ab. In gleicher Weise bildet das Feld f6 506 auf das Attribut x 571 in der Klasse A 561 ab; das Feld f1 501 bildet auf das Attribut y 572 in der Klasse A 561 ab; und das Feld f2 502 bildet auf das Attribut z 573 in der Klasse A 561 ab.

Wie ebenfalls aus Fig. 6 offensichtlich ist, ist es möglich, daß keine Felder 220 existieren, die auf ein Attribut 320 abbilden. Eine Situation, bei der kein klassenloses Objekt feld 220 auf ein Attribut 320 in einer Klasse 315 abbildet, tritt auf, wenn das Attribut 320 neu ist. Aus den Fig. 5A und 5B ist folglich das Attribut q 574 in der Klasse B 562 neu, auf das keine Felder 220 abbilden; in gleicher sind das Attribut r 575 und das Attribut s 576 in der Klasse B 562 ebenfalls neu.

Felder, die in der Feld-Auf-Attribut-Abbildungsdatei nicht erscheinen, stellen Felder dar, die durch nicht-bewegte An wendungen definiert sind. In Fig. 6 erscheinen in der Datei nur Felder, die bewegt wurden, einschließlich f1 501, f2 502, f3 503, f5 505 und f6 506. Die Felder f4 504, f7 507 und f8 508 aus Fig. 5A erscheinen in der Abbildungsdatei in Fig. 6 nicht, da dieselben zu Anwendungen gehören, die noch nicht bewegt wurden. In anderen Worten heißt das, daß die klassenlosen Objekte Objekt4 545 und Objekts 555 noch nicht bewegt werden können, da keine Klasse 315 ihre Attribute 320 unterstützt.

Bei dem bevorzugten Ausführungsbeispiel werden die Feld- Auf-Attribut-Abbildungen durch die Anwendungsentwickler über eine Feldregistrierungsdatei geliefert. Die Registrierungs datei liefert das Objektumwandlungssystem 100 mit einer Ab bildung der klassenlosen Objektfelder 200 auf auf Klassen basierende Objektattribute 320. Sobald die Abbildungen er halten sind, findet die Bewegung durch die Instanzbildung der auf Klassen basierenden Objekte 305 mit den Werten der sich bewegenden Felder 220 statt.

Beispielsweise wird, bezugnehmend auf das flache Objekt1 551 mit den Feldern f1, f2 und f6 (501, 502 und 506), wie in Fig. 5A dargestellt ist, die Klasse A 561, wie in Fig. 5B definiert ist, und die Feld-Auf-Attribut-Abbildung, wie in Fig. 6 definiert ist, ein neues Objekt A3 701 instantiiert, wie in Fig. 7 dargestellt ist. Da das Feld f1 501 auf das Attribut y 572 der Klasse A 561 abbildet, das Feld f2 502 auf das Attribut z 572 der Klasse A 561 abbildet, und das Feld f6 506 auf das Attribut x 571 der Klasse A 561 abbil det, werden die Daten durch eine Instanzbildung des Objekts A3 701 und über die Objektverfahren, die die Attribute y, z und x (572, 573 und 571) auf die Werte der Felder f1, f2 und f3 (501, 502 und 503) einstellen, bewegt. Symbolischer aus gedrückt heißt das:
Da f1 → Attribut y
f2 → Attribut z
f6 → Attribut x
ermöglicht die Instanzbildung des Objekts A3 701 eine Daten bewegung wie folgt:
Attribut x = Wert f6 = v3
Attribut y = Wert f1 = v1
Attribut z = Wert f2 = v2.

Wenn sich Anwendungen von dem klassenlosen Objektmodell 200 zu dem auf Klassen basierenden Objektmodell 300 bewegen, be wegt jede Anwendung 103 für ein klassenloses Objektmodell nur die Daten, die für dieselbe spezifisch sind, während al le anderen Daten auf dem klassenlosen Objekt 205 allein be lassen werden (da die übrigen Felder 220 zu anderen Anwen dungen 103 für ein klassenloses Objekt gehören). Während sich bewegende Anwendungen 103 für ein klassenloses Objekt modell ihre Datenfelder 202 von den klassenlosen Objekten 205 bewegen, löschen sie den Wert dieser Felder 220 der klassenlosen Objekte 205 in der lokalen Datenbank 114 für klassenlose Objekte. Die vorliegende Erfindung ermöglicht einen Zugriff auf die Felder 220, die bewegt wurden, durch die übrigen nicht-bewegten Anwendungen 103 für klassenlose Objektmodelle.

Gemäß der vorliegenden Erfindung und bezugnehmend auf Fig. 1 weist das Objektumwandlungssystem 100 einen Satz von vier Tabellen auf, der in Kombination mit einem Satz von Prozedu ren, die hierin nachfolgend beschrieben werden, einen Zu griff auf Daten sowohl in der lokalen Datenbank 114 für klassenlose Objekte als auch in der lokalen Datenbank 115 für auf Klassen basierende Objekte durch nicht-bewegte An wendungen 103 für klassenlose Objektmodelle ermöglicht. Der Satz von vier Tabellen weist folgende auf: (1) eine Feldort tabelle 110 zur Verwendung bei der Bestimmung, ob ein Feld 220 durch eine Anwendung 103 für klassenlose Objektmodelle oder eine Anwendung 107 für auf Klassen basierende Objekt modelle erzeugt wurde; (2) eine Feldverfahrenstabelle 111 zum Speichern von Abbildungen von Feldern 220 sowohl auf die entsprechende Klasse 315 als auch das Verfahren 330 dersel ben für einen Zugriff; (3) eine Identifikationstabelle 112 zum Speichern der Abbildung zwischen einer klassenlosen Ob jekt-ID 210 und der entsprechenden Klasse 315 und der auf Klassen basierenden Objekt-ID 310 derselben; und (4) eine Objektbeschreibungstabelle 113 zum Speichern der Abbildung zwischen einer klassenlosen Objekt-ID 210 auf jedes Feld 220, das dieser klassenlosen Objekt-ID 210 zugeordnet ist.

Die Feldorttabelle 110 enthält Informationen zum Bestimmen dessen, welcher Anwendungstyp ein bestimmtes Feld 220 defi niert; d. h. ob das Feld 220 durch eine nicht-bewegte Anwen dung oder eine bewegte Anwendung erzeugt wurde. Diese Infor mationen werden zum Bestimmen dessen, ob das Feld abgebildet oder nicht-abgebildet ist, verwendet. Wenn das Feld 220 durch eine nicht-bewegte Anwendung erzeugt wurde, ist es folglich nicht-abgebildet und befindet sich in der lokalen Datenbank 114 für klassenlose Objekte. Wenn das Feld 220 durch eine bewegte Anwendung erzeugt wurde, ist es abgebil det und befindet sich in der Datenbank 115 für auf Klassen basierende Objekte. Fig. 8 zeigt die bevorzugte Implementie rung der Feldorttabelle 110, die eine Nachschlagtabelle, die durch Feld_ID 221 indiziert ist, und eine Boolesche Variable Abgebildet_Typ 802 aufweist. Die Variable Abgebildet_Typ 802 ist auf WAHR gesetzt, wenn die Anwendung, die das Feld 220 erzeugt, auf das durch die Feld_ID 221 derselben verwiesen wird, zu der Plattform 105 für auf Klassen basierende Objek te bewegt wurde. Die Variable Abgebildet_Typ 802 ist auf FALSCH gesetzt, wenn die Anwendung, die das Feld 220 er zeugt, nicht bewegt wurde und sich auf der Plattform 101 für klassenlose Objekte befindet.

Die Feldverfahrenstabelle 111 enthält die Abbildungen von klassenlosen Objektfeldern 220 auf ihre entsprechenden Klas senattribute 320. Wie in Fig. 9 dargestellt ist, enthält die Feldverfahrenstabelle 111 bei dem bevorzugten Ausführungs beispiel die Abbildungen von den Feldern 220 sowohl auf die entsprechende Klasse 315 als auch das Verfahren 330 dersel ben für einen Zugriff. Die Feldverfahrenstabelle 111 enthält eine Abbildung von dem Feld 220 auf die Klasse 315 des auf Klassen basierenden Objekts 305, um den Objekttyp sicherzu stellen, um auf demselben ein Verfahren aufzurufen. Die Feldverfahrenstabelle 111 enthält ferner eine Abbildung von dem Feld 220 auf das Verfahren 330 desselben für einen Zu griff, da eine Abfrage auf dem Feld sich in einen Verfah rensaufruf auf diesem auf Klassen basierenden Objekt 305 um wandelt. Die vorliegende Erfindung arbeitet auf Privatattri buten, die einen Zugriff nur durch zugeordnete Verfahren er möglichen. Folglich bildet das Feld 220 auf ein Attribut ab, das auf den Feldwert gesetzt ist, wobei jedoch ein Zugriff auf das Attribut nur indirekt durch sein zugeordnetes Ver fahren verfügbar ist. Folglich enthält die Feldverfahrensta belle 111 bei dem bevorzugten Ausführungsbeispiel eine Ab bildung von einem Feld 220, auf das durch seine Feld_ID 221 verwiesen wird, auf die entsprechende Klasse 315 und das Verfahren 330 desselben, und nicht auf das entsprechende At tribut 320 desselben. Das bevorzugte Ausführungsbeispiel ist mit einer Nachschlagtabelle implementiert, die durch Feld_ID 221 und Verfahren_Typ 904 indiziert ist. Die Variable Ver fahren_Typ 904 ist ein aufgezählter Typ, der zumindest die Werte von ERHALTE und STELLE EIN aufweist (was bezeichnet, ob seine zugeordnete Verfahrensoperation das Erhalten oder Einstellen des Feld_Werts 224 einschließt). Die Klasse 315 und das Verfahren 330 für jede Feld_ID 221 und der Verfah ren_Typ 904 sind ebenfalls in der Feldverfahrenstabelle 111 enthalten.

Die Identifikationstabelle 112 speichert die Abbildung zwi schen einer klassenlosen Objekt-ID 210 und ihrer entspre chenden auf Klassen basierenden Objekt-ID 310 und der zuge ordneten Klasse 315. Die Identifikationstabelle 112 ist er forderlich, da neue Objektidentifizierer erzeugt werden, wenn ein klassenloses Objekt 205 zu der Plattform 105 für auf Klassen basierende Objekte bewegt wird. Da eine nicht bewegte Anwendung 103 für klassenlose Objektmodelle das klassenlose Objekt 205 (von dem ein oder mehrere Felder 220 bewegt worden sein können) durch dessen klassenlose Objekt- ID 210 identifiziert, ist die Abbildung auf die entsprechen de auf Klassen basierende Objekt-ID 310 für das Lokalisieren dieser Felder 220 in der Datenbank 115 für auf Klassen ba sierende Objekte kritisch. Das bevorzugte Ausführungsbei spiel ist in Fig. 10 gezeigt und mit einer Nachschlagtabelle implementiert, die durch die klassenlose Objekt-ID 210 indi ziert ist. Für jede klassenlose Objekt-ID 210 enthält die Identifikationstabelle 112 ihre entsprechende auf Klassen basierende Objekt-ID 310 und die zugeordnete Klasse 315. Ei ne Eins-Auf-Eins-Abbildung kann zwischen den klassenlosen Objekt-IDs 210 und den auf Klassen basierenden Objekt-IDs 310 in der Identifikationstabelle 112 nicht existieren, da jedes klassenlose Objekt Felder aufweisen kann, die auf Attribute abgebildet sind, die in unterschiedlichen Klassen enthalten sind.

Die Objektbeschreibungstabelle 113 enthält die Abbildung zwischen einer klassenlosen Objekt-ID 210 und jedem Feld 220, das dieser klassenlosen Objekt-ID 210 zugeordnet ist. Diese Tabelle ermöglicht Abfragen für klassenlose Objekte durch Anwendungen 103 für klassenlose Objektmodelle, welche eine gesamte klassenlose Objekt-ID 210 entschlüsseln, und ermöglicht die Bestimmung von allen Feldern 220 für ein be liebiges gegebenes klassenloses Objekt 205. Das bevorzugte Ausführungsbeispiel ist in Fig. 11 dargestellt und ist mit einer Nachschlagtabelle implementiert, die durch die klas senlose Objekt-ID 210 indiziert ist und für jeden Eintrag in der Tabelle einen Zeiger 1102 auf eine verknüpfte Liste von allen Feldern 220, die der klassenlosen Objekt-ID 210 zuge ordnet sind, aufweist.

Ferner arbeitet gemäß der vorliegenden Erfindung ein Satz von vier Prozeduren auf dem Satz von vier Tabellen und ak tualisiert und hält denselben, wodurch ein Zugriff auf Daten sowohl in der lokalen Datenbank 114 für klassenlose Objekte als auch in der lokalen Datenbank 115 für auf Klassen basie rende Objekte durch nicht-bewegte Anwendungen 103 für klas senlose Objektmodelle, die sich auf Daten aus einer Anwen dung 107 für auf Klassen basierende Objektmodelle stützen, möglich ist. Der Satz von Prozeduren weist zumindest Folgen de auf: (1) eine Felderzeugungseinrichtung 121 zum Erzeugen eines Feld 220; (2) eine Feldwiedergewinnungseinrichtung 122 zum Wiedergewinnen des Werts eines Felds 220, sowohl abge bildet als auch nicht-abgebildet; (3) eine Feldeinstellein richtung 123 zum Einstellen des Werts eines Felds 220; (4) eine Objektfeld-Wiedergewinnungseinrichtung 124 zum Wieder gewinnen der Werte jedes Felds 220 für eine gegebene klas senlose Objekt-ID 210; (5) eine Vertretungsobjekt-Erzeu gungseinrichtung 120 zum Erzeugen einer klassenlosen Ob jekt-ID 210 für ein neu erzeugtes lokales auf Klassen basie rendes Objekt 115; (6) eine Vertretungsobjekt-Löscheinrich tung 125 zum Beseitigen der klassenlosen Objekt-ID 210 für ein gelöschtes oder bewegtes, auf Klassen basierendes Objekt 305; und (7) eine Objektorteinrichtung 126 zum Lokalisieren der klassenlosen Objekt-IDs 210 für alle klassenlosen Objek te 114 und das auf Klassen basierende Objekt 115, das einen gegebenen Wert für ein gegebenes Feld 220 aufweist.

Die Felderzeugungseinrichtung 121 zum Erzeugen eines Felds 220 wird durch Anwendungen 107 für auf Klassen basierende Objektmodelle aufgerufen, um zu ermöglichen, daß die Attri bute 220, die dieselbe erzeugt, als Felder 220 für die nicht-bewegten Anwendungen 103 für klassenlose Objektmodelle sichtbar sind. Nur nicht-bewegte Anwendungen 103 für klas senlose Objektmodelle verwenden Feld_Definitionen 225, wobei sich die Schnittstelle zum Erzeugen von Feldern durch nicht-bewegte Anwendungen bei der vorliegenden Erfindung nicht ändert. Jedoch hängen die Anwendungen 103 für klassen lose Objektmodelle von Feld_Definitionen 225, das durch an dere Anwendungen erzeugt wird, ab, selbst nachdem diese an deren Anwendungen bewegt wurden. Daher müssen bewegte Anwen dungen ihre Felder derart darstellen, daß nicht-bewegte An wendungen auf dieselben zugreifen können. Wenn eine bewegte Anwendung ein neues auf Klassen basierendes Objekt 305 mit einem Attribut 320, auf das ein Feld 220 abgebildet wurde, erzeugt, muß dieselbe dieses neu erzeugte "Feld" für Anwen dungen 103 für klassenlose Objektmodelle sichtbar machen. Folglich liefert die Felderzeugungseinrichtung 121 Zugriffs informationen, die anzeigen, daß das neue Feld 220, auf das durch Feld_ID 221 desselben verwiesen wird, auf die Daten bank 115 für auf Klassen basierende Objekte abgebildet wur de, und die die Klasse 315, zu der dasselbe gehört, und das Zugriffsverfahren desselben anzeigen. Dies wird erreicht, indem ein Eintrag zu der Feldorttabelle 110 und zu der Feld verfahrenstabelle 111 hinzugefügt wird.

Fig. 12 zeigt das bevorzugte Ausführungsbeispiel der Feld erzeugungseinrichtung 121. Wie in Fig. 12 dargestellt ist, weist die Felderzeugungseinrichtung 121 eine Prozedur, Er zeuge_Feld 1201, auf, die als Eingabe eine Feld_ID 1202, ein Verfahren 1203, einen Verfahren_Typ 1204 und eine Klasse 1205 empfängt. In einem Schritt 1 1210 erzeugt die Erzeu ge_Feld-Prozedur 1201 einen neuen Eintrag in die Feldortta belle 110. Der Eintrag weist die eingegebene Feld_ID 1202 und einen Abgebildet_Typ 802 von WAHR auf, was anzeigt, daß das Feld abgebildet wurde. Zusätzlich muß ein Eintrag in der Feldverfahrenstabelle 111 durchgeführt werden. Der Eintrag in die Feldverfahrenstabelle 111 weist, wie im Schritt 2 1220 gezeigt ist, jeden getrennten Verfahren_Typ 1204 (bei spielsweise ERHALTE oder STELLE EIN) die Feld_ID 1202, die Klasse 1205, das Verfahren 1203 und den Verfahren_Typ 1204 auf. Die Feldverfahrenstabelle 111 enthält die tatsächlichen Feld-Auf-Attribut-Abbildungen, wodurch durch die Verfahren auf die Attribute zugegriffen wird.

Die Feldwiedergewinnungseinrichtung 122 zum Wiedergewinnen des Werts eines Felds 220 wird durch Anwendungen 103 für klassenlose Objektmodelle verwendet, um den Feld_Wert 224 eines Felds 220 wiederzugewinnen. Das Feld 220 kann zu der Plattform 105 für auf Klassen basierende Objekte bewegt wor den sein und wird folglich als ein Attribut 320 eines auf Klassen basierenden Objekts 305 für eine definierte Klasse 315 in der Datenbank 115 für auf Klassen basierende Objekte gehalten, wobei das Feld 200 alternativ nicht bewegt worden sein kann und sich folglich in der lokalen Datenbank 114 für klassenlose Objekte befindet.

Fig. 13 zeigt das bevorzugte Ausführungsbeispiel für die Feldwiedergewinnungseinrichtung 122. Wie in Fig. 13 darge stellt ist, weist die Feldwiedergewinnungseinrichtung 122 eine Prozedur, Erhalte_Feld_Wert 1301, auf, die als Eingabe eine klassenlose Objekt-ID 1302 und eine Feld_ID 1303 emp fängt. In einem Schritt 1 1310 führt die Feldwiedergewin nungseinrichtung 122 einen Nachschlag in der Feldorttabelle 110 durch, entschlüsselt die Feld_ID 1303 und gewinnt den Wert von Abgebildet_Typ 802 wieder (d. h. ob die Anwendung, die das Feld erzeugt hat, abgebildet wurde oder nicht). Wenn das Feld nicht abgebildet wurde, was durch einen Wert von FALSCH für Abgebildet_Typ 802 angezeigt wird, führt die Er halte_Feld_Wert-Prozedur 1301 einen Nachschlag in der loka len Datenbank 114 für klassenlose Objekte durch, um den Feld_Wert 1304 wiederzugewinnen und denselben zu der Anwen dung 103 für klassenlose Objektmodelle zurückzugeben. Wenn das Feld 220 abgebildet wurde, was durch einen Wert von WAHR für Abgebildet_Typ 802 angezeigt wird, führt die Erhal te_Feld_Wert-Prozedur 1301 einen Nachschlag in der Identi fikationstabelle 112 in einem Schritt 3 1330 durch, um die auf Klassen basierende Objekt-ID 1305, die zu der eingege benen klassenlosen Objekt-ID 1302 gehört, wiederzugewinnen. Die entsprechende auf Klassen basierende Objekt-ID 1305 ist zum Lokalisieren des richtigen auf Klassen basierenden Ob jekts in der Datenbank 115 für auf Klassen basierende Objek te notwendig. Als nächstes führt die Erhalte_Feld_Wert-Pro zedur 1301 einen Nachschlag in der Feldverfahrenstabelle 111 durch, wobei die Feld_ID 1303 und Verfahren_Typ 904 von ERHALTE entschlüsselt wird, um die Klasse 1306 und das Ver fahren 1307 zur Wiedergewinnung von Feld_Wert 1304 zu be stimmen. Feld_Wert 1304 wird in einem Schritt 5 1350 über einen Aufruf auf einer auf Klassen basierenden Objekt-ID 1305 mit einem Verfahren 1307 wiedergewonnen (d. h. das Ob jekt_ID.ERHALTE_Verfahren gibt Feld_Wert 1304 zurück). Der Feld_Wert 1304 wird dann zu der aufrufenden Anwendung 103 für klassenlose Objektmodelle zurückgegeben.

Die Feldeinstelleinrichtung 123 zum Einstellen des Werts ei nes Felds 220 wird durch Anwendungen 103 für klassenlose Ob jektmodelle zum Einstellen von Feld_Wert 224 eines Felds 220 abhängig davon, ob sich das Feld 200 in der lokalen Daten bank 114 für klassenlose Objekte befindet, oder ob das Feld zu der Plattform 105 für auf Klassen basierende Objekte be wegt wurde und folglich als ein Attribut 320 eines auf Klas sen basierenden Objekts 305 für eine definierte Klasse 315 in der Datenbank 115 für auf Klassen basierende Objekte ge halten ist, verwendet.

Fig. 14 zeigt das bevorzugte Ausführungsbeispiel der Feld einstelleinrichtung 123. Wie in Fig. 14 gezeigt ist, weist die Feldeinstelleinrichtung 123 eine Prozedur, Stelle_Feld_- Wert_Ein 1401 auf, die als Eingabe eine klassenlose Objekt- ID 1402, eine Feld_ID 1403 und einen Feld_Wert 1404 emp fängt. In einem Schritt 1 1410 führt die Stelle_Feld_Wert_- Ein-Prozedur 1401 einen Nachschlag in der Feldorttabelle 110 durch, wobei die Feld_ID 1403 entschlüsselt und der Wert von Abgebildet_Typ 802 wiedergewonnen wird (d. h., ob die Anwen dung, die das Feld erzeugt hat, abgebildet wurde oder nicht). Wenn das Feld nicht abgebildet wurde, wie durch ei nen Wert von FALSCH für Abgebildet_Typ 802 angezeigt ist, führt die Prozedur Stelle_Feld_Wert_Ein 1401 in einem Schritt 2 1420 einen Nachschlag und ein Einstellen in der lokalen Datenbank 114 für klassenlose Objekte durch, um Feld_Wert 1404 einzustellen. Wenn das Feld 220 abgebildet wurde, was durch einen Wert von WAHR für Abgebildet_Typ 802 angezeigt ist, führt die Prozedur Stelle_Feld_Wert_Ein in einem Schritt 3 1430 einen Nachschlag in der Identifika tionstabelle 112 durch, um die entsprechende auf Klassen ba sierende Objekt-ID 1405 für die eingegebene klassenlose Ob jekt-ID 1402 wiederzugewinnen. Die entsprechende auf Klassen basierende Objekt-ID 1405 ist zum Lokalisieren des richtigen Objekts in der Datenbank 115 für auf Klassen basierende Ob jekte erforderlich. Als nächstes führt die Stelle_Feld_- Wert_Ein-Prozedur 1401 in einem Schritt 4 1440 ein Nach schlagen in der Feldverfahrenstabelle 111 durch, wobei die Feld_ID 1403 und Verfahren_Typ 904 von EINSTELLEN entschlüs selt wird, um die Klasse 1406, auf die das Feld abgebildet wird, und das Verfahren 1407 zum Einstellen des Werts des Attributs des eingegebenen Feld_Werts 1404 zu bestimmen. Der Wert des Attributs, das der eingegebenen Feld_ID 1403 ent spricht, wird in einem Schritt 5 1450 über einen Aufruf auf der auf Klassen basierenden Objekt-ID 1405 mit dem Verfahren 1407 auf den eingegebenen Feld_Wert 1404 eingestellt. Nach dem Einstellen des Werts des Attributs auf den Feld_Wert 1404 springt die Prozedur Stelle_Feld_Wert_Ein 1401 zu der aufrufenden Anwendung 103 für klassenlose Objektmodelle zu rück.

Die Objektfeld-Wiedergewinnungseinrichtung 124 wird durch Anwendungen 103 für klassenlose Objektmodelle verwendet, um die Werte jedes Felds 220 für eine gegebene klassenlose Ob jekt-ID 210 wiederzugewinnen, abhängig davon, ob die Felder 220 zu der Plattform 105 für auf Klassen basierende Objekte bewegt wurden, oder ob sich das Feld 200 in der lokalen Da tenbank 114 für klassenlose Objekte befindet.

Fig. 15 zeigt das bevorzugte Ausführungsbeispiel der Objekt feld-Wiedergewinnungseinrichtung 124. Wie in Fig. 15 gezeigt ist, weist die Objektfeld-Wiedergewinnungseinrichtung 124 eine Prozedur, Erhalte_Feld_Werte 1501, auf, die als eine Eingabe eine klassenlose Objekt_ID 1502 empfängt, und die beim Abschluß die Feld_Werte 1503 für jedes der derselben zugeordneten Felder zurückgibt. In einem Schritt 1 1510 führt die Prozedur Erhalte_Feld_Werte 1501 einen Nachschlag in der Objektbeschreibungstabelle 113 durch, um den Zeiger 1551 auf eine verknüpfte Liste 1550 der Feld_IDs 221, die der eingegebenen klassenlosen Objekt-ID 1502 zugeordnet sind, zu erhalten. Wenn der Zeiger 1551 auf eine leere Liste zeigt, sind der klassenlosen Objekt-ID 1502 keine Felder zu geordnet, und die Prozedur Erhalte_Feld_Werte 1501 springt zu der aufrufenden Anwendung 103 für klassenlose Objektmo delle zurück. Wenn die verknüpfte Liste 1550 nicht leer ist, zeigt der Zeiger 1551 auf die erste Feld_ID 221 in der Li ste.

In einem Schritt 2 1520 ruft die Prozedur Erhalte_Feld_Werte 1501 die Erhalte_Feld_Wert-Prozedur 1301 mit der ersten Feld_ID 221 in der Liste 1550 auf, um den Feld_Wert 1503 derselben zu erhalten.

In einem Schritt 3 1530 inkrementiert die Prozedur Erhal te_Feld_Werte 1501 den Zeiger in der verknüpften Liste 1550, um die nächste Feld_ID 221 wiederzugewinnen, die der einge gebenen klassenlosen Objekt-ID 1502 zugeordnet ist. Wenn der Zeiger auf das Ende der Liste 1552 zeigt, wurden alle Fel der, die der klassenlosen Objekt-ID 1502 zugeordnet sind, wiedergewonnen, und die Prozedur Erhalte_Feld_Werte 1501 gibt alle wiedergewonnenen Feldwerte 1503 zu der aufrufenden Anwendung 103 für klassenlose Objektmodelle zurück. Wenn der Zeiger auf eine andere Feld_ID 221 zeigt, wiederholt die Prozedur Erhalte_Feld_Werte 1501 die Schritte 2 1520 und 3 1530.

Dieses Verfahren setzt sich fort, bis der Zeiger auf das Ende der Liste 1552 zeigt. Dann gibt die Prozedur Er halte_Feld_Werte 1501 alle wiedergewonnenen Feldwerte 1503 zu der aufrufenden Anwendung 103 für klassenlose Objektmo delle zurück.

Die Vertretungsobjekt-Erzeugungseinrichtung 120 wird durch Anwendungen 107 für auf Klassen basierende Objektmodelle 107 verwendet, um eine klassenlose Objekt-ID 210 zu erzeugen, um einen Zugriff auf ein neu erzeugtes, lokales, auf Klassen basierendes Objekt 115 durch Anwendungen 103 für klassenlose Objektmodelle zu ermöglichen. Fig. 16 zeigt das bevorzugte Ausführungsbeispiel der Vertretungsobjekt-Erzeugungseinrich tung 120. Das bevorzugte Ausführungsbeispiel weist eine Pro zedur auf, Erzeuge_Vertretungs_Objekt 1601, die als eine Eingabe eine auf Klassen basierende Objekt-ID 1602, die ent sprechende Klasse 1603, zu der dieselbe gehört, und eine Li ste von Feldern 1604 empfängt. In einem Schritt 1 1601 er zeugt die Erzeuge_Vertretungs_Objekt-Prozedur 1601 eine neue klassenlose Objekt-ID 1605 zur Verwendung durch Anwendungen 103 für klassenlose Objektmodelle. Als nächstes fügt die Prozedur Erzeuge_Vertretungs_Objekt 1601 in einem Schritt 2 1620 einen Eintrag in der Identifikationstabelle 112 hinzu, wobei der Eintrag die neu erzeugte klassenlose Objekt-ID 1605, die eingegebene auf Klassen basierende Objekt-ID 1602 und die eingegebene Klasse 1603 enthält. Die Objektbeschrei bungstabelle 113 wird in einem Schritt 3 1630 mit einem Ein trag aktualisiert, der die neu erzeugte klassenlose Objekt- ID 1605 und die eingegebene Liste von Feldern 1604 enthält. Die Prozedur Erzeuge_Vertretungs_Objekt 1601 springt dann zu der aufrufenden Anwendung 107 für auf Klassen basierende Ob jektmodelle zurück.

Die Vertretungsobjekt-Löscheinrichtung 125 wird durch Anwen dungen 107 für auf Klassen basierende Objektmodelle verwen det, um eine klassenlose Objekt-ID 210, die einem gelöschten auf Klassen basierenden Objekt 305 entspricht, zu entfernen. Fig. 17 zeigt das bevorzugte Ausführungsbeispiel der Vertre tungsobjekt-Löscheinrichtung 125. Das bevorzugte Ausfüh rungsbeispiel weist eine Prozedur auf, Lösche_Vertretungs_- Objekt 1701, die als eine Eingabe eine auf Klassen basieren de Objekt-ID 1702 empfängt. Die Prozedur Lösche_Vertre tungs_Objekt 1701 entfernt in einem Schritt 1 1710 alle Ein träge in der Identifikationstabelle 112, in denen die ein gegebene auf Klassen basierende Objekt-ID 1702 erscheint. In gleicher Weise entfernt die Prozedur Lösche_Vertretungs_Ob jekt 1701 in einem Schritt 2 1720 alle Einträge in der Ob jektbeschreibungstabelle 113, in denen die eingegebene auf Klassen basierende Objekt-ID 1702 erscheint. Die Prozedur Lösche-Vertretungs_Objekt 1701 springt dann zu der aufru fenden Anwendung 107 für auf Klassen basierende Objektmodel le zurück.

Die Objektorteinrichtung 126 wird durch Anwendungen 103 für klassenlose Objektmodelle zum Lokalisieren der klassenlosen Objekt-IDs 210 für alle klassenlosen Objekte 114, die für ein gegebenes Feld 220 einen gegebenen Wert aufweisen, ver wendet. Das bevorzugte Ausführungsbeispiel, das in Fig. 18 gezeigt ist, ist mit einer Prozedur, Lokalisiere_Objekt 1801, implementiert, die als eine Eingabe eine Feld_ID 1802 und einen Feldwert 1803 empfängt.

Wie in Fig. 18 gezeigt ist, führt die Lokalisiere_Objekt- Prozedur 1801 in einem Schritt 1 1810 einen Nachschlag in der Feldorttabelle 110 durch, um zu bestimmen, ob das Feld, auf das durch die eingegebene Feld_ID 1802 verwiesen wird, auf ein Attribut 320 eines beliebigen der auf Klassen basie renden Objekte 305, die in der Datenbank 115 für auf Klassen basierende Objekte enthalten sind, abgebildet wurde.

Wenn das Feld, auf das durch die Feld_ID 1802 verwiesen wird, nicht auf ein Attribut 320 abgebildet wurde, führt die Prozedur Lokalisiere_Objekt 1801 in einem Schritt 2 1820 einen Nachschlag in der Datenbank 114 für klassenlose Ob jekte auf jedem klassenlosen Objekt 205 durch. Die Prozedur Lokalisiere_Objekt 1801 gewinnt die klassenlose Objekt-ID 210 für jedes klassenlose Objekt 205, das einen Feldwert 224 aufweist, der gleich dem eingegebenen Feldwert 1803 ist, wieder. Eine Liste der klassenlosen Objekt-IDs 1804 wird zu der aufruf enden Anwendung 103 für klassenlose Objektmodelle zurückgegeben.

Wenn das Feld, auf das durch die Feld_ID 1802 verwiesen wird, auf ein Attribut 320 abgebildet wurde, führt die Pro zedur Lokalisiere_Objekt 1801 in einem Schritt 3 1830 einen Nachschlag in der Feldverfahrenstabelle 111 durch, um die Klasse 315 wiederzugewinnen, zu der das Attribut 320 gehört, zusammen mit dem Verfahren 330 zum Lesen des Attributs, auf das das Feld 220 abgebildet ist.

In einem Schritt 4 1840 führt die Prozedur Lokalisiere_Ob jekt 1801 einen Nachschlag in der Identifikationstabelle 112 durch, um die auf Klassen basierende Objekt-ID 310 jedes auf Klassen basierenden Objekts 305 in der Datenbank 115 für Klassen basierende Objekte, das zu der Klasse 315 gehört, die das Attribut 320 aufweist, auf das das Feld 220 abgebil det ist, wiederzugewinnen.

Für jede der auf Klassen basierenden Objekt-IDs 310, die im Schritt 4 1840 wiedergewonnen werden, gewinnt die Prozedur Lokalisiere_Objekt 1801 in einem Schritt 5 1850 den Wert des Attributs 320 wieder, auf den das Feld 220 abgebildet ist, um zu bestimmen, ob der Wert des Attributs gleich dem einge gebenen Feldwert 1803 ist.

In einem Schritt 6 1860 führt die Prozedur Lokalisiere_Ob jekt 1801 einen Nachschlag in der Identifikationstabelle 112 durch, um die klassenlose Objekt_ID 210 für jedes auf Klas sen basierende Objekt 305, das einen Attributwert aufweist, der gleich dem eingegebenen Feldwert 1803 ist, wiederzuge winnen.

Schließlich werden in dem Fall, in dem das Feld abgebildet ist, alle klassenlosen Objekt-IDs 210, die in den Schritten 3 bis 6 lokalisiert werden, zu der aufrufenden Anwendung 103 für klassenlose Objektmodelle zurückgegeben.

Die obige Beschreibung zeigt detailliert die Koexistenz von Daten und Anwendungen, die sowohl auf der Plattform 101 für klassenlose Objektmodelle als auch der Plattform 105 für auf Klassen basierende Objektmodelle basieren. Die Notwendigkeit der vorliegenden Erfindung wird kritisch, nachdem zumindest eine Anwendung 103 für klassenlose Datenmodelle zu der Plattform 105 für auf Daten basierende Datenmodelle bewegt wurde. Um die Bewegung zu erreichen muß die Anwendung durch den Anwendungsentwickler aktualisiert werden, um auf der Plattform 105 für auf Klassen basierende Objekte zu laufen, eine Feld-Auf-Attribut-Abbildungsdatei muß erzeugt werden, und die Daten, die von der sich bewegenden Anwendung beses sen werden, müssen aus dem klassenlosen Objektmodell 200 in das auf Klassen basierende Modell 300 umgewandelt werden. Gemäß der vorliegenden Erfindung muß das Objektumwandlungs verfahren auch die Feldorttabelle 110, die Feldverfahrens tabelle 111 und die Identifikationstabelle 112 aktualisie ren, um zu ermöglichen, daß das Objektumwandlungssystem 100 ordnungsgemäß läuft.

Eine Einrichtung des Erreichens des Bewegungsobjekt-Umwand lungsverfahrens ist eine Stapelverarbeitungseinrichtung. Das bevorzugte Ausführungsbeispiel der Stapelverarbeitungsein richtung ist mit einem Computerprogramm, Bewege_Daten 1901, das in Fig. 19 dargestellt ist, implementiert. Das Bewege_- Daten-Programm 1901 empfängt als Eingabe eine Feld-Auf-At tribut-Abbildungsdatei 1902, die durch den Anwendungsent wickler geliefert wird, sowie die klassenlosen Objekte 1903 von der Datenbank 114 für klassenlose Objekte. Das Programm Bewege_Daten 1901 verarbeitet jedes klassenlose Objekt 1903 einzeln.

In einem Schritt 1 1910 von Fig. 19 überprüft das Programm Bewege_Daten 1901 auf beliebige existierende, unverarbeitete klassenlose Objekte 1903. Wenn bereits alle klassenlosen Ob jekte 1903 verarbeitet wurden, oder keine klassenlosen Ob jekte existieren, wird das Programm Bewege_Daten 1901 be endet.

Wenn noch irgendwelche unverarbeiteten klassenlosen Objekte existieren, gewinnt das Programm Bewege_Daten 1901 ein ein zelnes klassenloses Objekt aus den eingegebenen klassenlosen Objekten 1903 in einem Schritt 2 wieder, und zeigt auf das erste Feld desselben, das verarbeitet werden soll.

In einem Schritt 3 1930 liest das Programm Bewege_Daten 1901 die eingegebene Feld-Auf-Attribut-Abbildungsdatei 1902, um zu bestimmen, ob das verarbeitete Feld eine Abbildung auf ein Attribut 320 einer Klasse 315 aufweist. Wenn eine Feld- Auf-Attribut-Abbildung in der Feld-Auf-Attribut-Abbildungs datei 1902 für das verarbeitete Feld existiert, erzeugt das Programm Bewege_Daten 1901 einen Eintrag in die Feldortta belle 110, der die Feld_ID 221 des Felds und Abgebildet_Typ 802, das einen Wert von WAHR aufweist, enthält. Wenn in der Feld-auf-Attribut-Abbildungsdatei 1902 keine Feld-Auf-Attri but-Abbildung für das verarbeitete Feld existiert, erzeugt das Programm Bewege_Daten 1901 einen Eintrag in die Feldort tabelle 110, der die Feld_ID 221 des Felds und Abgebildet_- Typ 802, das einen Wert von FALSCH aufweist, enthält, und springt zu einem Schritt 9.

Wenn keine Feld-Auf-Attribut-Abbildung in der Feld-Auf-At tribut-Abbildungsdatei 1902 existiert, springt das Programm Bewege_Daten 1901 zu einem Schritt 4 1940, um die Feldver fahrenstabelle 111 mit einem Eintrag zu aktualisieren, der die Feld_ID 221, die dem verarbeiteten Feld entspricht, das Verfahren 330 zum Zugreifen auf das Attribut 320, auf das das verarbeitete Feld abgebildet ist, die Klasse, zu der das Attribut 330 gehört, und Verfahren_Typ 904 von ERHALTEN auf weist. Die Tabellen müssen aktualisiert werden, um zu ermög lichen, daß nicht-bewegte Anwendungen das Objektumwandlungs system 100 verwenden, um auf die bewegten Daten zuzugreifen.

In einem Schritt 5 1950 bestimmt das Programm Bewege_Daten 1901, ob bereits ein auf Klassen basierendes Objekt erzeugt wurde, das dem verarbeiteten Objekt entspricht, und das zu der Klasse gehört, die das Attribut aufweist, auf dem das verarbeitete Feld abgebildet werden soll. Wenn noch kein derartiges auf Klassen basierendes Objekt erzeugt wurde, wird eine neue auf Klassen basierende Objekt-ID 310 in einem Schritt 6 1960 erzeugt.

Die Identifikationstabelle 112 wird in einem Schritt 7 1970 aktualisiert. Das Programm Bewege_Daten 1901 erzeugt einen Eintrag in die Identifikationstabelle 112, der den Identifi zierer des klassenlosen Objekts des einzelnen verarbeiteten Objekts, zu dem das verarbeitete Feld gehört, den auf Klas sen basierenden Objektidentifizierer 310 des auf Klassen ba sierenden Objekts 305, das mit dem Wert des verarbeiteten Felds instantiiert wurde, und die Klasse 315, zu der das in stantiierte, auf Klassen basierende Objekt 305 gehört, auf weist.

In einem Schritt 8 1980 wird das neu erzeugte, auf Klassen basierende Objekt 305 oder das bereits erzeugte, auf Klassen basierende Objekt 305 durch das Einstellen des Werts des At tributs 320, auf den das verarbeitete Feld abgebildet wird, auf den Wert des verarbeiteten Felds instantiiert. Ferner wird in dem Schritt 8 1980 des Wert des verarbeiteten Felds in der Datenbank 114 für klassenlose Objekte gelöscht.

Ein Schritt 9 1990 wird nach der Instanzbildung (instan tiating) eines auf Klassen basierenden Objekts 305 durch das Einstellen des Werts eines seiner Attribute auf den Wert des verarbeiteten Felds in dem Schritt 8 1980 oder nach dem Be stimmen in dem Schritt 3 1930, daß keine Feld-Auf-Attribut- Abbildung für das verarbeitete Feld existiert, erreicht. In dem Schritt 9 1990 bestimmt das Programm Bewege_Daten 1901, ob irgendwelche verbleibenden, unverarbeiteten Felder für das verarbeitete klassenlose Objekt 1903 verbleiben. Wenn für dieses verarbeitete klassenlose Objekt 1903 unverarbei tete Felder existieren, wird das nächste verbleibende, un verarbeitete Feld in einem Schritt 10 1991 wiedergewonnen. Die Schritte 3 bis 10 werden wiederholt, bis keine verblei benden unverarbeiteten Felder existieren.

Wenn in dem Schritt 9 1990 keine verbleibenden unverarbei teten Felder existieren, wiederholt das Programm Bewege_Da ten 1901 die Schritte 1 bis 10, bis keine verbleibenden un verarbeiteten Objekte 19 03 existieren, wobei zu dieser Zeit das Programm Bewege_Daten 1901 endet und alle klassenlosen Objekte 1903 bewegt wurden.

Basierend auf der vorhergehenden detaillierten Beschreibung liefert die vorliegende Erfindung ein Verfahren und ein Sy stem zum Bewegen von Objekten aus einem klassenlosen Objekt modell zu einem auf Klassen basierenden Objektmodell, wäh rend die Koexistenz von gleichzeitig laufenden Anwendungen, die entweder den klassenlosen Objektraum oder den auf Klas sen basierenden Objektraum benötigen, ermöglicht ist.

Claims

1. Objektumwandlungssystem (100) zum Ermöglichen der Ko existenz von Daten und Anwendungen, die auf einem klas senlosen Objektmodell (200) basieren, und Daten und An wendungen, die auf einem auf Klassen basierenden Ob jektmodell (300) basieren, wobei ein klassenloses Ob jekt (205), das auf dem klassenlosen Objektmodell (200) basiert, zumindest einen klassenlosen Objektidentifi zierer (210) und eine Mehrzahl von Feldern (220) mit Feldwerten (224) aufweist, und wobei ein auf Klassen basierendes Objekt (305), das auf dem auf Klassen ba sierenden Objektmodell (300) basiert, einen auf Klassen basierenden Objektidentifizierer (310), eine Mehrzahl von Attributen (320) und eine Mehrzahl von Verfahren (330) zum Zugreifen auf die Attribute (320) gemäß einer definierten Klasse (315) aufweist, wobei das Objektum wandlungssystem (100) folgende Merkmale aufweist:
eine Feldorttabelle (110) zum Speichern einer Abbil dungsbezeichnung, um anzuzeigen, ob ein Feld (220) ei nes klassenlosen Objekts (205) auf ein Attribut (320) eines auf Klassen basierenden Objekts (305) abgebildet wurde;
eine Feldverfahrenstabelle (101) zum Speichern von Ab bildungen von Feldern (220) auf sowohl deren entspre chende Klasse (315) als auch deren entsprechendes At tribut (320);
eine Identifikationstabelle (112) zum Speichern von Abbildungen zwischen einem klassenlosen Objektidenti fizierer (210) und seiner entsprechenden Klasse (315) und dem auf Klassen basierenden Objektidentifizierer (310);
eine Objektbeschreibungstabelle (113) zum Speichern von Abbildungen zwischen einem klassenlosen Objektidentifi zierer (220) auf jedes der Mehrzahl von Feldern (220), die dem klassenlosen Objektidentifizierer (210) zugeord net sind;
eine Mehrzahl von Prozeduren, die folgende einschlie ßen: eine Felderzeugungseinrichtung (121) zum Erzeugen eines Felds (220); eine Feldzugriffseinrichtung (122, 123) zum Wiedergewinnen oder Einstellen des Werts eines Felds (220); eine Objektfeld-Wiedergewinnungseinrich tung (124) zum Wiedergewinnen der Werte jedes Felds (220), das einem gegebenen klassenlosen Objektidentifi zierer (210) zugeordnet ist; eine Vertretungsobjekt-Er zeugungseinrichtung (120) zum Erzeugen eines klassenlo sen Objektidentifizierers (210) für ein neu erzeugtes, auf Klassen basierendes Objekt (115); eine Vertretungs objekt-Löscheinrichtung (125) zum Beseitigen des klas senlosen Objektidentifizierers (210) eines gelöschten auf Klassen basierenden Objekts (305); und eine Objekt orteinrichtung (126) zum Lokalisieren der klassenlosen Objektidentifizierer (210) für alle klassenlosen Objek te (114), die einen gegebenen Wert für ein gegebenes Feld (220) aufweisen; und
eine Bewegungseinrichtung zum Bewegen der klassenlosen Objekte (205), die auf dem klassenlosen Objektmodell (200) basieren, zu auf Klassen basierenden Objekten (305), die auf dem auf Klassen basierenden Objektmodell (300) basieren.

2. System gemäß Anspruch 1, bei dem die Feldorttabelle (110) eine Mehrzahl von Einträgen aufweist, wobei jeder Eintrag folgende Merkmale aufweist:
einen Feldidentifizierer (221), und
eine Bezeichnung (802), die anzeigt, ob das Feld (220), das dem Feldidentifizierer (221) zugeordnet ist, auf ein Attribut (320) einer Klasse (315) abgebildet wurde oder nicht.

3. System gemäß Anspruch 1 oder 2, bei dem die Feldverfah renstabelle (111) eine Mehrzahl von Einträgen aufweist, wobei jeder Eintrag folgende Merkmale aufweist:
einen Feldidentifizierer (221), und
ein Attribut (320), auf das ein Feld (220), auf das durch den Feldidentifizierer (221) verwiesen wird, ab gebildet ist.

4. System gemäß einem der Ansprüche 1 bis 3, bei dem die Identifikationstabelle (112) eine Mehrzahl von Einträ gen aufweist, wobei jeder Eintrag folgende Merkmale aufweist:
einen auf Klassen basierenden Objektidentifizierer (310) zum Verweisen auf ein auf Klassen basierendes Objekt (305);
eine Klasse (315), zu der das auf Klassen basierende Objekt (305) gehört; und
einen klassenlosen Objektidentifizierer (210) zum Ver weisen auf ein klassenloses Objekt (205), das ein Feld (220) aufweist, das auf ein Attribut (320) des auf Klassen basierenden Objekts (305) abbildet.

5. System gemäß einem der Ansprüche 1 bis 4, bei dem die Objektbeschreibungstabelle (113) eine Mehrzahl von Ein trägen aufweist, wobei jeder Eintrag folgende Merkmale aufweist:
einen klassenlosen Objektidentifizierer (210) zum Ver weisen auf ein klassenloses Objekt (205); und
eine Liste jedes Felds, das dem klassenlosen Objekt (205) zugeordnet ist.

6. System gemäß einem der Ansprüche 1 bis 5, bei dem die Felderzeugungseinrichtung (121) eine Verarbeitungsein richtung zum Durchführen folgender Schritte aufweist:
Empfangen als eine Eingabe eines Eingabefeldidentifi zierers (221) zum Verweisen auf ein Feld (220) und eines Eingabeattributs (320), auf das das Feld (220), auf das verwiesen wird, abgebildet wird;
Erzeugen eines neuen Eintrags in der Feldorttabelle (110) wobei der Eintrag den Eingabefeldidentifizierer (221) und eine Bezeichnung (802) aufweist, die anzeigt, daß das Feld (220), auf das verwiesen wird, durch eine Anwendung (107) erzeugt ist, die auf dem auf Klassen basierenden Objektmodell (300) basiert; und
Erzeugen eines neuen Eintrags in der Feldverfahrensta belle (101), wobei der Eintrag den Eingabefeldidenti fizierer (221) und das Eingabeattribut (320), auf den das Feld (220), auf das verwiesen wird, abgebildet wird.

7. System gemäß einem der Ansprüche 1 bis 6, bei dem die Feldzugriffseinrichtung (122, 123) eine Verarbeitungs einrichtung zum Durchführen folgender Schritte auf weist:
Empfangen als Eingabe eines Eingabeidentifizierers ei nes klassenlosen Objekts (210) und eines Eingabefeld identifizierers (221) zum Verweisen auf ein Feld (220), dessen Wert (224) wiedergewonnen werden soll;
Durchführen eines Nachschlags in der Feldorttabelle (110), um zu bestimmen, ob das Feld (220), auf das ver wiesen wird, abgebildet wurde; und
wenn das Feld, auf das verwiesen wurde, nicht abgebil det wurde,
Durchführen eines Nachschlags auf ein klassenloses Objekt (205), auf das durch den Eingabeidentifizierer des klassenlosen Objekts (210) verwiesen wird, um den Wert (224) des Felds (220), auf das verwiesen wurde, wiederzugewinnen oder einzustellen; und
wenn das Feld, auf das verwiesen wurde, abgebildet wur de,
Durchführen eines Nachschlags basierend auf dem Ein gabeidentifizierer (210) des klassenlosen Objekts, in der Identifikationstabelle (112), um einen entspre chenden auf Klassen basierenden Objektidentifizierer (310) für den Eingabeidentifizierer (210) des klas senlosen Objekts wiederzugewinnen;
Durchführen eines Nachschlags, basierend auf dem Ein gabefeldidentifizierer (221), in der Feldverfahrens tabelle (111), um eine entsprechende Klasse (315) und ein entsprechendes Attribut (320) zu bestimmen, auf die das Feld (220), auf das verwiesen wurde, abgebil det wird, und
Durchführen eines Nachschlags nach einem auf Klassen basierenden Objekt (305), auf das durch den entspre chenden auf Klassen basierenden Objektidentifizierer (310) verwiesen wird, wobei das auf Klassen basieren de Objekt (305), auf das verwiesen wurde, zu der ent sprechenden Klasse (315) gehört und das entsprechende Attribut (320) aufweist, um den Wert (224) des ent sprechenden Attributs (320), auf das das Feld (220), auf das verwiesen wurde, abgebildet wird, wiederzuge winnen oder einzustellen.

8. System gemäß einem der Ansprüche 1 bis 7, bei dem die Vertretungsobjekt-Erzeugungseinrichtung (120) eine Ver arbeitungseinrichtung zum Durchführen folgender Schrit te aufweist:
Empfangen als eine Eingabe eines Eingabeidentifizierers für auf Klassen basierende Objekte (310) zum Verweisen auf ein auf Klassen basierendes Objekt (305), einer Eingabeklasse (315), zu der das auf Klassen basierende Objekt (305), auf das verwiesen wird, gehört, und einer Liste jedes Felds (220), das dem auf Klassen basieren den Objekt (305), auf das verwiesen wird, zugeordnet ist;
Erzeugen eines neuen klassenlosen Objektidentifizierers (210) zur Verwendung durch Anwendungen, die auf dem klassenlosen Objektfeld (200) basieren;
Hinzufügen eines Eintrags in die Identifikationstabelle (112), wobei der Eintrag den neu erzeugten klassenlosen Objektidentifizierer (210), den Eingabeidentifizierer für auf Klassen basierende Objekte (310) und die Einga beklasse (315) aufweist; und
Hinzufügen eines Eintrags in die Objektbeschreibungsta belle (113), wobei der Eintrag den neu erzeugten klas senlosen Objektidentifizierer (210) und die Eingabeli ste von Feldern aufweist.

9. System gemäß einem der Ansprüche 1 bis 8, bei dem die Objektorteinrichtung (126) eine Verarbeitungseinrich tung zum Durchführen folgender Schritte aufweist:
Empfangen eines Eingabefeldidentifizierers (221) als eine Eingabe zum Verweisen auf ein Feld (220) und einen Eingabefeldwert;
Durchführen eines Nachschlags in der Feldorttabelle (111), um zu bestimmen, ob das Feld (220), auf das ver wiesen wurde, abgebildet wurde; und
wenn das Feld, auf das verwiesen wurde, nicht abgebil det wurde,
Durchsuchen einer Datenbank (114) für klassenlose Ob jekte, die eine Mehrzahl von klassenlosen Objekten aufweist, um jedes klassenlose Objekt (205) zu loka lisieren, das das Feld (220), auf das verwiesen wur de, besitzt;
Vergleichen des Werts (224) des Felds (220), auf das verwiesen wurde, des klassenlosen Objekts (205), das das Feld aufweist, mit dem Eingabefeldwert;
Wiedergewinnen und Zurückgeben des klassenlosen Ob jektidentifizierers (210), der auf das klassenlose Objekt (205) verweist, das das Feld besitzt, bei dem der Wert (224) des Felds (220), auf das verwiesen wurde, gleich dem Eingabefeldwert ist; und
wenn das Feld, auf das verwiesen wurde, abgebildet wur de,
Durchführen eines Nachschlags basierend auf dem Ein gabefeldidentifizierer (221) in der Feldverfahrensta belle (111), um eine entsprechende Klasse (315) und ein entsprechendes Attribut (320), auf die das Feld (220), auf das verwiesen wurde, abgebildet ist, zu bestimmen,
Durchführen eines Nachschlags basierend auf der ent sprechenden Klasse (315) in der Identifikationstabel le (112), um eine Klassenmitgliedliste wiederzugewin nen, die eine Mehrzahl von auf Klassen basierenden Objektidentifizierern (310) aufweist und auf jedes auf Klassen basierende Objekt verweist, das zu der entsprechenden Klasse (315) gehört, und
für jeden der Mehrzahl von auf Klassen basierenden Objektidentifizierern (310), die in der Klassenmit gliedliste enthalten sind, Durchführen eines Nach schlags nach dem entsprechenden auf Klassen basieren den Objekt (305) desselben, um den Wert des entspre chenden Attributs, auf den das Feld (220), auf das verwiesen wurde, abgebildet ist, wiederzugewinnen, Vergleichen des Werts des entsprechenden Attributs (320) mit dem Eingabefeldwert und Erzeugen einer Li ste für auf Klassen basierende Objektidentifizierer aller auf Klassen basierenden Objektidentifizierer (310), die einen entsprechenden Attributwert gleich dem Eingabefeldwert aufweisen, wobei das Feld (220), auf das verwiesen wurde, auf das Attribut (320) abge bildet wird; und
Durchführen eines Nachschlags in der Identifikations tabelle (112), um einen klassenlosen Objektidentifi zierer (310) für jeden auf Klassen basierenden Iden tifizierer (310), der in der Liste für auf Klassen basierende Identifizierer enthalten ist, wiederzuge winnen und zurückzugeben.

10. System gemäß einem der Ansprüche 1 bis 9, bei dem die Bewegungseinrichtung als eine Eingabe eine Eingabeab bildungsdatei, die eine Mehrzahl von Einträgen auf weist, empfängt, wobei jeder Eintrag einen Feldidenti fizierer (221) zum Verweisen auf ein Feld (220) und eine entsprechende Klasse (315) und ein Attribut (320), auf das das Feld (220) abgebildet ist, aufweist, und bei dem die Bewegungseinrichtung ferner als Eingabe eine Mehrzahl von klassenlosen Objekten, die von einer sich bewegenden Anwendung besessen werden, empfängt, wobei jedes der Mehrzahl von besessenen klassenlosen Objekten einen klassenlosen Objektidentifizierer und eine Mehrzahl von Feldern aufweist, welche Feldwerte aufweisen und auf die durch die Feldidentifizierer ver wiesen wird, wobei die Bewegungseinrichtung ein einzel nes klassenloses Objekt (205) aus der Mehrzahl von klassenlosen Eingabeobjekten durch Bezugnahme auf sei nen klassenlosen Objektidentifizierer (210) zu einer Zeit bearbeitet, und für jedes Feld (220), das von dem einzelnen klassenlosen Objekt (205) besessen wird, und dessen entsprechender Feldidentifizierer (221) in der Eingabeabbildungsdatei enthalten ist, Durchführen fol gender Schritte:
Hinzufügen eines Eintrags zu der Feldorttabelle (110), wobei der Feldorttabelleneintrag den Feldidentifizierer (221), der auf das besessene Feld (220) verweist, und eine Bezeichnung (802), die anzeigt, daß das Feld (220) abgebildet wurde, aufweist;
Hinzufügen eines Eintrags zu der Feldverfahrenstabelle (111), wobei der Feldverfahrenstabelleneintrag den Feldidentifizierer (221) zum Verweisen auf das besesse ne Feld (220), die Klasse (315) und das Attribut (320), das in der Eingabeabbildungsdatei enthalten ist und auf das das besessene Feld (220) abgebildet ist, aufweist;
Erzeugen eines neuen auf Klassen basierenden Objekt identifizierers (310);
Hinzufügen eines Eintrags zu der Identifikationstabelle (112), wobei der Identifikationstabelleneintrag den klassenlosen Objektidentifizierer (210), der auf das einzelne klassenlose Objekt (205) verweist, die Klasse (315), die in der Eingabeabbildungsdatei enthalten ist, auf die das besessene Feld (220) abgebildet ist, und den neu erzeugten, auf Klassen basierenden Objektiden tifizierer (310) aufweist;
Instantiieren eines neuen auf Klassen basierenden Ob jekts (305), das dem neu erzeugten auf Klassen basie renden Objektidentifizierer (310) entspricht, durch das Einstellen des Attributs (320), auf das das besessene Feld (220) abgebildet ist, auf den Wert (224) des be sessenen Feldes (220); und
Löschen des Werts (224) des besessenen Felds (220) des einzelnen klassenlosen Objekts (205).