DE10205108A1 - System und Verfahren zum Zugreifen auf Softwarekomponenten in einer verteilten Netzwerkumgebung - Google Patents

Abstract

Ein System und Verfahren werden beschrieben, die zum Zugreifen auf Softwarekomponenten, Schnittstellen oder Ressourcen in einer verteilten Netzwerkumgebung beschrieben sind. Ein wesentliches Merkmal des Systems und Verfahrens, die hierin beschrieben sind, ist die Fähigkeit, solche Komponenten, Schnittstellen oder Ressourcen auf der Basis von bestimmten spezifizierten Attributen zu lokalisieren, ohne eine vorherige Kenntnis der Adresse oder Position der Komponente, Schnittstelle oder Ressource zu haben. Gemäß einem Ausführungsbeispiel umfaßt ein Verfahren die Schritte des Erzeugens einer Anforderung nach einer Komponente mit zumindest einem spezifizierten Attribut, des Sendens der Anforderung über das Netzwerk, des Empfangens der Anforderung an einem Dienstanbieter, des Vergleichens des zumindest einen spezifizierten Attributs der empfangenen Anforderung mit Komponentenattributen des Dienstanbieters und des Übertragens einer Antwort zu dem anfordernden Dienstverbraucher. Das System umfaßt Mechanismen zum Implementieren und Ausführen dieser Schritte.

Description

Die vorliegende Erfindung bezieht sich auf vernetzte Compu­ tersysteme und insbesondere auf ein neuartiges System und Verfahren zum Zugreifen auf Softwarekomponenten (für eine zusammenhängende Ausführung), die über eine verteilte Netz­ werkumgebung positioniert sind.

Allgemein können Softwareanwendungen in einer verteilten (vernetzten) Umgebung als Serviceprovider bzw. Dienstanbie­ ter, Serviceconsumer bzw. Dienstverbraucher oder beides an­ gesehen werden. Wie die Namen andeuten, sind Dienstanbieter Programme, die Schnittstellen, Komponenten oder Ressourcen an andere Programme liefern, so daß die anderen Programme die Schnittstellen, Komponenten oder Ressourcen verwenden können, um eine Aufgabe auszuführen. Die Dienstverbraucher sind Programme, die die Schnittstellen, Komponenten oder Ressourcen verwenden, die durch die Dienstanbieter gelie­ fert werden.

Wie bekannt ist, sind viele Softwareanwendungen über ein Netzwerk "verteilt", so daß dieselben ihre Aufgaben durch Verwenden von Softwarekomponenten, die über das Netzwerk verteilt sind, erfüllen. Der Begriff "Komponenten", wie er hierin verwendet wird, soll eine sehr breite Interpretation umfassen, die Dienste, Schnittstellen, Ressourcen, Codeseg­ mente, usw. umfaßt. Ein Beispiel einer solchen verteilten Anwendung ist die Verwendung eines Netzwerkdruckers. Genau­ er gesagt kann ein Netzwerkdrucker unter der direkten Steuerung eines Servers arbeiten, der konfiguriert ist, um den Betrieb des Druckers zu steuern. Trotzdem können ver­ teilte Anwendungen (Klienten) auf den Drucker zugreifen und denselben für "Druck"-Anwendungen verwenden. Ein weiteres Beispiel einer solchen verteilten Anwendung ist ein GUI (GUI = graphische Benutzeroberfläche)-Front-End für eine Datenbank (d. h., das GUI-Front-End ist eine Anwendung oder eine Komponente, die einem Computer zugeordnet ist, auf dem sich die Datenbank befindet). Wie bekannt ist, kann ein solches GUI-Front-End vorgesehen sein, um den Inhalten der Datenbank ein bestimmtes graphisches/visuelles "Erscheinen" zu geben. Entfernte Softwareanwendungen, die auf die Daten­ bank zugreifen möchten, können das GUI-Front-End verwenden.

Wie bekannt ist, müssen die Dienstverbraucher (d. h. die Softwareanwendungen, die den Drucker oder das GUI-Front-End verwenden wollen) die Netzwerkadresse oder die Position der zu liefernden Komponente kennen. Das heißt, die Workstati­ on-Anwendung, die drucken möchte, muß die Netzwerkadresse des Druckers kennen. Gleichartig dazu muß das Programm, das das GUI-Front-End verwenden möchte, konfiguriert sein, um die Position des Computers zu kennen, auf dem sich die Da­ tenbank befindet.

Solche Komponenten werden oft auf der Basis von "Attribu­ ten" gesucht, die durch den Dienstverbraucher spezifiziert werden. Beispielsweise kann in einer Firmen-LAN-Umgebung ein Benutzer in einer Workstation wünschen, ein Dokument auf einem "Farb"-Drucker zu drucken, der auf dem "zweiten" Stockwerk des Gebäudes "G" positioniert ist. Die Elemente in (d. h. Farbe, Zweites und G) sind Attribute, die verwen­ det werden können, um die gewünschte Druckerressource zu spezifizieren. Es ist daher gewünscht, daß ein System in der Lage ist, Attribute wie diese zu nehmen und entspre­ chende Komponenten in einem Netzwerk zu lokalisieren, die mit den spezifizierten Attributen übereinstimmen (oder zu­ mindest beinahe übereinstimmen).

Zum Ausführen dieser umfassenden Funktion sind verschiedene Systeme und Verfahren bekannt. Diese verschiedenen Systeme und Verfahren arbeiten im allgemeinen durch Verwenden einer vorherigen Kenntnis der Adresse oder Position der Komponen­ te, die von einem Dienstanbieter benötigt wird. Ein Lö­ sungsansatz, der als CORBA (common object request brokering architecture = gemeinsame Objektanforderungs- Informationsvermittlungsarchitektur) bekannt ist, verwendet einen Objektanforderungsinformationsvermittler (ORB = ob­ ject request broker), um Objektaufrufe zwischen einem Dienstverbraucher (u. B. Klienten) und einem Dienstanbieter (z. B. Server) zu bearbeiten. Beim Betrieb sendet ein Dienstverbraucher Anforderungen (Anforderungen nach Kompo­ nenten) an den ORB. Unabhängig davon "registrieren" sich Dienstanbieter mit dem ORB, um den ORB über die Komponenten zu informieren, die sie liefern können. Der ORB führt dann eine "Informationsvermittlungs"-Aufgabe durch, die Anforde­ rungen von Dienstverbrauchern mit Fähigkeiten von regi­ strierten Dienstanbietern vergleicht. Falls keine solche Übereinstimmung gefunden wurde, kann der ORB den Dienstver­ braucher darüber informieren. Falls jedoch eine Überein­ stimmung gefunden wird, kann der ORB den Dienstverbraucher (und/oder den Dienstanbieter) informieren, so daß die ange­ forderte Komponente an den Dienstverbraucher gesendet wer­ den kann. Die Einzelheiten darüber, wie dieses Informati­ onsvermitteln spezifisch implementiert ist, können von Sy­ stem zu System variieren, aber es ist im allgemeinen für den Fachmann auf diesem Gebiet bekannt und verständlich. Daher muß es hierin nicht näher beschrieben werden.

Ein anderes Verfahren das zum Ausführen dieser Funktion be­ kannt ist, umfaßt die Verwendung eines Verzeichnisdienstes. In der Tat werden elektronische Verzeichnisse schnell zu einem populären Werkzeug zum Verwalten von Netzwerkressour­ cen. Gedruckte Verzeichnisse können Listen Kennzeichnungs­ informationen umfassen, die es Dienstverbrauchern ermögli­ chen, Komponenten zu finden und leicht auf diese zuzugrei­ fen. Neben anderen Informationen enthalten diese Verzeich­ nisse normalerweise die Netzwerkadresse oder die Position für die darin aufgelistete Komponente.

Frühere elektronische Verzeichnisse wurden typischerweise für eine spezielle Anwendung und ein spezielles Computersy­ stem entwickelt, und waren daher oft nicht mit anderen An­ wendungen oder Systemen kompatibel. Es sind jedoch Proto­ kolle entstanden, die es beinahe jeder Anwendung, die auf praktisch jedem Computersystem läuft, ermöglichen, Ver­ zeichnisinformationen zu erhalten. Das X.500 Verzeichnis- Zugangs-Protokoll (DAP = directory access protocol) liefert beispielsweise eine standardisierte Funktionalität, die Be­ nutzer beim Durchblättern oder Durchsuchen von Verzeichnis­ sen unterstützt, unabhängig von dem Servertyp, auf dem sich das Verzeichnis befindet. Ein weiteres Beispiel eines Ver­ zeichnisprotokolls ist das leichte Verzeichnis-Zugangs- Protokoll (LDAP = Lightweight Directory Access Protocol), eine TCP/IP-basierte Version von X.500 DAP.

Nachfolgend wird kurz auf Fig. 1 Bezug genommen, ein Dia­ gramm, das die herausragenden Merkmale dieser Typen von herkömmlichen Systemen breit darstellt. Fig. 1 stellt grob einen Dienstverbraucher 10, einen Dienstanbieter 12 und ei­ nen Nachschlagedienst 14 dar. Der Nachschlagedienst kann entweder ein elektronisches Verzeichnis oder der ORB in ei­ nem CORBA-System sein. Bei jedem System ist der Nachschla­ gedienst 15 an einer bekannten Stelle vorgesehen, so daß der Dienstanbieter 12 den Nachschlagedienst 14 mit einer Identifizierung der Komponenten des Dienstanbieters 12 lie­ fern kann. Wenn ein Dienstverbraucher 10 solche Komponenten braucht oder wünscht, gibt derselbe eine Anforderung an den Nachschlagedienst 14 aus, um zu bestimmen, ob solche Kompo­ nenten auf dem Netzwerk verfügbar sind. Falls dies der Fall ist, antwortet der Nachschlagedienst 14 im allgemeinen durch Identifizieren der Netzwerkadresse oder Position des Dienstanbieters 12, der solche Komponenten aufweist, so daß der Dienstverbraucher 10 danach direkt mit dem Dienstanbie­ ter 12 eine Schnittstelle bilden kann.

Obwohl Systeme wie diese es einem Dienstverbraucher effek­ tiv ermöglichen, spezifische Komponenten von einem Dienst­ anbieter zu erhalten, ohne daß der Dienstverbraucher eine vorherige Kenntnis der Netzwerkadresse oder Position des Dienstanbieters haben muß, gibt es eine Anzahl von Nachtei­ len, die bei solchen Systemen offenkundig sind. Im wesent­ lichen stellt der Nachschlagedienst 14 eine einzelne Feh­ lerstelle in dem System dar. Daher kann es sein, daß der Dienstverbraucher 10 nicht in der Lage ist, seine Aufgabe zu erfüllen, falls der Nachschlagedienst 14 ausfällt, auch wenn sowohl der Dienstanbieter 12 als auch der Dienstverbraucher 10 richtig funktionieren könnte.

Außerdem stellt der Nachschlagedienst 14 bei solchen Syste­ men außerdem einen Leistungsfähigkeitenpaß dar, und ver­ langsamt den Zugriff auf Komponenten, die durch den Dienst­ anbieter 12 geliefert werden. Da viele Dienste bei dem Nachschlagedienst registriert sein können, müssen Anforde­ rungen nach Diensten im allgemeinen mit der gesamten Liste von registrierten Diensten verglichen werden. Während der Zeit, während diese Vergleiche durchgeführt werden, sind sowohl der Dienstverbraucher als auch der Dienstanbieter oft ungenutzt und nicht in der Lage, nützliche Arbeit zu tun. Außerdem stellt der Nachschlagedienst 14 ein Sicher­ heitsrisiko dar, weil er der ganzen Welt alle die Dienste verkündet, die bei demselben registriert sind. Der Nach­ schlagedienst 14 ist wahrlich ein Werbungsdienst. Es kann jedoch Dienste geben, die ihre Existenz nicht der "Welt" als ganzes bekanntmachen wollen, aber die dennoch ihre Dienste an einige ausgewählte Verbraucher liefern wollen. Obwohl Dienstanbieter konfiguriert sein können, um Dienste für Kunden außerhalb der ausgewählten Gruppe abzulehnen, fügt dies eine zusätzliche Schicht an erforderlicher Kom­ plexität zu dem Dienstanbieter hinzu. Darüber hinaus kann die reine Existenz des Dienstes unerwünschte Angriffe her­ ausfordern.

Dementsprechend wird gewünscht, ein verbessertes System und Verfahren zum Lokalisieren und Zuordnen von entfernten Softwarekomponenten, die über eine verteilte Netzwerkumge­ bung verstreut sind, auf der Basis von spezifizierten At­ tributen und ohne, daß eine vorherige Kenntnis der Adresse oder Position der Komponente erforderlich ist, zu schaffen.

Es ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren zum Lokalisieren und Zuordnen von ent­ fernten Softwarekomponenten in einer verteilten Netzwerkum­ gebung mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und ein System gemäß Anspruch 12 und 20 gelöst.

Bestimmte Aufgaben, Vorteile und neuartige Merkmale der Er­ findung werden teilweise in der folgenden Beschreibung aus­ geführt und werden teilweise dem Fachmann auf diesem Gebiet bei der Untersuchung des folgenden offensichtlich werden, oder können bei der Anwendung der Erfindung erlernt werden. Die Aufgaben und Vorteile der Erfindung können durch die Einrichtungen und Kombinationen, die besonders in den ange­ hängten Ansprüchen aufgeführt sind, realisiert und erhalten werden.

Die vorliegende Erfindung bezieht sich allgemein auf ein System und Verfahren zum Zugreifen auf Softwarekomponenten, Schnittstellen oder Ressourcen in einer verteilten Netz­ werkumgebung. Ein wesentliches Merkmal der Erfindung ist ihre Fähigkeit, solche Komponenten, Schnittstellen oder Ressourcen auf der Basis von spezifizierten Attributen zu lokalisieren, und ohne eine vorherige Kenntnis der Adresse oder Position der Komponente, Schnittstelle oder Ressource zu haben.

Gemäß einem Ausführungsbeispiel umfaßt ein Verfahren die Schritte des Erzeugens einer Anforderung nach einer Kompo­ nente mit zumindest einem spezifizierten Attribut, des Rundsendens der Anforderung über das Netzwerk, des Empfan­ gens der Anforderung an einem Dienstanbieter, des Verglei­ chens des zumindest einen spezifizierten Attributs der emp­ fangenen Anforderung mit Komponentenattributen des Dienst­ anbieters, und des Sendens einer Antwort zu dem anfordern­ den Dienstverbraucher.

Die beiliegenden Zeichnungen, die in der Anmeldung enthal­ ten sind und einen Teil derselben bilden, stellen mehrere Aspekte der vorliegenden Erfindung dar, und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Erfindung zu erklären.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:

Fig. 1 ein Diagramm auf hoher Ebene, das die Art und Weise darstellt, wie herkömmliche Systeme Soft­ warekomponenten in einem Computernetzwerk dyna­ misch lokalisierten.

Fig. 2 ein Diagramm einer veranschaulichenden Netzwerk­ umgebung, über die ein System, das gemäß der vor­ liegenden Erfindung aufgebaut ist, arbeiten kann.

Fig. 3A und 3B gemeinsam ein Diagramm, das die Hauptkom­ ponenten eines Systems darstellt, das gemäß dem bevorzugten Ausführungsbeispiel der Erfindung aufgebaut ist.

Bevor das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung beschrieben wird, werden unmittelbar nachfolgend mehrere Definitionen dargelegt. In dem Maße, in dem diese Begriffe eine spezielle Bedeutung haben können, als ein Be­ griff oder eine Technik oder etwas anderes, der sich von den nachfolgend dargelegten Definitionen unterscheidet, sollen die Definitionen die Interpretation und Bedeutung der Begriffe steuern, wie sie in der Anmeldung und in den Ansprüchen hierin verwendet werden, außer die Anmeldung oder die Ansprüche weisen einem Begriff in einer speziellen Position oder für eine spezielle Anwendung ausdrücklich ei­ ne andere oder begrenztere Bedeutung zu.

Dienstanbieter (Serviceprovider), wie hierin verwendet, be­ zieht sich auf eine Entität auf einem Computernetzwerk, die ein Programm, eine Schnittstelle, einen Dienst oder eine andere Komponente zu einem anfordernden Gerät oder Prozeß liefert.

Dienstverbraucher (Serviceconsumer), wie hierin verwendet, bezieht sich auf eine Entität auf einem Computernetzwerk, die ein Programm, eine Schnittstelle, einen Dienst oder ähnliche Komponente verwendet, die von einem Dienstanbieter geliefert wurde, um eine Aufgabe durchzuführen oder ander­ weitig etwas zu erledigen.

Dienstbeschreiber (Service Deskriptor), wie hierin verwen­ det, bezieht sich auf ein Objekt, eine Tabelle oder ein an­ deres Element, das einen Dienst durch Verwendung von einem oder mehreren Attributen beschreibt oder definiert.

Dienstfindeeinrichtung (Service Finder), wie hierin verwen­ det, bezieht sich auf eine Instanz eines Objekts oder eines getrennten Prozesses, die von einem Dienstverbraucher er­ zeugt oder verwendet wird, um die Entdeckung von einer oder mehreren Komponenten (wie durch einen Servicebeschreiber definiert) eines Dienstanbieters auf einem Netzwerk zu steuern. Die Dienstfindeeinrichtung kann außerdem das Mel­ den der entdeckten Komponenten zu dem Dienstverbraucher steuern.

Obwohl die Erfindung oben zusammengefaßt wurde, bevor auf die Zeichnungen Bezug genommen wurde, wird das folgende Beispiel dargestellt, um den Fortschritt der vorliegenden Erfindung darzustellen. Diesbezüglich wurde ein Beispiel des Netzwerkdruckers und einer Druckanwendung ausgewählt, lediglich um bestimmte erfindungsgemäße Konzepte der vor­ liegenden Erfindung darzustellen. Es sollte jedoch offen­ sichtlich sein, daß die vorliegende Erfindung äußerst weit­ reichende Anwendungen findet, und auf keinen Fall auf einen Drucker oder eine Druckanwendung begrenzt werden sollte, die hierin erörtert wird.

Die Verwendung von Netzwerkdruckern und Druckanwendungen ist gut bekannt. In einer Netzwerkumgebung gibt es oft meh­ rere Drucker, die auf dem Netzwerk verfügbar sind. Aus ei­ ner Benutzerperspektive kann ein Benutzer bei einer gegebe­ nen Anwendung (beispielsweise einer Windowsanwendung) typi­ scherweise einen von einer Anzahl von verfügbaren Druckern auswählen, auf dem die Anwendung drucken kann. Davor wird jedoch das Computersystem, das der Benutzer benutzt, "kon­ figuriert". Während der Konfiguration wird der Computer über die Drucker, die verfügbar sind, angewiesen, und auch über die Position von jedem dieser Drucker auf dem Netz­ werk. Außerdem werden für jeden der verfügbaren Drucker auf dem Computer Treiber installiert. Sobald ein spezieller Drucker ausgewählt wird, und ein Befehl ausgegeben wird, um an einen ausgewählten Drucker zu drucken, arbeitet der Druckertreiber, der auf dem Computer des Benutzers instal­ liert ist, mit einem Treiber zusammen, der auf einem Druck­ server (z. B. dem Computer oder dem Prozeß, der den Netz­ werkdrucker steuert) läuft, um den Auftrag oder die Mate­ rialien, die zum Drucken ausgewählt wurden, zu drucken.

Die vorliegende Erfindung liefert jedoch einen völlig neuen Lösungsansatz für das Drucken (in diesem Zusammenhang) und auch für zahlreiche andere Anwendungen. Diesbezüglich muß ein System, das gemäß der vorliegenden Erfindung konfigu­ riert ist, Computer-Workstationen nicht mit Druckertreibern oder -identifikationen vorkonfigurieren. Statt dessen kön­ nen Netzwerkdrucker in Echtzeit "entdeckt" werden, und kön­ nen verwendet werden, ohne vorher Treiber auf die Computer- Workstationen installieren zu müssen. Das erfindungsgemäße System arbeitet durch Identifizieren von angeforderten Kom­ ponenten (z. B. Druckern) auf der Basis von Attributen, die durch einen Benutzer oder durch eine Workstation spezifi­ ziert werden. Um bei dem Druckerbeispiel zu bleiben, muß ein Benutzer, wenn er Material drucken möchte, und ein Sy­ stem gemäß der vorliegenden Erfindung aufgebaut ist, nur bestimmte Attribute eines gewünschten Druckers definieren.

Man nehme beispielsweise ein lokales Netz einer Firmenumge­ bung. Ein Benutzer, der einen Auftrag oder Material drucken möchte, kann bestimmte Attribute eines gewünschten Druckers benennen, wie z. B., daß der Drucker ein Hochgeschwindig­ keitsfarblaserdrucker ist, der in der Lage ist, auf beiden Seiten des Papiers zu drucken, und in dem vierten Stock des Gebäudes 100 positioniert ist. Ein System, das gemäß der vorliegenden Erfindung aufgebaut ist, würde dann alle sol­ che Drucker identifizieren, die die Anforderung erfüllen, und eine Liste dieser Drucker an den Benutzer (oder die an­ fordernde Anwendung) zurückzusenden, die dann auf der Basis der zurückgesendeten Liste einen Drucker auswählen könnte. Selbstverständlich ist vorzugsweise eine geeignete Ausnah­ mebehandlung in das System eingebaut. Falls daher bei­ spielsweise kein Drucker lokalisiert wurde, der mit jedem der spezifizierten Attribute übereinstimmt, kann das System trotzdem konfiguriert sein, um annähernde Übereinstimmungen zu identifizieren, und an den Benutzer zurückzusenden, da­ mit derselbe davon auswählen kann. Als ein Teil dieser Aus­ nahmebehandlung und dem allgemeinen Systementwurf kann der Benutzer aufgefordert werden, diejenigen Attribute auszu­ wählen, die am wichtigsten sind, so daß der Identifikati­ ons- und Entscheidungsprozeß entsprechend formuliert werden kann. Ferner wird bei einem bevorzugten Ausführungsbeispiel vorzugsweise eine gemeinsame "Ausdrucksweise" zum Spezifi­ zieren von Attributen ausgewählt. Einzelheiten wie diese können jedoch dem Anwendungsprogrammierer überlassen wer­ den, und können in Übereinstimmung mit dem Schutzbereich und der Wesensart der vorliegenden Erfindung von Anwendung zu Anwendung variieren.

Es ist jedoch offensichtlich, daß das System, das gemäß den oben allgemein beschriebenen Lehren aufgebaut ist, im Ver­ gleich zu herkömmlichen Systemen einen enormen Fortschritt liefert. Beispielsweise können neue Drucker zu dem Netzwerk hinzugefügt werden, ohne daß ein Techniker erforderlich ist, der jede einzelne Arbeitsstation besucht, um einen ge­ eigneten Treiber für den neuen Drucker zu installieren oder die Druckerauswahl zu aktualisieren. Falls ferner ein Druc­ ker ausfällt oder anderweitig für einen bestimmten Zeitraum von dem Netzwerk entfernt wird, wäre ein solcher Ausfall oder Entfernung für die Benutzer transparent, da dieser Drucker einfach nicht auf eine Anforderung antwortet, die von einer bestimmten Arbeitsstation gesendet wird, die ei­ nen Druckerdienst anfordert. Für einen Fachmann auf diesem Gebiet werden zahlreiche andere Vorzüge und Vorteile von der hierin gelieferten Offenbarung offensichtlich werden.

Nachfolgend wird auf Fig. 2 Bezug genommen, die ein Dia­ gramm einer veranschaulichenden Netzwerkumgebung ist, über die ein System 100, das gemäß der vorliegenden Erfindung aufgebaut ist, arbeiten kann. Diesbezüglich ist das System 100 mit mehreren Dienstverbrauchern (z. B. 112, 118) darge­ stellt, und auch mit mehreren Dienstanbietern (z. B. 114, 126, 136), die über ein Netzwerk 116 in Kommunikation sind. Die hierin besonders beschriebenen Ausführungsbeispiele stellen das Netzwerk 116 als ein lokales Netz dar. Wie es für einen Fachmann auf diesem Gebiet offensichtlich ist, können die Konzepte und Lehren der vorliegenden Erfindung jedoch leicht auf weite Netze ausgedehnt werden, ein­ schließlich dem Internet. Es ist ferner für einen Fachmann auf diesem Gebiet klar, daß IP-Router oft konfiguriert sind, um Gruppenübertragungen über LAN-Grenzen zu blockie­ ren. Daher können geeignete Konfigurationsänderungen an IP-Routern erforderlich sein, um es zu ermöglichen, daß die Erfindung verwendet wird, um LAN-Grenzen zu überspannen. Da solche Einzelheiten weder das Thema der vorliegenden Erfin­ dung sind, noch für das Verständnis derselben wesentlich sind, müssen sie hierin nicht beschrieben werden.

Bestimmte Hardwarekomponenten, wie z. B. Server 120 und 130, sind ebenfalls dargestellt. Der Server 120 ist als ein Datenbankserver dargestellt. Der Server umfaßt einen Compu­ ter 122 in Kommunikation mit einem Datenbank- oder Spei­ chergerät 124. Selbstverständlich kann das Speichergerät 124 eine Festplatte sein, die in dem Computer 122 positio­ niert ist, aber es wurde in der Zeichnung lediglich zu Dar­ stellungszwecken als getrenntes Gerät dargestellt. Da der Server 120 eine Ressource aufweist, die von anderen Entitä­ ten auf dem Netzwerk 116 angefordert werden kann, umfaßt derselbe einen Dienstanbieter 126, der die Ressourcenkompo­ nente verwaltet. Gleichartig dazu ist der Server 130 als ein Druckserver dargestellt. Der Server umfaßt einen Compu­ ter 132 in Kommunikation mit einem Drucker 134. Da der Ser­ ver eine Ressource (d. h. den Drucker 134) aufweist, der von anderen Entitäten auf dem Netzwerk 116 angefordert wer­ den kann, umfaßt derselbe einen Dienstanbieter 136. Zahl­ reiche zusätzliche Typen von Dienstanbietern können in dem Schutzbereich und der Wesensart der vorliegenden Erfindung enthalten sein, und wurden dennoch hier nicht spezifisch dargestellt. Wie oben kurz erörtert wurde, ist ein Dienst­ anbieter lediglich eine Entität, die eine Ressource, einen Dienst, eine Schnittstelle, ein Programmsegment oder eine andere Komponente an einen Dienstverbraucher liefert, der die Verwendung einer solchen Komponente anfordert.

Diesbezüglich ist Fig. 2 lediglich zu Darstellungszwecken vorgesehen, und sollte nicht als den Schutzbereich der vor­ liegenden Erfindung begrenzend angesehen werden.

Nachfolgend wird auf Fig. 3A und 3B Bezug genommen, die zu­ sammen ein Diagramm umfassen, das die Hauptkomponenten ei­ nes Systems 200 darstellt, das gemäß dem bevorzugten Aus­ führungsbeispiel der Erfindung aufgebaut ist. Um die Zeich­ nung zu vereinfachen, wurde nur ein einzelner Dienstanbie­ ter 212 und ein einzelner Dienstverbraucher 214 darge­ stellt. Zusätzlich zu den Hauptkomponenten des bevorzugten Systems 200 ist die Zeichnung von Fig. 3A und 3B auch zum Darstellen des Verfahrens eines bevorzugten Ausführungsbei­ spiels nützlich. Diesbezüglich beschreibt die unmittelbar nachfolgende Beschreibung das Hauptverfahren eines bevor­ zugten Ausführungsbeispiels. Die verschiedenen Komponenten des Systems sind in dem Zusammenhang und dem Fluß des Ver­ fahrens beschrieben.

Ein früher Schritt des Verfahrens ist das Erzeugen einer Anforderung nach einer Komponente (z. B. Dienst, Schnitt­ stelle, Ressource, Codesegment, usw.) durch einen Dienst­ verbraucher 214, um zu einen Dienstanbieter 212 gesendet zu werden. Abhängig davon, wie die Anwendung auf dem Dienst­ verbraucher 214 ausgeführt wird, kann die Anforderung auto­ matisch (z. B. unter Programmsteuerung) oder unter der Steuerung und Anweisung eines Benutzers erzeugt werden. Beispielsweise, und wie es bei dem obigen Beispiel darge­ stellt ist, kann ein Benutzer, der eine Textverarbeitungs­ anwendung verwendet, und ein Dokument drucken möchte, spe­ zifizieren, daß der gewünschte Drucker ein Hochgeschwindig­ keitsfarblaserdrucker ist, der in der Lage ist, doppelsei­ tige Seiten zu drucken und in einem speziellen Gebäude po­ sitioniert ist. Bei einem solchen Szenario wird die Anfor­ derung teilweise unter der direkten Steuerung des Benutzers erzeugt.

Bei dem bevorzugten Ausführungsbeispiel wird die Anforde­ rung in der Form eines Datenpakets 220 erzeugt, das über das Netzwerk 216 an alle Geräte auf dem Netzwerk rundgesen­ det wird. Die Struktur und der physikalische Aufbau des Da­ tenpakets 220 können variieren. Ein bevorzugtes Datenpaket umfaßt jedoch eine Paket-Identifikation (Paket-ID) 221, ei­ ne Paketversion 222, einen Pakettyp 223, eine Tornummer 224, einen Eintragindex 225 und einen Dienstbeschreiber 226. Bei dem bevorzugten Ausführungsbeispiel ist die Paket- ID 221 eine kurze Zeichenfolge, die das Datenpaket eindeu­ tig identifiziert. Die Paketversion 222 ist eine Ganzzahl­ nummer, die verwendet werden kann, während und falls späte­ re Versionen des Systems entwickelt werden. Der Pakettyp 223 ist vorzugsweise eine Ganzzahl, die anzeigt, ob das Pa­ ket ein Entdeckungspaket (d. h. eine Anforderung), ein Ant­ wortpaket, ein Ankündigungspaket oder ein anderer Typ von Paket ist, der durch das System 200 unterstützt werden kann. Die Tornummer 224 identifiziert das Tor, an das die Antwort geleitet werden sollte. Der Eintragindex 225 ist ein Identifizierer der Handhabungsvorrichtung, an die die Antwort geleitet werden sollte. Schließlich ist der Dienstbeschreiber 226 im wesentlichen eine Hash-Tabelle von Name/Wert-Paaren, die die verschiedenen Attribute definie­ ren, die von dem Dienstverbraucher 214 gesucht werden. Zu­ sätzliche Informationen bezüglich des Dienstbeschreibers 226 werden nachfolgend in Verbindung mit dem Bezugszeichen 230 erörtert.

Bei einem bevorzugten Ausführungsbeispiel kann ein "Ant­ wortzeit"-Feld 227 ebenfalls als Teil des Anforderungspa­ kets enthalten sein. Dieses Feld spezifiziert vorzugsweise eine maximale Zeitperiode für die Antwort. Dienstanbieter erzeugen beim Empfangen eines Anforderungspakets vorzugs­ weise eine Zufallsverzögerungsperiode (bis zu der Periode, die durch das Antwortzeit-Feld eingestellt ist) zum Verzö­ gern der Antwort. Dies trägt dazu bei, Überlastung auf dem Netzwerk zu reduzieren, wenn sehr viele Antworten erzeugt werden. Zusätzliche Felder, die nicht gezeigt sind, können ebenfalls in dem Anforderungspaket enthalten sein, ein­ schließlich ungenutzter Felder, um eine zukünftige Erweite­ rung zu unterstützen.

Es ist offensichtlich, daß das Nachrichtenpaket 220, das in der Zeichnung dargestellt ist, lediglich darstellend gese­ hen werden sollte, und nicht die Erfindung begrenzend. Diesbezüglich kann ein System, das gemäß dem erfindungsge­ mäßen Lehren aufgebaut ist, Anforderungspakete erzeugen oder verwenden, die eine Vielzahl von unterschiedlichen Formen und Strukturen aufweisen. Für die Zwecke des bevor­ zugten Ausführungsbeispiels ist es jedoch wesentlich, daß das Antwortpaket ein oder mehrere Attribute einer Komponen­ te definiert, die durch den Dienstverbraucher 214 angefor­ dert wird.

Wie oben erwähnt wurde, sendet der Dienstverbraucher 214 bei dem bevorzugten Ausführungsbeispiel das Anforderungspa­ ket 220 an alle Geräte auf dem Netzwerk 216. Obwohl es eine Vielzahl von Möglichkeiten gibt, wie eine solche Nachrichtenübertragung implementiert werden kann, wird bei dem bevorzugten Ausführungsbeispiel ein Gruppenprotokoll verwendet. Vorzugsweise werden Anforderungspakete 220 von einem Dienstverbraucher und Verwendung von UDP-Multicast über IP-Netzwerke rundgesendet.

Diesbezüglich und wie es bekannt ist, ist es bei großen Netzwerken manchmal wünschenswert, kurze Nachrichten, die relativ wenig Pakete enthalten, schnell an das Netzwerk zu senden und sicherzustellen, daß jedes Gerät auf dem Netz­ werk die Nachricht entweder mit absoluter Sicherheit oder mit einer sehr hohen Wahrscheinlichkeit empfängt. Ein Sen­ degerät kann die Nachricht zu einer Anzahl von Empfangsge­ räten schicken. Soweit es möglich ist, relativ kurze Nach­ richten zuverlässig zu übertragen, kann ein großes, lose gekoppeltes Netzwerk zentrale Steuerattribute aufweisen, die ähnlich sind wie die Charakteristika von Zentralprozes­ sorsystemen. Eine Möglichkeit zum Sicherstellen von Zuver­ lässigkeit ist es, unter Verwendung eines verbindungsba­ sierten Protokolls, wie z. B. TCP über IP-Netzwerk, mit je­ dem einzelnen empfangenden System zu kommunizieren. Bei ei­ nem verbindungsbasierten Protokoll bildet ein Gerät eine Verbindung zu einem anderen Gerät, wickelt alle Kommunika­ tion mit dem Gerät ab und beendet dann die Verbindung. Falls eine Kommunikation mit mehreren Geräten gewünscht wird, wird abwechselnd eine Verbindung mit jedem System ge­ bildet. Der Mehraufwand im Zusammenhang mit dem Erzeugen und Verwalten einer Verbindung zwischen einem sendenden Sy­ stem und einer Anzahl von empfangenden Systemen ist uner­ schwinglich teuer, wenn es eine große Anzahl von empfangen­ den Systemen gibt.

Um den Mehraufwand im Zusammenhang mit verbindungsbasierten Protokollen zu reduzieren, wurden verbindungslose Protokol­ le, wie z. B. UDP über ein IP-Netzwerk entwickelt. Verbin­ dungslose Protokolle verlassen sich typischerweise auf ein Sende- oder "Multicast bzw. Gruppen"-Modell, bei dem eine einzelne Nachricht zu mehreren empfangende Geräten rundge­ sendet wird, ohne eine Verbindung mit den einzelnen System zu bilden. Dieser Lösungsansatz elimeniert den Mehraufwand im Zusammenhang mit dem Bilden von Verbindungen mit jedem Gerät, aber leidet im allgemeinen an der Unfähigkeit, den Empfang von Nachrichten bei allen Geräten zu garantieren. Für IP-Netzwerke ist Multicast vom Entwurf her unzuverläs­ sig, um den Mehraufwand des Sendens von Paketen zu mehreren Zielen zu reduzieren.

Es wurden andere Nachrichtenprotokolle entwickelt, um das Problem der hohen Zuverlässigkeit im Zusammenhang mit gro­ ßen Nachrichten, die aus hunderttausenden oder Millionen von Paketen bestehen, zu lösen, aber nicht für kurze Nach­ richten mit relativ wenig Paketen. Solche Protokolle senden Daten von einem sendenden System zu mehreren empfangenden Geräten, die in einem IP-Netzwerk verbunden sind, unter Verwendung von IP-Multicast, was den Sendemehraufwand redu­ ziert.

In dem Zusammenhang der vorliegenden Erfindung könnte wie­ der jedes dieser Verfahren verwendet werden. Es wird jedoch ferner offensichtlich, daß eine zuverlässige Übersendung zu jedem einzelnen Gerät nicht wesentlich ist, da kein be­ stimmtes Gerät antworten muß. Vorzugsweise werden Anforde­ rungspakete 220 von einem Dienstverbraucher unter Verwen­ dung von UDP-Multicast über IP-Netzwerke rundgesendet.

Wenn ein bestimmter Dienstanbieter 212 mit Bezugnahme auf die Beschreibung von Fig. 3A und 3B ein Anforderungspaket 220 empfängt, vergleicht derselbe die Attribute, die in dem empfangenen Paket definiert sind, mit Attributen der ver­ schiedenen Komponenten, die der Dienstanbieter 212 auf­ weist, die anderen Geräten auf dem Netzwerk 216 verfügbar gemacht werden können. Diesbezüglich kann der Dienstanbie­ ter 212 einen Dienstbeschreiber für jede einzelne Komponen­ te umfassen, die er aufweist, die anderen Geräten auf dem Netzwerk 216 verfügbar gemacht werden kann. Das Bezugszei­ chen 230 beschreibt einen solchen Dienstbeschreiber. Wie vorher erwähnt wurde, ist ein Dienstbeschreiber im wesent­ lichen eine Hash-Tabelle, die Name/Wert-Paare enthält, die verwendet werden können, um verschiedene Attribute zu spe­ zifizieren. Bei dem dargestellten Dienstbeschreiber können Elemente wie Dienstname, Serverhost, Servername, Betriebs­ systemname und Betriebssystemversion in dem Dienstbeschrei­ ber 230 enthalten sein. Zusätzlich kann eine Vielzahl von Attributen auch in dem Dienstbeschreiber 230 definiert oder spezifiziert sein. Wieder gibt es eine große Anzahl und zahllose Typen von Attributen, die abhängig von der Anwen­ dung in verschiedenen Dienstbeschreibern definiert sein können. Solche Attribute werden für einen Fachmann auf die­ sem Gebiet auf der Basis des Zusammenhangs einer bestimmten Anwendung offensichtlich sein. Daher muß hier keine er­ schöpfende Auflistung von Attributen aufgeführt werden.

Sobald ein Anforderungspaket 220 von einem Dienstanbieter 212 empfangen wird, vergleicht der Dienstanbieter 212 die Attribute, die in dem Dienstbeschreiber 226 des empfangenen Pakets spezifiziert sind, mit den Attributen, die in den Dienstbeschreibern (z. B. 230) der verschiedenen Komponen­ ten des Dienstanbieters 212 spezifiziert sind. Falls alle der Attribute, die in dem Dienstbeschreiber 226 des Anfor­ derungspakets spezifiziert sind, in einem Dienstbeschreiber 230 einer Komponente des Dienstanbieters 212 enthalten sind, erzeugt der Dienstanbieter 212 eine Antwort, die an­ zeigt, daß derselbe die spezifizierte Komponente an den Dienstverbraucher 214 liefern kann. In Übereinstimmung mit der Erfindung kann der Dienstanbieter 212 konfiguriert sein, um eine ähnliche Antwort zu erzeugen, obwohl alle At­ tribute der Anforderung, die durch den Dienstbeschreiber 226 spezifiziert wurden, vielleicht nicht in einem einzigen Dienstbeschreiber 230 des Dienstanbieters 212 enthalten sind. Statt dessen kann der Dienstanbieter 212 konfiguriert sein, um eine Antwortnachricht zu erzeugen, falls bei­ spielsweise ein bestimmter Prozentsatz von Attributen, die in dem Dienstbeschreiber 226 der Anforderung spezifiziert sind, in einem einzelnen Dienstbeschreiber 230 in dem Dienstanbieter 212 gefunden werden. In Übereinstimmung mit der Erfindung können andere variierende Algorithmen verwen­ det werden, beim Bestimmen, wenn ein Dienstanbieter 212 ei­ ne Antwortnachricht zum Zurücksenden an den Dienstverbrau­ cher 214 erzeugen soll.

Wenn der Dienstanbieter 212 in Übereinstimmung mit dem Ver­ fahren des bevorzugten Ausführungsbeispiels bestimmt hat, das eine geeignete "Übereinstimmung" gefunden wurde (z. B. eine ausreichende Anzahl von Attributen, die in dem Dienstbeschreiber 226 der Anforderung spezifiziert sind, werden in einem Dienstbeschreiber 230 des Dienstanbieters 212 gefunden), dann wird durch den Dienstanbieter 212 ein Antwortnachrichtenpaket 240 erzeugt. Anders als das Nach­ richtenpaket 220 bei dem bevorzugten Ausführungsbeispiel wird das Antwortpaket 240 nicht an alle Geräte auf dem Netzwerk 216 gesendet. Statt dessen wird es nur zu dem an­ fordernden Dienstverbraucher 214 gesendet. Diesbezüglich kann die Antwort über eine Unicast-Nachricht gesendet wer­ den. In Übereinstimmung mit der Erfindung kann die Antwort jedoch auf eine Vielzahl von Arten und Weisen gesendet wer­ den, einschließlich durch eine zuverlässige Antwort unter Verwendung von TCP.

Gemäß der Erfindung kann das Antwortpaket 214 in einer Vielzahl von Formen oder Strukturen implementiert werden. Bei einem bevorzugten Ausführungsbeispiel umfaßt ein Ant­ wortpaket jedoch eine Paket-ID 241, eine Paketversion 242, einen Pakettyp 243, einen Eintragindex 244, einen Dienstbeschreiber 245 und eine Dienstschnittstelle 246. Die meisten dieser Elemente wurden in Verbindung mit dem Ant­ wortpaket 220 beschrieben, und müssen nicht erneut be­ schrieben werden. Es ist jedoch wesentlich, anzumerken, daß der Dienstbeschreiber 245 ein Duplikat des Dienstbeschrei­ bers 230 sein kann, der eine Übereinstimmung mit dem Dienstbeschreiber 226 zu sein schien. Durch Senden des Dienstbeschreibers 230 als ein Teil des Antwortpakets 240 kann der anfordernde Dienstverbraucher 214 die endgültige Bestimmung durchführen, ob der Dienstbeschreiber 230 eine geeignete "Übereinstimmung" für die Komponente ist, die durch den Dienstverbraucher 214 angefordert wurde. Falls der Dienstbeschreiber 246 diesbezüglich fünf Attribute spe­ zifiziert hat, und der Dienstbeschreiber 230 nur drei die­ ser Attribute enthielt, kann der Dienstanbieter 212 dies so ansehen, als daß eine "Übereinstimmung" gefunden wurde. Es kann jedoch sein, daß es der Dienstverbraucher 214 nicht als eine Übereinstimmung ansieht, wobei derselbe die Ant­ wort 240 löschen könnte.

Das Antwortpaket 240 umfaßt außerdem eine Dienstschnitt­ stelle (eine serialisierte Stub-Einrichtung) 246. Bei dem bevorzugten Ausführungsbeispiel ist diese Dienstschnitt­ stelle 246 als ein Segment von Java-Code implementiert, das den Code liefert, der zum Bilden einer Schnittstelle mit der angeforderten Komponente des Dienstanbieters 212 not­ wendig ist. Vorteilhafterweise elimeniert dies die Notwen­ digkeit, den Dienstverbraucher 214 mit einem Treiber für die angeforderte Komponente vorzukonfigurieren. Zusätzlich, und obwohl nicht explizit dargestellt, kann die Antwort au­ ßerdem eine Identifikation der Netzwerkadresse oder Positi­ on des Dienstanbieters umfassen. In Übereinstimmung mit der Erfindung kann diese "Stub-Einrichtung" jedoch auf eine Vielzahl von Weisen geliefert werden. Diesbezüglich muß die Stub-Einrichtung bei einem bevorzugten Ausführungsbeispiel einen Verbraucher nur mit ausreichend Informationen versor­ gen, um eine Verbindung mit dem Dienstanbieter zu erstellen und die Dienste desselben zu verwenden. In einigen Fällen können diese Informationen lediglich eine IP-Adresse, eine Tornummer und Verfahren umfassen, die beteiligt sein kön­ nen.

Es sei darauf hingewiesen, daß für jede bestimmte Anforde­ rung, die von einem Dienstverbraucher 214 rundgesendet wird, eine Vielzahl von Antworten empfangen werden kann. Der Dienstverbraucher 214 umfaßt daher die funktionale Fä­ higkeit zum Bearbeiten einer solchen Vielzahl von Antwor­ ten. Diese funktionale Fähigkeit kann das Löschen von über­ schüssigen Antworten, das Auferlegen einer "Auszeit"- Periode für das Empfangen von Antworten und andere Handha­ bungsdinge umfassen.

Nach dem Empfang der Antwort(en) kann der Dienstanbieter 214 danach direkt mit dem Dienstanbieter 212 kommunizieren, um die gemeinsame Verwendung der Komponente, die von dem Dienstanbieter geliefert wird, zu koordinieren. Auch hier kann diese Einzelheit auf eine Vielzahl von Weisen imple­ mentiert werden, und liegt überwiegend in dem Ermessen des Programmierers für die spezielle Anwendung.

Bei dem dargestellten Ausführungsbeispiel umfaßt der Dienstverbraucher 214 eine Dienstfindeeinrichtung 250, die verantwortlich ist für das Erzeugen einer Anforderung, das Horchen nach Antworten, Verdichten von Antworten, Melden von Antworten an den Dienstverbraucher, usw. Bei einem Aus­ führungsbeispiel kann die Dienstfindeeinrichtung 250 ein getrennter Prozeß sein, der unter dem Dienstverbraucher läuft. Bei dem bevorzugten Ausführungsbeispiel ist die Dienstfindeeinrichtung 250 jedoch ein Beispiel mit getrenn­ ten Teilprozessen für die Ausführung. Wie dargestellt ist, umfaßt die Dienstfindeeinrichtung 250 ein Segment 252 zum Erzeugen eines Anforderungspakets. Dieses Segment 252 ist verantwortlich für das Spezifizieren eines Dienstbeschrei­ bers, das Spezifizieren von zumindest einem Attribut, das in dem Anforderungspaket enthalten sein soll. Die Dienstfindeeinrichtung 250 umfaßt außerdem ein Segment 254, das verantwortlich ist für das "Horchen" nach Antworten, nachdem das Anforderungspaket über das Netzwerk 216 rundge­ sendet wird. Die Dienstfindeeinrichtung 250 umfaßt außerdem ein Segment 256 zum Empfangen und Verdichten von Antworten, die empfangen werden. Dieses Segment 256 kann eine "Aus­ zeit"-Periode auferlegen, während der es nach Antworten "horcht". Die Antworten werden dann in einem Vektor ver­ dichtet, der an den Dienstverbraucher 24 weitergeleitet werden kann. Die Dienstfindeeinrichtung 250 umfaßt ein wei­ teres Segment 258, das den Stifter der Antworten an den Dienstverbraucher 214 meldet.

Wie der Dienstverbraucher 214 umfaßt der Dienstanbieter 212 vorzugsweise einen Mechanismus zum Handhaben des Empfangs von Anforderungen und der Erzeugung von Antworten. Bei dem dargestellten Ausführungsbeispiel wird dieser durch den Dienstantworter 260 gehandhabt. Wie die Dienstfindeeinrich­ tung 250 kann der Dienstantworter 260 ein getrennter Prozeß sein. Bei dem bevorzugten Ausführungsbeispiel ist der Dien­ stantworter 260 ein Objekt mit getrennten Teilprozessen für die Ausführung. Neben anderen Funktionen umfaßt der Dienst­ anbieter 260 ein Segment 262 zum Empfangen von Gruppenan­ forderungen. Der Dienstantworter 260 umfaßt außerdem ein Segment 264 zum Vergleichen des Dienstbeschreibers der emp­ fangenen Anforderungen mit einem Dienstbeschreiber 230 je­ der Komponente des Dienstanbieters 212. Der Dienstantworter 260 umfaßt ein weiteres Segment 266 zum Erzeugen von Ant­ wortpaketen, die an den anfordernden Dienstverbraucher 214 gesendet werden.

Aus dem Vorhergehenden ist offensichtlich, daß die Erfin­ dung ein neuartiges System und Verfahren zum Zugreifen auf entfernte Softwarekomponenten in einer Computernetzwerkum­ gebung schafft. Das Verfahren eines bevorzugten Ausfüh­ rungsbeispiels umfaßt die Schritte des Erzeugens einer An­ forderung für eine Komponente mit zumindest einem spezifi­ zierten Attribut, des Rundsendens der Anforderung über das Netzwerk, des Empfangens der Anforderung an einem Dienstan­ bieter, des Vergleichens des zumindest einen spezifizierten Attributs der empfangenen Anforderung mit Komponentenattri­ buten des Dienstanbieters und des Sendens einer Antwort an den anfordernden Dienstverbraucher. Es sollte ferner offen­ sichtlich sein, daß das System und Verfahren des bevorzug­ ten Ausführungsbeispiels verschiedene Unzulänglichkeiten und Nachteile von herkömmlichen Systemen beseitigt. Insbe­ sondere eliminiert das System des bevorzugten Ausführungs­ beispiels die Notwendigkeit eines zentralen Informations­ vermittlers oder eines zentralen Verzeichnisdienstes. Folg­ lich verbessert die Eliminierung dieses zentralen Elementes die Fehlertoleranz des Systems durch Vermeiden des einzel­ nen Fehlerpunktes, der durch solch eine zentrale Komponente eingeführt wird.

Claims (20)

1. Verfahren zum Zugreifen auf eine entfernte Software­ komponente (124, 134) durch einen Dienstverbraucher (214) in einem verteilten Netzwerk-System mit zumin­ dest einem Dienstverbraucher (112, 118, 214) und zu­ mindest einem Dienstanbieter (114, 126, 136, 212), wo­ bei das Verfahren folgende Schritte umfaßt:
Erzeugen (252) einer Anforderung (220) nach einer Kom­ ponente mit zumindest einem spezifizierten Attribut;
Rundsenden der Anforderung (220) über das Netzwerk (216);
Empfangen (262) der Anforderung bei einem Dienstanbie­ ter (212);
Vergleichen (264) des zumindest einen spezifizierten Attributs der empfangenen Anforderung mit Komponenten­ attributen (230) des Dienstanbieters (212); und
Übertragen (266) einer Antwort (240) zu dem anfordern­ den Dienstverbraucher (214).

2. Verfahren gemäß Anspruch 1, bei dem die Softwarekompo­ nente (124, 134) aus der Gruppe ausgewählt wird, die aus einem Dienst, einer Ressource, einer Schnittstelle und einem Programmsegment besteht.

3. Verfahren gemäß Anspruch 1 oder 2, bei dem der Schritt des Erzeugens (252) einer Anforderung (220) das Formu­ lieren eines Dienstbeschreibers (226) umfaßt, wobei der Dienstbeschreiber (226) ein Objekt ist, das das zumindest eine spezifizierte Attribut spezifiziert.

4. Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem der Schritt des Rundsendens der Anforderung (220) ein Multicast-Protokoll zum Senden der Anforderung (220) über das Netzwerk (216) verwendet.

5. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das Netzwerk (216) ein lokales Netz ist.

6. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das Netzwerk ein weites Netz ist.

7. Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem der Schritt des Übertragens einer Antwort (240) ein Unicastprotokoll verwendet.

6. Verfahren gemäß einem der Ansprüche 1 bis 7, das fer­ ner den Schritt des Formulierens einer Antwort (240) durch den Dienstanbieter (214) umfaßt, wobei die Ant­ wort eine Identifikation einer Netzwerkposition des Dienstanbieters (212) umfaßt.

9. Verfahren gemäß Anspruch 8, das ferner den Schritt des direkten Anforderns der Komponente von dem Dienstan­ bieter (212) durch den Dienstverbraucher (214) umfaßt, ansprechend auf die Antwort (240), die von dem Dienst­ verbraucher (214) empfangen wird.

10. Verfahren gemäß Anspruch 8 oder 9, bei dem der Schritt des Formulierens einer Antwort (240) ferner das Zuord­ nen eines Codes zu der Antwort umfaßt, zum schnitt­ stellenmäßigen Verbinden der angeforderten Komponente, ohne daß es erforderlich ist, daß ein Treiber getrennt auf dem Dienstverbraucher (214) installiert wird.

11. Verfahren gemäß Anspruch 10, bei dem der Code zum schnittstellenmäßigen Verbinden mit dem angeforderten Code Java-Code in der Form eines Stub-Objektes ist.

12. Verteiltes Netzwerksystem zum Zugreifen auf eine ent­ fernte Softwarekomponente, das folgende Merkmale um­ faßt:
zumindest einen Dienstverbraucher (214);
zumindest einen Dienstanbieter (212);
eine Einrichtung zum Erzeugen (252) einer Anforderung (220) bei einem Dienstverbraucher (214) nach einer Komponente mit zumindest einem spezifizierten Attri­ but;
eine Einrichtung zum Rundsenden der Anforderung über das Netzwerk (216);
eine Einrichtung zum Empfangen (262) der Anforderung an einem Dienstanbieter (212);
eine Einrichtung zum Vergleichen (264) des zumindest einen spezifizierten Attributs der empfangenen Anfor­ derung mit Komponentenattributen (230) des Dienstan­ bieters (212); und
eine Einrichtung zum Übertragen einer Antwort (240) zu dem anfordernden Dienstverbraucher (214).

13. System gemäß Anspruch 12, das ferner eine Einrichtung zum Erzeugen der Antwort (240) umfaßt.

14. System gemäß Anspruch 13, bei dem die Einrichtung zum Erzeugen der Antwort (240) konfiguriert ist, um in der Antwort (240) einen Mechanismus zum Identifizieren ei­ ner Netzwerkposition für die Komponente zu umfassen.

15. System gemäß Anspruch 13, bei dem die Einrichtung zum Erzeugen der Antwort (240) konfiguriert ist, um in der Antwort (240) ein Codesegment zu umfassen, das es dem Dienstverbraucher (214), der die Anforderung erzeugt hat, ermöglicht, mit der Komponente schnittstellenmä­ ßig verbunden zu werden, ohne einen getrennt instal­ lierten Treiber auf dem Dienstverbraucher (214) zu ha­ ben.

16. System gemäß Anspruch 15, bei dem das Codesegment Ja­ va-Code in der Form eines Stub-Objektes umfaßt.

17. System gemäß einem der Ansprüche 13 bis 16, bei dem die Einrichtung zum Rundsenden der Anforderung (220) ein Multicast-Protokoll umfaßt.

18. System gemäß einem der Ansprüche 13 bis 17, bei dem die Einrichtung zum Erzeugen einer Anforderung (220) eine Dienstfindeeinrichtung (250) umfaßt.

19. System gemäß einem der Ansprüche 13 bis 18, das ferner eine Einrichtung zum Verdichten von Antworten (240) und Liefern der verdichteten Antworten an den Dienst­ verbraucher (214) umfaßt.

20. Verteiltes Netzwerksystem zum Zugreifen auf eine ent­ fernte Softwarekomponente (124, 134), das folgende Merkmale umfaßt:
zumindest einen Dienstverbraucher (214);
zumindest einen Dienstanbieter (212);
einen Mechanismus, der konfiguriert ist, um eine An­ forderung (220) bei einem Dienstverbraucher (214) nach einer Komponente mit zumindest einem spezifizierten Attribut zu erzeugen;
einen Mechanismus, der konfiguriert ist, um die Anfor­ derung (220) über das Netzwerk (216) rundzusenden;
einen Mechanismus, der konfiguriert ist, um die Anfor­ derung (220) bei einem Dienstanbieter (212) zu empfan­ gen;
einen Mechanismus, der konfiguriert ist, um das zumin­ dest eine spezifizierte Attribut der empfangenen An­ forderung (220) mit Komponentenattributen des Dienst­ anbieters (212) zu vergleichen; und
einen Mechanismus, der konfiguriert ist, um eine Ant­ wort (240) zu dem anfordernden Dienstverbraucher (214) zu übertragen.