DE69731614T2

DE69731614T2 - Netzübergreifende einrichtung und verfahren zur herstellung einer solchen einrichtung

Info

Publication number: DE69731614T2
Application number: DE69731614T
Authority: DE
Inventors: Adrian Newcombe; Damian Ashbourne McGRATH
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1996-02-15
Filing date: 1997-02-14
Publication date: 2005-10-06
Anticipated expiration: 2017-02-15
Also published as: JP2000504868A; EP0880842B1; EP0880842A1; AU732374B2; AU2227497A; US6324576B1; CN1166115C; DE69731614D1; CA2244918C; CA2244918A1; WO1997030535A1; CN1211364A

Description

Die vorliegende Erfindung betrifft eine Management Interworking Unit (MIU = Managementzusammenwirkungseinheit) sowie ein Verfahren zum Produzieren einer solchen Einheit. Die Erfindung betrifft insbesondere, aber nicht ausschließlich, das Zusammenwirken von Telekommunikationssystemen.
Es gibt zahlreiche Situationen, in denen eine Managementzusammenwirkungseinheit benötigt wird, damit Managementsysteme kooperieren können. In einem typischen Beispiel ist ein Managementsystem eine PABX, die eine proprietäre Managementschnittstelle unterstützt, und das andere ist ein Fernmanager, der eine standardisierte Schnittstelle unterstützt. Die MIU bietet die Konvertierung von Protokollen und Informationen, so dass der Fernmanager die PABX steuern kann.
MIUs haben typischerweise eine Konvertierungsfunktion, die häufig als Informationskonvertierungsfunktion (ICF) bezeichnet wird, sowie Schnittstellen, die häufig Nachrichtenkommunikationsfunktionen (MCFs) genannt werden. Ein Beispiel für eine MIU ist in der PCT-Patentspezifikation Nr. WO95/23469 (British Telecommunications PLC) beschrieben. Die ICF beinhaltet einen Mapper 44 und die MCFs beinhaltet Stapel 40 und 52. Während solche MIUs im Allgemeinen recht effektiv sind, sind sie doch häufig schwer zu produzieren, weil ein großes Maß an manueller Eingabe erforderlich ist und weil sie sich nur schwer modifizieren oder expandieren lassen.
Die WO9423514 (British Telecommunications PLC) beschreibt eine MIU, die Kommunikationen zwischen einem Netzwerkmanagement und an ein LAN angeschlossenen Ressourcen zulässt. Die MIU hat Mittel zum Kommunizieren mit den Ressourcen auf dem LAN durch ein erstes Netzmanagementprotokoll sowie Mittel zum Kommunizieren mit dem Netzwerkmanager durch ein zweites Protokoll. Die beschriebene MIU wäre zwar im Gebrauch effektiv, würde aber eine erhebliche Vorlaufzeit benötigen, da für ihre Produktion ein hohes Maß an manuellen Eingaben erforderlich wäre.
Der Artikel „SNMP Management Unbound", DATA Communications, Bd. 21, Nr. 2, 1.2.1992, Seiten 125–128, XP000256999, M. Jender, offenbart ein Managementsystem, bei dem die Steuerung eines Netzwerks von einer zentralen Stelle aus durchgeführt werden kann. Die verfügbare Bandbreite wird dadurch konserviert, dass grafische Benutzeroberflächenfunktionen von Managementschnittstellenfunktionen getrennt werden. Der Artikel enthält jedoch keinen Vorschlag, wie ein hohes Maß an Automation bei der Produktion einer MIU erzielt werden kann.
Es ist Aufgabe der Erfindung, eine verbesserte und einfacher konstruierte Managementzusammenwirkungseinheit bereitzustellen.
Es ist eine weitere Aufgabe, ein Verfahren zum Produzieren einer Managementzusammenwirkungseinheit bereitzustellen, das effizienter ist, als dies bisher der Fall war.
Gemäß der Erfindung wird ein Verfahren zum Erzeugen einer Managementzusammenwirkungseinheit für ein Paar Managementschnittstellen gemäß Anspruch 1 bereitgestellt.
Durch Erzeugen von Modellen und nachfolgendes Erzeugen von Mappings zwischen äquivalenten Teilen der Modelle kann die Produktion der ICF in einem hohen Maß automatisiert werden. Dadurch wird die Vorlaufzeit beim Produzieren einer MIU erheblich reduziert. Ferner wird durch Abtrennen der Formatkonvertierung als ein Vorgang, der ausschließlich von der MCF durchgeführt wird, die Aufgabe des Produzierens der MIU auf einfache Weise aufgeteilt. Sämtliche interne Kommunikation erfolgt mit dem internen Protokoll und die MCFs führen lediglich Formatkonvertierung durch, die für Kommunikationen mit den zusammenwirkenden Managementschnittstellen erforderlich ist.
In einer Ausgestaltung umfasst jedes Modell Objekte in einer Containment-Hierarchie, die einen Containment-Kontext für jedes Objekt bereitstellt. Auf diese Weise werden die verwalteten Ressourcen auf einfache Weise repräsentiert, die ihre Struktur reflektiert.
Jedes Objekt hat vorzugsweise eine Klasse, die durch Charakteristiken unabhängig vom Kontext definiert wird. Man hat gefunden, dass das Verknüpfen der Klasse und des Kontexts eine sehr wirksame Weise ist, um automatisch äquivalente Teile der beiden Modelle zu identifizieren. Dies ermöglicht ein hohes Maß an Automation.
Die Modelle werden vorzugsweise wenigstens teilweise automatisch durch Ladermodule erzeugt. Die Verarbeitungsvorgänge von Ladermodulen können sehr effizient durchgeführt werden.
In einer Ausgestaltung werden die Modelle für Managementschnittstellenspezifikationen erzeugt und spezifikationsfreier Text wird manuell in die Modellsprache konvertiert. Dies hilft zu gewährleisten, dass eventuelle Uneindeutigkeiten, die evtl. in den Spezifikationen vorliegen, nicht auf die Modelle übertragen werden.
Die Mappings befinden sich vorzugsweise zwischen individuellen Objekten und zwischen Gruppen von Objekten mit der-/demselben Klasse und Kontext, nämlich Kontextklassen. Dies ergibt einen sehr umfassenden Satz von Mappings.
Die Mappings definieren vorzugsweise Kontextklassenkardinalität. In einer Ausgestaltung werden die Mappings zwischen Kontextklassen und vorzugsweise auch zwischen Objekten und vorzugsweise auch zwischen Objektcharakteristiken erzeugt.
In einer Ausgestaltung beinhalten die Charakteristiken Objektfunktionen (oder Aktionen), Beziehungen, Attribute, Avisierungen und Verhalten. Es wurde gefunden, dass dieser Satz von Charakteristiken jedes Objekt umfassend charakterisiert.
Die Mappings werden vorzugsweise interaktiv unter Verwendung einer grafischen Schnittstelle erzeugt, die die Modelle und die Mappings repräsentiert. Dies ist eine sehr einfache und schnelle Weise des Erzeugens der Mappings.
Die Mappings werden idealerweise durch für die Mappings gewählte Laufzeitregeln prädikatiert.
In einer Ausgestaltung beinhaltet das Verfahren den weiteren Schritt des Vorkompilierens der Modelle und der Mappings zu einer Schablone zum Produzieren von Source-Code.
Idealerweise wird die Schablone nach dem Vorkompilieren manuell modifiziert und Flags werden in die Schablone gesetzt, um zwischen automatisch generiertem Code und manuell generiertem Code zu unterscheiden.
In einer Ausgestaltung werden Suchläufe durchgeführt, um zu ermitteln, ob ein vorgeschlagenes Mapping zuvor für ähnliche Charakteristiken durchgeführt wurde, und solche Mappings können wiederverwendet werden.
Gemäß einem weiteren Aspekt stellt die Erfindung eine Managementzusammenwirkungseinheit (MIU) für ein Paar Managementstellen gemäß dem unabhängigen Anspruch 14 bereit.
Diese Struktur von MIUs stimuliert die Wiederverwendung von individuellen MCF/ICF-Komponenten.
Jedes Modell umfasst vorzugsweise Objekte in einer Containment-Hierarchie, die einen Containment-Kontext für jedes Objekt bereitstellt.
In einer Ausgestaltung hat jedes Objekt eine Klasse, die Charakteristiken unabhängig vom Kontext definiert.
Die Mappings sind vorzugsweise zwischen individuellen Objekten sowie zwischen Gruppen von Objekten mit derselben Klasse und demselben Kontext, nämlich Kontextklassen.
In einer Ausgestaltung definieren die Mappings Kontextklassenkardinalität.
Idealerweise verknüpfen Mappings Kontextklassen und verknüpfen auch vorzugsweise Objekte und verknüpfen auch vorzugsweise Objektcharakteristiken.
In einer Ausgestaltung beinhalten die Objektcharakteristiken Funktionen oder Aktionen, Beziehungen, Attribute, Avisierungen und Verhalten.
In einigen Fällen werden Mappings durch für die Mappings gewählte Laufzeitregeln prädikatiert.
In einer Ausgestaltung beinhaltet das interne Protokoll Grundelemente, die Start, Ende und Rollback von atomaren Transaktionen in der ICF steuern.
Die Erfindung wird anhand der nachfolgenden Beschreibung von einigen ihrer Ausgestaltungen besser verständlich, die mit Bezug auf die Begleitzeichnungen lediglich beispielhaft gegeben wird. Dabei zeigt:
1 ein Fließschema, das ein erfindungsgemäßes Verfahren zum Produzieren einer Managementzusammenwirkungseinheit (MIU) illustriert;
2 eine schematische Darstellung von Beziehungen zwischen Entitäten von zusammenwirkenden Schnittstellen;
3 eine schematische Darstellung einer Art und Weise, in der Entitäten abgebildet werden;
4 ein Anzeigebildschirmbeispiel, das die Art und Weise zeigt, in der die MIU erzeugt wird; und
5 und 6 schematische Darstellungen der Struktur einer MIU.
1 illustriert ein Verfahren 1 zur Produzieren einer Managementzusammenwirkungseinheit (MIU) 10. Ganz kurz, bei dem Verfahren 1 werden Quellschnittstellenspezifikationen A und B der Managementsystemschnittstellen genommen, die zusammenwirken sollen. In dieser Ausgestaltung ist die Spezifikation A die einer GDMO- (General Description of Managed Objects) Schnittstelle, während Spezifikation B die einer proprietären Schnittstelle ist. Spezifikation A wird von Ladermodulen 2 in ein Informationsmodell 4 in einer Map-Sprachendarstellung konvertiert. Spezifikation B wird von Ladermodulen 3, die die Spezifikation parsen und sie in die semantisch äquivalente Map-Sprachendarstellung konvertieren, in ein in der Map-Sprache definiertes Informationsmodell 5 konvertiert.
Anstatt des Erzeugens der Modelle können sie zuvor als Teil der Spezifikation oder anderweitig erzeugt und daher einfach gespeichert werden.
Nach dem Erzeugen der Modelle 4 und 5 in der Map-Sprache erzeugt ein Prozessor 6 die MIU 10. Der Prozessor 6 verwendet gespeicherte Sätze von Fachwissen 7 und Eingaben von einer Benutzeroberfläche 8, die zum Erzeugen von Mappings 9 während des Prozesses verwendet werden.
Die MIU 10 umfasst eine Informationskonvertierungsfunktion (ICF) 11 sowie ein Paar Nachrichtenkommunikationsfunktionen (MCFs) 12. Die ICF 11 bildet die in einem der Modelle 4 und 5 enthaltenen Informationen auf die in dem anderen ab, um eine Laufzeitkonvertierung durchzuführen. Es gibt wenigstens eine ICF 11 für jedes Paar von zusammenwirkenden Modellen. Die MCFs 12 handhaben alle Kommunikationen mit den externen Entitäten. Die externe Kommunikation erfolgt nach den Grundelementen des relevanten Protokolls, wie z. B. CMIS (Common Management Information Services) oder MML (Man Machine Language). Es gibt eine definierte Schnittstelle zwischen jeder MCF 12 und der ICF 11, über die Signale gemäß einem internen Protokoll übertragen werden. Das interne Protokoll beinhaltet lediglich zehn Grundelemente.
Innerhalb der Architektur der MIU 10 gibt es eine Trennung der Kern- und optionalen Funktionalität, eine funktionale Verteilung der physikalischen Architektur, Administration und Initialisierungsoperationen.
Zurück zu Verfahren 1, in einem Beispiel ist Spezifikation A die einer Q3-Schnittstelle auf der Basis eines ETSI (European Telecommunications Standards Institute) Standardmanagementmodells für ATM-Crossconnects. Spezifikation B ist die einer proprietären Schnittstelle. Spezifikation A ist in der GDMO beschrieben, und es wird über das CMIP (Common Management Information Protocol) darauf zugegriffen, durch das die Operationen an den verwalteten Objekten durchgeführt werden können. Spezifikation B basiert auf einem proprietären objektorientierten Informationsmodell und kommuniziert unter Verwendung einer UNIX (eingetragenes Warenzeichen (RTM)) Nachrichtenwarteschlange.
Es gibt eine gemeinsame interne Repräsentation für Objekte der Informationsmodelle 4 und 5. Die Informationen in jeder Schnittstelle werden als ein Satz von Objekten in einer Containment-Hierarchie dargestellt. Diese Objekte werden in einer Sprache definiert, die für diesen Zweck entwickelt wurde und die mit Map bezeichnet wird und nicht nur die Informationsmodelle 4 und 5, sondern auch die Mappings 9 beschreibt, die die dazwischen existierenden Beziehungen definieren. Die Ladermodule 2 und 3 wirken auf den Spezifikationen A und B, die gewöhnlich als ASCII-Text gespeichert sind, um sie in die Map-Beschreibungsmodelle 4 und 5 zu konvertieren. Die Beschreibungen, die generiert werden, können mit der Schnittstelle 8 interaktiv annotiert werden, um zusätzliche Map-Statements zu generieren. Alternativ kann der Benutzer die gesamten Modelle 4 und 5 manuell mit Map direkt generieren. Teile der in Freitext geschriebenen Spezifikation können nicht automatisch vom Ladermodul konvertiert werden, und daher muss der Benutzer das Modell annotieren. Dadurch wird gewährleistet, dass eventuelle Uneindeutigkeiten, die aus Freitext entstehen, nicht in das Modell weitergeleitet werden. Ein Beispiel ist eine Freitextdarstellung des Verhaltens eines verwalteten Objekts in GDMO-Spezifikationen.
Die Art und Weise, in der der Prozessor 6 die Mappings 9 erzeugt, wird nachfolgend beschrieben. Diese Mappings beinhalten Erzeugungsbeziehungen, die Entitäten in den beiden Modellen verbinden. Solche Mappings zwischen den beiden Modellen verknüpfen:

– (a) Kontextklassen, und innerhalb dieser:
– (b) Objekte; und innerhalb dieser:
– (c) objektinterne Charakteristiken.

In Bezug auf (a) oben, jede Klasse wird von einem Satz von Charakteristiken definiert, wie z. B.:

– Funktion (Aktion),
– Beziehungen,
– Attribute (Datenelemente),
– Avisierungen und
– Verhalten.

Eine Kontextklasse ist eine besondere Klasse in einem bestimmten Kontext oder an einer bestimmten Position in der Containment-Hierarchie.
In Bezug auf (b) oben, jedes Ojekt repräsentiert eine Ressource, die von der assoziierten Managementsystemschnittstelle verwaltet wird. Dies kann auf stark unterschiedlichen Abstraktionsniveaus erfolgen, je nach der Art des benötigten Managements. Ein Abstraktionsniveau ist Crossconnect-Ausrüstung, ein Beispiel auf einem niedrigeren Level ist eine Switching-Fabric, die in der Crossconnect-Ausrüstung enthalten ist.
In Bezug auf (c) oben ist die interne Charakteristik jedes Objekts eine Instanz einer Klasse, d. h. sie hat bestimmte charakteristische Werte.
Die Map-Sprache kann Beziehungen beschreiben, die vorgeben, dass, wenn eine Instanz von einer Kontextklasse in einem Modell erzeugt wird, eine äquivalente Instanz einer anderen Kontextklasse in dem anderen Modell erzeugt werden soll. Diese beiden Instanzen gelten als Zwillinge, und die Beziehungen werden als Erzeugungsbeziehungen bezeichnet. Der Prozessor 6 erzeugt Code zum Unterstützen von Laufzeitmappings zwischen den in der MIU gespeicherten Instanzen und Instanzen, die in einem der Systeme gespeichert sind, die zusammenwirken sollen.
2 illustriert Beispiele der Erzeugungsbeziehungen. Eine solche Beziehung wird als eine totale Beziehung 20 zwischen einer Kontextklasse 21 und einer Kontextklasse 22 bezeichnet, die jeweils Objekte 23 haben. Hierbei handelt es sich um eine Eins-zu-eins-Beziehung. Ein weiterer Typ von Erzeugungsbeziehung ist eine Unterordnungsbeziehung 25, in der jede in A erzeugte Instanz zu einer Zwillingserzeugung in E führt, aber nicht unbedingt umgekehrt. Somit beinhalten die Mappings Kardinalität definierende Assertionen.
In Bezug auf das Mapping von Kontextklassen, die Map-Sprache unterstützt einen einfachen Satz von Assertionen, die zum Beziehen von Kontextklassen in zwei Modellen verwendet werden. Diese werden wie folgt beschrieben:

1. Einfache totale Beziehung. Bei einer Kontextklasse A in einem Modell und einer Kontextklasse B in einem anderen können sie mittels des Ausdrucks (is-total AB) bezogen werden. Dies bedeutet, dass immer dann, wenn eine Instanz von A erzeugt wird, eine Instanz von B erzeugt werden muss, und umgekehrt. Diese Instanzen gelten dann als Zwillinge. Dies bedeutet, dass immer dann, wenn eine Operation wie get, set oder action an einer durchgeführt wird, ihr Äquivalent an der anderen durchgeführt werden muss.
2. Untergeordnete und prädikatierte Beziehungen. Der Ausdruck is_subset AB bedeutet, dass, wenn eine Instanz von A erzeugt wird, auch eine Instanz von B erzeugt werden muss, aber das Umgekehrte ist nicht unbedingt wahr, d. h. wenn eine Instanz B erzeugt wird, dann muss nicht unbedingt eine Instanz A erzeugt werden. Die Bestimmung, wann ein Zwilling erzeugt wird, kann mit Prädikaten erfolgen. Diese können z. B. verwendet werden, um die Werte von Attributen in einer neu erzeugten Instanz B zu testen, um zu bestimmen, ob eine Zwillingsinstanz A erzeugt werden soll.
3. Beziehen von Attributen oder Unterteilen von Atributen. Zuweilen können Klassen in zwei Modellen über ein Attribut aufeinander bezogen werden, das eine Liste oder ein Satz ist, d. h. es existiert eine Zwillingsinstanz für jedes Element der Liste oder des Satzes.
4. Implizite Beziehungen. Diese Beziehungen implizieren keine Zwillingsbeziehung zwischen zwei Klassen. Zuweilen kann jedoch ein Attribut in einem Modell verwendet werden, um eine Instanz einer Klasse in einem anderen Modell eindeutig zu identifizieren. Dies wird als implizite Beziehung bezeichnet und wird in Map mit der Assertion is_imp unterstützt.
5. Beziehen von virtuellen Basisklassen. Das Zulassen von Vererbung von Mappings reduziert Arbeit auf dieselbe Weise wie das Zulassen von Vererbung in Klassen.
6. Viele-zu-eins-Erzeugungsassertionen. Diese treten dann auf, wenn zwei oder mehr Klassen in einem Modell auf dieselbe Klasse in einem anderen Modell bezogen werden sollen.
7. Mappings auf Funktionssysteme. Viele Legacy-Systeme verwenden funktionelle Schnittstellen wie APIs in C-Sprache oder MMLs. Die Map-Sprache spezifiziert Schnittstellenfunktionen und asynchrone Meldungen zum Handhaben dieser funktionellen Schnittstellentypen.

In Bezug auf das Mapping von Objekten und deren Charakteristiken beinhaltet dies das Beschreiben der Arten und Weisen, in denen sich verwaltete Ressourcen, die von den Objekten repräsentiert werden, aufeinander beziehen. Diese Beziehung wird durch das Mapping der enthaltenen Charakteristiken der Objekte repräsentiert. Es folgen Datenmapping-Fälle, die Grundelemente involvieren, die die Klassenmappings is total und is subset begleiten.

1. Abbilden einfacher Attribute. Dies beinhaltet das Beschreiben von Datenmappings zwischen zwei Attributen eines einfachen Typs (z. B. nummeriert oder ganzzahlig). Diese Mappings haben allgemein die Form von Tabellen zum Abbilden von nummerierten Typen und Funktionen zum Abbilden anderer Typen wie ganze Zahlen.
2. Abbilden komplexer Attribute. Komplexe Attribute sind solche, die Strukturen, Auswahloptionen, Listen oder andere Kombinationen der obigen beinhalten. Die Notation für ein Mapping dieser Typen ist aufwändiger.
3. Zusammengesetzte Attributmappings. Hier werden mehrere Attribute auf ein Attribut abgebildet.
4. Mapping-Aktionen. Aktionen in einer Klasse können auf eine oder mehrere Aktionen in einer verwandten Klasse abgebildet werden. Mapping-Aktionen beinhalten zwei Stufen. Die erste Stufe besteht im Abbilden von Parametern und Rückgabewerten der Aktion. Dies erfolgt in derselben Weise, in der Attribute abgebildet werden. Die zweite Stufe bei Mapping-Aktionen ist die Abbildung der kritischen Elemente ihrer Verhaltensweisen, die gets, sets, creates und actions beinhalten. Dies ist eine komplexe Aufgabe.
5. Nicht existierende Mappings für obligatorische Attribute. Diese Situation tritt dann auf, wenn ein Attribut zur Objekterzeugungszeit benötigt wird, aber keines existiert, weil es keine äquivalenten Informationen in der zusammenwirkenden Schnittstelle gibt. Stattdessen wird ein Vorgabewert spezifiziert.
6. Uncachebare Objekte. Hierbei handelt es sich um die Situation des Abbildens von Avisierungen und was geschieht, wenn ein Objekt sich ändern kann, aber keine Avisierung an die MIU ausgibt. Solche Objekte werden als in der MIU nicht cachebar markiert.

Die Map-Sprache besteht aus einer Liste von Deklarationen, die die Modelle 4 und 5 und die Mappings 9 beschreiben. Map beschreibt verwaltete Schnittstellen unter Verwendung von verwalteten Objektklassen, Datentypdefinitionen, Funktionen, Ausnahmen, Nachrichten und einem Containment-Baum.
Zum Wählen eines Beispiels wird ein typischer Datentyp wie folgt beschrieben: (deftype drink_machine_state (enum empty not_empty full)) Dies ist ein nummerierter Deklarationstyp für den Typ drink_machine_state, der einen der drei Werte empty, not_empty oder full haben kann. Strukturen werden auf ähnliche Weise wie Auswahloptionen und Listen deklariert. Darüber hinaus gibt es bestimmte Grundtypen wie ganzzahlig, natürlich, String, real, boolesch und Referenz (zum Referenzieren anderer verwalteter Objekte).
Es folgt ein Beispiel für ein Mapping in der Map-Sprache. Dieses Mapping bezieht sich auf das Diagramm von 3.
(is_total GEquipment G12Equipment (= GType 12)...)
In diesem Beispiel arbeiteten zwei Modelle mit einem anderen Ansatz zum Modellieren derselben wirklichen Ressourcen. Bei einem wurde entschieden, den Satz aller GEquipment-Objekte mit einer einzigen Klasse mit der Bezeichnung GEquipment zu modellieren. Das andere Modell hat denselben Ressourcentyp mit drei anderen Klassen modelliert: G12Equipment, G14Equipment und G16Equipment, die weniger allgemein sind als GEquipment. GType ist ein Attribut in GEquipment. Wenn beispielsweise eine Instanz von GEquipment mit GType=12 erzeugt wird, dann ist ihr Zwilling eine Instanz der G12Equipment-Klasse.
Wenn GType=24 ist, dann gibt es kein äquivalentes Mapping. Die Vorgabeentscheidung für ein prädikatiertes Mapping ist, keinen Zwilling zu erzeugen. Die Attribute, die getestet werden können, sind diejenigen, die zum Erzeugungszeitpunkt geliefert werden müssen, d. h. obligatorische Attribute.
Das allgemeine Format einer is total Beziehung lautet wie folgt:
(is total source-context-class target-context-class predicate
(attribute-maps...) ;; Datenmappings-Attribute
(action-maps...) ;; Mappings für Attribute
(notification-maps...)) ; Mappings für Avisierungen
Die Attribute-Maps-Statement besteht aus einer Liste von Maps-Statements, die die allgemeine Form für einfache Attribut-Mappings haben:
(maps <attribute-components> <attribute-component>
(down <maptable>|<function>)
(up <maptable>|<function>))
Es gibt zwei Mappings, eins in einer Abwärtsrichtung, eins in einer Aufwärtsrichtung. Diese können mittels einer Maptabelle beschrieben werden, die explizite Übersetzungen für nummerierte Typen bereitstellt, oder mittels einer Funktion, die als Programm geschrieben ist, wie z. B. ein Action-Verhalten, oder die aus einem Standardsatz von Funktionen genommen wurde, z. B. Pro-Stunde-bis-pro-Minute. Diese vordefinierten Funktionen könnten potentiell in einer Bibliothek von separaten Map-Modulen vorgesehen werden. Die einfachste Form der Maps-Statement ist die, bei der zwei Attribute beteiligt sind, von denen beide nummerierte Typen sind, und Maptabellen zum Vorgeben von Abwärts- und Aufwärts-Mappings verwendet werden. Ein Beispiel hierfür ist unten illustriert.
Dieses Beispiel beinhaltet das Mapping von einfachen Attributen wie z. B. nummerierten Typen oder ganzen Zahlen. Man betrachte die folgenden Typen, die zum Beschreiben der Attribute drink_machine_state und vending_machine_state verwendet werden:
(deftype drink_machine_state_type (enum run_out ok low))
(deftype vending_machine_state_type (enum empty operational)).
Um ein Attribut vom Typ drink_machine_state_type auf ein Attribut des Typs vending_machine_state-type abzubilden, verwenden wir den folgenden Ausdruck:
Mapping-Tabellen reichen zum Beschreiben eines Mappings nicht immer aus. Wenn mehr Flexibilität benötigt wird, dann verwenden Mapping-Funktionen dieselbe Programmsyntax zum Beschreiben von Konvertierungen. Man betrachte das Problem des Mapping von einem Ganzzahlenattribut X auf ein Ganzzahlenattribut Y. Der Wert von Y ist immer das Doppelte von dem von X, es sei denn, dass X 128 überschreitet, und in diesem Fall erhält Y immer den Wert 256. In Map würde dies wie folgt implementiert:
Es ist möglich, umdefinierte oder zuvor definierte Funktionen für Mapping zu verwenden. Zum Beispiel, wenn sich die Werte von Attribut X gerade auf Attribut Y mappen ließen und umgekehrt, dann könnte das Mapping wie folgt definiert werden:
Der Compiler gewährleistet, dass die Zahl der Argumente für die vordefinierte Funktion mit denen des Mappings übereinstimmt (in diesem Fall wird ein einziges Argument in jeder Richtung benötigt).
Der Prozessor 6 hat einen Compiler, der Gerüst-Source-Code für die MIU 10 erzeugt. Die Code-Erzeugung erfolgt in zwei Stufen, nämlich Vorkompilieren zum Erzeugen einer Code-Schablone und Konvertieren der Code-Schablone in einen Code-Ausgang. Die Code-Schablone ermöglicht es einem Benutzer, den automatisch generierten Source-Code zu betrachten und ihn durch Hinzufügen von handgeschriebenem Code anzupassen. Mit Hilfe von Flags wird zwischen den beiden Code-Typen unterschieden, so dass Benutzer-Code vom Compiler nicht überschrieben wird. Der Compiler erzeugt Source-Code einer High-Level-Sprache wie C++ sowie IDL-Code. Implementierte Mapping-Merkmale beinhalten die Verarbeitung von is total und is subset Klassen-Mappings einschließlich Aspekten wie:

– Implementieren von Mappingprädikaten,
– Mapping von ,Kontextklassen',
– Mapping von Klassenerzeugung,
– Propagierung von einfachen/Auswahl/strukturierten Datenmappings für Attribute zu und von Managing und Managing-Systemen [*2],
– Propagierung von Aktionen einschließlich Parameter- und Rückgabewert-Mapping,
– Mapping von Sollwert-Attributen und Aktionsparametern,
– Mapping von Avisierungen, die vom verwalteten System erzeugt wurden.

Zusätzlich zu einem Compiler verwendet der Prozessor 6 auch die Benutzeroberfläche 8 als Map-Modelleditor und Mapping-Definitionseditor. 4 zeigt eine Funktionsleiste 30, die von der Benutzeroberfläche 8 angezeigt wird. Diese Funktionsleiste ermöglicht es dem Benutzer, die abzubildenden Ausgangs- und Zielmodelle aus der in das System geladenen Liste von Modellen auszuwählen. Der in 4 gezeigte Bildschirm ist am Anfang einer Mapping-Session, in der ein Mapping gerade zwischen der Klasse FABRIC in Modell A und der Klasse FAB in Modell B gezeichnet wurde. Dies erfolgt einfach durch Anklicken von „Mapping erzeugen" auf der Schaltfläche und anschließendes Wählen der Ausgangs- und Zielklassen für das Mapping. Dann erscheint eine Linie, um das Mapping zu veranschaulichen, und es erscheint das Fenster auf der rechten oberen Seite der Figur. Dies wird als Assertion-Fenster bezeichnet und ermöglicht es dem Benutzer, Typ und Inhalt des Mappings vorzugeben. Normalerweise beginnt der Benutzer mit dem Vorgeben der Art des Mapping auf Klassenlevel, und dies beinhaltet in diesem Beispiel das Wählen eines Mapping als is_total oder is_subset. Es könnten andere Optionen zur Verfügung stehen, wie z. B. is_imp, is_total_rev oder is_subset_rev. Das Prädikat zum Beschreiben der Laufzeitbedingungen, unter denen die Zwillingsbeziehung gebildet wird, muss vorgegeben werden. Nach dem Anklicken der Prädikat-Schaltfläche kann das Prädikat direkt in ein Editor-Fenster eingegeben werden. In jeder Stufe während des Modellierens oder Abbildens kann der Benutzer beschließen, das System bis hinunter zu Source-Code mit dem illustrierten Menü zu kompilieren.

Zusammenfassend, der vom Prozessor 6 durchgeführte Vorgang könnte kurz in der folgenden Tabelle umrissen werden:

SCHRITT 1	Beschreiben der verwalteten Schnittstellen zu den beiden zusammenwirkenden Systemen. Diese Beschreibungen werden im Allgemeinen automatisch anhand der existierenden Systemspezifikation erzeugt. So wird beispielsweise eine Datei, die eine GDMO-Beschreibung enthält, mit einem Converter importiert, der die Spezifikation in Map konvertiert. Wenn dies nicht möglich ist, dann muss der Benutzer die verwaltete Schnittstelle manuell mit der MIU CE (Creation Environment) Modellierfunktionsleiste beschreiben.
SCHRITT 2	Beschreiben der Mappings zwischen den beiden Systemen in der Map-Sprache. Einige davon werden per Hand vorgegeben, andere können automatisch von der Creation Environment inferiert werden.
SCHRITT 3	Kompilieren der resultierenden Map-Beschreibung der Mappings bis hinunter auf Code-Schablonen für die MIU. Code-Schablonen enthalten den Umriss des endgültigen MIU-Source-Code. Sie ermöglichen es dem Benutzer zu sehen, wie dieser Code-Ausgang aussehen wird. Code-Schablonen ermöglichen es dem Benutzer auch, seinen eigenen handgeschriebenen Code zum Ergänzen des automatisch generierten Code hinzuzufügen (siehe Schritt 4).

SCHRITT 4

Handgeschriebenen Source-Code nach Bedarf hinzufügen und endgültigen Code-Ausgang generieren. Die Verwendung von Code-Schablonen bedeutet, dass selbst dann, wenn die Mappings rekompiliert werden, die handgeschriebenen Teile nicht überschrieben werden.

Die 5 und 6 zeigen die Erzeugung der MIU 10 ausführlicher. 5 zeigt die MIU in die MCFs und die ICF unterteilt. Die MCFs abstrahieren die spezifischen Einzelheiten der jeweiligen Kommunikationsprotokolle (e1 und e2). Sie verwenden einen homogenen Satz von internen generischen Management-Grundelementen, um mit der ICF über Schnittstellen i1 und i2 zu kommunizieren. Die interne Struktur der ICF, die zum Bewirken der Mappings zwischen Systemen zur Laufzeit verwendet wird, ist wichtig. Zweck der MIU CE (Creation Environment) ist es, Unterstützung für einen Prozess zum Aufbauen des ICF-Teils einer MIU bereitzustellen. Das interne Protokoll, das die internen Referenzpunkte 11 und 12 überquert, beinhaltet die folgenden Grundelemente:

GET	Get ist für objektgestützte Modelle spezifisch und ruft den Wert eines Attributs ab. Dies ist analog zum CMIS M-GET Service-Element.
SET	Set ist für objektgestützte Modelle spezifisch und legt den Wert eines Attributs fest. Dies ist analog zum CMIS M-SET Service-Element.
CREATE	Create ist für objektgestützte Modelle spezifisch und erzeugt eine neue Objektinstanz. Dies ist analog zum CMIS M-CREATE Service-Element.
DELETE	Delete ist für objektgestützte Modelle spezifisch und löscht eine Objektinstanz. Dies ist analog zum CMIS M-DELETE Service-Element.
FUNCTION	Function ruft eine Funktion über die Schnittstelle ab. Eine solche Funktion könnte eine CMIS M-ACTION oder ein MML-Befehl an eine verwaltete Ressource sein. Function kann synchron sein und wartet dann auf das Ergebnis der Funktion, oder asynchron, d. h. wartet nicht.
NOTIFY	Notify fängt einen Event-Report von der Schnittstelle ab. Ein solcher Event-Report könnte einem CMIS M-EVENT-REPORT

	oder einer asynchronen Meldung von der verwalteten Ressource entsprechen.
RECEIVE	Receive ermöglicht es der ICF, Daten von der Schnittstelle zu empfangen. Dies könnte dort verwendet werden, wo die ICF eine asynchrone Antwort von einer externen Entität erwartet. Das Receive-Grundelement blockiert die auf die Antwort wartende ICF.
START_MIU_TRANSACTION	Dieses Grundelement ermöglicht den Aufruf eines Satzes von Grundelementen als atomare Transaktion. Wenn ein Fehler während einer der Operationen auftritt, aus denen sich die Transaktion zusammensetzt, dann kann die vorherige Operation rückgängig gemacht werden, um in den vorherigen Zustand zurückzukehren.
END_MIU_TRANSACTION	Dieses Grundelement bedeutet das Ende der Transaktion und zeigt an, dass die Transaktion erfolgreich ist und committet werden soll.
ABORT_MIU_TRANSACTION	Dieses Grundelement dient zum Beenden einer Transaktion, in der eine der Operationen erfolglos war. Dies dient zum Zurückrollen aller Operationen, die während der Transaktion durchgeführt wurden, und zum Zurückbringen des Systems in seinen vorherigen Zustand.

Die MCFs führen die Formatkonvertierung in diese Grundelemente von dem relevanten externen Protokoll anhand von festcodierten Regeln durch.
Die MIU stellt die Laufzeitunterstützung bereit, die für eine Systemzusammenwirkung notwendig ist. Um die Mappings zu bewirken, unterstützt die MIU-Architektur einige besondere Laufzeitstrukturen, wie z. B:

– Eine Zwillingstabelle – Unter Anbetracht einer Referenz auf ein Objekt in der MIU gibt diese eine Referenz auf das äquivalente Objekt in den verwalteten Systemen zurück und umgekehrt.
– Eine erwartete Events-Warteschlange – Diese enthält eine Liste von Events, die erwartet werden, wann sie ankommen sollen und welche Maßnahme ergriffen werden soll, wenn sie ankommen.

Der Map-Compiler erzeugt Source-Code für diese Strukturen und alle zugehörigen Mappings. Nach Bedarf kann die MIU so erzeugt werden, dass sie ihre Objekte ständig unter Verwendung einer Datenbank speichert. Der Schlüssel zum Map-Compiler ist, dass er Flexibilität im Hinblick auf den Source-Code-Typ bietet, den er ausgibt. Der Benutzer kann ,Tags' in den Map-Code einfügen, so dass er Teile von handgeschriebenem Source-Code einbeziehen kann. Dies bedeutet, dass selbst dann, wenn die Mappings geändert werden, die handgeschriebenen Source-Code-Annotationen des Benutzers nicht überschrieben werden. Die Möglichkeit einer flexiblen Code-Erzeugung ist ein großer Vorteil. Die Erfindung erfordert keine kostspielige proprietäre Laufzeitumgebung, weil sie potentiell Code erzeugen kann, der in eine Reihe verschiedener Laufzeitumgebungen passt, oder ansonsten eine ,leichte' eigenständige Laufzeit-MIU bereitstellen kann.
Die MCF- und ICF-Komponenten der MIU 10 verwenden CORBA IDL (RTM) Schnittstellen zum Kommunizieren mit anderen Komponenten. Diese Schnittstellen basieren auf Grundelementen zum Abrufen und Einstellen von Werten von Attributen, Erzeugen und Löschen von Objektinstanzen, Involvieren einer Funktion über die Schnittstelle, Event-Reporting, Ermöglichen, dass die ICF wartet, bis vorgegebene Daten von der Schnittstelle empfangen werden, so dass ein Satz von Grundelementen als automatische Transaktion aufgerufen werden kann, Denotieren des Endes der Transaktion und Zurückrollen einer Transaktion.
Es kann zusätzlich Grundelemente für einen Start geben. Wie aus 3 hervorgeht, enthält jedes der Komponentenobjekte wenigstens einen Prozess und es gibt auch einen Server-Prozess für das DBMS (Database Management System). Sowohl die verwalteten als auch die verwaltenden ICFs sind DBMS-Clients und manipulieren die verwalteten Objekte in der MIB (Management Information Base), die im DBMS gespeichert ist. Sowohl die verwaltenden als auch die verwalteten ICF-Server dienen als eigene Datenbank-Clients und sind somit unabhängig voneinander.
Wieder mit Bezug auf 6, dort sind die Prozesse und IDL-Schnittstellen der MIU 10 illustriert. Die ICF 11 dient als Dispatcher für die verwalteten und die verwaltenden ICF-Schnittstellen. Eine MCF 12 ist nicht zulässig, um direkt mit entweder den verwalteten oder den verwaltenden ICF-Schnittstellen zu assoziieren, sondern sie assoziiert stattdessen mit der ICF-Schnittstelle, die dann eine Referenz zu den entsprechenden verwalteten oder verwaltenden ICF-Schnittstellen zurückleitet. Dies erfolgt, um zu gewährleisten, dass die MCFs in einer MIU mit den richtigen Schnittstellen assoziiert sind.
Man wird verstehen, dass die Erfindung ein Verfahren zum Erzeugen einer MIU bereitstellt, die die Aufgabe in einem hohen Maß automatisiert und gleichzeitig ein hohes Maß an Benutzerinteraktion zulässt, um die notwendige Flexibilität bereitzustellen. Die Struktur der Modelle sowie die Art und Weise, in der die Mappings erzeugt werden, ermöglichen das Ausmaß an Automation und ergeben zusätzlich eine einfache Struktur, die der Benutzer für eine manuelle Annotation und spätere Modifikation leicht verstehen kann. Ferner kann die Struktur der MIU, da sie sehr einfach ist, leicht modifiziert werden, um entweder Änderungen der Managementschnittstellen zu berücksichtigen, die bereits zusammenwirken, oder um zusätzliche Zusammenwirkungsfähigkeit hinzuzufügen. Die Tatsache, dass die Formatkonvertierung vom externen auf das interne Protokoll von den MCFs separat von der ICF durchgeführt wird, ist ein wichtiges Merkmal, da es zu einer deutlichen Grenze zwischen den MCFs und der ICF führt. Ferner ist innerhalb der ICF die Modell- und Mapping-Struktur relativ einfach und erlaubt eine leichte Modifikation.
Die Erfindung ist nicht auf die oben beschriebenen Ausgestaltungen begrenzt, sondern kann im Hinblick auf Aufbau und Detail variieren.

Claims

Verfahren zum Erzeugen einer Management Interworking Unit (MIU = Managementzusammenwirkungseinheit) (10) für ein Paar Managementschnittstellen, umfassend die folgenden Schritte: Erzeugen einer Informationskonvertierungsfunkton ICF (11) durch: Speichern eines Informationsmodells (4, 5), das mit jeder Managementschnittstelle assoziiert ist, wobei jedes Informationsmodell Objekte umfasst, die verwaltete Betriebsmittel repräsentieren, und Erzeugen von Mappings mit Laufzeitkonvertierungsfunktionen zwischen äquivalenten Teilen der Informationsmodelle; und Generieren einer Nachrichtenkommunikationsfunktion MCF (12), die mit jeder Managementschnittstelle assoziiert ist, wobei jede MCF (12) Mittel zum Durchführen von Formatkonvertierung zwischen dem externen Protokoll der assoziierten Schnittstellen und einem internen Protokoll für die ICF umfasst, dadurch gekennzeichnet, dass: jedes Informationsmodell (4, 5) Objekte in einer Containment-Hierarchie umfasst, die einen Containment-Kontext für jedes Objekt bereitstellt, und jedes Objekt eine Klasse hat, die durch Charakteristiken unabhängig vom Kontext definiert wird; und die Mappings zwischen individuellen Objekten und zwischen Gruppen von Objekten mit der-/demselben Klasse und Kontext sind, d. h. Kontextklassen.
Verfahren nach Anspruch 1, bei dem die Modelle wenigstens teilweise automatisch durch Ladermodule erzeugt werden.
Verfahren nach Anspruch 1 oder 2, bei dem die Modelle (4, 5) von Managementschnittstellenspezifikationen erzeugt werden und spezifikationsfreier Text manuell in die Modellsprache konvertiert wird.
Verfahren nach einem der vorherigen Ansprüche, bei dem die Mappings Kontextklassenkardinalität definieren.
Verfahren nach Anspruch 4, bei dem Mappings zwischen Kontextklassen erzeugt werden.
Verfahren nach Anspruch 4 oder 5, bei dem Mappings zwischen Objekten erzeugt werden.
Verfahren nach den Ansprüchen 4 bis 6, bei dem Mappings zwischen Objektcharakteristiken erzeugt werden.
Verfahren nach Anspruch 7, bei dem die Objektcharakteristiken Objektfunktionen, Beziehungen, Attribute, Avisierungen und Verhalten beinhalten.
Verfahren nach einem der vorherigen Ansprüche, bei dem die Mappings interaktiv unter Verwendung einer grafischen Schnittstelle (8) erzeugt werden, die die Modelle und die Mappings repräsentiert.
Verfahren nach einem der vorherigen Ansprüche, bei dem die Mappings durch für die Mappings gewählte Laufzeitregeln prädikatiert werden.
Verfahren nach einem der vorherigen Ansprüche, das den weiteren Schritt des Vorkompilierens der Modelle und der Mappings zu einer Schablone zum Produzieren von Source-Code beinhaltet.
Verfahren nach Anspruch 11, bei dem die Schablone nach dem Vorkompilieren manuell modifiziert wird und Flags in der Schablone gesetzt werden, um zwischen automatisch generiertem Code und manuell generiertem Code zu unterscheiden.
Verfahren nach einem der vorherigen Ansprüche, bei dem Suchläufe durchgeführt werden, um zu ermitteln, ob ein vorgeschlagenes Mapping zuvor für ähnliche Charakteristiken durchgeführt wurde, und solche Mappings können wiederverwendet werden.
Management Interworking Unit (MIU = Managementzusammenwirkungseinheit) (10) für ein Paar Managementschnittstellen, die Folgendes umfasst: eine Informationskonvertierungsfunkton ICF (11), die Folgendes umfasst: ein Informationsmodell (4, 5), das mit jeder Managementschnittstelle assoziiert ist, wobei jedes Informationsmodell Objekte umfasst, die verwaltete Betriebsmittel repräsentieren, und Laufzeitkonvertierungsmappings zwischen äquivalenten Teilen der Informationsmodelle; und eine Nachrichtenkommunikationsfunktion MCF (12), die mit jeder Managementschnittstelle assoziiert ist, wobei jede MCF (12) Mittel zur Durchführung von Formatkonvertierung zwischen dem externen Protokoll der assoziierten Schnittstellen und einem internen Protokoll für die ICF umfasst, dadurch gekennzeichnet, dass: jedes Informationsmodell (4, 5) Objekte in einer Containment-Hierarchie umfasst, die einen Containment-Kontext für jedes Objekt bereitstellt, und jedes Objekt eine Klasse hat, die durch Charakteristiken unabhängig vom Kontext definiert wird; und die Mappings zwischen individuellen Objekten und zwischen Gruppen von Objekten mit der-/demselben Klasse und Kontext sind, d. h. Kontextklassen.
Management Interworking Unit nach Anspruch 14, bei der die Mappings Kontextklassenkardinalität definieren.
Management Interworking Unit nach den Ansprüchen 14 und 15, wobei Mappings Kontextklassen verbinden.
Management Interworking Unit nach einem der Ansprüche 14 bis 16, wobei Mappings Objekte verbinden.
Management Interworking Unit nach einem der Ansprüche 14 bis 17, wobei Mappings Objektcharakteristiken verbinden.
Management Interworking Unit nach Anspruch 18, wobei die Objektcharakteristiken Objektfunktionen oder Aktionen, Beziehungen, Attribute, Avisierungen und Verhalten beinhalten.
Management Interworking Unit nach einem der Ansprüche 14 bis 19, wobei Mappings durch für die Mappings gewählte Laufzeitregeln prädikatiert werden.
Management Interworking Unit nach einem der Ansprüche 14 bis 20, wobei das interene Protokoll Grundelemente beinhaltet, die Start, Ende und Rollback von atomaren Transaktionen in der ICF (11) steuern.