DE69621494T2

DE69621494T2 - Vorrichtung und Verfahren eines verteilten Fehlerbeseitigers zur Fehlerbeseitigung von verteilten Anwendungsprogrammen

Info

Publication number: DE69621494T2
Application number: DE69621494T
Authority: DE
Inventors: Andrew E. Davidson; Jon A. Masamitsu
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-03-03
Filing date: 1996-03-01
Publication date: 2003-02-13
Anticipated expiration: 2016-03-02
Also published as: CA2170724A1; DE69621494D1; JPH09120366A; US5819093A; EP0730227A1; US6042614A; EP0730227B1

Description

Gebiet der Erfindung

Diese Erfindung liegt auf dem Gebiet von verteilten Computersystemen, dem Klienten-Server-Rechnen und dem objektorientierten Programmieren. Insbesondere betrifft die Erfindung ein Verfahren und eine Vorrichtung, um Programmentwickler und Nutzer in die Lage zu versetzen, Zielanwendungen zu debuggen, die Programme oder Objekte auf verteilten Servern enthalten. Hintergrund
Es ist wichtig, dass ein Computeranwendungsentwickler in der Lage ist, die Anwendung, die er erzeugt, zu debuggen. Dies wird in einer objektorientierten Umgebung mit verteiltem Prozessor zu einem über die Maßen schwierigen Problem. Derartige moderne Umgebungen umfassen Anwendungen, die Objekte aufrufen, die durch andere Personen entwickelt worden sind als den Anwendungsentwickler, und sie können Implementierungen der Objekte enthalten, die auf einem Prozessor entfernt von dem Anwendungsentwickler und unbekannt für diesen laufen. Dessen ungeachtet muss der Anwendungsentwickler eine Möglichkeit haben, diejenigen Teile der Anwendung zu debuggen, die in derartigen entfernten und unbekannten Prozessoren enthalten sind.
Beispielsweise handelt es sich bei einer verteilten Anwendung bzw. Verteil-Anwendung um eine Anwendung, die in zwei oder mehreren Teilen vorliegt. Diese Teile werden häufig als Kunde bzw. Klient und seine Server bezeichnet. Verteilte Anwendungen gibt es seit vielen Jahren und für gerade so viele Jahre haben Programmanwendungsentwickler das Problem gehabt, verteilte Anwendungen zu debuggen. Das typische Verfahren zum debuggen eines verteilten Programms besteht darin, den Klienten unter einem Debugger zu starten und den Klienten zu debuggen, bis man zu einer Funktion gelangt, die sich in einem Server befindet. Wenn der Entwickler Glück hat, läuft der Server bereits auf einem bekannten Host. Der Entwickler geht dann weiter zu dem Serverhost, identifiziert den Serverprozess, bringt an ihm einen Debugger an und setzt die Debuggersitzung fort. Wenn der Server noch nicht läuft, muss der Entwickler herausfinden, wie er den Server zum Laufen bekommt, und hoffen, dass, was immer er tut, der Bug, den er sucht, nicht verschleiert wird. Sobald der Server gestartet worden ist, bringt der Entwickler wiederum einen Debugger an ihm an. Alternativ muss der Entwickler herausfinden, wie er das Starten des Servers überlagern kann, um an dem Server einen Debugger anzubringen, bevor irgendetwas von Interesse geschieht. Dieses Verfahren ist fehleranfällig, mühsam und häufig verwirrend und langwierig.
In einem objektorientierten System bildet ein Objekt eine Komponente mit Daten und Operationen, die zum Manipulieren der Daten aufgerufen werden können. Die Operationen (auch "Methoden" genannt) werden auf dem Objekt aufgerufen durch Senden von Aufrufen zu dem Objekt. Jedes Objekt weist einen Objekttyp auf, der die Operationen definiert, die auf Objekten dieses Typs durchgeführt werden können. Ein Objekttyp kann die Objektoperationen übernehmen, die für andere Objekttypen definiert und implementiert sind. Zur weiteren Erläuterung von objektorientierten Auslegungs- und Programmiertechniken wird auf "Object-oriented Software Construction" von Bertrand Meyer, Prentice-Hall 1988 verwiesen.
Beim Klienten-Server-Rechnen bzw. bei der Klienten-Server- Computerkommunikation gibt es typischerweise einen Satz von Computern, die miteinander über ein Netzwerk, das die Computer verbindet, kommunizieren können. Einige dieser Computer wirken als Provider für Dienstleistungen oder Funktionalität für weitere Computer. Die Provider einer Dienstleistung oder Funktionalität sind als "Server" bekannt, und die Verbraucher der Dienstleistung oder Funktionalität werden als "Klienten" bezeichnet. Das Klienten-Server-Modell gilt auch für den Fall, dass einzelne Programme, die auf demselben Computer laufen, miteinander durch einen geschützten Mechanismus kommunizieren und als Provider und Verbraucher von Funktionalität wirken.
In objektorientierten verteilten Systemen bzw. Verteilsystemen auf Grundlage des Klienten-Server-Modells existieren Server, die objektorientierte Schnittstellen für ihre Klienten bereit stellen. Diese Server unterstützen Objekte, die aus Daten und der zugeordneten Software bestehen, um die Daten in Übereinstimmung mit Operationen zu manipulieren, die für diesen Objekttyp möglich sind. Klienten können Zugriff auf diese Objekte erhalten und Aufrufe auf sie ausführen durch Übertragen der Aufrufe zu dem Server. Im Server werden diese Aufrufe ausgeführt über die mit dem Objekt verbundene Software. Die Ergebnisse dieser Aufrufe werden daraufhin zum Klienten zurück übertragen.
Ein weiteres grundsätzliches Problem von Debuggern gemäß dem Stand der Technik tritt auf, wenn man mit dem debuggen einer Anwendung konfrontiert ist, die in einem modernen verteilten Objektsystem bzw. Verteil-Objektsystem implementiert ist. Es wird auf ein Distributed Objects System Bezug genommen, das durch die Object Management Group ("OMG") allgemein spezifiziert ist. Bei der OMG handelt es sich um einen Zusammenschluss von über 500 Herstellern, die Einvernahme über bestimmte Spezifikationen und Protokolle für ein derartiges verteiltes Objektsystem erzielt haben. Die grundsätzliche Spezifikation für dieses System ist in dem OMG-Dokument Nr. 93.xx.yy Revision 1.2 vom 29. Dezember 1993 mit dem Titel "The Common Object Request Broker: Architecture and Specification" (auch als CORBA bezeichnet) enthalten. Derartige, mit CORBA übereinstimmende Systeme stellen Bauanleitungen für bereits existierende Objekte bereit. Diese Anleitungen bzw. Anwendungen können die Erzeugung eines Objekts und die Durchführung von Operationen an diesem Objekt anfordern. Die Erzeugung und die Operation von bzw. an Objekten werden durch Server für diese Objekte durchgeführt. Wenn eine derartige Anwendung ein Objekt erzeugen möchte, nutzt sie in transparenter Weise einen Lokalisierermechanismus zum Ermitteln eines Servers, der für dieses Objekt als "Factory" bekannt ist. Wenn eine derartige Anwendung ein bereits existierendes Objekt aufweist, nutzt in ähnlicher Weise ihre Transparenz einen Lokalisierermechanismus zum Ermitteln eines Servers, der Operationen an diesem Objekt durchführen kann.
In derartigen, mit CORBA übereinstimmenden Systemen existiert eine beträchtliche Anzahl von Mechanismen hinter jedem Objekt, die es dem Anwendungsprogrammierer erlauben, Objekte ohne das Wissen zu nutzen, wo die Server für die Objekte laufen. Unter den speziellen Umständen, unter denen der Entwickler des Klienten auch der Entwickler des Servers ist, können solche Anordnungen derart getroffen sein, dass der Programmierer weiß, wo die Server laufen und wie ihre Namen lauten. Der Entwickler von Anwendungen des mit CORBA übereinstimmenden Systems ist jedoch üblicherweise nicht in der Lage, die mit diesen Objekten verbundenen Server zu lokalisierten. Es besteht deshalb ein Bedarf, das Debuggen von Objekten auf Grundlage von Anwendungen ungeachtet dessen zu unterstützen, ob das Objekt im selben oder einem entfernten Prozess angeordnet ist, und ungeachtet dessen, wo das Objekt sich befindet. Darüber hinaus sollte diese Debugging-Prozedur bevorzugt die Illusion eines "einzigen Prozesses" für den Entwickler erzeugen, um das Debuggen einer großen verteilten Anwendung unter Verwendung eines üblichen Debugging-Paradigmas zu ermöglichen.
Ein hauptsächlicher Nachteil von Debuggern gemäß dem Stand der Technik besteht darin, dass sie einen großen Overhead von unterstützenden Daten und Prozessen erfordern, üblicherweise aufweisend zusätzliche Daten, die durch betreffende Compiler erzeugt werden. Eine bevorzugte Ausführungsform für einen entfernten Debugger macht es deshalb erforderlich, dass Objektimplementatoren speziell nichts anderes aufweisen dürfen, um ihre Objekte "debuggbar" zu machen, als ihre Server so zu compilieren, dass symbolische Information erzeugt wird. (In C und C++ die Verwendung der -g-Compileroption.) Keine zusätzlichen verhaltensmäßigen oder datenmäßigen Abstraktionen auf jedem Server bzw. Diener sollten jedoch erforderlich sein, es sei denn, der diesbezügliche Overhead dominiert die Größe und das Leistungsvermögen feinkörniger Objekte. Eine weitere Beschränkung der Debugging-Systeme gemäß dem Stand der Technik besteht in ähnlicher Weise darin, dass sie mit einem bestimmten Typ einer Zielanwendung und/oder einer speziellen Compilersprache verbunden sind. Es besteht deshalb ein Bedarf an einem verteilten Debugger bzw. Verteil-Debugger, der in der Lage ist, Anwendungen unabhängig von der Implementierungssprache zu debuggen. D. h., der bevorzugte verteilte Debugger sollte keinerlei Annahmen bezüglich der Arten der Server und Objekte benötigen, die er betreiben kann oder mit denen er betrieben werden kann. Die CORBA-Spezifikation beschreibt eine Abwandlung von "Objekt-Adaptern", die genutzt werden können, um unterschiedliche Arten von Objektimplementierungen zu bedienen. Der benötigte verteilte Debugger bzw. Verteil- Debugger sollte in einer "Objekt-Adapter"-unabhängigen Weise arbeiten, wenn er tatsächlich keinerlei Annahmen über die Art von Servern und Objekten machen muss, mit denen er zusammenarbeiten kann. Ferner besteht ein Bedarf an einem verteilten Debugger bzw. Verteil-Debugger, der jeglichen Kochplattencode (Boiler-Plate-Code) ignorieren kann, der die Implementierung des mit CORBA übereinstimmenden Systems ggf. nutzt, um den Betrieb des Systems zu erläutern. Der "Kochplatten"-Code bezieht sich auf einen beliebigen, nicht von einem Programmierer erzeugten Code, der durch die Entwicklungsumgebung erzeugt wird und dem Entwickler nicht bekannt ist. Der verteilte Debugger sollte den Entwickler außerdem in die Lage versetzen, sein System auf demselben funktionellen Abstraktionsniveau zu debuggen, mit dem sie das System implementiert haben.
Die US-A-5371746 offenbart ein Programmdebuggingsystem für ein verteiltes bzw. Verteil-Datenverarbeitungssystem desjenigen Typs, in dem mehrere Prozesse miteinander kommunizieren, um ihre gleichlaufenden und parallelen Operationen zu realisieren. Das Debuggingsystem umfasst mehrere Satellitendebuggingeinheiten, die jeweils mit den mehreren Prozessen zum Debuggen der Prozesse verbunden sind; eine zentrale Debuggingeinheit zum Fernsteuern der mehreren Satellitendebuggingeinheiten und eine Fernprozeduraufrufermittlungseinheit zum vorläufigen Ermitteln einer Ausgabe oder eines Endes eines entfernten Prozeduraufrufs in dem durch die Satelliten-Debuggingeinheiten zu debuggenden Prozess.
Der erfindungsgemäße verteilte Debugger, der als "doeDebugger" bezeichnet ist, kann eine Vorrichtung und ein Verfahren zum Ausführen von verteiltem Debuggen in nahtloser, müheloser Weise mit niedrigem Overhead bereit stellen, wodurch ein Entwickler in die Lage versetzt wird, eine verteilte objektorientierte Anwendung mit der Illusion zu debuggen, dass er eine "Einzelprozess"-Anwendung debuggt.
Die vorliegende Erfindung ist in den anliegenden unabhängigen Ansprüchen festgelegt.
Eine Vorrichtung und ein Verfahren werden offenbart, demnach eine Klientenanwendung einen Debugger auf einem lokalen Host nutzen kann, während er gleichzeitig eine Anwendung nahtlos debuggen kann, die Objekte und Objektimplementierungen einbezieht, die auf unbekannten entfernten bzw. entfernt angeordneten Hostcomputern laufen können.
Ein verteiltes Debuggersystem bzw. ein Verteil-Debuggersystem wird offenbart zum Debuggen eines verteilten Zielanwendungssystems, das teilweise auf einem lokalen Hostcomputer vorliegt und teilweise auf einem oder mehreren entfernten Rostcomputern, wobei das verteilte Debuggersystem eine Debugger- GUI und eine oder mehrere dbx-Maschinen aufweist, die auf dem lokalen oder dem entfernten Hostcomputer vorgesehen sind, und einen Kommunikationsmechanismus zur Verwendung durch die dbx- Maschinen und die Debugger-GUI, damit sie miteinander sprechen können.
Die vorliegende Erfindung betrifft eine Vorrichtung zum Durchführen verschiedener Operationen. Die Vorrichtung kann speziell für die erforderlichen Zwecke ausgelegt sein oder sie kann aus einem üblichen bzw. normalen Computer bestehen, der durch ein Computerprogramm selektiv aktiviert und rekonfiguriert ist, das in dem Computer gespeichert ist. Die Operationen, die vorliegend angeführt werden, beziehen sich nicht inhärent auf einen speziellen Computer oder eine andere Vorrichtung. Insbesondere können verschiedene übliche Maschinen mit Programmen genutzt werden, die in Übereinstimmung mit den vorliegend genannten Lehren geschrieben sind oder es kann sich als zweckmäßiger erweisen, mehrere spezialisierte Vorrichtungen zu erstellen, um die benötigten Verfahrensschritte durchzuführen. Die erforderliche Struktur für unterschiedliche dieser Maschinen ergibt sich aus der vorliegend angeführten Beschreibung.
Für ein besseres Verständnis der vorliegenden Erfindung wird nunmehr eine Ausführungsform beispielhaft unter Bezug auf die anliegenden Zeichnungen erläutert; in diesen zeigen:
Fig. 1 einen Allzweckcomputer bzw. normalen Computer und zugehörige Einheiten,
Fig. 2 ein verteiltes Computersystem,
Fig. 3 eine Klienten-Server-Systemkonfiguration mit mehreren Maschinen und unter Darstellung der Beziehung von Nutzer, Klientenanwendung, Objektreferenz, Objektimplementierung und Erzeugungsobjektreferenzprogramm,
Fig. 4 eine Klienten-Server-Konfiguration unter Verwendung einer einzigen Maschine,
Fig. 5 den SPARCworks-Debugger,
Fig. 6 eine Beziehung zwischen einer Klientenanwendung, einer Objektreferenz und dem SPARCworks-Debugger,
Fig. 7 eine beispielhafte Distributed-Object-Environment- (DOE) Klientenanwendung, die Zugang zu mehreren Servern erfordert,
Fig. 8 eine Unterteilung zwischen einem Nutzercode und den diesem zu Grunde liegenden DOE-Mechanismen in einem DOE- Klienten oder -Server,
Fig. 9 eine doeDebugger-Konfiguration,
Fig. 10 ein Flussdiagramm der Arbeitsweise des doeDebugger in einer verteilten Umgebung,
Fig. 11 ein Flussdiagramm des Zwischen-dbx- Maschinenprozesses,
Fig. 12 ein Flussdiagramm der Arbeitsweise des doeDebugger- Erzeugungs- und Anbringungsprozesses (Block 246 im Diagramm von Fig. 10),
Fig. 13 ein Flussdiagramm der Arbeitsweise des doeDebugger- Trennungs- und Anbringungsprozesses (Block 284 im Diagramm von Fig. 11),
Fig. 14 die Beziehung zwischen doeDebugger, dbx-Maschinen, Wrapperdienstleistungs- und Klientenanwendung und Serverobjektimplementierung,
Fig. 15 eine typische Schnittstelle für einen dbxwrapper.

ANMERKUNGEN UND NOMENKLATUR

Die nunmehr folgende detaillierte Erläuterung erfolgt mit den Begriffen von Programmprozeduren, die in einem Computer oder einem Computernetzwerk ausgeführt werden. Diese Prozessbeschreibungen und -darstellungen stellen die Mittel dar, die durch den Fachmann auf diesem Gebiet der Technik verwendet werden, um die Substanz ihrer Arbeit am wirksamsten umzusetzen.
Eine Prozedur bedeutet vorliegend und allgemein eine selbstkonsistente Sequenz von Schritten, die zu einem erwünschten Ergebnis führen. Bei diesen Schritten handelt es sich um diejenigen, die physikalische Manipulationen physikalischer Größen erfordern. Üblicherweise, jedoch nicht notwendigerweise haben diese Größen die Form elektrischer oder magnetischer Signale, die gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert werden können. Mitunter erweist es sich als nützlich, prinzipiell, um mit üblicher Nomenklatur übereinzustimmen, sich auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen o. dgl. zu beziehen. Es wird jedoch bemerkt, dass sämtliche dieser oder ähnlicher Terme bzw. Begriffe mit den geeigneten physikalischen Größen verbunden werden können, und dass es sich bei ihnen lediglich um geeignete Bezeichnungen für diese Größen handelt.
Die durchgeführten Manipulationen werden häufig als Terme bzw. Begriffe bezeichnet, wie etwa addieren oder vergleichen, die üblicherweise mit durch einen menschlichen Operator durchgeführten mentalen Operationen verbunden sind. Keine derartige Fähigkeit eines menschlichen Operators ist erforderlich oder in den meisten Fällen erwünscht in einer der vorliegend erläuterten Operationen, die Teil der vorliegenden Erfindung bilden; bei den Operationen handelt es sich um Maschinenoperationen. Nützliche Maschinen zum Durchführen der Operationen der vorliegenden Erfindung umfassen normale bzw. Allzweckdigitalcomputer oder ähnliche Vorrichtungen.
Die vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum Durchführen dieser Operationen. Diese Vorrichtung kann speziell für die erforderlichen Zwecke erstellt sein, oder sie kann einen üblichen bzw. Allzweckcomputer umfassen als selektiv aktiviert oder rekonfiguriert durch ein Computerprogramm, das im Computer gespeichert ist. Die vorliegend präsentierten Prozeduren beziehen sich nicht inhärent auf einen speziellen Computer oder eine andere Vorrichtung. Unterschiedliche Allzweckmaschinen können mit Programmen genutzt werden, die in Übereinstimmung mit den vorliegend definierten Lehren geschrieben sind, oder es kann sich als günstiger erweisen, eine spezialisiertere Vorrichtung zu erstellen, um die benötigen Verfahrensschritte durchzuführen. Die benötigte Struktur für eine Vielzahl dieser Maschinen erschließt sich aus der vorliegenden Erläuterung.

BESCHREIBUNG DER AUSFÜHRUNGSFORM

Die folgende Offenbarung erläutert ein System und eine Vorrichtung zum Debuggen einer verteilten Computeranwendung, bei der der Programmierer/Entwickler der Anwendung sich an einer Hostmaschine befindet, und bei der die zu entwickelnde Anwendung Objekte und Objektimplementierungen nutzt, die auf unterschiedlichen Hostmaschinen lokalisiert sein können, was dem Programmierer/Entwickler nicht bekannt ist. Das System und die Verfahren stellen Lösungen für Probleme bereit, die angetroffen werden, wenn versucht wird, eine neue Anwendung zu debuggen, die mit der Nutzung von Objekten in einem stark verteilten objektorientierten Klienten-Server-System verbunden ist. Bei verteilten Objekten kann es sich um Objektklienten oder Objektserver abhängig davon handeln, ob sie Anfragen zu anderen Objekten senden oder auf Anfragen von Klienten antworten. In einer verteilten Objektumgebung erfolgen Anfragen und Antworten durch einen Object Request Broker (ORB), der die Orte und den Status der Objekte kennt. Eine Architektur, die geeignet ist, einen derartigen ORB zu implementieren, wird bereit gestellt durch die Spezifikation der Common Object Request Broker Architecture (CORBA). Bei der erläuterten Implementierung, die in einem beliebigen relevanten Kontext genutzt werden kann, handelt es sich um eine Erweiterung des Systems Distributed Object Environment ("DOE") von Sun Microsystems, Inc. Bei der DOE handelt es sich um die aktuelle Implementierung von Sun bezüglich der CORBA-Architektur. Es ist jedoch kein spezielles Wissen über das DOE-System für den Fachmann auf diesem Gebiet der Technik erforderlich, um den Prozess und das System, die in dieser Offenbarung erläutert werden, zu verstehen und zu implementieren.
Die vorliegende Ausführungsform offenbart Systeme und Verfahren zum Erzeugen und Nutzen eines doeDebugger, der es einem Programmierer/Entwickler erlaubt, die Tatsache zu ignorieren, dass ein durch seine Anwendung aufgerufenes Objekt entfernt implementiert werden bzw. sein kann, und sie erfordert nicht, dass er bezüglich einer entfernten Implementierung spezielle Maßnahmen ergreift und sie belastet ihn nicht mit einer unangemessenen Overhead-Last, wodurch gewährleistet ist, dass der Programmierer/Entwickler sein System auf demselben funktionellen Abstraktionsniveau debuggt, mit dem er das System implementiert. Alternative Implementierungen erbringen ebenfalls eine bestimmte Sprachenunabhängigkeit.

I. DEFINITIONEN

Der Begriff "verteiltes Objekt" oder "Objekt" bezieht sich, wie vorliegend verwendet, auf eine verkapselte Code- und Datenverpackung, die durch Operationen über eine definierte Schnittstelle manipuliert werden kann, die mit einem Objekt verbunden ist. Verteilte Objekte bzw. Verteil-Objekte erschließen sich dem Fachmann auf diesem Gebiet der Technik deshalb als Basiseigenschaften enthaltend, die traditionelle Programmierobjekte definieren. Verteilte Objekte bzw. Verteil-Objekte unterscheiden sich jedoch von traditionellen Programmierobjekten durch den Einschluss von zwei wesentlichen Merkmalen. Als erstes sind die verteilten Objekte bzw. Verteil-Objekte mehrsprachig. Die Schnittstellen verteilter Objekte werden definiert unter Verwendung einer Schnittstellendefinitionssprache, die auf eine Vielzahl unterschiedlicher Programmiersprachen abgebildet werden kann. Bei einer derartigen Schnittstellendefinitionssprache handelt es sich um OMG IDL. Als zweites sind die verteilten Objekte ortsunabhängig, d. h., verteilte Objekte können an beliebiger Stelle in einem Netz zu liegen kommen. Dies steht im scharfen Gegensatz zu traditionellen Programmierobjekten, die typischerweise in einem einzigen Adressraum existieren, dem Adressraum des "Klienten". Verteilte Objekte können Objektklienten oder Objektserver, abhängig davon sein, ob sie Anfragen an andere Objekte senden oder auf Anfragen von anderen Objekten antworten. Anfragen und Antworten erfolgen über den Object Request Broker (ORB), der die Orte und den Status der Objekte kennt. Ein "verteiltes Objektsystem" bzw. "Verteil-Objektsystem" oder eine "verteilte Objektbetriebsumgebung" bezieht sich auf ein System mit verteilten Objekten, die über einen ORB kommunizieren.
Bei einer "Objektreferenz" oder bei "objref" handelt es sich um eine Datenstruktur (hierbei kann es sich um ein traditionelles Programmiersprachenobjekt handeln), die einen Zeiger oder ein anders Objekt enthält. Die Erzeugung und Definition von Objektreferenzen ist dem Fachmann auf diesem Gebiet der Technik geläufig.
Ein "Klient", wie er vorliegend definiert ist, bezieht sich auf eine Entität, die eine Anfrage an ein Objekt sendet. In diesem Modell stellt das Objekt eine Dienstleistung bereit und wird als "Serverobjekt" oder "Zielobjekt" oder "Objektimplementierung" bezeichnet. Klienten rufen deshalb Operationen oder Implementierungen von Servern auf. In einigen Fällen handelt es sich bei den Klienten selbst um Objekte. In einer verteilten Objektumgebung benötigen Klienten weder Wissen über die Implementierungsprogranvniersprache, noch muss die Implementierung ein Wissen über die Programmiersprache des Klienten haben auf Grund des Erfordernisses des Mehrsprachencharakters dieser Objekte. Klienten und Server in verteilten Objektbetriebsumgebungen müssen lediglich in Begriffen bzw. Termini der Schnittstellendefinitionssprache kommunizieren. Wie vorstehend angemerkt, wird die Anfrage durch den Klienten an den Server und die Antwort des Servers an den Klienten durch den ORB gehandhabt. Es wird bemerkt, dass der Klient und der Server innerhalb desselben Prozesses existieren können auf demselben Hostcomputer oder auf zwei unterschiedlichen Hostcomputern.
Bei einer "Objektschnittstelle" handelt es sich um eine Spezifikation der Operationen, Attribute und Ausnahmen, die ein Objekt bereit stellt. Bevorzugt sind Objektschnittstellen für verteilte Objekte geschrieben unter Verwendung einer autorisierten Interface Definition Language (IDL). Wie vorstehend angeführt, führen Objekte Transaktionen über ihre Schnittstellen durch. Die Verwendung von Schnittstellen macht es daher für Klienten unnötig, die Programmiersprachen zu kennen, die verwendet werden, um die Methoden und Daten der Objekte in der Transaktion zu definieren.
Beim "Aufstellen" bzw. "Zusammenstellen" eines Informationspakets handelt es sich um die Zubereitung dieser Information zur Übertragung entweder über einen geteilten Speicherkommunikationskanal oder über eine Netzwerkkommunikationsleitung. Dies bedeutet häufig das Organisieren der Daten in einem speziehen Format in Übereinstimmung mit dem verwendeten Kommunikationsprotokoll.
Beim "Vereinzeln" eines Informationspakets handelt es sich im Wesentlichen um die umgekehrte Auf- bzw. Zusammenstellprozedur zur Erzeugung von Daten in einem Format, das in einer geeigneten Umgebung Bedeutung hat.
Bei "ToolTalk" handelt es sich um ein Kommunikationssystem, das durch SunSoft, einer Tochterfirma von Sun Microsystems, Inc. entwickelt wurde und zur Verfügung gestellt wird. "Tool- Talk" stellt eine Kommunikationsdienstleistung bereit, die durch eine Anwendung erzeugte Mitteilungen anderen zur Verfügung stellt, die angefragt haben, die Mitteilung zu empfangen. "ToolTalk" erlaubt unabhängigen Anwendungen, mit anderen Anwendungen zu kommunizieren, ohne dass sie direkt voneinander wissen. Ein Sender kann eine "ToolTalk"-Mitteilung für eine speziellen Prozess adressieren, für einen beliebigen interessierenden Prozess, für ein Objekt oder für einen Objekttyp. "ToolTalk" ist im Einzelnen erläutert in SunSoft Press/PTR Prentice Hall, im Buch mit dem Titel "The ToolTalk Service: An Inter-Operability Solution" (ISBN 013-088717-X).

II. BETRIEBSUMGEBUNG

Die Umgebung, in der die vorliegende Erfindung eingesetzt wird, umfasst das übliche verteilte Computersystem, in dem Allzweckcomputer, Workstations oder Personalcomputer über Kommunikationslinks unterschiedlicher Typen verbunden sind in einer Klienten-Server-Anordnung, in der Programme und Daten, zahlreiche in Form von Objekten, den verschiedenen Mitgliedern des Systems zur Verfügung gestellt werden zur Ausführung und zum Zugriff durch andere Mitglieder des Systems. Einige der Elemente eines Allzweck-Workstationcomputers sind in Fig. 1 gezeigt. Gezeigt ist demnach ein Prozessor 1 mit einem Eingabe-/Ausgabe-("I/O")abschnitt 2, einer Zentralprozessoreinheit ("CPU") 3 und einem Speicherabschnitt 4. Der I/O- Abschnitt 2 ist mit einer Tastatur 5, einer Anzeigeeinheit 6, einer Plattenspeichereinheit 9 und einer CD-ROM-Antriebseinheit 7 verbunden. Die CD-ROM-Einheit 7 kann ein CD-ROM- Medium 8 lesen, das typischerweise Programme 10 und Daten enthält. Fig. 2 zeigt ein typisches verteiltes Mehrprozessorcomputersystem, bei dem unabhängige Computer 20, 22 und 24 und ggf. mit einer geteilt genutzten Speichereinheit 28 über eine Kommunikationsverbindung bzw. einen -link 26 verbunden sind. Fig. 3 zeigt eine typische objektorientierte Klienten- Server-Anordnung. Demnach kann ein Nutzer 30 eine Klientenanwendung 34 auf einem ersten Computer 32 initiieren. Die Klientenanwendung 34 setzt an eine Objektreferenz 36 einen Aufruf bzw. Anruf 40 ab, der zu einer Implementierung des Objekts (auch als "Zielobjekt" bezeichnet) 46 auf einem zweiten Computer (dem Server) 50 zeigt. Der Anruf bzw. Aufruf 40 wird zu dem Kommunikationssteuermechanismus 38 geleitet, der den Aufruf bzw. Anruf zu dem Server 50 sendet, auf dem die Objektimplementierung 46 angeordnet ist. Dieser Objektimplementierungsmechanismus 46 erzeugt ursprünglich die Objektreferenz 36 und macht sie für Nutzer verfügbar. Bei Beendigung der Verarbeitung des Aufrufs bzw. Anrufs führt die Objektimplementierung 46 eine Mitteilung oder die Ergebnisse einer gewünschten Operation über die Kommunikationsverbindung 42 zu der ursprünglichen Klientenanwendung 34 zurück. Dieses Klienten-Server-Modell funktioniert auch in einer einzelnen Prozessoreinheit, in der die Kommunikationsmechanismusfunktionen durch das Betriebssystem (62 in Fig. 4) durchgeführt werden.

III. DER VERTEILTE DEBUGGER - WIE ER ERSTELLT WIRD

In Fig. 5 ist das SPARCworks-Debuggersystem gezeigt. Der SPARCworks-Debugger (nachfolgend als der "Debugger" bezeichnet) stellt eine integrierte Komponente des SPARCworks- Toolsets dar, hergestellt durch Sun Microsystems, Inc., und aufweisend einen Analysator, eine dbx-Maschine, ein FileMerge-Tool, ein Maketool, einen Manager und einen Sourceßrowser. Der Debugger ist im Einzelnen in der Publikation mit dem Titel "Debugging a Program" erläutert, veröffentlicht durch SunSoft als Teil Nr. 801-7105-10 vom August 1994.
Wie in Fig. 5 gezeigt, umfasst der Debugger ein ausgeklügeltes fensterbasierendes Werkzeug bzw. Tool 72 (die Debugger- Grafik-Nutzerschnittstelle (GUI)), die mit der dbx-Maschine 76 eine Schnittstelle bildet. Bei der dbx-Maschine 76 handelt es sich um einen interaktiven, zeilenorientierten, symbolischen Source-Level-Debugger. Die dbx-Maschine 76 erlaubt es, zu ermitteln, wo das Zielprogramm abgestürzt ist, die Werte der Variablen und Ausdrücke anzusehen, in dem Code Unterbrechungspunkte 78 zu setzen und ein Zielprogramm laufen zu lassen und zu verfolgen. Während der Programmausführung erhält die dbx-Maschine 76 Information über das Zielprogrammverhalten und versorgt die Debugger-GUI 72 mit dieser Information über das ToolTalk-Kommunikationsprotokoll 74. Die dbx-Maschine 76 bezieht sich auf die Debugging-Information, die ein Compiler erzeugt unter Verwendung der Compileroption -g zum Inspizieren des Zustands des Zielprozesses. Durch Default auf Solaris 2.x, der aktuellen Betriebssystemumgebung von Sun Microsystems, Inc., ist bzw. wird Debugging-Information für jedes Programmmodul in der Datei .o des Moduls gespeichert. In der bevorzugten Ausführungsform auf Solaris 2.x liest die dbx-Maschine 76 die Information für jedes Modul bedarfsmäßig ein. Zusätzlich zu der Fähigkeit, einen Unterbrechungspunkt zu erzeugen "set breakpoint" 78, besitzt die dbx-Maschine 76 die Fähigkeit eines einzelnen Schritts bzw. "single step" 80 sowie zahlreiche weitere Merkmale 82, die im Einzelnen in der vorstehend genannten Veröffentlichung "Debugging a Program" erläutert sind. Das Merkmal "Schritt" 80 erlaubt es dem Programmierer/Entwickler, durch den Zielprogrammcode zeilenweise entweder auf dem Quellen- oder Maschinensprachenniveau sich einzelschrittweise vorwärts zu bewegen, Funktionsaufrufe zu "überspringen" oder in diese "hineinzuspringen", "über" und "aus" einen Funktionsaufruf zu springen und an der Zeile anzugelangen, in der die Funktionsleitung aufgerufen wird (jedoch nach dem Aufruf bzw. der Anfrage). Es existieren drei Typen von Befehlen für den Unterbrechungspunkt 78:
(1) Stop-Typ-Unterbrechungspunkte - Wenn das Zielprogramm an einem Unterbrechungspunkt anlangt, der mit einem Stop- Befehl erzeugt wurde, hält das Programm an und gibt optional einen oder mehrere Debugging-Befehle aus. Ein weiterer Debugging-Befehl muss ausgegeben werden, um das Zielprogramm wieder aufzunehmen;
(2) When-Typ-Unterbrechungspunkte - Das Zielprogramm hält an und die dbx-Maschine gibt einen oder mehrere Debugging-Befehle aus, woraufhin das Zielprogramm fortgesetzt wird; und
(3) Trace-Typ-Unterbrechungspunkte - Das Zielprogramm hält an und eine ereignisspezifische Spur- bzw. Trace- Informationszeile wird emittiert, woraufhin das Programm fortsetzt.
In einem nicht verteilten System ist eine typische Konfiguration des Debugger in Fig. 6 gezeigt. Demnach ist die Hostmaschine 92 die Debugger-GUI 94 enthaltend gezeigt, die mit einer dbx-Maschine 98 durch eine ToolTalk-Kommunikationsverbindung 96 verbunden ist, wobei die dbx-Maschine 98 mit einem Klienten (Zielprogramm) 100 verbunden ist, der seinerseits mit einem zusätzlichen Zielprogrammanwendungscode (Server) 102 verbunden ist. In einem verteilten System ist der Programmierer/Entwickler mit einer Situation konfrontiert, die mehr derjenigen entspricht, die in Fig. 7 gezeigt ist. Fig. 7 zeigt mehrere Klienten mit mehreren Servern auf mehreren Hosts.
Ein den Debugger 114 auf dem roten Host 112 verwendender Programmierer/Entwickler zum Debuggen des Klienten 1 116 kann herausfinden, dass der Klient 1 116 eine Operation an einem Objekt durchführt, das durch den Server 118 auf dem roten Host 112 oder durch den Server 124 auf dem blauen Host 122 durchgeführt wird und der Programmierer als der Entwickler des Klienten 1 116 weiß nicht, welcher Server für die Ausführung eines Aufrufs bzw. Anrufs verwendet wird. Welcher Server auch immer verwendet wird durch den Klienten 1 116, kann außerdem verwendet werden durch den Klienten 2 128 auf dem weißen Host 130. In einem mit CORBA übereinstimmenden verteilten System, wie etwa DOE (der bevorzugten Ausführungsform der vorliegenden Erfindung), steht hinter jedem Objekt ein beträchtlich großer Mechanismus, der es dem Anwendungsprogrammierer erlaubt, Objekte ohne das Wissen zu nutzen, wo die Server für die Objekte laufen. Hierdurch wird das Debuggen verteilter Anwendungen unter solchen Umständen ernsthaft beeinträchtigt. Sämtliche DOE-Server sind außerdem Mehrfadenserver, bei denen es möglich ist, dass der Server gemäß der vorliegenden Ausführungsform eine Lösung für zahlreiche der Debugging-Probleme darstellt, erzeugt durch die verteilte DOE-Umgebung.
Bevor die Modifikationen an dem Debugger erläutert werden, der benötigt wird, den doeDebugger gemäß der vorliegenden Ausführungsform zu erzeugen, ist es hilfreich, kurz den Kochplattenmechanismuscode zu betrachten, der durch DOE genutzt wird, damit Objekte miteinander in einer mit CORBA übereinstimmenden Umgebung kommunizieren können. In Fig. 8 ist eine Unterteilung zwischen dem verwendeten Code und dem diesem zu Grunde liegenden DOE-Mechanismus gezeigt.
In Fig. 8 ruft auf einem lokalen Host 142 ein Nutzercode eine Funktion auf, beispielsweise die Funktion "foo" 144. Das DOE- System stellt den erzeugten Code bereit, der die Schnittstelle für die Funktion foo 148 bereit stellt und der erzeugte Code 148 ruft Mitteilungsfunktionen 150 auf, um die geeigneten Mitteilungen zu erzeugen und sie zum Server 152 zu senden. Diese Mitteilungen 154 erreichen einen geeigneten Host 156 und werden durch das serverseitige Mitteilungssystem 158 empfangen, das die Mitteilungen zu einem serverseitigen Stub leitet, bei dem es sich um den durch das DOE-System 160 erzeugten Code handelt, der daraufhin den Implementierungscode für die Funktion foo 162 und den Nutzercode für die Implementierung der Funktionsprozesse des Aufrufs 164 aufruft. Der Anwendungsprogrammierer schreibt den Code 144, der Objekte nutzt, die durch DOE-Server bereit gestellt werden. Der Anwendungsprogrammierer definiert die Schnittstellen zu den Objekten unter Verwendung der Interface Definition Language (IDL). IDL wird in die klientenseitigen und serverseitigen Bibliotheken compiliert, die die Operation an einem Objekt in dem Klienten zur Durchführung in dem Server freigeben. Die klientenseitige Bibliothek besteht aus Stub-Funktionen 148, 150, die eine Operation in einer Anfrage 154 an einen Server umsetzen. Die serverseitigen Bibliotheken 160, 162 wandeln eine Anfrage von einem Klienten in einen Anruf für einen Nutzer um, der mit der Funktion 164 versehen ist, die die Operation implementiert.
Beispielsweise in Fig. 8 hat der Nutzer eine Funktion foo in IDL definiert. Der IDL-Compilierer erzeugt eine Stub-Funktion foo 148, 150, die dafür sorgt, dass eine Mitteilung erzeugt wird 152, die zu dem Server übertragen wird. Auf der Serverseite empfängt der IDL-erzeugte Code 160, 162 die Mitteilung von dem Klienten und setzt sie in einen Aufruf für die Funktion foo 164 um, die durch den Programmierer bereit gestellt wird, der die Funktionalität von foo implementiert. Bei dem gesamten, diesem zu Grunde liegenden Code 148, 150, 152, 158, 160 und 162 handelt es sich um einen Code, den ein Programmierer/Entwickler nicht debuggen möchte, und den er in einer normalen Debugg-Sitzung nicht sehen möchte. Folglich ist es erwünscht, eine verteilte Debugging-Sitzung zu ermöglichen, um den gesamten zu Grunde liegenden Code zu ignorieren, soweit der Programmierer/Entwickler betroffen ist.
Fig. 9 zeigt die Modifikationen und Erweiterungen, die erforderlich sind, den SPARCworks-Debugger in den doeDebugger umzusetzen, der in der vorliegenden Erfindung genutzt wird. Die tatsächlichen Erweiterungen sind in einer geteilt genutzten Bibliothek "libdoeDebugger.so" 204 verpackt. Die benötigten fundamentalen Erweiterungen umfassen Folgendes:
Einen "dstep"-Befehl 206 einen "remote surrogate code test"-Mechanismus 208 einen "Remote Breakpoint"-Wählmechanismus 210 einen "Getlmplementation"-Mechanismus 212 einen "IdentifyRemoteFunction"-Mechanismus 214 einen "multiple dbx engine synchronizer"-Mechanismus 216.
Zusätzlich zu diesen Erweiterungen umfassen die Modifikationen an der Debugger-GUI und der dbx-Maschine zur Unterstützung der doeDebugger-Operation:
Kommunikationsfähigkeit für eine dbx-Maschine zur Kommunikation mit einer weiteren dbx-Maschine;
die Fähigkeit der Debugger-GUI, sie auf eine spezielle dbx-Maschine zu fokussieren; und
die Fähigkeit, eine Liste sämtlicher aktiver dbx- Maschinen von der Debugger-GUI zu erhalten.
Die Ausführungsform dieser Modifikationen wird nunmehr allgemein erläutert; dem Fachmann auf diesem Gebiet der Technik erschließt sich jedoch, dass diese Fähigkeiten und Merkmale in beliebigen Formen implementiert werden können, einschließlich einigen Hardwaremechanismen und Vorrichtungen für diejenigen Abschnitte, die am geeignetsten sind.
Der "dstep"-Befehl wird durch den Programmierer/Entwickler verwendet, um nahtlos in die Implementierung einer gegebenen Funktion ungeachtet dessen zu springen, wo in dem verteilten System die Implementierung der Funktion tatsächlich vorliegt. "dstep" arbeitet, indem zunächst ein normaler dbx-"Schritt"- Befehl ausgegeben wird. Der Standard-"Schritt"-Befehl setzt die Ausführung des Prozesses, der dem Debuggen unterliegt (der Debuggee) ausgehend von der aktuellen Quellenzeile zur nächsten Quellenzeile des Debuggee fort. Wenn die aktuelle Zeile sich am Punkt des Aufrufs einer Funktion befindet, handelt es sich bei der nächsten Quellenzeile um die erste Quellenzeile in der aufgerufenen Funktion. Um die Semantik des Schrittbefehls auf das Debuggen verteilter Anwendungen zu erweitern, sollte dann, wenn der erweiterte Schritt eine Funktion eingibt, wie etwa foo auf den Klienten in Fig. 8 (Punkt A 146), die Ausführung in der ersten Zeile beim Implementieren von foo im Server (Punkt B 166) stoppen. Der erweiterte Schrittbefehl (auf den als "dstep"-Befehl Bezug genommen wird) arbeitet als Standardschrittbefehl mit Ausnahme der folgenden beiden Situationen:
Wenn der "dstep"-Befehl beim Aufrufen einer Funktion ausgeführt wird, führt dies zu einem Aufruf in einem Server und die nächste Quellenzeile ist die erste Zeile der im Server aufgerufenen Funktion; und
wenn der "dstep"-Befehl beim Rückführen von einer Funktion, aufgerufen im Server, ausgeführt wird, ist die nächste Quellenzeile diejenige Quellenzeile in dem Klienten nach dem Funktionsaufruf, die in einem entfernten Aufruf resultiert hat. Für den DOE-Klienten startet der "dstep"- Befehl seine speziellen Funktionen, wenn der Nutzer in den IDL-erzeugten Code einsteigt. Für den DOE-Nutzer startet der "dstep"-Befehl seine spezielle Funktion, wenn der Nutzer durch den IDL-erzeugten Code rückkehrt.
Außerdem ist es notwendig, den doeDebugger transparent herunter zu fahren. Da der Nutzer nicht weiß, was unternommen worden ist, um das entfernte Debuggen zu unterstützen, darf von ihm nicht erwartet werden, dass er dies rückgängig macht. Nachdem der "dstep"-Befehl ausgeführt ist, versucht der doe- Debugger, zu ermitteln, ob die aktuelle Funktion der "remote surrogate code" ist. Bei dem "remote surrogate code" handelt es sich um den Code, der verantwortlich ist für die Verursachung des entfernten Aufrufs der IDL-Operation (d. h., die Elemente 148, 150 in Fig. 8). In dem DOE-System wird aktuell der gesamte "remote surrogate code" durch den IDL-Compiler erzeugt.
Auf der Klientenseite muss der doeDebugger erkennen, dass er in den IDL-erzeugten Code heruntersteigt. Um dies zu bewirken, nennt DOE eine Variable, die in der ersten Schicht des IDL-erzeugten Codes mit einem speziellen Namen genutzt wird. Das Vorliegen dieser Variablen dient als Trigger zum Starten der "dstep"-Funktionalität.
Es ist zu erwarten, dass der Name der klientenseitigen Funktion, die aufgerufen wird, derselbe ist wie der Name der serverseitigen Funktion, die diese Funktion implementiert. Im Beispiel von Fig. 8 bedeutet dies, dass der Programmierer die Funktion "foo" auf der Klientenseite aufruft und erwartet, die Funktion "foo" zu erhalten, die er auf der Serverseite geschrieben hat. Ein Server kann zahlreiche Klienten mit Dienstleistungen versehen und deshalb können zahlreiche Aufrufe der Funktion "foo" in dem Server auftreten. Das Interesse in dem Server am Aufruf wird identifiziert durch Ermitteln, welcher Faden (Thread) in dem Server den Funktionsaufruf des Klienten, der dem Debuggen unterliegt, Dienstleistung erbrachte. Zwei Funktionen (eine auf der Klientenseite und eine auf der Serverseite) wurden der Mitteilungsübertragungsschicht (in DOE) hinzugefügt, um die Identifikation des speziellen Fadens im Server zu unterstützen.
Um den Server für ein Objekt zu lokalisieren, wurde einer DOE-Basisklasse die Funktion "find server" hinzugefügt. Dies führt zur Durchführung der Funktionalität, die als "Getlmplementation" bezeichnet wird. Diese Funktion kann auf einem beliebigen DOE-Objekt aufgerufen werden und führt den Host des Servers und den Prozess-Id (Pid) des Servers zurück. Der doe- Debugger ruft die "find server"-Funktion im Klienten auf. Hierbei handelt es sich nicht um eine Funktion, die in den doeDebugger inkorporiert werden kann, weil sie einen Teil des Objekts bilden muss, das durch den Klienten verwendet wird. Wenn der Server zu dem Zeitpunkt nicht läuft, wenn die "find server"-Funktion aufgerufen wird, wird der Server gestartet.
Wie vorstehend erläutert, wird das Vorliegen einer speziellen Variable als "Trigger" genutzt, um zu signalisieren, dass die "dstep"-Funktionalität aufgerufen werden sollte, wenn in eine Funktion gesprungen wird. Ein ähnlicher "Trigger" wird nicht benötigt, um zu signalisieren, wenn ein "dstep" von einem Server rückgeführt werden sollte, und zwar aus zwei Gründen: Der Triggermechanismus war für das Rückführen bzw. den Rücksprung nicht verfügbar; und
der Rücksprung bzw. das Rückführen sieht das Zurückgehen durch den Code vor, der bereits bekannt war (d. h., der dem Server durch diesen Code zugegangen war) und dieses Wissen kann genutzt werden, um das Rückführen bzw. den Rücksprung zu triggern.
Wenn der Server zum ersten Mal eingegeben wird bzw. wenn zum ersten Mal auf diesen zugegriffen wird, speichern wir den Stapelzeiger (Stack Pointer) der Funktion (als Rücksprungtrigger bezeichnet), der direkt die Implementierung der Funktion "foo" des Nutzers aufruft (in Fig. 8 eine IDLerzeugte Funktion). Wenn auf dem Rücksprung von dem Server geprüft wird, prüfen wir den Stack Pointer der aktuellen Funktion gegenüber dem Rücksprungtrigger. Wenn Übereinstimmung vorliegt, verlassen wir den Server bzw. setzen außerhalb von diesem die Operation fort.
Wenn der doeDebugger zum ersten Mal in einen Server springt, muss er auf dem Server eine neue dbx-Maschine starten. Dieser Prozess bildet Teil des "IdentifyRemote Function"-Prozesses, der als Erweiterung hinzugefügt wurde, um entfernte dbx- Maschinen zu identifizieren, eine entfernte dbx-Maschine zu starten/erzeugen unter Verwendung der Möglichkeiten eines dbxWrapperFactory-Objekts. Wie dies erfolgt, wird nunmehr unter Bezug auf Fig. 14 erläutert. Fig. 14 zeigt einen lokalen Host 520 mit einer Debugger-GUI 502, einer dbx-Maschine 504, einem Unterstützerprozess 506, einem klientenseitigen Wrapperserver 510 und einem Klienten 508. Gezeigt sind außerdem ein entfernter Host 522 mit einer dbx-Maschine 512, ein Unterstützerprozess 514, ein serverseitiger Wrapper-Server 518 und der Server 516 (Implementierung der aufgerufenen Funktion). Die Initialisierung einer neuen dbx-Maschine, enthaltend die Verbindung zu einer Debugger-GUI und das Anbringen an einem Server wird ausgeführt durch die klientenseitige dbx- Maschine 504, die einen Aufruf durchführt, um eine neue dbx- Maschine zu erzeugen.
Die dbx-Maschine 504 auf dem lokalen Host 520 erzeugt die dbx-Maschine 512 auf dem entfernten Host 522 durch Anfrage an den Wrapper-Server 510 auf dem lokalen Host 520 über den Unterstützerprozess 506 auf dem lokalen Host 520. Bei dem Unterstützerprozess 506 handelt es sich um eine DDE-Applikation, die mit dem Wrapper-Server 510 kommuniziert. Erforderlich ist dies, weil die dbx-Maschinen selbst nicht mehrfadensicher (MT-sicher) sind und nicht in eine DDE-Anwendung überführt bzw. erstellt werden können (sämtliche DDE-Anwendungen sind inhärent mehrfädig bzw. multithreaded). Die dbx-Maschinen greifen auf die Dienstleistungen des Wrapperserver durch den Unterstützerprozess zu. Der Wrapperserver 510 auf dem lokalen Host 520 sendet eine Mitteilung an den Wrapperserver auf dem entfernten Host 522 unter Anforderung, dass eine dbx- Maschine auf dem entfernten Host 522 erzeugt und instruiert wird, am Server 516 angebracht zu werden. Die Anforderung durch die dbx-Maschine 504 auf dem lokalen Host 520 zur Erzeugung der dbx-Maschine auf dem entfernten Host 522 geht nicht zu Ende, bis die dbx-Maschine 512 auf dem entfernten Host 522 vollständig gestartet ist. Der Wrapperserver auf dem entfernten Host 522 verzweigt bzw. forked und führt aus die neue dbx-Maschine 512 auf dem entfernten Host 522 und wartet daraufhin, dass die dbx-Maschine 512 entweder zu Ende geht oder ihm (Wrapperserver 518) eine Mitteilung sendet, die anzeigt, dass die dbx-Maschine 512 vollständig gestartet ist. Der Wrapperserver 518 auf dem entfernten Host 522 erzeugt zwei Fäden. Ein Faden wartet darauf, dass das geforkte Kind (dbx-Maschine 512) zu Ende geht. Der andere Faden wartet auf eine Mitteilung von der dbx-Maschine 512, dass sie vollständig gestartet ist. Wenn einer dieser Fäden aufgenommen wird, zerstört er den anderen Faden und sendet die geeignete Antwort zurück zu dem Wrapperserver 510 auf dem lokalen Host 520, der seinerseits die Anfrage nach der Erzeugung der dbx- Maschine 512 auf dem entfernten Host 522 beendet und den korrekten Statuswert (Erzeugung erfolgreich oder nicht erfolgreich) an die dbx-Maschine 504 auf dem lokalen Host rückführt.
Nachdem die neue dbx-Maschine 512 auf dem Server gestartet ist (wie vorstehend erläutert), sendet die dbx-Maschine 504 auf den Klienten eine Mitteilung an die neue dbx-Maschine 512, den korrekten Unterbrechungspunkt (Breakpoint) in dem Server 516 zu wählen. Die dbx-Maschine 504 auf dem Klienten vermag die Unterbrechungspunktmitteilung nicht an die dbx- Maschine 512 auf dem Server zu senden, bis diese dbx-Maschine 512 vollständig gestartet worden ist (d. h., bis sie ihre Initialisierung durchlaufen hat einschließlich der Verbindung mit der Debugger-GUI und bis sie am Server angebracht worden ist).
Einige zusätzliche Einzelheiten bezüglich der Arbeitsweise des doeDebugger, die erforderlich sind, um mögliche Überlaufbedingungen (Race Conditions) zu vermeiden, werden nunmehr genannt.
Die Erläuterung der Schritte, die während eines "dstep" durchgeführt werden, beziehen sich auf das Senden eines Befehls zu der dbx-Maschine, die am Server angebracht ist, um in dem Server einen Unterbrechungspunkt (Breakpoint) zu wählen. Der Befehl enthält ausreichend Information, um den Unterbrechungspunkt (Breakpoint) auf dem korrekten Faden im Sever zu wählen. Wenn der Schritt die Triggerfunktion einführt, existiert die Information noch nicht, die den Faden in dem Server in einziger Weise identifizieren kann, der den Aufruf bzw. Anruf, der resultierend aus dem Aufruf bzw. Anruf der Triggerfunktion herrührt, abarbeitet. Der tatsächliche Mechanismus besteht darin, dass ein Ereignis in einer Transportschicht in einem Punkt gewählt wird, wo ein Identifizierer für die Anfrage (die Anfrage-Id), resultierend aus dem Aufruf der Triggerfunktion, verfügbar ist. Dieses Ereignis sendet einen Befehl an die dbx-Maschine auf dem Server. Die Mitteilung enthält die Anfrage-Id, den Hostnamen des Klienten und die Zwischenprozessadresse des Klienten, und hierdurch ist die Anfrage korrekt bzw. in einzigartiger Weise identifiziert. Die Mitteilung, die zu der dbx-Maschine auf dem entfernten Host gesendet wird, führt zu einer Unterbrechungspunktwahl in der Mitteilungsweiterleitschicht in dem Server. Dieser Unterbrechungspunkt prüft auf Übereinstimmung mit der Anforderungs-Id, dem Hostnamen des Klienten und der Klientenzwischenprozessadresse, und wenn Übereinstimmung ermittelt wird, ist der Faden, der die Übereinstimmung herstellt bzw. erkennt, der Faden, der die Anfrage abarbeitet, die aus der Triggerfunktion in dem Klienten herrührt. Ein Unterbrechungspunkt wird daraufhin für diesen Faden beim Zugang auf die Funktion gewählt und der Server wird daraufhin fortgesetzt.
Wenn die Triggerfunktion in dem Klienten "foo" lautet, lautet die Funktion in dem Server, in dem der Unterbrechungspunkt gewählt ist, ebenfalls "foo". Klasseninformation steht jedoch in dem Server nicht zur Verfügung, so dass der "stop in member foo"-Befehl mit einer Prüfung auf einen speziellen Faden verwendet wird. In einigen Fällen liegt eine Funktion "foo" in dem automatisch erzeugten IDL-Code vor und die Ausführung des erzeugten Codes führt dazu, dass der Unterbrechungspunkt aktiv wird. Wenn der Unterbrechungspunkt aktiv wird (Fires), erfolgt eine Prüfung, um zu ermitteln, ob wir uns in dem IDLerzeugten Code befinden. Wenn dies der Fall ist, wird ein weiterer Unterbrechungspunkt gewählt und die Ausführung wird fortgesetzt.
Wenn die Triggerfunktion in dem Klienten "foo" lautet, wenn der Unterbrechungspunkt (Breakpoint) in dem Server in "foo" aktiv wird, wird der Rücksprung- bzw. Rückführtriggerstapelzeiger (Trigger Stack Pointer) gespeichert. Der Rückführtrigger wird verwendet, um die Erziehung fortzusetzen, wenn ein "dstep" am Ende von "foo" ausgeführt wird. Der Nutzer kann außerdem explizit aus dem Server mit einem "cont"-Befehl herausgelangen. In jedem Fall muss der gespeicherte Return Trigger Stack Pointer verworfen werden, so dass er bei einem weiteren Aufruf des Servers nicht genutzt wird. Ein Ereignis wird in der Transportschicht in einem Punkt gewählt, der die Ausführung eines Rücksprungs bzw. einer Rückführung gewährleistet und der gespeicherte Rücksprungtrigger wird in diesem Fall bzw. bei diesem Ereignis verworfen. Das Ereignis wird auf dem Faden gefiltert, so dass lediglich der Rücksprung der konkreten Anfrage dazu führt, dass der Rücksprungtrigger verworfen wird.
Wie vorstehend unter Bezug auf Fig. 14 erläutert, wird von der dbx-Maschine 504 auf dem lokalen Host 520 zu der dbx- Maschine 510 auf dem entfernten Host 522 eine Mitteilung gesendet, um einen Unterbrechungspunkt (Breakpoint) in dem Server 516 zu wählen. Nachdem die Unterbrechungspunktmitteilung gesendet ist, wird der Klient 508 fortgesetzt, so dass der entfernte Aufruf vom Klienten 508 zum Server 516 weiter schreitet. Es gibt jedoch keine Garantie, dass die Unterbrechungspunktmitteilung durch die dbx-Maschine 512 auf dem entfernten Host 522 empfangen und verarbeitet wurde, bevor der entfernte Aufruf den Server 516 erreicht. Um zu gewährleisten, dass der Unterbrechungspunkt (Breakpoint) aktuell gewählt wird, bevor der entfernte Aufruf stattfindet, stoppt die dbx-Maschine 504 auf dem lokalen Host 520 und wartet auf eine Mitteilung von der dbx-Maschine 512 auf dem entfernten Host 522. Sobald die dbx-Maschine 512 auf dem entfernten Host 522 den Unterbrechungspunkt (Breakpoint) in dem Server 516 wählt, sendet sie eine Mitteilung an die dbx-Maschine 504 auf dem lokalen Host 520, um den Klienten 508 fortzusetzen.
Die zusätzlichen Änderungen/Erweiterungen, die vorstehend angeführt sind, werden nunmehr erläutert.
Die Änderungen, die erforderlich sind, damit eine dbx- Maschine mit einer weiteren dbx-Maschine kommunizieren kann, umfassen Änderungen sowohl an der Debugger-GUI wie der dbx- Maschine, so dass eine spezielle ToolTalk-Mitteilung (als "rcmd"-Mitteilung bezeichnet) von der dbx-Maschine zu der Debugger-GUI geleitet werden kann, damit eine Mitteilung zu einer weiteren dbx-Maschine (als Ziel-dbx-Maschine bezeichnet) gesendet werden kann. Die Debugger-GUI akzeptiert Befehle von dem Nutzer und leitet sie zu speziellen dbx-Maschinen weiter. Die "rcmd"-Mitteilung enthält den Namen einer Hostmaschine, wo die Ziel-dbx-Maschine läuft, den Prozessidentifizierer (Pid) des Prozesses, der durch die Ziel-dbx-Maschine debuggt wird, und die Mitteilung für die Ziel-dbx-Maschine. Die Debugger-GUI enthält eine Liste von dbx-Maschinen und diese Liste enthält den Namen des Host, wo die dbx-Maschine läuft, und den Pid des Prozesses, der debuggt werden soll. Wenn die Debugger-GUI die "rcmd"-Mitteilungen erhält, sucht sie ihre Liste von dbx-Maschinen auf eine dbx-Maschine ab, die auf der genannten Hostmaschine läuft und einen Prozess mit dem gegebenen Pid debuggt. Die Mitteilung für die Ziel-dbx-Maschine wird daraufhin zu der dbx-Maschine übertragen.
Die Änderungen, die erforderlich sind, dass die Debugger-GUI sich auf eine spezielle dbx-Maschine fokussiert, enthält Änderungen von sowohl der Debugger-GUI wie der dbx-Maschine, so dass eine spezielle ToolTalk-Mitteilung (als "attention"- Mitteilung bezeichnet) von der dbx-Maschine zu der Debugger- GUI geleitet werden kann, damit die Debugger-GUI ihre Aufmerksamkeit auf das Senden der dbx-Maschine fokussiert. Die Debugger-GUI behält Anzeigen, die sich auf die spezielle dbx- Maschine beziehen. Beispielsweise wird das Quellenprogramm für den durch die spezielle dbx-Maschine zu debuggenden Prozess durch die Debugger-GUI angezeigt. Die Debugger-GUI weist einen Satz von Anzeigen auf und kann die Information von einer dbx-Maschine zu einem Zeitpunkt anzeigen. Die "attention"-Mitteilung veranlasst die Debugger-GUI, ihre Anzeigen ausgehend von der Information für die aktuelle dbx-Maschine auf die Information für die dbx-Maschine zu ändern, die die "attention"-Mitteilung sendet.
Die Änderungen, die erforderlich sind, damit eine Liste sämtlicher aktiver dbx-Maschinen von der Debugger-GUI erhalten werden kann, umfassen Änderungen sowohl betreffend die Debugger-GUI wie die dbx-Maschine, so dass eine spezielle Tool- Talk-Mitteilung (als "get dbx engines"-Mitteilung bezeichnet) von der dbx-Maschine zu der Debugger-GUI übertragen werden kann, damit die Debugger-GUI eine Liste der Hostnamen zurücksenden kann, wo jede dbx-Maschine gelaufen ist und von dem Prozessidentifizierer (Pid) des Prozesses, der durch diese dbx-Maschine debuggt wird. Die Debugger-GUI enthält eine Liste sämtlicher dbx-Maschinen, die den Namen des Host enthält, wo die dbx-Maschine gelaufen war und den Pid des Prozesses, der durch die dbx-Maschine debuggt worden ist. Wenn die Debugger-GUI die "get dbx engines"-Mitteilung enthält, extrahiert sie den Namen des Host und den Pid des Prozesses, der für jede dbx-Maschine debuggt wird, und sendet dies zurück zu der dbx-Maschine unter Sendung der "get dbx engines" - Mitteilung.

IV. VERTEILTER DEBUGGER - WIE ER VERWENDET WIRD

Nachdem die Änderungen/Erweiterungen am SPARCworks- Debuggersystem erläutert worden sind, die erforderlich sind, den doeDebugger gemäß der vorliegenden Ausführungsform zu erzeugen, wird nunmehr das Verfahren zum Verwenden des doeDebugger erläutert.
Die doeDebugger-Operation 220 wird nunmehr unter Bezug auf Fig. 10 erläutert. Ein Programmierer/Entwickler einer lokalen Maschine startet den doeDebugger 222. Das Zielprogramm wird angezeigt 224 und ein "dstep"-Befehl wird für eine gewünschte Funktion spezifiziert 226. Der doeDebugger führt einen Standard-"step"-Befehl 228 durch und der doeDebugger versucht zu ermitteln, ob die Zielimplementierung lokal oder entfernt ist 230. Wenn erkannt wird, dass das Ziel entfernt liegt (durch Erkennen des "remote surrugate code", erzeugt durch den IDL), wird die "find server"-Funktion ausgeführt 232, um den Host- Id und den Pid der Zielimplementierung zu finden. Die lokale dbx-Maschine gibt daraufhin einen Befehl zur Erzeugung einer dbx-Maschine in dem gefundenen Host 234 aus und blockiert und wartet auf eine Antwort. Der gefundene Host ermittelt, ob eine dbx-Maschine mit der Zielimplementierung 236 verbunden ist. Wenn bereits eine dbx-Maschine läuft 250, sendet der Server auf den gefundenen Host eine Rückführmitteilung zu der dbx-Maschine des anrufenden Klienten, dass die dbx-Maschine läuft 252. Die klientenseitige dbx-Maschine empfängt die Mitteilung und entsperrt 254. Die klientenseitige dbx-Maschine sendet daraufhin eine Mitteilung zu der dbx-Maschine auf dem Server, um einen vorübergehenden Unterbrechungspunkt (Breakpoint) in der designierten Funktion zu wählen 262 (in Fig. 11). Weiter in Fig. 11 führt die Server-dbx-Maschine den Befehl aus, einen Unterbrechungspunkt in der Zielfunktion 264 zu wählen und sie rettet bzw. speichert den Return Trigger Stack Pointer 266. Die Zielimplementierung wird durch die Server-dbx-Maschine "fortgesetzt" 268. Daraufhin trifft die Zielimplementierung auf den designierten Unterbrechungspunkt 270 und die Server-dbx-Maschine versorgt den Unterbrechungspunkt und sendet eine Mitteilung zu der Debugger-GUI auf dem Klientenhost, um auf der Server-dbx-Maschine 272 zu fokussieren. Der Programmierer, der die Debugger-GUI nutzt, ist nunmehr in der Lage, die entfernte Funktion so zu debuggen, als ob sie auf dem Klientenhost 274 vorliegen würde. Daraufhin prüft das System, um zu ermitteln, ob die Debugg-Sitzung beendet ist (d. h., ob ein Verlassenbefehl empfangen wird) 276, und wenn nicht 278, wird die Debugg-Sitzung fortgesetzt 282. Wenn der Verlassenbefehl empfangen wurde 280, steigt die entfernte dbx-Maschine aus und koppelt sich von dem Zielprozess 284 ab und verlässt die Sitzung 286.
Wenn unter erneutem Bezug auf den Block 236 in Fig. 10 keine dbx-Maschine in dem gefundenen Serverhost 238 läuft, teilt der Server der dbx-Maschine auf dem Klientenhost mit, dass keine dbx-Maschine läuft 240. Die Klienten-dbx-Maschine, die den Unterstützerobjektprozess nutzt, verarbeitet eine Anfrage auf der klientenseitigen dbxwrapperFactory, um eine dbx- Maschine auf dem Server auf dem gefundenen Host 242 zu erzeugen. Das klientenseitige dbxWrapperFactory-Objekt ruft die serverseitige dbxwrapperFactory-Implementierung auf 244, und eine dbx-Maschine wird auf dem Server des gefundenen Host erzeugt und wird an der Zielfunktionsimplementierung angebracht 246. Diese dbx-Maschine, die soeben erzeugt und an der Zielfunktion angebracht wurde, wird bezüglich ihres Laufs gestartet 248 und eine Rückführmitteilung wird zu der klientenseitigen dbx-Maschine 252 gesendet und der Prozess wird ausgehend von diesem Punkt fortgesetzt, wie vorstehend unter Bezug auf Block 254 und die Blöcke in Fig. 11 erläutert.
Der im Block 246 von Fig. 10 gezeigte "Remote dbx engine Create and attach"-Prozess wird nunmehr unter Bezug auf Fig. 12 näher erläutert. In Fig. 12 wird der "create"-Prozess 302 initialisiert und die klientenseitige dbx-Maschine ruft den lokalen Unterstützerprozess 304 auf. Der lokale Unterstützerprozess gibt einen "create"-Befehl an das dbxWrapperFactory- Objekt 306 aus. Das dbxWrapperFactory-Objekt sendet eine Mitteilung zu der dbxWrapperFactory-Implementierung auf dem gefundenen Host 308, der den "create"-Befehl 310 erzeugt. Die dbxwrapperFactory-Implementierung führt ein "fork" und "exec" für eine dbx-Maschine 316 durch und wartet auf eine Mitteilung von der neu erzeugten dbx-Maschine 318. Wenn die neue dbx-Maschine aus irgend einem Grund nicht vollständig gestartet wird 324, wird eine "Failed to start"-Mitteilung rückgeführt 326 und die dbxWrapperFactory-Implementierung geht zu Ende 320. Wenn die neue dbx-Maschine nicht vollständig gestartet wird 322, wird die neue dbx-Maschine angewiesen, an der Zielfunktion 328 angebracht zu werden. Wenn die neue dbx- Maschine nicht in der Lage ist, angebracht zu werden 334, wird eine Mitteilung "Failed to attach" rückgeführt 336 und die dbxWrapperFactory-Implementierung geht zu Ende 320. Wenn die neue dbx-Maschine in der Lage ist, angebracht zu werden 332, wird eine Mitteilung "Attached and running" rückgeführt und die dbxWrapperFactory-Implementierung geht zu Ende 320. Es wird bemerkt, dass "failure to attach" an einem Zielserver von einem Server resultieren kann, der seinerseits eine Erlaubnis hat für Anbringungserfordernisse, in welchem Fall andere Mechanismen zum Anbringen notwendig sein können.
Der im Block 284 von Fig. 11 gezeigte "Remote dbx engine Quit and Detach"-Prozess wird nunmehr unter Bezug auf Fig. 13 näher erläutert. In Fig. 13 beginnt der "Quit"-Prozess 402 wenn der Programmierer/Entwickler einen "Quit"-Befehl an die Debugger-GUI ausgibt, die den Befehl zu der lokalen dbx- Maschine 404 leitet. Die lokale dbx-Maschine sendet eine "QuitSession"-Mitteilung über den Unterstützerprozess zu der dbxWrapperFactory, um die Debugging-Sitzung 406 zu verlassen. Der "QuitSession"-Befehl veranlasst die dbxWrapperFactory- Ojekte auf jedem der teilnehmenden Hosts, ein Signal auszusenden 408 an jede dbx-Maschine, die Teil der Debugging- Sitzung bildet 410. Jede dbx-Maschine weist einen Signalhandhaber für das gesendete Signal auf, der eine Prüfung durchführt, um zu ermitteln, ob das Signal von der dbxWrapperFactory gesendet worden ist, und falls dies der Fall ist, wird die dbx-Maschine von dem Prozess abgekoppelt, den sie debuggt 412 und sie geht zu Ende. Alternative Ausführungsformen können zusätzliche Schritte umfassen, wie etwa das Abkoppeln des dbx-Maschinenprozesses von seiner Zielfunktion 414 und das Rückführen einer Mitteilung, wie etwa "dbx debugger detached and deleted" zu der klientenseitigen dbx-Maschine 416.
Eine Schnittstelle zum Implementieren eines dbxWrapper ist in Fig. 15 gezeigt. Dem Fachmann auf diesem Gebiet erschließt sich, dass für diese Funktion verschiedene Implementierungen vorgenommen werden können.
Obwohl die vorliegende Erfindung unter Bezug auf spezielle Betriebssysteme, Programmcodemechanismen und Objekt- und Objektreferenzdefinitionen erläutert worden ist, erschließt sich dem Fachmann auf diesem Gebiet der Technik, dass die vorliegende Erfindung in verschiedener Weise innerhalb einer gegebenen Betriebsumgebung implementiert werden kann oder in einem anderen Betriebssystem oder Objektsystemumgebungen. In ähnlicher Weise sind die speziellen Klienten- und Serverkonfigurationen oder -kombinationen, die in den Figuren gezeigt sind, lediglich repräsentativ für eine von zahlreichen derartigen Konfigurationen von Klienten und Servern und Objekt- und Zusatzobjektbeziehungen, die von der vorliegenden Erfindung Gebrauch machen können. Darüber hinaus wird bemerkt, dass die Figuren lediglich der Illustration dienen und für die vorliegende Erfindung nicht beschränkend sind. Einige zusätzliche Kombinationen der entfernten dbx-Maschine mit einer klientenseitigen Debugger-GUI mit anderen Funktionen umfassen das Kombinieren der dbx-Maschine mit einem Graphical User Interface ("GUI")-Agenten, der eine freundliche Nutzerschnittstelle für das Zielobjekt bereit stellt; das Kombinieren der entfernten dbx-Maschine mit einem Agenten mit künstlicher Intelligenz zur Modifizierung entfernter Anfrage auf Grundlage von bekannten Vorzügen des Nutzers; das Kombinieren der entfernten dbx-Maschine mit einem Caching-Programm, das Antworten zu den entfernten Anfragen cacht; das Kombinieren der entfernten dbx-Maschine mit einer Telekonferenzanwendung, die die Eingänge von verschiedenen Nutzern zusammenführt und sie zu dem Ziel führt; oder das Kombinieren einer entfernten dbx- Maschine mit einer Anzahl von Audio- und Videozugriffsagenten in einem Multimediasystem. Diese möglichen dbx-Maschinen- und Debugger-GUI-Kombinationen beschränken in keinster Weise die mögliche Verwendung der entfernten Debugger-Funktionalität, wie sie vorstehend erläutert ist, sondern stellt lediglich einige Beispiele dar, die sich dem Fachmann auf diesem Gebiet der Technik als beispielhaft erschließen.

Claims

1. Verteil-Debugger-System zum Diagnostizieren eines Verteil- Ziel-Anwendungssystems (100, 102), das in einem lokalen Host-Computer (520) und einem oder mehreren entfernten Host-Computern (522) vorgesehen ist, wobei das Verteil- Debugger-System eine graphische Debugger-Nutzer- Schnittstelle (72, 94, 502) und eine oder mehrere Debugger-Maschinen (76, 98, 504) aufweist, wobei die graphische Debugger-Nutzer-Schnittstelle (72, 94, 502) einen Schnittstellenmechanismus zur Kommunikation mit den Debuggermaschinen (76, 98, 504) und zum Kommunizieren mit einem Nutzer des Debugger-Systems bereitstellt, wobei die Debugger-Maschinen (76, 98, 504) in dem lokalen Host-Computer (520) und dem einen oder mehreren entfernten Host- Computern (522) vorgesehen sein können, wobei das Verteil- Debugger-System aufweist:

einen Kommunikationsmechanismus zur Verwendung durch die Debuggermaschinen (76, 98, 504) und die graphische Debugger-Nutzer-Schnittstelle (72, 94, 502) beim Senden von Mitteilungen zueinander und Empfangen von Mitteilungen voneinander; und

eine entfernte Debugger-Maschine, bei der es sich um eine der einen oder mehreren Debugger-Maschinen (76, 98, 504) handelt, und die in dem Host-Computer entfernt von dem lokalen Host-Computer (520) vorgesehen ist, wobei die entfernte Debugger-Maschine mit der graphischen Debugger- Nutzer-Schnittstelle (72, 94, 502) mittels des Kommunikationsmechanismus verbunden ist, dadurch gekennzeichnet, dass die entfernte Debugger-Maschine mit der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) zusammenarbeitet, während sie jeglichen zwischenschnittstellendefinitionssprachenerzeugten Codemechanismus ignoriert, der lokale und entfernte Abschnitte des Verteil-Ziel- Anwendungssystems verbindet, jedoch keinen Teil des Verteil-Ziel-Anwendungssystems selbst bildet, um den Nutzer in die Lage zu versetzen, das Verteil-Ziel- Anwendungssystem (100, 102) mit der Illusion zu diagnostizieren, dass der Nutzer eine einzige Prozessanwendung diagnostiziert.

2. Verteil-Debugger-System nach Anspruch 1, dadurch gekennzeichnet, dass die entfernte Debugger-Maschine einen entfernten Surrogatcode-Testmechanismus (208) zum Ermitteln aufweist, welche zwischenschnittstellendefinitionssprachenerzeugten Codemechanismen, welche lokale und entfernte Abschnitte der Zielanwendung verbinden, ignoriert werden sollen.

3. Verteil-Debugger-System nach Anspruch 2, dadurch gekennzeichnet, dass die entfernte Debugger-Maschine Fähigkeiten äquivalent zu denjenigen einer SPARCworks-Debugger- Maschine aufweist.

4. Verteil-Debugger-System nach Anspruch 1, 2 oder 3 gekennzeichnet durch einen zweiten Kommunikationsmechanismus, um die graphische Debugger-Nutzer-Schnittstelle (72, 94, 502) in die Lage zu versetzen, sich auf eine der Debugger- Maschinen (76, 98, 504) ungeachtet dessen zu fokussieren, in welchem Host-Computer die Debuggermaschine vorgesehen ist.

5. Verteil-Debugger-System nach Anspruch 1, 2, 3 oder 4 gekennzeichnet durch einen dritten Kommunikationsmechanismus, um den Nutzer in die Lage zu versetzen, von der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) eine Liste sämtlicher aktiver Debuggermaschinen (76, 98, 504) ungeachtet dessen zu erhalten, in welchem Host-Computer die Debugger-Maschinen (76, 98, 504) vorgesehen sind.

6. Verteil-Debugger-System nach Anspruch 1, 2, 3, 4 oder 5 wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen entfernten Unterbrechungspunktwahlmechanismus (210), um einen Nutzer an dem lokalen Host-Computer (520) in die Lage zu versetzen, einem Unterbrechungspunkt in einer Funktion des Verteil-Ziel-Anwendungssystem (100, 102) zu wählen, das aktuell in dem entfernten Host-Computer (522) implementiert ist.

7. Verteil-Debugger-System nach einem der Ansprüche 1 bis 6, wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen Getlmplementation-Mechanismus (212) zum Lokalisieren einer Host-Idee und einer Prozess-Idee eines Servers für ein beliebiges bezeichnetes Objekt.

8. Verteil-Debugger-System nach einem der Ansprüche 1 bis 7, wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen IdentityRemoteFunctidn-Mechanismus (214) zum identifizieren, ob eine entfernte Debugger-Maschine arbeitet, und falls dies nicht der Fall ist, zum Erzeugen und Anknüpfen einer Debugger-Maschine an einer entfernten Zielfunktion unter Verwendung der Möglichkeiten eines Debugger-WrapperFactory-Objekts.

9. Verteil-Debugger-System nach einem der Ansprüche 1 bis 8, wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen Mehrfach-Debugger-Maschinen-Synchronisierer- Mechanismus (216), um die Debugger-Maschinen (76, 98, 504) in die Lage zu versetzen, miteinander zu kommunizieren.

10. Computerimplementiertes Verfahren zum Erzeugen eines Verteil-Debuggersystems zum Diagnostizieren eines Verteil- Ziel-Anwendungsystems (100, 102), welches Ziel-Anwendungssystem in einem lokalen Host-Computer (520) und in einem oder mehreren entfernten Host-Computern (522) vorgesehen ist, wobei das computerimplementierte Verfahren die Schritte aufweist:

Bereitstellen einer graphischen Debugger-Nutzer- Schnittstelle (72, 94, 502) in einem lokalen Host-Computer (520) und von einer oder mehreren Debugger-Maschinen (76, 98, 504), wobei ein Schnittstellenmechanismus bereitgestellt wird zum Kommunizieren mit den Debuggermaschinen (76, 98, 504) und zum Kommunizieren mit einem Nutzer des Debugger-Systems;

Bereitstellen eines Kommunikationsmechanismus zur Verwendung durch die Debuggermaschinen (76, 98, 504) und die graphische Debugger-Nutzer-Schnittstelle (72, 94, 502) zum Senden von Mitteilungen zueinander und Empfangen von Mitteilungen voneinander; und

Bereitstellen einer entfernten Debugger-Maschine, bei der es sich um eine der einen oder mehreren Debugger-Maschinen (76, 98, 504) handelt, und die in dem Host-Computer entfernt von dem lokalen Host-Computer (520) vorgesehen ist, wobei die entfernte Debugger-Maschine mit der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) mittels des Kommunikationsmechanismus verbunden ist, dadurch gekennzeichnet, dass die entfernte Debugger-Maschine mit der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) zusammenarbeitet, während sie jegliche beliebige zwischenschnittstellendefinitionssprachenerzeugten Codemechanismen ignoriert, die lokale und entfernte Abschnitte des Verteil-Ziel-Anwendungssystems verbinden, jedoch keinen Teil des Verteil-Ziel-Anwendungssystems selbst bilden, um den Nutzer in die Lage zu versetzen, das Verteil-Ziel- Anwendungssystem (100, 102) mit der Illusion zu diagnostizieren, dass der Nutzer eine einzige Prozessanwendung diagnostiziert.

11. Computerimplementiertes Verfahren nach Anspruch 10, wobei der entfernte Debugger Fähigkeiten äquivalent zu einer SPARCworks Debugger-Maschine aufweist, wobei die entfernte Debugger-Maschine dazu in der Lage ist, unter Steuerung von der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) sich selbst an einen Abschnitt des Verteil-Ziel- Anwendungssystems (100, 102) anzubinden, das in dem entfernten Host-Computer vorgesehen ist, um den Abschnitt des Verteil-Ziel-Anwendungssystems (100, 102) zu diagnostizieren, das in dem entfernten Host-Computer vorgesehen ist, wobei die entfernte Debugger-Maschine einen entfernten Surrogatcode-Testmechanismus (208) aufweist, um zu ermitteln, welche zwischenschnittstellendefinitionssprachenerzeugten Codemechanismen, welche die lokalen und entfernten Abschnitte der Verteil-Ziel-Anwendung verbinden, ignoriert werden sollen.

12. Computerimplementiertes Verfahren nach Anspruch 10 oder 11, gekennzeichnet durch Bereitstellen eines zweiten Kommunikationsmechanismus, um die graphische Debugger-Nutzer- Schnittstelle (72, 94, 502) in die Lage zu versetzen, sich auf eine der Debugger-Maschinen (76, 98, 504) ungeachtet dessen zu fokussieren, in welchem Host-Computer die Debugger-Maschine vorgesehen ist.

13. Computerimplementiertes Verfahren nach Anspruch 10 oder 11, gekennzeichnet durch Bereitstellen eines zweiten Kommunikationsmechanismus, um den Nutzer in die Lage zu versetzen, von der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) eine Liste sämtlicher aktiver Debugger- Maschinen (76, 98, 504) ungeachtet dessen zu erhalten, in welchem Host-Computer die Debugger-Maschinen (76, 98, 504) vorgesehen sind.

14. Computerimplementiertes Verfahren nach Anspruch 13, gekennzeichnet durch Bereitstellen eines dritten Kommunikationsmechanismus, um die graphische Debugger-Nutzer- Schnittstelle (72, 94, 502) in die Lage zu versetzen, sich auf eine der Debugger-Maschinen (76, 98, 504) zu fokussieren, ungeachtet dessen, in welchem Host-Computer die Debugger-Maschine vorgesehen ist.

15. Computerimplementiertes Verfahren nach Anspruch 10, 11, 12, 13 oder 14, wobei der entfernte Debugger gekennzeichnet ist durch einen entfernten Unterbrechnungspunkt- Wahlmechanismus (210), um einen Nutzer an den Local-Host- Computer (520) in die Lage zu versetzen, einen Unterbrechungspunkt in einer Funktion des Verteil-Ziel- Anwendungssystems (100, 102) zu wählen, das in dem entfernten Host-Computer aktuell implementiert ist.

16. Computerimplementiertes Verfahren nach einem der Ansprüche 10 bis 15, wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen Getlmplementation-Mechanismus (212) zum Lokalisieren einer Host-Idee und einer Prozess- Idee eines Servers für ein beliebiges bezeichnetes Objekt.

17. Computerimplementiertes Verfahren nach einem der Ansprüche 10 bis 16, wobei die entfernte Debugger-Maschine gekennzeichnet ist durch einen IdentityRemoteFunction- Mechanismus (214) zum Identifizieren, ob eine entfernte Debugger-Maschine arbeitet, und falls dies nicht der Fall ist, zum Erzeugen und Anknüpfen einer Debugger-Maschine an einer entfernten Zielfunktion unter Verwendung der Möglichkeiten eines Debugger-WrapperFactory-Objekts.

18. Computerimplementiertes Verfahren nach einem der Ansprüche 10 bis 17, wobei der entfernte Debugger gekennzeichnet ist durch einen Mehrfach-Debugger-Maschinen-Synchronisierer- Mechanismus (216), um die Debugger-Maschinen in die Lage zu versetzen, miteinander zu kommunizieren.

19. Computerimplementiertes Verfahren nach einem der Ansprüche 10 bis 18, wobei die Debugger-Maschinen (76, 98, 504) in dem lokalen Host-Computer und den entfernten Host- Computern (522) vorgesehen sind.

20. Computerimplementiertes Verfahren nach Anspruch 19, gekennzeichnet durch Bereitstellen eines Debugger- WrapperFactory-Mechanismus zur Verwendung durch die graphische Debugger-Nutzer-Schnittstelle (72, 94, 502), um in dem entfernten Host-Computer eine neue Debugger-Maschine zu erzeugen zur Verwendung beim Diagnostizieren eines Teils des Ziel-Anwendungssystems, das in dem entfernten Host-Computer vorgesehen ist, wobei die neue Debugger- Maschine Fähigkeiten äquivalent zu denjenigen einer SPARCworks-Debugger-Maschine aufweist.

21. Computerimplementiertes Verfahren nach Anspruch 20, wobei die neue Debugger-Maschine in dem entfernten Host-Computer mit der graphischen Debugger-Nutzer-Schnittstelle (72, 94, 502) und der einen oder mehreren Debugger-Maschinen (76, 98, 504) zusammenwirkt, die in dem lokalen Host-Computer (520) vorgesehen sind, um das Ziel-Anwendungssystem zu diagnostizieren, während sämtliche zwischenschnittstellendefinitionssprachenerzeugte Codemechanismen ignoriert werden, welche die lokalen und entfernten Äbschnitte des Zielanwendungssystems verbinden, die jedoch keinen Teil des Zielanwendungssystems selbst bilden, wodurch der Nutzer in die Lage versetzt wird, das Verteil-Ziel- Anwendungssystem (100, 202) mit einer Illusion zu diagnostizieren, das der Nutzer eine einzige Prozessanwendung diagnostiziert.

22. Computerimplementiertes Verfahren nach Anspruch 21, wobei die neue Debugger-Maschine mit der graphischen Debugger- Nutzer-Schnittstelle (72, 94, 502) mittels des Kommunikationsmechanismus verbunden ist.

23. Computerimplementiertes Verfahren nach Anspruch 21 oder 22, gekennzeichnet durch Bereitstellen eines ersten Kommunikationsmechanismus, um die Debuggermaschinen (76, 98, 504) in die Lage zu versetzen, ungeachtet dessen mit einander zu kommunizieren, ob diese Debugger-Maschinen (76, 98, 504) in unterschiedlichen Host-Computern vorgesehen sind.

24. Computerimplementiertes Verfahren nach Anspruch 21, 22 oder 23, gekennzeichnet durch Bereitstellen eines zweiten Kommunikationsmechanismus, um die graphische Debugger- Nutzer-Schnittstelle (72, 94, 502) in die Lage zu versetzen, sich auf eine der Debugger-Maschinen (76, 98, 504) ungeachtet dessen zu fokussieren, in welchem Host-Computer die Debugger-Maschine vorgesehen ist.

25. Computerimplementiertes Verfahren nach Anspruch 21, 22, 23 oder 24, gekennzeichnet durch Bereitstellen eines dritten Kommunikationsmechanismus, um den Nutzer in die Lage zu versetzen, von der graphischen Debugger-Nutzer- Schnittstelle (72, 94, 502) eine Liste sämtliche aktiver Debugger-Maschinen (76, 98, 504) ungeachtet dessen zu erhalten, in welchem Host-Computer die Debugger-Maschinen (76, 98, 504) vorgesehen sind.

26. Computerimplementiertes Verfahren nach Anspruch 20, 21, 22, 2324 oder 25, gekennzeichnet durch:

Bereitstellen eines d-Schritt-Mechanismus (206), um die Debugger-Maschinen (76, 98, 504) zu instruieren, die zwischenschnittstellendefinitionssprachenerzeugten Codemechanismen zu ignorieren, welche die lokalen und entfernten Abschnitte des Zielanwendungssystems verbinden, die jedoch keinen Teil des Zielanwendungssystems selbst bilden; und

Bereitstellen eines entfernten Surrogat-Code-Testmechanismus (208) für die neue Debugger-Maschine, um zu ermitteln, welche zwischenschnittstellendefinitionssprachenerzeugten Codemechanismen, welche die lokalen und entfernten Abschnitte des Zielanwendungssystems verbinden, ignoriert werden sollen.