Die Erfindung betrifft ein Verfahren zur Unterstützung des Erzeugens eines ersten Objektes in einer Objekt Umgebung, in der erste und weitere Objekte über CORBA-Mechanismen interagieren, noch dem Oberbegriff von Anspruch 1, Verfahren zum Erzeugen und zum Löschen eines ersten Objektes nach dem Oberbegriff von Anspruch 6 bzw. 7, ein Programm-Modul mit einer CORBA-Schnittstelle zur Interaktion als CORBA-Objekt über CORBA-Mechanismen nach dem Oberbegriff von Anspruch 8 und eine Rechnereinheit nach dem Oberbegriff von Anspruch 11.

Für die softwaremässige Realisierung von verteilten Computersystemen wird zunehmend die objektorientierte Modellierung als Architekturprinzip verwendet. Eine solche Soffware - Architektur eines Computersystems ist die CORBA - Architektur (CORBA = Common Object Request Broker Architecture), die eine bedeutende Komponente der von der Object Management Group (OMG) specifizierten OSA-Architektur (OSA = Object Service Architecture) ist.

Die Erfindung geht nun von dem Verfahren aus, wie Objekte (Managed Objects) normaleweise in einem Computersystem nach der CORBA - Architektur erzeugt und gelöscht werden. Dies ist beispielsweise in

Common Object Request Broker: Archtitecture and Specification r2.0, Object Management Group, Framingham, Massachusetts, 1995, beschrieben.

Das Erzeugen und das Löschen von Objekten wird von speziellen Objekten durchgefüht, den Generierungs-Objekten (factories). Die ausschliessliche Funktion eines solchen Generierungs-Objektes ist es, dieses Löschen und Erzeugen von Objekten für bestimmte Arten von Objekten durchzuführen. Zur Definition solcher Generierungs-Objekte wird ein spezieller Dienst, der LifeCycle Dienst, verwendet. Eine allgemeines Generierungs-Objekt steht zur Verfügung. Von diesem ausgehend können auch spezielle Generierungs-Objekte für jede Art von Objekten, z.b. bestimmte Klassen von Objekten (object class) definiert werden, die die Eingabe spezieller Erzeugungsparameter erlauben.

Um nun ein spezielles Objekt zu Erzeugen oder zu Löschen, muss zuerst das für die Erzeugung und das Löschen dieses speziellen Objekts zuständige Generierungsobjekt gefunden werden. Hierzu wird eine Suchnachricht an einen speziellen Dienst, den FactorieFinder Dienst, der ein Teil des LifeCycle Dienstes ist, gesendet und die Suchkriterien (Typ, Ort,..) für diese Suche angegeben. Ist das zuständige Generierungsobjekt gefunden, so wird eine Anforderungsnachricht (invocation) and das Generierungsobjekt gesendet, das daraufhin ein Objekt entsprechend der in der Anforderungsnachricht angegebenen Parameter erzeugt oder löscht.

Der Nachteil dieser Vorgehensweise besteht darin, dass das Aufinden eines geeigneten Generierungsobjektes in der Regel sehr aufwendig ist und eine weiteren Kommunikationsbelastung des Computersystems verursacht.

Der Erfindung liegt nun die Aufgabe zugrunde, die Systembelastung in einem auf einer CORBA - Architektur beruhenden Computersystem zu reduzieren.

Diese Aufgabe wird gelöst durch Verfahren nach der Lehre von Anspruch 1, 6 und7, durch ein Programm-Modul nach der Lehre von Anspruch 8 und durch eine Rechnereinheit nach der Lehre von Anspruch 11.

Der Erfindung liegt hierbei der Gedanke zugrunde, dass Objekte in einer CORBA- Umgebung für das Erzeugen oder das Löschen der ihnen unmittelbar nachfolgenden Objekte (descendant objects) im Abhängigkeitsbaum (containment tree) zuständig sind. Sie übernehmen somit zusätzlich die Rolle von Generierungs-Objekten für ihre Kind-Objekte (child objects).

Durch diese von der CORBA-Philosophie abweichende Vorgehensweise ergeben sich weitere Vorteile:

Die Anzahl der Objekte in dem Computersystem wird reduziert. Dadurch reduziert sich auch die Systembelastung und die Anzahl der Referenzen.

Weiter entfällt der Zugriff auf den FaktoryFinder Dienst und die Prozessorbelastung durch den Suchvorgang. Durch ihre logische Einordnung im Abhänigkeitsbaum sind leicht zu finden

Weiter wird die System-Konsistenz verbessert. Ein nachfolgendes Objekt wird nur erzeugt, wenn sein Vorgänger im Abhängigkeitsbaum vorhanden ist.

Weitere Vorteile ergeben sich bei hybriden System im Bereich des Netzwerkmanagement, bei denen ein Netzwerkmanagement-System basierend auf CORBA realisiert wird. Zum einen können hier für die Erzeugungs- und Löschfunktionen CMISE Dienste verwendet werden, die aus einem einfachen Interface vererbt werden, in dem alle CMISE Dienste enthalten sind.

Im Folgenden wird die Erfindung anhand dreier Ausführungsbeispiele unter Zuhilfenahme beiliegender Zeichnungen beispielhaft erläutert:

Fig. 1a zeigt eine Blockschaltbild eines Computersystems für ein erstes Ausführungsbeispiel.
Fig. 1b zeigt eine funktionelle Darstellung der Software Struktur des Computersystems nach Fig.1.
Fig. 2 zeigt eine symbolische Darstellung von Abhängigkeitsverhältnissen zwischen Objekten.
Fig. 3 zeigt einen Ausschnitt aus einer Interface-Beschreibung in einer Darstellung in einer symbolischen Beschreibungsphase.
Fig. 4a zeigt eine funktionelle Darstellung der Software Struktur eines Computersystems für ein zweites Ausführungsbeispiel.
Fig. 4b zeigt eine funktionelle Darstellung der Software Struktur eines Computersystems für ein drittes Ausführungsbeispiel.


In einem ersten Ausführungsbeispiel wird die Durchführung der erfindungsgemässen Verfahren in einem Computersystem beschrieben, das aus einem oder aus mehreren erfindungsgemässen Rechnereinrichtungen besteht, auf denen jeweils ein erfindungsgemässes Programm-Modul abläuft.

Fig. 1 zeigt ein Rechnersystem CS mit drei Rechnereinheiten C1 bis C3, die untereinander kommunizieren.

Bei den Rechnereinheiten C1 bis C3 handelt es sich beispielsweis um Computer, Drucker oder um Netzelemente eines Kommunikationsnetzes. Sie weisen jeweils eine Hardware-Plattform, bestehend aus Prozessoren, Speichereinrichtungen und peripheren Komponenten, eine Software-Plattform, die beispielsweise ein Betriebssystem und ein Datenbanksystem umfasst und Anwendungen auf, die von auf der Software-Plattform ablaufenden Anwendungs-Programm-Modulen gebildet werden. Die Rechnereinheiten C1 bis C3 sind durch ein oder mehrere Kommunikationsnetze untereinander verbunden, beispielsweise durch X.25, #7, Ethernt oder Token-Ring Kommunikationssysteme. Die Software-Plattform der Rechnereinheiten C1 bis C3 stellt hierbei die notwendigen Datenübertragungsdienste bereit.

Die Anwendungs-Programm-Module sind als Objekte (Managed objekt) modelliert, d. h. der Code und die Daten eines Objektes werden durch eine Summe von Attributen und Funktionen repräsentiert, auf die andere Objekte zugreifen können. Durch das wechselseitige Zugreifen einer Vielzahl solcher Objekte werden sodann die Anwendungsfunktionen des Computersystems CS erbracht.

Gemäss der CORBA-Architektur weisen die Rechnereinheiten C1 bis C3 mehrere Objekte CO und SO und mehrere Objekt-Anforderungs-Broker (Object Request Broker) ORB auf.

Aus der Dienstsicht können die Objekte CO und SO jeweils als eine verkapselte Einheit betrachtet werden, die einen oder mehrere Dienste zur Verfügung stellt, die von einem Klienten (client) angefordert werden können. Die Objekte CO fordern hierbei Dienste an (Client Object), die von den Objekten SO erbracht werden (Server Objects).

Zum Anfordern eines Dienstes sendet ein CO eine Anforderungs-Nachricht (request) an ein SO. Eine solche Anforderungs-Nachricht enthält hierbei folgende Informationen: eine Operation, ein Ziel-Objekt, keinen oder mehrere Parameter und optional einen Anforderungs-Kontext (request context). Nach Erbringen des Dienstes sendet das SO eine Ergebnis-Nachricht (outcome) an das CO zurück, die für diese Anforderungsnachricht definiert ist.

Zum Senden und zum Empfang der Anforderungs- und Ergebnisnachrichten steht den Objekten SO und CO eine Schnittstelleneinheit IU zur Verfügung.

Die Objekt-Anforderungs-Broker (ORB) stellen eine Infrastruktur zur Verfügung, die es den Objekten erlaubt, in einer verteilten Umgebung zu kommunizieren. Für die Objekte CO ist es damit nicht von Bedeutung auf welchem der anderen der Rechnereinheiten C1 bis C3 ein Objekt SO, dessen Dienst sie anfordern wollen, angesiedelt ist und auf welcher speziellen Plattform oder in welchem Implementierungsverfahren das Objekt realisiert ist.

Jedes Objekt kennt hierzu zumindest einen Objekt-Anforderungs-Broker ORB und weiss, wie sie diesen lokalen Objekt-Anforderungs-Broker zu kontaktieren hat. Jeder Objekt-Anforderungs-Broker weiss wie er andere Objekt-Anforderungs-Broker kontaktieren kann und wie er mit ihnen zu kommunizieren hat. Hierfür Verwendet er das RPC-Verfahren (RPC = remote procedure call mechanisms). Ein Objekt sendet somit eine Anforderungsnachricht und einen der Objekt-Anforderungs-Broker ORB, die Weiterreichen der Anforderungsnachricht an das Ziel-Objekt wird durch die von den Objekt-Anforderungs-Broker ORB gebildeten CORBA-Infrastruktur erledigt.

Fig. 1b zeigt eine Darstellung der Kommunikationsmechanismen für die Kommunikation zwischen einem CO und einem SO. Fig. 1b zeigt eine Kommunikationsschicht ORB Core, eine darüberliegende Kommunikationsschicht mit fünf Funktionseinheiten DII, IDLSubs, ORBI, SKEL und BOA und zwei auf diese Funktionseinheiten zugreifende Objekte CO und SO.

Um über die CORBA-Infrastruktur kommunizieren zu können und mit anderen Objekten auf dieser Infrastruktur zusammenarbeiten zu können, muss jede der Objekte CO und SO über eine CORBA spezifische Schnittstelle (Interface) verfügen. Ein solche Schnittstelle enthält hierbei eine Beschreibung eines Satzes von möglichen Operation, die eine anderes Objekt von diesem Objekt anfordern kann. Die Schnittstellen der Objekte sind hierbei in der Beschreibungssprache IDL (Interface Definition Language) definiert, bei der es sich um eine reine Schnittstellen-Beschreibungssprach handelt. Die Vererbung (inheritance) dieser Interfaces erlaubt es dass ein Objekt mehrere Schnittstellen unterstützt.
I
In CORBA wird auf ein Objekt direkt über diese CORBA spezifische Schnittstelle zugegriffen. Die Implementierung dieser Schnittstelle ist das Object selbst. Es besteht aus Code und Daten und benötigt somit keine Ausführungsinstanz (Agent entity), wie dies der Fall ist, wenn ein Objekt rein durch eine Datenstruktur repräsentiert ist.

Um eine Anforderungsnachricht zu senden benötigt das Objekt CO Zugriff zu der Referenz (Object Reference) des Objektes SO, benötigt Kenntnis über den Typ des Objektes SO und die Operation, die von diesem ausgeführt werden soll. Das Objekt CO initiiert die Anforderungsnachricht, indem es Rufroutinen (stub routines) der Funktionseinheit IDLStube aufruft oder indem sie die Anforderungsnachricht dynamisch mittels der Funktionseinheit DII erzeugt (Dynamic Invocation Interface). Das zweite Vorgehen ermöglicht es hierbei einen Dienst anzufordern, der bei der Entwicklung des Objektes CO noch nicht bekannt war.

Der Empfang der Anforderungsnachricht wird beim Objekt SO durch Funktionen der Funktionseinheit DOA unterstützt (Basic Object Adapter). Es ist auch möglich, dass das Objekt mittels Funktionen der Funktionseinheit SKEL eine Schnittstelle anbietet, die der obigen zweiten Möglichkeit entspricht.

Zwischen den Objekten des Computersystems CS besteht eine logische Beziehung, deren Struktur beispielhaft in Fig. 2 dargestellt ist.

Fig. 2 zeigt 7 Objekte OA bis OAABB, die untereinander in Beziehung stehen. Die Beziehung der Objekte zueinander wird Beziehungsbaum (containment tree) oder Beziehungs-Hirarchie (containment hirarchy) genannt. Jedes Objekt stellt ein Beispiel (object instance) einer speziellen Objekt - Klassen (object class) dar. Die Objekt-Klassen haben eine spezielle Hirarchie, so ist beispielsweise eine speziellere Objekt-Klasse in einer allgemeineren enthalten und eine allgemeinere Objekt Klasse enthält mehrere speziellere Objekt-Klassen. Entsprechendes gilt für die konkreten Objekte (Managed Objects, Object Instances). Das Objekt OA bildet die Wurzel des Beziehungsbaumes. Die Objekte OAA und OAB sind speziellere Objekte, die in dem höheren Objekt OA enthalten sind. Die Objekte OAAA und OAAB sind Objekte, die in dem Objekt OAA enthalten sind und die Objekte OAABA und OAABB sind Objekte, die in dem Objekt OAAB enthalten sind. Das höhere Objekt wird auch als Eltern-Objekt der enthaltenen Objekte bezeichnet, die wiederum als dessen Kind-Objekte bezeichnet werden.

Genauso wie das Anfordern und Erbringen von Diensten wird in CORBA das Erzeugen und das Löschen von Objekten durch spezielle Generierungs-Objekte (factories) durchgeführt. Diese enthalten jeweils einen Satz von Operationen, die geeignet sind, jeweils bestimmte Arten von Objekten zu erzeugen und zu löschen.

Diese Satz von Operationen wird nun aus den speziellen Generierungs-Objekten in andere Objekte verlagert, deren Hauptaufgabe eigentlich die Erbringung ganz andere Dienste ist. Die Verlagerung dieser Operationen folgt hierbei folgendem Schema: In jedes Eltern-Objekt wird der Satz von Operationen verlegt, der für das Erzeugen und Löschen der diesem nach dem Beziehungsbaum zugeordneten Kind-Objekte zuständig ist. Beim Generieren eines Kind-Objektes zu einem Eltern-Objekt wird dieser Satz von Operationen vererbt und kann bei der Generierung weiter spezialisiert werden, so dass speziellere Erzeugungsfunktionen beispielsweise mit mehr Parametern möglich werden. Objekte (Managed Objects) bilden so Generierungs-Objekte (factories) für ihrer unmittelbaren Nachfolger im Abhängigkeitsbaum. Zur Verwaltung dieses Erzeugen und Löschen von Objekten speichert das Objekt eine Liste der möglichen, ihm unmittelbar nachfolgenden Typen von Objekten.

Damit enthält die Schnittstelle dieser Objekte neben den ursprünglich vorhanden Operationen auch die Erzeugungs- und Löschfunktionen für unmittelbar nachfolgende Objekte im Abhängigkeitsbaum.

Soll somit ein Objekt erzeugt oder gelöscht werden, so ist eine entsprechende Anforderungsnachricht an das entsprechende Eltern-Objekt zu senden. Die Semantik dieser Anforderungsnachricht ist hierbei die eines Generierungs-Objekts. Aufgrund der logischen Beziehung ist das Eltern-Objekt leicht zu lokalisieren, so dass das zuständige Generierungs-Objekt einfach aufzufinden ist.

Es ist auch Möglich, dass diese Art der Erzeugung und des Löschens von Objekten nicht auf alle Objekte des Computersystems CS angewendet wird, sondern nur auf die einem Teilbaum des Beziehungsboumes zugeordneten Objekte. Auch eine Trennung der Lösch- von der Generierungsfunktion wäre möglich. So könnten die Lösch-Operationen auch in die Schnittstelle des zu löschenden Objekts integriert werden.

Müssen Generierungs-Objekte für bestimmte Klassen von Objekten erst noch spezifiziert werden, so ist es auch möglich, auf bereits vorhandene Funktionen zurückzugreifen.

Stehen in dem Computersystem CMISE Operationen zur Verfügung, so können CMISE-Operationen für die Erzeugung- und Löschfunktionen verwendet werden und in einem CMISE Interface weitervererbt werden. Der relevante Teil einer solchen weiterzuvererbenden Schnittestelle ist in Fig. 3 in einer Beschreibungssprache spezifiziert dargestellt.

Die Operationen in Fig. 3 haben hierbei folgende Bedeutung:

Support subordinate ist hierbei eine Spezifikation der GenericFactory : : suports operation. Es hat einen Objetkt- Identifizierer (object identifier als Eingang anstelle eines mehr allgemeinen Schlüssels (Key).
Create_subordinate ist eine Spezialisierung von GenericFactory :: create_object. Es wird wieder der Object- Identifizierer (object identifier) als anstelle eines mehr allgemeinen Schlüssels (Key) verwendet. Ein extra Parameter
name ist vorhanden, der das Attribut des erzeugten Objektes verwendet, um es zu benennen. Der Parameter
Name kann jedoch auch in dem letzen Paramter
criteria enthalten sein. Dieser ist derselbe wie in GenericFactory :: create_object one. Es handelt sich um eine Liste von &lang&name, value&rang& Paaren, die irgendeinen der Erzeugungsparameter (initial values, resource constraints, location...) enthalten kann. Die Objektkennung (reference object) wird, soweit eine vorhanden ist, in einem Kriterium abgespeichert. Abweichungen (Exeptions) werden von GenericFactory::creat_object zurückgemeldet. Bis auf eine Rückmeldung, autonaming, die anzeigt, dass der Namens parameter ignoriert wird, werden die Objekte automatisch benannt.
Delete_subordinate ist eine Spezialisierung von LifeCycleObject :: remove. Diese Anforderung ist an das Eltern-Objekt gerichtet, so dass dieses die Resourcen verwalten kann, die durch das Löschen des Objekts frei werden. Diese Operation kann eine Zurücksetzungsoperation in dem zurückgesetzten Objekt selbst auslösen, so dass es überprüfen kann, ob es zurücksetzbar ist und so seine eigenen Resourcen löschen kann. Elete_subordinate kann die NotRemovable Abweichung auslösen, genauso wie durch LifeCycleObject:: remove. Es besitzt eine extra InvalidName Abweichung, die zum Ausdruck bringt, dass der zur Verfügung gestellte Name kein existierendes Kind-Objekt identifiziert.


Das zweite Ausführungsbeispiel gibt hierfür ein Beispiels aus dem Bereich des Netzwerkmanagement.

In einem zweiten Ausführungsbeispiel wird nun ebenfalls die Durchführung der erfindungsgemässen Verfahren in einem erfindungsgemässen Computersystem beschrieben, das aus einem oder aus mehreren erfindungsgemässen Rechnereinrichtungen besteht, auf denen jeweils ein erfindungsgemässes Programm-Modul abläuft. Im Gegensatz zum ersten Ausführungsbeispiel handelt es sich bei dem Computersystem jedoch um ein Netzwerkmanagementsystem, bei dem auch nicht CORBA Objekte durch Anpassungsfunktionen so modifiziert werden, dass sie nach aussen hin als CORBA Objekte auf der CORBA Infrastruktur agieren. Das Computersystem ist so wie das Computersystem CS nach Fig. 1a ausgestaltet. Die Rechnereinheiten stellen Netzwerkmanagement-Einheiten, beispielsweise Netzelemente (network elements), Netzwerkmanagement-Zentralen (network management center) oder Anpassungeinrichtung (mediation device) dar. Es ist auch möglich, dass das Computersystem noch weitere Aufgaben wie das Verwalten oder Erbringen von Netzdiensten erbringt. Diese Dienste könnten auch auf der TINA -Softwarearchitektur (TINA DPE Service Specification, TINA-C, 1994) basieren.

Fig. 4a zeigt eine Darstellung der Kommunikationsmechanismen für die Kommunikation zwischen zwei solcher Netzwerkmanagement-Objekte über die CORBA-Infrastruktur.

Fig. 4a zeigt eine Kommunikationsschicht CORB/ORB, mehrere über diese Kommunikationsschicht allgemein zur Verfügung stehende Dienste CMISE Services, zwei Netzwerkmanagement-Komponenten M und A und jeweils zwei zwischen diesen Objekten und der Kommunikationsschicht CORB/ORB gelegenen Kommunikationsfunktionen GMO/C+ + und CMISE/IDL.

Für den Bereich des Netzwerkmanagements ist von der OSI (Open System Interconnection) ebenfalls ein Objektmodell standardisiert (Management framework for open systems interconnection, ITU-T Recommendation X.700, 1992). Neben dem Objektmodell (SMI = Structure of Management Information) sind auch grundlegende Objekte, ein Set von Management Diensten (CMIS common management information service definition) und ein Netzwerkmanagement-Protokoll (CMIP = Common Management Information Protocol) zur Kommunikation der Objekte untereinander spezifiziert. Objekte sind in der Beschreibungssprache GEMO spezifiziert, die die ASN Syntax verwendet und weitere eigene Makros enthält.

Bei den Komponenten M und A handelte es sich nicht um CORBA-Objekte, sondern jeweils um ein oder mehrere OSI- Objekten OM bzw. OA und einer Manager bzw. Agent Funktionseinheit. Mittels der Agent bzw. Manger Funktionseinheit werden Operationen auf diesen Objekten ausgeführt bzw. Anforderung an andere Objekte versendet. Agent und Manager Funktionseinheit kommunizieren über das CMIP -Protokoll. Aus der Sichtweise des Netzwerkmanagement nimmt die Komponente M die Rolle eines Managers (Manager) und die Komponente A die eines Agenten (Agent) ein.

Die Kommuniktationseinheit GDMO/C++ besteht aus einem oder mehreren speziellen Zugriffs-Objekten, die die Ausführung von CMISE Operationen auf den Objekt OA oder OM ermöglichen.

Die CMISE Management Dienste werden durch ein CMISE-Objekt auf der Seite des Objektes OA realisiert. Die Schnittstelleneinheit CMISE/IDL enthält dieses CMISE-Objekt und die diesem Objekt zugeordneten Dienste. Das CMISE-Objekt der Schnittstelleneinheit CMISE/IDL ist durch ein IDL-Interface spezifiziert ist und agiert und erscheint so nach aussen wie ein CORBA-Objekt. Um diese Spezifizierung und damit die Bereitstellung einer CORBA-Scnittstelle zu dem Objekt OA zu ermöglichen, ist eine Typkonvertierung von ASN.1 in IDL Typen notwendig. CMISE-Dienste stellen somit als ein Set von CORBA Objekten zur Verfügung. Durch über die CORBA-Infrastruktur geleitet CORBA-Anforderung können so CMISE-Operationen auf dem Objekt OA ausgeführt werden. Gleiches gilt für das Objekt MO.

Für das Erzeugen oder Löschen von Objekten wird nun das der in Fig. 3 dargestellte Teil in dem Interface weitervererbt.

Eine zweite Möglichkeit der Anbindung von OSI-Objekten über eine CORBA-Infrastruktur ist in Fig. 4b aufgezeigt, die ein drittes Ausführungsbeispiel darstellt.

Fig. 3b zeigt die Kommunikationsschicht CORB/ORB, mehrere über diese Kommunikationsschicht allgemein zur Verfügung stehende Dienste CMISE Services, die Objekte OM und OA und jeweils zwei zwischen diesen Objekten und der Kommunikationsschicht CORB/ORB gelegenen Kommunikationsfunktionen GDMO/IDL und CMISE/IDL

Durch die Schnittstelleneinheit GDMO/IDL werden die in GDMO spezifizierten OSI-Objekte der Komponenten A und M in eine Spezifikation als IDL Schnittstelle übersetzt. Auf ein so spezifiziertes Objekt kann durch klassische CORBA-Nachrichten zugegriffen werden. Jedes dieser OSI-Objekt wird somit in ein reines CORBA Objekt transformiert. Da die Spezifikation in IDL und ASN.1 von unterschiedlicher Natur sind (Schnittstellenbeschreibung &lang&-&rang& Objekt- Spezifikation) ist keine vollkommene Übersetzung möglich und nur ein Untermenge von CMISE-Diensten wird über die Schnittstelleneinheit GDMO/IDL angeboten. Dies bedeute, dass nur eine Untermenge von CMISE Operationen auf den transformierten CORBA-Objekten ausführbar ist.

Für das Löschen und Erzeugen von Objekten mittels CMISE Dienste wird nun zusätzlich eine Schnittstelleneinheit CMISE/IDL vorgesehen. Über diese zusätzliche Schnittstelle wird die in CMISE vorhandene Erzeugungsfunktion (m-create) über eine CORBA Schnittstelle zugänglich gemacht und eine Anwendung dieser Funktion auf die transformierten CORBA-Objekte der Komponennte A ermöglicht.

Zum Erzeugen eines Objektes in der Komponente A muss ein Objekt der Komponente M oder ein sonstiges CORBA- Objekt des Commputersystems CS das für die Verwaltung der Erzeugung und des Löschens des Objekts zuständig Generierungs-Objekt adressierten. Dieses Generierungs-Objekt ist das Eltern-Objekt des zu erzeugenden Objektes, das ebenfalls ein Objekt der Komponente A ist. Um auf die Erzeugungsfunktion zuzugreifen, wird hierbei über die CMISE/IDL Schnittstelleneinheit auf die CMISE-Erzeugungsfunktion zugegriffen, die über diese Schnittstelleneinheit dem Eltern-Objekt zur Verfügung stellte. Die Erzeugung dieses Kind-Objektes wird somit über eine CORBA-Nachricht unter Verwendung der CEMISE Semantik und unter Zuhilfenahme von CMISE- Diensten durch ein transformiertes CORBA Objekt durchgeführt.. Auf reziproke Weise wird auf den entsprechen CMISE Dienst zum Löschen von Objekten zugegriffen.