DE10121671A1

DE10121671A1 - Bereitstellung einer Schnittstelle von einer Dienstkomponente zu einer maschinenspezifischen API

Info

Publication number: DE10121671A1
Application number: DE10121671A
Authority: DE
Inventors: Mark Skrzynski; Huy Ton
Original assignee: Siemens Information and Communication Networks Inc
Current assignee: Siemens Communications Inc
Priority date: 2000-05-31
Filing date: 2001-05-04
Publication date: 2002-01-10
Also published as: GB0113062D0; US6691302B1; GB2367926A

Abstract

Es werden Systeme und Verfahren zur Bereitstellung einer Schnittstelle von einer Dienstkomponente (80, 82, 84), die in einer beliebigen von verschiedenen Programmiersprachen geschrieben ist, zu einer Anwendungsprogrammschnittstelle (API) (64) eines maschinenspezifischen Betriebssystems beschrieben. Zum Beispiel wird bei einer Ausführungsform eine generische Schnittstelle (104, 105) zwischen der Win32-API (Anwendungsprogrammschnittstelle) (64) und Windows-NT-Dienstkomponenten (80, 82, 84) bereitgestellt, die in C, C++ und JAVA geschrieben sind. Gemäß einem Aspekt ist ein Schnittstellenmodul (104, 105) so konfiguriert, dass es eine Dienstkomponente lädt, die nicht in einer maschinenspezifischen Programmiersprache geschrieben ist. Gemäß einem anderen Aspekt ist ein Schnittstellenmodul (104, 105) so konfiguriert, dass es Dienstkomponenteninformationen aus einer Konfigurationsdatenbank (63) abruft.

Description

VERWEIS AUF SACHVERWANDTE ANMELDUNGEN

Die vorliegende Anmeldung ist verwandt mit der U.S.-Anmeldung Nr. 09/586,557 mit dem Titel: "Hierarchical Dependability for Open Distributed Environments", eingereicht von Mark Skrzynski und Vijay K. Misra am selben Datum wie die vorlie gende Schrift. Auf diese Anmeldung wird hiermit ausdrücklich Bezug genommen.

TECHNISCHES GEBIET

Die vorliegende Erfindung betrifft Systeme und Verfahren zur Bereitstellung einer Schnittstelle von einer Dienstkomponente zu einer Anwendungsprogrammschnittstelle (application program interface = API) eines maschinenspezifischen Betriebssystems (native operating system).

HINTERGRUND

Ein Computersystem enthält in der Regel ein Betriebssystem, das eine Umgebung bereitstellt, in der ein oder mehrere An wendungsprogramme ablaufen können. Das Betriebssystem steuert im allgemeinen den Betrieb des Computersystems und die Zutei lung von Systemressourcen. Das Betriebssystem bietet den An wendungsprogrammen außerdem Systemdienste, die ihrerseits diese Dienste zur Durchführung einer oder mehrerer Datenver arbeitungsaufgaben ( = computing tasks) benutzen. Bei dem Be triebssystem Windows NT Server stellt zum Beispiel ein Win32- Subsystem Anwendungsprogrammen eine 32-Bit- Anwendungsprogrammschnittstelle (API) zur Verfügung. Zu typi schen Betriebssystemdiensten (operating System services) ge hören Speicherdienste, Prozesserzeugungsdienste und Verarbei tungsablauf-Steuerungsdienste.

Betriebssysteme wie zum Beispiel das Betriebssystem Windows NT Server verwenden sehr häufig dynamisch verknüpfte Biblio theken. Eine dynamisch verknüpfte Bibliothek (Dynamic Link Library = DLL) ist ein Computercodemodul, das Funktionen enthält, die mit einem Anwendungscode verknüpft werden sol len. Eine DLL kann während der Laufzeit geladen und mit einer Anwendung verknüpft werden, und wenn ihre Funktionen nicht mehr gebraucht werden, kann man sie wieder herausladen. Eine DLL besteht gewöhnlich aus einer Menge autonomer Funktionen, die von einer beliebigen Anwendung benutzt werden können. Bei 32-Bit-Windows-Betriebssystemen, wie zum Beispiel Windows NT, Windows 95 und Windows CE, sind alle Funktionen der Win32-API in DLLs enthalten. Weitere Einzelheiten bezüglich der Win32- API findet man in "Advanced windows", dritte Auflage, Jeffrey Richter, Microsoft Press (1997), worauf hiermit ausdrücklich Bezug genommen wird.

In der 32-Bit-Windows-Umgebung muss eine Anwendung (oder eine andere DLL), um die Systemdienstfunktionen der Win32-API auf zurufen, einer standardmäßigen, auf C basierenden Schnitt stelle entsprechen. Folglich werden die meisten Dienstkompo nenten, die in einer 32-Bit-Windows-Umgebung ablaufen, in der Programmiersprache C oder C++ geschrieben. Um die Funktionen von Dienstkomponenten aufzurufen, die in anderen Programmier sprachen geschrieben sind, muss jede Komponente ihre eigene angepasste Betriebsumgebung bereitstellen, in der die Kompo nente ablaufen kann. Zum Beispiel müssen in der Programmier sprache JAVA geschriebene Programme in einer von einer virtu ellen JAVA-Maschine (Java virtual machine = JVM) bereitge stellten Umgebung ablaufen. Die JVM ist eine abstrakte ma schinenspezifische Datenverarbeitungsmaschine, die in einem Betriebssystem abläuft, um JAVA-Anwendungen zu interpretieren und auszuführen. Weitere Einzelheiten bezüglich der JVM fin det man in "The Java™" Virtual machine Specification", Tim Lindholm und Frank Yellin, Addison Wesley (1997), worauf hiermit ausdrücklich Bezug genommen wird.

KURZE DARSTELLUNG

Die Erfindung umfasst Systeme und Verfahren zur Bereitstel lung einer Schnittstelle von einer Dienstkomponente (service component), die in einer beliebigen von verschiedenen Pro grammiersprachen geschrieben ist, zu einer Anwendungspro grammschnittstelle eines maschinenspezifischen Betriebssy stems. Gemäß einem Aspekt umfasst die Erfindung ein Schnitt stellenmodul, das so konfiguriert ist, dass es eine Dienst komponente lädt, die nicht in einer maschinenspezifischen Programmiersprache (native programming language) geschrieben ist. Gemäß einem weiteren Aspekt umfasst die Erfindung ein Schnittstellenmodul, das so konfiguriert ist, dass es Dienst komponenteninformationen aus einer Konfigurationsdatenbank abruft.

Ausführungsformen können eines oder mehrere der folgenden Merkmale aufweisen.

Das Schnittstellenmodul ist vorzugsweise so konfiguriert, dass es eine Anwendungsbetriebsumgebung erzeugt, in der die Dienstkomponentenanwendung ablaufen kann. Zum Beispiel ist das Schnittstellenmodul bei einer Ausführungsform so konfigu riert, dass es eine virtuelle JAVA-Maschine zur Ausführung einer Dienstkomponentenanwendung erzeugt, die in einer JAVA- Programmiersprache geschrieben ist. Das Schnittstellenmodul ist vorzugsweise so konfiguriert, dass es die Anwendungsbe triebsumgebung und die Dienstkomponentenanwendung bei der Ausführung als einen einzigen Prozess behandelt. Insbesondere ist das Schnittstellenmodul vorzugsweise so konfiguriert, dass es eine Anwendungsroutine erzeugt, auf dem die Anwen dungsbetriebsumgebung erzeugt werden kann. Das Schnittstel lenmodul kann so konfiguriert werden, dass es eine Hauptrou tine zur Überwachung und zum Blockieren der Anwendungsroutine erzeugt.

Das Schnittstellenmodul wird vorzugsweise so konfiguriert, dass es Dienstkomponenteninformationen aus einer Konfigurati onsdatenbank abruft. Das Schnittstellenmodul kann so konfigu riert sein, dass es aus der Konfigurationsdatenbank die Iden tität einer auszuführenden Dienstkomponentenanwendung abruft. Das Schnittstellenmodul ist vorzugsweise so konfiguriert, dass es die identifizierte Dienstkomponentenanwendung lädt, startet und steuert und Informationen über den Laufzeit- Status der Komponentenanwendung erhält.

Das Schnittstellenmodul enthält vorzugsweise eine dynamisch verknüpfte Bibliothek (DLL) der Dienstkomponentenschnittstel len. Bei einer Ausführungsform ist das Schnittstellenmodul unter dem Betriebssystem Windows NT Server betreibbar und ist so konfiguriert, dass es eine Schnittstelle von einer Win32- API zu Dienstkomponenten bereitstellt, die in den Program miersprachen C, C++ oder JAVA geschrieben sind.

Die Erfindung bietet die folgenden Vorteile.

Die Erfindung liefert eine generische Schnittstelle zwischen einer API eines maschinenspezifischen Betriebssystems und Dienstkomponenten, die in verschiedenen Programmiersprachen (z. B. C, C++ und JAVA) geschrieben sind. Durch Trennung der Dienstfunktionen von anderen Aspekten des Systems ermöglicht die Erfindung Entwicklern, Dienste leichter und mit größerer Flexibilität zu erzeugen. Außerdem können Dienste, die gemäß der Erfindung entwickelt werden, leichter gewartet und ge prüft werden, da die Dienstwartung und -prüfung getrennt von anderen Komponenten des Systems durchgeführt werden kann. Zum Beispiel kann ein Verlässlichkeitssystem (dependability sy stem), das mit gemäß der Erfindung entwickelten Diensten im plementiert wird, ersetzt oder aktualisiert werden, ohne die zugrundeliegenden Dienstmodule zu modifizieren. Außerdem können neue Dienste ohne weiteres zu dem System hinzugefügt werden, ohne das Verlässlichkeitssystem zu ändern. Zum Bei spiel muss ein Systementwickler mit der Erfindung nur die entsprechende DLL- oder JAVA-Klasse durch ein neues Dienstmo dul ersetzen, das die gewünschten Funktionen implementiert. Durch die erfindungsgemäße Verwendung der System- Konfigurationsdatenbank (Registry) können Systementwickler ohne weiteres Dienstfunktionen mit bestehenden Dienstmodulen implementieren, ohne die Programmiersprachen zu beachten, mit denen die Dienstmodule erzeugt wurden. Die Erfindung erlaubt es Entwicklern außerdem, Dienstmodule zu erzeugen, ohne sich um die Einzelheiten der maschinenspezifischen Schnittstelle kümmern zu müssen.

Weitere Merkmale und Vorteile der Erfindung werden aus der folgenden Beschreibung in Verbindung mit den Zeichnungen und den Ansprüchen deutlich.

BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockschaltbild eines Computernetzwerks mit einem Server-Computer und zwei abgesetzten Computern.

Fig. 2 ist ein Blockschaltbild einer durch den Server-Compu ter von Fig. 1 bereitgestellten Dienstmodul ausführungsumgebung.

Fig. 3A und 3B sind Diagramme von Dienstmodulen mit Dienst komponenten, die in den Programmiersprachen C/C++ bzw. JAVA geschrieben wurden.

Fig. 4 ist ein Flussdiagramm eines Verfahrens zur Bereitstel lung einer Schnittstelle von einer Dienstkomponente zu einer maschinenspezifischen API.

AUSFÜHRLICHE BESCHREIBUNG

Bezugnehmend auf Fig. 1 kann bei einer Ausführungsform das erfindungsgemäße Schnittstellenmodul in einer verteilten Da tenverarbeitungsumgebung implementiert werden, die einen Ser vercomputer 10 und einen oder mehrere abgesetzte Computer 12, 13 enthält. Der Servercomputer 10 enthält eine Verarbeitungs einheit 14, einen Systemspeicher 16 und einen Systembus 18, der die Verarbeitungseinheit 14 an die verschiedenen Kompo nenten des Servercomputers 10 ankoppelt. Die Verarbeitungs einheit 14 kann einen oder mehrere Prozessoren enthalten, die jeweils in Form beliebiger verschiedener handelsüblicher Pro zessoren vorliegen können. Der Systemspeicher 16 enthält ei nen Nur-Lese-Speicher (ROM) 20, der ein einfaches Eingabe- /Ausgabesystem (basic input/output system = BIOS) speichert, das Start-Up-Routinen für den Servercomputer 10 speichert, und einen Direktzugriffsspeicher (RAM) 22. Der Systembus 18 kann ein Speicherbus, ein Perpheriebus oder ein lokaler Bus sein und kann mit beliebigen verschiedenen Busprotokollen, wie zum Beispiel PCI, VESA, Microchannel, ISA und EISA, kom patibel sein.

Der Server-Computer 10 enthält außerdem ein Plattenlaufwerk 24, ein Diskettenlaufwerk 26 und ein CD-ROM-Laufwerk 28, die durch jeweilige Schnittstellen 30, 32, 34 mit dem Systembus 18 verbunden sind. Das Plattenlaufwerk 24, das Diskettenlauf werk 26 und das CD-ROM-Laufwerk 28 enthalten jeweilige compu terlesbare Medienplatten 36, 38, 40, die eine nichtflüchtige Speicherung für Daten, Datenstrukturen und computerausführba re Befehle bereitstellen. Es können auch andere computerles bare Speichergeräte mit dem Servercomputer 10 verwendet wer den (z. B. Magnetbandlaufwerke, Flash-Speichergeräte und DVD- Disks). Ein Benutzer kann über eine Tastatur 42 und einer Maus 44 mit dem Servercomputer 10 kommunizieren (z. B. Befehle oder Daten eingeben). Außerdem können weitere Eingabegeräte bereitgestellt werden (z. B. ein Mikrofon, Joystick oder Touchpad). Informationen können auf einem Monitor 46 dem Be nutzer angezeigt werden. Der Servercomputer 10 kann außerdem Ausgabe-Peripheriegeräte, wie zum Beispiel Lautsprecher und einen Drucker, enthalten.

Die abgesetzten Computer 12, 13 können Workstations, Server computer, Router, Peer-Geräte oder andere gemeinsame Netz werkknoten sein. Der abgesetzte Computer 12 kann über ein lo kales Netzwerk (local area network = LAN) 48 mit dem Server computer 10 vernetzt sein, und der abgesetzte Computer 13 kann über ein Fernnetz (wide area network = WAN) 50 (z. B. das Internet) vernetzt sein.

Bezugnehmend auf Fig. 2 können auf den Speichergeräten 24-28 und in dem RAM 20 mehrere Programmmodule gespeichert werden, darunter ein Betriebsystem 60 (z. B. das von dar Microsoft Corporation in Redmond, Washington, USA, erhältliche Be triebssystem Windows NT Server), ein oder mehrere Anwendungs programme und Programmdaten. Das Betriebsystem 60 enthält ein Executive-Modul 62, das die Basis-Betriebssystemdienste (z. B. Speichermanagement, Prozess- und Routinemanagement (thread management), Sicherheit, Eingabe/Ausgabe und die Kommunikati on zwischen Prozessen) zur Erzeugung einer Laufzeit- Ausführungsumgebung (run-time execution environment) auf dem Servercomputer 10 bereitstellt. Eine Konfigurationsdatenbank (Registry) 63 enthält die folgenden Informationen: Parameter, die zum Booten und Konfigurieren des Systems benötigt werden; systemweite Software-Einstellungen, die den Betrieb des Be triebsystems 60 steuern; eine Sicherheitsdatenbank; und Pro fileinstellungen für jeden Benutzer. Eine Anwendungsprogramm schnittstelle (API) 64 des maschinenspezifischen Betriebssy stems (OS) stellt Benutzeranwendungen und einem oder mehreren Dienstmodulen (oder einfach "Diensten") 66, 68, 70 die Basis- Betriebssystemdienste des Executive-Moduls 62 zur Verfügung. Der Ausdruck "Dienst" (oder "Dienstmodul") bezeichnet eine Komponente eines Betriebssystems, die eine Menge aus einer oder mehreren Funktionen bereitstellt. Die Dienstmodule 66-70 sind Prozesse des Benutzermodus, die so konfiguriert werden können, dass sie automatisch beim Booten des Systems starten, ohne eine interaktive Anmeldung zu erfordern; sie können auch dynamisch während der Laufzeit gesteuert werden. Die Dienst module 66-70 rufen bestimmte Basis-Betriebssystemdienste (oder Funktionen) auf, um einen Dialog mit der Dienststeue rung 72 zu führen; solche Funktionen sind z. B. das Registrie ren eines erfolgreichen Startvorgangs, das Reagieren auf Sta tusanforderungen und das Suspendieren oder Herunterfahren des Dienstes. Die Dienststeuerung 72 startet, verwaltet und lenkt Operationen in den Dienstmodulen 66-70. Die Dienstmodule 66-70 erzeugen dagegen die Umgebung, in der einer oder mehrere Prozesse ablaufen können, und steuern das Herauffahren, War ten und Beenden solcher Prozesse. Die Laufzeit-Ausführungs umgebung wird in der Regel auf dem Servercomputer 10 instal liert und ein oder mehrere Client-Programme 74, 75, die auf den abgesetzten Computern 12, 13 ablaufen, können über ihre jeweiligen Netzwerkverbindungen auf die von den Dienstmodulen 66-70 bereitgestellten Funktionen zugreifen. Bei einer alter nativen Ausführungsform kann die Laufzeit-Ausführungsumgebung auf einem einzigen Computer installiert werden, der sowohl für die Dienstmodule 66-70 als auch die Client-Programme 74, 75 der Host ist.

Bevor ein Dienstmodul 66-70 in der Laufzeit-Ausführungs umgebung ablaufen kann, muss es auf dem Servercomputer 10 in stalliert werden. Ein Dienstmodul wird in der Regel dadurch installiert, dass das Dienstmodul in einem Datenspeicherbe reich, der dem Servercomputer 10 zugänglich ist (z. B. auf der Platte 36 in dem Plattenlaufwerk 24), gespeichert wird und die Attribute des Dienstmoduls in der Konfigurationsdatenbank 63 registriert werden. Bei einer Ausführungsform folgt jeder Dienst 66-70 einer standardmäßigen Prozedur und implementiert eine standardmäßige Schnittstelle, durch die der Dienst über wacht und ferngesteuert werden kann. Zu diesem Zweck enthält jedes Dienstmodul ein Schnittstellenmodul, dass eine Schnitt stelle zwischen der Basis-Betriebssystem-API und einer Dienstkomponente bereitstellt, die die Funktionen des Dien stes implementiert. Insbesondere implementiert das Schnitt stellenmodul Funktionen, durch die das Dienstmodul als ein Dienst installiert und gewartet werden kann. Zum Beispiel muss das Schnittstellenmodul in einem System, das unter Win dows NT abläuft, eine DIENSTTABELLENEINTRAGSSTRUKTUR (SERVICE TABLE ENTRY STRUCTURE) initialisieren. Das Schnittstellenmo dul ruft dann einen StartServiceCtrlDispatcher auf, um seine Sub-Dienste und deren Eintrittspunktfunktionen zu registrie ren. Beim Start jedes Dienstes wird seine Eintrittspunktfunk tion (entry point function) aufgerufen. Die Eintrittspunkt funktion ruft die Funktion RegisterServiceCtrlHandler auf, um einen Steuerungstreiber (control handler) zu registrieren, durch den der Dienst auf Steueranforderungen (z. B. Dienst Starten, Dienst Stoppen und Statusanfrage) von der Dienst steuerung 72 reagieren kann. Das Schnittstellenmodul defi niert und behandelt außerdem bestimmte Verlässlichkeitsmit teilungen, durch die die Dienste Statusinformationen austau schen und sich gegenseitig steuern können. Weitere Einzelhei ten bezüglich des Betriebsystems Windows NT findet man in "Inside Windows NT", zweite Auflage, David A. Solomon, Micro soft Press (1998), worauf hiermit ausdrücklich Bezug genommen wird.

Wie in Fig. 3A und 3B zu sehen ist, können die Funktionen der Dienstmodule 66-70 durch jeweilige Dienstkomponenten 80, 82, 84 bereitgestellt werden, die in verschiedenen Programmier sprachen (z. B. C, C++ und JAVA) geschrieben sind, von denen mindestens eine von der Programmiersprache, die von der API 64 des maschinenspezifischen Betriebssystems unterstützt wird, verschieden sein kann. Jeder Dienstkomponente 80-84 ist ein Schnittstellenmodul zugeordnet, dass die zugeordnete Dienstkomponente 80-84 lädt und startet, indem es die notwen dige Eintrittsfunktion bereitstellt, und die zugeordnete Dienstkomponente steuert, indem es eine Funktion einrichtet, durch die andere Prozesse einen Dialog mit der Dienstkompo nente führen können (z. B. durch Weitergeben von Steuercodes wie zum Beispiel Start, Stop, Herunterfahren). Jedes Schnitt stellenmodul enthält ein Dienst-Stub-Modul 92, 94, 96, das eine jeweilige Schnittstelle 98, 100, 102 zu der API des ma schinenspezifischen Betriebssystems (OS)(z. B. der Win32-API für das Betriebssystem Windows NT) und eine Dienstkomponen tenschnittstelle 104, 105 bereitstellt, die die zugeordnete Dienstkomponente 80-84 lädt, startet und steuert. Jedes Dienst-Stub-Modul 92-96 implementiert eine Funktion Service- Main und enthält einen festcodierten Dienstnamen, der den Re gistry-Schlüssel für den Dienst und die Programmiersprache, in der die Dienstfunktionen implementiert sind, identifi ziert. Im Betrieb registrieren die Dienst-Stub-Module 92-96 die Dienstkomponenten 66-70 bei dem Betriebsystem 60 als Dienste und laden die Dienstkomponentenschnittstellen 104, 105. Die Dienst-Stub-Module 92-96 können in C++ geschrieben werden und die folgende Form aufweisen:

Jede Dienstkomponentenprogrammiersprache wird von einer je weiligen Dienstkomponentenschnittstelle 104, 105 unterstützt (z. B. die Dienstkomponentenschnittstelle 104 unterstützt in C/C++ geschriebene Dienstkomponenten und die Dienstkomponen tenschnittstelle 105 unterstützt in JAVA geschriebene Dienst komponenten). Bei einer Ausführungsform wird jedes ausführba re Modul 104 der Dienstkomponentenschnittstelle als eine DLL (Dynamic Link Library) implementiert. Im Betrieb lesen die Dienstkomponentenschnittstellen 104, 105 den Namen der zuge ordneten Dienstkomponenten 80-84 aus dem dienstspezifischen Bereich der Konfigurationsdatenbasis 63 und laden und starten die identifizierte Dienstkomponente 80-84 (z. B. Initialisie ren von Daten, Erzeugen von Warteschlangen und Abwickeln von Steuernachrichten). Jede Dienstkomponentenschnittstelle 104, 105 ist so konfiguriert, dass sie Dienstkomponenten lädt, startet und steuert, die in einer jeweiligen Programmierspra che (z. B. C/C++ und JAVA) geschrieben sind. In der Be triebsumgebung von Windows NT ist die API des maschinenspezi fischen OS (d. h. die Win32-API) in C/C++ geschrieben. In Be zug auf die in C/C++ geschriebenen Dienstkomponenten 80, 82 muss die Dienstkomponentenschnittstelle 104 folglich einfach die entsprechende Eintrittsfunktion aufrufen, um diese Dien ste unter-Windows NT zu laden und zu starten. Die Komponen tenschnittstelle 104 liefert außerdem Call-Back-Funktionen, die die Dienstkomponenten 80, 82 als Funktionsaufrufe aufru fen können. Die C/C++-Dienstkomponentenschnittstelle 104 kann in C++ geschrieben sein und die folgende Form aufweisen.

Bezüglich Dienstkomponenten, die eine andere Betriebsumgebung erfordern (z. B. die JAVA-Dienstkomponente 84) behandelt die Dienstkomponentenschnittstelle 105 die andere Betriebsumge bung (z. B. die virtuelle JAVA-Maschine) und den Prozess (z. B. die JAVA-Dienstkomponente), der in dieser Umgebung abläuft, als einen einzigen Prozess, um eine generische Schnittstelle zu der API des maschinenspezifischen OS bereitzustellen. Zum Beispiel lädt die Dienstkomponentenschnittstelle 105 eine in der Programmiersprache JAVA geschriebene Dienstkomponente, indem sie zuerst eine virtuelle JAVA-Maschine (JVM) erzeugt und anschließend die JAVA-Dienstkomponente unter der JVM auf ruft. Durch die JVM kann die Dienstkomponentenschnittstelle 105 Methoden aufrufen und mit javai.dll auf die Datenelemente der JAVA-Dienstkomponente zugreifen. Eine JAVA- Dienstkomponente kann eine maschinenspezifische Methode (z. B. eine DLL in C++), durch die die Dienstkomponentenschnittstel le Änderungen des Status der JAVA-Dienstkomponente überwachen kann, laden und implementieren. Die JAVA-Dienstkomponenten schnittstelle 105 kann in C++ geschrieben werden und kann die folgende Form aufweisen:

Die Dienstkomponentenschnittstelle 105 enthält außerdem ma schinenspezifische "Call Back"-Methoden, und ein Aufruf zu diesen maschinenspezifischen Methoden kehrt auch dann zu der selben Dienstkomponentenschnittstelle zurück, wenn die zuge ordnete Dienstkomponente in JAVA geschrieben ist, weil die JVM in der Dienstkomponentenschnittstelle erzeugt wird (d. h. im selben Kontext). Bei einer Ausführungsform wird, um die Implementierung einer Dienstkomponentenschnittstelle 105 für jeden Dienst zu vermeiden, eine Klasse CallBackClass bereit gestellt, die alle maschinenspezifischen Methoden deklariert; alle Dienste, die in die Dienstkomponentenschnittstelle auf rufen, rufen die maschinenspezifischen Methoden der CallBack- Class auf. Dieses Merkmal kann folgendermaßen in C++ imple mentiert werden:

Bezugnehmend auf Fig. 4 kann die Dienstkomponenten schnittstelle 104, 105 bei einer Ausführungsform eine Dienst komponente laden, starten und steuern, um die Funktionen des Dienstes folgendermaßen zu implementieren. Eine Hauptroutine wird gestartet, um die Dienstfunktionen aufzurufen (Schritt 110). Die Dienstkomponentenschnittstelle 104, 105 liest die Konfigurationsdatenbank 63, um die Speicherstelle der auszu führenden Dienstkomponente zu identifizieren (Schritt 112). Wenn die Dienstkomponente eine JAVA-Klasse ist (Schritt 114), erzeugt die Dienstkomponentenschnittstelle 105 eine JVM auf einer zweiten (Anwendungs-)Routine (Schritt 116). Die JAVA- Klassenkomponente wird dann unter der JVM aufgerufen (Schritt 118). Die Eintrittsklasse ist so ausgelegt, dass sie erst nach der Beendigung der Dienstkomponente zurückkehrt. Dieses Merkmal erleichtert die Erkennung und das Abfangen von Ab stürzen und unbearbeiteten Ausnahmebedingungen. Während die JAVA-Klassenkomponente abläuft, überwacht und blockiert die Haupt-Routine (den Haupt-Thread) die Anwendungs-Routine (den Anwendungs-Thread) (Schritt 120), bis die Anwendungs-Routine endet. Wenn die Anwendungs-Routine endet (Schritt 122), dann hört die Haupt-Routine mit dem Blockieren auf und benachrich tigt das maschinenspezifische Betriebsystem, den Dienst her unterzufahren (Schritt 124). Wenn die Komponente in C/C++ ge schrieben ist (Schritt 114), ruft die Dienstkomponenten schnittstelle 104 die entsprechende Dienstkomponentenanwen dung und ihre Eintrittsfunktion auf (die beide in der Konfi gurationsdatenbank 63 identifiziert werden), um die Dienst komponente zu starten (Schritt 126). Wenn die Dienstkomponen te endet (Schritt 128), benachrichtigt die Haupt-Routine das Betriebsystem, den Dienst herunterzufahren (Schritt 130).

Die Dienstkomponentenschnittstelle 104, 105 kann so konfigu riert werden, dass sie Dienstkomponenten lädt, startet und steuert, die der maschinenspezifischen JAVA-Schnittstelle (JAVA native interface = JNI), der C/C++-Win32-Schnittstelle und einer beliebigen anderen Betriebsumgebung, die aus einer DLL-Bibliothek aufgerufen werden kann, entsprechen.

Bei einer Ausführungsform kann man die Dienstmodule 66-70 verwenden, um ein Verlässlichkeitssystem in einer Telefonie- über-LAN-Anwendung (ToL-Anwendung) gemäß der Beschreibung in der U.S.-Anmeldung Nr. ....... mit dem Titel: "Hierarchical De pendability for Open Distributed Environments", eingereicht von Mark Skrzynski und VJ Misra am selben Datum wie die vor liegende Anmeldung, zu implementieren. Auf diese Schrift wird hiermit ausdrücklich Bezug genommen.

Andere Ausführungsformen liegen im Schutzumfang der Ansprü che. Zum Beispiel können, obwohl die obigen Ausführungsformen im allgemeinen Kontext computerausführbarer Befehle eines auf einem Servercomputer ablaufenden Computerprogramms beschrie ben wurden, diese Ausführungsformen auch in Kombination mit anderen Programmmodulen implementiert werden. Zusätzlich kön nen diese Ausführungsformen mit anderen Computersystemkonfi gurationen realisiert werden, z. B. Computersysteme mit einer einzigen Verarbeitungseinheit oder Computersysteme mit mehre ren Verarbeitungseinheiten, Minicomputer, tragbare Daten verarbeitungsgeräte, prozessorgestützte oder programmierbare Geräte der Unterhaltungselektronik und dergleichen. Weiterhin können, obwohl die obigen Ausführungsformen in Verbindung mit einer verteilten Datenverarbeitungsumgebung beschrieben wur den, in der Tasks von abgesetzten Verarbeitungsgeräten durch geführt werden, die durch ein Kommunikationsnetz verbunden werden, andere Ausführungsformen auf selbständigen Computer systemen realisiert werden.

Claims

1. System zur Bereitstellung einer Schnittstelle von einer Dienstkomponente (80, 82, 84) zu einer Anwendungspro grammschnittstelle (API) (64) eines maschinenspezifi schen Betriebssystems mit einem Schnittstellenmodul (104, 105), das so konfiguriert ist, dass es eine Dienstkomponente (80, 82, 84) lädt, die in einer nicht- maschinenspezifischen Programmiersprache geschrieben ist.

2. System nach Anspruch 1, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es eine Anwendungs betriebsumgebung erzeugt, in der die Dienstkomponentenan wendung (80, 82, 84) betrieben werden kann.

3. System nach Anspruch 2, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es eine virtuelle JAVA-Maschine die in einer JAVA-Programmiersprache ge schrieben ist, zur Ausführung einer Dienstkomponentenan wendung (84) erzeugt

4. System nach Anspruch 2, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es die Anwendungs betriebsumgebung und die Dienstkomponentenanwendung (80, 82, 84) während der Ausführung als einen einzigen Pro zess behandelt.

5. System nach Anspruch 4, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es eine Anwendungs routine erzeugt, auf dem die Anwendungsbetriebsumgebung erzeugt werden kann.

6. System nach Anspruch 5, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es eine Hauptrouti ne zur Überwachung und zum Blockieren der Anwendungsrou tine erzeugt.

7. System nach Anspruch 1, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es Dienstkomponen teninformationen aus einer Konfigurationsdatenbank (63) abruft.

8. System nach Anspruch 7, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es aus der Konfigu rationsdatenbasis (63) die Identität einer auszuführen den Dienstkomponentenanwendung (80, 82, 84) abruft.

9. System nach Anspruch 8, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es die identifi zierte Dienstkomponentenanwendung (80, 82, 84) lädt, startet und steuert.

10. System nach Anspruch 1, wobei das Schnittstellenmodul (104, 105) eine dynamisch verknüpfte Bibliothek mit Dienstkomponentenschnittstellen enthält.

11. System nach Anspruch 1, wobei das Schnittstellenmodul (104, 105) unter dem Betriebssystem Windows NT Server (60) betrieben werden kann und so konfiguriert ist, dass es eine Schnittstelle von einer Win32-API (64) zu Dienstkomponenten (80, 82, 84) bereitstellt, die in den Programmiersprachen C, C++ und JAVA geschrieben sind.

12. System zur Bereitstellung einer Schnittstelle von einer Dienstkomponente (80, 82, 84) zu einer Anwendungspro grammschnittstelle (API) (64) eines maschinenspezifischen Betriebssystems mit einem Schnittstellenmodul (104, 105), das so konfiguriert ist, dass es Dienstkomponen teninformationen aus einer Konfigurationsdatenbank (63) abruft.

13. System nach Anspruch 12, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es aus der Konfigu rationsdatenbank (63) die Identität einer auszuführenden Dienstkomponentenanwendung (80, 82, 84) abruft.

14. System nach Anspruch 13, wobei das Schnittstellenmodul (104, 105) so konfiguriert ist, dass es die identifi zierte Dienstkomponentenanwendung (80, 82, 84) lädt, startet und steuert.

15. System nach Anspruch 12, wobei das Schnittstellenmodul (104, 105) eine dynamisch verknüpfte Bibliothek (DLL) mit Dienstkomponentenschnittstellen enthält.

16. System nach Anspruch 12, wobei das Schnittstellenmodul (104, 105) unter dem Betriebssystem Windows NT Server (60) betrieben werden kann und so konfiguriert ist, dass es eine Schnittstelle von einer Win32-API (64) zu Dienstkomponenten (80, 82, 84) bereitstellt, die in den Programmiersprachen C, C++ und JAVA geschrieben sind.

17. Verfahren zur Bereitstellung einer Schnittstelle von ei ner Dienstkomponente (80, 82, 84) zu einer Anwendungspro grammschnittstelle (API) (64) eines maschinenspezifischen Betriebssystems, dass das Laden einer Dienstkomponente (80, 82, 84), die nicht in einer maschinenspezifischen Programmiersprache geschrieben ist, umfasst.

18. Verfahren nach Anspruch 17, das weiterhin das Erzeugen einer Anwendungsbetriebsumgebung, in der die Dienstkom ponentenanwendung betrieben werden kann, umfasst.

19. Verfahren nach Anspruch 18, wobei eine virtuelle JAVA- Maschine zur Ausführung einer Dienstkomponentenanwendung (80, 82, 84) erzeugt wird, die in einer JAVA- Programmiersprache geschrieben ist.

20. Verfahren nach Anspruch 18, wobei die Anwendungsbe triebsumgebung und die Dienstkomponentenanwendung (80, 82, 84) während der Ausführung als ein einziger Prozess behandelt werden.

21. Verfahren nach Anspruch 20, weiterhin mit dem Schritt des Erzeugens einer Anwendungsroutine, auf dem die An wendungsbetriebsumgebung erzeugt werden kann.

22. Verfahren nach Anspruch 21, weiterhin mit dem Schritt des Erzeugens einer Hauptroutine zur Überwachung und zum Blockieren der Anwendungsroutine.

23. Verfahren nach Anspruch 17, das weiterhin das Abrufen von Dienstkomponenteninformationen aus einer Konfigura tionsdatenbank (63) umfasst.

24. Verfahren nach Anspruch 23, wobei die Identität einer auszuführenden Dienstkomponentenanwendung (80, 82, 84) aus der Konfigurationsdatenbank (63) abgerufen wird.

25. Verfahren nach Anspruch 24, das weiterhin das Laden, Starten und Steuern der identifizierten Dienstkomponen tenanwendung (80, 82, 84) umfasst.

26. Verfahren nach Anspruch 17, wobei die Dienstkomponente (80, 82, 84) durch die dynamisch verknüpfte Bibliothek (DLL) geladen wird.

27. Verfahren zur Bereitstellung einer Schnittstelle von ei ner Dienstkomponente (80, 82, 84) zu einer Anwendungs programmschnittstelle (API) (64) eines maschinenspezifi schen Betriebssystems, das das Abrufen von Dienstkompo nenteninformationen aus einer Konfigurationsdatenbank (63) umfasst.

28. Verfahren nach Anspruch 27, wobei die Identität einer auszuführenden Dienstkomponentenanwendung (80, 82, 84) aus der Konfigurationsdatenbasis (63) abgerufen wird.

29. Verfahren nach Anspruch 28, das weiterhin das Laden, Starten und Steuern der identifizierten Dienstkomponen tenanwendung (80, 82, 84) umfasst.

30. Verfahren nach Anspruch 27, wobei die Dienstkomponente (80, 82, 84) durch die dynamisch verknüpfte Bibliothek (DLL) geladen wird.