-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht sich auf Datenverarbeitungssysteme
und insbesondere auf die Definition des Umfangs eines Suchvorganges, wie
er durch ein CORBAServices-FactoryFinder-Objekt in einer objektorientierten
Programmierungsumgebung realisiert wird.
-
Hintergrund
der Erfindung
-
Die
Entwicklung von Anwendungs- und Systemsoftware für Datenverarbeitungssysteme
war bisher in der Regel eine zeitaufwendige und von vergleichsweise
vielen Wiederholungen geprägte
Aufgabe, bei der Software-Entwickler häufig Code für die Ausführung bekannter Benutzerschnittstellen-
und Systemfunktionen schreiben bzw. neu schreiben und zusätzlich den
Code schreiben mussten, mit dem die gewünschte neue Funktionalität realisiert
werden sollte. In jüngster
Zeit setzte sich die objektorientierte Programmierung (Object-Oriented Programming, OOP)
als beherrschendes neues Programmierungsmuster durch, das die schnelle
Entwicklung und Realisierung einer Funktionalität bei gleichzeitiger Anpassung
und Wiederverwendung von Objekten gestattet.
-
Die
Leistungsfähigkeit
der OOP als ein Denkmuster für
die Software-Entwicklung wird in erster Linie durch Objektstrukturen
erzielt, die eine Zusammenstellung grundlegender Objektklassen bereitstellen,
die von einem Systementwickler nach Wahl verwendet werden können, um
auf ähnliche
Art und Weise, wie ein Hardware-Entwickler aus standardmäßigen Hardwarekomponenten
einen Tischcomputer aufbaut, ein Softwaresystem zu erzeugen. Objektstrukturen
sind besonders vorteilhaft, wenn sie innerhalb einer verteilten
Rechenumgebung verwendet werden, in der mehrere möglicherweise
heterogene Computersysteme miteinander verbunden sind, um so die
gemeinsame Nutzung von Hardware- und Softwaresystemressourcen durch
Computersysteme zu ermöglichen.
Damit in unterschiedlichen Sprachen geschriebene Programme Objektklassen
verwenden können,
die im Rahmen einer einzigen Objektstruktur definiert wurden, muss
ein Mindestmaß an
Objektstandardisierung entwickelt werden, um so – zumindest bis zu einem gewissen
Grad – das
Zusammenwirken von objektorientierter Software zu ermöglichen.
Eine Organisation, die sich mit der Erstellung von Branchenrichtlinien
und Objektverwaltungsspezifikationen beschäftigt, um eine gemeinsame Objektstruktur
für die
Anwendungsentwicklung bereitzustellen, ist die Objektverwaltungsgruppe
(Object Management Group, OMG). Die von der OMG erarbeiteten Spezifikationen
ermöglichen
die Wiederverwendung, Übertragung
und das Zusammenwirken von objektbasierter Software in heterogenen
verteilten Rechenumgebungen (Heterogeneous Distributed Computing
Enviroments, HDCE). Ein Beispiel für eine handelsübliche Objektstruktur,
die OMG-Spezifikationen entspricht, ist das Objektmodell für verteilte
Systeme (Distributed System Object Model, DSOM), das beispielsweise
in „SOM
Objects Toolkit version 3.0 Programmer's Guide, Volume 1: SOM and DSOM", erhältlich von
der International Business Machines Corporation, beschrieben wird.
-
In "Life Cycle Services
Specification",
OMG Joint Object Services Submission, 2. Juli 1993, sowie in "CORBAservices: Common
Object Services Specification",
OMG Dokument Nr. 95-3-31,
definiert die OMB einen Branchenstandard für Lebenszyklusdienste. Im Rahmen
des OMG-Standards für
Lebenszyklusdienste werden eine Reihe von objektorientierten Schnittstellen
definiert, welche die Erzeugung und Löschung von Objekten innerhalb
einer heterogenen verteilten Rechenumgebung (HDCE) unterstützen. Zu
den Schnittstellen, die durch den OMG-Standard für Lebenszyklusdienste eingeführt werden,
gehört
auch die FactoryFinder-Schnittstelle, die einen Standarddienst bereitstellt,
mit dem Anwendungen innerhalb der heterogenen verteilten Rechenumgebung
(HDCE) ein Factory-Objekt
(d.h. ein Objekt, das zur Erzeugung von Instanzen anderer Objekte
dient) auffinden können.
-
Die
Schnittstelle FactoryFinder der OMG führt eine Operation mit der
Bezeichnung find_factories ein, die eine IDL-Sequenz (Interface Definition
Language, Schnittstellenbeschreibungssprache) von Factory-Objekten
zurückgibt,
welche die in einem Eingabeparameter factory_key festgelegten Eingabekriterien
erfüllt.
In heterogenen verteilten Datenverarbeitungssystemen mit hunderten
oder tausenden von Objekten, von denen viele einem bestimmten factory_key
entsprechen, kann die Anzahl der in der Sequenz zurückgegebenen
Factory-Objekte sehr groß sein.
Aus diesem Grund möchte
der Benutzer unter Umständen
den Umfang der FactoryFinder-Methode find_factory auf eine bestimmte
Gruppe von Servern beschränken,
um so zu steuern, welche Factory-Objekte
zurückgegeben
werden.
-
Obwohl
es äußerst wünschenswert
ist, das Verhalten der FactoryFinder-Methode durch die Beschränkung der
Aktivitäten
auf einen bestimmten Standortumfang zu steuern, definieren die OMG-Spezifikationen
keine Standardschnittstelle, mit der ein Benutzer einen Standortumfang
angeben kann. Obwohl der Standortumfang in einem FactoryFinder-Objekt
gekapselt sein könnte,
wäre für jedes FactoryFinder-Objekt
eine eigene Realisierung erforderlich und die Änderung des Umfangs während der Laufzeit
wäre ein
kein einfaches Unterfangen. Aus diesem Grund wäre die Bereitstellung einer
Schnittstelle wünschenswert,
mit der sich ein Standortumfang definieren lässt, und insbesondere einer
Schnittstelle, die mit der OMG-Schnittstelle
FactoryFinder kompatibel ist und die somit als Umfang für FactoryFinder-Operationen
verwendet werden kann. Wünschenswert
ist auch die Möglichkeit,
einem FactoryFinder-Objekt
oder einer beliebigen Anzahl von FactoryFinder-Objekten ein Standortobjekt
zuweisen zu können,
um so einen Standortumfang für
das Verhalten des FactoryFinder-Objekts bzw. der FactoryFinder-Objekte
vorzugeben.
-
Zusammenfassung
der Erfindung
-
Gemäß einem
ersten Aspekt stellt die Erfindung ein in einem Computersystem realisiertes
Verfahren zur Erzeugung einer Schnittstelle bereit, mit welcher
der Umfang von Suchvorgängen
nach Objekt-Factories in einer objektorientierten Umgebung definiert
werden kann, das folgende Schritte beinhaltet: Definieren eines
abstrakten Standortobjekts in der objektorientierten Umgebung; Definieren
einer Standortteilklasse des abstrakten Objekts, wobei die Teilklasse über Realisierungslogik
für Serverdarstellungen
in der objektorientierten Umgebung verfügt; und Zuweisen einer Vielzahl
von Servern in der objektorientierten Umgebung zu der Standortteilklasse, um
so den Umfang des Standorts für
Suchvorgänge nach
Factory-Objekten festzulegen.
-
Gemäß einem
zweiten Aspekt stellt die Erfindung eine Vorrichtung für die Erzeugung
einer Schnittstelle bereit, mit welcher der Umfang von Suchvorgängen nach
Objekt-Factories in einer objektorientierten Umgebung definiert
werden kann, die Folgendes beinhaltet: ein Mittel für die Definition
eines abstrakten Standortobjekts in der objektorientierten Umgebung;
ein Mittel für
die Definition einer Standortteilklasse des abstrakten Objekts,
wobei die Teilklasse über
Realisierungslogik für
Serverdarstellungen in der objektorientierten Umgebung verfügt; sowie
ein Mittel für
die Zuweisung einer Vielzahl von Servern in der objektorientierten
Umgebung zu der Standortteilklasse, um so den Umfang des Standorts für Suchvorgänge nach
Factory-Objekten festzulegen.
-
Gemäß einer
bevorzugten Ausführungsform stellt
diese Erfindung ein Verfahren und eine Vorrichtung für die Steuerung
eines Standortumfangs für
ein FactoryFinder-Objekt bereit. FactoryFinder-Objekte stellen eine
standardmäßige Art
und Weise dar, wie ein Programm ein Factory-Objekt, das für die Erzeugung
eines anderen Objekts in einem objektorientierten System verwendet
wird, finden kann. Dabei kann der Standortumfang aus einer bestimmten
Einheit, allen Einheiten innerhalb einer Arbeitsgruppe, allen unter
einem bestimmten Betriebssystem ausgeführten Objekt-Server-Prozessen
usw. bestehen. Eine abstrakte Standortschnittstelle wird bereitgestellt,
die in Teilklassen untergliedert werden kann, um ein Standortobjekt
bereitzustellen. Die abstrakte Standortschnittstelle wird von allen
anderen Standortschnittstellen geerbt. Die abstrakte Schnittstelle
führt eine
Methode ein, mit der alle Server innerhalb des Umfangs zurückgegeben
werden, der durch das Standortobjekt definiert wird. Das Standortobjekt stellt
mindestens Methoden bereit, mit denen eine Liste von Servern zurückgegeben
wird, die den vollständigen
Umfang des Standorts angibt, mit denen ein Boolescher Wert WAHR
oder FALSCH für
eine Anfrage bezüglich
eines bestimmten Servers zurückgegeben
wird und mit denen ein neues Standortobjekt erstellt wird und Server
registriert werden, die sich aus einer Schnittmenge/Vereinigungsmenge
der Server ergeben, die durch den aktuellen Standort und einen weiteren
Standort eingeschlossen sind.
-
Kurze Beschreibung
der Zeichnungen
-
1 ist
eine veranschaulichende Ausführungsform
eines heterogenen verteilten Datenverarbeitungssystems gemäß der vorliegenden
Erfindung;
-
2 ist
ein Schaubild eines Computers/eines Arbeitsplatzrechners innerhalb
des verteilten Datenverarbeitungssystems aus 1;
-
3 ist
eine bildliche Darstellung der verallgemeinerten Softwarekonfiguration
von zwei Knoten innerhalb einer heterogenen verteilten objektorientierten
Rechenumgebung;
-
4 zeigt
eine grafische Klassendarstellung, welche die Klassenbeziehung zwischen
einem FactoryFinder-Objekt gemäß der OMG
und einem Standortobjekt zeigt;
-
5 zeigt
eine bildliche Darstellung für
den Zugriff auf ein Standortobjekt durch ein Clientobjekt von einem
FactoryFinder-Objekt aus, wenn ein Clientobjekt die find_factories-Methode
eines FactoryFinder-Objekts aufruft;
-
6 zeigt
ein Abfolgediagramm, das darstellt, wie ein FactoryFinder-Objekt
anhand eines Standortobjekts den Umfang seiner Methoden steuert;
-
7 ist
ein Ablaufdiagramm für
die Definition eines Standortobjekts und dessen Verwendung zur Definition
des Standortumfangs für
verschiedene FactoryFinder-Objekte;
-
8 ist
ein Standortobjekt und zeigt die möglichen Methoden des Standortobjekts;
und
-
9 ist
ein Standortobjekt und zeigt die grundlegenden (Mindest-)Merkmale
des Standortobjekts.
-
Ausführliche
Beschreibung der Ausführungsformen
-
Gemäß einer
bevorzugten Ausführungsform stellt
diese Erfindung ein Verfahren und eine Vorrichtung für ein Standortobjekt
bereit, das in einem FactoryFinder-Objekt gemäß der OMG (Object Management
Group) enthalten ist. Anhand von Standortobjekten wird der Standortumfang
definiert, innerhalb dessen ein Objekt vorhanden ist. Für einen
Benutzer kann der Standortumfang eine bestimmte Einheit, alle Einheiten
innerhalb einer Arbeitsgruppe, alle unter einem bestimmten Betriebssystem
ausgeführten Objekt-Server-Prozesse
usw. sein. Im Rahmen eines verteilten Objektsystems ist ein Standort
ein äußerst konkretes
Konzept, das unmittelbar mit der Realisierung des Objektanfragenvermittlers
(Object Request Broker, ORB) für
das System verknüpft
ist. So kann ein bestimmter ORB beispielsweise den Standort definieren,
an dem ein Objekt in Form eines Objekt-Server-Prozesses vorhanden
ist, der durch einen bestimmten, eindeutigen Realisierungsbezeichner kenntlich
gemacht wird. Das Standortobjekt hat die Aufgabe, die Kluft zwischen
der Sichtweise des Benutzers von dem Standort und der Art und Weise,
wie das verteilte Objektsystem den Standort sieht, zu überbrücken. So
können
anhand eines Standortobjekts z.B. alle Einheiten einer Arbeitsgruppe
(Benutzersichtweise) definiert werden, während eine Liste aller eindeutigen
Realisierungsbezeichner für
alle Objekt-Server-Prozesse bereitgestellt wird, die innerhalb dieses
Umfangs vorhanden sind (Sichtweise des verteilten Objektsystems).
Im Folgenden wird diese Erfindung anhand der 1 bis 9 ausführlicher
beschrieben.
-
Eine
repräsentative
Hardware-Umgebung, in der diese Erfindung in die Praxis umgesetzt
werden kann, ist in 1 abgebildet, die eine bildliche
Darstellung eines verteilten Datenverarbeitungssystems 8 zeigt.
Wie abgebildet, enthält
das Datenverarbeitungssystem 8 eine Vielzahl von Netzwerken,
unter anderem die lokalen Netze (Local Area Network, LAN) 10 und 32,
von denen jedes vorzugsweise eine Vielzahl einzelner Computer 12 bzw. 30 beinhaltet. Dabei
weiß der
Fachmann, dass für
jedes derartige Netzwerk eine Vielzahl von mit einem Hostprozessor verbundenen
Arbeitsstationen verwendet werden können. Wie bei derartigen Datenverarbeitungssystemen üblich kann
jeder Computer 12 und 30 mit einer Speichereinheit 14 und
einem Drucker 16 verbunden sein.
-
Das
Datenverarbeitungssystem 8 beinhaltet ferner einen oder
mehrere Großrechner
wie beispielsweise den Großrechner 18,
der vorzugsweise über
eine Datenübertragungsverbindung 22 mit
dem LAN 10 verbunden sein kann. Der Großrechner 18 ist vorzugsweise
mit einer Speichereinheit 20 verbunden, die als entfernter
Speicher für
das LAN 10 dient. Das LAN 10 ist außerdem über die
Datenübertragungsverbindung 24,
die Datenübertragungssteuereinheit 26 und
die Datenübertragungsverbindung 34 mit
dem Verbindungsserver 28 verbunden. Der Verbindungsserver 28 ist
vorzugsweise ein Arbeitsplatzrechner, der das LAN 32 über die
Datenübertragungsverbindung 35 mit
dem LAN 10 verbindet. Dabei ist dem Fachmann bewusst, dass
das Datenverarbeitungssystem 8 zusätzlich nicht abgebildete Verbindungsrechner,
Leitwegeinheiten, Überleiteinheiten
und verschiedene andere Netzwerkhardware beinhaltet, mit denen die
einzelnen Bestandteile des Datenverarbeitungssystems 8 miteinander
verbunden werden.
-
2 zeigt
eine bildliche Darstellung eines Arbeitsplatzrechners mit einer
Zentraleinheit 40 wie beispielsweise einem herkömmlichen
Mikroprozessor und einer Anzahl anderer Einheiten, die über einen
Systembus 42 miteinander verbunden sind. Der Arbeitsplatzrechner
aus 2 beinhaltet einen Direktzugriffsspeicher (Random
Access Memory, RAM) 44, einen Festwertspeicher (Read Only
Memory, ROM) 46, einen E/A-Adapter 48 für die Verbindung von
Peripheriegeräten
wie beispielsweise einer Platteneinheit 43 mit dem Bus,
einen Benutzerschnittstellenadapter 52 für die Verbindung
einer Tastatur 47, einer Maus 53, eines Lautsprechers 54,
eines Mikrofons 49 und/oder sonstiger Benutzerschnittstelleneinheiten
wie beispielsweise einer (nicht abgebildeten) Berührungsbildschirmeinheit
mit dem Bus, einen Datenübertragungsadapter 45 für die Verbindung des
Arbeitsplatzrechners mit einem Datenverarbeitungsnetzwerk und einen
Anzeigeadapter 51 für
die Verbindung des Busses mit der Anzeigeeinheit 50. In der
bevorzugten Ausführungsform
befinden sich auf dem Arbeitsplatzrechner das Betriebssystem OS/2 und
die Computersoftware, aus der diese Erfindung besteht und die in
Form eines Satzes von Dienstprogrammen enthalten ist. Dabei weiß der Fachmann, dass
die Verfahren dieser Erfindung in Form eines Computerprogrammprodukts
auf einem computerlesbaren Medium vorliegen können, das vorübergehend
oder dauerhaft auf einen Festplattenspeicher 43, eine Diskette 41 oder
in den RAM 44 der Arbeitsstation geladen werden kann.
-
3 zeigt
eine bildliche Darstellung der verallgemeinerten Softwarekonfiguration
zweier Knoten 56 und 57 innerhalb einer heterogenen
verteilten Rechenumgebung (HDCE) wie z.B. dem Datenverarbeitungssystem 8.
Wie abgebildet führen
die Knoten 56 und 57, die zwei der Computer 12 innerhalb
des Datenverarbeitungssystems 8 umfassen können, unter
der Steuerung durch möglicherweise
verschiedenartige Betriebssysteme 60 bzw. 65 Software
aus. Obwohl die Knoten 56 und 57 verschiedenartige
Betriebssysteme verwenden können,
wird die Datenübertragung
zwischen den Knoten 56 und 57 über das Netzwerk 66 durch
die Netzwerktransportschichten 59 und 64 ermöglicht,
die beispielsweise das TCP/IP-Referenzmodell (Transport Control
Protocol/Interface Program) umfassen können. Die Softwarekonfigurationen
der Knoten 56 und 57 umfassen weiter eine verteilte
Objektumgebung 58 und 63 mit den Objekten A, B,
C und D. Um die Interaktion zwischen den Objekten A bis D innerhalb
der verteilten Objektumgebung 58 und 63 darzustellen,
soll das Objekt A eine Methode für
die Objekte B und C aufrufen, wobei das Objekt D als ein Parameter
weitergeleitet wird, und die Objekte B und C sollen zu derselben
Klasse gehören.
Wenn das Objekt A das Objekt B aufruft, bei dem es sich um ein lokales
Objekt handelt, erfolgt die gesamte Interaktion zwischen den Objekten
A, B und D innerhalb desselben lokalen Prozesses und unter strikter
Steuerung durch die Sende- und Referenzmechanismen des lokalen Prozesses.
Wenn das Objekt A dagegen das Objekt C aufruft, bei dem es sich
um ein entferntes Objekt handelt, wird der Aufruf an das Proxy-Objekt
C weitergeleitet, das mit dem Aufbereitungscode 61 und
der Transportstruktur 62 zusammenwirkt, um die Aufrufparameter
in einer Nachricht mit einem Format zu packen, das sich für die Übertragung über das
Netzwerk 66 eignet. Als Reaktion auf den Empfang der Nachricht
im Knoten 57 leitet die Netzwerktransportschicht 64 die
Nachricht an die Transportstruktur 67 und den Aufbereitungscode 68 weiter,
der die Parameter decodiert, um so den Aufruf von Objekt C wiederherzustellen.
Danach wird ein Proxy-Objekt D erzeugt, und das Objekt C wird so
aufgerufen, als wäre es
ein lokales Objekt in Bezug auf Objekt A. Etwaige Anfragen von Objekt
C an Objekt D werden über
das Proxy-Objekt D auf ähnliche
Art und Weise verarbeitet. Wie aus dieser Beschreibung einer verteilten
Objektumgebung hervorgeht, kann ein Objekt auf transparente Art
und Weise mit anderen Objekten innerhalb der verteilten Objektumgebung
zusammenwirken, wobei dies unabhängig
davon ist, ob sich die anderen Objekte in einem lokalen oder entfernten
Knoten befinden oder ob die Objekte zu ein und demselben Prozess
gehören.
-
4 zeigt
eine Beziehung 70 zwischen einem FactoryFinder-Objekt 72 und
einem Standortobjekt 76. Das FactoryFinder-Objekt 72 enthält kein („0") oder ein einzelnes
(„1") Standortobjekt 76.
Das Standortobjekt 76 kann von einer beliebigen Anzahl („0" bis „N") von FactoryFinder-Objekten 72 enthalten sein.
Die Standortschnittstelle ist abstrakt und für die Untergliederung in Teilklassen
vorgesehen.
-
5 zeigt
eine grafische Darstellung 80, die den Fluss zwischen Objekten
zeigt, wenn ein Client-Objekt 82 eine find_factories-Methode 100 für ein FactoryFinder-Objekt 84 aufruft,
das über
ein bei ihm registriertes Standortobjekt A 86 verfügt. Das
Client-Objekt 82 ruft die find_factories-Methode 100 für das FactoryFinder-Objekt 84 auf.
Das FactoryFinder-Objekt 84 ruft die list_server_ids-Methode 110 für das Standortobjekt
A 86 auf, bei dem es sich um ein Standortobjekt handelt,
das anhand der set_location_scope-Methode 104 bei dem FactoryFinder-Objekt 84 registriert
wurde. Das Standortobjekt A 86 gibt die Liste der Server 112 zurück, die
es dem FactoryFinder-Objekt 84 vorlegt. Das FactoryFinder-Objekt 84 sucht
nach Factory-Objekten, die der vom Client-Objekt 82 bereitgestellten
Spezifikation entsprechen. Dabei werden nur Factory-Objekte berücksichtigt,
die sich auf einem vom Standortobjekt A 86 zurückgegebenen
Server befinden (d.h. die Server aus der Liste 112). Das
FactoryFinder-Objekt 84 gibt dem Client-Objekt 82 eine
Liste der Factory-Objekte 98 zurück, die sich innerhalb des
Standortumfangs des Standortobjekts 86 befinden und den
Client-Anforderungen entsprechen.
-
6 zeigt
ein Abfolgediagramm, das darstellt, wie ein FactoryFinder-Objekt
anhand eines Standortobjekts den Umfang seiner Methoden steuert.
Dabei ist die find_factories-Methode des FactoryFinder-Objekts auf
den Umfang beschränkt,
der durch das bei ihm registrierte Standortobjekt vorgegeben wird.
Dabei wird im Rahmen dieser Erfindung „registrieren" im Sinne von „enthalten
sein" verwendet.
Als Ergebnis der Beschränkung
berücksichtigt die
find_factories-Methode nur Factory-Objekte, die Objektinstanzen
auf dem Server erzeugen können, der
bei dem Standortobjekt registriert ist. Mit Blick auf 6 ruft
ein Client-Objekt die find_factories-Methode 130 für ein FactoryFinder-Objekt
auf, das über
ein bei ihm registriertes Standortobjekt verfügt. Die find_factories-Methode
reicht einen Schlüsselparameter
ein, der den zu erzeugenden Objekttyp sowie verschiedene andere
zu der Factory-Suche gehörige Informationen
angibt, wobei dies von der Realisierung des FactoryFinder-Objekts
abhängig
ist. Das FactoryFinder-Objekt ruft die list_server_ids-Methode 132 für das bei
ihm registrierte Standortobjekt A auf, um so eine Liste der Server 134 zu
erhalten, die den Umfang der find_factories-Operation definieren. Das
FactoryFinder-Objekt führt
sämtliche
internen Verarbeitungsschritte durch, die unter Umständen notwendig
sind, um die Parameter 136 für die Factory-Suche zu erzeugen,
wobei die erhaltenen Standortdaten mit einbezogen werden. Das FactoryFinder-Objekt
wirkt mit der Sucheinheit 138 zusammen und reicht dabei
die erforderlichen Parameter ein, um so die Factory-Objekte ausfindig
zu machen, die den Anforderungen entsprechen. Der Factory-Suchmechanismus
gibt die gefundenen Factory-Objekte 140 an das FactoryFinder-Objekt
zurück.
Bei dieser Darstellung werden zwei Factory-Objekte (f1, f2) innerhalb
der Beschränkungen
des Standortumfangs gefunden, die sämtliche Anforderungen des Client-Objekts
erfüllen.
Die beiden Factory-Objekte werden von dem FactoryFinder-Objekt an
den Client 142 zurückgegeben,
um so die Anforderungen des Client-Objekts zu erfüllen.
-
7 zeigt
ein Ablaufdiagramm für
die Definition eines Standortobjekts und dessen Verwendung zur Definition
des Standortumfangs für
verschiedene FactoryFinder-Objekte. Das Verfahren beginnt mit Schritt 150 und
fährt sofort
mit Block 152 fort, an dem das Verfahren ein abstraktes
Standortobjekt mit den Standardverhaltensweisen definiert, die für alle Teilklassen
des Standorts gelten sollen. Auf dieser Ebene sind keine Einzelheiten
zur Realisierung notwendig, da der Großteil der Logik auf der Teilklassenebene
angesiedelt ist. In Block 154 werden Teilklassen des abstrakten
Standorts definiert, um eine Realisierung für die verschiedenen Serverdarstellungen
bereitzustellen, die in der Umgebung vorhanden sind. Beispielsweise
könnte
es eine Teilklasse geben, die Serverkennungen als Zeichenfolgen
definiert, während
eine andere Teilklasse Serverdarstellungen als Objekte verarbeitet.
In Block 156 werden Server bei den Standorteilklassen registriert,
um so den Umfang eines jeden Standorts zu definieren. Der Registrierungsprozess
weist dem Umfang ein Standortobjekt zu, wobei dem Fachmann jedoch
klar sein dürfte, dass
es neben der Registrierung eine Vielzahl anderer Optionen gibt,
die von der für
die Realisierung zuständigen
Person festgelegt werden können.
Der wichtigste Aspekt des Registrierungsprozesses besteht darin,
dass ein Mechanismus vorhanden ist, mit dem der Umfang der Standortteilklasse
definiert werden kann, so dass die Standortteilklasse die Server auflisten
kann, die als ihr Umfang kenntlich gemacht sind. In Block 158 wird
die Standortteilklasse bei einem FactoryFinder-Objekt registriert,
um den Umfang für
verschiedene Aktivitäten,
die von dem FactoryFinder-Objekt durchgeführt werden, zu definieren. Dabei
kann eine Standortteilklasse bei einer beliebigen Anzahl von FactoryFinder-Objekten
registriert werden.
-
8 zeigt
ein Standortobjekt 160 und die Merkmale, die bei einem
Standortobjekt wünschenswert
sind, das unter Verwendung eines Registrierungsmechanismus Server
als Bestandteil der Standortteilklasse definiert. Der interne Speichermechanismus 178,
anhand dessen das Standortobjekt 160 die Liste seiner Server
verwaltet, ist von der jeweiligen Realisierung abhängig und
wird durch die konkreten Teilklassen bestimmt. So können die
Serverkennungen bei einer Standortteilklasse beispielsweise als
Zeichenfolgen und bei einer anderen durch Objekte dargestellt werden.
Die in 8 definierten Methoden gelten für alle Teilklassen,
die einen Registrierungsmechanismus verwenden. Dabei können die
Methoden allerdings auf der abstrakten Ebene definiert und auf der
Teilklassenebene realisiert werden. Beispiele für Methoden für ein Standortobjekt 160,
das einen Registrierungsmechanismus verwendet, lauten wie folgt:
- 1) list_servers 164: Diese Methode
gibt eine Liste der Server zurück,
die bei dem Standortobjekt registriert sind.
- 2) add_server 174: Diese Methode registriert den Server,
der von dem Standortobjekt eingereicht wurde.
- 3) remove_server 162: Diese Methode beendet den Registrierungsstatus
des Servers, der an den Standortserver 160 eingereicht
wurde.
- 4) add_servers 166: Diese Methode registriert die Gruppe
von Servern, die durch das Standortobjekt 160 angegeben
wird.
- 5) remove_servers 168: Diese Methode beendet den Registrierungsstatus
der angegebenen Gruppe von Servern.
- 6) is_server_location 176: Diese Methode gibt einen
Booleschen Wert WAHR zurück,
wenn der angegebene Server bei dem Standortobjekt 160 registriert
ist; wenn dies nicht der Fall ist, gibt sie einen Booleschen Wert
FALSCH zurück.
- 7) location_union 172: Diese Methode erzeugt ein neues
Standortobjekt und registriert die Server, die das Ergebnis einer
Vereinigungsmenge der bei dem aktuellen Standort registrierten Server mit
den Servern sind, die bei einem anderen, vom Benutzer festgelegten
Standort registriert sind.
- 8) location_intersection 170: Diese Methode erzeugt
ein neues Standortobjekt und registriert die Server, die das Ergebnis
einer Schnittmenge der bei dem aktuellen Standort registrierten
Server mit den Servern sind, die bei einem anderen, vom Benutzer
festgelegten Standort registriert sind.
-
Dabei
weiß der
Fachmann, dass dem Standortobjekt abhängig von der Umgebungsstruktur
und den Erfordernissen des Benutzers weitere Methoden hinzugefügt werden
können.
-
9 zeigt
die grundlegenden Merkmale eines Standortobjekts 180 mit
einem Mindestsatz an Methoden, wobei dies unabhängig davon ist, ob ein Registrierungsmechanismus
verwendet wird. Alle Standortobjekte sollten mindestens einen Auflistungsmechanismus
wie die list_servers-Methode 182 bereitstellen, die dem
Aufrufer den Standortumfang des Standortobjekts 180 angibt.
Andere zur Steigerung des Benutzerkomforts dienende Methoden wie location_union 188, location_intersection 184 und is_server_in_location 186 sind
nützlich,
um dem Benutzer Daten bereitzustellen.
-
Obwohl
die Erfindung mit Blick auf eine bevorzugte Ausführungsform beschrieben wurde,
dürfte
dem Fachmann klar sein, dass verschiedene Änderungen an Einzelheiten hiervon
vorgenommen werden können,
ohne von Umfang und Lehre der Erfindung abzuweichen. Das Standortobjekt
dieser Erfindung bietet breit gefächerte Nutzungsmöglichkeiten,
da es durch ein beliebiges Objekt verwendet werden kann, das die
Operationen auf einen festgelegten Umfang beschränken möchte. So ist das Standortobjekt
beispielsweise bei Verwaltungsaufgaben von Nutzen, da es Administratoren
einen Mechanismus für
die Ressourcenkontrolle zur Hand gibt, indem es beschränkt, wo
Objekte für
eine Servergruppe, die durch ein Standortobjekt definiert ist, erzeugt werden
können.
Die Fähigkeit
zur Steuerung des Objektverhaltens durch die Verwendung eines Standortobjekts,
mit dem Methodenaktivitäten
beschränkt werden,
ist in umfangreichen verteilten Umgebungen äußerst wünschenswert. Das Konzept ist äußerst leistungsfähig und
lässt sich
auf verschiedenste Art und Weise anwenden, um so die geschäftlichen
Anforderungen von Benutzern zu erfüllen.