-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf verteilte Rechnerumgebungen
einschließlich
Web-zentrierter und Internet-zentrierter Rechnerumgebungen, und
genauer gesagt auf das Überbrücken einer
heterogenen, verteilten Rechnerumgebung auf der Basis eines Nachrichtenübergebenden
Modells für
die Verbindung von Netzwerk-Clients und Diensten mit anderen Umgebungen
(30) auf der Basis anderer Modelle.
-
2. Beschreibung der verwandten
Technik
-
Intelligente
Einrichtungen bzw. Geräte
finden zunehmend Verbreitung. Solche Einrichtungen reichen von intelligenten
Geräten
bzw. Apparaten, Persönlichen
Digitalen Assistenten (PDAs), Mobiltelefonen, Laptop-Computern,
Desktop-Computern, Arbeitsplatzrechnern bis zu Mainframes bzw. Großcomputern;
sogar Super-Computern. Netzwerke werden auch zu einem zunehmend
verbreiteten Mittel, um intelligente Einrichtungen miteinander zu
verbinden, so daß sie
miteinander kommunizieren können.
Es bestehen jedoch große
Unterschiede bei der Computerleistung und den Speicherfähigkeiten
der verschiedenen intelligenten Einrichtungen. Einrichtungen mit
beschränkteren
Fähigkeiten
können
als Schmalspur-Einrichtungen oder "Thin"-Devices bezeichnet
werden. Thin-Devices
sind möglicherweise
nicht in der Lage, an Netzwerken, die leistungsfähigere Einrichtungen miteinander
verbinden, teilzunehmen. Es kann aber dennoch wünschenswert sein, eine breite Vielfalt
von verschiedenen Arten von intelligenten Einrichtungen miteinander
zu verbinden.
-
Der
Wunsch, die Netzwerkfähigkeiten
zu verbessern, nimmt weiter zu. Geschäfts- bzw. Firmennetzwerke werden
erweitert, um eine direkte Interaktion mit den Lieferanten bzw.
Zulieferern und Kunden aufzunehmen. Mobiltelefone, Persönliche Digitale
Assistenten und Internet-fähige
Computer sind sowohl in Unternehmen als auch zuhause alltäglich. Netzwerke
im Haus stehen zur Verbindung von Audio-/Video-Ausrüstung wie
Fernsehgeräten
und Stereoanlagen mit Heimcomputern und anderen Einrichtungen zum
Steuern intelligenter Systeme wie Sicherheitssysteme und Temperaturkontrollthermostate
zur Verfügung.
Medien mit hoher Bandbreite wie Kabel und ADSL ermöglichen
verbesserte Dienste wie Internetzugang für Video-on-Demand, E-Commerce
etc. Netzwerksysteme werden allgegenwärtig. Auch ohne ein formelles
bzw. förmliches
Netzwerk ist es bei intelligenten Einrichtungen dennoch wünschenswert,
miteinander zu kommunizieren und Ressourcen gemeinsam zu nutzen.
-
Derzeit
sind herkömmliche
Netzwerke kompliziert aufzubauen, zu erweitern und zu verwalten.
Zum Beispiel erfordert das Hinzufügen von Hardware oder Software
zu einem Netzwerk häufig
einen Netzwerk-Administrator, um Treiber zu laden und Systeme zu
konfigurieren. Kleine Änderungen
an einer Netzwerk-Konfiguration vorzunehmen, kann es erfordern,
daß das
gesamte Netzwerk für
eine Zeitspanne heruntergefahren wird. Darüber hinaus kann es sein, daß bestimmte
intelligente Einrichtungen die benötigten Schnittstellen nicht unterstützen, um
auf einem gegebenen Netzwerk zu kommunizieren.
-
Was
benötigt
wird, ist eine einfache Möglichkeit,
verschiedene Arten von intelligenten Einrichtungen anzuschließen bzw.
zu verbinden, um eine Kommunikation und das gemeinsame Nutzen von
Ressourcen zu ermöglichen,
während
die bei herkömmlichen
Netzwerken vorhandenen Interoperabilitäts- und komplizierten Konfigurationsprobleme
vermieden werden. Es gibt verschiedene Technologien, um das Hinzufügen von
Einrichtungen zu einem Netzwerk zu verbessern. Zum Beispiel helfen
viele moderne I/O-Busse wie der Universelle Serielle Bus, 1394 und
PCI Plug&Play
oder dynamische Discovery- bzw. Entdeckungsprotokolle dabei, das
Hinzufügen
einer neuen Einrichtung an dem Bus zu vereinfachen. Jedoch sind
diese Lösungen
auf spezielle Peripheriebusse beschränkt und sind für allgemeine
Netzwerk nicht geeignet.
-
Eine
neuere Technologie, Jini von Sun Microsystems Inc., ist darauf ausgerichtet,
die Verbindung und die gemeinsame Nutzung von Einrichtungen wie
Druckern und Plattenlaufwerken in einem Netzwerk zu vereinfachen.
Eine Einrichtung, die Jini einbezieht bzw. umfaßt, kann sich selbst dem Netzwerk
gegenüber
bekannt machen, kann einige Einzelheiten über ihre Fähigkeiten bereitstellen bzw. übergeben
und kann sofort für
andere Einrichtungen in dem Netzwerk zugänglich werden. Jini ermöglicht verteilte
Verarbeitung, wobei die Fähigkeiten
der verschiedenen Einrichtungen in einem Netzwerk gemeinsam genutzt
werden. Die Jini-Technologie strebt an, Benutzer in die Lage zu
versetzen, Dienste und Ressourcen über ein Netzwerk gemeinsam zu
nutzen. Ein anderes Ziel der Jini-Technologie ist es, Benutzern
einen einfachen Zugang zu bzw. Zugriff auf Ressourcen irgendwo im
Netzwerk zu gewähren,
während
die Anordnung bzw. die Lokation des Benutzers im Netzwerk sich ändern kann.
Jini strebt auch an, die Aufgabe der Errichtens, Unterhaltens und Änderns eines Netzwerkes
von Einrichtungen, Software und Benutzern zu vereinfachen.
-
Jini
erfordert, daß jedes
Jini-fähige
Gerät eine
bestimmte Menge von Speicher und Rechenleistung hat. Typischerweise
ist eine Jini-fähige
Einrichtung mit einer virtuellen Java-Maschine ausgerüstet. Daher
sind Jini-Systeme auf die Java-Technologie ausgerichtet. Java ist
eine objektorientierte, hohe Programmiersprache, die von Sun Microsystems
Inc. entwickelt wurde. Java-Quellcode kann in ein Bytecode genanntes
Format kompiliert werden, das dann von einer virtuellen Java-Maschine ausgeführt werden
kann.
-
Bytecode
ist Computerquellcode, der von einer virtuellen Maschine anstelle
des "realen" Computers, des Hardwareprozessors,
verarbeitet wird. Die virtuelle Maschine wandelt verallgemeinerte
Maschinenbefehle (den Bytecode) in spezifische Maschinenbefehle
um (Befehle, die der Prozessor des Computers versteht). Unter Verwendung
einer Sprache, die mit einer virtuellen Maschine für jede Plattform
geliefert wird, brauchen die Quellsprachenanweisungen nur einmal
kompiliert werden und können
danach auf jeder Plattform ablaufen, die die virtuelle Maschine
unterstützt.
Die Programmiersprache Java ist ein Beispiel einer solchen Sprache,
und die Virtuelle Java-Maschine (JVM) ist ein Beispiel einer virtuellen
Maschinenplattform, die in der Programmiersprache Java geschriebene
Programme unterstützt.
-
Da
virtuelle Java-Maschinen für
die meisten Computerplattformen bereitgestellt werden können, sorgen
Java und somit Jini in einem gewissen Umfang für Plattformunabhängigkeit.
Die Jini-Architektur setzt die Voraussetzung wirksam ein, daß die Programmiersprache
Java die Implementationssprache für die Komponenten des Jini-Systems
ist. Die Fähigkeit,
Java-Code dynamisch herunterzuladen und ablaufen zu lassen, ist zentral
für viele
Eigenschaften bzw. Fähigkeiten
der Jini-Architektur.
-
Der
Zweck der Jini-Architektur ist, Gruppen von Einrichtungen bzw. Geräten und
Softwarekomponenten zu einem einzelnen, dynamisch verteilten System
zu vereinigen bzw. zu verbünden.
Ein Schlüsselkonzept innerhalb
der Jini-Architektur ist das eines Dienstes. Ein Dienst ist eine
Einheit bzw. eine Instanz, die von einer Person, einem Programm
oder einem anderen Dienst verwendet werden kann. Zwei Beispiele
von Diensten sind das Drucken eines Dokumentes und das Übersetzen
von einem Textverarbeitungsformat in ein anderes. Jini ermöglicht es
den Mitgliedern eines Jini-Systems, den Zugang zu bzw. den Zugriff
auf Dienste(n) gemeinsam zu nutzen. Dienste in einem Jini-System
kommunizieren miteinander unter Verwendung eines Dienstprotokolls,
welches ein Satz bzw. eine Menge von Schnittstellen ist, die in
der Programmiersprache Java geschriebenen sind. Dienste werden in
einem Jini-System von einem Nachschlagedienst bzw. Nachschlagedienst
gefunden und aufgelöst.
Ein Nachschlagedienst bildet Schnittstellen, die die von einem Dienst
bereitgestellte Funktionalität
angeben, auf Mengen von Objekten ab, die den Dienst implementieren.
-
Beschreibende
Einträge
können
auch einem Dienst zugeordnet sein. Einrichtungen und Anwendungen
verwenden einen Prozeß,
der als die Entdeckung bzw. Discovery bekannt ist, um sich bei dem
Jini-Netzwerk zu registrieren. Sobald die Einrichtung oder die Anwendung
registriert ist, setzt bzw. stellt sie sich in den Nachschlagedienst.
Der Nachschlagedienst kann nicht nur Zeiger auf diese Dienste in
dem Netzwerk speichern, sondern kann auch den Code für den Zugriff
auf diese Dienste speichern. Wenn sich zum Beispiel ein Drucker
bei dem Nachschlagedienst registriert, lädt er seinen Druckertreiber
und/oder eine Schnittstelle zu dem Treiber in den Nachschlagedienst.
Wenn ein Client den Drucker verwenden möchte, werden der Treiber und
die Treiberschnittstelle aus dem Nachschlagedienst in den Client
heruntergeladen. Diese Codemobilität bedeutet, daß Clients
aus den Diensten des Netzwerkes einen Vorteil ziehen bzw. sich die
Dienste des Netzwerks zunutze machen können, ohne Treiber oder andere
Software vorab zu installieren oder zu laden.
-
Die
Kommunikation zwischen den Diensten in einem Jini-System wird erreicht,
indem ein abgesetzter bzw. entfernter Methodenaufruf von Java (Java
Remote Method Invocation, RMI) verwendet wird. RMI ist eine für die Programmiersprache
Java angepaßte
Erweiterung für
herkömmliche
Mechanismen zum abgesetzten bzw. entfernten Prozeduraufruf. RMI
erlaubt es nicht nur, daß Daten
von Objekt zu Objekt in dem Jini-Netzwerk übergeben werden, sondern auch
vollständige
Objekte, die auch Code enthalten. Jini-Systeme hängen von dieser Fähigkeit
ab, Code über
das Netzwerk in einer Form herumzuschieben, die in einem Java-Objekt
eingekapselt ist.
-
Zugriff
auf Dienste in einem Jini-System beruht auf Pacht bzw. Überlassung.
Eine Pacht bzw. Überlassung
bzw. ein Leasing ist ein Einräumen
eines garantierten Zugriffs für
eine Zeitspan ne. Jede Überlassung wird
zwischen einem Benutzer des Dienstes und dem Anbieter des Dienstes
als Teil des Dienstprotokolls ausgehandelt. Ein Dienst kann für eine Zeitspanne
angefordert werden und der Zugriff kann für eine gewisse Zeitspanne wahrscheinlich
entsprechend der angeforderten Zeitspanne gewährt werden. Überlassungen
müssen erneuert
werden, damit ein Dienst Teil des Jini-Systems bleibt.
-
1 stellt
den grundlegenden Stock der Jini-Technologie dar. Die Jini-Technologie
definiert ein verteiltes Programmiermodell 12 (unterstützt von
JavaSpaces, Überlassungen
und Objektmustern). Die Objektkommunikation in Jini basiert auf
einer RMI-Schicht 14 über
einer TCP/IP-fähigen
Netzwerkschicht 16.
-
Jini
ist eine vielversprechende Technologie zur Vereinfachung verteilter
Verarbeitung. Für
bestimmte Arten von Einrichtungen ist Jini jedoch möglicherweise
nicht geeignet. Die IT-Landschaft bewegt sich in Richtung eines
verteilten, Web-zentrierten Dienst- und Inhaltmodels, bei dem sich
die Zusammensetzung von Clientdiensten und Inhalt schnell verändert. Der
Client der Zukunft kann ein begleiterartiges Gerät sein, das Benutzer mit sich
nehmen, wo immer sie hingehen. Solch ein Gerät kann zum Beispiel eine Kombination
eines Mobiltelefons und eines PDA sein. Es wäre für eine solche Einrichtung bzw.
ein solches Gerät
wünschenswert, wenn
es in der Lage wäre,
sowohl mit anderen Einrichtungen, die leistungsfähiger sind, zu kommunizieren
und Ressourcen gemeinsam zu nutzen, als auch mit "dünneren" oder weniger leistungsfähigen Einrichtungen.
-
Darüber hinaus
wird mit dem Aufkommen des Internet und der daraus resultierenden
Explosion der mit dem Netz verbundenen Einrichtungen ein verteiltes
Programmiermodell benötigt,
das dafür
ausgestaltet ist, dieses Phänomen
wirksam einzusetzen. Es wird eine geeignete Technologie benötigt, die
es Clients erleichtert, sich mit Diensten in einer zuverlässigen und
sicheren Weise in Verbindung zu setzen. Verschiedene Clients von "dick" zu "dünn" und Dienste müssen über das Internet, Firmen-Internets
oder sogar innerhalb einzelner Computer verbunden werden. Es ist
wünschenswert,
die Entfernung, Verzögerung
und Implementierung sowohl von Clients als auch von Diensten zu
abstrahieren.
-
Der
Schüssel
der Herausforderung für
eine verteilte IT-Technologie ist es, von mächtigen bzw. leistungsstarken
Thick-Clients hinunter bis zu sehr schmalen Thin-Clients wie eingebettete
mobile Einrichtungen skalierbar zu sein. Aktuelle verteilte IT-Technologien
wie Jini sind möglicherweise
nicht für
die Anforderungen aller Arten von Clients skalierbar genug. Einigen
Einrichtungen wie Einrichtungen mit kleiner Basis bzw. schwacher
Ausstattung oder eingebetteten Einrichtungen fehlen möglicherweise
ausreichende Speicherressourcen und/oder ausreichende Netzwerkbandbreiten,
um zufriedenstellend an aktuellen verteilten IT-Technologien teilzunehmen.
Das untere Ende des Clientspektrums einschließlich eingebetteter mobiler
Einrichtungen hat häufig
beschränkte
oder feste Codeausführungsumgebungen.
Diese Einrichtungen können
auch minimale oder nicht dauerhafte Speicherfähigkeiten haben. Die meisten
kleinen, eingebetteten mobilen Einrichtungen unterstützen keine
virtuelle Java-Maschine. Die meisten codierbaren kleinen Clients
lassen nur eigenen Code ablaufen. Darüber hinaus haben die meisten
kleinen Clients wenig mehr als Flashspei cher oder batteriegestützten RAM
als ihr einziges dauerhaftes Speichermedium. Die Größe des Speichers
ist häufig
sehr klein und manchmal nur lesbar. Mehr noch ist die Zugriffszeit
für diese
Art von Speichermedien häufig
um eine Größenordnung
größer als
die Zugriffszeit auf Festplatten in Clients, die leistungsfähiger sind.
-
Bestehende
Verbindungstechnologien wie Jini sind möglicherweise nicht so skalierbar
wie gewünscht, weil
sie zu umfangreich sind. Zum Beispiel ist es bei Jini erforderlich,
daß alle
Teilnehmer Java unterstützen; viele
kleine Clients haben jedoch möglicherweise
nicht die Ressourcen für
eine virtuelle Java-Maschine. Darüber hinaus erfordert es Jini
wegen seiner Verwendung von RMI, daß Clients in der Lage sind,
Code und Inhalt herunterzuladen. Jini kann die vorhandene Clientplattform
durch das Herunterladen neuer Klassen erweitern, was Sicherheits-
und Größenbedenken
für kleine
Einrichtungen wie eingebettete Einrichtungen aufwerfen kann. Jini
arbeitet bzw. funktioniert, indem Clients und Ressourcen durch die Übergabe
von Code und Daten kommunizieren. Wenn ein Client einen Jini-Dienst
aktiviert, kann der Dienst seine Ergebnisse an den Client zurückgeben,
was eine große
Menge von Code oder Inhalt umfassen kann. In Jini kann ein Client
eine Methode aufrufen, und ein großes Objekt kann zurückgeliefert
und somit heruntergeladen werden. Der Client hat möglicherweise
nicht die Ressourcen, das zurückgelieferte
Objekt anzunehmen. Darüber
hinaus benötigen RMI
und Java selbst eine Menge Speicher. Viele Einrichtungen mit kleiner
Standfläche
haben eventuell nicht die Ressourcen, um effektiv oder überhaupt
an aktuellen verteilten IT-Technologien
teilzuhaben.
-
Ein
andere Sorge bei bestehenden verteilten IT-Technologien ist, daß sie häufig bestimmte
Stufen von Verbindungsmöglichkeiten
und -protokollen erfordern. Zum Beispiel setzt Jini das Vorhandensein
eines Netzwerks von angemessener Geschwindigkeit zur Verbindung
von Computern und Einrichtungen voraus. Jini erfordert auch, daß Einrichtungen
das TCP/IP-Netzwerk-Transportprotokoll unterstützen. Jedoch haben viele kleinere
Einrichtungen möglicherweise
beschränkte
Verbindungsfähigkeiten.
Kleine Einrichtungen können eine
hohe Verzögerung
oder Netzwerkverbindungen mit niedriger Geschwindigkeit haben und
TCP/IP eventuell nicht unterstützen.
-
Wie
oben erwähnt
erfordert Jini es, daß Einrichtungen
Java unterstützen
und somit eine Virtuelle Java-Maschine enthalten, was eine gewisse
Menge von Rechen- und Speicherfähigkeiten
erfordert, die bei vielen kleinen Einrichtungen womöglich nicht
vorhanden ist. Dies schränkt
auch die Flexibilität
von Jini dahingehend ein, daß Nicht-Java-Einrichtungen
nicht direkt an einem Jini-System
beteiligt sein können.
Da Jini Java benötigt,
kann man es sich als eine homogene Umgebung vorstellen. Es ist jedoch
wünschenswert,
eine verteilte IT-Einrichtung bzw. -Anlage für heterogene, verteilte Verarbeitung
zu haben, die von extrem kleinen, eingebetteten Einrichtungen über PDAs
und Mobiltelefonen zu Laptops und sogar über die leistungsfähigsten Computer
hinaus skalierbar ist.
-
Es
gibt andere heterogene Lösungen
wie die Common Object Request Broker Architecture (CORBA). CORBA
ist eine Architektur, die Programmobjekte in die Lage versetzt,
miteinander zu kommunizieren unabhängig von der Programmiersprache,
in der sie geschrieben wurden, oder un ter welchem Betriebssystem
sie ablaufen. Jedoch behandelt CORBA nicht alle Problemkreise bei
der Verbindung, die von Jini behandelt werden. Darüber hinaus
leidet CORBA unter ähnlichen
Skalierbarkeitsproblemen wie Jini.
-
Eine
Technologie wie Jini und CORBA verwendet ein codezentriertes Programmierungsmodell,
um die Schnittstelle zwischen entfernten Komponenten zu definieren.
Ein codezentriertes Programmierungsmodell definiert programmatische
Schnittstellen oder APIs zur Kommunikation zwischen entfernten Clients
oder Komponenten. Die APIs können
in einer speziellen Programmiersprache definiert werden. Die APIs
müssen
unter allen Softwarekomponenten abgestimmt sein, um eine saubere
Interoperabilität
sicherzustellen. Da alle Zugriffe auf Komponenten über diese
standardisierten APIs erfolgt, muß der Code, der diese APIs
implementiert, in der Client-Plattform vorhanden sein. Der Code
kann in die Plattform statisch gelinkt sein oder dynamisch heruntergeladen
werden, wenn benötigt.
Viele eingebettete oder mobile Einrichtungen können sowohl aufgrund der damit
verbundenen Qualitätskontrollprobleme
als auch wegen des Vertrauens auf eine einzige Sprach- und Programmausführungsumgebung
schlichtweg keinen Code dynamisch akzeptieren. Datenzentrierte Modelle
wie Netzwerkprotokolle können
die Abhängigkeit
von sich bewegendem Code vermeiden; jedoch sind solche Protokolle
nicht umfangreich genug, um einfach für verteilte Verarbeitung zu
sorgen und ihnen mangelt es auch an der Einfachheit der Programmierung
mit Code- und anderen Programmierungseigenschaften wie Typsicherheit.
-
Herkömmliche
verteilte Verarbeitungssysteme verlassen sich auf der Fähigkeit
eines Programms, das auf einer ersten Einrichtung ausgeführt wird,
in der Lage zu sein, ein Programm auf einer zweiten Einrichtung entfernt
aufzurufen und die Ergebnisse zur ersten Einrichtung zurückliefern
zu lassen. Der abgesetzte Prozeduraufruf (Remote Procedure Call,
RPC) ist ein grundlegender Mechanismus, um ein Programm oder eine
Prozedur aus der Ferne aufzurufen. CORBA und Jini beruhen beide
auf der Fähigkeit,
Programm-Methoden aus der Ferne aufzurufen. Jedoch kann es ziemlich
kompliziert sein, durch das Übergeben
von Code oder Objekten wie in Jini oder CORBA zu kommunizieren.
Zum Beispiel verwendet Jini wie oben erwähnt die Java Remote Method
Invocation (RMI), um zwischen Diensten zu kommunizieren. Damit ein
Client Java-Objekte von und zu entfernten Stellen bewegen kann,
ist eine Möglichkeit
zur Serialisierung/Deserialisierung erforderlich. Solche aktuellen
Fähigkeiten
im Java Development Kit (JDK) stützen
sich auf das Spiegelungs-API bzw. Reflektions-API, um den Inhalt
eines Java-Objektes bestimmen und schließlich muß dieser Code die virtuelle
Maschine konsultieren. Dieser Code ist umfangreich und ineffizient.
-
Die
fundamentalen Probleme mit dem aktuellen Verfahren zum Serialisieren/Deserialisieren
beinhalten seine Größe, Geschwindigkeit
und das Modell zum Durchlaufen von Objekten. Code außerhalb
der JVM kennt nicht die Struktur oder den Graphen eines Java-Objektes
und muß daher
den Objekt-Graphen durchlaufen, indem er ihn auseinander zieht,
und muß schließlich die
JVM aufrufen. Herkömmliche
Mechanismen zur Serialisierung und Spiegelung für das Speichern und Bewegen
von Java-Objekten sind gerade nicht für alle Arten von Einrichtungen,
insbesondere dünnere
Clients, praktikabel. Einige der Schwierigkeiten mit Java-Spiegelung
und -Serialisierung sind, daß die
Spiegelung des Graphen eines Objektes (eine transitive Hülle bzw. ein
transitiver Abschluß des
Objektes) außerhalb
der JVM schwierig durchzuführen
ist. Eine Serialisierung ist zu umfangreich und erfordert eine große Menge
an Code. Darüber
hinaus ist die Serialisierung ein Java-spezifisches Austauschformat für Objekte
und kann somit nicht für
Nicht-Java-Einrichtungen verwendet werden.
-
Das
verteilte Verarbeitungsmodell von Jini erfordert das Bewegen von
Java-Objekten zwischen Java-Einrichtungen. Somit ist der Serialisierungsmechanismus
selbst nicht Plattformunabhängig,
da er nicht von nicht-Java-Plattformen verwendet werden kann, um
Objekte zu senden und zu empfangen. Die Serialisierung ist ein homogenes
Objektformat – es
funktioniert nur auf Java-Plattformen. Die Serialisierung verwendet
das Spiegelungs-API bzw. Reflektions-API und kann aufgrund von Sicherheitsbedenken
eingeschränkt
sein, die oft durch Verwendung von arteigenen JVM-abhängigen Verfahren
angegangen werden müssen.
Das Reflektions-API kann einen Graphen von Objekten bereitstellen,
aber es ist wegen der Anzahl von Aufrufen zwischen der JVM und dem
Code, der die Reflektionsmethoden aufruft, ineffizient.
-
Die
Verwendung der Java-Reflektion zur Serialisierung eines Objektes
erfordert eine Anwendung, um in die und aus der JVM hin- und herzuwechseln,
um ein Objekt, ein Feld zu einem Zeitpunkt, auseinanderzupflücken, während der
transitive Abschluß des
Objektes dynamisch analysiert wird. Die Deserialisierung eines Objektes
unter Verwendung der Java-Deserialisierung macht es erforderlich,
daß die
Anwendung eng mit der JVM zusammenarbeitet, um das Objekt, ein Feld
zu einem Zeitpunkt, wieder herzustellen, während der transitive Abschluß des Objektes
dynamisch analysiert wird. Somit ist die Java-Serialisierung/Deserialisierung langsam
und schwerfällig,
während
sie gleichzeitig sowohl eine große Menge von Anwendungs- und
JVM-Code als auch dauerhaften Speicherplatz benötigt.
-
Auch
für Thin-Clients,
die Java unterstützen,
ist das Jini-RMI möglicherweise
nicht praktizierbar für Thin-Clients
mit minimalem Speicherplatz und minimaler Bandbreite. Die mit Jini-RMI
verbundene Serialisierung ist langsam, umfangreich, benötigt das
Reflektions-API der JVM und ist eine Java-spezifische Objektdarstellung.
Die Java-Deserialisierung ist auch langsam, umfangreich und erfordert
einen Parser für
serialisierte Objekte. Auch Java-basierte Thin-Clients sind möglicherweise
nicht in der Lage, riesige Java-Objekte (zusammen mit den benötigten Klassen)
zu akzeptieren, die (notwendigerweise) über das Netzwerk an den Client
zurückgeliefert
werden, wie in Jini erforderlich. Ein besser skalierbarer Mechanismus
der verteilten Verarbeitung wird benötigt. Es ist vielleicht wünschenswert,
daß ein
besser skalierbarer Mechanismus der verteilten Verarbeitung Sicherheitsbedenken
berücksichtigt
und erweiterbar ist, um die Übergabe
von Objekten wie Java-Objekten
zu ermöglichen,
und es sogar zu ermöglichen,
daß ein
Prozeß von
einem Netzwerkmodus zu einem anderen migriert.
-
Objektbasierte
Systeme zur verteilten Verarbeitung erfordern dauerhaften Speicher.
Wie oben diskutiert, sind jedoch die Versuche, Objektspeicher zu
realisieren, häufig
sprach- und betriebssystemspezifisch. Darüber hinaus sind diese Objektspeichersysteme
zu kompliziert, um bei vielen kleinen, eingebetteten Systemen verwendet
zu werden. Zum Beispiel verwendet die Jini-Technologie JavaSpaces als dauerhafte
Objektcontainer. Jedoch kann ein JavaSpace nur Java-Objekte speichern
und kann nicht in kleinen Systemen implementiert werden. Jedes Objekt
in einem JavaSpace ist serialisiert und bezahlt mit den oben beschriebenen Strafen,
die mit der Java-Serialisation
verbunden sind. Es kann wünschenswert
sein, einen heterogenen Objektcontainer für die verteilte Verarbeitung
zu haben, der von kleinen bis zu großen Einrichtungen skalierbar
ist.
-
JavaSpaces
von Sun Microsystems Inc. zieht Nutzen aus der Arbeit über parallele
Verarbeitung von David Gelernter, einem Professor der Computerwissenschaften
an der Yale Universität.
Gelernter Satz von Funktionen namens "Linda" erzeugt einen gemeinsam genutzten Speicherplatz,
der ein TupleSpace genannt wird, in den Ergebnisse von Prozessen
eines Computers oder die Prozesse selbst zum Zugriff durch mehrere CPUs
gespeichert werden können.
Linda stellt daher einen globalen, gemeinsam genutzten Speicher
für mehrere
Prozessoren zur Verfügung.
-
Eine
andere Technologie, die Linda erweitert, ist TSpaces von IBM Corporation.
TSpaces erweitert das grundlegende TupleSpace-Rahmenwerk von Linda
um reale Datenverwaltung und die Möglichkeit, neue Datentypen
und neue semantische Funktionalität herunterzuladen. TSpaces
stellt einen Satz von Puffern für
die Netzwerkkommunikation und einen Satz von APIs zum Zugriff auf
diese Puffer zur Verfügung.
Wie viele der oben diskutierten Lösungen verwendet TSpaces daher
ein codezentriertes Programmiermodell und teilt die Nachteile eines
solchen Modells. Darüber
hinaus ist TSpaces in der Programmiersprache Java implementiert und
erfordert daher eine Virtuelle Java-Maschine oder andere Möglichkeiten
zur Ausführung
von Java-Bytecode wie einen Java-fähigen Mikroprozessor. Daher
ist TSpaces möglicherweise
ungeeignet für
kleindimensionierte Einrichtungen, die nicht genügend Ressourcen zur Ausführung von
Java-Bytecode bereitstellen können.
-
Es
ist in objektorientierten verteilten Systemen wünschenswert, in der Lage zu
sein, Objektbehälter
zu lokalisieren und bestimmte Objekte in diesem Behälter zu
finden. Wie oben erwähnt
ist der Jini-Nachschlagedienst möglicherweise
für kleine
Einrichtungen mit kleinen Speicherdimensionen nicht praktizierbar.
Ein effizienterer Mechanismus zum Lokalisieren von Objektspeichern
kann wünschenswert
sein.
-
Es
kann wünschenswert
sein, daß in
einem verteilten Netzwerkverarbeitungsmodell Clients die Fähigkeit
besitzen, Dienste zu lokalisieren. Aktuelle Netzwerkprotokolle stellen
entweder nur eine einzige Zugangsschnittstelle für einen Standarddienst bzw.
standardmäßige Zugangsschnittstelle
für einen
Dienst zur Verfügung,
die nicht für
Sicherheit sorgt, wenn auf einen Netzwerkdienst zugegriffen wird,
oder stellt einen "Alles-oder-Nichts"-Zugang auf dem vollen
Umfang der Diensteigenschaften bzw. -fähigkeiten zur Verfügung, der Administrator-
oder privilegierte Funktionen umfassen kann. Ebenso stellen aktuelle
Netzwerkprotokolle zum Lokalisieren von Diensten keinen flexiblen
Mechanismus zum Finden von Diensten zur Verfügung. Aktuelle Protokolle stellen
entweder überhaupt
keine selektive Suchmöglichkeit
zur Verfügung
(z.B. UPnP) oder stellen nur einen primitiven Grammatikmechanismus
mit Schlüsselwort
und Attribut zur Verfügung
(z.B. SLP). Daher können
aktuelle Mechanismen zum Ausfindigmachen von Diensten in ihren Mechanismen
zu Sicherheit und Suchkriterien zu unflexibel sein.
-
Aktuelle
Modelle zum Ausfindigmachen von Diensten haben auch ein symmetrisches
Modell zum Lokalisieren von Diensten. Es kann jedoch eine Verschwendung
von Ressourcen darstellen, für
gewisse Diensteinrichtungen, wie z.B. Einrichtungen, für welche
die Verfügbarkeit
der Funktionalität
auf der Nähe
beruht, das Auffindungsmodell zu unterstützen. Dies liegt daran, daß solche
Einrichtungen bereits nach der Nähe
zueinander angeordnet sind (z.B. indem eine Einrichtung physikalisch
auf eine andere zeigt). Daher kann auch ein alternativer, leichtgewichtiger
Auffindungsmechanismus für
solche Einrichtungen wünschenswert
sein.
-
Ein
verteilter Objektzugriff strebt einen gerechten und effizienten
Mechanismus der gemeinsamen Nutzung an. Wie oben beschrieben verwendet
Jini aktuell einen Überlassungs-
bzw. Pachtmechanismus, um Objekte gemeinsam zu nutzen. Jedoch sind
die Überlassungen
von Jini zeitbasiert, was zu einer Reihe von Problemen führen kann.
Zum Beispiel könnte
der aktuelle Halter eines Objektes keine Vorstellung darüber haben, wie
lange er ein Objekt pachten soll, und er hält es womöglich zu lange. Darüber hinaus
kann es die Verwendung von Überlassungen
auf Zeitbasis erforderlich machen, daß die Zeit zwischen mehreren
Maschinen synchronisiert ist. Weiterhin kann Überlassen auf Zeitbasis eine
Unterstützung
durch das Betriebssystem erfordern. Darüber hinaus werden Jini-Überlassungen
mittels RMI eingerichtet und freigegeben. Somit leidet der Überlassungsmechanismus
von Jini unter den oben erkannten Problemen bei der Verwendung von
RMI. Darüber
hinaus stellt der Überlassungsmechanismus
von Jini keinen Sicherheitsmechanismus für das Einrichten, Erneuern
und Aufgeben von Überlassungen
bereit. Andere Überlassungsmechanismen
sind möglicherweise wünschenswert.
-
Allgemein
gesprochen ist es wünschenswert,
daß mobile
Clienteinrichtungen mit kleindimensioniertem Speicher in der Lage
sind, eine Vielzahl von Diensten, sowohl hergebrachte als auch neue,
in einer verteilten Umgebung ablaufen zu lassen. Die Arten von kleinen
Clients können
Mobiltelefone und PDAs mit einer Vielzahl von verschiedenen Netzwerkschnittstellen,
typischerweise mit niedriger Bandbreite, umfassen. Häufig haben
diese Einrichtungen sehr kleine Anzeigen mit eingeschränkter Grafik,
aber sie können
auch Laptops und Notebook-Computer umfassen, die eine größere Anzeige
und anspruchsvollere grafische Fähigkeiten
besitzen. Die Dienste können
ein weiter Bereich sowohl von Anwendungen als auch von Steuerprogrammen
für Geräte bzw.
Einrichtungen wie Drucker sein. Es ist wünschenswert, daß ein mobiler
Client in der Lage ist, diese Dienste zu verwenden, wo auch immer
sie sein mögen.
-
Ein
mobiler Client befindet sich häufig
an einer temporären,
dynamischen Netzwerkadresse, so daß Netzwerknachrichten, die
er sendet, nicht über
die Netzwerkschnittstelle hinaus geleitet werden können (ansonsten
kann es Kollisionen geben, wenn zwei verschiedene Clients auf verschiedenen
Netzwerken dieselbe dynamische Adresse haben). Mobile Clients haben
häufig
nicht die Fähigkeit
bzw. Möglichkeit
für einen
Browser mit vollem Funktionsumfang oder andere anspruchsvolle Software.
Die Anzeige kann den Client einschränken, gewisse Anwendungen ablaufen zu
lassen. Traditionelle Anwendungsmodelle beruhen auf vorher festgelegten
Benutzerschnittstellen- oder Dateneigenschaften. Jede Änderung
der Anwendung erfordert eine Neukompilierung der Anwendung.
-
Es
kann wünschenswert
sein, daß solche
Clients über
einen Mechanismus verfügen,
um verteilte Anwendungen oder Dienste zu finden und aufzurufen.
Der Client kann sogar große
Altlastanwendungen ablaufen lassen müssen, die möglicherweise nicht in die Speicherdimensionierung
des Clients passen würden.
Wie oben diskutiert ist die aktuelle Technologie wie Jini für kleinformatige
Einrichtungen bzw. Geräte
möglicherweise
nicht praktikabel. Die Verbreitung von mobilen Thin-Clients kann auch
zusätzliche
Anforderungen aufkommen lassen. Zum Beispiel kann es wünschenswert
sein, einen Dienst bezogen auf den physikalischen Aufenthaltsort
des Benutzers und seines mobilen Client zu lokalisieren. Zum Beispiel
kann Information über
die Dienste in der lokalen Nachbarschaft wie lokale Restaurants,
Wetter, Verkehrskarten und Kinoinformation sehr hilfreich sein.
In ähnlicher
Weise kann Information über
Verarbeitungsressourcen wie Drucker an einer bestimmten Stelle hilfreich
sein. Aktuelle Technologien sehen keinen automatischen Mechanismus
vor, um Dienste auf der Basis des physikalischen Ortes des Clients
zu lokalisieren. Ein anderer Bedarf, der durch mobile Thin-Clients
aufgekommen ist, ist die Berücksichtigung
des menschlichen Faktors. Mobile Thin-Clients enthalten typischerweise
keine ergonomischen Tastaturen und Monitore. Die Bereitstellung
solcher Dienste, die den menschlichen Faktor betreffen, und/oder
die Fähigkeit,
solche Dienste in einer verteilten Rechnerumgebung zu lokalisieren,
kann wünschenswert
sein.
-
Ein
verteiltes IT-Modell sollte Clients mit einer Möglichkeit versorgen, transiente
Dokumente und Dienste zu finden. Es kann wünschenswert sein, einen Mechanismus
zum Finden von Mehrzweck-Dokumenten (einschließlich Diensten und/oder Dienstannoncen)
zu haben, bei dem die Dokumente in einer plattform- und sprachunabhängigen Schreibweise
wie derjenigen, die durch die eXtensible Markup Language (XML) bereitgestellt
wird, ausgedrückt
sind. Aktuelle Ansätze
einschließlich
Suchmechanismen von Jini, Universal Plug and Play (UPnP) und das
Service Location Protocol (SLP) unterstützen einen solchen Suchmechanismus
für Mehrzweck-Dokumente
nicht. Zum Beispiel ist der Suchmechanismus von Jini auf Schreiben
bzw. Eingabe in der Sprache Java beschränkt und ist daher nicht sprachunabhängig. UPnP
und SLP unterstützen
ein Auffindungsprotokoll nur für
Dienste, nicht für
Mehrzweck-Dokumente.
-
In „XML and
Jini – on
using XML and the JAVA Border Service Architecture to integrate
moile devices into the Java Intelligent Network Infrastructure" („XML und
Jini zur Verwendung von XML und der JAVA-Grenzdienstarchitektur
bei der Integration mobiler Einrichtungen in eine intelligente Java-Netzwerkinfrastruktur") von Mueller-Wilken
et al. wird eine Infrastruktur beschrieben, die XML und einen Objektanalysemechanismus
verwendet, um Zugriff auf Jini-Dienste
für irgendeine
mobile Einrichtung zu gewähren,
ohne daß auf
der Client-Seite Java erforderlich ist. Dies wird erreicht durch
Bereitstellen einer Java-Grenzdienstarchitektur, die es ermöglicht,
GUIs zu bedienen, so daß sie
von einfachen Browser-Geräten,
wie z. B. WAP-Telefonen,
zugänglich
sind.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die
vorliegende Erfindung stellt ein System und ein Verfahren zur Verwendung
in einer verteilten Rechnerumgebung bereit, wie es in den anhängenden
Ansprüchen
1 und 25 definiert wird.
-
Verschiedene
Ausführungsformen
von Mechanismen zur Herstellung einer Brücke von einem Nachrichtenprotokoll
in einer Datenrepräsentationssprache
zu fremden (außerhalb
der verteilten Rechnerumgebung liegende) Clients, Dienste, Einrichtungen
und Übertragungen
werden hier beschrieben. Fremde Geräte, Clients, Dienste und Transporte
bzw. Verkehrsarten können
unter Verwendung von Proxy-Diensten über eine Brücke in die verteilte Rechnerumgebung übernommen
werden. Eine Ausführungsform
einer verteilten Rechnerumgebung kann Geräte-Proxies umfassen. Ein Geräte-Proxy
ist ein Dienst, der ein Geräteerkennungsprotokoll
und ein Erkennungsprotokoll einer verteilten Rechnerumgebung vertretungsweise
für ein
Gerät implementiert.
Geräte-Proxies
einer verteilten Rechnerumgebung können verwendet werden, um eine
Brücke
für Geräte in eine
verteilte Rechnerumgebung zu bilden. Für irgendeines dieser Geräteerkennungsprotokolle
kann ein Proxy-Dienst nach Geräten
sondieren, Dienstanzeigen für
jedes entdeckte Gerät
erzeugen und Dienstanzeigen in einem Space (Speicherraum) speichern
(oder direkt auf Suchanfragen für
eine Diensterkennung reagieren).
-
Eine
Ausführungsform
einer verteilten Rechnerumgebung kann Client-Proxies enthalten.
Ein Client-Proxy ist ein Dienst, der das Erkennungs- bzw. Erfassungsprotokoll
einer verteilten Rechnerumgebung für einen außerhalb liegenden Client, wie
z. B. einen Browser, implementiert. Clients in der verteilten Rechnerumgebung
können
eine Datenrepräsentationssprache
annehmen und können
Style-Sheets (Grundformulare) unterstützen, um zwischen der Datenrepräsentationssprache
und anderen Typen von Inhalten zu übersetzen. Für diejenigen
Clients, die die Datenrepräsentationssprache
nicht direkt unterstützen,
kann ein Client-Proxy implementiert werden, der von den Inhaltstypen,
die von dem vertretenen Client unterstützt werden, in die Datenrepräsentationssprache übersetzt
und umgekehrt.
-
Eine
Ausführungsform
einer verteilten Rechnerumgebung kann Dienst-Proxies enthalten.
Ein Dienst-Proxy ist ein Dienst, der das Protokoll der verteilten
Rechnerumgebung für
einen außerhalb
liegenden Dienst implementiert. Dienst- bzw. Service-Provider in
der verteilten Rechnerumgebung können
auf den Protokollaufbau (Protocol Suite) der verteilten Rechnerumgebung
reagieren. Für
Dienste, welche die verteilte Rechnerumgebung nicht unterstützen, kann
ein Dienst-Proxy Nachrichten an ein ursprüngliches Aufrufmodell des vertretenen
Dienstes übersetzen
und auch Nachrichten von diesen zurückübersetzen.
-
Eine
Ausführungsform
einer verteilten Rechnerumgebung kann Transport-Proxies enthalten.
Ein Transport-Proxy ist ein Dienst-Proxy, welcher Nachrichten in
einer Datenrepräsentationssprache
zwischen zwei unterschiedlichen Nachrichtenverkehren leitet, was
manchmal auch als eine Nachrichtenbrücke bezeichnet wird. Transport-Proxies
leiten Nachrichten von einem Verkehrstyp an einen anderen Verkehrstyp.
Der Transport-Proxy darf keinerlei Nachrichteninhalt beeinflussen
und kann daher sowohl für
den Client als auch für
den Dienst transparent sein.
-
Ein
Client-Proxy einer verteilten Rechnerumgebung kann vorgesehen werden,
welcher ermöglicht, daß Clients
einer verteilten Rechnerumgebung auf Dienste in einer Umgebung zugreift,
die auf dem entfernten Methodenaufruf (RMI) beruht. Ein Client-Proxy
auf einer RMI-basierten
Umgebung kann bereitgestellt werden, welcher es ermöglicht,
daß Clients
in der RMI-basierten
Umgebung auf Dienste in der verteilten Rechnerumgebung zugreift.
Gemeinsam bilden diese beiden Proxies eine transparente Brücke zwischen
der verteilten Rechnerumgebung und einer RMI-basierten Umgebung,
wie z. B. Jini. Die Proxies können
getrennt voneinander arbeiten, was es ermöglichen kann, daß Einwege-
oder Zweiwege-Brücken
verwendet werden. Ähnliche Proxies
können
verwendet werden, um andere Umgebungs-Clients (auf Nachrichtenbasis
und nicht auf Nachrichtenbasis) und entsprechende Dienste mit Diensten
und Clients in der auf Nachrichten basierten, verteilten Rechnerumgebung über eine
Brücke
zu verbinden.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
eine Darstellung eines Stack nach herkömmlicher, verteilter Rechnertechnologie;
-
2 ist
eine Darstellung eines Programmiermodells für eine verteilte Rechnerumgebung
gemäß einer
Ausführungsform;
-
3 ist
eine Darstellung der Nachrichten- und Netzschichten für eine verteilte
Rechnerumgebung gemäß einer
Ausführungsform;
-
4 ist
eine Darstellung eines Auffindungs- bzw. Discoverydienstes zum Auffinden
von Spaces, die Objekte oder Dienste in einer verteilten Rechnerumgebung
gemäß einer
Ausführungsform
ankündigen;
-
5 stellt
Clientprofile dar, die statische und formatierte Nachrichten für eine verteilte
Rechnerumgebung gemäß einer
Ausführungsform
unterstützen;
-
6 ist
eine Darstellung eines verteilten Verarbeitungsmodells, das das
Senden von XML-Nachrichten gemäß einer
Ausführungsform
verwendet;
-
7 stellt
eine plattformunabhängige,
verteilte Rechnerumgebung gemäß einer
Ausführungsform dar;
-
8 ist
eine Darstellung eines verteilten Verarbeitungsmodells, in dem Dienste
in Spaces gemäß einer
Ausführungsform
angekündigt
werden;
-
9 ist
eine Darstellung eines verteilten Verarbeitungsmodells, in dem Ergebnisse
gemäß einer
Ausführungsform
in Spaces gespeichert werden;
-
10a ist eine Darstellung von Client- und Dienst-Gattern
als Nachrichtenendpunkte in einem verteilten Rechnermodell gemäß einer
Ausführungsform;
-
10b ist eine Darstellung einer Erzeugung eines
Nachrichtenendpunktes gemäß einem
Schema zum Zugriff auf einen Dienst gemäß einer Ausführungsform.
-
11a stellt das Erzeugen eines Gatters in einer
verteilten Rechnerumgebung gemäß einer
Ausführungsform
dar;
-
11b stellt das Erzeugen eines Gatters und Gatterpaare
in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
dar;
-
12 ist eine Darstellung möglicher Gatterkomponenten in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform;
-
13 ist eine Darstellung eines Proxy-Client für einen
herkömmlichen
Browser, um an einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
teilzunehmen;
-
14 stellt die Verwendung eines Methodengatters
dar, um eine Schnittstelle zum entfernten Aufruf von Methoden für einen
Dienst in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
zu bieten;
-
15 ist eine Darstellung der Verwendung eines Space
in einer verteilten Rechnerumgebung gemäß einer Ausführungsform;
-
16 stellt eine Anzeige- bzw. Ankündigungsstruktur
gemäß einer
Ausführungsform
dar;
-
17 stellt ein Beispiel von Zustandübergängen von
Ankündigungen
dar, denen eine Ankündigung während ihrer
Lebensdauer gemäß einer
Ausführungsform
unterliegen kann;
-
18 ist eine Darstellung verschiedener Mechanismen
zur Lokalisierung von Spaces in einer verteilten Rechnerumgebung
gemäß einer
Ausführungsform;
-
19 ist eine Darstellung von Space-Bündnissen
in einer verteilten Rechnerumgebungen gemäß einer Ausführungsform;
-
20 ist ein Flußdiagramm, das die Bildung
einer Sitzung bzw. Session eines Client mit einem Space-Dienst in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform
darstellt;
-
21 ist eine Darstellung einer Hierarchie von Space-Ereignistypen
für eine
Ausführungsform;
-
22 ist ein Flußdiagramm, das die Instantiierung
eines Dienstes in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
darstellt;
-
23 ist eine Darstellung eines Standard-Space in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform;
-
24 veranschaulicht ein Beispiel einer Einrichtung,
die gemäß einer
Ausführungsform
eine Brücke für nahegelegene
Einrichtungen zu einem anderen Transportmechanismus schlägt, um es
zu ermöglichen, daß auf die
von den nahegelegenen Einrichtungen bereitgestellten Dienste von
Einrichtungen außerhalb
des Nachbarschaftsbereichs der Einrichtungen zugegriffen werden
kann;
-
25 ist eine Darstellung der Verwendung von Überlassugs-
bzw. Lease-Verlängerungsnachrichten in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform;
-
26a ist ein Flußdiagramm, das einen Authentifizierungsdienst
darstellt, der gemäß einer
Ausführungsform
einen Authentifizierungsnachweis für einen Client bereitstellt;
-
26b ist ein Flußdiagramm, das Schritt 1002 von 26a erweitert und einen Authentifizierungsdienst
darstellt, der gemäß einer
Ausführungsform
einen Authentifizierungsnachweis erzeugt;
-
27 stellte eine Ausführungsform eines Überbrückungs-
bzw. Brückenschlag-Mechanismus' dar;
-
28 veranschaulicht ein Beispiel eines Space-Auffindungsprotokolls,
das gemäß einer
Ausführungsform
auf einen externen Auffindungs- bzw. Discovery-Dienst abgebildet
wird;
-
29 veranschaulicht das Überbrücken bzw. den Brückenschlag
für einen
Client, der außerhalb
der verteilten Rechnerumgebung liegt, zu einem Space in der verteilten
Rechnerumgebung gemäß einer
Ausführungsform;
-
30 ist eine Darstellung eines Proxy-Mechanismus' gemäß einer
Ausführungsform;
-
31 stellt eine Ausführungsform eines Client mit
einer zugehörigen
Anzeige und einem Anzeigedienst gemäß einer Ausführungsform
dar;
-
32A und 32B veranschaulichen
Beispiele der Verwendung von Schemata von dynamischen Anzeigeobjekten
gemäß einer
Ausführungsform;
-
33A stellt eine typische Zeichenkettendarstellung
in der Programmiersprache C dar;
-
33B veranschaulicht ein Beispiel einer herkömmlichen
Zeichenkettenfunktion;
-
33C stellt ein effizientes Verfahren zur Darstellung
und Verwaltung von Zeichenketten im allgemeinen und in kleinformatigen
Systemen wie eingebettete Systeme im besonderen gemäß einer
Ausführungsform
dar:
-
34 stellt den Vorgang des Bewegens von Objekten
zwischen einem Client und einen Dienst gemäß einer Ausführungsform
dar;
-
35a und 35b sind
Datenflußdiagramme,
die Ausführungsformen
darstellen, in denen eine virtuelle Maschine (z. B. JVM) Erweiterungen
zum Kompilieren von Objekten (z. B. Java-Objekten) in XML-Darstellungen der Objekte
und zum Dekompilieren von XML-Darstellungen von (Java)-Objekten
in (Java)-Objekte beinhaltet;
-
36 stellt einen Client und einen Dienst dar, die
auf Speichermechanismen in der verteilten Rechnerumgebung gemäß einer
Ausführungsform
zugreifen;
-
37 veranschaulicht eine Prozeßmigration mittels einer XML-Darstellung
des Zustandes eines Prozesses gemäß einer Ausführungsform;
-
38 stellt eine mobile Client-Einrichtung dar,
die auf Spaces in einem lokalen, verteilten Rechnernetz gemäß einer
Ausführungsform
zugreift;
-
39a stellt einen Benutzer einer mobilen Einrichtung
dar, der den Standort von Docking-Stationen gemäß einer Ausführungsform
ausfindig macht;
-
39b stellt eine mobile Client-Einrichtung dar,
die sich gemäß einer
Ausführungsform
mit einer Docking-Station verbindet;
-
40a stellt eine Ausführungsform von eingebetteten
Einrichtungen dar, die gemäß einer
Ausführungsform
von einem Steuerungssystem kontrolliert werden und innerhalb der
verteilten Rechnerumgebung zugreifbar sind;
-
40b stellt ein Geräte- bzw. Einrichtungssteuerungssystem
dar, das über
ein Netz (z. B. das Internet) mit eingebetteten Einrichtungen verbunden
ist, die innerhalb der verteilten Rechnerumgebung gemäß einer
Ausführungsform
zugreifbar sind;
-
41 ist ein Flußdiagramm, das das Erzeugen
eines Gatters gemäß einer
Ausführungsform
darstellt;
-
42a ist ein Flußdiagramm, das einen Client
darstellt, der gemäß einer
Ausführungsform
eine Nachricht an einen Dienst sendet;
-
42b ist ein Flußdiagramm, das einen Dienst
darstellt, der einen Nachricht von einen Client empfängt und
einen Authentifizierungsdienst verwendet, um die Nachricht gemäß einer
Ausführungsform
zu authentifizieren;
-
42c ist ein Flußdiagramm, das den allgemeinen
Vorgang eines Client und eines Dienstes darstellt, die Nachrichten
mit eingebetteten Authentifizierungsnachweisen gemäß einer
Ausführungsform
austauschen;
-
43 ist ein Flußdiagramm, das einen Mechanismus
zum Prüfen
der Integrität
von Nachrichten gemäß einer
Ausführungsform
darstellt;
-
44 ist ein Flußdiagramm, das einen Mechanismus
zum Überlassen
von Ressourcen gemäß einer Ausführungsform
darstellt;
-
45a-45e sind
Flußdiagramme,
die verschiedene Ausführungsformen
eines Mechanismus' zur
Kommunikation zwischen Clients und Diensten mittels Methodengattern
darstellen;
-
46 ist ein Flußdiagramm, das einen Mechanismus
zum Senden von Objekten von Diensten an Clients mittels XML-Darstellungen
der Objekte veranschaulicht.
-
47 ist ein Flußdiagramm, das einen Mechanismus
zum sicheren Dekompilieren von Objekten auf einer Client-Einrichtung
darstellt;
-
48 veranschaulicht gemäß einer Ausführungsform
einen Client in einer Nachrichtenbasierten, verteilten Rechnerumgebung,
der über
einen Client-Proxy einen Dienst in einer RMI-basierten Umgebung
aufruft.
-
49 ist ein Blockdiagramm, welches gemäß einer
Ausführungsform
Methodengatter und Ergebnismethodengatter gemäß einer Ausführungsform
der Erfindung veranschaulicht.
-
50 veranschaulicht gemäß einer Ausführungsform
einen Client in einer RMI-basierten
Umgebung, der nach Diensten in einer auf Nachrichten basierten,
verteilten Rechnerumgebung sucht, und
-
51 veranschaulicht einen Client in einer RMI-basierten
Umgebung, der gemäß einer
Ausführungsform
einen Dienst in einer Nachrichten-basierten, verteilten Rechnerumgebung
aufruft.
-
DETAILLIERTE BESCHREIBUNG
VON AUSFÜHRUNGSFORMEN
DER ERFINDUNG
-
Überblick der Ausführungsformen
für verteilte
Verarbeitung
-
In 2 ist
ein Programmierungsmodell für
eine verteilte Rechnerumgebung dargestellt. Da Modell umfaßt die API-Schicht 102,
um verteilte Verarbeitung zu erleichtern. Die API-Schicht 102 stellt
eine Schnittstelle bereit, die es Clients erleichtert, mit Diensten
Verbindung aufzunehmen. Die API-Schicht 102 befaßt sich mit
dem Ausfindig-Machen von Diensten und dem Verbinden von Clients
und Diensten. Die API-Schicht 102 stellt Fähigkeiten
zum Senden und Empfangen von Nachrichten zur Verfügung. Dieses
API zum Versenden von Nachrichten kann eine Schnittstelle für einfache
Nachrichten in einem Datendarstellungs- oder Meta-Datenformat wie
in der eXtensible Mark-up Language (XML) bereitstellen. Man beachte,
daß andere
Meta-Daten-artige Sprachen oder Formate in anderen Ausführungsformen
verwendet werden können,
auch wenn hier Ausführungsformen
unter Einsatz von XML beschrieben werden. Nach einigen Ausführungsformen
kann die API-Schicht auch eine Schnittstelle für Nachrichten zum Kommunizieren
zwischen Objekten oder zur Übergabe
von Objekten wie Java-Objekten bereitstellen. APIs können zur
Verfügung
stehen, um einen Objektspeicher oder -"raum" ausfindig
zu machen, ein bestimmtes Objekt zu finden, ein Objekt zu beanspruchen
und freizugeben und ein Objekt in den Objektspeicher zu schreiben
oder es aus dem Objektspeicher zu nehmen. Objekte, auf die durch
die API-Schicht 102 zugegriffen werden kann, können durch
ein Datenrepräsentationsformat wie
XML dargestellt werden. Somit kann eine XML-Darstellung eines Objektes
im Gegensatz zu dem Objekt selbst manipuliert werden.
-
Die
API-Schicht 102 sitzt oberhalb einer Nachrichtenschicht 104.
Die Nachrichtenschicht 104 beruht auf einem Datenrepräsentationsformat
wie XML. In einer Ausführungsform
werden XML-Nachrichten
von der Nachrichtenschicht 104 entsprechend zu Aufrufen
der API-Schicht 102 erzeugt. Die Nachrichtenschicht 104 kann
definierte, statische Nachrichten bereitstellen, die zwischen Clients
und Diensten gesendet werden können.
Die Nachrichtenschicht 104 kann auch für dynamisch erzeugte Nachrichten
sorgen. In einer Ausführungsform
kann ein Objekt wie ein Java-Objekt dynamisch in eine XML-Darstellung
konvertiert werden. Die Nachrichtenschicht 104 kann dann
die XML-Darstellung des Objektes als eine Nachricht senden. Umgekehrt
kann die Nachrichtenschicht 104 eine XML-Darstellung eines
Objektes empfangen. Das Objekt kann dann aus dieser Nachricht wieder
aufgebaut werden. In einer Ausführungsform
können
von der Nachrichtenschicht 104 gesendete Nachrichten einige
grundlegende Element umfassen wie eine Adresse, Authentisierungsnachweise, Sicherheitstoken
und einen Nachrichtenkörper.
Die Mechanismen des Nachrichtensystems zur Übertragung und zum Empfang
können
vollständig
zustandslos sein. Jedwede Vorstellung bzw. jedweder Begriff von
Zustand kann in dem Nachrichtenstrom zwischen dem Sender und dem
Empfänger
eingebettet sein. Somit kann die Nachrichtübertragung asynchron erfolgen.
Nach einer bevorzugten Ausführungsform
wird kein Verbindungsmodell eingeführt. Somit sind Transportmedien
wie TCP nicht notwendig. Ebenso können Fehlerbedingungen auf
Nicht-Ablieferung und Sicherheitsausnahmebedingungen beschränkt werden.
-
Die
Nachrichtenschicht 104 sitzt oberhalb einer zur Nachrichtenübertragung
fähigen
Netzwerkschicht 106. Nach einer bevorzugten Ausführungsform
erfordert die Nachrichtenschicht 104 nicht, daß ein bestimmtes Netzwerkprotokoll
zu verwenden ist. TCP/IP und UDP/IP sind Beispiele von zur Nachrichtenübertragung
fähigen
Protokolle, die für
die zur Nachrichtenübertragung
fähigen
Netzwerkschicht 106 verwendet werden können. Jedoch können auch
andere, spezialisiertere Protokolle wie das Wireless Application
Protocol (WAP) verwendet werden. Andere mögliche Nachrichtenprotokolle
sind IrDa- und Bluetooth-Netzwerktreiber unterhalb der Transportschicht.
Die Netzwerkschicht 106 ist nicht auf ein einzelnes, zuverlässiges Verbindungsprotokoll wie
TCP/IP beschränkt.
Daher ist eine Verbindung zu einer größeren Vielfalt von Geräten bzw.
Einrichtungen möglich.
-
In
einer Ausführungsform
kann die zur Nachrichtenübertragung
fähige
Netzwerkschicht 106 aus den Netzwerkklassen implementiert
werden, die von der Java2 Micro Edition (J2ME) Plattform zur Verfügung gestellt
werden. Die Java2 Micro Edition Plattform kann für kleinformatige Einrichtungen
geeignet sein, die nicht die Ressourcen für eine vollständige Java-Plattform
haben oder in denen es nicht effizient wäre, eine vollständige Java-Plattform
zu betreiben. Da J2ME bereits eine nachrichtenfähige Familie von Netzwerkprotokollen bereitstellt
(um Anschlüsse
bzw. Sockets zu unterstützen),
folgt, daß für die geringen
Kosten des Hinzufügens einer
Nachrichtenschicht 104, Eigenschaften bzw. Funktionen zur
verteilten Verarbeitung für
kleine Geräte bzw.
Einrichtungen bereitgestellt werden können, die bereits J2ME enthalten.
-
Die
zur Nachrichtenübertragung
fähige
Netzwerkschicht 106 kann ebenso durch die java.net Netzwerkklassen
des Java Development Kit (JDK) zur Verfügung gestellt werden. Alternativ
können
jedwede zur Nachrichtenübertragung
fähigen
Netzwerkfunktionen für
die zur Nachrichtenübertragung
fähige
Netzwerkschicht 106 verwendet werden. Nach einer bevorzugten
Ausführungsform
wird ein zuverlässiger
Transport nicht benötigt,
so daß eingebettete
Einrichtungen, die einen unzuverlässigen Datagramm-Transport
wie UDP/IP unterstützen,
immer noch die Nachrichtenschicht unterstützen können. Somit können Thin-Clients
an einer verteilten Rechnerumgebung teilnehmen, indem einfach eine
dünne Nachrichtenschicht 104 oberhalb
eines zugrundeliegenden Netzwerk-Protokollstack
hinzugefügt
wird. Wie in 3 gezeigt enthält ein elementares
System die Nachrichtenschicht 104 oberhalb einer Netzwerkschicht 106.
Die Netzwerkschicht kann für
zuverlässige
Nachrichten sorgen, z. B. TCP, oder für unzuverlässige Nachrichten, z. B. UDP.
Das Internet Protokoll (IP) wird in 3 als
ein Beispiel eines Protokolls gezeigt, das in der Netzwerkschicht 106 verwendet
werden kann. Die verteilte Rechnerumgebung erfordert jedoch IP nicht.
Andere Protokolle können
in der verteilten Rechnerumgebung neben IP verwendet werden. Ein
Netzwerktreiber wie für
Ethernet, Token Ring, Bluetooth, etc. kann ebenso Teil der Netzwerkschicht
sein. Viele kleine Clients stellen bereits einen Netzwerktreiber
und ein Transportprotokoll wie UDP/IP zur Verfügung.
-
Somit
kann das Gerät
bzw. die Einrichtung bei Hinzufügung
der dünnen,
XML-basierten Nachrichtenschicht an der verteilten Rechnerumgebung
teilnehmen.
-
Somit
ist die Grundlage für
die verteilte Rechnerumgebung eine einfache, Nachrichten übergebende Schicht,
die oberhalb einer zuverlässigen
Verbindung und/oder von unzuverlässigen
Datagrammen implementiert ist. Die Nachrichtentechnologie ist sehr
verschieden von Kommunikationstechnologien, die in anderen verteilten
Verarbeitungssystemen wie Jini, welches die Java Remote Method Invocation
(RMI) verwendet, eingesetzt werden, Die Nachrichten übergebende
Schicht 104 unterstützt
einen asynchronen, zustandslosen Stil von verteilter Programmierung
anstelle eines synchronen, zustandsbehafteten Stils, der auf RMI
beruht. Mehr noch gründet
sich die Nachrichten übergebende
Schicht 104 auf einen Datenrepräsentationssprache wie XML und
kopiert somit, anders als RMI, Daten, jedoch keinen Code, von der
Quelle zum Ziel. Durch Verwendung einer Datenrepräsentationssprache
wie XML kann die Nachrichtenschicht 104 mit Nicht-Java-
und Nicht-Jini-Plattformen
in einer nahtlosen Weise interoperieren, weil Java-Code auf der
sendenden oder empfangenden Seite einer Nachricht nicht vorausgesetzt
wird. Darüber
hinaus benötigt
die Nachrichtenschicht 104 anders als RMI keinen zuverlässigen Transportmechanismus
wie TCP/IP.
-
Die
Nachrichten übergebende
Schicht kann einfache send()- und receive()-Methoden zur Verfügung stellen,
um eine zum Beispiel als ein Array oder eine Kette von Bytes angegebene
Nachricht zu senden. Die send()-Methode kann sofort zurückkehren,
wobei die Datenübertragung
asynchron durchgeführt
wird. Zum Zweck der Flußkontrolle
kann eine Callback-Methode geliefert werden, die im dem Fall aufgerufen
wird, daß die
send()-Methode eine Ausnahmebedingung aufwirft, die anzeigt, daß sie die
send()-Anforderung nicht behandeln kann, Die receive()-Methode kann
synchron sein und die nächste
verfügbare
Nachricht zurückliefern.
-
Die
Nachrichten übergebende
Schicht kann auch Methoden zum Speichern von XML-Darstellungen von Objekten, Diensten
und Inhalt in "Räumen" bzw. "Spaces" zur Verfügung stellen.
Ein Space wird in einem Netzwerk mittels eines URI (Uniform Resource
Identifier) mit einem Namen versehen und es wird damit auf ihn zugegriffen.
Der URI kann ein URL (Uniform Resource Locator) oder eine einfachere
Version eines URL sein. In einigen Ausführungsformen kann die URL-Klasse
zu groß sein.
Für solche
Ausführungsformen
kann ein einfacherer Ressourcenlokator verwendet werden, der das
Protokoll zum Bewegen der Nachrichten zwischen Client und Server,
die protokollabhängige
Host-ID, die protokollabhängige
Anschluß-
bzw. Port-ID und einen Space-Namen angibt.
-
Eine
XML-Darstellung eines Objektes kann einem Space hinzugefügt werden,
indem eine von der Nachrichtenschicht zur Verfügung gestellte write()-Methode
verwendet wird. In einer Ausführungsform
können das
Objekt und der Client-spezifische Name als Parameter übergeben
werden. In einer Ausführungsform
kann die write()-Methode das Objekt in seine XML-Darstellung übersetzen.
Eine take()-Methode kann vorgesehen werden, um das Objekt zurückzuliefern
und es aus dem Space zu entfernen. Eine find()-Methode kann vorgesehen
werden, um ein spezifisches Objekt aus seiner XML-Darstellung in
einem Space zurückzugeben.
Die find()-Methode kann auch verwendet werden, um ein Array von übereinstimmenden
bzw. passenden Objekten in einem Space bei einer gegebene Klasse
zurückzugeben.
Jede dieser Space-Methoden ist unter Verwendung der Nachrichten übergebende
Schicht implementiert. Ein Überlassungsmechanismus
wie unten genauer beschrieben kann ebenso vorgesehen werden.
-
Ein
Auffindungsdienst kann für
Clients als eine allgemeine Suchfunktion zur Verfügung stehen,
der von einem Client verwendet werden kann, um einen bestimmten
Space zu lokalisieren. Anstatt des Versuches, ein kompliziertes
Suchprotokoll zu definieren, das für einen Thin-Client womöglich nicht
implementierbar ist, kann der Auffindungsdienst die tatsächliche
Suche auf XML-basierte
Suchfunktionen abladen, wodurch der Auffindungsdienst nur noch Schnittstellenfunktionalität für den Client
zur Verfügung
stellen muß.
Der Ansatz ist in 4 dargestellt. In einer Ausführungsform
empfängt
der Auffindungsdienst eine Zeichenkette, die etwas zu Lokalisierendes
angibt, und er sendet eine XML-Nachricht an einen bekannten Auffindungs-Eingangsrechner bzw.
-Front-End (vielleicht
in einem Default-Space zu finden), der dann die Zeichenkette analysiert
bzw. parst und eine entsprechende XML-Anfrage an eine Sucheinrichtung
stellt (die eine Internet-Sucheinrichtung
sein kann). Der Auffindungs-Eingangsrechner kann analysieren, was
er von der Sucheinrichtung erhält,
und es als ein Array von Zeichenketten neu verpacken (jede Zeichenkette
kann ein URI für
jeden gefundenen Space sein), das er in einer XML-Nachricht an den
Client senden kann. Es ist zu beachten, daß der Auffindungsdienst es
nicht erforderlich macht, daß der
Austausch von Nachrichten oberhalb eines verbindungsorientierten
Transportmechanismus' liegt.
Somit könnte
jeder sehr kleine bzw. dünne
Client, der nicht über
TCP verfügt,
einen solchen Auffindungsdienst benutzen. Der Auffindungs-Eingangsrechner
macht es möglich,
daß der
Client Spaces ohne einen Browser oder eine Sucheinrichtung auf dem
Client auffindet. Der Client braucht nur eine einfache Einrichtung
bzw. Möglichkeit,
eine Zeichenkette, die Schlüsselwörter angibt,
an den Eingangsrechner zu senden, der eine Schnittstelle zu einer
Sucheinrichtung hat bzw. darstellt.
-
Ein
Client kann jede Plattform sein, die eine Nachricht unter Verwendung
mindestens einer Teilmenge der API- und der Nachrichtenschichten
sendet. In einer Ausführungsform
kann die API-Schicht
sowohl statische (rohe) als auch formatierte (verarbeitete) Nachrichten
vorsehen. Ein Server kann jede Plattform sein, die in der Lage ist,
Anforderungsnachrichten zu empfangen und zu erfüllen. Das Senden einer expliziten,
rohen Nachricht kann bereitstehen, das eine Reihe von Bytes aus
einem Client zu einem Server oder einem anderen Client bewegt. Der
Nachrichtentyp kann als zuverlässig
(z. B. TCP) oder unzuverlässig
(z. B. UDP) angegeben werden. Die kleinsten der Geräte bzw.
Einrichtungen können
eine rohe, unzuverlässige
Nachrichtenübergabe als
ihr einziges Verfahren zur Teilnahme an der verteilten Rechnerumgebung
verwenden. Die Einrichtung kann diese Nachrichten verwenden, um
ihr Vorhandensein und ihren Zustand anzukündigen. Solche kleinen Einrichtungen
können
auch rohe Nachrichten empfangen, um bestimmte Funktionen wie Ein-
oder Ausschalten einer Eigenschaft bzw. Funktion zu implementieren.
-
Nachrichtenbasierte
Dienste wie Spaces können
zuverlässige,
formatierte Nachrichten senden und empfangen. Eine Space-Nachricht
kann mit einem wohldefinierten Header und mit XML formatiert sein.
In einer Ausführungsform
kann das Senden einer formatierten Nachricht erfolgen, wenn ein
Client eine Space-Methode verwendet, um Objekte aus dem Space zu
beanspruchen, zu schreiben oder zu entnehmen. Die Inhalte der Nachricht
können
dynamisch in XML formatiert werden und wohldefinierte Header enthalten. 5 stellt Clientprofile
dar, die formatierte und statische Nachrichten unterstützen. Unter
Verwendung statischer Nachrichten können kleine Clients ein kleineres
Profil von Nachrichten mit vordefiniertem Code verwenden. Abhängig von
dem Client kann die statische, vordefinierte Nachricht eine kleine
Menge von Speicher (Z. B. <200 Bytes)
verbrauchen. Statische Nachrichten können auch eine Option sogar
für größere Clients
sein. Andererseits können
die dynamischen XML-Nachrichten nützlich sein, wenn Objektwerte
zum Zeitpunkt der Kompilierung nicht bekannt sind.
-
In 6 ist
ein verteiltes Verarbeitungsmodell dargestellt, das ein Nachrichtensystem
mit XML-Nachrichten und XML-Objektrepräsentationen kombiniert. Die
Plattformunabhängigkeit
von XML kann ausgenutzt werden, so daß das System für eine heterogene
Rechnerumgebung sorgt. Somit kann der Client 110 auf fast jeder
beliebigen Plattform anstatt auf einer bestimmten Plattform wie
Java implementiert werden. Das Nachrichtensystem kann auf jeder
beliebigen netzwerkfähigen
Nachrichtenschicht wie Internet-Protokollen (z. B. TCP/IP oder UDP/IP)
implementiert werden. Somit kann die Rechnerumgebung über das
Internet verteilt werden. In einer Ausführungsform kann das Nachrichtensystem
auch gemeinsam genutzten Speicher als einen Mechanismus zur schnellen
Nachrichtenübergabe
zwischen Prozessen verwenden, wenn sich der Client und/oder der
Space-Server und/oder
der Dienst auf demselben Computersystem befinden. Das verteilte
Verarbeitungsmodell von 6 kann auch sehr skalierbar
sein, weil ein Client fast jeder Größe konfiguriert werden kann,
XML-Nachrichten zu senden und/oder zu empfangen.
-
Wie
in 6 gezeigt, können
zwei Arten von Softwareprogrammen in dem verteilten Verarbeitungsmodell
ablaufen: Dienste 112 und Clients 110. Die Dienste 112 können ihre
Eigenschaften Clients anpreisen bzw. anbieten, die die Dienste nutzen
möchten.
Die Dienste 112 können
ihre Eigenschaften in den Spaces 114 anbieten. Wie in 7 dargestellt,
können
sich Clients 110 und Dienste 112 innerhalb desselben
Netzwerkgerätes
bzw. derselben Netzwerkeinrichtung befinden oder nicht. Zum Beispiel
unterstützt
jede der Einrichtungen 120 und 124 einen Client,
wohingegen der Dienst 112a und der Client 110b in
derselben Einrichtung 122 implementiert sind. Es ist auch,
wie in 7 dargestellt, keine bestimmte
Plattform notwendig, damit die Einrichtungen die Clients und Dienste
unterstützen.
Zum Beispiel ist die Einrichtung 120 Java-basiert, wohingegen die
Einrichtung 124 eine Laufzeitumgebung mit art-eigenem Code
zur Verfügung
stellt.
-
Eine
Einrichtung kann eine netzwerkfähige,
adressierbare Transporteinheit sein. Beispieleinrichtungen umfassen,
sind jedoch in keiner Weise beschränkt auf: PDAs, Mobiltelefone,
Notebook-Computer,
Laptops, Desktop-Computer, leistungsfähigere Computersysteme, sogar
Supercomputer. Sowohl Clients als auch Dienste können URI-adressierbare Instanzen
von Software (oder Firmware) sein, die auf Einrichtungen ablaufen.
Unter Verwendung der Architektur verteilter Rechnerumgebungen kann
auf einem Client ein Dienst ablaufen. Ein Space ist ein Dienst,
der einen Behälter
bzw. Speicher von XML-Dokumenten verwaltet. Auch wenn es redundant
ist, kann der Begriff Space-Dienst hier zur besseren Lesbarkeit
verwendet werden. Eine Softwarekomponente kann zu verschiedenen
Zeiten bzw. Zeitpunkten sowohl ein Client als auch ein Dienst sein. Zum
Beispiel ist in dem Fall, daß ein
Dienst einen Space verwendet (z. B. um sich anzubieten), dieser
Dienst ein Client des Space.
-
8 stellt
das grundlegende Modell der verteilten Rechnerumgebung In einer
Ausführungsform
dar. Die verteilte Rechnerumgebung kann Clients 110 mit
Diensten 112 durch das gesamte Netzwerk verbinden. Das
Netzwerk kann ein Weitverkehrsnetzwerk wie das Internet sein. das
Netzwerk kann auch eine Kombination von Netzwerken wie ein lokales
Netzwerk (LAN) sein, das mit einem drahtlosen Netzwerk über das
Internet verbunden ist. Wie in 8 abgebildet,
veröffentlicht
ein Dienst 112 eine Annonce bzw. Bekanntmachung 132 seiner
selbst (dargestellt in XML) in einem Space 114. Die Annonce 132 gibt
das XML-Schema und die URI-Adresse des Dienstes an. Danach kann
ein Client in der Annonce 132 nachsehen. Der Client kann
die Annonce 132 verwenden, um ein Gatter 130 einzurichten.
Das Gatter 130 ermöglicht
es dem Client 130, den Dienst 112 ablaufen zu
lassen, indem er XML-Nachrichten an den Dienst 112 sendet
(und von diesem empfängt).
-
Einige
Ergebnisse des Ablaufen-Lassens eines Dienstes können an den Client in einer
XML-Nachricht zurückgegeben
werden. Da jedoch andere Ergebnisse zu groß sein können, als daß sie ein
kleiner Client auf einmal empfangen und verbrauchen könnte, kann
ein Dienst 112 diese Ergebnisse oder eine XML-Repräsentation
der Ergebnisse 134 in einen Space 114 stellen,
wie in 9 gezeigt, und sie als Referenz
(in einer XML-Nachricht) statt als Wert an den Client 110 zurückgeben.
Beispiele von Verfahren der Lieferung einer Referenz auf Ergebnisse
umfassen, sind jedoch nicht beschränkt auf: Lieferung einer URI
in der Nachricht, die auf die Ergebnisse in einem Space verweist,
und: Lieferung eines XML-Dokumentes in der Nachricht, das die URI
der Ergebnisse enthält.
Anschließend
kann der Client 110 auf die Ergebnisse zugreifen oder sie
als Referenz an einen anderen Dienst übergeben. Der Space, in dem
die Ergebnisse gespeichert werden können, kann verschieden sein
von dem Space, in dem der Dienst angezeigt wird.
-
In
einer Ausführungsform
verwendet die verteilte Rechnerumgebung XML für die Definition, Annonce und
Beschreibung von Inhalten. Neuer Inhalt für die verteilte Rechnerumgebung
(zum Beispiel Nachrichten und Annoncen) wird in XML definiert. Existierende
Arten von Inhalten (z. B. für
andere Umgebungen entwickelte) können
auch mittels XML als eine Stufe der Indirektheit (Metadaten) beschrieben
werden. XML stellt ein leistungsfähiges Mittel zur Repräsentation
von Daten überall
in einem verteilten System zur Verfügung, weil XML ähnlich zu
der Art und Weise, in der Java universellen Code zur Verfügung stellt,
universelle Daten zur Verfügung
stellt. Der XML-Inhalt kann durch Schemata strikt typisiert und
validiert werden. Unter Verwendung eines bereitstehenden XML-Schemas kann das
System sicherstellen, daß nur
gültiger
XML-Inhalt in einer Nachricht übergeben
wird. XML-Inhalt kann auch in andere Arten von Inhalten wie HTML
und WML übersetzt werden.
Daher können
Clients, die XML nicht verstehen, immer noch die Dienste der verteilten
Rechnerumgebung verwenden.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung das Protokoll definieren, das
verwendet wird, um Clients mit Diensten zu verbinden, und Inhalt
in Spaces und Speichern zu adressieren. Die Verwendung von Nachrichten
zum Definieren eines Protokolls erlaubt es, daß viele verschiedene Arten
von Geräten
bzw. Einrichtungen an dem Protokoll teilnehmen. Jeder Einrichtung
kann es freigestellt werden, das Protokoll in einer Art zu implementieren,
die am besten für
ihre Fähigkeiten
und ihre Rolle geeignet ist. Zum Beispiel sind nicht alle Einrichtungen
in der Lage, eine Java-Laufzeitumgebung zu unterstützen. Die
Protokolldefinition für
die verteilte Rechnerumgebung macht die Verwendung von Java in einer
Einrichtung weder erforderlich noch beinhaltet sie diese. Genauso
wenig schließt
sie sie aus.
-
Die
Fähigkeiten
eines Dienstes können
mittels der Nachrichten, die der Dienst akzeptiert, ausgedrückt werden.
Ein Satz von Nachrichten eines Dienstes kann unter Verwendung eines
XML-Schemas definiert
werden. Ein XML-Nachrichtenschema definiert jedes Nachrichtenformat
unter Verwendung von typisierten XML-Tags. Die Verwendungsregeln
für Tags
können
auch in dem Schema definiert werden. Das Nachrichtenschema kann
eine Komponente einer XML-Annonce zusammen mit dem Endpunkt der
Nachricht des Dienstes sein, der zum Empfang der Nachrichten verwendet
wird. Die verteilte Rechnerumgebung kann es Clients er-möglichen,
das ganze oder eine gewisse Teilmenge der Fähigkeiten eines Dienstes zu
verwenden. Sicherheitsrichtlinien können verwendet werden, um den
Satz von Fähigkeiten,
der einem Client gegeben wird, zu erzwingen. Zum Beispiel kann der
Client, sobald dem Client ein Satz von Fähigkeiten gegeben wurde, diesen Satz
nicht ohne richtige bzw. passende Berechtigung ändern. Dieses Modell der Definition
von Fähigkeiten
ermöglicht
Dienstestufen, die von einer Grundmenge von Fähigkeiten bis zu einer erweiterten
Menge reichen. Erweiterungen können
den Diensten durch Ergänzen
der Zahl von erkannten Nachrichten hinzugefügt werden.
-
In
einer Ausführungsform
werden alle Operationen in der verteilten Rechnerumgebung als XML-Nachrichten
verkörpert,
die zwischen Clients und Diensten gesendet werden. Speicheranbieter
(sowohl von transientem als auch dauerhaftem Speicher) sind Beispiele
von Diensten, die Clients und Dienste in die Lage versetzen, Inhalt
zu speichern, anzuzeigen und zu adressieren. Clients und Dienste
können
sich gegenseitig finden und sie können Vermittlerinhalt finden,
indem sie einen transienten Speicherraum bzw. -space benutzen. Dienste
können
einen Inhalt oder eine Dienstannonce in einen Space stellen. Die
Annonce kann die Art des Inhalts oder die Fähigkeiten des Dienstes beschreiben.
Clients können
anschließend
Spaces durchblättern, um
nach Annoncen zu schauen, die zu einem gewünschten Satz von Fähigkeiten
passen. Wenn ein Client eine passende Annonce findet, kann ein Kommunikationskanal
aufgebaut werden, der eine bidirektionale Übergabe von Nachrichten an
den Dienst ermöglicht,
der die Annonce enthält.
In einer Ausführungsform
wird der Kommunikationskanal authentisiert. Ergebnisse (die nur
eine andere Art von Inhalt sind) von Dienstoperationen können in
einer Antwortnachricht direkt an den Client zurückgegeben, in einem Space angezeigt
und gespeichert oder in einem Space angekündigt, jedoch dauerhaft gespeichert werden.
Gespeicherte Ergebnisse können
unter Verwendung einer URI (z. B. in der Antwortnachricht geliefert)
adressiert werden und können
einen zugeordneten Authentisierungsnachweis haben.
-
Nachrichtengatter
-
Wie
oben diskutiert, setzt die verteilte Rechnerumgebung die Verwendung
einer Datenbeschreibungssprache wie XML wirksam ein. XML kann verwendet
werden, um eine Zieleinheit bzw. -entität (z. B. ein Dokument, einen
Dienst oder einen Client) soweit zu beschreiben, daß Code erzeugt
werden kann, um auf diese Entität
zuzugreifen. Der erzeugte Code zum Zugriff auf die Zielentität kann als
ein Nachrichtengatter bezeichnet werden. Somit unterscheidet sich
die verteilte Rechnerumgebung In einer Ausführungsform von anderen verteilten
Rechnerumgebungen darin, daß anstatt
den benötigten
Code zwischen Objekten zu übergeben,
der notwendig ist, um auf andere Objekte zuzugreifen, die Umgebung
Zugriff zu XML-Beschreibungen eines Objektes oder Ziels zur Verfügung stellt,
so daß auf
der Grundlage der XML-Beschreibung Code erzeugt werden kann, um
auf das Ziel zuzugreifen. Die verteilte Rechnerumgebung kann ein
XML-Schema verwenden, um sowohl Typsicherheit als auch ein Programmiermodell
zu gewährleisten
(z. B. unterstützte
Nachrichten), ohne sich hinsichtlich sprachspezifischer APIs abstimmen
zu müssen,
nur XML-Schemata.
-
Aus
einem XML-Schema erzeugter Code kann auch die Sprache, die Sicherheit,
die Typsicherheit und Charakteristiken der Ausführungsumgebung der lokalen
Plattform enthalten. Die lokale Plattform kann somit Kontrolle über den
erzeugten Code haben, um sicherzustellen, daß er fehlerfrei ist und nur
gültige
Daten gemäß dem Schema
erzeugt. Der erzeugte Code kann sowohl zu der Codeausführungsumgebung
des Client (z. B. Java, C++, Smalltalk) als auch zu seinem Management-
und Sicherheits-Rahmenwerk (Webserver und/oder Betriebssystem) konform
sein.
-
Man
beachte, daß die
verteilte Rechnerumgebung es nicht erfordert, daß der aus einem XML-Schema generierte
Code "on the fly" zur Laufzeit erzeugt
wird. Stattdessen kann ein Teil des Codes oder der gesamte Code
für Kategorien
(oder Klassen) der Dienste vorab generiert und dann während des
Erstellungs- bzw. Aufbauprozesses für die Plattform eingebunden
werden. Vorab-Generierung
von Code kann für
einige Clients wie eingebettete Systeme nützlich sein, wobei bestimmte
XML-Schemata bereits bekannt sind. In einer Ausführungsform braucht ein Teil
des Codes oder der gesamte Code überhaupt
nicht tatsächlich
erzeugt zu werden. Ein privater Code-Ladeplan (beim Client) könnte In
einer Ausführungsform
verwendet werden, um den Generierungsprozeß anzureichern. darüber hinaus
kann die verteilte Rechnerumgebung nach einigen Ausführungsformen
eine Schnittstelle angeben, um Code für zusätzliche Funktionen beim Zugriff
auf einen Dienst herunterzuladen (siehe z. B. die unten beschriebenen
Nachrichtenleiter). Typischerweise kann solcher heruntergeladener
Code klein sein und der Client kann die Option haben, den Code herunterzuladen
oder nicht.
-
Der
Ausdruck "erzeugter
Code" kann sich
auf Code beziehen, der seinen Ursprung beim Client hat unter der
Kontrolle bzw. Steuerung der Codeausführungsumgebung des Client,
oder auf Code, der woanders erzeugt wird (wie auf dem Dienstsystem
oder auf einem Space-Dienstsystem) und der in das Clientsystem nach
der Erzeugung heruntergeladen werden kann. Der Zeitpunkt zur Anbindung
kann während
der Laufzeit sein. Zur Laufzeit kann der Code an eine Dienstadresse
(URI) gebunden werden, so daß eine
Nachricht zu dieser Dienstinstanz gesendet werden kann.
-
Wie
oben diskutiert, kann die Schnittstelle zu irgendeinem Dienst in
der verteilten Rechnerumgebung durch ein XML-Schema spezifiziert
werden, indem die Menge von Nachrichten definiert wird, die ein
Client diesem Dienst senden (und von ihm empfangen) kann. Wie in 10 dargestellt, können der Client 110 und
der Dienst 112 jeweils ein Nachrichtengatter 130 zum
Kommunizieren gemäß dem spezifizierten
XML-Schema einrichten bzw. aufbauen. Aus dem für den Dienst 112 angekündigten
XML-Schema (und möglicherweise
aus anderer Information in der Dienstannonce) kann ein Nachrichtengatter 130a oder 130b von
dem Client 110a bzw. Client 110b eingerichtet
werden. Ein entsprechendes Nachrichtengatter 130c, das
aus demselben XML-Schema erzeugt wird, kann auch bei dem Dienst 112a existieren.
Ein Gatter 130 ist ein Nachrichtenendpunkt, der typischere
XML-Nachrichten senden und/oder empfangen kann und der die Richtigkeit
bezogen auf Typen von XML-Nachrichten überprüfen kann, wenn er die Nachrichten
sendet und/oder empfängt.
Das Nachrichtengatter kann auch Authentisierungs- und/oder andere
Sicherheitsmechanismen vorsehen, um sicherzustellen, daß der Nachrichtenendpunkt
sicher ist. In einer Ausführungsform
sind Nachrichtengatter immer sicher.
-
Die
oben beschriebene Nachrichtenschicht der verteilten Rechnerumgebung
kann an ein Gatter angeschlossen sein oder Teil eines Gatters sein.
Die Nachrichtenschicht liefert unter Verwendung eines Netzwerktransportmediums
eine geordnete Reihe von Bytes asynchron vom Sender an den Empfänger ab,
wobei sie sowohl beim Sender als auch beim Empfänger der Begriff bzw. die Vorstellung
aufrecht erhält,
daß diese Sequenz
von Bytes eine unteilbare Einheit, die Nachricht, ist. Die verteilte
Rechnerumgebung setzt nicht voraus, daß das Netzwerktransportmedium
IP-basiert ist. Stattdessen kann die Nachrichtenschicht über einem beliebigen
Netzwerktransportmedium sitzen, welches auch immer von dem Gerät bzw. der
Einrichtung unterstützt
wird.
-
Nachrichtengatter
könne einen
Mechanismus zum Senden und Empfangen von XML-Nachrichten zwischen Clients und Diensten
bereitstellen. Die XML-Nachrichten können "typisiert" sein. Zum Beispiel kann die Nachricht
ein Tag enthalten, um anzuzeigen, ob ein Datenfeld der Nachricht
z. B. ganzzahlig oder ein Fließkomma-Wert
ist, oder aus Textdaten etc. besteht. Ein Nachrichtengatter kann
dafür eingerichtet
sein, die Richtigkeit der Typen von gesendeten oder empfangenen
Nachrichten zu überprüfen. Ein
XML-Schema kann für einem
Dienst zur Verfügung
stehen, das die Menge von Nachrichten beschreibt, die von dem Dienst
akzeptiert und/oder von dem Dienst gesendet werden. Ein Nachrichtengatter
kann die Richtigkeit von gesendeten und empfangenen Nachrichten
gemäß dem XML-Schema überprüfen, für das das
Gatter eingerichtet wurde.
-
Ein
Gatter kann als eine einzelne, unteilbare Einheit von Code und Daten
eingerichtet werden, die Typüberprüfung und/oder Überprüfung der
Richtigkeit von Nachrichten und/oder Identifizierung von Sendern
für Nachrichten
zwischen einem Client und einem Dienst in der verteilten Rechnerumgebung
durchführt.
In einer Ausführungsform
kann, sobald die unteilbare Einheit von Code und Daten für ein Nachrichtengatter
eingerichtet wurden, dieses nicht mehr bezüglich seiner Typi sierung, Nachrichtendeskriptoren
und Senderidentifikation geändert
werden. In anderen Ausführungsformen
kann das Gatter bezüglich
der Inhalte des Nachrichtenschemas abgewandelt werden, nachdem das
Gatter erzeugt wurde, einschließlich
des Löschens,
Hinzufügens
und Modifizierens von Nachrichten in dem Nachrichtenschema.
-
Ein
Nachrichtengatter ist der Endpunkt von Nachrichten für einen
Client oder einen Dienst in der verteilten Rechnerumgebung. Ein
Nachrichtengatter kann einen sicheren Endpunkt bereitstellen, der
typsichere XML-Nachrichten sendet und empfängt. Nachrichtengatter können es
Clients und Diensten ermöglichen, XML-Nachrichten
in einer sicheren und zuverlässigen
Weise über
irgendein geeignetes Nachrichtentransportmedium (z. B. HTTP) auszutauschen.
Für einen
Client kann ein Nachrichtengatter die Vollmacht bzw. Ermächtigung
darstellen, einige oder alle der Leistungen eines Dienstes zu verwenden.
Jede Leistung kann mittels einer Nachricht ausgedrückt werden,
die an einen Dienst gesendet werden kann. Jede solche Nachricht
kann durch ein Nachrichtengatter beim Client gesendet werden, das
die Richtigkeit der Nachricht überprüfen kann. Die
Nachricht kann von einem Nachrichtengatter beim Dienst empfangen
werden, das die Nachricht authentisieren und ihre Richtigkeit überprüfen kann.
-
Ein
Nachrichtengatter kann einen sicheren Kommunikationsendpunkt bereitstellen,
der eine Typüberprüfung für XML-Nachrichten
vornimmt. Wie unten weiter diskutiert, kann ein Nachrichtengatter
auch einen Mechanismus bereitstellen, um den Nachrichtenstrom zwischen
Clients und Diensten einzuschränken.
In einer Ausführungsform
wird ein Paar von Nachrichtengattern beim Client und beim Dienst
erzeugt, falls sie nicht bereits existieren, wenn ein Client auf
einen Dienst zugreifen möchte.
In einer Ausführungsform
kann das Nachrichtengatter beim Dienst erzeugt werden, wenn der
Dienst die erste Nachricht von dem Nachrichtengatter beim Client
empfängt.
In einer Ausführungsform
können
ein oder mehrere Nachrichtengatter beim Dienst erzeugt werden, wenn
der Dienst initialisiert wird, und verwendet werden, um mit Nachrichtengattern
bei Clients ein Paar zu bilden, wenn diese erzeugt werden. Das Erzeugen
eines Nachrichtengatters kann einen Authentisierungsdienst einbeziehen,
der die gewünschte
Sicherheitsstufe und den Satz bzw. die Menge von Nachrichten aushandelt,
die zwischen dem Client und dem Dienst übergeben werden. In einer Ausführungsform kann
der Authentisierungsdienst ein ID-Token eines Client (auch als ein
Client-Token bezeichnet), ein ID-Token eines Dienstes (auch als
ein Dienst-Token bezeichnet) und ein Nachrichtenschema in einer
Datenrepräsentationssprache
akzeptieren, das die Menge von Nachrichten in der Datenrepräsentationssprache
beschreibt, die an den Dienst gesendet oder von dem Dienst empfangen
werden können.
Zum Beispiel können
Nachrichten beschrieben werden, die von einem Client an einen Dienst
gesendet werden können,
um den Dienst aufzurufen oder um Aspekte des Dienstes aufzurufen.
Es können
auch Nachrichten beschrieben werden, die von dem Dienst zu senden
sind, wie Antwortnachrichten und Nachrichten für Ereignismeldungen. Siehe
Abschnitt über Authentisierung
und Sicherheit unten wegen weiterer Diskussion darüber, wie
der Authentisierungsdienst bei der Einrichtung und der Verwendung
eines Nachrichtengatters verwendet werden kann.
-
Ein
Paar aus einem Nachrichtengatter beim Client und einem Nachrichtengatter
beim Dienst kann es ermöglichen,
daß Nachrichten
zwischen dem Client und dem Dienst gesendet werden. In einer Ausführungsform
können
Nachrichtengatter eingerichtet werden, die nur eine Teilmenge der
Gesamtmenge von Nachrichten, wie in dem Nachrichtenschema für einen
Dienst beschrieben, senden und/oder empfangen. Dieser eingeschränkte Zugang
kann innerhalb der verteilten Rechnerumgebung verwendet werden,
um eine Strategie bzw. Politik eines geringsten bzw. kleinsten Privilegs
zu implementieren, wodurch Clients auf der Grundlage einer Sicherheitsstrategie
nur Zugang zu spezifischen, individuellen Nachrichtentypen gegeben
wird. Siehe Abschnitt über
Authentisierung und Sicherheit unten wegen weiterer Diskussion der
Sicherheitsprüfungen
für die Verwendung
von Gattern und das Einrichten von Gattern.
-
Client-
und Dienstgatter können
das tatsächliche
Senden (und Empfangen) der Nachrichten von dem Client an den Dienst
durchführen,
indem sie das Protokoll verwenden, das in der Dienstannonce angegeben ist
(URI des Dienstes in der Dienstannonce). Der Client kann den Dienst über diese
Nachrichtenübergabe
ablaufen lassen. Ein Nachrichtengatter kann eine Abstraktionsstufe
zwischen einem Client und einem Dienst bereitstellen. Ein Client
kann auf ein Dienstobjekt durch ein Nachrichtengatter zugreifen,
anstatt auf das Dienstobjekt direkt zuzugreifen. Da das Nachrichtengatter
den Dienst von dem Client abstrahiert, braucht der Code des Dienstes
nicht geladen und dann gestartet zu werden, bis der Client das erste
Mal den Dienst benutzt.
-
Das
Clientgatter kann auch eine Überprüfung der
Nachricht gegen das XML-Schema bereitstellen, oder eine Überprüfung der
Nachricht gegen das XML-Schema kann von dem Dienstgatter durchgeführt werden,
z. B. wenn der Client anzeigt, daß sie noch nicht überprüft wurde.
Nach einigen Ausführungsformen
ist eine Überprüfung für einfache
Clients womöglich
nicht praktikabel und kann daher bei dem Client nicht erforderlich
sein. Nach einigen Ausführungsformen
kann eine Überprüfung von
dem Dienst durchgeführt
werden. Die Gatter können
auch Authentisierungsaktivierungs- und/oder Sicherheitssysteme bzw.
-abläufe
durchführen.
In einer Ausführungsform
ist es einem Client in dem Fall, daß er das in der Dienstannonce
angegebene Protokoll nicht unterstützt, unter Umständen nicht
möglich,
das richtige Gatter einzurichten. Um dieses Problem zu vermeiden,
können
Dienstannoncen (zum Einrichten von Gattern verwendet) eine Liste
möglicher URIs
für einen
Dienst enthalten, so daß eine
Vielzahl von Clients unterstützt
werden kann.
-
Ein
elementares Nachrichtengatter kann ein API implementieren, um Nachrichten
zu senden und zu empfangen. Das SPI schiebt Daten (z. B. XML-Nachrichten)
in das Gatter hinein und von dort heraus und validiert dabei Nachrichten
vor dem Senden und/oder beim Empfang. In einer Ausführungsform
können
Nachrichtengatter ein festgelegtes, minimales API unterstützen, um
Nachrichten zu senden und zu empfangen. Dieses API kann auf andere
Funktionen erweitert werden. wie unten diskutiert. Wie in 10b dargestellt kann ein Gatter 130 gemäß einem
XML-Schema 132 erzeugt werden. Der erzeugte Code des Gatters überprüft Nachrichten
auf der Grundlage des XML-Schemas.
Das Gatter kann korrekte Nachrichtenarten und/oder korrekten Inhalt
durch das Nachrichten-API überprüfen. Wie
in 10b dargestellt, kann eine überprüfte Nachricht
durch das Nachrichten-API an einen Dienst gesendet werden. Die Nachricht
kann durch ein entsprechendes Gatter beim Dienst empfangen werden.
Als Antwort auf die Nachricht kann der Dienst Ergebnisse 180 erzeugen.
Der Dienst kann die Ergebnisdaten 182 durch sein Gatter
zurückgeben.
Die Ergebnisdaten können die
Ergebnisse selbst oder eine Referenz auf die Ergebnisse wie ein
URI auf die in einem Space gespeicherten Ergebnisse sein. Nach verschiedenen
Ausführungsformen
kann das Nachrichten-API zum Beispiel synchrone Nachrichten (Antwort
auf Anforderung), asynchrone Nachrichten (Antwort ist von der Anforderung
getrennt bzw. nicht mit der Anforderung verbunden), Unicast-Nachrichten
(Punkt zu Punkt), Multicast-Nachrichten (Rundsenden) und Veröffentlichen
und Abonnieren (Ereignisnachrichten) unterstützen. Andere Arten von Nachrichten
wie Nachrichten zum entfernten Methodenaufruf (Remote Method Invocation)
können
auch unterstützt
werden.
-
Jede
von einem Gatter gesendete Nachricht kann einen Authentisierungsnachweis
enthalten, so daß das
empfangende Gatter die Nachricht authentisieren kann. Jede Nachricht
kann auch ein Token enthalten, das Information enthält, die
es dem empfangenden Gatter ermöglicht,
zu überprüfen, daß die Nachricht
nicht kompromittiert oder geändert
wurde. Zum Beispiel kann der Sender einen Hash oder eine Prüfsumme der Nachricht
berechnen, der bzw. die von dem Empfänger überprüft werden kann. Der Sender
kann dieses Token und/oder die gesamte Nachricht unter Verwendung
des privaten Schlüssels
des Senders auch verschlüsseln und
kann in die verschlüsselte
Nachricht den entsprechenden öffentlichen
Schlüssel
aufnehmen, so daß der Empfänger überprüfen kann,
daß das
Token nicht geändert
wurde. Siehe den Abschnitt unten zu Authentisierung und Sicherheit.
-
Ein
Paar von Nachrichtengattern kann einen Mechanismus zum Kommunizieren
von Anforderungen von Clients an Dienste und der Antwort von den
Diensten an die Clients bereitstellen. Zwei zugeordnete Endpunkte
von Nachrichtengattern können
verwendet werden, um einen sicheren, unteilbaren, bidirektionalen Nachrichtenkanal
zur Übergabe
einer Anforderungs-Antwort-Nachricht
zu erzeugen. Daher kann die verteilte Rechnerumgebung ein Transportmedium
für Nachrichten
einsetzen, in dem ein Nachrichtengatter sowohl auf Seiten des Client
als auch auf Seiten des Dienstes existiert. Die beiden Gatter können zusammenarbeiten,
um einen sicheren und zuverlässigen
Nachrichtenkanal bereitzustellen.
-
In 11a wird eine Darstellung für eine Ausführungsform mitgeliefert, die
das Einrichten eines Gatters 130a in einem Client 110 aus
einer Dienstannonce oder einer anderen Dienstbeschreibung 132 zeigt.
Der Client kann eine Gatterfabrik 140 haben, die zuverlässigen Code
beim Client zum Generieren von Gattern auf der Grundlage von XML-Dienstbeschreibungen
darstellt. Die Verwendung der Gatterfabrik 140 kann sicherstellen,
daß das
Gatter, das es erzeugt, auch zuverlässigen Code darstellt und daß der Code
bezüglich
der Serverannonce korrekt ist. Wie in 11b gezeigt,
kann ein Gatter 130c auch bei einem Dienst 112 generiert werden.
Das Clientgatter 130a und das Dienstgatter 130c stellten
Nachrichtenendpunkte zur Kommunikation zwischen dem Client und dem
Dienst bereit. In einer Ausführungsform
sind die Teile, die die Gatterfabrik benötigt, um ein Gatter 130 einzurichten,
das XML-Schema des Dienstes (aus der Serverannonce) und der URI des Dienstes
(aus der Serverannonce). In einer anderen Ausführungsform kann auch ein Authentisierungsnachweis
erhalten werden und beim Einrichten eines Gatters verwendet werden,
indem man einen in der Serverannonce angegebenen Authentisierungsdienst
ablaufen läßt.
-
Eine
Gatterfabrik kann einen zuverlässigen
Mechanismus bereitstellen, um Nachrichtengatter zu erzeugen. Nach
einigen Ausführungsformen
muß der
zum Erzeugen des Gatters verwendete Code zuverlässiger Code sein, um sicherzustellen,
daß ein
Nachrichtengatter ein zuverlässiger
Nachrichtenendpunkt ist. Eine Gatterfabrik 140 kann ein
zuverlässiges
Codepaket sein, das verwendet wird, um Gatter zu erzeugen. In einer Ausführungsform
kann jede Plattform einer Client- und
einer Diensteinrichtung, die in der verteilten Rechnerumgebung Nachrichten
senden und empfangen möchte,
eine Gatterfabrik haben. Nach einigen Ausführungsformen können Gatter
von einer separaten Gatterfabrik vorkonstruiert werden, so daß eine Einrichtung
mit vorkonstruierten Gattern keine vollständige Gatterfabrik braucht
oder eine partielle Gatterfabrik enthalten kann, um zur Laufzeit
einen Dienst-URI und/oder einen Authentisierungsnachweis an das
vorkonstruierte Gatter zu binden (z. B. wenn das Senden von Nachrichten
gewünscht
wird).
-
Eine
Gatterfabrik für
eine Einrichtung kann Gattercode erzeugen, der die Sprache, Sicherheit,
Typsicherheit und/oder Eigenschaften der Ausführungsumgebung der lokalen
Plattform der Einrichtung enthält.
Indem sie Gatter selbst erzeugt, hat eine Einrichtung die Fähigkeit
sicherzustellen, daß der
erzeugte Gattercode fehlerfrei ist, nur gültige Daten erzeugt und für Typsicherheit
sorgt. Ein Vorteil einer Einrichtung, die ihren eigenen Gattercode
generiert, anstatt den Code zum Zugriff auf einen Dienst herunterzuladen,
ist, daß die
Codemanagement-Umgebung des Client die Kontrolle hat. Der generierte
Code kann sowohl zu der Codeausführungsumgebung
des Client (z. B. Java, C++, Smalltalk) als auch zu seinem Management-
und Sicherheits-Rahmenwerk (Webserver und/oder Betriebssystem) konform
sein. Erzeugter Code ist auch zuverlässiger Code, weil die Laufzeitumgebung
des Client bei seiner Erzeugung beteiligt war. Zuverlässige Sicherheitsinformation
kann daher auch von dem zuverlässigen,
erzeugten Code hinzugefügt
werden. Somit kann eine Einrichtung ein XML-Nachrichten-Schema für einen
Dienst empfangen und dann ein Gatter auf der Grundlage dieses Schemas
einrichten, um auf die Einrichtung zuzugreifen. Das XML-Schema kann
betrachtet werden, als ob es den Vertrag bzw. Kontrakt mit dem Dienst
definiert, und der erzeugte Gattercode kann betrachtet werden, als
ob er eine sichere Art und Weise bereitstellt, um den Kontrakt auszuführen. Man
beachte, daß offene
Einrichtungen, in denen man unzuverlässigen (z. B. heruntergeladenen)
Code ablaufen läßt, so eingerichtet
sein können,
daß Gatter
nur von zuverlässigem
Code generiert werden können.
Offene Einrichtungen können
ein Prozeßmodell
anwenden, in dem Gatter in einem geschützten, isolierten Codebehälter eingeschlossen
sind, der für
Werkzeuge bzw. Tools wie Debugger nicht zugänglich ist, die in der Lage
sind, die Implementierung des Gatters aufzudecken, besonders den
Authentisierungsnachweis des Gatters.
-
Eine
Gatterfabrik 140 kann für
einen Client mit einem Dienst aushandeln, daß ein Gatter zum Senden von
Nachrichten an den Dienst erzeugt wird. In ähnlicher Weise kann bei dem
Dienst ein Gatter zum Empfang von Nachrichten von dem Clientgatter
und zum Senden von Nachrichten an das Clientgatter eingerichtet
werden. Zusammen können
die Client- und Dienstgatter einen sicheren, bidirektionalen Kommunikationskanal
bilden.
-
Eine
Gatterfabrik kann eine Abstraktionsstufe beim Erzeugen eines Gatters
bieten. Wenn zum Beispiel ein Client einen Dienst verwenden möchte, kann
das Gatter von einer Gatterfabrik als Teil des Instantiieren des Dienstes
erzeugt werden, anstatt daß der
Client ein Gatter zum Zugriff auf den Dienst erzeugt.
-
Die
Gatterfabrik kann ihre eigenes, zuverlässiges Nachrichtengatter erzeugen
oder enthalten, das verwendet wird, um mit einem Authentisierungsdienst
zu kommunizieren (z. B. durch die Dienstannonce angegeben), um einen
Authentisierungsnachweis für
das Gatter, das eingerichtet wird, zu empfangen. Für Dienste, die
den Zugriff bzw. Zugang nicht einschränken, kann ein Gatter ohne
einen Authentisierungsnachweis eingerichtet werden. Die Gatter für solche
Dienste brauchen möglicherweise
nicht mit jeder Nachricht einen Authentisierungsnachweis zu senden,
weil der Dienst den Zugang nicht einschränkt. Der Authentisierungsdienst
ist ein Beispiel eines Dienstes, der In einer Ausführungsform
den Zugang nicht einschränkt.
Wenn der Dienst den Zugang nicht einschränkt, dann kann es die Gatterfabrik
vermeiden, einen Authentisierungsdienst als Teil der Gattereinrichtung
ablaufen zu lassen, und kann einbezogene Bereitstellungen für einen
Authentisierungsnachweis als Teil des eingerichteten Gatter vermeiden.
Die Gatterfabrik kann auch ein XML-Nachrichtenschema (Z. B. durch eine
Dienstannonce angegeben) empfangen oder herunterladen, um ein Gatter
einzurichten, das diesem Schema entspricht bzw. das zu diesem Schema
paßt.
Die Gatterfabrik kann auch einen URI für den Dienst und/oder für ein Nachrichtengatter
beim Dienst empfangen oder herunterladen, um ihn beim Erzeugen des Nachrichtengatters
beim Client zum Kommunizieren mit dem URI zu verwenden.
-
Darüber hinaus
kann eine weitere Optimierung beim Einrichten eines Gatters bei
bestimmten Clients eingesetzt werden, die eine Überprüfung der Nachrichten gegen
das XML-Schema des Dienstes nicht durchführen möchten. Der Client kann zu klein
sein, um die Überprüfung durchzuführen, oder
kann sich darauf verlassen, daß das
Dienstgatter die Überprüfung durchführt, oder
kann einfach wählen,
die Überprüfung nicht durchzuführen (z.
B. um den Speicherbedarf des Gatters zu reduzieren). Die Gatterfabrik
kann dafür
eingerichtet sein, eine Anzeige bzw. einen Hinweis zu empfangen,
ob ein Gatter zum Überprüfen der
Nachrichten gegen das bereitgestellte XML-Schema eingerichtet werden
sollte oder nicht. Nach einigen Ausführungsformen können bestimmte
Clients eine Gatterfabrik haben, die keine Überprüfung von Nachrichten gegen
das Schema bei den eingerichteten Gattern vorsieht. Nach einigen
Ausführungsformen
können
Gatter so vorkonstruiert werden, daß sie Nachrichten nicht überprüfen. Nach
einigen Ausführungsformen
kann ein Gatter eingerichtet werden, nur ausgehende Nachrichten
zu überprüfen oder
nur empfangende Nachrichten zu überprüfen. Somit
kann es ein Client nach einigen Ausführungsformen vermeiden oder
zu vermeiden wählen,
einiges oder alles von dem Gattercode, der die Nachrichten gegen
das XML-Schema überprüft, aufzubauen
bzw. einzubauen.
-
Nach
einigen Ausführungsformen
können
Einrichtungen einen Cache von Gattern vorhalten, um zu vermeiden,
sie jedes Mal aufzubauen bzw. einzurichten, wenn derselbe Dienst
abläuft.
Wenn zum Beispiel ein neues Gatter von einer Gatterfabrik eingerichtet
wird, kann das Gatter in einem Gattercache vorgehalten werden. Wenn
das Gatter nicht mehr verwendet wird, wird ein in dem Gattercache
gehalten, anstatt gelöscht
zu werden. Wenn der Gattercache voll wird, können ein oder mehrere Gatter
gemäß einem
Cache-Ersetzungsalgorithmus wie least-recently-used bzw. amlängsten-nicht-verwendet
aus dem Gattercache entfernt werden. Wenn die Gatterfabrik aufgerufen
wird, um ein Gatter einzurichten, prüft sie zunächst den Gattercache, um nachzusehen,
ob ein passendes Gatter bereits existiert, so daß das Einrichten eines neuen
Gatters vermieden werden kann.
-
Der
Bau eines Gatters kann durch geeignete Wiederverwendung von Teilen,
die zum Aufbau anderer Gatter verwendet werden bzw. wurden, leicht
bzw. einfach gemacht werden. Gewisse Anteile eines jeden Gatters
können
gleich sein und können
somit von Gatter zu Gatter wiederverwendet werden wie Teile des
Codes zur Überprüfung der
Nachrichten. Ebenso kann für
einige Einrichtungen gemeinsamer Gattercode in die Systemsoftware
für die
Einrichtung eingebaut und von allen Gattern auf der Einrichtung
gemeinsam genutzt werden. Daher kann es die Gatterfabrik vermeiden,
diesen gemeinsamen Code für
jedes Gatter neu aufzubauen. Stattdessen kann die Gatterfabrik einfach
das Gatter an diesen Teil der Systemsoftware binden. Zum Beispiel kann
ein Teil der Systemsoftware bereitstehen, um die Nachrichtenschicht über einem
Transportmedium, welches auch immer auf der Einrichtung zur Verfügung steht,
zu behandeln.
-
Insbesondere
können
Space-Dienste gute Kandidaten für
viele der oben beschriebenen Optimierungen beim Aufbau eines Gatters
sein, da ein Dienstgatter, das für
einen Space-Dienst eingerichtet wurde, viele von denselben Funktionen
wie andere Dienstgatter für
diesen Space-Dienst durchführen
kann. Siehe den Abschnitt über
Spaces unten hinsichtlich weiterer Information zu Space-Diensten.
-
In
manchen Fällen
kann eine effizientere Form des Methodenaufrufs existieren. Wenn
zum Beispiel der Zieldienst auf derselben virtuellen Javamaschine
abläuft
wie die Clientanwendung, kann es eine effizientere Form des Methodenaufrufs
sein, eine dynamische Java-Proxyklasse für den Dienst zu erzeugen. In
einem solchen Fall kann der Aufruf einer Methode von java.lang.reflect
schneller sein, als eine Nachricht zu senden. Eine Prozedur bzw.
ein Vorgang zur Bindezeit eines Gatters kann hinsichtlich einer
solchen Optimierung prüfen
und sie verwenden, anstatt die Gatterfabrik ablaufen zu lassen bzw.
auszuführen,
um ein Gatter zu erzeugen oder ein existierendes Gatter zu binden.
-
In
einer Ausführungsform
wie für
spezielle Clients oder kleine, eingebettete Einrichtungen bzw. Geräte ist die
Erzeugung von Gattercode zur Laufzeit wegen des Speicherverbrauchs
und der Zeit zum Generieren des Codes möglicherweise nicht wünschenswert.
Daher können
nach einigen Ausführungsformen
Gatter vorgeneriert und in die Einrichtung eingebaut werden, anstatt
eine Gatterfabrik zu haben, die Gatter zur Laufzeit erzeugt. Zum
Beispiel können
Nachrichtengatter während
des Erstellens von eingebetteter Software als ein Mittel bzw. Verfahren
zum Einbeziehen eines si cheren Nachrichtenendpunktes erzeugt werden,
der nicht zur Laufzeit eingerichtet werden muß. Daher braucht ein Client
mit eingebauten Gattern möglicherweise
keine vollständige
Gatterfabrik oder benötigt
eventuell nur eine partielle Gatterfabrik, um gewisse Bindevorgänge an ein eingebautes
Gatter wie für
den URI und/oder den Authentisierungsnachweis zur Laufzeit durchzuführen.
-
Ein
Generierungswerkzeug kann für
das Vorgenerieren von Gattern vorgesehen sein. Das Generierungswertzeug
kann einen XML-Parser, einen Codegenerator und einen Codecompiler
enthalten. In einer Ausführungsform
kann der Codegenerator ein Generator von Java-Quellcode und der
Codecompiler eine Java-Codecompiler sein. Während des Erstellen von Software,
für die
eingebaute Nachrichtengatter gewünscht sind,
wird das Generierungswerkzeug mit der Eingabe aus allen relevanten
XML-Schemata ausgeführt,
für die Gatter
gewünscht
werden.
-
Wenn
es zum Beispiel für
eine Einrichtung gewünscht
ist, ein eingebautes Nachrichtengatter zu haben, das Nachrichten
von einer digitalen Kamera senden und empfangen kann, kann das Erstellen
der Software für
die Einrichtung beinhalten, das Generierungswerkzeug für Gatter
mit dem XML-Nachrichtenschema der Kamera als Eingabe laufen zu lassen
bzw. auszuführen.
Das XML-Schema kann
von dem XML-Parser analysiert werden, der das XML-Schema in eine
interne Form umwandeln kann, die für einen schnellen Zugriff während eines
Vorgangs zur Überprüfung der
Nachricht geeignet ist. Der Codegenerator des Werkzeugs kann Quellcode
für ein
Gatter bereitstellen, der dem Schema der Kamera entspricht. Nach
einigen Ausführungsformen
kann das Generierungswerkzeug auch den Quellcode kompilieren und
der Gattercode kann in das Softwarepaket für die Einrichtung bzw. das
Gerät eingebunden
werden. Zur Laufzeit kann der Kameradienst in der verteilten Rechnerumgebung
ausfindig gemacht werden. Der Nachrichten-URI für den Kameradienst kann an das
eingebaute Gatter für
die Kamera innerhalb des Gerätes
gebunden werden. Das Binden des URI an das vorab eingerichtete Gatter
kann von einem Gatterkonstrukteur bzw. -errichter innerhalb des
Gerätes
durchgeführt
werden. Der Gattererrichter kann eine viel kleinere, einfachere
Gatterfabrik sein. Wenn der Kameradienst eingerichtet ist, wird
der URI für
den Kameradienst an den Gattererrichter als eine XML-Nachricht übergeben. Der
Gattererrichter kann dann den URI an das vorab eingerichtete Gatter
binden.
-
Somit
kann ein Gatter teilweise oder vollständig zur Laufzeit erzeugt werden
oder ein Gatter kann vor der Laufzeit vorab erzeugt werden, wobei
ein Bindevorgang (z. B. für
ein URI oder einen Nachweis) während der
Laufzeit durchgeführt
wird. In einer Ausführungsform
können
ein Generierungswerkzeug für
Gatter wie die Gatterfabrik oder das Generierungswerkzeug für vorab
eingerichtete Gatter ein Java-basiertes Werkzeug sein, um für einen
gewissen Grad von Plattformunabhängigkeit
zu sorgen. Alternativ können
Generierungswerkzeuge für
Gatter in jeder beliebigen Sprache wie der geräteeigene Code für eine bestimmte
Einrichtung in der verteilten Rechnerumgebung bereitgestellt werden.
-
Man
beachte, daß die
verteilte Rechnerumgebung nicht ausschließt, daß eine Einrichtung einen Teil des
Codes oder den gesamten Code des Gatters herunterlädt. Zum
Beispiel kann ein Dienst. In einer Ausführungsform Gattercode bereitstellen,
der von einem Client heruntergeladen werden kann, der auf diesen
Dienst zugreifen möchte.
Jedoch kann heruntergeladener Code Risiken bezüglich der Größe, des
Datenschutzes und/oder der Funktionssicherheit in sich bergen.
-
Eine
detailliertere Darstellung möglicher
Gatterkomponenten für
eine Ausführungsform
wird in 12 gezeigt. Ein Gatter kann
seine Adresse (oder seinen Namen) 150, eine Zielgatteradresse 152,
ein gültiges XML-Schema
(oder eine interne Form davon) 154 und einen Transport-URI 153 beinhalten.
In anderen Ausführungsformen
kann ein Gatter auch einen Authentisierungsnachweis 156 enthalten.
Einige Gatter können auch
eine Überlassung
bzw. eine Pacht 158 und/oder eine Nachrichtenleitung 160 enthalten,
um die Reihenfolge der Nachrichten zu überprüfen. Der Name 150 eines
Gatters kann eine eindeutige ID sein, die (für die Lebensdauer des Gatters)
nur auf dieses verweist. Ein Gatter kann mittels seines Gatternamens 150 adressiert werden.
In einer Ausführungsform
können
Gatternamen als eine Kombination einer Zeichenkette aus einem XML-Schema
(z. B. aus einer Dienstannonce) und eine Zufallszahl wie einer 128-Bit
langen Zufallszahl erzeugt werden. Der Name 150 kann es
Clients und Diensten ermöglichen, über das
Netzwerk zu migrieren und immer noch zusammenzuarbeiten. Nach einer
bevorzugten Ausführungsform
ist die Gatteradresse unabhängig
von der physikalischen Transportadresse der Nachricht und/oder der
Socket-Schicht.
Somit kann ein Gattername eine virtuelle Adresse des Nachrichtenendpunktes
bereitstellen, die an eine Transportadresse der Nachricht gebunden
und von dieser wieder gelöst
werden kann. In einer Ausführungsform
kann der Name eines Gatters ein universeller eindeutiger Bezeichner
(Universal Unique Identifier, UUID) sein, der für die Lebensdauer des Gatters
nur auf dieses verweist.
-
Ein
Gattername kann solange bestehen, wie das Gatter besteht, so daß verschiedene
Anwendungen und Clients, die innerhalb derselben Einrichtung ausgeführt werden,
ein bestimmtes Gatter wiederholt lokalisieren und verwenden können. Zum
Beispiel kann ein Gatter für
einen ersten Clientprozeß,
der innerhalb der Einrichtung ausgeführt wird, erzeugt werden, um
auf einen Dienst zuzugreifen. Nachdem der erste Clientprozeß seine
Aktivität
mit dem Dienst abgeschlossen hat, kann er das Gatter freigeben.
Das Freigeben eines Gatters kann mit dem Lösen des Gatters von der Nachrichten-Transportadresse
des ersten Client (z. B. der IP- und/oder Port-Adresse) einhergehen.
Das Gatter kann in einem Gattercache oder -vorratsspeicher gespeichert
werden. Ein zweiter innerhalb derselben Einrichtung ausgeführter Clientprozeß, der denselben
Dienst auszuführen
bzw. ablaufen zu lassen wünscht,
kann das Gatter mittels seines Namens lokalisieren und es verwenden,
um auf den Dienst zuzugreifen. Um das Gatter zu verwenden, kann
der zweite Clientprozeß das
Gatter an seine Nachrichten-Transportadresse binden, so daß der Nachrichtenendpunkt
für den
zweiten Clientprozeß eine
Kombination aus dem Gatternamen und der Transportadresse des zweiten
Clientprozesses ist. In einem anderen Beispiel kann ein Client eine
dynamische IP-Adresse erhalten (z. B. ein mobiler Client). Wenn sich
die Transportadresse des Client ändert,
kann ein Gattername (oder Gatternamen) erneut an die neue Transportadresse
des Client gebunden werden, so daß der Client immer noch auf
einen Dienst (oder Dienste) zugreifen kann, auf den (oder die) er
zuvor zugegriffen hat, ohne den Dienst neu lokalisieren und das
Gatter neu erzeugen zu müssen.
-
Ein
Gattername kann auch für
eine Prozeßmigration
hilfreich sein. Ein Prozeß und
jegliche zugeordneten Gatter können
mit einem Prüf-
bzw. Wiederanlaufpunkt versehen oder an einem Knoten in der verteilten Rechnerumgebung
gesichert werden und zu einem anderen Knoten verschoben werden.
Der Prozeß kann
an dem neuen Knoten neu gestartet werden und die zugeordneten Gatter
können
an die Transportadresse für
den neuen Knoten gebunden werden, so daß der Prozeß immer noch Zugang zu externen
Diensten hat, zu denen er Zugang hatte, bevor er migriert wurde.
Ein Gatter kann den aktuellen Standort eines anderen Gatters, mit dem
es ein Paar bildet, ausfindig machen. Daher kann ein Dienst oder
ein Client migriert werden und immer noch zugänglich sein. Zum Beispiel können replizierte
und hinsichtlich der Last ausgeglichene Dienstimplementierungen
durch das Gatter von Clients des Dienstes abstrahiert werden.
-
Somit
sorgt ein Gattername 150 für einen flexiblen Mechanismus,
durch den ein Nachrichtenendpunkt in der verteilten Rechnerumgebung
adressiert werden kann. Ein Gattername kann verwendet werden, um
ein Gatter über
einen weiten Bereich von Netzwerken, von einem lokalen Netzwerk
bis zum Internet, zu lokalisieren und/oder zu adressieren. Gatternamen
können
unabhängig
vom Transportmedium für
Nachrichten sein, so daß ein
Nachrichtenendpunkt (Gatter) von Transportmedium zu Transportmedium
bewegt werden kann, indem die Bindung gelöst und er an andere, zugrundeliegende
Transportadressen gebunden wird (z. B. IP-/Port-Adreßpaare).
-
In
einer Ausführungsform
kann ein Gatter auch von einem Dienst separiert werden, so daß dasselbe Gatter
verwendet werden kann, um über
die Zeit Anforderungen an unterschiedliche Dienste zu senden. Dies kann
damit einhergehen, die Zielgatteradresse 152 des Gatters
zu lösen
und eine neue Zielgatteradresse an das Gatter zu binden.
-
Ein
Gatter kann als eine Schicht oberhalb der Transportschicht der Einrichtung
implementiert werden (z. B. Netzwerk-Sockets). Jedes Gatter kann
eine Transportreferenz 153 enthalten. Der Gattername 150 kann an
die Transportreferenz 153 gebunden werden, wie oben beschrieben.
Mehrere Gatter können
sich dasselbe Transportmedium für
Nachrichten teilen. Zum Beispiel können mehrere Gatter Transportreferenzen 153 auf denselben
TCP/IP-Socket haben. Indem dasselbe Transportmedium für Nachrichten
gemeinsam genutzt wird, kann die Größe und Komplexität jedes
Gatters reduziert werden. Eine Einrichtung in der verteilten Rechnerumgebung
kann eine große
Anzahl von Gattern haben, die Nachrichten senden und empfangen müssen. Die Komplexität der Nachrichtenbehandlung
für mehrere
Gatter kann durch gemeinsames Nutzen eines gemeinsamen Transportmediums
für Nachrichten
reduziert werden. Die Transportreferenz 153 kann ein Transport-URI (z. B. ein URL)
oder eine Socket-Referenz sein und kann einen Mechanismus zur Benennung
eines darunterliegenden Transportmediums und zum gemeinsamen Nutzen
mit anderen Gattern bereitstellen. Mehrere lokale Gatter können eine
Referenz 153 auf dasselbe Transportmedium beinhalten, jedoch
kann sich jedes lokale Gatter unabhängig von den anderen lokalen
Gattern verhalten, indem es Nachrichten zu oder von seinem entfernten
Gatter, mit dem es ein Paar bildet, sendet und empfängt.
-
Das
Schema 154 kann von einem Space von der Gatterfabrik in
das Gatter heruntergeladen werden. Das Schema kann in eine interne
Form kompiliert werden, die für
einen schnellen Zugriff während
des Überprüfungsvorgangs
einer Nachricht geeignet ist. In einer Ausführungsform kann das Schema
zwei Gruppen von Nachrichten angeben: Client-Dienstnachrichten und
Anbieter- bzw. Erbringer-Dienstnachrichten. Die Gruppe von Client-Dienstnachrichten
umfaßt
die Beschreibung aller Nachrichten, die der Client senden kann (die
der Erbringer unterstützt),
und die Gruppe von Erbringer-Dienstnachrichten umfaßt die Beschreibung
aller Nachrichten, die der Erbringer senden kann (die der Client
empfängt).
In einer Ausführungsform
kann entweder der Client oder der Erbringer eine bestimmte Anforderung
an den Space-Dienst senden, um eine Antwortnachricht zu erhalten
mit entweder: den gesamten Client-Dienstnachrichten oder den gesamten
Erbringer-Dienstnachrichten
oder den gesamten Client- und Erbringer-Dienstnachrichten oder einer
spezifischen Nachricht entweder von den Client-Dienstnachrichten
oder von den Erbringer-Dienstnachrichten. Darüber hinaus kann ein Client,
sobald ein Gatter eingerichtet wurde, hinsichtlich der Fähigkeiten
des Dienstes anfragen, ohne daß das Gatter
tatsächlich
eine Nachricht sendet, sondern stattdessen die Menge von Nachrichten
des Gatters inspiziert.
-
Wie
oben beschrieben kann ein Nachrichtengatter überprüfen, ob der Sender der Nachricht
einen Authentisierungsnachweis verwendet, und den Nachrichteninhalt
auf Typsicherheit und gemäß einem
XML-Schema überprüfen. Jedoch
kann es ebenso wünschenswert
sein zu überprüfen, daß Nachrichten
zwischen einem Client und einem Dienst in der richtigen Reihenfolge
gesendet werden. Es kann wünschenswert
sein, daß es möglich ist,
Anwendungen (Dienste) für
Clients vorzusehen, die ohne irgendeine vorab existierende, spezifische
Funktionalität
bezüglich
der Anwendung auf dem Client ablaufen sollen (z. B. kein GUI für die Anwendung auf
dem Client). Zum Beispiel kann auf dem Client ein Web-Browser als
das GUI für
einen Dienst verwendet werden, anstatt ein anwendungsspezifisches
GUI zu erforderlich zu machen. Von den möglichen Nachrichten in dem
XML-Schema, muß der
Client möglicherweise
wissen, welche Nachricht als nächstes
an den Dienst zu senden ist. Es kann wünschenswert sein, daß der Client
in der Lage ist festzustellen, welche Nachricht als nächstes zu
senden ist, ohne es erforderlich zu machen, daß der Client spezifische Kenntnisse
des Dienstes hat. In einer Ausführungsform
kann der Dienst kontinuierlich Antwortnachrichten senden, die die
nächste
Eingabe anzeigen, die er benötigt.
Der Dienst würde
dann von dem Client nur entsprechende Nachrichten mit der angegebenen
erforderlichen Eingabe akzeptieren. Eine andere Ad-Hoc-Maßnahme bzw.
-Vorgabe für
die Reihenfolge der Nachrichten kann ebenso eingesetzt werden.
-
In
einer anderen Ausführungsform
kann eine Nachrichtenleitung 160 in dem Gatter oder dem
Gatter zugeordnet eingesetzt werden, um die richtige Reihenfolge
von Nachrichten zu überprüfen, im
Gegensatz zum Überprüfen der
Syntax jeder Nachricht (was bereits in dem Gatter gemäß dem Schema
durchgeführt
sein kann). Die Nachrichtenleitung 160 kann einen allgemeineren
Ansatz für
das Bereitstellen von bzw. für
Anwendungen vorsehen. Die Nachrichtenleitung 160 kann in
der Annonce eines Dienstes angegeben werden. Die Angabe der Nachrichtenleitung
in einem Schema kann es ermöglichen,
daß Code
während
der Einrichtung eines Gatters auf dem Client erzeugt oder in den
Client heruntergeladen wird, der die benötigte Choreographie bereitstellt,
um zu entscheiden, welche Nachricht als nächstes an den Dienst zu senden
ist. Eine Nachrichtenleitung kann als eine Java-Anwendung, ein Java
Script, ein WML-Skript oder in einer Programmier- oder Skriptsprache
implementiert sein.
-
In
einer Ausführungsform
kann die Nachrichtenleitung als Eingabe ein XML-Dokument (z. B.
aus einer Dienstannonce) akzeptieren, das die gültige Reihenfolge oder Choreographie
für Nachrichten übergibt,
die zwischen einem Client und einem Dienst gesendet werden können. Dieses
XML-Dokument kann auch die Information über die Benutzerschnittstelle
und andere Regeln angeben. Die Leitung kann dieses XML-Dokument analysieren
und in eine interne Form überführen und
eine Reihenfolge der Nachrichten (und/oder andere Regeln) gemäß der enthaltenen
Information zur Reihenfolge erzwingen. Die Leitung kann verhindern,
daß Nachrichten
außer
der Reihe gesendet werden. Oder wenn eine Nachricht außer der
Reihe gesendet wird, kann eine Ausnahmebedingung innerhalb der sendenden
Einrichtung aufgeworfen bzw. verursacht werden. Wenn eine Nachricht
außer
der Reihe empfangen wird, kann die Leitung eine automatische Antwortnachricht
zurücksenden,
die den Fehler in der Reihenfolge meldet. Der Sender kann dann Nachrichten
in der richtigen Reihenfolge erneut senden. Man beachte, daß nach einigen
Ausführungsformen
eine Teil einer Leitung oder die gesamte Leitung mit mehreren Gattern
gemeinsam genutzt werden können.
Daher kann eine Leitung mit mehreren Gattern gebunden werden.
-
In
einer Ausführungsform
eine verteilten Rechnerumgebung können Eingangsrechner bzw. Datenstationen
für Dienste
(Dienstschnittstellen) in Clients eingebaut sein. In einer Ausführungsform
kann die Dienstschnittstelle eine vorab eingerichtete Benutzerschnittstelle
sein, die dem Client von dem Dienst bereitgestellt wird. In einer
Ausführungsform
kann die Dienstschnittstelle dem Client in der Dienstannonce bereitgestellt
bzw. übergeben
werden. Die Dienstschnittstelle kann auf dem Client mit dem Benutzer
des Dienstes interagieren, um eine Eingabe zur Ausführung des
Dienstes zu erhalten und kann danach die Ergebnisse der Ausführung des
Dienstes auf dem Client anzeigen. Ein "Benutzer" kann ein Mensch, ein eingebettetes
System, ein anderer Client oder Dienst, etc. sein. In einer Ausführungsform
ist eine Clienteinrichtung womöglich
nicht in der Lage, beliebige Dienste bereitzustellen, da die Clienteinrichtung
womöglich
nur in der Lage ist, Dienste auszuführen, für die sie eine Datenstation
eingebaut hat. In einer Ausführungsform
kann eine Dienstschnittstelle für
einen Dienst in einem Web-Browser auf dem Client implementiert sein.
-
In
einer Ausführungsform
können
eine Nachrichtenleitung und/oder eine Dienstschnittstelle extern
zu dem Gatter und somit von dem Gatter und Client abstrahiert sein.
Die abstrahierte Nachrichtenleitung für die Bereitstellung beliebiger
Dienste für
irgendeine Clienteinrichtung sorgen. In einer Ausführungsform
kann die Nachrichtenleitung in Code geschrieben sein, der im Wesentlichen
of jeder beliebigen Plattform ablaufen kann. In einer Ausführungsform
kann die Nachrichtenleitung in der Sprache Java geschrieben sein.
In einer Ausführungsform
braucht die Nachrichtenleitung nicht das beliebige Herunterladen
von Objekten, zum Beispiel Java-Objekten, erforderlich machen, die
an die Clienteinrichtung zurückgegeben
werden. Zum Beispiel können sehr
große
Objekte geliefert werden, und die Nachrichtenleitung kann wählen, diese
sehr großen
Objekte nicht herunterzuladen. In einer Ausführungsform kann die Nachrichtenleitung
XML-Nachrichten aus der Clienteinrichtung im Namen des Client an
Dienste senden. Die Nachrichtenleitung kann mit dem Benutzer des
Dienstes interagieren, um Eingabe entgegenzunehmen und Ergebnisse
anzuzeigen.
-
In
einer Ausführungsform
kann eine Dienstschnittstelle bereitgestellt werden, die mit dem
Client interagiert (z. B. über
eine Benutzerschnittstelle), um sämtliche Information zu erhalten,
um den Dienst auszuführen,
und danach entweder Ergebnisse der Ausführung des Dienstes oder Information
hinsichtlich des Ortes der Ergebnisse anzeigen, wie es passend ist.
Die Dienstschnittstelle kann entweder Teil der Nachrichtenleitung 160 sein
oder kann ein Zusatz zu der Nachrichtenleitung 160 sein
und kann mit ihr zusammenarbeiten. Die Dienstschnittstelle kann
eines von den folgenden sein:
- 1. In die Clienteinrichtung
eingebaut sein und somit auf dem Client ablaufen.
- 2. In die Clienteinrichtung aus dem Space-Server heruntergeladen
sein.
- 3. Auf dem Space-Server ablaufen.
- 4. Auf dem Diensterbringer ablaufen.
-
Für einen
Client muß der
Space-Server der verteilten Rechnerumgebung In einer Ausführungsform
#1 immer unterstützen,
anzeigen, wenn #2 unterstützt
wird (durch Annonce in einem Space), anzeigen, wenn zumindest #3
oder #4 unterstützt
werden. Man beachte, daß die
Unterstützung
von #4 davon abhängt,
ob der Diensterbringer #4 unterstützt oder nicht. In einer Ausführungsform
muß für einen
Diensterbringer der Space-Server der verteilten Rechnerumgebung
#4 immer unterstützen
und anzeigen, ob er #3 unterstützt.
-
Unabhängig davon,
wo die Dienstschnittstelle abläuft,
kann die Dienstschnittstelle mit dem Client interagieren, sobald
ein Dienst aktiviert ist, indem (abgesetzte bzw. entfernte) Eingabeanforderungen
auf der Anzeige des Client angezeigt und danach die (abgesetzten)
Ergebnisse des ablaufenden Dienstes angezeigt werden. Eine solche
Interaktion mit dem Client ist mittels XML-Nachrichten implementiert.
-
Die
Dienstschnittstelle und/oder die Nachrichtenleitung kann die Bedürfnisse
eines Clientbenutzers erfüllen,
der einen Dienst ausfindig gemacht hat, aber nicht ein typischerweise
langes, trockenes Computerhandbuch lesen möchte, um herauszufinden, wie
der Dienst zu benutzen ist. Da die Dienstschnittstelle und/oder
die Nachrichtenleitung mit dem Benutzer interagieren, um sämtliche
Eingaben anzufordern, die der Dienst benötigt, können sie sogar kurze Beschreibungen
der angeforderten bzw. benötigten
Eingaben liefern, wenn der Benutzer es anfordert. Sobald eine Dienstschnittstelle
die notwendige Information von dem Client erhalten hat, kann sie
XML-Nachrichten an den Diensterbringer senden, der den Dienst ablaufen
läßt bzw.
betreibt. Die Reihenfolge der Nachrichten kann von der Nachrichtenleitung 160 in
dem Gatter überprüft werden.
-
Nach
einer bevorzugten Ausführungsform
fließen
alle Nachrichten durch ein Gatter. Ein Gatter kann dafür eingerichtet
sein, einen Mechanismus zur Flußkontrolle
bereitzustellen. Zum Beispiel kann es notwendig sein, daß ein Dienst
eine große
Menge von ankommenden und abgehenden Nachrichten behandelt. Eine Flußkontrolle
kann es dem Dienst ermöglichen,
mit hohem Verkehrsaufkommen Schritt zu halten. Gatter können dafür eingerichtet
werden, Nachrichten auf Flußkontroll-Tags
hin zu überwachen.
Wenn ein Gatter eine Nachricht empfängt, kann es diese Nachricht
auf ein Flußkontroll-Tag
hin prüfen.
Die Flußkontroll-Tags
können XML-Tags
sein. Eine Nachricht kann zum Beispiel entweder ein OFF- bzw. AUS-Tag
oder ein ON- bzw. EIN-Tag enthalten. Wenn eine empfangene Nachricht
ein OFF-Tag enthält,
hört das
empfangende Gatter mit dem Senden von Nachrichten zu dem Zielgatter,
mit dem es ein Paar bildet, auf. Wenn das Gatter eine Nachricht
empfängt,
ein ON-Tag enthält,
kann es das Senden von Nachrichten wieder aufnehmen.
-
Somit
kann ein Gatter auf Seiten des Dienstes die Nutzung seiner Ressourcen überwachen
und Flußkontrolle
auslösen,
wenn die Nutzung seiner Ressourcen einen Grenz- bzw. Schwellwert überschreitet.
Zum Beispiel kann ein Dienst seine Last reduzieren, indem er Nachrichten
mit OFF-Tags an
ein oder mehrere Clientgatter sendet. Die Clientgatter, die Nachrichten
mit OFF-Tags empfangen, hören
auf, Nachrichten an den Dienst zu senden. In den Clients anstehende
Nachrichten können
gepuffert werden oder können
von internen Mechanismen zur Flußkontrolle behandelt werde.
Sobald der Dienst in der Lage ist, weitere Anforderungen zu behandeln,
kann er Nachrichten mit ON-Tags an einen oder mehrere Clients senden,
so daß die
Clients das Senden von Nachrichten wieder aufnehmen können. In
anderen Ausführungsformen
können
andere Flußkontroll-Tags
zusätzlich
zu oder anstelle von ON und OFF unterstützt werden. Andere Flußkontroll-Tags
können anzeigen,
den Nachrichtenstrom zu reduzieren, oder daß der Nachrichtenstrom gesteigert
werden kann.
-
Nachrichtengatter
können
dafür eingerichtet
sein, eine Ressourcenüberwachung
durchzuführen.
Da zum Beispiel alle Nachrichten durch ein Gatter fließen, kann
das Gatter dafür
eingerichtet werden, die Nutzung eines Dienstes (und möglicherweise
der ihm zugeordneten Ressourcen wie Speicher und Threads) durch
einen Client zu verwalten und/oder zu verfolgen. Ein Gatter kann
dafür eingerichtet
werden, die Aktivität
eines Softwareprogramms wie eines Client durch Überwachen, wieviel eine Ressource
wie ein Dienst benutzt wird oder welche und wie viele Dienstressourcen
genutzt werden, zu verfolgen. In einer Ausführungsform kann ein Gatter
ein Clientaktivitäts-Log
bzw. -Protokoll erzeugen oder die Erzeugung eines solchen erleichtern.
Jede Nachricht und ihr Ziel oder Sender können protokolliert werden.
-
Ein
Gatter kann auch dafür
eingerichtet werden, eine Überwachung
von Ressourcen zur Flußkontrolle von
der lokalen (sendenden) Seite eines Gatterpaars durchzuführen. Wenn
der Client eine zugeordnete Bandbreite der Nutzung eines Dienstes
(oder einer Ressource) überschreitet,
kann das Gatter zum Beispiel automatisch den Nachrichtenstrom zurückdrosseln.
Somit kann ein Nachrichtengatter auf Seiten des Client verschiedene
Arten von Flußkontrolle
durch Überwachen
der abgehenden Nachrichten auslösen.
Wenn der abgehende Nachrichtenstrom einen Schwellwert überschreitet,
kann das Gatter seinen Strom von ausgehenden Nachrichten reduzieren
oder abschalten. Der Schwellwert kann im XML-Schema oder der Annonce
eines Dienstes angegeben sein.
-
Nach
einigen Ausführungsformen
kann der Schwellwert nur für
Nachrichten, die bestimmte Dienstressourcen benutzen, oder für alle Nachrichten
angegeben werden.
-
Das
Gatter kann auch dafür
eingerichtet werden festzustellen, wann der Nachrichtenstrom gesteigert oder
wieder aufgenommen werden kann. In einer Ausführungsform unterhält das Gatter
einen Zähler
von abgehenden Nachrichten, die gesendet wurden, ohne daß die dazu
passende Antwort (Reaktion) empfangen wurde. Wenn passende Antworten
von dem Gatter auf Seiten des Client empfangen werden, kann der
Zähler von
ausstehenden Anforderungsnachrichten dekrementiert (herabgezählt) werden.
Wenn der Zähler
unter einen spezifizierten Schwellwert von ausstehenden Anforderungsnachrichten
fällt,
kann das Gatter das Senden neuer Anforderungsnachrichten steigern
oder wieder aufnehmen.
-
Ein
Gatter kann dafür
eingerichtet sein, eine Buchhaltung und/oder Abrechnung auf der
Basis von Nachrichten zu unterstützen.
Ein Abrechnungssystem kann auf der Grundlage der Anzahl und/oder
Art von Nachrichten, die von einem Nachrichtengatter gesendet und/oder
empfangen werden, implementiert werden. Da alle Nachrichten zu und
von einem Client durch ein Gatter laufen bzw. passieren können, kann
das Gatter dafür
eingerichtet werden, die Abrechnung bzw. das In-Rechnung-Stellen der Dienstnutzung eines
Client zu erleichtern, zum Beispiel pro Nachricht oder im Umlageverfahren
bzw. durch "Pay-as-you-go". Daher kann ein Abrechnungssystem
innerhalb der verteilten Rechnerumgebung implementiert werden, bei
dem einem Benutzer zum Beispiel jedes Mal etwas berechnet wird,
wenn eine Nachricht von der Software, die im Namen des Benutzers
abläuft,
gesendet und/oder empfangen wird.
-
In
einer Ausführungsform
kann ein Nachrichtengatter Gebühreninformation
von einem XML-Schema, z.
B. für
einen Dienst, erhalten. Die Gebühreninformation
kann eine Abrechnungsrichtlinie bzw. Abrechnungsverfahrensweise
und eine URI zur Rückverrechnung
angeben. Die URI zur Rückverrechnung
kann von einem Nachrichtengatter verwendet werden, um die Zeit oder
die Nutzung im Namen des Benutzers in Rechnung zu stellen. Ein Nachrichtengatter
kann eine Rückverrechnung
durch das Senden einer Belastungsnachricht an den in dem XML-Schema
angegebenen URI zur Rückverrechnung
ausführen.
So konfigurierte Gatter können als
Abrechnungsgatter bezeichnet werden. Die Abrechnungsrichtlinie kann
Belastungsbeträge
pro Nachricht oder pro kumulierter Nachrichtensummen, etc. angeben.
Die Abrechnungsrichtlinie kann angeben, mit wieviel und/oder wie
oft (z. B. nach jeweils einer Anzahl von x gesendeten und/oder empfangenen
Nachrichten) der Benutzer zu belasten ist. Die Richtlinie kann angeben,
daß nur
gewisse Arten von Nachrichten wie z.B. Nachrichten, die eine spezielle
Dienstressource anfordern, Belastungen auslösen. Die Abrechnungsrichtlinie
kann auch verschiedene Abrechnungsmodelle für verschiedene Clients oder
Klassen von Clients angeben. Zum Beispiel kann eine Abrechnungsrichtlinie
dafür eingerichtet
sein (z. B. in dem XML-Schema eines Dienstes), daß einige
Clients eine einmalige Gebühr
zahlen, wenn sie ein Gatter zum Zugriff auf den Dienst erzeugen. Die
Richtlinie kann Clients angeben, die im Umlageverfahren zahlen (z.
B. pro Nachricht), oder kann Clients angeben, denen überhaupt
nichts in Rechnung gestellt wird.
-
In
einigen Ausführungsformen
ist ein Client womöglich
zu klein bzw. schmal, um ein vollständiges Gatter zu unterstützen, oder
ein Client enthält
womöglich
keine Software, um direkt Teil der verteilten Rechnerumgebung zu
sein. Nach solchen Ausführungsformen
kann ein Server (wie der Space-Server, in dem der Dienst angekündigt wird,
oder ein anderer Server) ein vollständiges oder teilweises Proxy-Gatter
für den
Client sein. Der Server kann einen Dienstagenten (der ein Gatter
enthalten kann) für
jeden Dienst instantiieren, der von dem Client zu benutzen sein
soll. Der Dienstagent kann die Berechtigung, Nachrichten zu senden, überprüfen; Nachrichten
an den Erbringer senden, wobei er sie möglicherweise in eine Warteschlange
stellt, bis der Erbringer die nächste
entgegennehmen kann; Nachrichten an den Client senden, wobei er
sie möglicherweise
in eine Warteschlange stellt, bis der Client die nächste entgegennehmen
kann; und das Speichern von Ergebnissen in einem Ergebnis- oder
Aktivierungs-Space verwalten. Siehe auch den Abschnitt über Überbrückung.
-
Zum
Beispiel kann ein Client, wie in 13 dargestellt,
ein herkömmlicher
Browser 400 sein, der nicht unterstützt, daß Gatter direkt an dem oben
beschriebenen Nachrichtenschema bzw. -plan teilnehmen. Der Browser 400 kann
von einem Proxy-Servlet (Agenten) 402 unterstützt werden.
Der Benutzer des Browser kann eine Suchmaschine verwenden, um eine
Webseite zu finden, die für
einen Space, der Dienste innerhalb der verteilten Rechnerumgebung
ankündigt,
das Deckblatt bildet (dessen Inhalte anzeigt). Der Benutzer ist
in der Lage, auf die Space-Webseite zu zeigen und zu klicken, und
mit der Hilfe des Servlet auf den Dienst zuzugreifen. Die Webseiten
können
Skripte enthalten, zum Beispiel Java- oder WML-Skripte, die beim
Verbinden des Browser mit dem Proxy-Servlet verwendet werden können. Skripte
können
auch verwendet werden, um Nachrichten an das Proxy-Servlet zu senden.
Der Servlet-Agent kann Aktionen auf Webseiten in Nachrichten im
Namen des Browser-Client übersetzen.
Diese Aktionen können
das Navigieren in einem Space, das Starten von Diensten und die
Lieferung von Ergebnissen umfassen. URIs von Ergebnisseiten (die
auf Seiten verweisen, die XML enthalten) können direkt an den Browser
zur Anzeige für
den Benutzer zurückgegeben
werden (oder in HTML oder WAP übersetzt
werden, wenn nötig).
Somit braucht der Browser-basierte Client nicht zu wissen, wie Dienste
zu starten sind, noch, welche Nachrichten während der Sitzung zum Benutzen
des Dienstes zu senden sind. Zum Beispiel kann sich ein Benutzer
eines WAP-Browsers (z. B. auf einem Mobiltelefon) mit einer Space-Seite
verbinden, ihre Inhalte (Dienste) durchblättern und dann einen Dienst
starten, und zwar all das durch Zeigen und Klicken. Der Agent 402 stellt
die Clientschnittstelle zwischen dem herkömmlichen Client und der verteilten
Rechnerumgebung zur Verfügung.
-
Die
verteilte Rechnerumgebung kann einige unterschiedliche Arten von
Nachrichtengattern zur Kommunikation zwischen Clients und Diensten
beinhalten, die verschiedene Merkmale bzw. Funktionen unterstützen. Zum
Beispiel können,
wie oben diskutiert, einige Gatter Flußkontrolle oder Abrechnung
unterstützen.
Eine andere Art von Nachrichtengatter kann eine Form eines entfernten
Methodenaufrufs unterstützen.
Diese Art von Gatter kann als ein Methodengatter bezeichnet werden.
-
Ein
Gatter ist ein sicherer Nachrichtenendpunkt, der typsichere Nachrichten
sendet und empfängt,
z. B. XML-Nachrichten. Das Gatter im Stil eines Fernverfahrensaufrufs
(Remote Method Invocation. RMI) kann als ein Verfahrensgatter bzw.
Methodengatter bezeichnet werden. Das direkte, datenzentrierte Gatter
kann als ein Nachrichtengatter bezeichnet werden. Ein Methodengatter
kann als eine "Schicht" über einem Nachrichtengatter
implementiert werden. Die genaue Implementierung kann in der Bindung
an die Plattform definiert werden.
-
14 stellt die Verwendung eines Methodengatters
dar, um eine Schnittstelle zum entfernten Methodenaufruf zu einem
Dienst bereitzustellen. Methodengatter stellen eine Methodenschnittstelle
zwischen Clients und Diensten bereit. Ein Methodengatter kann bidirektional
sein, wodurch entfernte Methodenaufrufe von einem Client zu einem
Dienst und von einem Dienst zu einem Client ermöglicht werden. Ein Methodengatter 172 kann
aus der Information eines XML-Schemas 170 erzeugt werden
(z. B. aus einer Dienstannonce in einem Space). Die Information
eines XML-Schemas 170 umfaßt XML,
das eine Methodenschnittstelle oder Methodenschnittstellen definiert.
Aus dieser Information kann Code als Teil des Gatters als Schnittstelle
zu einer oder mehreren Methoden erzeugt werden. Jeder Methodenaufruf
(z. B. aus einer Clientanwendung 176) in dem erzeugten
Code kann dazu führen,
daß eine
Nachricht an den Dienst zu senden ist, der die geordneten bzw. aufgestellten
Methodenparameter enthält.
Die Syntax und die aufzunehmenden Parameter der Nachrichten können in
dem XML-Schema spezifiziert werden. Daher stellt das Methodengatter 172 eine
XML-Nachrichtenschnittstelle bereit, um das Verfahren eines Dienstes
aus der Ferne aufzurufen. Das Methodengatter kann auf dem Client
erzeugt oder auf einem Server als Proxy wie dem Space-Server realisiert
werden, bei dem die Dienstmethode angekündigt wurde, oder einem speziellen
Gateway-Server.
-
Ein
Dienst kann ein zugehöriges
Methodengatter haben, das einen Satz bzw. eine Menge von Objektmethoden
implementiert oder mit diesem verknüpft ist, welche dem Satz von
Methodennachrichten entsprechen, die in dem XML-Schema des Dienstes
definiert ist. Es kann eine eins-zu-eins Entsprechung zwischen den Objektmethoden,
die von dem Methodengatter des Dienstes implementiert werden oder
damit gebunden sind, und den Methodennachrichten geben, die von
dem XML-Schema des Dienstes definiert werden. Sobald die entsprechende
Methode eines Dienstes eine Nachricht von einem Client empfängt, um
eine der Methoden des Dienstes aufzurufen, kann das Methodengatter
des Dienstes die Parameter des Nachrichtenaufrufs entpacken und
dann das Verfahren aufrufen, das von der empfangenen Nachricht angegeben
wird, und die entpackten Parameter übergeben.
-
Das
Methodengatter kann eine synchrone Anforderungs-Antwort-Nachrichtenschnittstelle
sein, in der Clients aus der Ferne Methoden aufrufen, wodurch sie
Dienste veranlassen, Ergebnisse zurückzuliefern. Der darunterliegende
Mechanismus zur Nachrichtenübergabe
kann vollständig
vor dem Client verborgen sein. Diese Form des entfernten Methodenaufrufs
kann mit Ergebnissen von Methoden wie folgt umgehen. Anstatt Ergebnisobjekte
(und zugehörige
Klassen) in den Client herunterzuladen, werden In einer Ausführungsform
nur eine Ergebnisreferenz oder -referenzen (Er gebnishinweise) in
XML-Nachrichten zurückgegeben.
Eine Objektreferenz 178 (Hinweis oder Bezug auf ein Objekt)
kann ein generierter Code-Proxy sein (z. B. ein Ergebnisgatter),
der das wirkliche Objektergebnis 180 repräsentiert
(zum Beispiel immer noch draußen
im Netz gespeichert). In anderen Ausführungsformen kann der Client
wählen,
das tatsächliche
Ergebnisobjekt zu empfangen. Darüber
hinaus kann der Client, sobald er eine Objektreferenz empfangen
hat, diese Referenz verwenden, um das tatsächliche Ergebnisobjekt zu empfangen
oder zu manipulieren. In einer Ausführungsform beinhaltet die Ergebnisreferenz
einen oder mehrere URIs auf das wirkliche Ergebnis.
-
Das
wirkliche Ergebnisobjekt oder -objekte können in einem Space für Dienstergebnisse
gespeichert werden (der dynamisch zum Beispiel von einem Servlet
erzeugt werden kann). Dieser temporäre Ergebnis-Space kann als
ein Cache von Anfrageergebnissen bzw. Query Results dienen. Der
Ergebniscache (Space) kann von einer Serversoftware (Garbage Collector – Speicherbereiniger)
patrouilliert werden, die alte Ergebnisbereiche bereinigt. Ergebnisse,
die vom jeweiligen Methodenaufruf geliefert werden, können in
dem Ergebnis-Space angekündigt
werden. Ein Ergebnis selbst kann eine Methode sein oder kann eine
solche enthalten, die dann von einem Client entfernt instantiiert
werden kann, wodurch er sein eigenes Methodengatter erzeugt. Daher
kann die verteilte Rechnerumgebung einen rekursiven, entfernten
Methodenaufruf unterstützen.
-
Wie
oben erwähnt
kann in dem Fall, daß ein
Client ein Methodengatter verwendet, um eine Dienstmethode entfernt
aufzurufen, anstatt der tatsächlichen
Ergebnisse eine Referenz auf die Methodenergebnisse von dem Methodengatter
des Dienstes geliefert werden. Aus dieser Referenz kann ein Ergebnisgatter
erzeugt werden, um auf das tatsächliche
Ergebnis zuzugreifen. Daher kann der Client oder das Methodengatter
des Client ein Ergebnis-URI und vielleicht ein XML-Schema und/oder
einen Authentisierungsnachweis des Ergebnisses empfangen, um ein
Gatter zum Zugriff auf die Ergebnisse der entfernten Methode zu
erzeugen.
-
In
einer Ausführungsform
kann ein Dienstgatter ein "Tochter-Gatter" für die Ergebnisse
erzeugen. Dieses Tochter-Ergebnisgatter kann sich denselben Authentisierungsnachweis
wie sein Mutter-Gatter teilen. Nach einigen Ausführungsformen können Ergebnisse
einen unterschiedlichen Satz von Zugriffsrechten haben und somit
sich nicht denselben Authentisierungsnachweis wie ihr Elternteil
teilen. Zum Beispiel kann ein Gehaltslistendienst jeweils einer
unterschiedlichen Menge von Benutzern das Initiieren bzw. das Lesen
der Ergebnisse des Gehaltslistendienstes (Gehaltsschecks) erlauben.
-
Ein
Dienstmethodengatter kann ein Tochter-Ergebnisgatter an das Clientgatter
als das Ergebnis der Methode zurückgeben.
Der Client kann dann das Ergebnisgatter verwenden, um auf die tatsächlichen
Ergebnisse zuzugreifen. In einer Ausführungsform kann das Softwareprogramm
(der Client), das das Ergebnisgatter empfängt, nicht zwischen dem Ergebnisgatter
und dem Ergebnis selbst unterscheiden, wobei in diesem Fall das
Ergebnisgatter ein Objekt-Proxy für das tatsächliche Ergebnisobjekt sein
kann. Das Ergebnisgatter kann auch ein Methodengatter sein, das
einen entfernten Methodenaufruf zu den Ergebnisobjekten unterstützt. Auf diese
Weise kann eine Kette von Mutter- und Tochter-Methoden-/Ergebnisgattern
erzeugt werden.
-
In
einer Ausführungsform
können
die Methodengatter und entfernten Methoden in Java vorliegen. In dieser
Ausführungsform
werden Ergebnisse von Methoden gemäß dem Java-Typisierungssystem mit dem richtigen
Typ versehen. Wenn eine Java-Methode wie oben beschrieben entfernt
aufgerufen wird, kann das Ergebnisgatter in den Java-Typ umgewandelt
werden, der mit dem Ergebnistyp übereinstimmt.
In dieser Ausführungsform
können
Methodengatter in der verteilten Rechnerumgebung verwendet werden,
um es entfernten Java-Objekten zu ermöglichen, sich wie lokale Java-Objekte
zu verhalten. Der Methodenaufruf und die Ergebnisse können dem
Client-Java-Softwareprogramm
gleich erscheinen, unabhängig
davon, ob das reale Objekt lokal ist oder entfernt.
-
Siehe
den untenstehenden Abschnitt über
Spaces wegen weiterer Diskussion über die Verwendung von Spaces
für Ergebnisse.
-
Methodengatter
stellen Clients eine Methodenschnittstelle statt nur eine rohe Nachrichtenschnittstelle zur
Verfügung.
In einer Ausführungsform
kann ein Methodengatter über
einem Nachrichtengatter implementiert werden. Das Nachrichtengatter
sieht für
das Methodengatter Zugang zum Transportmedium, Überprüfung des Nachrichteninhaltes
und Zugriff auf den Nachrichteninhalt vor (Verfahren des Lesens
(Get) und Einstellens (Set) von Inhalt). In einer Ausführungsform
veranlaßt
jeder Methodenaufruf in dem erzeugte Code (d. h. in dem Methodengatter),
daß eine
einzelne synchrone Nachricht an den Dienst gesendet wird, der die
eingepackten Methodenparameter enthält. Das Methodengatter kann
dann veranlassen, daß der
aktuelle Thread (Strang) blockiert wird, indem er auf die Antwortnachricht
von dem Dienst wartet.
-
Diese
Art von Programmierung kann als synchrone Anfrage-Antwort-Programmierung
bezeichnet werden. Clients rufen Methoden auf, die Dienste dazu
veranlassen, Ergebnisse zurückzuliefern.
Die darunterliegenden Nachrichtenübermittlungsmechanismen sind
vollständig
vor dem Client verborgen. Diese Art von RMI kann mit Ergebnissen
von Methoden in einer einzigartigen und interessanten Weise umgehen.
In einer Ausführungsform
werden, anstatt Objekte (und zugehörige Klassen) in den Client
herunterzuladen, nur Ergebnisobjektreferenzen (Anzeigen bzw. Ankündigungen
oder Ankündigungs-URIs)
zurückgegeben.
In dieser Ausführungsform
kann bei gegebener Objektreferenz ein Ergebnisgatter erzeugt werden,
das Zugriff auf das reale Objekt gibt (das immer noch draußen im Netz
gespeichert ist).
-
In
einer Ausführungsform
werden einige Ergebnisse, die von einem Dienst erzeugt werden, in
einem Space angekündigt,
und schließlich
wird auf sie mittels eines Ergebnisgatters zugegriffen. Das Ergebnisgatter kann
denselben Sicherheitsnachweis wie das Eingabegatter, das zum Erzeugen
der Ergebnisse verwendet wurde, beinhalten oder nicht. Weil die
Eingabe für
einen Dienst asynchron von seiner Ausgabe (dem Ergebnis) ist, können mit
den Ergebnissen ein unterschiedlicher Satz von Zugriffsrechten verbunden
sein. Unter Verwendung eines B2B-Szenarios kann ein Gehaltslistendienst
einer jeweils anderen Menge von Benutzern erlauben, die Gehaltsliste
zu initiieren, bzw. die Ergebnisse des Gehaltslistendienstes (Gehaltsschecks)
zu lesen.
-
In
einer Ausführungsform
kann die Erzeugung eines Ergebnisgatters für Ergebnisse von Nachrichtengattern
manuell eingeleitet werden. Auf Inline-Ergebnisse (z. B. XML-Dokumente,
die als eine Antwort von einem Dienst gesendet werden) kann unter
Verwendung der Zugriffsmethoden (z. B. Get & Set) auf den Nachrichteninhalt zugegriffen
werden, die auf Nachrichtengattern verfügbar sind. Die Erzeugung von
Methodenergebnisgattern kann automatisch eingeleitet werden. Das
Methodengattermodell der Programmierung verbirgt die Erzeugung von
Ergebnisgattern, indem ein nahtloses Programmiermodell des entfernten
Methodenaufrufs erzeugt wird ohne den Overhead des Klassenladens
oder der Erfordernis für
den Anwendungsprogrammierer, Ergebnisgatter manuell zu erzeugen.
-
Die 45a-45e sind
Flußdiagramme,
die verschiedene Ausführungsformen
der Mechanismen zur Kommunikation zwischen Clients und Diensten
in einer verteilten Rechnerumgebung unter Verwendung von Methodengattern
darstellen. In 45a kann bei Schritt 2100 eine
Nachricht, die eine Darstellung eines Methodenaufrufs in einer Computerprogrammiersprache
(z. B. Java) beinhaltet, auf der Clienteinrichtung erzeugt werden.
In einer Ausführungsform
kann die Nachricht in einer Datenrepräsentationssprache vorliegen. In
einer Ausführungsform
ist die Datenrepräsentationssprache
XML. In einer Ausführungsform
kann ein Clientprozeß einen
Methodenaufruf vornehmen, und der Methodenaufruf kann in eine Repräsentation
des Methodenaufrufs, der in der Nachricht enthalten ist, verpackt
sein. Die Repräsentation
des Methodenaufrufs in der Nachricht kann einen Bezeichner (z. B.
einen Methodennamen), der den Methodenaufruf bezeichnet, und Null oder
mehr Parameterwerte für
den Methodenaufruf beinhalten, ist aber nicht darauf beschränkt. Die
Repräsentation
der Methode kann in der Datenrepräsentationssprache vorliegen.
Zum Beispiel können
die Elemente in der Repräsentation
ein oder mehrere Tags (z. B. XML-Tags) in der Nachricht sein.
-
In
einer Ausführungsform
kann ein Methodengatter auf den von dem Clientprozeß erzeugten
Methodenaufruf zugreifen und dann den Methodenaufruf in die Nachricht
verpacken. In einer Ausführungsform
kann eine Nachricht, die eine Repräsentation eines Methodenaufrufs
beinhaltet, auf einem Client erzeugt werden, wenn kein tatsächlicher
Methodenaufruf erfolgt ist. In dieser Ausführungsform kann ein Prozeß auf dem
Client Methoden in der Computerprogrammiersprache auf einem Dienst
aufrufen, ohne daß der
Client tatsächlich Methodenaufrufe
in der Computerprogrammiersprache erzeugt. Zum Beispiel kann ein
Client eine oder mehrere „verpackte" („canned") Nachrichten beinhalten,
die der Client an den Dienst senden kann, um eine oder mehrere Methoden
des Dienstes aufzurufen. Somit kann der Client Nachrichten verwenden,
um den Dienst zum Durchführen
von Methoden aufzufordern, ohne daß ein Prozeß auf dem Client tatsächlich einen
Methodenaufruf vornimmt.
-
In
Schritt 2102 kann der Client die Nachricht an den Dienst
senden. In einer Ausführungsform
kann das Client-Methodengatter die Nachricht an den Dienst senden.
In einer Ausführungsform
kann das Client-Methodengatter die Nachricht direkt an den Dienst
senden. In einer anderen Ausführungsform
kann das Client-Methodengatter die Nachricht an ein Client-Nachrichtengatter übergeben,
das dann die Nachricht an den Dienst sendet.
-
In
Schritt 2104 kann, nachdem der Dienst die Nachricht empfangen
hat, eine Funktion in Übereinstimmung
mit der Repräsentation
des Methodenaufrufs in der empfangenen Nachricht auf dem Dienst
durchgeführt
werden. In einer Ausführungsform
kann der Dienst den Methodenaufruf aus der empfangenen Nachricht auspacken,
die von der empfangenen Nachricht angegebene Methode aufrufen und
die ausgepackten Parameterwerte an die aufgerufene Methode übergeben.
In einer Ausführungsform
kann das Auspacken und Aufrufen von einem Methodengatter auf dem
Dienst durchgeführt
werden. In einer Ausführungsform
kann der Dienst, anstatt die Methode aufzurufen, als Reaktion auf
die Nachricht eine Funktion (z. B. eine andere Methode oder eine
andere Aktion) durchführen.
Zum Beispiel kann der Dienst eine Funktion ausführen, die die gewünschten
Ergebnisse des Methodenaufrufs erzeugt, ohne eine Methode auf dem
Dienst aufzurufen. In einem anderen Beispiel kann der Dienst Ergebnisdaten
für den
Methodenaufruf zuvor erzeugt haben und kann die Ergebnisdaten als
Reaktion auf die Nachricht an den Client liefern, ohne die Methode
aufzurufen.
-
In
Schritt 2106 kann die Funktion auf dem Dienst als Reaktion
auf die Nachricht Ergebnisdaten erzeugen. In Schritt 2108 können die
Ergebnisdaten an den Client geliefert werden. In einer Ausführungsform
können
die Ergebnisdaten direkt an den Client zurückgegeben werden (z. B. in
einer Nachricht). In einer anderen Ausführungsform können die
Ergebnisdaten in der verteilten Rechnerumgebung gespeichert werden
(z. B. in der Diensteinrichtung oder in einem zu der Diensteinrichtung
externen Space-Dienst), und eine Ankündigung zum Zugriff auf die
gespeicherten Ergebnisdaten kann an den Client geliefert werden.
Der Client kann dann die Ankündigung
verwenden, um ein Ergebnisgatter zum Zugriff auf die Ergebnisdaten
einzurichten. In einer anderen Ausführungsform kann der Dienst
ein Ergebnisgatter zum Zugriff auf die Ergebnisdaten an den Client zurückgeben.
-
In
einer Ausführungsform
kann der Client einen Methodenaufruf in eine oder mehrere Nachrichten
umformen, die an den Dienst gesendet werden können, wobei die Nachrichten
keine Information beinhalten, die in einen Methodenaufruf ausgepackt
werden können,
sondern stattdessen Informationen enthalten, die von dem Dienst
dafür verwendet
werden können,
eine Funktion im Namen des Client durchzuführen. In dieser Ausführungsform
weiß der
Dienst möglicherweise
nicht, daß die
Nachrichten ursprünglich
aus einem Methodenaufruf erzeugt wurden. In einer Ausführungsform
kann ein Methodengatter des Client einen auf dem Client erzeugten
Methodenaufruf in eine oder mehrere Nachrichten umformen, die den
Dienst auffordern, eine oder mehrere Funktionen für den Client
durchzuführen,
jedoch keinen verpackten Methodenaufruf enthalten, den der Dienst
in einen Methodenaufruf auspacken kann. Diese Nachrichten können dennoch
als eine „Repräsentation" des Methodenaufrufs
betrachtet werden, liegen jedoch möglicherweise nicht in einer
Form vor, die der Dienst als einen verpackten Methodenaufruf erkennt,
der ausgepackt werden kann, um den Methodenaufruf wieder zu erzeugen.
-
In
einer Ausführungsform
kann der Dienst eine oder mehrere Nachrichten umformen, die den
Dienst auffordern, eine oder mehrere Funktionen in einem Methodenaufruf
auszuführen.
In dieser Ausführungsform wurde
möglicherweise
auf dem Client kein Methodenaufruf vorgenommen, um die Nachrichten
zu erzeugen (der Client hat die eine oder mehreren Nachrichten möglicherweise
nicht als Reaktion auf einen Methodenaufruf erzeugt). Daher weiß der Client
möglicherweise
nicht, daß der
Dienst eine Methode aufruft, um die angeforderte(n) Funktion(en)
auszuführen.
In einer Ausführungsform
kann ein Methodengatter des Dienstes die Nachricht(en) von dem Client
empfangen und einen Methodenaufruf aus den Informationen in der
bzw. den Nachricht(en) konstruieren.
-
In 45b kann ein Clientprozeß, der innerhalb einer Clienteinrichtung
ausgeführt
wird, in Schritt 2110 einen Methodenaufruf vornehmen (d.
h. die Methode aufrufen). In einer Ausführungsform kann der Methodenaufruf
ein Aufruf einer Java-Methode sein. In einer Ausführungsform
ist die aufgerufene Methode möglicherweise
nicht lokal auf der Clienteinrichtung implementiert, sondern ist
auf einer Diensteinrichtung außerhalb
der Clienteinrichtung implementiert. Bei Schritt 2112 kann
ein Methodengatter des Client auf der Clienteinrichtung den Methodenaufruf
empfangen. Das Methodengatter des Client kann daraufhin den Methodenaufruf
in eine Nachricht in einer Datenrepräsentationssprache verpacken.
In einer Ausführungsform
ist die Datenrepräsentationssprache
XML. Die Nachricht kann einen Bezeichner bzw. eine Kennung der Methode
und einen oder mehrere Parameterwerte der Methode beinhalten. Die
Kennung kann ein Name, eine Nummer oder ein anderer Wert sein, der
verwendet wird, um die Methode dem Empfänger der Nachricht zu bezeichnen.
Ein Methodenaufruf kann einen oder mehrere Parameter beinhalten,
und beim Aufruf liefert der Aufrufer Werte für diese Parameter. In einer
Ausführungsform
können
sich mehr als ein Methodenaufruf dieselbe Kennung teilen und können durch
die Parameter der Methode unterschieden werden.
-
In
Schritt 2114 kann das Methothengatter des Client die Nachricht
an die Diensteinrichtung senden. In einer Ausführungsform kann das Methodengatter
des Client die Nachricht direkt an das Methodengatter des Dienstes
senden. In einer anderen Ausführungsform,
die in 45c dargestellt ist, kann das
Methodengatter des Client die Nachricht in Schritt 2124 an
ein Nachrichtengatter des Client liefern. Das Nachrichtengatter
des Client kann daraufhin die Nachricht in Schritt 2126 an
das Nachrichtengatter des Dienstes senden. Das Nachrichtengatter
des Dienstes kann daraufhin die Nachricht in Schritt 2128 an
das Methodengatter des Dienstes liefern. Die in 45c dargestellte Ausführungsform befreit die Methodengatter
von der Verantwortung, das Senden und Empfangen von Nachrichten
zu behandeln, und vereinfacht das Programmiermodell der verteilten Rechnerumgebung
durch das Aufteilen der RMI-Funktionalität und der Funktionalität der Nachrichtenbehandlung
in einzelne Abteilungen.
-
Gemäß einer
Ausführungsform
kann der Client der Nachricht einen Nachweis hinzufügen, um
die Nachricht (und den Client) auf dem Dienst zu verifizieren. Gemäß einer
Ausführungsform
kann der Nachweis von dem Client aus einem Authentifizierungsdienst
in der verteilten Rechnerumgebung beschafft worden sein. In einer
Ausführungsform
kann der Dienst Information an den Client übergeben haben, die den zu
verwendenden Authentifizierungsdienst angibt (z. B. in einer Dienst ankündigung).
In einer Ausführungsform
kann der Dienst denselben Authentifizierungsdienst verwenden, um
den Client (z. B. wenn eine erste Nachricht von dem Client empfangenen
wird) zu authentifizieren. Der Dienst kann daraufhin jede Nachricht
von dem Client prüfen, um
zu verifizieren, daß die
Nachricht den richtigen Nachweis für den Client beinhaltet. In
einer Ausführungsform
kann das Methodengatter des Dienstes die Verifikation durchführen. In
einer anderen Ausführungsform kann
das Nachrichtengatter des Dienstes die Verifikation durchführen und
dann die verifizierte Nachricht an das Methodengatter des Dienstes übergeben.
Siehe den Abschnitt über
Authentifizierung und Sicherheit für weitere Informationen über Nachweise
und Verifikation.
-
Gemäß 45b, kann das Methodengatter des Dienstes in Schritt 2116 den
Methodenaufruf aus der empfangenen Nachricht auspacken, die durch
die empfangene Nachricht angegebene Methode aufrufen und die ausgepackten
Parameterwerte der aufgerufenen Methode übergeben. Das Methodengatter
des Dienstes kann die in der Nachricht enthaltene Kennung verwenden,
um das Muster bzw. Schablonen für
den Methodenaufruf zu lokalisieren. Das Methodengatter des Dienstes
kann einen Satz von Methoden implementieren oder mit diesem verknüpft (verlinkt)
sein, der dem Satz von Methodennachrichten entspricht, die in dem
XML-Schema des Dienstes definiert sind. Es kann eine Eins-zu-Eins-Entsprechung
zwischen den vom Methodengatter des Dienstes implementierten oder
damit verknüpften
Objektmethoden und den durch das XML-Schema des Dienstes definierten
Methodennachrichten geben. In einer Ausführungsform kann ein Methodengatter
auf einem Client gemäß einem
Nachrichtenschema erzeugt werden, das dem Client durch den Dienst
geliefert wird, z. B. in einer Dienstankündigung. In einer Ausführungsform
kann eine Gatterfabrik verwendet werden, um das Methodengatter auf
dem Client zu erzeugen.
-
In
Schritt 2118 kann die aufgerufene Methode auf dem Dienst
implementiert oder durchgeführt
werden. In Schritt 2120 kann die aufgerufene Methode eine
Ergebnisausgabe von dem Aufruf gemäß den in dem Methodenaufruf
empfangenen Parameterwerten erzeugen. In Schritt 2122 können die
Ergebnisse des Methodenaufrufs dem Client-Prozeß übergeben werden, der ursprünglich die
Methode aufrief. In einer Ausführungsform
kann der Dienst dem Client die Ergebnisse direkt in einer oder mehreren
Ergebnisnachrichten übergeben. In
einer anderen Ausführungsform
kann der Dienst die Ergebnisse in einem Space plazieren und kann
dem Client eine Ergebnisankündigung
zum Zugriff auf die Ergebnisse bereitstellen. Die 45d und 45e veranschaulichen
andere Ausführungsformen,
bei denen dem Client ein Ergebnisgatter zum Zugriff auf die Ergebnisse
bereitgestellt werden kann.
-
In 45d kann das Methodengatter des Dienstes in Schritt 2130 dem
Nachrichtengatter des Dienstes eine Ergebnisreferenz bereitstellen.
In einer Ausführungsform
kann die Ergebnisreferenz eine Ankündigung zu den Ergebnissen
sein. In einer anderen Ausführungsform
kann die Ergebnisreferenz eine Adresse sein, z. B. ein URI für die Ergebnisse.
In Schritt 2132 kann das Nachrichtengatter des Dienstes
die Ergebnisreferenz in einer Nachricht an das Nachrichtengatter
des Dienstes senden. In Schritt 2134 kann der Client nach Empfang
der Nachricht aus der Nachricht mit der Ergebnisreferenz ein Ergebnisgatter
erzeugen. Zum Beispiel kann eine Ergebnisankündigung in der Nachricht geliefert
werden, und der Client kann das Ergebnisgatter gemäß der Ergebnisankündigung
in einer ähnlichen
Weise wie beim Erzeugen von Nachrichtengattern aus Ankündigungen
erzeugen, wie an anderer Stelle dieses Textes beschrieben. In Schritt 2136 kann
der Client das Ergebnisgatter verwenden, um auf die Ergebnisse zuzugreifen.
Zum Beispiel können
sich die Ergebnisse auf der Diensteinrichtung befinden und der Dienst
kann ein Ergebnisgatter des Dienstes erzeugt haben. Das Ergebnisgatter
des Clients kann erzeugt werden, um mit dem Ergebnisgatter des Dienstes
zu kommunizieren, z. B. kann die URI des Ergebnisgatters des Dienstes
in der Ergebnisankündigung
enthalten sein. Alternativ kann der Dienst die Ergebnisse anderswo
in der verteilten Rechnerumgebung gespeichert haben und das Ergebnisgatter
des Client kann dafür
ausgelegt sein, mit einem für
die Ergebnisse eingerichteten Ergebnisgatter zu kommunizieren. Zum
Beispiel können
sich die Ergebnisse in einem Space befinden, und das Ergebnisgatter des
Dienstes kann mit einem Ergebnisgatter auf dem Space kommunizieren.
-
In
der 45e kann der Dienst ein Ergebnisgatter
bei Schritt 2140 erzeugen. Der Dienst kann daraufhin bei
Schritt 2142 das Ergebnisgatter (in einer Nachricht) an
den Client senden. Das empfangene Ergebnisgatter kann dann von dem
Client verwendet werden, um auf das Ergebnis zu zugreifen. Diese
Ausführungsform
befreit den Client von der Verantwortung, das Ergebnisgatter einzurichten.
-
Für den Clientprozeß, der ursprünglich die
Methode aufgerufen hat, ist der Vorgang des RMI wie hier beschrieben
transparent bzw. unsichtbar. Dem Clientprozeß erscheint es, als ob die
Methode lokal aufgerufen wird und die Ergebnisse lokal bereitgestellt
werden. Somit können
es Methodengatter in Kombination mit dem Mechanismus zur Nachrichtenübergabe „Thin"-Clients ermöglichen,
Prozesse auszuführen,
die ansonsten zu groß und/oder
zu komplex wären,
um auf den Clients ausgeführt
zu werden.
-
Eine
Beispielimplementierung eines Methodengatters auf einer Java-Plattform
folgt. Die tatsächliche Implementierung
des Methodengatters in Java für
irgendeine Java-Plattform ist in der Plattformbindung der verteilten
Rechnerumgebung definiert. Jedes Java-Methodengatter, das Zugriff
auf ein Ergebnis gewährt,
ist tatsächlich
eine Instanz einer Java-Klasse (ein Objekt), die die Ergebnisschnittstelle
implementiert. Wenn zum Beispiel das Ergebnis ein Objekt vom Typ
Tabelle wäre,
kann die Klasse des Ergebnis-Methodengatters wie folgt definiert
werden:
-
Das
TabIeMethodGate-Objekt wird in den Typ Table umgewandelt, bevor
es als das Ergebnis des Methodenaufrufs zurückgegeben wird. Der Vorgang
ist rekursiv. Das heißt,
wenn die get-NextCell-Methode
aufgerufen wird, werden eine CellMethodGate-Klasse und -Objektinstanz
erzeugt, um das getNextCell-Ergebnis zu repräsentieren:
public class
CellMethodGate implements Cell {}
-
Die
Auswahl, welcher Gattertyp (Nachricht oder Methode) bei einem bestimmten
Dienst zu verwenden ist, wird in Kombination durch die Plattformbindung
und jede Dienstannonce angesprochen bzw. behandelt. Einige Plattformen
können
Methodengatter möglicherweise
nicht unterstützen.
Wenn eine Plattform Methodengatter unterstützt, kann die Bindung ihre
genaue Implementierung definieren. Zweitens kann sich die Schnittstelle
einer Dienstannonce für
RMI-artige Programmierung eignen oder nicht. Diejenigen Dienstschnittstellen,
die ein RMI-artiges Programmierungsmodell unterstützen, werden
mit dem folgenden XML-Attribut markiert:
<MethodGateInterface=true>
-
Nachrichtengatter
können
auch eine Nachrichtenübergabe
gemäß Publizieren
und Abonnieren bzw. Vorbestellen für Ereignisse unterstützen. Nachrichtengatter
mit Ereignisunterstützung
können
als Ereignisgatter bezeichnet werden. Das XML-Schema eines Dienstes
kann eine Menge von einem oder mehreren Ereignissen angeben, die
von einem Dienst veröffentlicht
werden können.
Ein Ereignisgatter kann aus dem XML-Schema aufgebaut werden. Das
Ereignisgatter kann dafür
eingerichtet werden, einige oder alle aus der Menge von Ereignissen,
die von einem Dienst veröffentlicht
werden, zu erkennen, diese Ereignisse zu abonnieren und jedes Ereignis
zu verteilen, wenn das Ereignis von dem Dienst erzeugt wird.
-
Die
Menge von Ereignissen für
einen Dienst kann in dem XML-Nachrichtenschema des Dienstes beschrieben
werden. Für
jede Ereignisnachricht in dem XML-Schema kann das Ereignisgatter
sich als einen Verbraucher bzw. Abnehmer für dieses Ereignis anmelden.
In einer Ausführungsform
kann ein Ereignisgatter alle Ereignisse bestellen, die von dem XML-Schema
angegeben werden. Jede Ereignisnachricht kann unter Verwendung eines
XML-Tag benannt werden. Das Ereignisgatter kann sich durch das Senden
einer Bestellnachricht, die das XML-Tag enthält, für das Ereignis anmelden, um
es zu abonnieren.
-
Wenn
ein entsprechendes Ereignis bei dem Dienst eintritt, kann der Dienst
eine Ereignisnachricht an Abonnenten senden, die das Eintreten des
Ereignisses angibt. Die Ereignisnachricht kann ein XML-Ereignisdokument
enthalten und kann an jedes angemeldete Gatter gesendet werden.
Wenn ein angemeldetes Gatter die Ereignisnachricht empfängt, wird
das XML-Ereignisdokument
aus der Nachricht entfernt, und der Verteilvorgang beginnt. Ereignisverteilung
ist der Vorgang, das Ereignisdokument innerhalb der Client-Plattform
auszuhändigen.
Jeder Abnehmer eines Ereignisses innerhalb der Client-Plattform
kann sich bei dem Ereignisgatter für jeden Typ von Ereignis anmelden.
Auf Java-Plattformen ist das Typisierungssystem Java (aus dem XML-Ereignistyp umgewandelt).
-
Der
Ereignisabnehmer kann dem Ereignisgatter eine Callback-Methode zur
Ereignisbehandlung übergeben.
Das Ereignisgatter kann eine Liste dieser Anmeldungen bzw. Abonnements
speichern. Bei Ankunft der jeweiligen Ereignisnachricht bei dem
Gatter (von dem Dienst, der das Ereignis erzeugt), geht das Gatter
durch die Liste der Clientabnehmer und ruft jedes Handhabungsverfahren
auf, wobei es das XML-Ereignisdokument als einen Parameter übergibt.
-
In
einer Ausführungsform
ist das XML-Ereignisdokument der einzige an die Callback-Methode übergebene
Parameter für
die Handhabung.
-
In
einer Ausführungsform
meldet sich das Ereignisgatter automatisch im Namen der lokalen
Abnehmerclients für
Ereignisse an. Wenn Clients bei dem Gatter Interesse bekunden, meldet
das Gatter Interesse bei dem Eneigniserzeugerdienst an. Ein Client
kann auch das Interesse kündigen,
was dazu führt,
daß das Gatter
sich bei dem Dienst, der das Ereignis erzeugt, abmeldet bzw. deregistriert.
-
Ein
Ereignisgatter kann unter Verwendung des XML-Schemas eine Typübenprüfung des
Ereignisdokuments durchführen,
genau wie ein reguläres
Nachrichtengatter bei der oben beschriebenen, standardmäßigen Art
der Nachrichtenübergabe
mittels Anforderung und Antwort es tut. Ein Ereignisgatter kann
auch einen Authentisierungsnachweis in Nachrichten, die es sendet,
aufnehmen und die Authentisierungsnachweise von empfangenen Ereignisnachrichten überprüfen.
-
Man
beachte, daß jede
Kombination der oben beschriebenen Gatterfunktionalität in einem
einzelnen Gatter unterstützt
werden kann. Jeder Typ ist nur der Klarheit halber separat beschrieben
worden. Zum Beispiel kann ein Gatter ein Nachrichtengatter, ein
Methodengatter und eine Ereignisgatter sein und kann Flußkontnolle
und Ressouncenüberwachung
unterstützen.
-
Mechanismus zum Auffinden
von Diensten
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zum Auffinden bzw.
Ausfindig-Machen von Diensten beinhalten, der für Clients Methoden bereitstellt,
um Dienste zu finden und die Rechte zum Benutzen einiger oder aller
der Funktionen des Dienstes auszuhandeln. Man beachte, daß ein Space
ein Beispiel eines Dienstes ist. Der Mechanismus zum Auffinden von
Diensten kann sicher sein und kann ausgehende Anforderungen von
Clients verfolgen und mit ankommenden Antworten von Diensten in
Einklang bringen.
-
Ein
Mechanismus zum Auffinden von Diensten kann verschiedene Eigenschaften
bzw. Funktionen bereitstellen einschließlich, jedoch nicht beschränkt auf:
-
Ein
Mechanismus zum Auffinden von Diensten kann verschiedene Eigenschaften
bzw. Funktionen bereitstellen einschließlich, jedoch nicht beschränkt auf:
- • Auffinden
eines Dienstes unter Verwendung flexibler Suchkriterien.
- • Anfordern
eines Authentifizierungsmechanismus', zum Beispiel eines Authentifizierungsnachweises,
der an den Client das Recht zum Benutzen der Gesamtmenge oder einer
Teilmenge von der Gesamtmenge der Funktionen eines Dienstes übertragen
kann.
- • Anfordern
eines Nachweises, Dokumentes oder eines anderen Objektes, der oder
das dem Client die Schnittstelle des Dienstes überträgt bzw. mitteilt. In einer
Ausführungsform
kann die Schnittstelle des Dienstes Schnittstellen zu einer angeforderten
Menge der Funktionen des Dienstes beinhalten.
- • Das
Verfolgen von Auffindungsantworten zu den ursprünglichen Anforderungen. In
einer Ausführungsform kann
jede Clientanforderung eine Sammlung von Daten enthalten, die auch
in dazu passenden Antworten zurückgegeben
werden können,
wodurch es möglich
wird, daß die
Anforderungen und Antworten aufeinander bezogen bzw. miteinander
korreliert werden.
-
In
einer Ausführungsform
der verteilten Rechnerumgebung kann ein Mechanismus zum Auffinden
von Diensten ein flexibles Suchkriterium, das auf einer erweiterbaren
Grammatik beruht, vorsehen. In einer Ausführungsform können ein
Dienstname, ein Diensttyp und andere Elemente, falls es solche gibt,
nach denen gesucht wird, mit Elementen in einem XML-Dokument auf Übereinstimmung
verglichen werden. In einer Ausführungsform
ist das XML-Dokument die Dienstannonce für den Dienst. XML kann eine
flexible, erweiterbare Grammatik für das Suchen zur Verfügung stellen.
XML kann auch für
Typsicherheit bei übereinstimmenden Elementen
sorgen. In einer Ausführungsform
können
die Dienstnamen und Diensttypen mit den Typen der Elemente in der
XML-Dienstannonce
hinsichtlich ihrer Typen überprüft werden.
-
In
einer Ausführungsform
kann eine verteilte Rechnerumgebung einen Mechanismus beinhalten,
damit Clients Zugriffsrechte auf Dienste aushandeln können. In
einer Ausführungsform
kann der Mechanismus verwendet werden, um eine Teilmenge der vollständigen Funktionalität des Dienstes
auszuhandeln. Das Ergebnis der Aushandlung kann eine Autorisierung
wie ein Authentisierungsnachweis sein, die dem Client das Recht
zum Benutzen der angeforderten Teilmenge der Funktionalität des Dienstes überträgt.
-
In
einer Ausführungsform
kann es der Mechanismus zum Auffinden von Diensten einem Client
ermöglichen,
einen Sicherheitsfunktions- bzw. -eigenschaftsnachweis von einem
Dienst anzufordern. In einer Ausführungsform kann der Client
dem Dienst eine Menge von gewünschten
Leistungsmerkmalen in der Form einer geschützten (sicheren) Annonce übergeben.
Der Dienst kann dann mit einem Funktions- bzw. -Leistungsmerkmalsnachweis
antworten, der dem Client die Rechte zum Benutzen der angeforderten
Funktionen bzw. Leistungsmerkmale, die in der geschützten Annonce
beschrieben sind, überträgt.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus beinhalten,
damit ein Client Zugriffrechte auf Dienste aushandeln und dann einen
Sicherheitsnachweis oder ein Sicherheitsdokument erhalten kann,
der oder das verwendet werden kann, um die Zugangsschnittstelle
des Dienstes der Menge oder Teilmenge von Diensteigenschaften oder
-funktionen darzustellen, die von dem Client angefordert wurde.
-
In
einer Ausführungsform
kann ein Client, der einen Leistungsmerkmalsnachweis von einem Dienst empfängt, ein
angepaßtes
Dokument der Zugangsschnittstelle des Dienstes erzeugen, das als
eine "komplette Annonce" bezeichnet werden
kann. In einer Ausführungsform
kann die komplette Annonce ein XML-Dokument sein. Die erzeugte Annonce
kann Zugriff auf Diensteigenschaften bereitstellen, wie sie dem
Client durch den empfangenen Leistungsmerkmalsnachweis gewährt werden.
In einer Ausführungsform
kann von der Annonce eine Schnittstelle nur für die Diensteigenschaften bereitgestellt
werden, für
die der Client durch den Leistungsmerkmalsnachweis Zugriff ge währt bekommen
hat. In einer Ausführungsform
kann dem Client Zugriff nur auf die angeforderten Eigenschaften
eingeräumt
werden, und zu denen der Client Zugriffsprivilegien hat.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zur Verfügung stellen,
durch den ein Client Leistungsmerkmale bzw. Funktionen mit einem
Dienst aushandeln kann. In einer Ausführungsform kann der Client
seine Funktionen auf dem Dienst aushandeln. Der Dienst kann dann
Ergebnisse beruhend auf den mit dem Client ausgehandelten Parametern
anpassen. Zum Beispiel kann ein Client, der zu einer Ein-Bit-Anzeige
bei einer Auflösung
von 160×200
fähig ist,
diese Parameter mit dem Dienst aushandeln, um es so dem Dienst zu
ermöglichen,
die Ergebnisse für
den Client anzupassen.
-
Das
Folgende ist als ein Beispiel einer XML-Eigenschaftsnachricht eingefügt und ist
nicht dazu gedacht, in irgendeiner Weise einschränkend zu sein:
-
Die
verteilte Rechnerumgebung kann einen Mechanismus beinhalten, der
es Clients ermöglichen kann
auszuhandeln, wie ein Dienst Ergebnisse eines Dienstaufrufes zurückgeben
soll. In einer Ausführungsform
kann während
einer Anforderung eines Leistungsmerkmalsnachweises eine Einrichtung,
durch die eine von den Verfahren zur Rückgabe von Ergebnissen gewählt werden
kann, an den Dienst überbracht
werden. Der Dienst kann dann eine angepaßte Dienstannonce erzeugen,
die dem Client sowohl den Ergebnismechanismus, der zu verwenden
ist, als auch die Dienstschnittstelle mitteilt.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zum Verfolgen von
Suchanforderungen zum Auffinden von Diensten und von Antworten auf
die Anforderungen beinhalten. In einer Ausführungsform können Suchanforderungs-
und -antwortnachrichten ein Feld beinhalten, das verwendet werden
kann, um eine Zeichenkette oder ein XML-Dokument einzuschließen. In
einer Ausführungsform wird
die Zeichenkette oder das XML-Dokument, das in dem Feld einer Anforderungsnachricht
enthalten ist, auch in der Antwortnachricht zurückgegeben. In einer Ausführungsform
muß die
Zeichenkette oder das XML-Dokument in der Antwortnachricht zurückgegeben
werden. In einer Ausführungsform
kann die Zeichenkette oder das XML-Dokument zusätzliche Information enthalten,
die in die Zeichenkette oder das XML-Dokument eingefügt oder
an diese(s) angehängt
wird, wenn sie oder es in der Antwortnachricht zurückgegeben wird.
In einer Ausführungsform
kann dieser Mechanismus beim Debugging komplexer Systeme verwendet werden.
In einer Ausführungsform
kann dieser Mechanismus auch ein Verfahren für Clients bereitstellen, um Dienste
auszuwählen,
die zugreifen, indem die Zeichenkette oder das XML-Dokument in der
Weise verwendet wird, daß angepaßte bzw.
auf den speziellen Fall zugeschnittene Suchinformation zwischen
einem Client und einem Dienst übergeben
wird, die nur von dem Client und dem Dienst verstanden werden kann.
-
Schnittstellen passender
bzw. übereinstimmender
Komponenten (Dienste)
-
Die
verteilte Rechnerumgebung kann einen Mechanismus bereitstellen,
um die Spezifikationsschnittstelle einer Komponente (zum Beispiel
eines Dienstes) bzw. die Schnittstelle einer Komponentenspezifikation mit
einer angeforderten Schnittstelle bezüglich Übereinstimmung abzugleichen.
Zum Beispiel kann ein Client (der ein Dienst sein kann) einen Dienst
wünschen,
der einen Satz von Schnittstellenanforderungen erfüllt. Jede Komponente
kann eine Beschreibung der Schnittstelle haben, mit der sie konform
ist. Der Mechanismus zum Abgleich von Spezifikationsschnittstellen
kann es ermöglichen,
daß eine
Komponente lokalisiert wird, die am besten mit den Schnittstellenanforderungen
eines Anforderers übereinstimmt.
Der Mechanismus zum Abgleich von Spezifikationsschnittstellen kann
auch "unscharfe" bzw. "fuzzy" Übereinstimmung bzw. Abgleich
von Schnittstellenanforderungen ermöglichen. Mit anderen Worten
kann der Mechanismus einen Abgleich ermöglichen, ohne die genaue Spezifikation
aller Aspekte der Schnittstelle zu verlangen, wodurch ein (Fuzzy)-Mechanismus
einer nächstkommenden Übereinstimmung
zur Verfügung
steht. In einer Ausführungsform
kann der Mechanismus zum Abgleich von Spezifikationsschnittstellen
als ein mehrschichtiges Modell, das Unterklassen bildet, implementiert
werden, statt Spezifikation auf einer einzelnen Schnittstellenstufe
bzw. -niveau zu erfordern.
-
In
einer Ausführungsform
kann eine Komponente eine XML-Schema-Definitionssprache (XML Schema
Definition Language, XSDL) verwenden, um seine Schnittstelle zu
beschreiben. XSDL kann eine von Menschen interpretierbare Sprache
zum Beschreiben der Schnittstelle vorsehen, wodurch Aktivitäten, die
eine Intervention durch Menschen erfordert, wie das Debugging vereinfacht
werden. In einer Ausführungsform
kann die Schnittstellenbeschreibung als Teil einer Annonce (zum
Beispiel einer Dienstannonce) bereitgestellt werden, wie an anderer
Stelle in diesem Dokument beschrieben.
-
Unter
Verwendung des Mechanismus zum Abgleich von Spezifikationsschnittstellen
kann eine einfache bzw. grundsätzliche,
gewünschte
Schnittstelle mit einem Satz bzw. einer Menge von Beschreibungen
von Schnittstellenkomponenten bzw. von Schnittstellen von Komponenten
verglichen werden. Eine oder mehrere Komponenten, die mit der einfachen,
gewünschten
Schnittstelle übereinstimmen,
können
identifiziert werden. Die Schnittstellenbeschreibungen können Beschreibungen
von Unterklassen enthalten, die die von den Komponenten bereitgestellten
Schnittstellen spezieller beschreiben. Bei dem Suchvorgang kann
die Klassentyphierarchie überprüft werden,
um festzustellen, ob eine gegebene Klasse eine Unterklasse des gesuchten Typs
ist. In einer Ausführungsform
können
Unterklassen Eigenschaften von der Basisklasse erben, und somit braucht
die Unterklassen-spezifische Information in dieser Phase nicht überprüft zu werden.
Daher kann die Suche generisch durchgeführt werden. Die identifizierten
Komponenten können
auf der nächsten (Unterklassen-)Stufe
gesucht werden. Die Suche kann für
die Unterklasse spezifisch werden und kann durchgeführt werden,
indem die Unterklassen-Information, die in der Schnittstellenbeschreibung
enthalten ist, interpretiert wird. Die Suche kann sich durch eine
oder mehrere Unterklassen fortsetzen, bis eine oder mehrere Komponenten bestimmt
sind, die die nächstkommende Übereinstimmung
mit der gewünschten
Schnittstelle des Anforderers liefern.
-
In
einer Ausführungsform
kann ein Mechanismus zum Abgleich von Spezifikationsschnittstellen
die Fähigkeit
bzw. Möglichkeit
bereitstellen, zwischen zwei oder mehr Komponenten zu unterscheiden,
die ähnliche
Schnittstellen implementieren. In einer Ausführungsform kann der Mechanismus
zum Abgleich von Spezifikationsschnittstellen die Fähigkeit
bereitstellen, zwischen verschiedenen Revisionen derselben Komponente
zu unterscheiden.
-
In
einer Ausführungsform
kann eine Komponentenbeschreibung bereitgestellt werden, die eine
Spezifikation der Schnittstelle enthält, zu der die Komponente konform
ist. Die Komponentenbeschreibung kann auch Information über die
Komponente selbst enthalten. Die Schnittstellenbeschreibung und/oder
die Komponenteninformation kann verwendet werden, um zwischen verschiedenen
Implementierungen einer gegebenen Schnittstelle zu differenzieren.
Die Komponentenbeschreibungen können
einen kanonischen Bezeichner und eine Versionsinformation enthalten.
Die Versionsinformation kann es ermöglichen, daß Überarbeitungen von Komponenten
unterschieden werden können.
In einer Ausführungsform
kann die Komponentenbeschreibung als Teil einer Annonce (zum Beispiel
einer Dienstannonce), wie an anderer Stelle in diesem Dokument beschrieben,
zur Verfügung
gestellt werden.
-
In
einer Ausführungsform
können
Komponenten nach einem bestimmten kanonischen Bezeichner durchsucht
werden. Zwei oder mehr Komponenten können mit passenden kanonischen
Bezeichnern identifiziert werden. Eine oder mehrere Komponenten
können
aus den Komponenten mit passenden kanonischen Bezeichnern ausgewählt werden.
Der Auswahlvorgang kann eine Version der Schnittstellenspezifikation,
eine Spezifikation der Komponentenimplementierung, ein Version der
Spezifikation der Komponentenimplementierung, andere Information
oder eine Kombination der Information aus der Komponentenbeschreibung
verwenden, um eine Menge von einer oder mehreren Komponenten zu
erzeugen, die am besten mit den Anforderungen des Anforderers übereinstimmen.
-
Spaces
-
Wie
oben erwähnt,
stützt
sich die verteilte Rechnerumgebung auf Spaces, um einen Rendezvous-Mechanismus
bereitzustellen, der Dienste oder Inhalt an Clients vermittelt. 15 veranschaulicht die grundlegende Verwendung
eines Space 114. Dienstanbieter bzw. -erbringer können Dienste
in einem Space 114 ankündigen.
Clients 110 können
die Annonce in einem Space 114 finden und die Information
aus der Annonce verwenden, um auf einen Dienst unter Verwendung
des XML-Nachrichten-Mechanismus der verteilten Rechnerumgebung zuzugreifen.
Es kann viele Spaces geben, von denen jeder XML-Annoncen enthält, die
Dienste oder Inhalt beschreiben. Daher kann ein Space ein Behälter für XML-Annoncen
von Diensten und/oder XML-Daten sein, die rohe Daten oder Annoncen
für bzw.
Hinweise auf Daten wie Ergebnisse sein können.
-
Ein
Space ist selbst ein Dienst. Wie jeder Dienst hat ein Space eine
Annonce, die ein Client des Space zuerst erhalten muß, um in
der Lage zu sein, diesen Space-Dienst ablaufen zu lassen. Die eigene
Annonce eines Space kann ein XML-Schema, einen Berechtigungsnachweis
bzw. -nachweise und einen URI enthalten, die angeben, wie auf den
Space zuzugreifen ist. Ein Client kann aus der Annonce eines Space-Dienstes
ein Gatter einrichten, um auf den Space zuzugreifen. Der Client
eines Space kann selbst ein Dienstanbieter sein, der in diesem Space
eine Annonce machen möchte
oder eine bestehende Annonce zu modifizieren wünscht. Oder ein Client eines
Space kann eine Anwendung sein, die auf einen Dienst oder Inhalt,
der von dem Space aufgelistet wird, zugreifen möchte. Somit können Spaces
Katalysatoren bzw. Beschleuniger für die Interaktion zwischen
Clients und Diensten in der verteilten Rechnerumgebung sein.
-
Ein
Space kann eine Sammlung von Annoncen mit Namen sein. In einer Ausführungsform
ist die Namensgebung für
eine Annonce bzw. das Benennen einer Annonce der Vorgang, eine Namenszeichenkette
einer Annonce zuzuordnen. Die Zuordnung kann beim Speichern einer
Annonce in einem Space stattfinden. Das Entfernen einer Annonce
aus einem Space trennt den Namen von der Annonce. Ein Space kann
mit einer einzelnen Stammannonce eingerichtet werden, die den Space
selbst beschreibt. Zusätzliche
Annoncen können zu
einem Space hinzugefügt
werden. Der Name einer Annonce kann die Annonce innerhalb des Space
lokalisieren, einschließlich
der Angabe jeglicher notwendiger Information zur graphischen Darstellung
wie einer Hierarchie von Namen. Nach einer bevorzugten Ausführungsform
schreibt die verteilte Rechnerumgebung nicht die Struktur eines
Space vor. Das heißt,
Spaces können
zum Beispiel als eine flache, nicht in Beziehung stehende Menge
von Annoncen oder ein Graph von miteinander in Beziehung stehenden
Annoncen (z. B. eine kommerzielle Datenbank) sein. Da die verteilte
Rechnerumgebung nach einer bevorzugten Ausführungsform nicht vorschreibt,
wie ein Space tatsächlich
seinen Inhalt speichert, können
Spaces von kleinen bis zu großen Einrichtungen
bzw. Geräten
unterstützt
werden. Zum Beispiel kann ein einfacher Space darauf zugeschnitten sein,
auf kleine Einrichtungen wie PDAs zu passen. Höher entwickelte Spaces können auf
großen
Servern unter Einsatz großer,
kommerzieller Datenbanken implementiert werden.
-
Wie
oben erwähnt,
kann ein Space Annoncen für
Dienste in der verteilten Rechnerumgebung enthalten. Eine Annonce
kann einen Mechanismus zum Adressieren von und Zugriff auf Dienste
und/oder Inhalt innerhalb der verteilten Rechnerumgebung bereitstellen.
Eine Annonce kann einen URI für
einen Dienst angeben. In einigen Ausführungsformen kann es der URI
ermöglichen,
daß auf
den Dienst über
das Internet zugegriffen wird. Eine Annonce kann auch ein XML-Schema
für den
Dienst enthalten. Das XML-Schema kann einen Satz von Nachrichten
spezifizieren, den Clients des Dienstes an den Dienst senden können, um
die Funktionalität
des Dienstes aufzurufen. Das XML-Schema kann die Client-Dienst-Schnittstelle
definieren. Der URI und das XML, die in einer Annonce spezifiziert
sind, können
zusammen angeben, wie der Dienst zu adressieren und wie auf ihn
zuzugreifen ist. Sowohl der URI als auch das Schema können in
XML als eine Annonce in einem Space bereitgestellt werden. Damit
kann ein Mechanismus zum Adressieren von und zum Zugriff auf einen
Dienst in einer verteilten Rechnerumgebung als eine Annonce in einem
Space publiziert werden. Clients können einen Space ausfindig
machen und dann nach individuellen Annoncen von Diensten oder Inhalt
durchsuchen.
-
16 veranschaulicht eine Annoncenstruktur gemäß einer
Ausführungsform.
Eine Annonce 500 kann wie andere XML-Dokumente eine Reihe
von hierarchisch angeordneten Elementen 502 enthalten.
Jedes Element 502 kann seine Daten oder zusätzliche
Elmente enthalten. Ein Element kann auch Attribute 504 haben.
Attribute können
Namen-Wert-Zeichenkettenpaare sein. Attribute können Metadaten speichern, die
die Beschreibung der Daten innerhalb des Elementes erleichtern.
-
Nach
einigen Ausführungsformen
kann eine Annonce in verschiedenen unterschiedlichen Zuständen existieren.
Ein solcher Zustand ist ein Entwurfszustand. In einer Ausführungsform
können
Annoncen anfangs in einem Entwurfszustand aufgebaut werden, der
außerhalb
der Grenzen eines Space existiert. Der Erzeuger einer Annonce kann
sie auf vielerlei Wegen aufbauen, einschließlich der Verwendung eines
XML-Editors. Zugriff auf Elemente und Attribute in dem Entwurfszustand
kann auf der Stufe der Rohdaten und Metadaten geschehen unter Verwendung
jeglicher geeigneter Mittel. Typischerweise werden keine Ereignisse
für Änderungen
erzeugt, die an Annoncen im Entwurfszustand vorgenommen werden.
Daher kann der Erzeuger der Annonce beliebig sowohl Elemente hinzufügen, ändern oder
löschen
als auch den gewünschten
Attributsatz zustande bringen und dann die Annonce veröffentlichen,
damit sie für
den Rest der verteilten Rechnerumgebung sichtbar wird.
-
In
einer Ausführungsform
ist ein anderer möglicher
Zustand für
Annoncen ein Zustand "veröffentlicht". Annoncen können in
den Zustand "veröffentlicht" übergehen, wenn sie in einen
Space eingefügt
werden. Sobald die Annonce in einem Space ist, können interessierte Clients
und Dienste sie lokalisieren, z. B. mittels ihres Namens und/oder
ihrer Elemente als Suchkriterien. Zum Beispiel können Suchkriterien als ein
XML-Vorlagendokument angegeben werden, das (z. B. vom Space-Dienst) mit den Annoncen
in dem Space verglichen werden kann. Veröffentlichte Annoncen können Online-Dienste
repräsentieren,
die zur Benutzung durch Clients bereitstehen. Die Nachrichtenadresse
(URI) des Dienstes kann als ein Element in der Annonce gespeichert
sein. Annoncen, die aus dem Space entfernt werden, können zurück in den
Entwurfszustand übergehen, in
dem sie verworfen oder gehalten werden können. Das Entfernen kann ein
Ereignis erzeugen, so daß interessierte
Empfänger über die Änderung
in Kenntnis gesetzt werden können.
Nachrichtengatter werden typischerweise aus veröffentlichten Annoncen erzeugt.
-
In
einer Ausführungsform
ist noch ein weiterer möglicher
Zustand für
Annoncen ein Zustand "dauerhaft archiviert". Ein Archivierungsvorgang
kann eine aktuell veröffentlichte
Annonce in einen Bytestrom umwandeln, der für eine spätere Rekonstruktion dauerhaft
gespeichert werden kann. Archivierte Annoncen können (z. B. in ihrer rohen
XML-Form) aus dem Space an einen Archivie rungsdienst gesendet werden.
Der URI für den
Archivierungsdienst einer Annonce kann als eine Element in der Annonce
gespeichert werden. XML kann ein Format zum Speichern und Wiederfinden
von Annoncen und zur Darstellung des Zustandes von Annoncenelementen
bereitstellen, das ausreicht, um das Annoncenobjekt oder die Annoncenobjekte
wiederherzustellen. Annoncen können
auch in anderen Formaten gespeichert werden, abhängig von der Implementierung des
Archivierungsdienstes. Der Vorgang, eine veröffentlichte Annonce dauerhaft
zu machen, kann die Annonce für
den Zustand "dauerhaft
archiviert" vorbereiten.
Dauerhafte Annoncen können
für eine
zukünftige
Verwendung in einer dauerhaften Speicherstelle wie einer Datei oder
einer Datenbank gespeichert werden (z. B. von einem Archivierungsdienst).
Ein Space kann es durch den Archivierungsvorgang möglich machen,
daß Annoncen
gespeichert werden, jedoch spielt der Space nicht notwendigerweise
eine Rolle dabei, wie dauerhafte Annonceneinträge tatsächlich gespeichert werden.
Wie dauerhafte Annoncen gespeichert werden, kann von dem Archivierungsdienst
der Annonce bestimmt werden. Typischerweise werden keine Ereignisse
im Namen von archivierten Annoncen erzeugt. Ebenso kann es sein,
daß Änderungen
an Annoncen in dem Zustand "dauerhaft
archiviert" nicht
erlaubt sind.
-
Annoncen
(Ankündigungen)
können
archiviert und entfernt oder nur archiviert werden. Wenn eine Annonce
archiviert wird, ohne aus dem Space entfernt zu werden, speichert
der Space eine Schattenversion der Annonce. Zugriff auf einen archivierten
Dienst kann dazu führen,
daß die
Annonce aus ihrem dauerhaften Hintergrundspeicher auf Anforderung
wieder geladen wird. Diese Eigenschaft kann es ermöglichen,
daß Annoncen
auf Anforderung gefüllt
werden, zum Beispiel aus LDAP-Einträgen (Lightweight Directory
Access Protocol).
-
17 veranschaulicht ein Beispiel von Zustandsübergängen einer
Annonce, die eine Annonce während
ihrer Lebensdauer erfahren kann. Zuerst kann eine Annonce aufgebaut
werden, wie bei 1 angegeben. Während
des Aufbaus befindet sich die Annonce in dem Entwurfszustand. Danach
kann die Annonce in einen Space eingefügt werden, wie bei 2 angegeben.
Die Annonce kann als ein veröffentlichter
Vorgänger
eingefügt werden.
Die Annonce ist im Zustand "veröffentlicht", nachdem sie in
einen Space eingefügt
wurde. Ein Ereignis (z. B. AdvInsertEvent) kann erzeugt werden,
wenn die Annonce in den Space eingefügt wird. Ereignisse werden
unten genauer beschrieben. Die Annonce kann archiviert und dauerhaft
gemacht werden, wie bei 3 angegeben, was die Annonce in den Zustand "dauerhaft archiviert" überführen kann. Eine Annonce kann
auch aus dem Zustand "dauerhaft
archiviert" veröffentlicht
werden, wie bei 4 angegeben. Eine Annonce kann aus einem Space entfernt
werden und zurück
in den Entwurfszustand übergehen,
wie bei 5 angegeben. Ein Ereignis (z. B. AdvRemoveEvent) kann erzeugt
werden, wenn die Annonce entfernt wird.
-
In
einer Ausführungsform
wird der archivierte, dauerhafte Zustand nicht verwendet. In dieser
Ausführungsform
werden auch die Zustandsänderungen
3 und 4 nicht verwendet. In dieser Ausführungsform ist eine Annonce
entweder im Entwurfszustand oder im Zustand "veröffentlicht".
-
In
einem Space gespeicherte Annoncen können die folgenden standardisierten
Elemente und/oder Attribute haben: Version (kann ein Element sein),
Erstellungsdatum (kann ein Attribut sein), Änderungsdatum (kann ein Attribut
sein), URI der Dienstimplementierung (kann ein Element sein) und/oder
Dauerhafter Archivierungsdienst (kann ein Element sein).
-
Ein
Space selbst ist typischerweise ein Dienst. Ein Space-Dienst kann
die Möglichkeit
bereitstellen, nach Annoncen in dem Space zu suchen, was das Durchsuchen
des Space nach der Art der Annoncen umfassen kann. Ein Space-Dienst
kann auch Einrichtungen zum Lesen von Annoncen, zum Schreiben (Veröffentlichen)
von Annoncen und Entfernen von Annoncen bereitstellen. Ein Space
kann auch die Möglichkeit
bieten, sich für
Benachrichtigungsmeldungen von Space-Ereignissen anzumelden. Einige
Spaces können
erweiterte Einrichtungen bieten wie Einrichtungen zum Navigieren
im Beziehungsgraphen des Space nach Position; Lesen, Schreiben oder
Wegnehmen von Elementen einer Annonce; Lesen, Schreiben oder Wegnehmen
von Attributen einer Annonce; und Anmelden für Benachrichtigungsmeldungen
von Space-Ereignissen. Space-Einrichtungen werden unten genauer
beschrieben. Die Fähigkeiten
eines Space sind im Nachrichtenschema einer Space-Annonce ausgedrückt. Aus
dem Nachrichtenschema, der Adresse des Space und dem Authentisierungsnachweis
kann ein Nachrichtengatter des Client eingerichtet werden, um auf
den Space und seine Einrichtungen zuzugreifen.
-
Spaces
und alle Annoncen innerhalb eines Space können mittels URIs adressiert
werden. In einer Ausführungsform
können
Namen von Spaces und Annoncen URL-Namenskonventionen folgen. Die
Verwendung von URIs, z. B. URLs, zur Adressierung von Spaces kann
man es in einigen Ausführungsformen
ermöglichen,
daß Spaces
durch das Internet hindurch adressierbar sind.
-
Der
Empfänger
einer Space-Nachricht (ein Space-Dienst) kann mittels eines URI
angegeben werden, der in einer Dienst-Annonce für den Space empfangen worden
sein kann. Der URI kann ein Protokoll, einen Host, eine Portnummer
und einen Namen enthalten. Das Protokoll kann das Protokoll benennen,
das verwendet werden kann, um Nachrichten zwischen Clients und dem
Space zu bewegen (zum Beispiel verläßliche oder unzuverlässige Sockets
bzw. Anschlüsse).
Der Host und die Portnummer können
protokollabhängige
IDs sein. Der Name kann der Space-Name gefolgt vom Namen einer Annonce,
eines Elementes und/oder eines Attributes sein. In einer Ausführungsform
kann ein Pfadname verwendet werden, um eine Annonce in einem Space
zu identifizieren. Pfadnamen können
entweder absolut oder relativ sein. Absolute Pfadnamen benennen
sowohl den Space als auch eine Annonce. Relative Pfadnamen sind
relativ zu einer bestimmten Annonce innerhalb eines angenommenen
Space. Nach einer Annonce sind die Syntaxregeln, die den Aufbau
von Pfadnamen festlegen, diejenigen des URI (Uniform Resource Identifier).
In dieser Ausführungsform
können
daher Space- und Annoncennamen keine für URIs reservierten Zeichen
oder Zeichenfolgen enthalten. Pfadnamen zu Elementen und Attributen
können
auch mittels eines URI angegeben werden. Im allgemeinen können Element-
und Attributnamen an Pfadnamen einer Annonce angehängt werden
wie:
httpa/java.sun.com/spacename/advertisement/element/attribute.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus enthalten,
der es einem Client ermöglicht,
den URI eines Space herauszufinden, aber den Zugriff auf die Dienstannonce
für den Space
einschränkt.
In einer Ausführungsform
kann anstatt der vollen Annonce zu dem Space der URI des Space und
der URI eines Authentisierungsdienstes für den Space geliefert werden.
Damit der Client auf die in dem Space angekündigten Dokumente oder Dienste
zugreifen kann, kann sich der Client zuerst bei dem Authentisierungsdienst
an dem URI, der in der Rückgabenachricht
geliefert wird, authentisieren. Der Authentisierungsdienst kann
dann einen Authentisierungsnachweis zurückgeben, der dem Client teilweisen
oder vollen Zugriff auf den Space ermöglicht. Wenn der Client den
Authentisierungsnachweis empfängt,
kann der Client versuchen, sich mit dem Space zu verbinden, um auf
die Dokumente oder Dienstannoncen in dem Space zuzugreifen.
-
Die
verteilte Rechnerumgebung kann einen Mechanismus oder Mechanismen
bereitstellen, die es einem Client ermöglichen, mit einem Space Verbindung
aufzunehmen. Ausführungsformen
eines Verbindungsmechanismus können
für Client-Space-Adressierung,
Client-Authentisierung. Sicherheit, Pachten bzw. Überlassen,
Feststellen der Leistungsmerkmale eines Client und Client-Space-Verbindungsverwaltung
sorgen. Eine Client-Space-Verbindung kann als eine Sitzung bezeichnet
werden. In einer Ausführungsform
kann einer Sitzung eine eindeutige Sitzungs-Identifikationsnummer
(Sitzungs-ID) zugewiesen werden. Die Sitzungs-ID kann eine Client-Space-Verbindung eindeutig
identifizieren. In einer Ausführungsform
kann ein Mechanismus zur Überlassung
einer Sitzung verwendet werden, um transparent Speicherbereinigung
bzw. Garbage-Collection
für die
Sitzung durchzuführen,
wenn der Client die Überlassung
nicht erneuert.
-
Das
Folgende ist ein Beispiel der Verwendung eines solchen Verbindungsmechanismus' gemäß einer Ausführungsform.
Ein Client kann einen Authentisierungsnachweis erhalten. In einer
Ausführungsform
kann der Space einen Authentisierungsdienst als Reaktion auf die
Anforderung eines Client für
einen Zugriff auf den Space bereitstellen. Der Client kann den Authentisierungsnachweis
durch den Authentisierungsdienst erhalten. Wenn der Client den Authentisierungsnachweis
erhält,
kann der Client eine Verbindung zu dem Space initiieren, indem er
eine Nachricht zur Verbindungsanforderung sendet. In einer Ausführungsform
kann die Nachricht zur Verbindungsanforderung die URI-Adresse des
Space-Dienstes, den Authentisierungsnachweis für den Client und Information über die
Verbindungsüberlassung
enthalten, die der Client anfordert. Nachdem der Space die Nachricht
zur Verbindungsanforderung empfangen hat, kann der Space die Nachricht
auf Gültigkeit überprüfen. In
einer Ausführungsform
kann ein XML-Schema verwendet werden, um die Nachricht zu überprüfen. Der
Client kann danach mittels des Authentisierungsnachweises authentifiziert
werden. In einer Ausführungsform
kann die Information, die in der Nachricht zur Verbindungsanforderung
empfangen wurde, verwendet werden, um die Fähigkeiten des Client zum Benutzen
des Space zu ermitteln. In einer Ausführungsform kann jedem Client
eines Space seine eigene Menge von Leistungsmerkmalen zur Nutzung
des Space zugewiesen werden. In einer Ausführungsform kann eine Zugangskontrolliste
(Access Control List, ACL), die Information bezüglich der Leistungsmerkmale über einen
oder mehrere Clients des Space enthält, beim Bestimmen der Leistungsmerkmale
eines Client verwendet werden. In einer Ausführungsform kann die Information,
die in der Nachricht zur Verbindungsanforderung empfangen wurde,
verwendet werden, um nach den Leistungsmerkmalen des Client in der
ACL zu suchen.
-
Nach
der Authentisierung des Client und dem Bestimmen der Leistungsmerkmale
des Client kann die Verbindungsüberlassung
festgelegt werden, um den Client zuzulassen. Nachdem die Überlassung
festgelegt wurde, kann die Struktur zum Aufrechterhalten der Client-Space-Verbindung
erzeugt werden. Eine Sitzungs-ID für die Verbindung kann erzeugt
werden. In einer Ausführungsform
kann jeder Client-Space-Verbindung eine eindeutige Sitzungs-ID zugewiesen
werden. In einer Ausführungsform
kann ein Aktivierungsspace eingerichtet und der Client-Space-Sitzung
zugewiesen werden oder alternativ ein vorher vorhandener Aktivierungsspace der
Client-Space-Sitzung zugewiesen werden. In einer Ausführungsform
kann ein Aktivierungsspace verwendet werden, um Ergebnisse von Diensten
für den
Client zu speichern, wenn er den Space verwendet. In einer Ausführungsform
können
die Leistungsmerkmale eines Client verwendet werden, um zu festzustellen,
wenn ein Aktivierungsspace für
den Client zu erzeugen ist. Zum Beispiel hat ein Client eventuell
nicht die Leistungsmerkmale, auf einen Aktivierungsspace zuzugreifen,
um die Ergebnisse zu speichern und zurückzuholen. Eine Nachricht oder
Nachrichten können
an den Client gesendet werden, die den Client informieren, daß die Verbindung
aufgebaut wurde. Die Nachricht oder Nachrichten können die
Sitzungs-ID und Information über
die Überlassung
enthalten. Der Client kann daraufhin den Space verwenden einschließlich, jedoch
nicht beschränkt
auf: Durchsuchen der Annonce, Registrierung der Annonce und Zurückholen
der Annonce. In einer Ausführungsform
kann die Verbindung geöffnet
bleiben, bis die zugeordnete Überlassung
erlischt oder bis der Client eine Nachricht an den Space sendet,
die das Streichen der Überlassung
anfordert. In einer Ausführungsform
kann der Client für
das Erneuern der Überlassung
verantwortlich sein, bevor die Überlassung
erlischt. Wenn die Überlassung
erlischt, bevor der Client die Überlassung
erneuert, kann die Verbindung fallen gelassen werden, was dazu führt, daß der Client
die Verbindung zu dem Space verliert. In einer Ausführungsform kann
es erforderlich sein, daß der
Client den Verbindungsvorgang wiederholt.
-
In
einer Ausführungsform
kann ein Client eines Space die Annonce eines Space auf vielen verschiedenen
Wegen erhalten. Einige der Wege, auf denen ein Client die Annonce
eines Space erhalten kann, sind in 18 abgebildet.
Zum Beispiel kann ein Protokoll zur Ausfindig-Machen eines Space
als Teil einer verteilten Rechnerumgebung bereitgestellt werden.
Ausfindig-Machen eines Space ist ein Protokoll, das ein Client oder
ein Dienst verwenden kann, um einen Space zu finden. Ein Horcher-Agent 202 kann
eingerichtet sein, der einem oder verschiedenen Spaces zugeordnet
ist, um auf Auffindungsanforderungen zu horchen. Der Auffindungs-Horcher-Agent 202 kann
auf mehreren Netzwerkschnittstellen horchen und kann entweder Rundsendeanforderungen
oder Anforderungen an eine bestimmte Adresse bzw. Unicast-Anforderungen
(an den URI des Agenten) von Clients 200a empfangen, die
nach einem Space oder nach Spaces suchen. Der Horcher-Agent 202 antwortet
dann mit der Dienstannonce oder den Dienstannoncen oder mit URIs
für die
Dienstannoncen des angeforderten Space oder der angeforderten Spaces.
In einer Ausführungsform
ist der Horcher-Agent im allgemeinen getrennt von dem Space, weil
seine Funktionalität
orthogonal zur Funktionalität
eines Space-Dienstes ist. Jedoch kann der Horcher-Agent auf derselben
Einrichtung oder einer unterschiedlichen Einrichtung wie der Space-Dienst
implementiert sein.
-
In
einer Ausführungsform
kann das Auffindungsprotokoll ein Dienst sein, der in einem Standard-Space angekündigt wird.
Ein Client kann das Auffindungsprotokoll aus dem Standard-Space
des Client instantiieren, um zusätzliche
Spaces ausfindig zu machen. Das Auffindungsprotokoll kann bei einem
Standard-Space eines Client vorab registriert sein. Alternativ kann
sich das Auffindungsprotokoll selbst bei dem Standard-Space registrieren,
indem es eine Annonce in diesen Space einstellt, d. h., wenn ein
Client sich mit einem lokalen Netzwerk verbindet, das von dem Auffindungsdienst
bedient wird.
-
In
einer Ausführungsform
kann das Space-Auffindungsprotokoll auf darunter liegende Geräte-Auffindungsprotokolle
für andere
Plattformen wie SLP, Jini, UPnP etc. abgebildet sein. Somit kann
ein Client das Auffindungsprotokoll der verteilten Rechnerumgebung
verwenden, um Dienste in anderen Umgebungen zu finden. Eine Brücke zu diesen
anderen Umgebungen und Annoncen für Dienste in diesen anderen
Umgebungen kann bereitgestellt werden, so daß Clients der verteilten Rechnerumgebung,
die hier beschrieben werden, auf sie zugreifen können. Siehe den Abschnitt zu
Bridging.
-
Für jedes
angekündigte
Auffindungsprotokoll kann die verteilte Rechnerumgebung einen nachfolgenden
Ergebnisspace anlegen, um die Ergebnisse des Auffindungsprotokolls
aufzunehmen. In einer Ausführungsform
können
Space-Dienste in der verteilten Rechnerumgebung das Multicast Announcement
Protocol (multicast UDP) verwenden, um sich auf einem LAN anzukündigen.
Ein Horcher-Agent kann diese Information aufzeichnen. Eine Einrichtung
(entweder ein Client oder eine Dienst) kann das Multicast Request
Protocol (multicast UDP) verwenden, um das Auffinden eines Space-Managers
in die Wege zu leiten. In einer Ausführungsform antworten die Space-Manager mit Information,
die die URIs ihrer zugehörigen
Spaces anzeigen. Alternativ kann ein Horcher-Agent für mehrere
Spaces antworten. Die Auffindungsantwort kann auch eine kurze Zeichenkette
enthalten, die jeden Space (z. B. abgeleitet aus Schlüsselwörtern des
Space) und Information mit einer Aufschrift versehen, die verwendet
werden kann, um eine TCP-Verbindung aufzubauen, z.B. mit jedem Space-Manager,
um Operationen auf dem zugehörigen
Space durchzuführen.
Da die anfordernde Einrichtung Antworten von mehr als einem Space-Manager
(oder mehrere Space-Aufstellungen
von einem Horcher-Agenten) erhalten kann, kann diese Information
einem Client beim Aussuchen helfen, mit welchem Space er Verbindung
aufzunehmen wünscht.
-
Über die
oben beschriebene Multicast-Auffindung hinaus kann der Auffindungsdienst
auch eine Auffindung bzw. Suche mittels Unicast-Messaging (Nachrichten-Senden
an eine Adresse, z. B. über
TCP) durchführen,
das verwendet werden kann, um einen Space-Manager an einer bekannten
Adresse auf dem Netzwerk (z. B. dem Internet, einem anderen WAN,
LAN etc.) ausfindig zu machen. Die Auffindungsnachricht an eine Adresse
kann eine Anforderung eines Space-Dienstes an einer bekannten URI
enthalten, um seine Dienstannonce bereitzustellen. Die Multicast-
und Unicast- Auffindungsprotokolle
sind auf dem Nachrichtenniveau definiert und können daher unabhängig davon
verwendet werden, ob die an der Auffindung teilnehmenden Einrichtungen
Java oder irgendeine bestimmte Sprache unterstützen.
-
Das
Auffindungsprotokoll kann die Verbreitung von Clients unabhängig von
der Verbreitung des Serverinhalts erleichtern, der diese Clients
innerhalb der verteilten Rechnerumgebung unterstützt. Z. B. kann ein mobiler
Client seinen Standard-Space anfangs in seiner lokalen Plattform
eingebaut haben. Zusätzlich
zu lokalen Diensten, die in dem Standard-Space angekündigt sind,
kann der mobile Client Dienste haben, die nach zusätzlichen
Spaces suchen, wie einen Dienst zum Zugriff auf das Auffindungsprotokoll
oder einen Dienst zum Zugriff auf Space-Suchmaschinen.
-
In
einer Ausführungsform
kann das Auffindungsprotokoll für
Spaces der verteilten Rechnerumgebung einen Satz von XML-Nachrichten
und ihre Antworten definieren, die es den Clients ermöglichen:
- • Protokolldefinierte
Space-Auffindungsnachrichten auf ihren Netzwerkschnittstellen rundzusenden.
- • Von
Horchern XML-Nachrichten zu empfangen, die mögliche Spaces beschreiben,
die diese Horcher repräsentieren.
- • Einen
von diesen ausfindig gemachten Spaces als Standard bzw. Voreinstellung
auszuwählen,
ohne daß der
Client die Adresse des ausgewählten
Space zu wissen braucht.
- • Information über den
ausgewählten
Space zu erhalten wie seine Adresse, so daß der Client diesen selben Space
später
mittels Mechanismen außerhalb
des Auffindungsprotokolls finden kann (nützlich, wenn der Client später auf
einen Space zugreifen möchten,
der nicht mehr lokal ist, aber der immer noch von Interesse für den Client
ist).
-
Nach
einigen Ausführungsformen
können
die Multicast- und Unicast-Auffindungsprotokolle ein IP-Netzwerk
erfordern. Obwohl diese Auffindungsprotokolle den Bedarf von Einrichtungen
erfüllen,
die IP-Netzwerk-fähig
sind, kann es viele Einrichtungen geben, die nicht direkt von diesen
Auffindungsprotokollen unterstützt
werden. Um den Bedarf solcher Einrichtungen beim Auffinden von Spaces
in der verteilten Rechnerumgebung zu erfüllen, kann ein Vorab-Auffindungsprotokoll
verwendet werden, um einen IP-Netzwerk-fähigen Agenten zu finden. Das
Vorab-Auffindungsprotokoll kann die Einrichtung enthalten, die eine
Nachricht auf einer Nicht-IP-Netzwerkschnittstelle sendet, die einen
Netzwerkagenten anfordert. Der Netzwerkagent kann eine Verbindung
zwischen sich und der Einrichtung aufbauen. Sobald die Verbindung
zwischen der Einrichtung und dem Agenten aufgebaut ist, nimmt der
Agent an dem Auffindungsprotokoll auf dem IP-Netzwerk im Namen der
Einrichtung teil, für
die er als Agent dient. Der Netzwerkagent kann generell für die Einrichtung auch
eine Schnittstelle zu der verteilten Rechnerumgebung bereitstellen.
Zum Beispiel können
Gatter in dem Agenten im Namen der Einrichtung aufgebaut werden,
um Dienste ablaufen zu lassen, die in aufgefundenen Spaces angekündigt sind.
Siehe den Abschnitt zu Bridging bzw Brückenbildung.
-
Eine
andere Möglichkeit,
wie Clients Spaces in der verteilten Rechnerumgebung lokalisieren
können, ist
durch Annonce eines Space in einem anderen Space. Ein Space ist
ein Dienst und kann daher wie jeder andere Dienst in einem anderen
Space angekündigt
werden. Wie in 18 dargestellt kann ein Client 200b eine
Annonce 206 in einem ersten Space 204a für einen
zweiten Space 204b finden. Space 204b kann seinerseits
Annoncen für
zusätzliche
Spaces enthalten. Weil ein Dienst (der einen Space implementiert)
auch als ein Client fungieren kann, können Spaces Annoncen austauschen
oder sich zusammenketten, um eine Vereinigung von Spaces bereitzustellen,
wie in 19 dargestellt. Jede beliebige
Anzahl von Spaces kann in der verteilten Rechnerumgebung enthalten
sein. Die Anzahl und die Topologie von Spaces können implementierungsabhängig sein.
Zum Beispiel könnten
Spaces, die auf einem IP-Netzwerk implementiert sind, jeweils einem
unterschiedlichen Teilnetz entsprechen.
-
Eine
dritte Möglichkeit,
wie ein Client einen Space lokalisieren kann, ist durch Ablaufen-Lassen eines Dienstes 208,
wie in 18 abgebildet. Man kann einen
Dienst 208 ablaufen lassen, der als seine Ergebnisse die
Dienstannoncen von Space-Diensten zurückliefert. Da Dienstannoncen
XML-Dokumente sind und da die verteilte Rechnerumgebung das Internet
einschließen
kann, kann der Dienst 208 ein Web-basiertes Suchwerkzeug
sein. Ein Beispiel eines solchen Dienstes ist der Space-Auffindungsdienst,
der in Verbindung mit 4 beschrieben wurde. In einer
Ausführungsform
können
Spaces innerhalb der verteilten Rechnerumgebung als Web-Seiten implementiert
sein. Jeder Web-Seiten-Space kann ein Schlüsselwort enthalten, nach dem
gesucht werden kann, um die Web-Seite als einen Space in der verteilten
Rechnerumgebung zu identifizieren. Der Space kann sowohl andere
Schlüsselwörter enthalten,
nach denen gesucht werden kann, als auch den Space weiter definieren.
Ein Client kann sich mit einem Nachschlagedienst 208 verbinden
und Schlüsselwörter für den Nachschlagedienst
in der Form von XML-Nachrichten liefern. Der Nachschlagedienst kann
die Schlüsselwörter von
dem Client erhalten und die Schlüsselwörter in
eine Internet-Suchmaschine
einspeisen, die eine herkömmliche
Suchmaschine oder eine Suchmaschine einer dritten Seite sein kann.
Der Nachschlagedienst kann die Ergebnisse von der Internet-Suchmaschine
entweder direkt als XML-Nachrichten oder durch Referenz auf einen
Ergebnis-Space an den Client zurückliefern.
Die Ergebnisse können
die URIs der Spaces sein, die mit der Suchanfrage übereinstimmen.
-
Alternativ
kann der Nachschlagedienst Spaces kontaktieren, die durch die Suche
identifiziert wurden, die Dienstannonce für jeden solchen Space erhalten
und die Annoncen der Space-Dienste entweder direkt als XML-Nachrichten
oder durch Referenz auf einen Ergebnis- Space zurückliefern.
Der Client kann dann einen Space aus den Suchergebnissen auswählen und
ein Gatter aufbauen (selbständig
oder durch einen Proxy), um auf den ausgewählten Dienst zuzugreifen. Sobald
auf den ausgewählten
Space zugegriffen wird, kann der Client Dienstannoncen innerhalb
dieses Space durchsuchen, was zu zusätzlichen Spaces führen kann.
-
Wie
oben beschrieben kann ein Space eine Webseite auf XML-Basis sein
und als solche mittels Mechanismen zur Websuche im Internet durchsucht
werden. Ein Space kann im Internet suchbare Schlüsselwörter enthalten. Einige Einrichtungen
wie kleine Clienteinrichtungen unterstützen möglicherweise keinen Internet-Browser.
Jedoch können
solche Einrichtungen immer noch In ternetsuchen nach Spaces innerhalb
der verteilten Rechnerumgebung durchführen. Eine Einrichtung kann
ein Programm haben, das Zeichenketten von Schlüsselwörtern akzeptiert, die an ein
Proxy-Programm auf einem Server (z. B. einen Nachschlagedienst)
gesendet werden. Der Proxy kann die Zeichenketten zum Durchführen der
Suche an eine Sucheinrichtung auf Browser-Basis (z. B. eine Internet-Sucheinrichtung)
senden. Der Proxy kann die Ausgabe der Suche empfangen und sie in
Zeichenketten zerlegen bzw. parsen (z. B. XML-Zeichenketten), die
jeden URI für
die Suchergebnisse repräsentieren,
und die Antwortzeichenketten zurück
an den Client senden. Somit kann ein Client Spaces über das
Internet lokalisieren, ohne ein Programm wie einen Web-Browser unterstützen zu
müssen. Leistungsfähigere Einrichtungen
können
die Verwendung eines Proxy vermeiden und einen Nachschlagedienst
auf Internet-Basis direkt initiieren.
-
Ein
vierter Weg, wie ein Client einen Space lokalisieren kann, ist durch
das Erhalten oder Empfangen von Information über einen neu eingerichteten,
leeren Space oder einen abgeteilten Space, wenn ein vorhandener
Space geteilt wird. Ein vorhandener Space kann eine Schnittstelle
zum Abtrennen eines leeren Space mit derselben Funktionalität (z. B.
demselben XML-Schema) wie der Space enthalten, von dem er abgetrennt wird.
Das Abtrennen bzw. Aufteilen von Spaces ist unten näher beschrieben.
-
Sobald
ein Client eines Space die Annonce eines Space-Dienstes findet,
kann dieser Client des Space den Space-Dienst ablaufen lassen, wie
er es mit jedem anderen Dienst tun könnte. Man beachte, daß der Client
des Space-Dienstes ein anderer Dienst sein kann (z. B. ein Dienst,
der eine Annonce in einem Space machen möchte). In einer Ausführungsform,
wie in 20 dargestellt, kann der Client
des Space, wenn er einen Space-Dienst ablaufen lassen möchte, zuerst
einen Authentisierungsdienst für
den Space ablaufen lassen, um einen Authentisierungsnachweis zu
erhalten, wie bei 300 dargestellt. Der Authentisierungsdienst
kann in der Dienstannonce des Space-Dienstes angegeben sein. Der Client
des Space verwendet den Authentisierungsnachweis, das XML-Schema
des Space (aus der Dienstannonce des Space) und den URI des Space
(aus der Dienstannonce des Space), um ein Gatter für den Space
einzurichten, wie bei 302 angegeben. Der Client des Space
kann dann den Space-Dienst unter Verwendung des Gatters ablaufen
lassen, um Nachrichten an den Space-Dienst zu senden. Eine erste
solche Nachricht ist bei 304 angegeben.
-
Für Ausführungsformen,
die Authentisierung einsetzen, verwendet der Space-Dienst dann,
wenn der Space-Dienst die erste Nachricht von dem Client mit dem
eingebetteten Authentisierungsnachweis empfängt, denselben Authentisierungsdienst
(der in der Dienstannonce des Space-Dienstes angegeben ist), um den Client
zu authentisieren und dadurch seine Identität zu ermitteln, wie bei 306 angegeben.
Der Space-Dienst kann die Leistungsmerkmale des Client feststellen
und sie an den Authentisierungsnachweis binden, wie bei 308 angegeben.
-
Wie
bei 310 angegeben, kann ein Client eines Space verschiedene
Spacefunktionen durch Senden von Nachrichten an den Space-Dienst
ausführen.
In einer Ausführungsform übergibt
ein Client eines Space seinen Authentisierungsnachweis in der Anforderung,
wenn er eine Anforderung an den Space-Dienst sendet, so daß der Space-Dienst
die Anforderung gegen die spezifischen Leistungsmerkmale des Client
prüfen
kann.
-
Jeder
Space ist typischerweise ein Dienst und kann ein XML-Schema haben,
das die Hauptfunktionalität
des Space-Dienstes definiert. Das XML-Schema kann die Clientschnittstelle
zu dem Space-Dienst spezifizieren. In einer Ausführungsform können alle
Space-Dienste eine Basisstufe von Space-bezogenen Nachrichten bereitstellen.
Die Basisstufe der Space-Funktionalität kann die grundlegende Space-Funktionalität sein,
die von den meisten Clients einschließlich kleiner Einrichtungen
bzw. Geräte
wie PDAs verwendet werden kann. Es kann wünschenswert sein, zusätzliche
Funktionalität
vorzusehen, z. B. für
höher entwickelte
Clients. Erweiterungen zu der Basisstufe eines Space können bewerkstelligt
werden, indem mehr Nachrichten dem XML-Schema, das den Space ankündigt, hinzugefügt werden.
Zum Beispiel führen
In einer Ausführungsform
die Basisstufen-Nachrichten keinen Beziehungsgraphen auf den Annoncen
ein. Zum Beispiel können Nachrichten
zum Traversieren einer Hierarchie von Annoncen eine Space-Erweiterung
sein. Solche zusätzliche
Funktionalität
kann durch ein oder mehrere erweiterte XML-Space-Schemata oder Schemaerweiterungen für einen
Space bereitgestellt werden. Die erweiterten Schemata können das
Basis-Schema umfassen,
so daß Clients
eines erweiterten Space immer noch auf den Space als einen Basis-Space
zugreifen können.
-
In
einer Ausführungsform
kann ein Basis-Space-Dienst ein transientes Behältnis von XML-Dokumenten (z. B.
Annoncen von Diensten, Ergebnisse von laufenden Diensten) bereitstellen.
Jedoch kann ein Basis-Space-Dienst In einer Ausführungsform eventuell keine
hochentwickelten Funktionen bereitstellen, um die Dauerhaftigkeit
von Space-Inhalt, Navigation oder Erzeugung von Space-Struktur (z.
B. Hierarchie) und ein Transaktionsmodell zur Verfügung zu
stellen. Ein Mechanismus zum Unterstützen von Dauerhaftigkeit, Hierarchie
und/oder Transaktionen ist die Erweiterung des XML-Schemas. Da erweiterte
Spaces immer noch das grundlegende XML-Schema enthalten, können Clients
erweiterte Spaces immer noch als Basis-Spaces behandeln, wenn gerade
die Basis-Space-Funktionalität
alles ist, was gebraucht wird oder unterstützt werden kann.
-
In
einer Ausführungsform
kann der Basis-Space transient sein. Der Basis-Space kann aus vielen Gründen akzeptabel
sein. Dienstanbieter können
ihre Dienste in verschiedenen Spaces registrieren. In einer Ausführungsform
müssen
Dienste ständig Überlassungen
beim Veröffentlichen
von Information in den Spaces erneuern. Deswegen können die
Dienstannoncen insofern transient sein, als sie oft neu aufgebaut
und/oder neu bestätigt
werden. Es kann jedoch wünschenswert
sein, für
eine gewisse Dauerhaftigkeit in einem Space zu sorgen. Zum Beispiel
kann ein Space, der Ergebnisse hat, eine gewisse Dauerhaftigkeit
für Benutzer
bereitstellen, die sicher sein wollen, daß Ergebnisse für eine bestimmte
Zeit nicht verloren gehen. In einer Ausführungsform kann für Dauerhaftigkeit
gesorgt werden, indem eine Space-Schnittstelle spezifiziert wird,
bei der der Client steuern kann, welche Objekte in dem Space von
einem dauerhaften Speicher unterstützt werden, und das Beibehalten
dieses Dauerspeichers verwalten kann. Die Dauerschnittstelle kann
mit einem erweiter ten XML-Schema für den Space, der die Schnittstellen
für Dauerhaftigkeit
definiert, spezifiziert werden.
-
In
einer Ausführungsform
kann ein Basis-Space eine Schnittstelle vorsehen, über die
ein XML-Dokument zu einem Space hinzugefügt und mittels einer Zeichenkette
identifiziert werden kann. Der Basis-Space sieht möglicherweise
keine Hierarchie für
die verschiedenen, so benannten XML-Dokumente in dem Space vor.
In Ausführungsformen,
in denen eine Unterstützung
einer Hierarchie gewünscht
wird, können
zusätzliche Schnittstellen
definiert werden (die das XML-Schema erweitern), über die
der Benutzer eine Hierarchie definieren kann. Andere Schnittstellen
können
bereitgestellt werden, um in der Hierarchie zu navigieren oder in einem
Beziehungsgraphen per Position zu navigieren. Jedoch können andere
Benutzer die Schnittstelle des Basis-Space immer noch benutzen,
um auf dieselben Dokumente ohne jegliche Hierarchie zuzugreifen. Schnittstellen
für eine
andere Space-Struktur können
ebenso in erweiterten Space-Schemata vorgesehen werden.
-
Erweiterte
XML-Space-Schnittstellen können
auch für
Space-Transaktionsmodelle vorgesehen werden. Zum Beispiel kann ein
erweitertes Space-XML-Schema bereitgestellt werden, das eine Schnittstelle
für ACID-Transaktionen
spezifiziert. ACID ist ein Akronym, das verwendet wird, um vier
Eigenschaften von Transaktionen auf Unternehmensniveau zu beschreiben.
ACID steht für
Unteilbarkeit (Atomicity), Konsistenz (Consistency), Entkopplung
bzw. Trennung (Isolation) und Dauerhaftigkeit (Durability). Unteilbarkeit
bedeutet, daß eine
Transaktion vollständig
vollzogen oder gar nicht vollzogen werden sollte. Im Falle eines
Scheiterns sollten alle Operationen und Vorgänge rückgängig gemacht werden und alle
Daten sollten in ihren vorherigen Zustand zurückgesetzt werden. Konsistenz
bedeutet, daß eine
Transaktion ein System von einem konsistenten Zustand in einen anderen
konsistenten Zustand überführen sollte.
Entkopplung bedeutet, daß jede
Transaktion unabhängig
von anderen Transaktionen, die zur selben Zeit auftreten, geschehen
sollte. Dauerhaftigkeit bedeutet, daß abgeschlossene Transaktionen
permanent bestehen bleiben sollten, z. B. auch während eines Systemausfalls.
Es können
auch andere Transaktionsmodelle in erweiterten Space-Schemata spezifiziert
werden.
-
Erweiterte
Space-Schemata können
XML-Dokumente sein, die die Nachrichtenschnittstelle (z. B. XML-Nachrichten)
zur Benutzung der erweiterten Space-Eigenschaften, -Funktionalität oder Einrichtungen spezifizieren.
Ein Space kann ein Basis-Schema und mehrere erweiterte Schemata
haben. Dies kann es erleichtern, abhängig von der Authentisierung
der Clients unterschiedlichen Clients unterschiedliche Stufen von Diensten
zur Verfügung
zu stellen.
-
Neben
Erweiterungen für
die Dauerhaftigkeit eines Space, seine Struktur und Transaktionen
können auch
andere Space-Erweiterungen nach Bedarf spezifiziert werden. Zum
Beispiel können
Erweiterungen vorgesehen werden, um Annoncen auf der Element- oder
Attributebene zu manipulieren: Lesen, Schreiben oder Wegnehmen von
Annoncenelementen; Lesen, Schreiben oder Wegnehmen von Annoncenattributen;
und Anmelden für
Nachrichten mit Ereignismeldungen zu Annoncen. Ein Space kann praktisch
jede beliebige Anzahl von Funktionen bereitstellen und sie nach
Wunsch in Basis- und erweiterte Schemata anordnen. In einer Ausführungsform
müssen
alle Basis- Spaces
Funktionen zum Lesen, Schreiben, Wegnehmen und Durchsuchen von Annoncen
und für
Anmeldungen für
Space-Ereignisse bereitstellen.
-
Verschiedene
Space-Funktionen können
bereitgestellt werden. Nach einigen Ausführungsformen kann eine Funktion
zum Aufbau einer Sitzung mit dem Space vorgesehen werden. Nach einer
solchen Ausführungsform
ist der Rest der Space-Funktionalität nicht verfügbar, bis
dies erfolgt ist. In anderen Ausführungsformen ist der Begriff
einer Sitzung nicht vorgesehen oder er ist optional und/oder implementierungsabhängig.
-
Eine
weitere Space-Funktion kann sein, eine Dienstannonce zu einem Space
hinzuzufügen
oder sie aus einem Space zu entfernen. Eine Space-Funktion kann
auch zum Hinzufügen
oder Entfernen eines XML-Dokumentes (nicht einer Annonce, aber vielleicht
eines Ergebnisses in einen Space) zur Verfügung gestellt werden. Der Space-Dienst
kann die Eindeutigkeit eines Gegenstandes bzw. einer Einheit überprüfen, bevor
er das Hinzufügen
der Einheit erlaubt. Zum Beispiel kann jede Einheit, die zu einem
Space hinzugefügt wird,
einer benutzerspezifischen Zeichenkette zugeordnet werden, die die
Einheit identifiziert und die verwendet werden kann, um die Eindeutigkeit
der Einheit zu überprüfen.
-
In
einer Ausführungsform
kann ein Client eine Auflistung, einen Baum oder eine andere Darstellung aller
Dienste anfordern, die in dem Space angekündigt werden. Der Benutzer
kann daraufhin durch die Annoncen durchblättern oder durch den gewünschten
Dienst manövrieren
und auswählen.
Ein Space kann auch eine Funktion zum Durchsuchen vorsehen, die
es einem Client ermöglicht,
nach einem Dienst durch Angabe von Schlüsselwörtern oder Namensketten zu
suchen. In einer Ausführungsform
kann eine Space-Funktion einen Mechanismus bereitstellen, um eine
Space-Einheit durchzusehen, die dem Space hinzugefügt wurde.
Die Funktion zum Durchsuchen kann nach Zeichenketten suchen, die
einem Namen, einer Wildcard oder sogar einer Datenbankanfrage entsprechen.
Die Funktion zum Durchsuchen kann mehrere Einträge zurückliefern, aus denen der Client
einen auswählen
oder eine einengende Suche durchführen kann. In einer Ausführungsform
kann die Funktion zum Durchsuchen einen Mechanismus vorsehen, um
eine Dienstannonce zu lokalisieren, die einem bestimmten XML-Schema
entspricht. Der Client kann ein bestimmtes XML-Schema oder einen Teil
eines bestimmten XML-Schemas angeben, nach dem innerhalb des Space
gesucht wird. Damit kann innerhalb eines Space nach einem Dienst
entsprechend seiner Schnittstellenfunktionalität gesucht werden.
-
Eine
weitere Space-Funktion, die in der verteilten Rechnerumgebung bereitgestellt
wird, ist ein Mechanismus, der es Diensten und Clients ermöglicht,
transiente Dokumente zu finden, die auf einem Modell zur Typisierung
wie XML beruhen. Der Mechanismus kann ein allgemein verwendeter
Mechanismus zum Durchsuchen von typisierten Dokumenten sein. In
einer Ausführungsform
kann der Mechanismus zum Durchsuchen auf XML beruhen. Der Mechanismus
zum Durchsuchen kann es Clients und Diensten ermöglichen, Dokumente im allgemeinen
zu finden, einschließlich
Diensten durch Dienstannoncen.
-
In
einer Ausführungsform
kann ein Paar von Space-Durchsuch- und Antwortnachrichten verwendet werden,
um es Clients und Diensten zu ermöglichen, XML-Dokumente zu finden,
die innerhalb eines transienten Dokumentenspeichers im Netzwerk
(Space) gespeichert sind. Der Space kann ein Dokumenten-Space sein,
der verwendet wird, um eine Vielzahl von Dokumenten zu speichern.
In einer Ausführungsform
sind die Dokumente XML-Dokumente oder Nicht-XML-Dokumente, die in XML eingekapselt sind.
Spaces sind an anderer Stelle weitergehend beschrieben. Die Durchsuch-Nachrichten
können
auf jede Art von XML-Dokument wirken, das in dem Space gespeichert
ist, einschließlich
Dienstannoncen und Annoncen von Gerätetreibern. In einer Ausführungsform
kann ein Client (der ein anderer Dienst sein kann) einen Auffindungsmechanismus verwenden,
wie an anderer Stelle beschrieben, um einen oder mehrere Dokumenten-Spaces
zu finden. Daraufhin kann der Client Durchsuch-Nachrichten für Spaces
verwenden, um in dem Space gespeicherte Dokumente zu lokalisieren.
-
Die
verteilte Rechnerumgebung kann einen Mechanismus beinhalten, der
es Diensten und Clients ermöglicht,
sich für
Ereignisse über
die Veröffentlichung
von XML-Dokumenten anzumelden und Ereignisse über die Veröffentlichung von XML-Dokumenten
zu empfangen. Ereignisse können
die Veröffentlichung
und das Entfernen von XML-Dokumenten in und aus einem transienten
Behältnis
für XML-Dokumente
wie einem Space umfassen. In einer Ausführungsform kann ein Ereignis
ein XML-Dokument sein, das auf ein anderes XML-Dokument verweist.
-
In
einer Ausführungsform
kann ein Paar von Ereignis-Anmeldungs- und Antwortnachrichten verwendet
werden, um es Clients und Diensten zu ermöglichen, sich für Ereignisse
bezüglich
Dokumenten anzumelden, die zu einem Space hinzugefügt oder
daraus entfernt werden. In einer Ausführungsform kann eine Ereignisanmeldung
mittels eines Überlassungs-
bzw. Pachtmechanismus, der an anderer Stelle beschrieben wird, überlassen
bzw. gepachtet werden. In einer Ausführungsform kann eine Anmeldung
gestrichen werden, wenn die Überlassung
gestrichen wird oder erlischt. In einer Ausführungsform kann das Erneuern
der Überlassung einer
Anmeldung eine Anmeldung erneuern.
-
In
einer Ausführungsform
kann eine Ereignisanmeldungsnachricht ein XML-Schema enthalten,
das als ein Mechanismus zum Erkennen bzw. Feststellen von übereinstimmenden
Dokumenten verwendet werden kann. Dokumente, die mit dem Schema übereinstimmen,
können
durch die Anmeldung abgedeckt werden. In einer Ausführungsform
kann jedes Dokument, das zu einem Space hinzugefügt wird und mit dem XML-Schema übereinstimmt,
eine Space-Ereignisnachricht erzeugen.
-
Es
kann auch eine Space-Funktion bereitstehen, für die sich ein Client registrieren
(und wieder abmelden) kann, um eine Benachrichtigung zu erhalten,
wenn etwas zu einem Space hinzugefügt oder aus ihm entfernt wird.
Ein Space kann einen transienten Inhalt enthalten, der Dienste repräsentiert,
die zu einem Space hinzugefügt
werden und aus ihm entfernt werden. Es kann ein Mechanismus vorgesehen
werden, um einen Client zu benachrichtigen, wenn zum Beispiel ein
Dienst verfügbar
wird oder nicht mehr verfügbar
ist. Ein Client kann sich bei einem Ereignisdienst registrieren,
um solche Benachrichtigungen zu erhalten. In einer Ausführungsform
kann sich ein Client registrieren, um benachrichtigt zu werden,
wenn ein Dienst mit einem Namen, der mit einer angegebenen Zeichenkette übereinstimmt,
oder mit einem Schema, das mit einem angegebenen Schema (oder Teil
eines Schemas) übereinstimmt,
zu einem Space hinzugefügt
oder aus ihm entfernt wird. Somit kann die Anfrage, sich bei einer
Benachrichtigungsfunktion für
Space-Ereignisse zu registrieren, dasselbe oder etwas ähnliches
sein wie eine Anfrage an eine oben beschriebene Suchfunktion nach
Diensten.
-
Wenn
ein Client eines Space eine Bestellung dahingehend abgibt, daß er benachrichtigt
wird, wenn ein XML-Dokument (bzw. XML-Dokumente) (beispielsweise
eine Dienstannonce) dem Space hinzugefügt oder aus diesem entfernt
wird, so kann der Client auf Basis dieser Bestellung von Meldungen
ein Mietrecht erhalten. Das Mietrecht könnte es dem Dienst des Space
ermöglichen,
zu erkennen, ob er fortfahren soll, Meldungen an einen bestimmten
Client zu senden. Beispielsweise kann ein Mietrecht für die Einrichtung
der Meldung nach einem bestimmten ZeitSpace erlöschen, wenn es nicht erneuert
wird. Man beachte, daß ein
Mietrecht nicht erforderlich sein muß, während ein Client eine aktive
Sitzung mit einem Space hergestellt hat. Wenn ein Client eine aktive
Sitzung mit einem Space abgebrochen hat, so kann er weiterhin Nachrichten über Ereignisse
entsprechend seinen Vorbestellungen für Ereignisse empfangen, solange
sein entsprechendes Mietrecht bzw. Abonnement aktiv ist. Auf den
folgenden Abschnitt über
Abonnements wird hier Bezug genommen.
-
Ein
Client kann verschiedene Arten von Ereignissen abonnieren. Beispiele
bestehen in einer Dienstannonce, die einem Space hinzugefügt oder
von diesem entfernt wird, wie es oben beschrieben wurde. Ein Client
kann auch benachrichtigt werden, wenn Ergebnisse von einem Dienst,
der durch den Client (oder irgendjemanden anders) ausgelöst wurde,
in einem Space abgelegt werden. Beispielsweise können der Client und der Dienst
wechselseitig einen Namen für
die Bezugnahme auf die Ergebnisse des Dienstes auswählen. Der
Client kann sich bei dem Dienst des Space registrieren lassen, an
welchem die Ergebnisse aufgegeben oder angezeigt werden sollen,
um ein Ereignis bzw. eine Ereignismeldung zu erhalten, wenn ein
Ergebnis, das durch den ausgewählten
Namen aufgerufen wird, dem Space hinzugefügt wird.
-
Ein
Space kann unterschiedliche Typen von Ereignissen erzeugen, welche
ein Client abonnieren kann. Wenn sich die Zusammensetzung eines
Space verändert,
können
Ereignisse für
diejenigen Clients und Dienste erzeugt werden, die derartige Ereignisse
abonniert haben. In einer Ausführungsform
kann es zwei hauptsächliche
Kategorien von Ereignissen des Space geben, diejenigen, die zu dem
Space gehören
(Einfügen
und Entfernen von Annoncen), und diejenigen, die verwendet werden
und welche Veränderungen
einer Annonce anzeigen (Hinzufügen,
Entfernen oder Verändern
eines Elements oder eines Attributs). Welche Ereignisse unterstützt werden,
kann in dem XML-Nachrichtenschema für den Space angezeigt werden.
-
Die
folgenden Ereignisse sind Beispiele von Ereignissen, die durch den
Dienst eines Space erzeugt werden können, um ein Space- oder Annonceereignis
anzuzeigen: Tabelle
1 Spaceereignisse
-
Ereignisse
können
mit Typen versehen sein. Nach einigen Ausführungsformen können es
die Ereignisfunktionen, die von Spaces unterstützt werden, Ereignishorchern
ermöglichen,
z. B. Vorteil aus Java-Klassenhierarchien (oder XML-Typhierarchien)
zu ziehen. Zum Beispiel empfängt
der Horcher durch das Horchen auf AdvElementEvent Ereignisse vom
Typ AdvElementEvent und aller seiner Unterklassen (XML-Typen). Somit
werden bei diesem Beispiel alle Ereignisse, die sich auf Elementänderungen
beziehen (jedoch nicht auf das Einfügen oder Entfernen von Annoncen),
empfangen.
-
Als
weiteres Beispiel führt
das Anmelden für
oder das Horchen auf eine Ereignisklasse oder einen Ereignistyp
auf oberster Stufe, z. B. SpaceEvent, zum Empfang aller Space-Ereignisse.
Typen von Ereignisklassen können
zum Beispiel mittels des Java-Operators instanceof oder des XML-Typisierungssystems
unterschieden werden.
-
Ein
Ereignis kann einen URI zu der betroffenen Annonce oder dem betroffenen
Element enthalten. Zum Beispiel können AdvertisementEvent und
alle seine Unterklassen eine Referenz (z. B. URI oder URL) auf
die betroffene Annonce enthalten. AdvElementEvent und seine Unterklassen
können
auf die Namen des betroffenen Elementes hin untersucht werden. Der
vorige Wert des Elementes (URI oder URL) kann zum Beispiel aus AdvElementRemoveEvent
und AdvElementValueChangeEvent verfügbar sein.
-
Eine
Typhierarchie von Space-Ereignissen für eine Ausführungsform ist in 21 dargestellt. Typen können in XML definiert und in
Java oder in irgendeiner anderen geeigneten, objektorientierten
Sprache wie C++ verwendet werden.
-
Ein
Space kann eine Funktion zum Instantiieren eines in dem Space angekündigten
Dienstes für
einen Client zur Verfügung
stellen. Die Instantiierung eines Dienstes heißt, die Initialisierung ausgeführt zu haben, die
es einem Client ermöglicht,
einen Dienst ablaufen lassen zu können. Eine Ausführungsform
der Instantiierung von Diensten ist in 22 dargestellt.
Zum Instantiieren eines Dienstes kann ein Client zuerst eine der
in dem Space veröffentlichten
Dienstannoncen auswählen,
wie bei 320 angegeben. Der Client kann verschiedene Funktionen
wie die Funktion zum Durchsuchen verwenden, die von den Space bereitgestellt
werden, um die verschiedenen Annoncen in dem Space zu durchsuchen.
Danach kann der Client anfordern, daß der Space den Dienst instantiiert,
wie bei 322 angegeben.
-
In
einer Ausführungsform
kann eine Instantiierung eines Diensten die folgenden Aktionen umfassen. Nachdem
der Client angefordert hat, daß der
Space-Dienst den ausgewählten
Dienst instantiiert, wie bei 322 angegeben, kann der Space-Dienst
daraufhin überprüfen, daß der Client
berechtigt ist, den angeforderten Dienst zu instantiieren, wie bei 324 angegeben.
Der Space-Dienst kann diese Überprüfung durchführen, indem er
einen Authentisierungsnachweis, der in der Nachricht des Client
enthalten ist, überprüft. Der
Authentisierungsnachweis ist der Nachweis, den der Client erhalten
hat, als er eine Sitzung mit dem Space-Dienst aufgebaut hat. Der
Space-Dienst kann prüfen,
ob es dem Client erlaubt ist, den angeforderten Dienst gemäß dem Authentisierungsnachweis
des Client und den Leistungsmerkmale, die für diesen Client angegeben sind,
zu instantiieren. Siehe den Abschnitt über Authentisierung und Sicherheit.
-
Angenommen,
der Client ist berechtigt, dann kann der Space-Dienst auch eine
Pacht auf bzw. eine Überlassung
für die
Dienstannonce für
den Client erhalten, wobei die Pacht- bzw. Überlassungsanforderungszeit
von dem Client angegeben wird, wie bei 326 angegeben. Überlassungen
werden unten weiter diskutiert. Der Space-Dienst kann dann eine
Nachricht an den Client senden, die die zugeordnete Überlassung
und die Dienstannonce des Dienstes enthält, wie bei 328 angegeben.
In einer Ausführungsform
kann der Client einen Authentisierungsdienst laufen lassen, der
in der Dienstannonce spezifiziert ist, und einen Authentisierungsnachweis
erhalten, wie bei 330 angegeben. Siehe den Abschnitt über Authentisierung
und Sicherheit für
mehr Information über
den Authentisierungsdienst. Als nächstes kann der Client, wie
bei 332 angegeben, ein Gatter für den Dienst einrichten (zum
Beispiel unter Verwendung des Authentisierungsnachweises und des XML-Schemas und des Dienst-URI
aus der Annonce). Siehe den Abschnitt über Gatter. Die oben beschriebene
Kommunikation zwischen dem Client und dem Space-Dienst wird mittels
des Sendens von XML-Nachrichten der verteilten Rechnerumgebung durchgeführt. Der
Client kann danach den Dienst unter Verwendung des eingerichteten
Gatters und Sendens von XML-Nachrichten ablaufen lassen. Der Dienst
kann in ähnlicher
Weise ein Dienstgatter für
die XML-Nachrichtenkommunikation mit dem Client einrichten.
-
Zusammenfassend
wird eine beispielhafte Verwendung eines Space wie folgt diskutiert.
Ein Client kann auf einen Space-Dienst zugreifen (z. B. sich mit
ihm verbinden). (Ein Dienst kann zum Zweck des Zugreifens auf einen
Space oder zur anderweitigen Nutzung eines Space als ein Client
fungieren.) Der Space-Dienst kann eine oder mehrere Dienstannoncen
und/oder anderen Inhalt in einem Space speichern, und jede der Dienstannoncen
kann Information enthalten, die verwendbar ist, um auf einen zugehörigen Dienst
zuzugreifen und ihn auszuführen.
Der Space-Dienst kann ein Schema enthalten, das eine oder mehrere
Nachrichten spezifiziert, die verwendet werden können, um die Funktionen des
Space-Dienstes aufzurufen. Zum Beispiel kann das Schema Methoden
zum Lesen von Annoncen aus dem Space und zum Veröffentlichen von Annoncen in dem
Space enthalten. Das Schema und die Dienstannoncen können in
einer Objektrepräsentationssprache wie
eXtensible Markup Language (XML) ausgedrückt werden. Beim Zugriff auf
den Space-Dienst kann der Client Information wie eine XML-Nachricht
(wie in dem Schema spezifiziert) an den Space-Dienst bei einer Internet-Adresse
senden. Beim Zugriff auf den Space-Dienst kann der Client die eine
oder mehrere Dienstannoncen durchsuchen, die in dem Space gespeichert
sind. Der Client kann eine der Dienstannoncen aus dem Space auswählen. In
einer Ausführungsform
kann der Client eine Instantiierungsanforderung an den Space senden,
nachdem er die gewünschten
Dienstannoncen aus dem Space ausgewählt hat. Eine Überlassung kann
von dem gewünschten
Dienst erhalten werden, und die Überlassung
und die ausgewählte
Dienstannonce kann von dem Space-Dienst an den Client gesendet werden.
Der Client kann danach ein Gatter zum Zugriff auf den gewünschten
Dienst einrichten. Der gewünschte
Dienst kann dann im Namen des Client ausgeführt werden.
-
Eine
andere Funktion, die von einem Space-Dienst bereitgestellt wird,
kann das Hervorbringen oder Erzeugen eines leeren Space sein. Die
Space-Funktion kann es einem Client (der ein Dienst für einen
anderen Client sein kann) ermöglichen,
dynamisch einen neuen Space zu erzeugen. In einer Ausführungsform
kann diese Space-Funktion eine Schnittstelle zum Erzeugen eines
leeren Space mit derselben Funktionalität enthalten (demselben XML-Schema
oder erweiterten Schema) wie der Space, aus dem er erzeugt bzw.
abgeleitet wird. Diese Funktion kann zum (z. B. dynamischen) Erzeugen
von Spaces für
Ergebnisse nützlich
sein. Zum Beispiel kann ein Client einen Space erzeugen und einen
Dienst auffordern, Ergebnisse in dem erzeugten Space zu plazieren
oder darin anzukündigen.
Der Client kann den URI des erzeugten Space und/oder einen Authentisierungsnachweis
an den Dienst übergeben.
Oder ein Dienst kann einen Space für Ergebnisse erzeugen und den
URI des erzeugten Space und/oder einen Authentisierungsnachweis
an den Client übergeben. Nach
einigen Ausführungsformen
kann ein Space, nachdem er erzeugt wurde, genau wie andere Spaces
mittels einer oder mehrerer der hier beschriebenen Mechanismen zum
Auffinden von Spaces aufgefunden werden.
-
Durch
das Verwenden eines Mechanismus',
bei dem ein Space über
eine Schnittstelle in einem anderen Space erzeugt werden kann (z.
B. einer Funktion zum Erzeugen von Spaces), können neue Spaces effizient
erzeugt werden. Zum Beispiel kann In einer Ausführungsform Speicher für den erzeugten
Space mittels derselben Funktion reserviert werden, die von dem
ursprünglichen
Space für
Speicher verwendet wurde. Ebenso kann sich ein erzeugter Space eine
gemeinsame Dienstfunktion mit seinem ursprünglichen (oder Eltern-)Space
teilen. Zum Beispiel kann ein neuer URI dem neuen Space zugewiesen
werden. In einer Ausführungsform
kann der neue URI eine Umlenkung zu einer gemeinsamen Space-Funktion
sein, die mit dem ursprünglichen
Space gemeinsam genutzt wird. Somit kann ein neu erzeugter Space
denselben oder einen Teil desselben Dienstcodes wie denjenigen des
ursprünglichen
Space verwenden.
-
Space-Funktionen
können
auch Sicherheitsverwaltung umfassen, um zum Beispiel die verschiedenen Sicherheitsrichtlinien
des Space zu aktualisieren, und andere administrative Funktionen.
Zum Beispiel können die
Anzahl und das Alter von Annoncen von einem Stamm-Space-Dienst kontrolliert
und überwacht
werden. Alte Annoncen können
gesammelt und entsorgt werden. Siehe, z. B. den Abschnitt über Überlassungen
im Hinblick darauf, wann Annoncen als alt angesehen werden können. Der
Dienst, der den Space implementiert, kann unter der Kontrolle eines
Verwalters sein. Der Verwalter kann die Richtlinie in einer dienstabhängigen Weise
festsetzen. Space-Funktionen können
auch eine Funktion umfassen, um einen leeren Space zu löschen.
-
Gewisse
Spaces können
Funktionen oder Dienste beinhalten, um die Verbreitung von gewissen
Clients wie mobile Clients weiter zu unterstützen. Zum Beispiel können Dienste
in Spaces, die ein mobiler Client auffinden kann, z. B. über das
Auffindungsprotokoll, Unterstützung
für mobile
Clients bereitstellen wie:
- • Zuweisen und Verwalten von
temporären
Netzadressen für
den Client.
- • Nachrichtenübergabe über einen
Proxy für
den Client.
- • Bereitstellen
von Suchfunktionen nach zusätzlichen
Spaces. Zum Beispiel kann es ein Dienst einem Client ermöglichen,
Schlüsselwörter durch
eine einfache Schnittstelle anzugeben. Der Dienst verwendet dann
die Schlüsselwörter in
Verbindung mit Web-Suchmaschinen
zur Suche nach Spaces auf dem Web, wie hier näher beschrieben. In anderen
Ausführungsformen
kann ein Suchdienst Clients einschränken, nur einige wenige unterstützte Spaces
innerhalb der verteilten Rechnerumgebung zu suchen.
-
Wie
zuvor erwähnt
(siehe 9 und zugehörigen Text) können Spaces
einen bequemen Mechanismus zum Speichern von Ergebnissen aus einem
Dienstdurchlauf durch einen Client bereitstellen. Die Verwendung
eines Space für
Ergebnisse kann es einem kleinen Client ermöglichen, die Ergebnisse des
Ablaufen-Lassens eines Dienstes in Teilen zu empfangen. Einige Dienste
können
womöglich
eine große
Menge von Ergebnissen erzeugen. Durch das Verwenden eines Space
zum Speichern der Ergebnisse von einem Dienst können Clients, die nicht über die
Ressourcen verfügen,
um die gesamten Ergebnisse auf einmal zu empfangen, den Dienst immer
noch benut zen. Darüber
hinaus kann durch das Verwenden eines Space zum Speichern der Ergebnisse
ein Dienst, der auf einem schnellen, ausgelasteten Server abläuft, davon
befreit werden, direkt mit einem langsamen Client zu interagieren,
wenn er umfangreiche Ergebnisse zurückgibt. Somit kann der Dienst eher
zur Benutzung durch andere Clients freigegeben werden.
-
Ein
Space kann einen bequemen Mechanismus zum Zugriff auf ein Ergebnis
durch unterschiedliche Clients und/oder zu unterschiedlichen Zeiten
bereitstellen. Zum Beispiel ist ein Client möglicherweise nicht in der Lage,
das gesamte Ergebnis zu verwenden, aber ein Benutzer wünscht, auf
den Rest des Ergebnisses später
unter Verwendung eines anderen Client, der darauf zugreifen kann,
zuzugreifen. Zum Beispiel könnte das
Ergebnis Information über
Börsenkurse
sein, die den aktuellen Preis einer Aktie anzeigt (zugänglich über einen
PDA), und die eine Kurve bzw. ein Diagramm von Aktienkursen anzeigt
(zugänglich über einen
Laptop zu einem späteren
Zeitpunkt). Das Verwenden eines Space für Ergebnisse in der verteilten
Rechnerumgebung kann es einem Client auch ermöglichen, ohne die Notwendigkeit,
die Ergebnisse zuerst herunterzuladen, die Ergebnisse eines Dienstes
in einen anderen Dienst einzuspeisen. Zum Beispiel könnte in
dem obigen Fall der Aktienkursinformation der PDA das Diagramm in
einen anderen Dienst einspeisen, der das Diagramm druckt, ohne daß der PDA
das Diagramm selbst herunterladen muß. Somit kann ein Ergebnis-Space
für einen
Client einen Mechanismus zur Weitergabe an einen anderen Client
oder Dienst zur Verfügung
stellen, ohne daß der Client
die Ergebnisse behandeln oder empfangen muß.
-
Nach
verschiedenen Ausführungsformen
kann die Entscheidung, einen Space für Ergebnisse zu verwenden,
durch den Dienst in Auftrag gegeben werden, durch den Client in
Auftrag gegeben werden und/oder von dem Client angefordert werden.
Ein Dienst kann die Verwendung eines Space für seine Ergebnisse vorschlagen,
z. B. in seiner Annonce. In einer Ausführungsform kann entweder der
Client oder der Dienst einen neuen Space für Ergebnisse erzeugen oder
einen vorhandenen Space für
Ergebnisse verwenden. Siehe die Beschreibung bezüglich Abspalten bzw. Erzeugen
von Spaces.
-
In
einer Ausführungsform
bedeutet die Verwendung eines Space für Ergebnisse nicht notwendigerweise,
daß der
Dienst alle Ergebnisse in diesen Space stellen muß. Es kann
für jegliches
Ergebnis, das ein Dienst erzeugt, Alternativen geben. Zum Beispiel
können
ein Teil oder alle Ergebnisse in eine Nachricht eingebunden an den
Client gesendet werden. Alternativ kann das Ergebnis in den Space
eingestellt werden, und danach kann eine Hinweisnachricht an den
Client gesendet werden, die das Ergebnis referenziert (z. B. einschließlich eines
URI auf das Ergebnis oder auf eine Annonce des Ergebnisses). Eine
weitere Option kann sein, das Ergebnis mit einer Benachrichtigung über ein
Ergebnis von dem Space in den Space einzustellen. Zum Beispiel können der
Client und der Dienst vereinbaren, dem Ergebnis einen bestimmten
Namen zu geben, und dann kann sich der Client bei dem Space registrieren
(mittels einer Space-Funktion wie oben beschrieben), um ein Ereignis
zu empfangen, wenn ein Ergebnis mit diesem Namen zu dem Space hinzugefügt wird.
Siehe die obige Beschreibung zur Benachrichtigung über Ereignisse.
-
Somit
können
für einen
Dienst einige unterschiedliche Mechanismen innerhalb der verteilten
Rechnerumgebung eingesetzt werden, um Ergebnisse an einen Client
abzuliefern. Die tatsächlichen
Ergebnisse können
an den Client als Wert in einer XML-Nachricht zurückgegeben
werden, oder die Ergebnisse können
an den Client als Referenz zurückgegeben
werden, wobei die tatsächlichen
Ergebnisse (oder eine Annonce der tatsächlichen Ergebnisse) in einen
Space eingestellt werden und der Client eine Nachricht erhält, die
auf die Ergebnisse in dem Space hinweist. Darüber hinaus können Ergebnisse
oder Ergebnisannoncen in einen Space eingestellt werden, und der
Client kann durch ein Ereignis benachrichtigt werden.
-
Ein
anderer Mechanismus zur Behandlung von Ergebnissen kann sein, daß der Client
einen anderen Dienst spezifiziert, in den die Ergebnisse einzuspeisen
sind. Wenn ein Client zum Beispiel einen Dienst ablaufen läßt, der
Ergebnisse erzeugt, kann der Client diesen Dienst instruieren (z.
B. durch das Senden von XML-Nachrichten), die Ergebnisse an einen
anderen Dienst zur weiteren Verarbeitung zu senden. Dies kann beinhalten,
daß der
Client den URI der Annonce des anderen Dienstes angibt, so daß der Ergebnis-produzierende
Dienst ein Gatter zu dem anderen Dienst erzeugen kann, um den anderen
Dienst ablaufen zu lassen und ihm die Ergebnisse zu übergeben.
In diesem Beispiel kann der Ergebnis-produzierende Dienst ein Client des
anderen Dienstes sein. Nach einigen Ausführungsformen kann der Client
das Schema oder ein vorab eingerichtetes Gatter an den Ergebnis-produzierenden
Dienst zum Zugriff auf den Dienst zur weiteren Verarbeitung senden.
Ein Beispiel für
einen Dienst zur weiteren Verarbeitung ist ein Anzeige-Dienst, der
die Ergebnisse für
den ursprünglichen
Client anzeigen kann. Dieser Anzeige-Dienst kann auf derselben Einrichtung
wie der Client sein oder dieser zugeordnet sein.
-
Ergebnis-Spaces
und Methodengatter können
es der verteilten Rechnerumgebung ermöglichen, einen einfachen entfernten
Methodenaufruf zur Verfügung
zu stellen, der für
Thin-Clients mit minimalem Speicherausbau und minimaler Bandbreite
praktikabel ist, weil er nicht die ungünstigen Nebeneffekte von riesigen Programmobjekten
(zusammen mit den benötigten
Klassen) hat, die wie bei herkömmlichen
Techniken zum entfernten Methodenaufruf (notwendigerweise) über das
Netzwerk an den Client zurückgeliefert
werden. Stattdessen können
Ergebnisse an einen Ergebnis-Space
zurückgegeben
werden, und nur wenn gewünscht
(und wenn sie auf dem Client Platz finden können), werden die tatsächlichen
Objekte an den Client heruntergeladen.
-
Der
Mechanismus, durch den die verteilte Rechnerumgebung entfernte Methodenaufrufe
zur Verfügung
stellen kann, ist wie folgt (siehe auch die Beschreibung der Methodengatter
in dem Abschnitt über
Gatter). Ein Objekt kann in einem Space angekündigt werden (z. B. als ein
Dienst oder als Teil eines Dienstes). Die Annonce beinhaltet eine
Referenz, die den URI (z. B. URL) des Objektes zusammen mit anderen
Zugangsparametern wie Sicherheitsnachweise und ein XML-Schema enthält. Ein
Client kann ein Client-Methodengatter für das Objekt besitzen oder
kann eines einrichten, das für
jede Methode des Objektes (oder des Dienstes) selbst eine Wrapper-Methode
bzw. Einwickel-Methode besitzen kann, welche die Methodenparameter
nimmt und eine Anforderungs-XML-Nachricht
erzeugt, um eine Methode des Objektes aufzurufen. Die XML-Nachricht
wird an ein Dienstgatter gesendet, das die tatsächliche Methode auf dem Dienstobjekt
aufruft. Wenn diese Methode ein Ergebnisobjekt zurückliefert,
kann das Dienstgatter das Ergebnisobjekt in einem Ergebnis-Space bekannt geben
und eine Nachricht mit einer Referenz auf das Ergebnisobjekt an
den Client zurückgeben.
-
Somit
sendet der Client, damit er eine entfernte Methode aufrufen kann,
zuerst eine Nachricht, um ein Objekt (z. B. einen Dienst) zu instantiieren,
wie oben beschrieben. In einer Ausführungsform kann die Instantiierung
eines Objektes das Erzeugen oder Abspalten eines Ergebnis-Space beinhalten.
In einer anderen Ausführungsform
kann das Erzeugen eines Ergebnis-Space unabhängig von der Instantiierung
des Objektes sein. Die Instantiierung kann den Objekt-URI an den
Client zurückgeben,
und die Client- und Dienst-Gatter können dynamisch eingerichtet
werden, wenn ein Client eine Instantiierung anfordert. Nach einigen
Ausführungsformen
kann ein Ergebnis-Space
bereits vorhanden sein und von dem Objekt (dem Dienst) angekündigt werden. Ein
Teil der Gatter oder alle Gatter können auch vorab eingerichtet
sein oder wiederverwendet werden.
-
Sobald
ein Client ein Objekt instantiiert hat, bewirkt ein lokaler Aufruf
des geeigneten Methodengatters des Client einen entfernten Aufruf
des tatsächlichen
entfernten Objektes, wie oben beschrieben. Der Ansatz des entfernten
Methodenaufrufs der verteilten Rechnerumgebung kann rekursiv sein,
wobei Objektreferenzen anstelle der Objekte selbst an den Client
zurückgegeben
werden, wenn das Clientgatter aufgerufen wird. Man beachte, daß solche
zurückgegebenen
Objekte bereits instantiiert sein können. Nach einigen Ausführungsformen
kann der Client entscheiden, das ganze Objekt selbst herunterzuladen,
anstatt es nur entfernt aufzurufen.
-
Eine
Methode oder ein Dienst, die bzw. der wie oben beschrieben aufgerufen
wird, kann ein Tochter-Gatter erzeugen, das dem Ergebnisdokument
zugeordnet ist. Die Methode kann ein Tochter-Gatter (oder das Schema,
den URI und Sicherheitsnachweise für den Client zum Einrichten
eines Tochter-Gatters) für
die Referenzen anstatt der Referenzen selbst zurückgeben. Der Client kann dann über das
Tochter-Gatter auf die Referenzen zugreifen. Das Tochter-Gatter
kann auch ein Methodengatter sein.
-
Wie
oben beschrieben ermöglicht
dieser entfernte Methodenaufruf, der von der verteilten Rechnerumgebung
bereitgestellt wird, daß das
reale Ergebnisobjekt oder die realen Ergebnisobjekte in einem Dienst-Ergebnis-Space
(der auch dynamisch kreiert werden kann, zum Beispiel von einem
Servlet) gespeichert werden. Der Ergebnis-Space kann temporär sein.
Der Ergebnis-Space kann als ein Cache zur Anfrage von Ergebnissen
fungieren. Der Ergebnis-Space kann von Server-Software (Garbage Collector) patrouilliert
werden, die alte Ergebnisbereiche bereinigt. Eine verteilte Garbage
Collection bzw. Speicherbereinigung kann eingesetzt werden, da bzw.
während
Ergebnis-Spaces
sich füllen
können,
bis sie von einem Client, der anzeigt, daß er den Space nicht mehr benötigt, oder
von einem Administrator auf dem Server, der geeignete Grenzwerte
setzt, gelöscht
werden.
-
In 23 ist eine Darstellung eines Standard-Space bzw.
Default-Space 350 wiedergegeben. Die verteilte Rechnerumgebung
kann mindestens einen Standard-Space bereitstellen, so daß Clients
einen anfänglichen
Satz von Annoncen finden können.
Eine Einrichtung kann einen Standard-Space mit einem eingebauten, vorab
eingerichteten Gatter haben, der lokal vorhanden ist. Die Dienste,
die in diesem Standard-Space angekündigt werden, können lokal
auf der Einrichtung existieren, und sie können Systemsoftware bereitstellen,
die eine Teilnahme der Einrichtung an der verteilten Rechnerumgebung
ermöglicht
oder erleichtert.
-
Der
Standard-Space 350 kann einen oder mehrere Mechanismen 352 umfassen,
um externe Spaces zu lokalisieren, wie in 23 dargestellt.
Ein Dienst in dem Standard-Space kann das oben beschriebene Protokoll
zum Auffinden von Spaces ausführen,
um externe Spaces zu finden. Ebenso können externe Spaces in dem
Standard-Space angekündigt
werden. Darüber
hinaus kann ein Dienst (z. B. eine Suchmaschine oder ein Proxy-Dienst
zu einer Suchmaschine) in dem Standard-Space angekündigt werden,
der externe Spaces ermittelt oder findet. Jeder Space kann analog
zu einem Anschlußpunkt
eines Dateisystems sein. Somit kann die verteilte Rechnerumgebung
durchsuchbare, dynamische Anschlußpunkte zu Diensten zur Verfügung stellen. Ein
Standard-Space kann
der anfängliche
Anschlußpunkt
eines Client zu der verteilten Rechnerumgebung sein.
-
Ein
Standard-Space oder der Zugriff auf einen Standard-Space kann in
einer Einrichtung eingebaut sein. Durch den Standard-Space und lokale
Dienste, die auf der Einrichtung vorhanden sind, kann eine Ausführungsumgebung
eines Client für
die verteilte Rechnerumgebung zur Verfügung gestellt werden. Die lokalen Dienste
einer Einrichtung und der Standard-Space-Dienst können eingebaute,
vorab eingerichtete Gatter haben. Einer der eingebauten Dienste,
die in dem Standard-Space
aufgelistet sind, kann ein Dienst sein, um das Auffindungsprotokoll
auszuführen,
so daß der
Client zusätzliche
(z. B. externe) Dienste lokalisieren kann. Ein Standard-Space kann
einen eingebauten Dienst beinhalten, der eine Ausführungsumgebung
für Clients
bereitstellt, die es einem Benutzer des Client ermöglicht,
die Spaces zu durchsuchen bzw. durchzublättern, Dienste auszuwählen und
dann zu instantiieren. Ein solcher Dienst kann eine einfache Benutzerschnittstelle
bereitstellen, die es einem Client ermöglicht, Zeichenketten (z. B.
Schlüsselwörter für das Suchen
nach Spaces) einzugeben, Ergebnisreferenzen (z. B. Auflistungen
von Spaces oder von Diensten innerhalb eines Space) zu betrachten
oder durchzublättern,
Gegenstände
bzw. Einheiten auszuwählen
(z. B. um einen Dienst auszuwählen und
zu instantiieren), etc.
-
Einrichtungen,
die in erster Linie einen Dienst bereitstellen, können auch
einen Standard-Space
und einen eingebauten Dienst in dem Standard-Space beinhalten, der
es einem Dienst ermöglicht,
seine eigene Annonce in verschiedenen Spaces zu verwalten. Zum Beispiel
kann eine Einrichtung wie ein Drucker einen eingebauten Standard-Dienst
haben, der (eventuell durch ein Auffindungsprotokoll) einen Space
auf einem lokalen Netzwerk findet und eine Annonce für den Druckerdienst
zu diesem Space hinzufügt.
Dieser Dienst kann auch die Annonce des Druckerdienstes innerhalb
des LAN-Space verwalten, zum Beispiel durch Erneuerung seiner Pacht
bzw. Überlassung
oder durch Aktualisierung des XML-Schemas des Druckers, etc.
-
Für einige
Einrichtungen, die einen Dienst bereitstellen, ist der Overhead
des Auffindens eines Space zur Annonce ihres Dienstes und zum Bereithalten
dieser Annonce nicht unerwünscht.
In einer Ausführungsform
können
Dienste auf einigen Einrichtungen ihre Annoncen als Reaktion auf
Verbindungsanforderungen übermitteln,
anstatt einen Space oder Spaces zu suchen und zu verwalten, um Dienstannoncen
zu veröffentlichen.
Zum Beispiel unterhält
eine Druckereinrichtung mit einem Druckerdienst, der auf Nachbarschaftsbasis verfügbar ist,
möglicherweise
keine Annonce in einem Space (auf der Einrichtung oder extern zu
der Einrichtung). Stattdessen kann der Druckerdienst die Dienstannonce übermitteln,
wenn eine andere Einrichtung eine Verbindung mit der Druckereinrichtung
aufbaut (zum Beispiel ein Benutzer mit einem Laptop, der einen Client ausführt, möchte ein
Dokument drucken), um das XML-Schema des Dienstes zum Herstellen
einer Verbindung mit dem Dienst und zum Ausführen des Dienstes zu übergeben,
der die Druckfunktionalität
auf der Druckereinrichtung zur Verfügung stellt. Einige Einrichtungen
können
auch nur Annoncen für
ihre Dienste in einer bestimmter Nähe bzw. Umgebung oder einem
lokalen Netzwerk unterhalten. Eine solche Einrichtung möchte möglicherweise
keinen Zugang unterstützen
oder hat möglicherweise
keinen Zugang zu Transportmitteln für eine breitere Zugangsmöglichkeit.
-
Ein
Beispiel einer Diensteinrichtung, in der es für die Einrichtung wünschenswert
sein kann, das Beibehalten von Dienstannoncen in einem Space zu
vermeiden oder zu begrenzen, ist eine Einrichtung, deren Funktionalität auf Nachbarschaftsbasis
verfügbar
ist. Auf Nähe
beruhende Dienste können
Annoncen ihrer Funktionalität
auf Anforderung bereitstellen. Diese Annoncen sind möglicherweise
nicht allgemein zugänglich. Zum
Beispiel können
auf Nähe
beruhende Dienste in einem drahtlosen Kommunikationssystem zur Verfügung gestellt
werden. Der Begriff "drahtlos" kann sich auf ein
System zur Kommunikation, Überwachung
oder Steuerung beziehen, in dem elektromagnetische oder akustische
Wellen ein Signal durch den atmosphärischen Raum anstatt entlang
eines Drahtes übertragen.
In den meisten drahtlosen Systemen werden Funk- (Radio Frequency,
RF) oder Infrarot-(IR) Wellen verwendet. Typischerweise muß in einem
auf Nähe
beruhenden drahtlosen System eine Einrichtung, die einen Sende-/Empfänger bzw.
Transceiver aufweist, innerhalb der Reichweite (Nähe) einer
anderen Einrichtung sein, um einen Kommunikationskanal aufzubauen
und aufrecht zu halten. Eine Einrichtung kann ein Netzknoten bzw.
Hub sein, um andere Einrichtungen mit einem drahtlosen lokalen Netzwerk
(Local Area Network, LAN) zu verbinden.
-
Wie
bereits erwähnt
können
Ausführungsformen
der verteilten Rechnerumgebung einen Mechanismus unter Verwendung
eines Such-Space zur Verfügung
stellen, der es Clients ermöglicht,
mit Diensten in Kontakt zu treten. In einer nachbarschaftsbezogen
Rechnerumgebung kann eine Ausführungsform
der verteilten Rechnerumgebung einen Mechanismus zum Auffinden von
Diensten bereitstellen, den Clients verwenden können, um Dienste zu finden,
ohne Such-Spaces als Treffpunkte zu benutzen. Ein Beispiel einer
nachbarschaftsbezogen Rechnerumgebung ist eine IrDA-Punkt-zu-Punkt-Kommunikationsumgebung.
In einer nachbarschaftsbezogen Rechnerumgebung kann der Nachbarschaftsmechanismus
den "physikalischen" Standort des Dienstes
für den
Client finden. Zum Beispiel kann in einer IrDA-Umgebung bei der
Einrichtung, die den Dienst oder die Dienste enthält, die
der Client verwenden möchte,
physikalisch bzw. räumlich
auf die Clienteinrichtung gezeigt werden.
-
Der
Mechanismus zum Auffinden von Diensten in der Nähe kann es dem Client ermöglichen,
direkt nach Dienstannoncen zu suchen, anstatt eine Suchanforderung
an einen Such-Space zu senden, um nach Dienstannoncen zu suchen.
Da die Clienteinrichtung eine Nachbar- bzw. Nachbarschaftsverbindung
zu der Diensteinrichtung aufgebaut haben kann, kann der Client direkt
den gewünschten
Dienst anfordern. Zum Beispiel kann eine PDA-Clienteinrichtung eine
Nachbarschaftsverbindung zu einer Druckereinrichtung aufbauen; der
Client "weiß" möglicherweise,
wie eine Verbindung zu einem Druckdienst auf der Druckereinrichtung
anzufordern ist.
-
In
einer Ausführungsform
kann der Client eine Nachricht zum Auffinden eines Dienstes in der
Nähe an die
Diensteinrichtung senden. Die Nachricht kann Information beinhalten,
die einen gewünschten
Dienst auf der Diensteinrichtung spezifiziert, zu der die Clienteinrichtung
eine Nachbarschaftsverbindung hat. In einer Ausführungsform kann ein Dienst
auf der Diensteinrichtung auf die Nachricht zum Auffinden eines
Dienstes in der Nähe
antworten und eine Dienstannonce an den Client senden, die der Client
verwenden kann, um mit dem gewünschten
Dienst Verbindung aufzunehmen. Die Nachricht zum Auffinden eines
Dienstes in der Nähe kann
auch Information beinhalten, die verwendet werden kann, um den Client
zu authentisieren und die Leistungsmerkmale des Client auf dem Dienst
einzurichten. Unter Verwendung der empfangenen Dienstannonce kann
der Client ein Gatter einrichten, um eine Kommunikation mit dem
gewünschten
Dienst aufzubauen.
-
Gleichwohl
kann es immer noch wünschenswert
sein, Annoncen für
Dienste zu veröffentlichen,
die ihre Annoncen nicht in einem Space, der allgemein zugänglich ist,
unterhalten möchten
oder können.
In einer Ausführungsform
einer verteilten Rechnerumgebung kann eine Einrichtung, die eine
Verbindung mit einer Einrichtung aufbaut, die ihre Dienstannonce(en)
nicht veröffentlicht
wie eine nachbarschaftsbezogene Einrichtung, Dienstannoncen veröffentlichen,
die sie von der nicht veröffentlichenden
Einrichtung empfangen hat. Zum Beispiel kann eine Einrichtung, die
eine Verbindung mit einer nachbarschaftsbezogenen Einrichtung aufbaut
und eine alternative Transportverbindung oder Transportverbindungen
hat, Dienstannoncen, die sie von der nachbarschaftsbezogenen Einrichtung
empfangen hat, in der alternativen Transportumgebung veröffentlichen
(oder erneut veröffentlichen),
um es dadurch zu ermöglichen,
daß der
Dienst oder die Dienste der nachbarschaftsbezogenen Einrichtung
von anderen Einrichtungen (durch die (erneut) veröffentlichten
Dienstannoncen), die außerhalb
des Nachbarschaftsbereiches der Einrichtung liegen, benutzt werden
kann.
-
Die
veröffentlichende
Einrichtung kann eine lokal veröffentlichte
Dienstannonce für
die nachbarschaftsbezogene Einrichtung mit einem Auffindungs- und/oder
Nachschlagedienst lokalisieren, oder alternativ kann die Dienstannonce
von der lokalen Diensteinrichtung nicht veröffentlicht werden, sondern
stattdessen von der lokalen Einrichtung beim Aufbau einer Verbindung
an die veröffentlichende
Einrichtung gesendet werden, wie oben beschrieben. In einer Ausführungsform
kann die erneut veröffentlichte
Dienstannonce solange verfügbar
gemacht werden, wie die Einrichtung, die die Annonce unterhält, mit
der lokalen Einrichtung verbunden ist oder in der Lage ist, mit
der lokalen Einrichtung Verbindung aufzunehmen. Wenn zum Beispiel
die Verbindung der veröffentli chenden
Einrichtung mit der lokalen Einrichtung getrennt wird (zum Beispiel
diese sich aus dem Nachbarschaftsbereich der Einrichtung heraus
bewegt), kann die Dienstannonce als abgelaufen markiert oder gelöscht werden.
Ein Überlassungs-
bzw. Pachtmechanismus kann vorgesehen werden, um es dem Space, der
die Annonce enthält,
zu ermöglichen,
Nachrichten zur Erneuerung der Überlassung
an die veröffentlichende
Einrichtung zu senden. Die veröffentlichende
Einrichtung kann ihre Verbindung zu der lokalen Einrichtung überprüfen und
es damit dem Space ermöglichen
herauszufinden, wenn die lokale Einrichtung nicht mehr verfügbar ist.
Regeln darüber,
wie die Dienstannoncen erneut veröffentlicht werden, können von
der lokalen Einrichtung oder von einer Verwaltungsrichtlinie für die lokale
Nachbarschaft (z. B. den Nachbarschaftsbereich) oder das lokale
Netzwerk vorgesehen werden.
-
24 stellt ein Beispiel einer Einrichtung dar,
die für
nachbarschaftsbezogene Einrichtungen eine Brücke zu einem anderen Transportmechanismus
herstellt, um zu ermöglichen,
daß auf
die von den nachbarschaftsbezogenen Einrichtungen bereitgestellten
Dienste von Einrichtungen außerhalb
des Nachbarschaftsbereiches der Einrichtungen gemäß einer
Ausführungsform
zugegriffen werden kann. Eine veröffentlichende Einrichtung 1404 kann
mit einem Netzwerk 1412 wie einem Ethernet-LAN oder dem
Internet etc. verbunden sein und kann Nachbarschaftsverbindungen 1414 mit
nachbarschaftsbezogenen Einrichtungen 1400 und 1402 aufbauen
und aufrecht erhalten. Die Nachbarschaftsverbindungen können zum
Beispiel drahtlose Verbindungen oder LAN-Drahtverbindungen sein. Die nachbarschaftsbezogenen
Einrichtungen 1400 und 1402 können jeweils beim Verbindungsaufbau
eine Dienstannonce an die veröffentlichende
Einrichtung 1404 senden, oder die veröffentlichende Einrichtung kann
alternativ die Dienstannoncen mittels eines Auffindungs- und/oder
Nachschlagedienstes für
die Nachbarschaftsverbindungen lokalisieren. Die veröffentlichende
Einrichtung 1404 kann daraufhin die von den nachbarschaftsbezogenen
Einrichtungen bereitgestellten Dienste anderen Einrichtungen 1408 und 1410 auf
dem Netzwerk 1412 verfügbar
machen, indem sie die Dienstannoncen 1416 und 1418 in
dem Space 1406 veröffentlicht.
Der Space 1406 kann auf der veröffentlichenden Einrichtung
oder auf anderen Einrichtungen, die mit dem LAN verbunden sind (einschließlich der
Einrichtungen 1408 und 1410), gespeichert sein.
-
Andere
Einrichtungen auf dem LAN einschließlich der Einrichtungen 1408 und 1410 können daraufhin den
Space 1406 auffinden und die erneut veröffentlichten Dienstannoncen 1416 und 1418 für die nachbarschaftsbezogenen
Einrichtungen durchsuchen, Gatter einrichten, um mit diesen Diensten
auf den nachbarschaftsbezogenen Einrichtungen 1400 und 1402 mittels
der früher
beschriebenen Methoden zur Übergabe
von XML-Nachrichten zu kommunizieren (Einrichtung 1404 kann
als ein Proxy oder eine Bridge dienen), und Anforderungen an die
nachbarschaftsbezogenen Einrichtungen senden und Ergebnisse von
ihnen in Empfang nehmen. Die veröffentlichende
Einrichtung 1404 kann als eine Bridge zwischen dem Netzwerk 1412 und
den Nachbarschaftsverbindungen 1414 zu den nachbarschaftsbezogenen
Einrichtungen dienen.
-
Überlassungen bzw. Pachten
-
Überlassungen
(Leasing) können
in der verteilten Rechnerumgebung verwendet werden, um mit teilweisem
Ausfall, Synchronisation von Ressourcen (Zeitplanung bzw. Scheduling)
umzugehen und für
einen ordnungsgemäßen Vorgang
zum Aufräumen
von Ressourcen zu sorgen. Überlassungen
können
das gesamte verteilte System dabei unterstützen, unabhängige Clients und Dienste,
die kommen und gehen können,
zu verwalten. Die verschiedenen Ressourcen, die Clients von Diensten
(einschließlich
Space-Diensten) erhalten, können
von diesen Diensten überlassen
werden. Im allgemeinen kann oder braucht nicht jede Ressource überlassen
(zu) werden. In einer Ausführungsform
ist es Sache der Implementierung jedes einzelnen Dienstes festzulegen,
welche seiner Ressourcen überlassen
bzw. gepachtet werden müssen.
Insbesondere brauchen Ressourcen, die von einer großen Zahl
von Clients gleichzeitig verwendet werden, möglicherweise nicht überlassen
zu werden oder erfordern stattdessen angepaßte Überlassungsprotokolle. Diese
Klasse von Überlassung
kann dem Dienstanbieter überlassen
sein. Angepaßte
Protokolle wie zum Beispiel diejenigen zum Implementieren von Transaktionen
können
auf dem grundlegenden Überlassungsschema
bzw. -system aufgebaut werden. In einer Ausführungsform ist das grundlegende Überlassungsmodell
ein relatives Modell auf Zeitbasis.
-
Dienste
können Überlassungen
an Clients herausgeben und Operationen auf diesen Überlassungen zur
Verfügung
stellen. In einer Ausführungsform
ist die gesamte derartige Funktionalität eines Dienstes zur Überlassung
Teil des XML-Schemas dieses Dienstes. Somit kann ein Client sein
Gatter (das dem Dienst entspricht und für das XML-Schema des Dienstes
eingerichtet ist) verwenden, um Überlassungsoperationen durchzuführen. In
einer Ausführungsform
stellen alle Dienste, die Überlassungen
herausgeben, die folgenden Überlassungsoperationen
(nur möglich
für die
Besitzer der Überlassung)
bereit: (i) Erneuern einer Überlassung
(angegebene Parameter: Überlassung
(z. B. Überlassungs-ID, Überlassungsnachweis),
neue angeforderte Überlassungszeit
bzw. -dauer), und (ii) Streichen bzw. Löschen einer Überlassung
(angegebene Parameter: Überlassung
(z. B. Überlassungs-ID, Überlassungsnachweis)).
In einer Ausführungsform
werden alle Überlassungen
für eine
bestimmte relative Zeitspanne (Dauer der Überlassung) gewährt, die
ausgehandelt werden kann. Der Anforderer kann eine bestimmte Zeitspanne
(z. B. in Sekunden) angeben, und der Geber bzw. Gewährende kann
die Überlassung
für jede
Dauer bis zu dieser Zeitspanne gewähren. In einer Ausführungsform
kann ein Wert von –1
verwendet werden, um eine unbestimmte Überlassung anzugeben.
-
In
einer Ausführungsform
kann eine Dienstannonce eine oder mehrere Überlassungsadressen beinhalten.
In einer Ausführungsform
können
die Überlassungsadressen
URIs sein. Standardüberlassungsnachrichten
zum Erneuern und Löschen
von Überlassungen
von Dienstressourcen können
an einen Überlassungs-URI
gesendet werden. Ein Beispiel für
einen Überlassungs-URI:
<leaser>service1://resource1</leaser >
-
Eine
Annonce kann auch verschiedene Überlassungsnachrichten
wie oben beschrieben beinhalten. Überlassungsnachrichten können Nachrichten
zum Erneuern und Löschen
von Überlas sungen
für Ressourcen
des Dienstes beinhalten. In einer Ausführungsform können die
Nachrichten in einem XML-Schema in der Annonce enthalten sein.
-
Der Überlassungsmechanismus
kann einen Mechanismus zum Erkennen eines Dienst- und Client-Ausfalls
bereitstellen. Überlassungen
können
auch einen Mechanismus vorsehen, um gemeinsam genutzten und exklusiven
Zugriff auf Ressourcen zur Verfügung
zu stellen. In einer Ausführungsform
haben alle Dienstressourcen entweder keine Überlassung (Ressource ist nicht überlassen
und daher verfügbar),
eine gemeinsam genutzte Überlassung
(auf Ressource wird von mehreren Clients zugegriffen) oder eine
exklusive Überlassung
(auf Ressource wird zu einem Zeitpunkt genau von einem Client zugegriffen).
In einer Ausführungsform
sind alle Ressourcen zu Anfang im Zustand "keine Überlassung". Ein Zustand "keine Überlassung" zeigt an, daß es keinen aktuellen Zugriff
zu der darunterliegenden Ressource gibt, und weist darauf hin, daß ein Interesse
besteht, daß die
Ressource vorhanden und somit für
eine Überlassung
verfügbar
bleibt. Die Stufe der Überlassung
kann von "keine" zu "gemeinsam genutzt", "keine" zu "exklusiv" oder "gemeinsam genutzt" zu "exklusiv" erhöht werden.
Stufen der Trennung bzw. Isolation von Überlassungen können ebenso
von "exklusiv" zu "gemeinsam genutzt", "exklusiv" zu "keine" und "gemeinsam genutzt" zu "keine" herabgesetzt werden.
In einer Ausführungsform
können
Clients die Stufe der Isolation von Überlassungen freiwillig erhöhen oder
herabsetzen oder können
vom Dienst dazu aufgefordert werden, dies zu tun. Eine Antwortnachricht
von dem Dienst kann anzeigen, ob die Änderung der Stufe der Isolation
akzeptiert wurde.
-
Paare
von Anforderungs-Antwortnachrichten können eingesetzt werden, um
eine Überlassung
zu verlangen bzw. zu beanspruchen, freizugeben und zu erneuern.
Jede Nachricht kann mittels eines reservierten XML-Tag gekennzeichnet
werden, um anzuzeigen, daß die
Nachricht eine Überlassungsnachricht
ist. Die verteilte Rechnerumgebung definiert nicht notwendigerweise
die vollständige
Zusammensetzung der Nachricht. In einer solchen Ausführungsform
können
Entwickler von Diensten angepaßten
Nachrichteninhalt anhängen, so
lange die Nachricht als eine Überlassungsnachricht
gekennzeichnet ist.
-
In
einer Ausführungsform
kann von Clients, die überlassene
Ressourcen verwenden, erwartet werden: (i) die Ressource als gemeinsam
genutzt oder exklusiv anzufordern, (ii) die Beanspruchung der Ressource
freizugeben (wenn sie dazu aufgefordert werden oder mit der Ressource
fertig sind) und (iii) auf Erneuerungsnachrichten zu antworten (mit
einer weiteren Anforderung auf derselben oder einer anderen Isolationsstufe). Erneuerungsnachrichten
können
von Diensten gesendet werden (z. B. in gleichmäßigen Intervallen), um Ausfälle eines
Client zu entdecken. Das Intervall (in dem die Erneuerungsnachricht
gesendet wird) kann dienstspezifisch sein. Wenn eine Antwort auf
die Erneuerungsnachricht nicht nach einer spezifischen Zeitspanne ausgegeben
wird (z. B. basierend auf einer Zeit(dauer), die in der Dienstannonce
vermerkt ist), kann bei dem Dienst ein Vorgang zur Rückforderung
der Ressource beginnen, der die Überlassung
vollständig
für nichtig
erklärt
bzw. widerruft. Nach einer solchen Ausführungsform sollten an Clients
gesendete Erneuerungsnachrichten rechtzeitig behandelt werden. 25 veranschaulicht die Verwendung von Erneuerungsnach richten
sowohl zwischen einem Client und einem instantiierten Dienst als
auch zwischen einem Dienstanbieter und einem Space-Dienst. Man beachte,
daß beide
Fälle als
die Verwendung von Erneuerungsnachrichten zwischen einem Client
und einem Dienst betrachtet werden können, da ein Dienstanbieter
gegenüber
dem Annoncendienst eines Space ein Client sein kann.
-
Erneuerungs-
bzw. Verlängerungsnachrichten
können
in einer "Band-externen" bzw. "Out-of-Band" Weise ankommen,
die für
den Client unbequem bzw. ungewöhnlich
zu behandeln ist. Das bedeutet, der Client kann nicht vorhersehen,
wann eine Erneuerungsnachricht von dem Dienst gesendet wird. Die
Behandlung von Band-externen Nachrichten kann die Logik des Client
verkomplizieren und ihre Komplexität erhöhen. Um dieses Problem zu lösen, kann
ein automatischer Mechanismus zur Erneuerung von Überlassungen
implementiert werden, um den Client von der Verantwortung der Behandlung
von Band-externen Nachrichten zu befreien und damit die Komplexität des Client
zu reduzieren. In dem automatischen Mechanismus zur Erneuerung von Überlassungen
kann jedes Gatter (Nachrichten-. Methoden- und/oder Ereignisgatter)
Erneuerungsnachrichten empfangen und auf sie automatisch ohne Hilfe
des Client antworten. Die Standardantwort auf eine Erneuerungsnachricht
ist, die Überlassung
auf ihrer aktuellen Stufe anzufordern. Jedes Nachrichtengatter kann eine
einzelne, zurückgestellte
Antwort auf eine Erneuerungsnachricht enthalten, die automatisch
an den Annoncen-Space-Dienst gesendet wird, wenn das Gatter die
Erneuerungsnachricht empfängt.
Diese "Band-externe" Nachricht wird im
Namen des Client behandelt, was ein saubereres Programmiermodell
des Client ergibt. In einer Ausführungsform
kann das Gatter es Clients ermöglichen,
eine Behandlungsroutine für Überlassungsereignisse
zu registrieren, um verschiedene Isolationsstufen in der Antwortnachricht
anzugeben.
-
Standard-Überlassungsnachrichten
können
in der verteilten Rechnerumgebung definiert sein. In einer Ausführungsform
können
zusätzliche Überlassungsnachrichten
durch angepaßte Überlassungsmodelle
definiert werden. In einer Ausführungsform
kann jeder Dienst, der Überlassungen
herausgibt, einen URI angeben, an den Nachrichten zur Erneuerung
und zum Löschen
von Überlassungen
gesendet werden können. Überlassungsnachrichten
können
eingebettete Berechtigungsnachweise enthalten, um den Sender der
Nachricht zu authentisieren. In einer Ausführungsform kann ein Client
den Berechtigungsnachweis (z. B. einen Authentisierungsnachweis)
von einem Authentisierungsdienst bei der Instantiierung des Dienstes
und den Berechtigungsnachweis in Nachrichten einbetten, die er an
den Dienst sendet. In einer Ausführungsform
kann der Authentisierungsdienst in der Dienstannonce für den Dienst
angegeben worden sein. Der Dienst kann dann den Berechtigungsnachweis
authentisieren, wenn er in einer Nachricht von dem Client empfangen
wird. In einer Ausführungsform
kann der Dienst den Berechtigungsnachweis, wenn er zum ersten Mal
empfangen wurde, an denselben Authentisierungsdienst senden, der
von dem Client verwendet wurde, um den Berechtigungsnachweis zu
erzeugen. Somit kann das Ausgeben und Einbetten von Berechtigungsnachweisen
in Überlassungsnachrichten
verwendet werden, um für
eine sichere Überlassungsumgebung
zu sorgen. Zum Beispiel kann das Einbetten eines Berechtigungsnachweises
in einer Nachricht zum Löschen
einer Überlassung
effektiv verhindern, daß irgend
jemand au ßer
dem autorisierten, durch Berechtigung ausgewiesenen Client (und
dem Dienst, der die Überlassung
ausgibt) die Überlassung
löscht.
Siehe den Abschnitt "Authentisierung
und Sicherheit" zu
weiteren Einzelheiten.
-
44 ist ein Flußdiagramm, das einen Mechanismus
zur Überlassung
von Ressourcen darstellt. In Schritt 2000 kann ein Client
eine Überlassung
einer Ressource anfordern, die von einem Dienst bereitgestellt wird.
In einer Ausführungsform
erfolgen Überlassungen
möglicherweise
auf Zeitbasis, d. h. sie werden dem Client für eine Zeitspanne gewährt. In
einer anderen Ausführungsform
erfolgen Überlassungen
möglicherweise
nicht auf Zeitbasis und bleiben erhalten, bis sie von dem Client
oder dem Dienst gelöscht
werden. In einer Ausführungsform
kann der Dienst ein Space-Dienst
sein, und die Ressource kann eine Dienstannonce für einen
anderen Dienst sein und dem Client von dem Space-Dienst überlassen
werden. In einer Ausführungsform kann
der Dienst ein Space-Dienst sein, der Client kann selbst ein Dienst
sein, und die Ressource kann die Veröffentlichung einer Dienstannonce
durch den Space-Dienst im Namen des Client/Dienstes sein. In einer
Ausführungsform
kann der Client eine Anforderungsnachricht an den Dienst senden,
die die Ressource angibt und die Überlassung der Ressource anfordert.
In einer Ausführungsform
kann die Nachricht eine angeforderte Überlassungsdauer spezifizieren.
In einer Ausführungsform
kann ein Nachrichtengatter im Client die Nachricht zur Anforderung
einer Überlassung
im Namen des Client an den Dienst senden. In einer Ausführungsform kann
die Nachricht zur Anforderung einer Überlassung eine XML-Nachricht
sein.
-
In
Schritt 2002 kann der Dienst die Überlassung der Ressource dem
Client gewähren.
In einer Ausführungsform
kann der Dienst eine Nachricht zur Anforderung einer Überlassung
von dem Client empfangen. Der Dienst kann daraufhin die Überlassung
der Ressource gewähren.
In einer Ausführungsform
kann die Nachricht zur Anforderung einer Überlassung eine angeforderte Überlassungsdauer
enthalten. In einer Ausführungsform
kann der Dienst die Überlassung
für eine
gewährte Überlassungsdauer
kleiner oder gleich der angeforderten Überlassungsdauer einräumen. In
einer Ausführungsform
kann die angeforderte Überlassungsdauer
für eine
unbestimmte Überlassung
(d. h. die Zeitspanne läuft
nicht ab) sein. In dieser Ausführungsform muß der Client
oder der Dienst die Überlassung
löschen,
da die Überlassung
selbst nicht abläuft.
-
Die
dem Client zur Verfügung
gestellte Dienstannonce kann bei der Einrichtung einer anfänglichen Überlassung
einer Ressource oder von Ressourcen verwendet werden, die von dem
Dienst bereitgestellt und von dem Client während des Zugriffs auf den
Dienst angefordert werden. In einer Ausführungsform kann die Überlassung
der Ressource zum Zeitpunkt der Instantiierung des Dienstes gewährt werden.
In dieser Ausführungsform
sendet der Client womöglich
keine Nachricht zur Anforderung einer Überlassung an den Dienst senden,
um die Überlassung
anzufordern. In dieser Ausführungsform
kann der Dienst eine anfängliche Überlassung
der Ressource oder der Ressourcen an den Client gewähren, wenn
er aus der Dienstannonce instantiiert wird. Zum Beispiel kann ein
Space-Dienst als Reaktion auf eine Anforderungsnachricht von einem
Client einen Dienst aus einer Dienstannonce auf dem Space-Dienst
instantiieren. Der Dienst kann die Überlassungen an den Client
für eine
oder mehrere von dem Dienst bereitgestellten Ressourcen gewähren, wenn
er instantiiert wird, ohne es erforderlich zu machen, daß der Client
explizit eine Nachricht sendet, die die Überlassungen anfordert.
-
In
Schritt 2004 kann der Client eine Erneuerung der Überlassung
anfordern. In einer Ausführungsform kann
der Dienst eine Anforderungsnachricht zur Erneuerung einer Überlassung
an den Client senden. In einer Ausführungsform kann die Anforderungsnachricht
zur Erneuerung einer Überlassung
vor dem Ablauf des zuvor gewährten Überlassungszeitraumes
an den Client gesendet werden. Der Client kann auf die Nachricht
dem Dienst mit einer Antwortnachricht zur Erneuerung einer Überlassung
antworten, die eine Erneuerung der Überlassung anfordert. In einer
Ausführungsform,
die Überlassen
auf Zeitbasis verwendet, kann die Antwortnachricht zur Erneuerung
einer Überlassung
eine angeforderte Überlassungszeitspanne
enthalten. In einer anderen Ausführungsform,
die nicht-zeitbasiertes Überlassen
verwendet, kann die Antwortnachricht zur Erneuerung einer Überlassung
anfordern, daß die Überlassung
fortgesetzt wird. In einer Ausführungsform
kann der Client eine Antwortnachricht zur Erneuerung einer Überlassung
zurückgeben,
die den Dienst darüber
in Kenntnis setzt, daß die Überlassung
nicht weiter benötigt
wird. In einer Ausführungsform
sendet der Client möglicherweise
keine Antwortnachricht zur Erneuerung einer Überlassung, und der Dienst
könnte
annehmen, wenn er keine Antwortnachricht empfängt, daß der Client die Überlassung
nicht weiter benötigt.
Zum Beispiel kann der Client vom Netzwerk getrennt worden sein.
Dies versorgt den Dienst mit einem Mechanismus zum Entdecken nicht
verwendeter Überlassungen
und zur Bereinigung von Ressourcen einschließlich Überlassungsressourcen.
-
In
einer Ausführungsform
sendet der Dienst möglicherweise
keine Anforderungsnachricht zur Erneuerung einer Überlassung
an den Client. In dieser Ausführungsform
kann der Client stattdessen eine gewährte Überlassungszeitspanne überwachen und eine Nachricht
zur Erneuerung der Überlassung
an den Dienst senden, bevor die gewährte Überlassungszeitspanne abläuft. Die
Nachricht zur Erneuerung der Überlassung
kann die Ressource angeben, die überlassen
wird, und eine angeforderte, neue Überlassungszeitspanne für die Überlassung
der Ressource. In einer Ausführungsform
kann die angeforderte Überlassungszeitspanne
für eine
unbestimmte Überlassung
(d. h. die Zeitspanne läuft
nicht ab) vorgesehen sein. Wenn der Client die Überlassung nicht mehr wünscht, braucht
der Client kein Erneuerungsnachricht zu senden und kann dadurch
die Überlassung
aufgeben.
-
In
einer Ausführungsform
kann ein Nachrichtengatter des Client die Erneuerung von Überlassungen im
Namen des Clientprozesses behandeln, wodurch der Clientprozeß von der
Verantwortung, das Aufrecht-Erhalten von Überlassungen zu behandeln,
freigestellt wird. In einer Ausführungsform
kann das Nachrichtengatter des Client automatisch auf von dem Dienst
gesendete Anforderungsnachrichten zur Erneuerung einer Überlassung
antworten. In einer Ausführungsform
kann eine Standard-Antwortnachricht zur Erneuerung von Überlassungen
in ein Gatter kompiliert werden und automatisch an den Dienst gesendet
werden, wenn das Gatter die Anforderungsnachricht zur Erneuerung
einer Überlassung
empfängt.
In einer anderen Ausführungsform
sendet der Dienst möglicherweise
keine Anforderungsnachrichten zur Erneuerung einer Überlassung.
In dieser Ausführungsform
kann das Clientgatter automatisch Nachrichten zur Erneuerung einer Überlassung senden.
In einer Ausführungsform
kann das automatische Senden periodisch durchgeführt werden. In einer Ausführungsform
kann das Clientgatter eine aktuell gewährte Überlassungszeitspanne überwachen
und kann eine Nachricht zur Erneuerung einer Überlassung senden, bevor die
aktuell gewährte Überlassungszeitspanne abläuft.
-
In
einer Ausführungsform
kann eine Überlassung
auf einer von mehreren Zugangsstufen einschließlich exklusivem Zugang und
gemeinsam genutztem Zugang vorliegen. Exklusiver Zugang gibt dem
Client exklusive Rechte auf die Ressource, indem sie während der
Dauer der Überlassung
anderen Clients den Zugang zu der Ressource verbietet. Gemeinsam
genutzter Zugang gibt anderen Clients das Recht, dieselbe Ressource
wie der Client zeitgleich überlassen
zu bekommen, das heißt
eine Überlassung
der Ressource zu erhalten, die die Zeitspanne der von dem Client
gehaltenen Überlassung überlappt.
In einer Ausführungsform
kann der Client eine Überlassung
auf einer Zugangsstufe halten und eine Nachricht zur Erneuerung
der Überlassung senden,
die die Überlassung
auf einer anderen Zugangsstufe anfordert.
-
In
Schritt 2006 kann der Dienst im Anschluß an den Empfang einer Nachricht
zur Erneuerung der Überlassung
von dem Client eine Erneuerung der Überlassung der Ressource dem
Client gewähren.
Die Nachricht zur Erneuerung der Überlassung kann als Antwort
auf eine Nachricht zur Anforderung der Erneuerung einer Überlassung,
die von dem Dienst an den Client gesendet wurde, gesendet worden
sein oder kann automatisch vom Client vor Ablauf einer zuvor gewährten Überlassungszeitspanne
gesendet worden sein. In einer Ausführungsform kann die Überlassung
für eine
eingeräumte Überlassungszeitspanne
gewährt
werden. In einer Ausführungsform
kann die Nachricht zur Erneuerung einer Überlassung eine Erneuerungszeitspanne der Überlassung
anfordern. In einer Ausführungsform
kann die gewährte Überlassungszeitspanne
kleiner oder gleich der angeforderten Überlassungszeitspanne sein.
In einer Ausführungsform
kann der Dienst die Anforderung der Erneuerung der Überlassung
von dem Client ablehnen. Zum Beispiel kann der Client eine maximale,
kumulierte Überlassungszeitdauer überschritten
haben oder ein anderer Client kann einen exklusiven Überlassungszugang
zu der Ressource anfordern. In einer Ausführungsform kann der Dienst
die Überlassung
für weniger
als die angeforderte Überlassungszeitspanne
gewähren.
In einer Ausführungsform
kann der Dienst eine Nachricht an den Client senden, um den Client
zu informieren, ob die Überlassung
erneuert wurde. In einer Ausführungsform
kann die Nachricht die gewährte Überlassungszeitspanne
enthalten.
-
In
Schritt 2008 kann der Client eine Nachricht an den Dienst
senden, die die Löschung
der Überlassung
anfordert. Die Nachricht kann die Ressource angeben, für die der
Client eine Überlassung
hält, die
gelöscht
werden soll. In Schritt 2010 kann der Dienst die Überlassung
löschen.
Der Dienst kann die Überlassung als
Reaktion auf den Empfang einer Anforderungsnachricht zur Löschung einer Überlassung
löschen,
wie in Schritt 2008 beschrieben. In einer Ausführungsform
kann der Dienst die Überlassung
auch löschen,
wenn eine gewährte Überlassungszeitspanne
abläuft, ohne
eine Nachricht zur Erneuerung der Überlassung vom Client zu empfangen.
Der Dienst kann die Überlassung
auch aus einer Vielzahl von anderen Gründen löschen. Zum Beispiel kann ein
anderer Client exklusiven Zugang zu der Ressource anfordern, oder
die Ressource kann nicht mehr verfügbar sein. In einer Ausführungsform
kann der Dienst eine Nachricht an den Client senden, um ihn zu informieren,
daß die Überlassung
gelöscht
wurde.
-
In
einer Ausführungsform
kann ein Sicherheitsnachweis wie ein unten beschriebener Authentisierungsnachweis
in den Überlassungsnachrichten
enthalten sein, die zwischen dem Client und dem Dienst, wie in 44 beschrieben, gesendet werden. Zum Beispiel
kann der Client den Sicherheitsnachweis in den Nachrichten zur Erneuerung
einer Überlassung
und zum Anfordern der Löschung
einer Überlassung,
die an den Dienst gesendet werden, einbetten. Der Dienst kann beim
Empfang einer Nachricht den Berechtigungsnachweis untersuchen, um
zu überprüfen, daß er von
dem Halter der Überlassung
stammt, um damit die Authentizität
der Nachricht zu überprüfen. Dies
sorgt für
Sicherheit in dem Überlassungsmechanismus,
indem Einheiten, die nicht die richtigen Berechtigungsnachweise
besitzen, daran gehindert werden, die aktuelle(n) Überlassung(en)
des Clients beim Dienst zu ändern.
-
In
einer Ausführungsform
können
die Überlassungsnachrichten,
die zwischen dem Client und dem Dienst gesendet werden, alle in
einer Datenrepräsentationssprache
vorliegen. In einer Ausführungsform
kann die Datenrepräsentationssprache
die eXtensible Markup Language (XML) sein. In einer Ausführungsform
können
alle Nachrichten von einem Nachrichtengatter des Dienstes und einem
Nachrichtengatter des Client gesendet und empfangen werden. In einer
Ausführungsform
können
die Überlassungsnachrichten
in einem XML-Nachrichtenschema beschrieben sein, das dem Client
zur Verfügung
gestellt wird und verwendet wird, um das Nachrichtengatter des Client
einzurichten. In einer Ausführungsform
kann das XML-Nachrichtenschema von dem Client in einer Dienstannonce
beschafft werden, z.B. von einem Space-Dienst geholt werden.
-
Der Überlassungsmechanismus
kann auch einen Mechanismus vorsehen, um veraltete bzw. abgelaufene
Annoncen zu entdecken. Wenn ein Dienst seine Annoncen in einem Space
veröffentlicht,
erhält
dieser Dienst eine Überlassung
dieser Veröffentlichung
seiner Annoncen. Jede Annonce kann eine Zeit enthalten, zu der der
Dienst zusagt, die Annonce zu erneuern. In einer Ausführungsform
werden alle Zeitüberwachungswerte
in Sekunden angegeben. Wenn der Dienst fortfährt, seine Überlassung zu erneuern, erhält der Space
eine bestimmte Zusicherung, daß der
angekündigte
Dienst immer noch angeboten wird. Die Erneuerungszeit kann von dem
Space-Dienst bis auf Null heruntergezählt werden. Wenn der Dienst
seine Überlassung
nicht erneuert, kann der Dienst ausgefallen sein oder er kann nicht
länger
wünschen
oder in der Lage sein, den Dienst bereitzustellen. Wenn die Überlassung
nicht erneuert wird, markiert der Space-Dienst die Dienstannonce
als abgelaufen, so daß er
sie Clients nicht verfügbar
macht. Dienste erneuern Annoncen, indem sie eine Erneuerungsnachricht
an den Space senden. Der Space-Dienst empfängt diese Nachrichten und setzt
die Erneuerungszeit für
die Annonce auf ihren Anfangswert zurück.
-
In
einer Ausführungsform
werden abgelaufene Annoncen nicht automatisch gelöscht. Abhängig von den
Richtlinien des Space kann dieser entscheiden, ob er abgelaufene
Dienstannoncen löscht,
die bereits eine angemessen lange Zeitspanne abgelaufen sind. Die
Richtlinie für
das Löschen
kann durch den Space-Dienst festgelegt werden. Der Space-Dienst
kann nach abgelaufenen Annoncen suchen und sie entweder löschen oder
sie zum Beispiel einem Administrator zur Kenntnis bringen.
-
Ein
Space-Dienst kann Überlassungen
verwenden, um die Ressourcen seiner Einrichtungen, die Clients des
Space (einschließlich
anderen Diensten) zur Verfügung
gestellt werden, zu verwalten. Wenn ein Client zum Beispiel einen
Dienst nutzen möchte,
kann der Space-Dienst eine Überlassung
für den
Client als Teil der Instantiierung des Dienstes anfordern. Die Instantiierung
des Dienstes kann durchgeführt
werden, um es einem Client zu ermöglichen, den Dienst ablaufen
zu lassen. Um einen Dienst zu instantiieren, kann ein Client zuerst
eine der Dienstannoncen auswählen,
die in einem Space veröffentlicht
sind. Der Client kann die verschiedenen Funktionen benutzen, die
von dem Space bereitgestellt werden, um Annoncen in dem Space zu durchsuchen.
Danach kann der Client anfordern, daß der Space den Dienst instantiiert.
Die Überlassung,
die während
der Instantiierung des Dienstes herbeigeführt wird, bezieht sich auf
die Nutzung der Dienstannonce (nicht dasselbe wie die Überlassung
der Veröffentlichung
der Dienstannonce). Man sollte beachten, daß der Space-Dienst es mehreren
Clients ermöglichen
kann, eine Überlassung
der Nutzung einer Dienstannonce zu besitzen, wenn die Annonce über einen
Hinweis verfügt,
daß sie
gemeinsam genutzt wird. Ansonsten ermöglicht der Space-Dienst es
zu einem Zeitpunkt nur einem Client, eine Überlassung der Dienstannonce
zu besitzen (exklusiv).
-
Ein
anderes Beispiel dafür,
wie ein Space-Dienst Überlassungen
verwendet, um die Ressourcen zu verwalten, die seine Einrichtungen
den Clients zur Verfügung
stellen, liegt vor, wenn ein Client des Space sich dafür registriert,
daß er
benachrichtigt wird, wenn XML-Dokumente (z. B. Dienstannoncen) zu
dem Space hinzugefügt
werden oder aus ihm entfernt werden. Der sich registrierende Client
des Space kann eine Überlassung
dieser Anmeldung bzw. Subskription für Benachrichtigungen erhalten.
Diese Überlassung
ermöglicht
es dem Space-Dienst zu wissen, ob er mit dem Senden von Benachrichtigungen
fortfahren soll. Solch eine Überlassung
ist möglicherweise
nicht notwendig, wenn ein Client eine aktive Sitzung bei dem Space
eingerichtet hat. Man beachte auch, daß, wenn ein Client eines Space
(könnte
ein Dienst sein) eine Sitzung mit einem Space aufbaut, der Client
eine Überlassung
der Sitzung erhalten kann. Dies ermöglicht es, daß der Space
jegliche Ressourcen verwalten kann, die der Sitzung zugeordnet sind.
-
In
einer anderen Ausführungsform
kann die verteilte Rechnerumgebung einen Überlassungsmechanismus einsetzen,
der nicht zeitbasiert ist. Die Überlassung
kann erzeugt werden, wenn ein Objekt zur Verwendung angefordert
wird. Anstelle eines zeitbasierten Mechanismus' kann das Anforderungsverfahren einen Callback
bzw. Rückruf
akzeptieren, der den aktuellen Halter der Überlassung benachrichtigt,
daß eine
andere Partei Zugriff auf dasselbe Objekt (z. B. einen Dienst) haben
möchte.
Somit können
als eine alternative Ausführungsform
zu zeitbasierten Überlassungen Clients
stattdessen Ansprüche
auf Space-Objekte (z. B. Dienste) geltend machen. Wenn ein anderer
Client eine Überlassung
wünscht,
die nicht kompatibel mit der Überlassung
des aktuellen Inhabers der Überlassung
ist, kann der Dienst eine "Rückrufnachricht" an den Client senden.
Beim Empfang der Rückrufnachricht
kann der Client (d. h. das Clientgatter) eine Rückrufmethode aufrufen, um über die
Antwort auf die Rückrufnachricht
zu entscheiden (die Überlassung
behalten, die Überlassung löschen, die
Zugangsstufe auf gemeinsam genutzt ändern, etc.). Sobald eine Antwort
festgelegt wurde, sendet das Clientgatter eine Antwortnachricht
an den Dienst. Dieser verteilte Mechanismus zum Verwalten von Überlassungen
kann unter Verwendung der XML-Nachrichtenübergabe-Schichtimplementiert werden.
-
Für eine nicht-zeitbasierte
Ausführungsform
der Überlassung
kann die verteilte Rechnerumgebung eine Unterstützung von Überlassungen für mehrere
Stufen (oder Arten) von Zugang vorsehen, die es einem verteilten
Algorithmus ermöglichen,
die Kompatibilität
von Überlassungen
zu ermitteln. Diese Stufen können beinhalten:
(i) das Objekt in dem Space halten (keepInSpace), (ii) das Objekt
in dem Space lesen (readShared) und (iii) das Objekt in dem Space
exklusiv lesen (readExclusive).
-
Authentisierung und Sicherheit
-
Die
verteilte Rechnerumgebung sieht spontane und heterogene, verteilte
Systeme vor, die auf einem asynchronen Modell zur Nachrichtenübergabe
beruhen, wobei Daten und/oder Objekte in einer Datenrepräsentationssprache
wie XML dargestellt werden können.
In der verteilten Rechnerumgebung können Clients zum Beispiel über das
Internet mit Diensten Verbindung aufnehmen. Die verteilte Rechnerumgebung
kann eine große
Anzahl von Netzwerkeinrichtungen in die Lage versetzen, in einer
zuverlässigen,
dynamischen und sicheren Weise zusammenzuarbeiten. Die verteilte
Rechnerumgebung kann ein Protokoll definieren, das im wesentlichen
die Interoperabilität
zwischen konformen Softwarekomponenten (Clients und Diensten) ermöglicht.
-
Im
Kontext der verteilten Rechnerumgebung kann eine Einrichtung eine
im Netzwerk verbundene, auf der Transportschicht adressierbare Einheit
sein. Clients und Dienste können
als mittels Universellen Ressourcenkennzeichnern (Universal Resource
Identifier, URI) adressierbare Instanzen von Software oder Firmware implementiert
sein, die auf Einrichtungen ablaufen.
-
Der
Internet-Space ist durch viele Inhaltspunkte besiedelt. Ein URI
ist ein Verfahren, das verwendet wird, um irgendeinen dieser Inhaltspunkte
zu kennzeichnen, sei es eine Textseite, ein Video- oder Sound-Clip, ein
Bild, Software, Firmware oder anderer Internet-Inhalt. Die verbreitetste
Form eines URI ist die Webseiten-Adresse, die eine bestimmte Form
oder Teilmenge eines URI ist, die Uniform Resource Locator (URL)
genannt wird. Ein URI beschreibt typischerweise den Mechanismus,
der verwendet wird, um auf die Ressource zuzugreifen, den spezifischen
Computer, der die Ressource beherbergt und den spezifischen Namen
der Ressource (typischerweise ein Dateiname) auf dem Computer.
-
Clients
und Dienste (beide können
auf Einrichtungen als Software und/oder Firmware implementiert sein)
können über das
Internet, ein firmeneigenes Intranet, ein dynamisches nachbarschaftsbezogenes
Netzwerk innerhalb eines einzelnen Computers oder durch andere Netzwerkverbindungsmodelle
verbunden sein. Die Größe und Komplexität der Einrichtungen,
die Clients und Dienste unterstützen,
kann zum Beispiel von einem einfachen Lichtschalter bis zu einem
komplexen, hochverfügbaren
Server rangieren. Beispiele für
Einrichtungen umfassen, sind jedoch nicht beschränkt auf: PDAs; Mobiltelefone,
Notebook, Laptop, und leistungsfähigere
PCs; und leistungsfähigere
Computersysteme bis hin zu Supercomputern. Nach einigen Ausführungsformen
kann von der Entfernung, der Verzögerung und der Implementierung
von Clients und Diensten mittels einer allgemeinem Methodologie
zur Auffindung und Kommunikation abstrahiert werden, was einen "Blackbox"-Effekt erzeugt.
Dieser Definitionsansatz ermöglicht
es, daß Belange
der Softwareimplementierung von der zugrundeliegenden Plattform
abgehandelt werden, was zu einem lose gekoppelten System führt, das auf
Internet-Proportionen skaliert werden kann.
-
Die
verteilte Rechnerumgebung kann ein Internet-zentriertes Programmiermodell
zur Verfügung
stellen einschließlich
der Repräsentation
von WEB- und XML-Inhalten, dynamischer Auffindung von Einrichtungen und
sicherer Kommunikation zwischen Einrichtungen, die von einer breiten
Spanne von Netzwerkeinrichten zugänglich ist. Die verteilte Rechnerumgebung
kann ein Netzwerk-Programmiermodell
bereitstellen, das über das
CPU-Niveau abstrahiert ist. Das Programmiermodell kann die folgenden
Eigenschaften umfassen:
- • URI-Adressen
- • Streng
typisierte Daten, die als Inhalt bezeichnet werden (adressiert mittels
URIs)
- • Eine
im Wesentlichen unbeschränkte
Menge von persistentem Inhaltsspeicher (z. B. Speicher), (der XML- und
Nicht-XML-Inhalt wie den durch MIME-Typen gekennzeichneten enthält)
- • Eine
im Wesentlichen unbeschränkte
Menge von transientem Inhaltsspeicher, der Spaces genannt wird (der
XML-Inhalt enthält)
- • Beschreibende
Inhaltsankündigungen
mit XML-Metadaten (Daten über
Daten), die in einem Space gespeichert werden können, um interessierte Clients
zu benachrichtigen bzw. in Kenntnis zu setzen.
- • Eine
im Wesentlichen unbeschränkte
Anzahl von Instruktionen (ausgedrückt als Nachrichten)
- • Sichere
Nachrichten-Endpunkte (Gatter), die durch URIs adressiert werden
- • Unterstützung für Datenfluß (Ereignisnachrichten),
um den Arbeitsablauf bzw. Informationsfluß zwischen verteilten Softwareprogrammen
zu koordinieren
-
Dienste
und Clients können
als Programme innerhalb der verteilten Rechnerumgebung ablaufen. Dienste
können
Clients, die den Dienst benutzen möchten, ihre Fähigkeiten
ankündigen
bzw. bekanntmachen. Clients können
sich innerhalb derselben Netzeinrichtung befinden oder auch nicht,
und die Codeausführungsumgebung
dieser Einrichtung kann die Java-Plattform unterstützen oder
auch nicht.
-
Die
Verwendung von URIs zur Adressierung von Inhalten und Nachrichtenendpunkten
gibt der verteilten Rechnerumgebung ein mächtiges Adressierungsschema.
Die Adresse kann den Ort bzw. die Lage des Inhaltes oder des Endpunktes
angeben, und kann den zu verwendenden Weg bzw. die zu verwendende
Route (oder das zu verwendende Transportprotokoll) angeben. Gegenstände, die
mittels URIs adressiert werden, können auch einen zugeordneten
Sicherheitsnachweis haben. Der Sicherheitsnachweis kann zur Kontrolle bzw.
Steuerung verwendet werden, welchen Clients ein Zugriff auf den
Gegenstand bzw. die Einheit erlaubt wird als auch welche Operationen
autorisierte Clients auf dieser Einheit durchführen dürfen.
-
Der
hohe Grad von Zugriff, der durch die verteilte Rechnerumgebung bereitgestellt
wird, kann durch geeignete Authentifizierung und Sicherheitssysteme
und -verfahren kontrolliert werden. Authentifizierung und Sicherheit
in der verteilten Rechnerumgebung kann umfassen, ist jedoch nicht
beschränkt
auf: Überprüfen der Richtigkeit
der Typen von XML-Inhalten in einer Nachricht; sicheres Identifizieren
des Senders gegenüber
dem Empfänger;
einen Mechanismus zum Prüfen
der Integrität
von Nachrichten, die von einem Client an einen Dienst gesendet werden
und umgekehrt; und einen Mechanismus, um einem Client den Satz von
akzeptierten Nachrichten eines Dienstes zu beschreiben und die Anforderungen
an Nachrichten bei Nachrichten, die bei dem Dienst empfangen werden,
durchzusetzen. Die oben aufgelisteten Sicherheits- und Autorisierungseigenschaften
bzw. -funktionen können
in einer einzelnen, unteilbaren Einheit von Code und Daten umgesetzt
werden. Die unteilbare Einheit von Code und Daten kann dynamisch
erzeugt werden. In einer Ausführungsform kann
die unteilbare Einheit von Code und Daten, sobald sie kreiert wurde,
einen Nachrichtenendpunkt (Gatter) repräsentieren und darf nach den
während
der Erzeugung implementierten Sicherheits- und Autorisierungsrichtlinien
nicht verändert
werden.
-
Ein
Gatter kann die Befugnis repräsentieren,
einige oder alle Leistungsmerkmale eines Dienstes zu verwenden.
Jedes Leistungsmerkmal kann als eine Nachricht ausgedrückt werden,
die an einen Dienst gesendet werden kann. Gatter können auch
zum Erkennen von Fehlerfällen
verwendet werden, wenn ein Client Ressourcen überlassen bekommt bzw. pachtet.
-
Authentisierung
und Sicherheit kann auch einen Mechanismus umfassen, der überprüft, daß ein Client,
der einen Dienst zu benutzen versucht, autorisiert ist, den Dienst
zu benutzen; daß der
Space, von dem der Client die Dienstannonce empfängt, autorisiert ist, die Dienstannonce
bereitzustellen; und/oder daß die Dienstannonce
selbst autorisiert ist.
-
Die Übergabe
von Nachrichten kann in einer Nachrichtenschicht als die Möglichkeit
implementiert sein, Anforderungen von Clients zu Diensten zu kommunizieren,
und daß Dienste
den Clients mit Ergebnissen antworten können. Die Nachrichtenschicht
der verteilten Rechnerumgebung kann im Wesentlichen sicherstellen,
daß gültige XML-Nachrichten
gesendet werden, und kann Mechanismen bereitstellen, die ein sprachunabhängiges Sicherheitsmodell
ermöglichen.
In der Nachrichtenschicht kann ein sendender Nachrichtenendpunkt
mit einem empfangenden Nachrichtenend punkt verbunden sein bzw. werden.
Die zwei zugeordneten Nachrichtenendpunkte können einen sicheren, unteilbaren,
bidirektionalen Nachrichtenkanal bereitstellen, der für die Übergabe
von Anforderungs-Antwort-Nachrichten zwischen einem Client und einem
Dienst geeignet ist.
-
Nach
Ausführungsformen
einer verteilten Rechnerumgebung kann eine Annonce für einen
Dienst in einem Space veröffentlicht
werden. Eine Annonce kann ein XML-Dokument sein, das das XML-Schema
und den URI des Dienstes enthält.
Der Dienst kann auch ein Dienst-ID-Token oder einen Berechtigungsnachweis in
der Annonce enthalten und kann einen Authentisierungsdienst in der
Annonce angeben, der sowohl von dem Client als auch von dem Dienst
zu verwenden ist. Ein Client kann dann die Dienstannonce auf dem
Space lokalisieren und die Annonce verwenden, um ein Nachrichtengatter
auf dem Client zu instantiieren. Der Client kann den in der Annonce
angegebenen Authentisierungsdienst benutzen, um eine Authentisierungsbestätigung zum
Senden von Nachrichten an den Client zu erlangen. In einer Ausführungsform
kann der Client das Dienst-ID-Token
oder den Berechtigungsnachweis aus der Dienstannonce an den Authentisierungsdienst übergeben,
und der Authentisierungsdienst kann daraufhin das Dienst-Token oder
den Berechtigungsnachweis zum Erzeugen der Authentisierungsbestätigung für den Client
verwenden. In einer Ausführungsform
kann der Client eine Gatterfabrik beinhalten, die die notwendige
Information zum Erzeugen des Nachrichtengatters empfängt, und
die Gatterfabrik kann das Nachrichtengatter einrichten und mit dem
Authentisierungsdienst kommunizieren, um den Authentisierungsnachweis
für den
Client zu erhalten. Ein entsprechendes Nachrichtengatter des Dienstes
kann beim Dienst instantiiert werden.
-
Der
Client sendet zu einem bestimmten Zeitpunkt eine erste Nachricht
an den Dienst. In einer Ausführungsform
kann des Nachrichtengatter des Client den Authentisierungsnachweis
des Client, der von dem Authentisierungsdienst aufgebaut bzw. eingerichtet
wurde, in die Nachricht einbetten. Wenn der Dienst die Nachricht
empfängt,
kann er denselben Authentisierungsdienst zum Überprüfen des in der Nachricht empfangenen Authentisierungsnachweises
benutzen. Durch gemeinsames Nutzen desselben Authentisierungsdienstes kann
jedes aus einer Vielzahl von Authentisierungsprotokollen eingesetzt
werden, wobei die Einzelheiten der Erzeugung von Authentisierungsnachweisen
von dem Client und dem Dienst separiert werden können. Somit kann ein Client
verschiedene Authentisierungsbestätigungsprotokolle bei verschiedenen
Diensten benutzen.
-
In
einer Ausführungsform
kann der Authentisierungsdienst beim ersten Empfang des Authentisierungsnachweises
eines Client von dem Dienst die Leistungsmerkmale des Client festlegen
(z. B. was der Client auf dem Dienst zu tun berechtigt ist). Die
Leistungsmerkmale des Client können
an die Identität
des Client gebunden sein. Danach kann das Nachrichtengatter des
Client den Authentisierungsnachweis in jede Nachricht einbetten,
die vom Client an den Dienst gesendet wird. Die Nachrichten können von
dem Nachrichtengatter des Dienstes empfangen und dann von dem Authentisierungsdienst überprüft werden,
um sicherzustellen, daß die
Nachricht von dem Client ist und die Nachrichtenanforderung innerhalb
der Leistungsmerkmale des Client liegt. In einer anderen Ausführungsform
kann das Nachrichtengatter des Dienstes die Festlegung der Leistungsmerkmale und
das Überprüfen der
Nachrichten hinsichtlich der Leistungsmerkmale ohne Benutzung des
Authentisierungsdienstes behandeln.
-
Die
Nachrichtengatter des Client und des Dienstes können zur Bereitstellung eines
sicheren und zuverlässigen
Nachrichtenkanals zusammenarbeiten. Die Gatter können als sichere Nachrichtenendpunkte
dienen, die es dem Client ermöglichen,
den Dienst durch Senden und Empfangen von gesicherten, autorisierten XML-Nachrichten
an den und von dem Dienst ablaufen zu lassen.
-
Operationen
in der verteilten Rechnerumgebung können als zwischen Clients und
Diensten gesendete XML-Nachrichten ausgedrückt werden. Das zum Verbinden
von Clients mit Diensten und zum Adressieren von Inhalt in Spaces
und Speichern verwendete Protokoll kann durch die Nachrichten definiert
werden, die zwischen den Clients und Diensten gesendet werden können. Die
Verwendung von Nachrichten zur Definition eines Protokolls kann
viele verschiedene Arten von Einrichtungen in die Lage versetzen,
an dem Protokoll teilzunehmen. Jeder Einrichtung kann es freigestellt
sein, das Protokoll in einer Weise zu implementieren, die am besten
zu ihren Möglichkeiten
und ihrer Rolle paßt.
-
Die
Leistungsmerkmale eines Dienstes können mittels Nachrichten ausgedrückt werden,
die der Dienst akzeptiert. Ein Nachrichtensatz eines Dienstes kann
mittels eines XML-Schemas definiert werden. Ein XML-Nachrichtenschema
kann jedes Nachrichtenformat mittels XML-typisierter Tags definieren.
Die Regeln zur Verwendung von Tags können auch in dem Schema definiert
werden. Das Nachrichtenschema kann eine Komponente einer XML-Annonce
zusammen mit dem Nachrichtenendpunkt (Gatter) des Dienstes sein,
das zum Empfang der Nachrichten verwendet wird. Erweiterungen (mehr
Fähigkeiten
bzw. Leistungsmerkmale) können
zu einem Dienst hinzugefügt
werden, indem Nachrichten zu dem XML-Nachrichtenschema hinzugefügt werden.
-
In
der verteilten Rechnerumgebung können
autorisierte Clients in der Lage sein, alle Leistungsmerkmale eines
Dienstes zu verwenden, oder können
darauf beschränkt
sein, eine Teilmenge der Leistungsmerkmale eines Dienstes zu verwenden.
In einer Ausführungsform
kann der Client, sobald ihm ein Satz von Leistungsmerkmalen gegeben
wurde, diesen Satz nicht ohne passende Autorisierung ändern. Dieses
Modell zur Definition von Leistungsmerkmalen kann Dienststufen ermöglichen,
die sich von einer Grundmenge von Leistungsmerkmalen bis zu einer
erweiterten Menge erstrecken.
-
Das
Instantiieren von Diensten kann durchgeführt werden, um es einem Client
zu ermöglichen,
einen Dienst ablaufen zu lassen. Zum Instantiieren eines Dienstes
kann ein Client zuerst eine der in einem Space veröffentlichten
Dienstannoncen auswählen.
Der Client kann die verschiedenen von dem Space bereitgestellten
Funktionen verwenden, um Annoncen in dem Space zu durchsuchen. Danach
kann der Client den Space zum Instantiieren des Dienstes auffordern.
Das Instantiieren von Diensten kann die folgenden Schritte umfassen,
ist jedoch nicht beschränkt
auf:
- 1. Der Client fordert den Space-Dienst
zum Instantiieren eines Dienstes auf.
- 2. Der Space-Dienst prüft,
ob der Client zum Instantiieren des Dienstes berechtigt ist.
- 3. Der Space-Dienst erhält
eine Überlassung
der Dienstannonce für
den Client, wobei die Anforderungsdauer der Überlassung durch den Client
angegeben wird. Alternativ kann die Dienstannonce dem Client ohne
Verwendung des Überlassungsmechanismus' zur Verfügung gestellt
werden.
- 4. Der Space-Dienst sendet eine Nachricht an den Client, die
die in Schritt 3 zugeordnete Überlassung und die Dienstannonce
des Dienstes beinhaltet.
- 5. Der Client läßt den in
der Dienstannonce angegebenen Authentisierungsdienst ablaufen und
erhält
einen Authentisierungsnachweis.
- 6. Der Client richtet ein Nachrichtengatter des Clients zur
Kommunikation mit dem Dienst ein.
-
Um
zwischen Clients und Diensten in einer verteilten Rechnerumgebung
für Vertrauen
zu sorgen, können
eine Reihe von dynamisch erzeugten Zahlen (Schlüssel oder Token) als Sicherheits- oder Authentisierungsnachweise
für Clients
verwendet werden. Ein oder mehrere Berechtigungsnachweise können zum Überprüfen der
Rechte eines Clients, einen Dienst zu benutzen, und zum Überprüfen von
Nachrichten zwischen dem Client und dem Dienst verwendet werden.
Jeder Client und Dienst kann einen eindeutigen Berechtigungsnachweis
haben.
-
Die
Art des zur Benutzung eines Dienstes benötigten Authentisierungsnachweises
kann an den Client zurückgegeben
werden, der eine Dienstsuche vornimmt. In einer Ausführungsform
ist ein Authentisierungsnachweis ein nicht-durchsichtiges Objekt,
das jedesmal vorgewiesen werden muß, wenn ein Client einen Dienst
benutzt. In einer Ausführungsform
kann der Authentisierungsnachweis von einem Nachrichtengatter im Namen
eines Client in jeder an einen Dienst gesendeten Nachricht übergeben
werden. Unabhängig
davon, welche Art von Authentisierungsnachweis durch einen Dienst
gefordert wird, braucht der Client und der Dienst durch das Verwenden
eines Authentisierungsdienstes, der zu dem Client und zu dem Dienst
extern ist, die Struktur des Authentisierungsnachweises oder den
Authentisierungsvorgang nicht zu kennen.
-
Ein
Authentisierungsnachweis kann auch zusätzlich zu dem Dienstticket
ein transportspezifisches Ticket beinhalten. Wenn ein Dienst abläuft kann
das Transportmedium abhängig
von dem in der Dienstannonce angegebenen Netzwerk-Transportmedium
eine sichere Verbindung bereitstellen. In einigen Fällen, in
denen die Datensicherungsschicht bereits sicher ist, braucht es
nicht notwendig zu sein, ein sicheres Transportmedium über einer
bereits sicheren Datensicherungsschicht zu verwenden.
-
Das
Konzept eines Authentisierungsnachweises ist abstrakt genug, um
verschiedene Sicherheitsstufen basierend auf der Implementierung
der Berechtigungsnachweise zu ermöglichen. Sicherheitsstufen
können
umfassen, sind jedoch nicht beschränkt auf:
- 1.
Keine (keine Nachrichtensicherheit – der Berechtigungsnachweis
ist leer oder es gibt keinen Berechtigungsnachweis)
Nachrichten
mit leeren Berechtigungsnachweisen oder ohne Berechtigungsnachweise
können
ausreichen, wenn Sicherheit durch physikalische Verbindungseigenschaften
des Transportmediums herbeigeführt
wird. Zum Beispiel kann ein intelligenter Lichtschalter, der mit
nur einer Lichtschaltsteuerung verbunden ist, sicher sein, weil
die Schalter in einer sicheren Weise verdrahtet sind.
- 2. Unterschriebene Nachrichten (digitale Unterschriften)
Unterschriebene
Nachrichten können
eine digitale Unterschrift beinhalten, die den Dienst (der die Nachricht empfängt) in
die Lage versetzt, den Ursprung (den Client) der Nachricht zu überprüfen.
- 3. Verschlüsselte
Nachrichten (das Transportmedium kann dies behandeln)
Verschlüsselte Nachrichten
fügen eine
weitere Sicherheitsstufe hinzu, indem die Nachrichteninhalte verschlüsselt werden,
so daß ein
weiterer Berechtigungsnachweis zum Entschlüsseln erforderlich ist.
- 4. Fähigkeitsnachrichten
(abhängig
von Dienstfunktionalität
und Benutzer)
Diese Sicherheitsstufe kann für Sicherheitsmerkmalen sorgen,
die für
jeden Benutzer spezifisch sein können
(z. B. was ein Benutzer tun darf), und kann eine fein abgestufte
Zugriffskontrolle für
Dienste und individuelle Dienstfunktionen ermöglichen.
-
Mehrere
Stufen von Sicherheitszonen können
verwendet werden abhängig
von der aufwendigen Implementierung, die zum Erreichen bzw. zum
Durchsetzen der höheren
Sicherheitsstufen (Leistungsmerkmale & Verschlüsselung) notwendig ist. Wenn
der Nachrichtentransport diese Sicherheitsstufen unterstützt (oder dabei
hilft, sie zu unterstützen),
kann die Unterstützung
wirksam eingesetzt werden, um Brückendienste
für Sicherheitsstufen
bereitzustellen, die eine Brücke
von einer Sicherheitsstufe zu einer anderen bilden.
-
Wie
oben erwähnt,
können
Dienste ohne jegliches Sicherheitsmodell leere Authentisierungsnachweise
akzeptieren. Für
Dienste, die den Zugang nicht einschränken, kann ein Gatter ohne
Authentisierungsnachweis oder mit einem "leeren" Authentisierungsnachweis aufgebaut
werden. Die Gatter für
solche Dienste brauchen nicht mit jeder Nachricht einen Authentisierungsnachweis
zu senden oder können
einen leeren Berechtigungsnachweis senden. Der Authentisierungsdienst
ist ein Beispiel eines Dienstes, der den Zugang nicht einschränkt. Andere
Dienste können
ein Benutzer-Paßwort-Paar
erfordern.
-
Authentisierung des Dienstzugriffs
mittels Berechtigungsnachweisen
-
Nach
einigen Ausführungsformen
kann ein Mechanismus für
die Überprüfung, daß ein Client,
der einen Dienst ablaufen zu lassen versucht, ein autorisierter
Client ist, für
die Überprüfung, daß die von
einem Client empfangene Dienstannonce eine autorisierte Dienstannonce
ist, und/oder zum Überprüfen, daß der Space,
von dem der Client die Dienstannonce empfängt, autorisiert ist, auf einem
asymmetrischen Verschlüsselungsmechanismus
mit öffentlichem
Schlüssel/privatem
Schlüssel
beruhen. In diesem Mechanismus kann eine autorisierte sendende Einheit
einen öffentlichen
Schlüssel
in einer Nachricht einbetten und die Nachricht einschließlich des öffentlichen
Schlüssels
mit seinem privaten Schlüssel
verschlüsseln.
Eine Einheit, die die verschlüsselte
Nachricht empfängt,
kann die Nachricht mittels des öffentlichen
Schlüssels
entschlüsseln
und denselben öffentlichen
Schlüssel
eingebettet in der entschlüsselten
Nachricht vorfinden und damit überprüfen, daß die Nachricht
von der autorisierten Einheit stammt, da nur diese Einheit über den
privaten Schlüssel
verfügt,
der zum Verschlüsseln
der Nachricht notwendig ist. Somit kann eine Einheit einen Berechtigungsnachweis
ausgeben, der im Wesentlichen fälschungssicher
ist und den andere Einheiten entschlüsseln können (mit dem passenden öffentlichen
Schlüssel),
um die von der Einheit gesendeten Nachrichten zu überprüfen.
-
Verschiedene
Algorithmen zur Erzeugung von Schlüsseln können in der verteilten Rechnerumgebung verwendet
werden. Die Zusammensetzung bzw. der Aufbau von Schlüsseln kann
sowohl vor Clients als auch vor Diensten verborgen werden; somit
brauchen sich der Client und der Dienst nicht darum zu kümmern, welcher
Algorithmus zur Erzeugung von Schlüsseln verwendet wird.
-
Ein
Kerberos-Ticket (Zerburus-Ticket) ist ein Beispiel eines Sicherheitsnachweises,
der in der verteilten Rechnerumgebung verwendet werden kann. Kerberos
ist ein sicheres Verfahren zur Authentisierung einer Anforderung
eines Dienstes in einem Computernetzwerk. Kerberos läßt einen
Benutzer ein verschlüsseltes "Ticket" von einem Authentisierungsprozeß anfordern,
das daraufhin verwendet werden kann, um einen bestimmten Dienst
anzufordern. Das Paßwort
des Benutzers braucht nicht durch das Netzwerk übergeben zu werden.
-
Von
der verteilten Rechnerumgebung können
Mechanismen zur Verfügung
gestellt werden, um im Wesentlichen zu garantieren, daß zwischen
Clients und Diensten gesendete Nachrichten nicht gefährdet werden.
In einer Ausführungsform
kann ein Sender ein Token einbetten, das Information enthält, die
von den Empfänger
zur Überprüfung verwendet
werden kann, daß die
Nachricht nicht verändert
wurde. Es gibt verschiedene Verfahren zum Erzeugen von Information,
die in die Nachricht eingebettet werden soll. In einer Ausführungsform
kann ein Hash der Nachricht berechnet und mit der Nachricht gesendet
werden. Das Erzeugen eines Hash kann die Transformation einer Zeichenkette
in einen üblicherweise
kürzeren
Wert oder Schlüssel
fester Länge
umfassen, der die ursprüngliche
Kette repräsentiert.
Beim Empfang der Nachricht kann der Empfänger den Hash neu berechnen
und ihn gegen den gesendeten Hash prüfen. Wenn die Nachricht geändert wurde,
ist es höchst
unwahrscheinlich, daß derselbe
Hash erzeugt wird. Der Sender kann den Hash verschlüsseln und
den entsprechenden öffentlichen
Schlüssel
in der verschlüsselten
Nachricht senden, um im Wesentlichen sicherzustellen, daß der Hash
nicht beeinträchtigt
wird.
-
In
anderen Ausführungsformen
kann ein Schema zur Fehlerentdeckung wie eine zyklische Redundanzprüfung verwendet
werden. Eine zyklische Redundanzprüfung ist ein Verfahren zum
Prüfen
auf Fehler in Daten, die auf einer Kommunikationsverbindung übertragen
werden. In einer Ausführungsform,
die zyklische Redundanzprüfung
benutzt, wendet der Sender ein n-Bit Polynom auf die Nachricht an
und hängt
den sich ergebenden zyklischen Redundanzcode (Cyclic Redundancy
Code, CRC) an die Nachricht an. Der Empfänger wendet dasselbe Polynom
(das auch in der Nachricht übergeben
werden kann) auf die Nachricht an und vergleicht sein Ergebnis mit
dem vom Sender angehängten
Ergebnis. Wenn sie übereinstimmen,
wurde die Nachricht erfolgreich empfangen. Falls nicht, kann der
Sender benachrichtigt werden, um die Nachricht erneut zu senden.
-
Gatterfabriken
können
auch eine Rolle bei der Sicherheit spielen, da eine Gatterfabrik "vertrauenswürdiger" Code sein kann.
Das Verwenden einer vertrauenswürdigen
Gatterfabrik zum Erzeugen von Gattern kann helfen sicherzustellen,
daß Gatter
vertrauenswürdigen
Code darstellen und daß der
Code bezogen auf die Dienstannonce korrekt ist. Von Clients kann
die Übergabe
eines Client-ID-Token oder -Berechtigungsnachweises an die Gatterfabrik
als ein Mittel zur Authentisierung verlangt werden. Dienste können ein(en) Dienst-ID-Token
oder -Berechtigungsnachweis an Clients übergeben (z. B. durch eine
Annonce), wenn ein Client ein Gatter erzeugen möchte. Wie hier diskutiert,
kann ein Client- und Dienst-Token-Paar zum Erzeugen eines dritten
Berechtigungsnachweises benutzt werden, der verwendet werden kann,
um dem Client das Senden von Nachrichten an den Dienst zu ermöglichen.
Dieser dritte Berechtigungsnachweises kann als Authentisierungsnachweis
bezeichnet werden. Ein Authentisierungsnachweis kann von einem Authentisierungsdienst während des
Authentisierungsvorgangs erzeugt werden. In einer Ausführungsform
kann der Dienst jegliche Authentisierungsrichtlinie zu seiner Verfügung verwenden.
In einer Ausführungsform
kann der Authentisierungsdienst die Authentisierungsrichtlinie im
Namen des Dienstes administrienen, und somit muß der Dienst die genaue Authentisierungsrichtlinie
nicht kennen, die verwendet wird.
-
Der
Client kann sein Gatter mittels eines Authentisierungsnachweises
einrichten, das der Client durch das Ablaufen-Lassen eines in der
Dienstannonce angegebenen Authentisierungsdienstes empfängt. Das
kann dem eingerichteten Gatter das Senden des Authentisierungsnachweises
mit jeder Nachricht an den Dienst ermöglichen. Wenn der Dienst den
ersten Authentisierungsnachweis in einer ersten Nachricht von dem
Client empfängt.
kann der Dienst den in der Dienstannonce angegebenen Authentisierungsdienst
zur Authentisierung des Client verwenden und dadurch eine Bindung
des Authentisierungsnachweises an die Identität des Client einrichten.
-
Wie
zuvor diskutiert, können
einige von einem Dienst erzeugte Ergebnisse in einem Space angekündigt werden,
und auf sie kann letztlich mittels eines Ergebnisgatters zugegriffen
werden. Das Ergebnisgatter kann denselben Sicherheitsnachweis wie
das Eingabegatter, das zum Erzeugen der Ergebnisse verwendet wurde,
enthalten oder auch nicht. Da die Eingabe an einen Dienst asynchron
von seiner Ausgabe (den Ergebnissen) sein kann, kann den Ergebnissen
ein unterschiedlicher Satz von Zugriffsrechten zugeordnet sein.
Zum Beispiel kann ein Dienst zur Gehaltsabrechnung die Initiierung
der Gehaltsabrechnung einer anderen Menge von Clients erlauben als
das Lesen der Ergebnisse des Gehaltsabrechnungsdienstes (Gehaltsschecks).
Daher muß ein
Client möglicherweise
durch einen separaten Authentisierungsvorgang gehen, um Zugriffsrechte
auf die Ergebnisse zu erhalten, was den Empfang eines Authentisierungsnachweises
für die
Ergebnisse von einem in der Annonce für die Ergebnisse angegebenen
Authentisierungsdienst umfassen kann.
-
Nachrichtengatter
können
den Diensten die meisten Sicherheitsüberprüfungen abnehmen. Dienste können sich
auf das Bereitstellen von Leistungsmerkmalen und das Authentisieren
von Clients konzentrieren. Ein Prinzip des geringsten Privilegs
kann dadurch unterstützt
werden, daß Clients
nur zu denjenigen Leistungsmerkmalen Zugang erhalten, die angefordert
(oder zugewiesen) wurden.
-
Sicherheitsüberprüfungen können auftreten,
wenn ein Gatter erzeugt und/oder wenn ein Gatter verwendet wird
(wenn Nachrichten gesendet und/oder empfangen werden). Wenn ein
Client Zugriff auf einen angekündigten
Gegenstand bzw. Einheit (Dienst) anfordert, kann der Vorgang der
Gattererzeugung beginnen. Während
dieses Vorgangs kann die Client-Gatterfabrik mit dem Dienst arbeiten,
um sich gegenseitig zu authentisieren. Die zum Zeitpunkt der Gattererzeugung
durchgeführten
Prüfungen
können
extensiv sein und können
die Anzahl der während
der Nutzung des Gatters durchgeführten
Prüfungen
minimieren. Nachdem der Dienst den Client authentisiert hat, kann
der Dienst spezifische Fähigkeiten
bzw. Möglichkeiten
für den
Client festlegen (z. B. was der Client auf dem Dienst tun darf),
und kann die Leistungsmerkmale dem Authentisierungsnachweis des
Client zuordnen. Diese spezifischen Leistungsmerkmale können angeben,
welche Operationen der Client auf dem Dienst durchführen darf.
Da die Gatter sicherstellen können,
daß jeder
Nachricht den Authentisierungsnachweis enthält, kann der Dienst dann jede
Anforderung, wenn sie empfangen wird, gegen die Leistungsmerkmale
des authentisierten Client prüfen.
-
Die
Prüfungen
bei der Gattererzeugung können
sicherstellen, daß ein
Client die Berechtigung hat, einige oder alle Leistungsmerkmale
des Dienstes zu benutzen, die durch das XML-Nachrichtenschema bestimmt sind. In
einer Ausführungsform
können
diese Prüfungen
mittels Zugangskontrollisten (Access Control Lists, ACLs) in Verbindung
mit einem Authentisierungsdienst wie Kerberos implementiert werden.
Eine Challenge-Response-Sequenz (wie ein Paßwort) kann auch zum Authentisieren
eines Client verwendet werden. Nach einigen Ausführungsformen kann ein Hardware-basiertes,
physikalisches Identifikationsverfahren zum Authentisieren des Client
verwendet werden. Zum Beispiel kann der Benutzer eine physikalische
Identifikation wie eine Smart-Card zur Identifikation und Autorisierung
liefern. Andere Mechanismen zur Authentisierung können in
anderen Ausführungsformen
verwendet werden.
-
In
einer Ausführungsform,
welches Mittel auch immer zum Authentisieren des Client verwendet
wird, kann die Authentisierung sowohl für den Client als auch für den Dienst
unsichtbar sein, die Gatterfabrik kann wissen, welcher Authentisierungsdienst
zu verwenden ist und der Authentisierungsdienst behandelt den Authentisierungsmechanismus
und die Authentisierungsrichtlinien. Gatterfabriken können produkt-
und umgebungsabhängig
sein oder können
sogar durch ein Konfigurationsmanagementsystem gesteuert werden.
In einer Ausführungsform
kann der Grad und das Verfahren der Isolation von Clients plattformabhängig, jedoch
der Gatterfabrik bekannt sein. Nach einigen Ausführungsformen kann ein Hardware-basiertes
physikalisches Identifikationsverfahren zum Authentisieren des Client
verwendet werden. Zum Beispiel kann der Benutzer eine physikalische
Identifikation wie eine Smart-Card zur Identifikation und Autorisierung
liefern. Andere Mechanismen zur Authentisierung können in
anderen Ausführungsformen
verwendet werden.
-
Nachrichtengatter
in der verteilten Rechnerumgebung sind typischerweise einem einzelnen
Client zugeordnet. Die Gatterfabrik kann das Mittel der Zuordnung
festlegen. Die zum Zeitpunkt des Sendens einer Nachricht durchgeführten Prüfungen können sicherstellen,
daß der
richtige Client das Gatter verwendet. In einer Ausführungsform
können
Gatter in Nachrichten übergeben
werden und können
geklont bzw. vervielfältigt werden,
wenn ein neuer Client das Gatter verwenden möchte. Der Vorgang des Klonens
bzw. der Klonierung kann einen neuen Satz von Prüfungen beim Erzeugen durchführen.
-
Sobald
ein Client eines Space (der Client kann ein anderer Dienst sein)
die Annonce eines Space-Dienstes findet, kann der Client des Space
den Space-Dienst wie jeden anderen Dienst ablaufen lassen. Das Ablaufen-Lassen
eines Space-Dienstes kann das Verwenden eines Authentisierungsmechanismus' nach sich ziehen.
Das Ablaufen-Lassen eines Space-Dienstes kann umfassen, ist jedoch
nicht beschränkt
auf:
- 1. Der Client des Space kann zuerst einen
Authentisierungsdienst ablaufen lassen, der in der Dienstannonce
des Space-Dienstes angegeben sein kann, um einen Authentisierungsnachweis
zu erhalten.
- 2. Der Client des Space kann den Authentisierungsnachweis, das
XML-Schema des Space (aus der Dienstannonce des Space) und den URI
des Space (aus der Dienstannonce des Space) zum Einrichten eines Gatters
für den
Space verwenden. In einer Ausführungsform
kann der Client die Information an eine Gatterfabrik zum Einrichten
des Gatters übergeben.
- 3. Der Client des Space kann den Space-Dienst ablaufen lassen,
indem er das Gatter zum Senden von Nachrichten an den Dienst verwendet.
- 4. Wenn der Space-Dienst die erste Nachricht von dem Client
mit dem eingebetteten Authentisierungsnachweis empfängt, kann
der Space-Dienst denselben Authentisierungsdienst verwenden, den
der Client zum Erhalt des Authentisierungsnachweises verwendet hat,
um den Client zu authentisieren und somit die Identität des Client
zu bestätigen.
- 5. Der Space-Dienst kann danach die Leistungsmerkmale des Client
festlegen (z. B. was der Client auf dem Space-Dienst tun darf) und
die Leistungsmerkmale an den Authentisierungsnachweis binden.
-
Wie
in dem Abschnitt über
Spaces diskutiert, können
die Funktionen eines Space eine Schnittstelle zum Abspalten bzw.
Ableiten eines leeren Space mit im Wesentlichen derselben Funktionalität (demselben XML-Schema)
wie der Space, von bzw. aus dem er abgespalten bzw. abgeleitet oder
erzeugt wurde, umfassen. Die Abspaltefunktion kann unter anderem
zum dynamischen Erzeugen von Spaces für Ergebnisse nützlich sein.
Wenn ein Anforderer einen Space erzeugt hat, kann es nur dem Anforderer
erlaubt sein, auf den erzeugten Space zuzugreifen. Zum Beispiel
kann der erzeugte Space zum Speichern von Ergebnissen von einem
Dienst vorgesehen sein, die der Client gesichert halten muß. Diese
Sicherheit kann sichergestellt werden durch:
- • Erzeugen
eines anfänglichen
Wurzel-Authentifizierungsnachweises und Initialisieren des Authentifizierungsdienstes
des erzeugten bzw. abgespaltenen Space, so daß der Authenti fizierungsdienst
nur den Wurzel-Authentifizierungsnachweis authentifiziert und so
daß er
keine anderen Authentifizierungsnachweise zurückliefert (keine anderen Clients
des abgespaltenen Space sind anfänglich
zugelassen).
- • Initialisieren
der Sicherheitsrichtlinien des abgespaltenen Space, so daß die dem
Wurzel-Authentifizierungsnachweis
zugeordnete Wurzel-Identität
auf alle Funktionen bzw. Einrichtungen des Space einschließlich der
Funktionen für
die Sicherheitsverwaltung Zugriff hat.
- • Zurückliefern
des Wurzel-Authentifizierungsnachweises und der Dienstankündigung
des abgespaltenen Space an den Anforderer des abgespaltenen Space.
-
Der
Anforderer kann ein Gatter zum Zugriff auf den erzeugten Space aufbauen,
da ihm der Authentisierungsnachweis und die Dienstannonce des erzeugten
Space zurückgeliefert
werden. In einer Ausführungsform
können
nur der Anforderer und Clients oder Dienste, denen der Anforderer
den Authentisierungsnachweis und die Dienstannonce des erzeugten
Space übergibt,
auf den erzeugten Space zugreifen. Eine solche Zugriffsbeschränkung auf
den erzeugten Space kann nützlich
sein, wenn ein Client und ein Dienst diesen erzeugten Space zum
Speichern von Ergebnissen verwenden, zum Beispiel wenn der Client
und der Dienst die Ergebnisse privat halten wollen.
-
Nachdem
man den Dienst hat ablaufen lassen, kann der Client die Authentisierungsrichtlinien
des erzeugten Space mittels einer Space-Funktion zur Sicherheitsverwaltung ändern, und
andere Clients oder Dienste können
dann auf den erzeugten Space zugreifen. Darüber hinaus kann die Dienstannonce
des erzeugten Space anderen Clients des erzeugten Space (die anderen
Clients können
Dienste sein) mittels des Auffindungsprotokolls oder anderer Mechanismen
verfügbar
gemacht werden.
-
Die
Nachrichtentransportschicht in einer verteilten Rechnerumgebung
kann Mechanismen zum Schutz der Sicherheit und Integrität der Kommunikation
unter Clients und Diensten während
des Transports umfassen. Diese Sicherheit kann als "Drahtsicherheit" oder "Transportsicherheit" bezeichnet werden,
um sie von der Authentisierungssicherheit zu unterscheiden, die
durch das Nachrichtensystem einschließlich Gatter implementiert
wird. Verschlüsselung
von Nachrichten kann auf der Nachrichtentransportschicht der verteilten Rechnerumgebung
zur Verfügung
stehen. Dienste, die einen verschlüsselten Transport anfordern,
können dies
durch Markieren der XML-Annonce tun. Die Gatterfabrik kann daraufhin
ein Gatter (oder (mehrere) Gatter) erzeugen, das einen sicheren
Transport von Nachrichten wie den von Bluetooth und HTTPS bereitgestellten verwendet.
-
HTTPS
(Secure Hypertext Transfer Protocol) ist ein Web-Protokoll, das
sowohl Seitenanforderungen von Benutzern als auch die Seiten, die
von dem Web-Server geliefert werden, verschlüsselt und entschlüsselt. HTTPS
kann eine Multi-Bit-Größe von Schlüsseln (kann
von 40 bis 128-Bit und mehr schwanken) für einen Stromverschlüsselungsalgorithmus
(z. B. RC4) verwenden, um einen angemessenen Grad von Verschlüsselung
für kommerziellen
Austausch bereitzustellen. HTTPS kann als ein Transportmedium in
der verteilten Rechnerumgebung verwendet werden.
-
Bluetooth
ist ein aufkommender Peer-to-Peer-Standard für drahtlose Kommunikation.
Die Algorithmen zum Erzeugen von Schlüsseln bei Bluetooth können in
der verteilten Rechnerumge bung verwendet werden. Bluetooth kann
Verschlüsselungsschlüssel unterstützen. Verschlüsselungsschlüssel sind
transportabhängig, während Schlüssel von
Clients, Diensten und Kombinationen transportunabhängig sein
können.
-
26a – Ein Authentisierungsdienst,
der einen Authentisierungsnachweis für einen Client bereitstellt
-
26a ist ein Flußdiagramm, das einen Authentisierungsdienst
darstellt, der einen Authentisierungsnachweis für einen Client gemäß einer
Ausführungsform
bereitstellt. Ein Client in der verteilten Rechnerumgebung kann
wünschen,
daß ein
Dienst eine oder mehrere Funktionen im Namen des Client durchführt. In
einer Ausführungsform
kann ein Authentisierungsdienst zum Gebrauch durch den Client und
den Dienst zur Verfügung
stehen, wenn ein sicherer Nachrichtenkanal aufgebaut wird. Ein Authentisierungsdienst
kann für
den Client und/oder den Dienst Funktionen ausführen einschließlich der
Authentisierung des Client und/oder des Dienstes und des Verhandelns
der gewünschten
Sicherheitsstufe und der Menge von Nachrichten, die zwischen dem
Client und dem Dienst übergeben
werden können.
Der Authentisierungsdienst kann ein Prozeß sein, der innerhalb der verteilten
Rechnerumgebung ausgeführt
wird. Der Authentisierungsdienst kann auf derselben Einrichtung
wie der Dienst und/oder der Client ausgeführt werden, oder der Authentisierungsdienst kann
alternativ auf einer separaten Einrichtung wie einem Authentisierungsserver
ausgeführt
werden. In einer Ausführungsform
kann der Authentisierungsdienst ein Internet-basierter Dienst sein.
Der Authentisierungsdienst kann seine eigene Adresse haben, zum
Beispiel einen Universal Resource Identifier (URI), über die
der Client und/oder Dienst mit dem Authentisierungsdienst kommunizieren
kann. In einer Ausführungsform
kann die Adresse des Authentisierungsdienstes dem Client in der
Dienstannonce für
den Dienst zur Verfügung
gestellt werden. Die gemeinsame Nutzung des Authentisierungsdienstes
durch den Client und den Dienst hilft sicherzustellen, daß ein sicherer
Nachrichtenkanal zwischen dem Client und dem Dienst aufgebaut wird,
da jedes von mehreren Sicherheits- und Authentisierungsprotokollen
in dem Nachrichtenkanal verwendet werden kann.
-
In
einer Ausführungsform
kann ein Client ein Token oder einen Berechtigungsnachweis zur Identifizierung
des Client dem Authentisierungsdienst übergeben. Das Client-Token
oder der Berechtigungsnachweis des Client kann ausreichend fälschungssicher
sein, um als Beweis für
die Identität
des Client verwendet zu werden. Der Authentisierungsdienst kann
daraufhin das Token oder den Berechtigungsnachweis zur Identifizierung
des Client überprüfen und
an den Client einen Authentisierungsnachweis ausgeben, den nur der
Authentisierungsdienst erstellen kann. Der Authentisierungsnachweis,
der an den Client zurückgegeben
wird, wird dann in jeder Nachricht von dem Client an den Dienst
gesendet. In einer Ausführungsform
wird das Nachrichtengatter des Client von einer Gatterfabrik erstellt,
die den Authentisierungsnachweis in das Nachrichtengatter aufnimmt,
wodurch das Nachrichtengatter den Authentisierungsnachweis in jede
Nachricht einbezieht, die im Namen des Client an den Dienst gesendet
wird. Beim Empfang eine Nachricht kann der Dienst dann den Authentisierungsnachweis überprüfen. Da
nur der Authentisierungsdienst den Authentisie rungsnachweis erstellen
kann, weiß der
Dienst, daß der
Client den Authentisierungsnachweis nicht gefälscht hat. In einer Ausführungsform
kann der Dienst den Authentisierungsnachweis an denselben Authentisierungsdienst übergeben,
der durch den Client benutzt wurde, um sicherzustellen, daß der Authentisierungsnachweis
gültig
ist, um zu überprüfen, daß der Client
ein autorisierter Client ist und um die Identität des Client herauszufinden.
-
Alle
Dienste einschließlich
des Space-Dienstes und des Authentisierungsdienstes können ihre
Clients authentisieren. Sobald ein Dienst einen Client authentisiert,
kann der Client auf den Dienst zugreifen. Zum Beispiel kann im Fall
eines Space-Dienstes ein Client daraufhin XML-Annoncen von dem Space erhalten.
-
In
einer Ausführungsform
kann ein Dienst einen vorab bereitgestellten Berechtigungsnachweis
haben, den alle Clients des Dienstes benutzen sollen. In dieser
Ausführungsform
kann die Authentisierung den vorab bereitgestellten Berechtigungsnachweis
einem Client, der ihn anfordert, zur Verfügung stellen. Jeder Client, der
den vorab bereitgestellten Berechtigungsnachweis dem Dienst vorlegt,
kann von dem Dienst anerkannt werden.
-
In
Schritt 1000 kann der Client einen Authentisierungsnachweis
von dem Authentisierungsdienst anfordern. In einer Ausführungsform
kann der Client nach einer Dienstannonce für den gewünschten Dienst suchen und sie
lokalisieren. In einer Ausführungsform
kann die Dienstannonce eine Annonce für den Authentisierungsdienst
enthalten, der zum Erhalt eines Authentisierungsnachweises zu verwenden
ist, der beim Zugriff auf den Dienst zu benutzen ist. In einer Ausführungsform
kann die Dienstannonce eine Adresse wie einen URI für den Authentisierungsdienst
beinhalten. In einer Ausführungsform
kann der Client Information an den Authentisierungsdienst senden,
die den Authentisierungsnachweis anfordert. In einer Ausführungsform
kann der Client Information an den Prozeß zur Gattererzeugung, zum
Beispiel eine Gatterfabrik, senden, und der Prozeß zur Gattererzeugung
kann auf den Authentisierungsdienst zugreifen, um den Authentisierungsnachweis zu
erhalten.
-
In
Schritt 1002 kann der Authentisierungsdienst einen Authentisierungsnachweis
für den
Client erzeugen. Der Authentisierungsnachweis kann ein Datenelement
oder eine Datenstruktur sein, das bzw. die in Nachrichten in einem
Nachrichtensystem eingebettet werden kann und das bzw. die es den
Empfängern
der Nachrichten ermöglichen
kann, den Sender der Nachricht zu authentisieren, um zu prüfen, daß die Nachricht von
einem autorisierten Sender kommt, und um zu prüfen, daß die Nachricht eine Nachricht
ist, die der Sender an den Empfänger
senden darf. In einer Ausführungsform
der verteilten Rechnerumgebung kann ein Authentisierungsnachweis
für den
Nachrichtenkanal eindeutig sein, der zwischen einem bestimmten Client
und einem bestimmten Dienst aufgebaut wurde. Schritt 1002 ist
in 26b weiter dargestellt und
beschrieben. In Schritt 1004 von 26a kann
der Authentisierungsdienst den Authentisierungsnachweis an den Client
zurückliefern. In
einer Ausführungsform
kann der Authentisierungsnachweis direkt an den Client zurückgeliefert
werden. In einer Ausführungsform
kann der Authentisierungsnachweis an einen Pro zeß zur Gattererzeugung, zum
Beispiel eine Gatterfabrik, zurückgeliefert
werden, der daraufhin den Authentisierungsnachweis beim Erzeugen eines
Gatters verwenden kann.
-
26b – Ein Authentisierungsdienst
der einen Authentisierungsnachweis erzeugt
-
26b ist ein Flußdiagramm, das Schritt 1002 von 26a erweitert und einen Authentisierungsdienst
darstellt, der einen Authentisierungsnachweis gemäß einer
Ausführungsform
erzeugt. In Schritt 1002a kann der Authentisierungsdienst
In einer Ausführungsform
ein Client-Token und ein Dienst-Token erhalten. In einer anderen
Ausführungsform
kann der Authentisierungsdienst nur ein Client-Token erhalten. In
einer Ausführungsform
kann das Client-Token ein eindeutiger Bezeichner für den Client
in der verteilten Rechnerumgebung sein. In einer Ausführungsform
kann das Dienst-Token ein eindeutiger Bezeichner für den Dienst
in der verteilten Rechnerumgebung sein. Zum Beispiel können die öffentlichen
Schlüssel
von einem Verschlüsselungsmechanismus
mit öffentlichen/privaten
Schlüsseln
als eindeutige Bezeichner für
den Client und den Dienst verwendet werden. In einer Ausführungsform
kann der Client das Dienst-Token in der Dienstannonce empfangen,
und der Client kann das Client-Token und das Dienst-Token an den
Authentisierungsdienst übergeben.
In einer anderen Ausführungsform
kann der Client das Dienst-Token und den URI der Dienstannonce an
den Authentisierungsdienst übergeben,
und der Authentisierungsdienst kann das Dienst-Token aus der Dienstannonce
abholen.
-
In
Schritt 1002b kann der Authentisierungsdienst den Client
und/oder den Dienst überprüfen. In
einer Ausführungsform
kann der Authentisierungsdienst die in Schritt 1002a erhaltenen
Client- und Dienst-Token zum Überprüfen des
Client und/oder des Dienstes verwenden. In einer anderen Ausführungsform
wurde in Schritt 1002a nur ein Client-Token erhalten, und
somit wird in Schritt 1002b nur das Client-Token zum Überprüfen des
Client verwendet. In einer Ausführungsform
kann der Client sein Client-Token zuvor bei dem Authentisierungsdienst
registriert haben, und der Authentisierungsdienst kann das empfangene
Client-Token mit dem registrierten Client-Token vergleichen, um
den Client als einen gültigen
Client zu überprüfen. In
einer Ausführungsform
kann der Client auf den Authentisierungsdienst mittels eines Challenge/Response-Mechanismus wie
z.B. eine Anmeldekennung mit Paßwort
zugreifen und somit als ein gültiger
Client überprüft werden.
In einer Ausführungsform
kann der Dienst sich zuvor bei dem Authentisierungsdienst registriert
haben und kann sein Dienst-Token an den Authentisierungsdienst übergeben
haben. Der Authentisierungsdienst kann dann überprüfen, ob der Client auf einen
gültigen
Dienst zuzugreifen versucht, indem er das empfangene Dienst-Token
mit dem zuvor registrierten Dienst-Token vergleicht. Andere Arten
von Client- und Dienst-Authentisierung können ebenso verwendet werden.
Zum Beispiel kann der Client eine digitale Unterschrift oder einen
digitalen Berechtigungsnachweis bereitstellen, die bzw. den der
Authentisierungsdienst zur Authentisierung des Client und/oder zur
Authentisierung des Dienstes, auf den der Client zuzugreifen versucht,
verwenden kann.
-
In
Schritt 1002c kann der Authentisierungsdienst einen Authentisierungsnachweis
erzeugen. In einer Ausführungsform
kann der Authentisierungsnachweis ein Authentisierungstoken enthalten, das
nur der Authentisierungsdienst erzeugen kann. In einer Ausführungsform
kann der Authentisierungsdienst das Client-Token und das Dienst-Token
beim Erzeugen des Authentisierungsnachweises verwenden. In einer
anderen Ausführungsform
kann der Authentisierungsdienst nur das Client-Token zum Erzeugen des Authentisierungsnachweises
verwenden. Nach noch einer anderen Ausführungsform verwendet der Authentisierungsdienst
möglicherweise
kein erhaltenes Token zum Erzeugen des Authentisierungsnachweises,
sondern kann stattdessen einen Algorithmus zum Erzeugen eines Authentisierungsnachweises
verwenden, um einen im Wesentlichen nicht fälschbaren Authentisierungsnachweis
zu erzeugen. In einer Ausführungsform
kann der Authentisierungsdienst das Dienst-Token und das Client-Token
zum Erzeugen eines eindeutigen bzw. einzigartigen Authentisierungsnachweises
kombinieren. Zum Beispiel können
das Dienst-Token und das Client-Token 64-Bit-Werte
sein, und die zwei Token können
zum Erzeugen eines 128-Bit-Authentisierungsnachweises
kombiniert werden. Andere Ausführungsformen
können
andere Verfahren zum Erzeugen eines Authentisierungsnachweises verwenden.
-
41 – Erzeugen
eines Gatters
-
41 ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
das Erzeugen eines Gatters für einen
Client darstellt. In einer Ausführungsform
kann eine Gatterfabrik vertrauenswürdiger Code auf dem Client
zum Herstellen von Gattern basierend auf XML-Dienstbeschreibungen
sein. In einer anderen Ausführungsform
kann sich die Gatterfabrik auf einer separaten Einrichtung befinden
und kann von dem Client zum Erzeugen von Gattern verwendet werden.
Zum Beispiel kann ein Gatterfabrik-Dienst von dem Client zum Erzeugen von
Gattern zugreifbar sein. Die Verwendung der Gatterfabrik kann sicherstellen,
daß die
erzeugten Gatter vertrauenswürdiger
Code sind und daß der
Code bezüglich
der Dienstannonce korrekt ist.
-
Sicherheitsüberprüfungen,
die zum Zeitpunkt der Erzeugung eines Gatters durchgeführt werden,
können
ausführlich
bzw. umfangreich sein und damit die Anzahl von Sicherheitsüberprüfungen minimieren,
die während
der Verwendung eines Gatters durchgeführt werden müssen. Sicherheitsüberprüfungen während der Erzeugung
eines Gatters können
dazu beitragen, sicherzustellen, daß der Client die Berechtigung
zum Benutzen der Menge von Dienstleistungsmerkmalen hat, die in
dem aus der Dienstannonce geholten Nachrichtenschema angegeben ist.
In einer Ausführungsform
können
die Sicherheitsüberprüfungen mittels
Zugriffskontrollisten (Access Control Lists, ACLs) in Verbindung
mit einem Authentisierungsdienstimplementiert werden. In einer Ausführungsform
kann eine Challenge-Response-Sequenz (wie eine Anmelde- und Paßwortkennung) zum
Authentisieren eines Client verwendet werden. In einer Ausführungsform
kann das Authentisieren eines Client und die Sicherheitsüberprüfungen beim
Erzeugung eines Gatters von dem Client und dem Dienst verborgen
bleiben, womöglich
nur die Gatterfabrik kann den zu verwendenden Authentisierungsdienst
kennen, und der Authentisierungsdienst kann den Authentisierungsmechanismus
und die Authentisierungsrichtlinien kennen.
-
In
Schritt 1010 kann die Gatterfabrik einen Authentisierungsnachweis
für den
Client zur Verwendung bei der Kommunikation mit einem Dienst erhalten.
In einer Ausführungsform
kann der Client zuvor den Authentisierungsnachweis von einem Authentisierungsdienst
erhalten haben und kann dann den Authentisierungsnachweis der Gatterfabrik übergeben.
In einer anderen Ausführungsform
kann die Gatterfabrik den Authentisierungsnachweis von dem Authentisierungsdienst
erhalten.
-
In
einer Ausführungsform
kann die Gatterfabrik auch ein Nachrichtenschema für den Dienst
erhalten. In einer Ausführungsform
kann die Gatterfabrik das Nachrichtenschema von dem Client erhalten.
In einer anderen Ausführungsform
kann die Gatterfabrik das Nachrichtenschema aus einer Dienstannonce
empfangen. Zum Beispiel kann der Client einen URI für die Dienstannonce
an die Gatterfabrik liefern, und die Gatterfabrik kann mit der Dienstannonce
mittels des URI Verbindung aufnehmen, um das Nachrichtenschema zu
erhalten. Das Nachrichtenschema kann die Menge von Nachrichten beschreiben,
die an den Dienst gesendet werden oder von dem Dienst empfangen
werden können.
Zum Beispiel können
Nachrichten beschrieben werden, die von einem Client an einen Dienst
gesendet werden können,
um den Dienst aufzurufen oder Aspekte des Dienstes aufzurufen. Ebenso
können
Nachrichten beschrieben werden, die von dem Dienst an den Client
gesendet werden können,
wie Antwortnachrichten und Nachrichten für Ereignismeldungen. In einer
Ausführungsform
können
die Nachrichten XML-Nachrichten sein, und das Nachrichtenschema
kann ein XML-Nachrichtenschema sein.
-
In
Schritt 1012 kann die Gatterfabrik ein Nachrichtengatter
des Client erzeugen. In einer Ausführungsform kann die Gatterfabrik
den Authentisierungsnachweis als Daten in das erzeugte Nachrichtengatter
einbetten, so daß der
Code des Nachrichtengatters auf den Authentisierungsnachweis zugreifen
kann. In einer anderen Ausführungsform
kann der Authentisierungsnachweis außerhalb des Nachrichtengatters
auf dem Client gespeichert sein. In einer Ausführungsform kann ein URI für den Dienst
von der Gatterfabrik in das Gatter eingebettet oder dem Gatter zur
Verfügung
gestellt werden.
-
In
Schritt 1012 kann die Gatterfabrik auch das Nachrichtenschema
beim Erzeugen des Nachrichtengatters des Client verwenden. Das Nachrichtenschema
kann zur Definition der Menge von Nachrichten verwendet werden,
die der Client über
das Nachrichtengatter an den Dienst senden kann. Die Gatterfabrik
kann das Nachrichtenschema in das Gatter kompilieren. Das Nachrichtenschema
kann von der Gatterfabrik in einer internen Form, die für einen
schnellen Zugriff während
des Überprüfungsvorgangs
einer Nachricht geeignet ist, in das Gatter kompiliert sein. Der
Zugriff auf einen Dienst kann für
einen bestimmten Client mittels des Schemas eingeschränkt werden,
wodurch dem Client weniger als der volle Zugriff auf den Dienst
gegeben wird. Wenn der Client In einer Ausführungsform die Dienstannonce
zum Beispiel von einem Space erhält,
kann basierend auf den Leistungsmerkmalen und/oder Zugriffsrechten
des Client ein eingeschränktes
Nachrichtenschema für
den Dienst dem Client zur Verfügung
gestellt werden. Daher kann die Gatterfabrik ein eingeschränktes Nachrichtenschema
in das Nachrichtengatter des Client kompilieren, wodurch der Zugriff des
Client auf den Dienst eingeschränkt
wird. In einer Ausführungsform
kann der Authentisierungsdienst eine Teilmenge der Gesamtmenge von
Nachrichten festlegen, die der Client an den Dienst senden kann.
Eine oder mehrere Zugriffsstufen können für einen Dienst in der verteilten
Rechnerumgebung vorgesehen sein. Eine Zugriffsstufe kann einen Client
des Dienstes mit dem Zugriff auf alle angeforderten Nachrichten
in dem Nachrichtenschema für
den Dienst und somit im Wesentlichen auf alle Funktionen versehen,
die von dem Dienst für Clients
in der verteilten Rechnerumgebung bereitgestellt werden. Andere
Stufen können
einen Client des Dienstes mit Zugriff auf verschiedene Teilmengen
der angeforderten Nachrichten in dem Nachrichtenschema und somit
zu verschiedenen Teilmengen der Funktionalität des Dienstes versehen. In
einer Ausführungsform können Zugriffsstufen
auch durch die Leistungsmerkmale eines Client festgelegt sein. Zum
Beispiel ist ein Thin-Client möglicherweise
nicht in der Lage, große
Datendateien herunterzuladen und somit von der Verwendung einer
Nachricht, die das Herunterladen einer großen Datendatei anfordert, ausgeschlossen.
-
In
einer Ausführungsform
kann der Client Information über
den Client dem Authentisierungsdienst zur Verfügung stellen, um eine Zugriffsstufe
für den
Client festzulegen. In einer Ausführungsform kann die Information
eine Anforderung für
eine spezifische Zugriffsstufe auf den Dienst enthalten. In einer
Ausführungsform kann
die Gatterfabrik die Information dem Authentisierungsdienst zur
Verfügung
stellen, um die Zugriffsstufe des Client festzulegen. Somit kann
die Gatterfabrik ein Nachrichtengatter des Client erzeugen, das
in der Lage ist, eine Teilmenge der gesamten Menge der in dem Nachrichtenschema
beschriebenen Nachrichten an den Dienst zu senden basierend auf
den Leistungsmerkmalen und/oder der Zugriffsstufe des Client.
-
In
Schritt 1014 hat die Gatterfabrik das Nachrichtengatter
des Client erzeugt und kann den Client benachrichtigen, daß das Gatter
erzeugt wurde. In einer Ausführungsform
ist das Nachrichtengatter des Client ein ausgeprägtes Codemodul, auf das von
dem Client zugegriffen werden kann. In einer Ausführungsform kann
sich das Nachrichtengatter des Client auf dem Client befinden. Der
Client kann daraufhin Nachrichten erzeugen und die Nachrichten an
das Nachrichtengatter des Client übergeben, das die Nachrichten überprüfen und
an den Dienst senden kann. Ausführungsformen
eines Gatterpaar-Mechanismus' für den Client
und den Dienst zum Austausch von Nachrichten sind in den 42a-42c weiter
beschrieben. Ausführungsformen von
Gatterfabriken werden an anderer Stelle weiter beschrieben.
-
Ein
Gatter weist Code und Daten auf und kann somit selbst in einer Nachricht übergeben
werden. Dies stellt eine alternatives Verfahren zum Herstellen von
Gattern auf Clients und/oder Diensten zur Verfügung. In einer Ausführungsform
kann ein in einer Nachricht übergebenes
Gatter geklont werden, wenn ein neuer Client das Gatter verwenden
möchte.
Der Klonierungsvorgang kann einen neuen Satz von Sicherheitsüberprüfungen beim
Erzeugen von Gattern einschließlich
der Authentisierung des neuen Client durchführen. Ein neuer, eindeutiger
Authentisierungsnachweis kann für
den neuen Client erzeugt und in das geklonte Gatter eingebettet werden.
-
42a – Ein Client.
der eine Nachricht an einen Dienst sendet
-
42a ist ein Flußdiagramm, das einen Client
darstellt, der gemäß einer
Ausführungsform
eine erste Nachricht an einen Dienst sendet. In Schritt 1020 kann
der Client eine Nachricht an das Nachrichtengatter des Client senden.
In einer Ausführungsform
kann die Nachricht eine XML-Nachricht
sein. In Schritt 1022 kann das Nachrichtengatter vor dem
Senden der Nachricht einen Authentisierungsnachweis in die Nachricht
einbetten. In einer Ausführungsform
kann der Authentisierungsnachweis von einem Authentisierungsdienst
als Teil der Gattererstellung wie oben beschrieben zur Verfügung gestellt
worden sein.
-
In
einer Ausführungsform
kann das Nachrichtengatter die Richtigkeit der Typen der Datenrepräsentationssprache,
der Syntax etc. in der Nachricht überprüfen. In einer Ausführungsform
kann das Nachrichtengatter die Nachricht mit einer Nachrichtenvorlage
in einem Nachrichtenschema in einer Datenrepräsentationssprache vergleichen,
um die Richtigkeit der Typen der Datenrepräsentationssprache in der Nachricht
zu ermitteln. In einer Ausführungsform
kann die Nachricht eine XML-Nachricht
sein, und das Nachrichtengatter kann die Nachricht gegen ein XML-Nachrichtenschema
prüfen.
In einer Ausführungsform
kann das Nachrichtenschema von einem Authentisierungsdienst als
Teil der Gattererstellung wie oben beschrieben zur Verfügung gestellt
worden sein. In einer Ausführungsform
kann das Nachrichtengatter eine Nachrichtenvorlage für die Nachricht
in dem Schema lokalisieren und die verschiedenen Gegenstände oder
Felder in der Nachricht mit der Nachrichtenvorlage vergleichen,
um die Richtigkeit der Typen der Gegenstände zu ermitteln.
-
In
einer Ausführungsform
kann die erste Nachricht eine Anforderungsnachricht sein, die von
dem Client empfangen wurde, um an den Dienst gesendet zu werden,
und das Nachrichtengatter kann herausfinden, ob die Nachricht und/oder
die angeforderte(n) Dienstfunktion(en), die von der Nachricht angegeben
werden, in der erlaubten Teilmenge der Nachrichten und/oder Dienstfunktionen
liegt bzw. liegen, die der Client an den Dienst senden darf. In
einer Ausführungsform
kann das Nachrichtengatter die Nachricht mit der Teilmenge der erlaubten
Nachrichten in dem Nachrichtenschema vergleichen, um herauszufinden,
ob die Nachricht erlaubt ist. In einer Ausführungsform kann eine Zugriffsstufe
zu dem Dienst, die dem Client von einem Authentisierungsdienst zur
Verfügung
gestellt wird, verwendet werden, um die Teilmenge der erlaubten
Nachrichten zu ermitteln, die der Client an den Dienst senden darf.
In einer Ausführungsform
kann die erste Nachricht den Dienst auffordern, einen Kommunikationskanal
mit dem Client aufzubauen. In einer Ausführungsform kann der Kommunikationskanal
ein Gatterpaar aufweisen. Das Gatterpaar kann ein Nachrichtengatter
des Client und ein Nachrichtengatter des Dienstes aufweisen. In
einer Ausführungsform
ist das Nachrichtengatter des Dienstes möglicherweise auf dem Dienst
nicht vorhanden, wenn die erste Nachricht an den Dienst gesendet
wird.
-
In
Schritt 1024 kann das Nachrichtengatter des Client diese
erste Nachricht über
den Kommunikationskanal, der den Client mit dem Dienst verbindet,
an den Dienst senden. In einer Ausführungsform kann das Nachrichtengatter
des Client die Nachricht an einen Dienst-URI senden. In einer Ausführungsform
kann der Dienst-URI dem Client in der Dienstannonce bereitgestellt
worden sein. In einer Ausführungsform
kann das Nachrichtengatter des Client für eine spezifische Dienst-URI erstellt worden
sein, so daß alle
Nachrichten an den spezifischen Dienst-URI gesendet werden, wodurch
ein Nachrichtenkanal von dem Client zu dem Dienst erzeugt wird.
In einer Ausführungsform
kann die Anforderungsnachricht eine Adresse für das Nachrichtengatter des
Client beinhalten, so daß der
Dienst über
das Nachrichtengatter des Client eine Kommunikationsverbindung zu
dem Client aufbauen kann. Beispiele von Adressen, die für Nachrichtengatter
verwendet werden können,
umfassen, sind jedoch nicht eingeschränkt auf: Universal Unique Identifiers
(UUIDs) oder URIs. Der Vorgang eines Dienstes, der eine erste Nachricht
von einem Client empfängt,
ist in 42b dargestellt und beschrieben.
-
42b – Eine Dienst.
der eine Nachricht von einem Client empfängt
-
42b ist ein Flußdiagramm, das einen Dienst
darstellt, der eine Nachricht von einem Client empfängt und
einen Authentisierungsdienst zum Authentisieren der Nachricht gemäß einer
Ausführungsform
verwendet. In Schritt 1030 kann der Dienst eine erste Nachricht
von dem Client empfangen. In einer Ausführungsform ist das Nachrichtengatter
des Dienstes möglicherweise
nicht auf dem Dienst vorhanden, wenn die erste Nachricht von dem
Dienst empfangen wird. In einer Ausführungsform kann das Nachrichtengatter
des Client eine erste Nachricht an den URI bei dem Dienst senden,
und der Dienst kann die erste Nachricht von dem Client empfangen
und daraufhin ein Nachrichtengatter des Dienstes erzeugen. In einer
Ausführungsform
kann ein Mechanismus auf dem Dienst eingerichtet werden, um allgemein
Nachrichten einschließlich
Nachrichten von Clients an einem URI zu empfangen, der dem Client
in der Dienstannonce zur Verfügung
gestellt wurde. Beim Empfang einer ersten Nachricht von einem Client
kann der Dienst ein Dienstgatter errichten, um dadurch einen Nachrichtenkanal
mit dem Client durch das Gatterpaar aufzubauen, das aus dem Nachrichtengatter
des Dienstes und dem Nachrichtengatter des Client besteht. In einer
Ausführungsform
kann eine Adresse (zum Beispiel ein UUID oder ein URI) für das Nachrichtengatter
des Client dem Dienst in der ersten Nachricht von dem Client übergeben
werden und kann zum Erstellen des Nachrichtengatters des Dienstes
verwendet werden. In einer Ausführungsform
kann das Nachrichtengatter des Dienstes nur mit dem Nachrichtengatter
des Client und somit mit dem dem Nachrichtengatter zugeordneten
Client kommunizieren. Somit kann es nach einigen Ausführungsformen
mindestens ein eindeutiges Nachrichtengatters des Dienstes für jeden
Client geben, der aktuell in Kommunikation mit dem Dienst steht.
-
Wie
oben beschrieben, kann das Nachrichtengatter des Client einen Authentisierungsnachweis
in der ersten Nachricht eingebettet haben, die an den Dienst gesendet
wird. In Schritt 1032 kann der Dienst den Authentisierungsnachweis
an einen Authentisierungsdienst senden. In einer Ausführungsform
kann der Authentisierungsdienst derselbe Authentisierungsdienst
sein, der von dem Client zum Erzeugen des Authentisierungsnachweises
verwendet wurde. In einer Ausführungsform
kann das Nachrichtengatter des Dienstes den Authentisierungsnachweis
an den Authentisie rungsdienst senden. In einer Ausführungsform
kann die gesamte Nachricht an den Authentisierungsdienst gesendet
werden.
-
In
Schritt 1034 kann der Authentisierungsdienst eine Überprüfung des
Authentisierungsnachweises durchführen. In einer Ausführungsform
kann der Authentisierungsdienst eine Kopie des Authentisierungsnachweises
aus der Erzeugung des Authentisierungsnachweises enthalten. In einer
Ausführungsform
kann der Authentisierungsdienst den von dem Dienst empfangenen Authentisierungsnachweis
mit der Kopie des Authentisierungsnachweises vergleichen. Wenn die
Authentisierungsnachweise übereinstimmen,
kann der Authentisierungsdienst in Schritt 1036 den Dienst
benachrichtigen, daß der
Authentisierungsnachweis überprüft wurde und
gültig
zu sein scheint. Wenn der Überprüfungsvorgang
fehlschlägt,
kann der Authentisierungsdienst den Dienst benachrichtigen, daß der Authentisierungsnachweis
ungültig
zu sein scheint.
-
In
einer Ausführungsform
kann der Authentisierungsdienst eine Zugriffsstufe für den Client
einrichten, um auf die Funktionalität des Dienstes zuzugreifen.
In einer Ausführungsform
kann der Client eine Zugriffsstufe für den Dienst bei dem Authentisierungsdienst
eingerichtet haben. In einer Ausführungsform kann der Authentisierungsdienst
den Dienst über
die Zugriffsstufe des Client benachrichtigen. Die Zugriffsstufe
des Client kann von dem Dienst verwendet werden, um eine Teilmenge
von Anforderungsnachrichten, wie in dem Nachrichtenschema des Dienstes
beschrieben, festzulegen, die der Client an den Dienst senden kann.
-
In
Schritt 1038 kann der Dienst ein Nachrichtengatter des
Dienstes erzeugen, wenn der Authentisierungsdienst den Dienst benachrichtigt
hat, daß der
Authentisierungsnachweis in Schritt 1036 gültig ist,
um mit dem Clientgatter ein Gatterpaar zu bilden. Das Nachrichtengatter
des Dienstes kann den Authentisierungsnachweis beinhalten, um ihn
in Nachrichten einzubetten, die von dem Dienst an den Client gesendet
werden, und zum Vergleich mit dem Authentisierungsnachweis in Nachrichten,
die von dem Client empfangen werden. Das Nachrichtengatter des Dienstes
kann auch eine Adresse (wie einen UUID oder einen URI) für das Nachrichtengatter
des Client beinhalten. Das Nachrichtengatter des Dienstes kann auch
Information über
die Zugriffsstufe für
den Client enthalten, um zu überprüfen, daß von dem
Client empfangene Nachrichten in der Teilmenge von erlaubten Nachrichten
liegen, die der Client an den Dienst senden darf. Das Nachrichtengatter
des Dienstes kann auch ein Nachrichtenschema zur Typprüfung und Überprüfung der
Syntax von vom Client empfangenen Nachrichten und zur Verwendung
bei der Überprüfung enthalten,
ob Nachrichten in der erlaubten Teilmenge von Nachrichten liegen.
In einer Ausführungsform
kann der Dienst ein neues Nachrichtengatter des Dienstes erzeugen.
In einer anderen Ausführungsform
kann ein Nachrichtengatter des Dienstes bereits vor dem Schritt 1038 vorhanden
sein, das zur Erzeugung des Nachrichtengatters des Dienstes zur
Kommunikation mit dem Client verwendet werden kann. In dieser Ausführungsform
erzeugt der Dienst möglicherweise
kein neues Gatter, sondern kann stattdessen das vorhandene Gatter
mit Information über
den Nachrichtenkanal aktualisieren, der zwischen dem Client und
dem Dienst aufzubauen ist.
-
In
einer Ausführungsform
kann der Dienst eine Nachricht an den Client senden, nachdem der
Dienst das Nachrichtengatter des Dienstes erzeugt hat. Die Nachricht
kann Information enthalten, um das Nachrichtengatter des Dienstes
gegenüber
dem Nachrichtengatter des Client zu identifizieren und somit den
Kommunikationskanal zwischen dem Client und dem Dienst mittels des
Nachrichtengatterpaares aufzubauen. In einer Ausführungsform
kann die Nachricht eine Adresse (wie einen UUID oder einen URI)
für das
Nachrichtengatter des Dienstes enthalten.
-
42c – Austausch
von Nachrichten mit eingebetteten Authentisierungsnachweisen
-
42c ist ein Flußdiagramm, das den allgemeinen
Vorgang des Nachrichtenaustauschs zwischen einem Client und einem
Dienst mit eingebettetem Authentisierungsnachweis gemäß einer
Ausführungsform darstellt.
In einer Ausführungsform
brauchen der Client und der Dienst nicht mehr die Dienste des Authentisierungsdienstes,
nachdem das Nachrichtengatter des Client und das Nachrichtengatter
des Dienstes eingerichtet sind. Beim Senden von Nachrichten können die
Nachrichtengatter des Client und des Dienstes den Authentisierungsnachweis
in die Nachrichten einbetten. Beim Empfang von Nachrichten können die
Nachrichtengatter des Client und des Dienstes die Nachricht durch
Vergleich des eingebetteten Authentisierungsnachweises mit der in
dem Gatter enthaltenen Kopie des Authentisierungsnachweises überprüfen.
-
In
Schritt 1040 kann das Nachrichtengatter des Senders (Client
oder Dienst) einen Authentisierungsnachweis in eine Nachricht vor
dem Senden der Nachricht einbetten. In einer Ausführungsform
kann der Authentisierungsnachweis von einem Authentisierungsdienst
zur Verfügung
gestellt worden sein. In einer Ausführungsform kann die Nachricht
eine XML-Nachricht sein.
-
In
einer Ausführungsform
kann das Nachrichtengatter des Senders die Richtigkeit der Typen
in der Datenrepräsentationssprache,
die Syntax, etc. der Nachricht vor dem Senden der Nachricht überprüfen. In
einer Ausführungsform
kann das Nachrichtengatter des Senders die Nachricht mit einer Nachrichtenvorlage
in einem Nachrichtenschema vergleichen, um die Richtigkeit der Typen
in der Nachricht zu ermitteln. Zum Beispiel kann die Nachricht eine
XML-Nachricht sein, und das Nachrichtengatter kann ein XML-Nachrichtenschema enthalten.
Das Nachrichtengatter des Senders kann eine Nachrichtenvorlage für die Nachricht
in dem Schema lokalisieren und die verschiedenen XML-Gegenstände oder
-Felder in der Nachricht mit der Nachrichtenvorlage vergleichen,
um die Richtigkeit der Typen bei den Gegenständen zu ermitteln.
-
In
einer Ausführungsform
kann das Nachrichtengatter des Senders die Zulässigkeit der Nachricht überprüfen. In
einer Ausführungsform
kann die Nachricht eine Anforderungsnachricht sein, die von einem
Client zum Senden an einen Dienst empfangen wurde, und das Nachrichtengatter
kann feststellen, ob die durch die Nachricht angeforderte(n) Funktion(en)
in der Teilmenge von Funktionen liegen, die dem Client durch die Zugriffsstufe
zur Verfügung
stehen, die der Client mit dem Dienst durch den Authentisierungsdienst
eingerichtet hat. In einer Ausführungsform
kann das Nachrichtengatter die Nachricht mit einer Teilmenge von
erlaubten Anforderungsnachrichten in einem Nachrichtenschema vergleichen,
um festzustellen, ob die Nachricht erlaubt ist. In einer Ausfüh rungsform
wird die Nachricht möglicherweise
nicht auf Zulässigkeit überprüft, wenn
die Nachricht eine Antwortnachricht von einem Dienst an einen Client
ist. In einer anderen Ausführungsform
können
Antwortnachrichten von dem Dienst an den Client durch das Nachrichtengatter
des Client überprüft werden,
um sicherzustellen, daß der
Client zum Empfang der Antwortnachricht autorisiert ist.
-
In
Schritt 1042 kann das Nachrichtengatter des Senders (Client
oder Dienst) daraufhin die Nachricht an das Nachrichtengatter des
Zieles (Client oder Dienst) über
den Kommunikationskanal senden, der die Quelle (Client oder Dienst)
mit dem Ziel (Client oder Dienst) verbindet. In einer Ausführungsform
können
die Nachrichtengatter beim Empfang der Nachricht den Sender der
Nachricht durch Vergleich des eingebetteten Authentisierungsnachweises
mit der in dem Gatter enthaltenen Kopie des Authentisierungsnachweises überprüfen.
-
In
einer Ausführungsform
kann die Nachricht vor dem Senden verschlüsselt werden. In einer Ausführungsform
kann das Nachrichtengatter die Verschlüsselung durchführen. In
einer anderen Ausführungsform kann
ein Prozeß,
der zu dem Nachrichtengatter extern ist, die Verschlüsselung
durchführen.
Zum Beispiel kann das Nachrichtengatter die vervollständigte Nachricht
an einen Treiberprozeß für einen
Kommunikationskanal übergeben,
und der Treiberprozeß kann
die Verschlüsselung
der Nachricht durchführen.
In einer Ausführungsform
kann die Verschlüsselung
und die Entschlüsselung
von Nachrichten von einem Transportmechanismus (z. B. HTTPS) durchgeführt werden.
-
In
Schritt 1044 kann das Nachrichtengatter des Empfängers (Client
oder Dienst) die in Schritt 1042 gesendete Nachricht empfangen.
In einer Ausführungsform
kann die Nachricht, wenn sie verschlüsselt ist, durch einen Prozeß entschlüsselt werden,
bevor sie von dem Nachrichtengatter empfangen wird. In einer anderen
Ausführungsform
kann das Nachrichtengatter die Nachricht entschlüsseln, wenn sie verschlüsselt ist.
In Schritt 1046 kann das Nachrichtengatter des Empfängers den
Sender der Nachricht durch Vergleich des eingebetteten Authentisierungsnachweises
mit der in dem Empfängergatter
enthaltenen Kopie des Authentisierungsnachweises authentisieren.
-
Nach
einigen Ausführungsformen
können
bestimmte Dienste zumindest für
einige Clients keine Authentisierungsnachweise benötigen. In
einer Ausführungsform
kann ein Client, der auf einen Dienst zugreifen möchte, für den kein
Authentisierungsnachweis für
den Client erforderlich ist, ein Nachrichtengatter ohne Verwendung
eines Authentisierungsdienstes erzeugen. In einer anderen Ausführungsform
kann ein Authentisierungsdienst eine Null, einen leeren oder anderweitig
generischen Authentisierungsnachweis an einen Client zurückgeben,
der keine Authentisierung zur Nutzung eines Dienstes benötigt. In
einer Ausführungsform
ohne erforderliche Authentisierung können die Nachrichtengatter
Nachrichten ohne Einbetten von Authentisierungsnachweisen senden.
In einer anderen Ausführungsform
kann eine Null, ein leerer oder anderweitig generischer Authentisierungsnachweis
von den Nachrichtengattern in Nachrichten eingebettet werden.
-
In
einer Ausführungsform
kann das Nachrichtengatter des Empfängers beim Empfang der Nachricht die
Richtigkeit der Typen, die Syntax, etc. einer Nachricht in der Datenrepräsentationssprache überprüfen. In einer
Ausführungsform
kann das Nachrichtengatter des Empfängers die Nachricht mit einer
Nachrichtenvorlage in einem Nachrichtenschema vergleichen, um die
Richtigkeit der Typen in der Nachricht zu ermitteln. Zum Beispiel
kann die Nachricht eine XML-Nachricht sein, und das Nachrichtengatter
kann ein XML-Nachrichtenschema enthalten. Das Nachrichtengatter
des Empfängers
kann eine Nachrichtenvorlage für
die Nachricht in dem Schema lokalisieren und die verschiedenen XML-Gegenstände oder
-felder in der Nachricht mit der Nachrichtenvorlage vergleichen,
um die Richtigkeit der Typen in den Gegenständen zu ermitteln.
-
In
einer Ausführungsform
kann das Nachrichtengatter des Empfängers die Zulässigkeit
der Nachricht prüfen.
In einer Ausführungsform
kann die Nachricht eine Anforderungsnachricht von einem Client sein,
und das Nachrichtengatter kann feststellen, ob die in der Nachricht
angeforderte(n) Funktion(en) in der Teilmenge von Funktionen liegen,
die dem Client durch die Zugriffsstufe zur Verfügung stehen, die der Client
mit dem Dienst über
den Authentisierungsdienst eingerichtet hat. In einer Ausführungsform
kann das Nachrichtengatter des Empfängers die Nachricht mit einer
Teilmenge von erlaubten Anforderungsnachrichten in einem Nachrichtenschema
vergleichen, um zu ermitteln, ob die Nachricht erlaubt ist.
-
In
einer Ausführungsform
können
der Sender und der Empfänger
die Nachricht auf Richtigkeit der Typen und/oder Zulässigkeit überprüfen. In
einer anderen Ausführungsform
kann der Sender ein Überprüfung der
Nachricht durchführen.
Nach noch einer anderen Ausführungsform
braucht der Sender keine Überprüfung der
Nachricht durchzuführen,
und der Empfänger
kann ein Überprüfung der
Nachricht durchführen.
Nach noch einer weiteren Ausführungsform
braucht keine Überprüfung durchgeführt zu werden.
-
Einige
Clients können
zu "klein" bzw. "thin" sein, um die vollständige Funktionalität eines
Nachrichtengatter des Clients zu unterstützen. Diese Clients brauchen
einiges oder alles von der Überprüfung der
Anforderungsnachrichten vor dem Senden von Anforderungsnachrichten
und von der Überprüfung der
Antwortnachrichten im Anschluß an
den Empfang von Antwortnachrichten wie oben beschrieben nicht durchzuführen. Zum
Beispiel können
einige einfache Clienteinrichtungen eine kleine Menge von Anforderungsnachrichten,
die an einen Dienst gesendet werden können, und eine kleine Menge
von Antworten, die von dem Dienst akzeptiert werden können, beinhalten.
In einer Ausführungsform
kann ein minimales Nachrichtengatter eines Client für die Clienteinrichtung
eingerichtet werden, das Anforderungsnachrichten sendet und Antwortnachrichten empfängt, ohne
die oben beschriebene Überprüfung der
Nachrichten durchzuführen.
In einer anderen Ausführungsform
kann ein Proxy-Nachrichtengatter eines Client auf einer anderen
Einrichtung aufgebaut werden, das einiges oder alles von dem Überprüfen, Senden
und Empfangen der Nachrichten, wie oben für den Client beschrieben, zur
Verfügung
stellt.
-
43 – Prüfen der
Integrität
von Nachrichten
-
43 ist ein Flußdiagramm, das einen Mechanismus
zum Prüfen
der Integrität
von Nachrichten gemäß einer
Ausführungsform
darstellt. In Schritt 1050 kann das Sendergatter, das im
Namen eines Client oder eines Dienstes agiert, ein Token in eine
zu sendende Nachricht einbetten.
-
Dieses
Token ist separat und verschieden von dem oben beschriebenen Authentisierungsnachweis. Das
Token kann Information enthalten, die das empfangende Gatter in
die Lage versetzt zu überprüfen, daß die Nachricht
nicht beschädigt
oder geändert
wurde. Zum Beispiel kann der Sender einen Hash oder eine Prüfsumme der
Nachricht berechnen, der oder die von dem Empfänger überprüft werden kann. Der Sender
kann dieses Token und/oder die gesamte Nachricht auch mittels des
privaten Schlüssels
des Senders verschlüsseln und
in die verschlüsselte
Nachricht den entsprechenden öffentlichen
Schlüssel
einbeziehen, so daß der
Empfänger überprüfen kann,
daß das
Token nicht verändert
wurde. In Schritt 1052 kann das Sendergatter die Nachricht
senden. In Schritt 1054 kann das Empfängergatter, das im Namen eines
Dienstes oder eines Client agiert, die Nachricht empfangen. In Schritt 1056 kann
das Empfängergatter
die Nachricht und das eingebettete Token untersuchen, um zu überprüfen, daß die Nachricht
nicht beeinträchtigt
wurde.
-
Es
gibt einige Verfahren zum Erzeugen des Token, um es in die Nachricht
einzubetten. In einer Ausführungsform
kann ein Hash der Nachricht berechnet und mit der Nachricht gesendet
werden. Das Bilden eines Hash kann die Umwandlung einer Zeichenkette
in einen üblicherweise
kürzeren
Wert oder Schlüssel
fester Länge
umfassen, der die ursprüngliche
Zeichenkette repräsentiert.
Beim Empfang der Nachricht kann der Empfänger den Hash neu berechnen
und ihn gegen den gesendeten Hash prüfen. Wenn die Nachricht geändert wurde,
ist es höchst
unwahrscheinlich, daß derselbe
Hash erzeugt wird. Der Sender kann den Hash verschlüsseln und
den entsprechenden öffentlichen
Schlüssel
in der verschlüsselten
Nachricht senden, um im Wesentlichen sicherzustellen, daß der Hash
nicht beschädigt
wurde.
-
In
anderen Ausführungsformen
kann ein Verfahren zur Fehlerentdeckung wie eine zyklische Redundanzprüfung verwendet
werden. Eine zyklische Redundanzprüfung ist ein Verfahren zum
Prüfen
auf Fehlern in Daten, die auf einer Kommunikationsverbindung übertragen
werden. In einer Ausführungsform,
die zyklische Redundanzprüfung
benutzt, wendet der Sender ein n-Bit Polynom auf die Nachricht an
und hängt
den sich ergebenden zyklischen Redundanzcode (Cyclic Redundancy
Code, CRC) an die Nachricht an. Der Empfänger wendet dasselbe Polynom
(das auch in der Nachricht übergeben
werden kann) auf die Nachricht an und vergleicht sein Ergebnis mit
dem vom Sender angehängten
Ergebnis. Wenn sie übereinstimmen,
wurde die Nachricht erfolgreich übertragen.
Falls nicht, kann der Sender benachrichtigt werden, um die Nachricht
erneut zu senden.
-
Andere
Ausführungsformen
können
andere Verfahren zum Erzeugen, Einbetten und Prüfen von Token zum Prüfen der
Nachrichten auf Fehler oder böswilliges
Verfälschen
beinhalten.
-
Brückenbildende Einrichtungen
zu der verteilten Rechnerumgebung
-
Es
kann Einrichtungen außerhalb
der verteilten Rechnerumgebung geben, die das von der verteilten Rechnerumgebung
implementierte Modell zur Nachrichtenübergabe nicht unterstützen. Diese
Einrichtungen können
Dienste zur Verfügung
stellen, die für
Clients in der verteilten Rechnerumgebung nützlich sein können. Die
verteilte Rechnerumgebung kann einen Mechanismus enthalten, um für solche
externen Einrichtungen eine Brücke
zu der verteilten Rechnerumgebung zu bil den, so daß Clients
in der verteilten Rechnerumgebung auf die in solchen Einrichtungen
angebotenen Dienste zugreifen kann. Die verteilte Rechnerumgebung
kann ebenso aus vorhandenen Auffindungsprotokollen für Einrichtungen
Nutzen ziehen können,
um solche externen Einrichtungen zur Verwendung in der verteilten
Rechnerumgebung ausfindig zu machen.
-
Viele
Technologien definieren Auffindungsprotokolle zum Veröffentlichen
und Überwachen
der Zusammensetzung der Einrichtungen eines Netzwerkes. Diese Technologien
umfassen, sind jedoch nicht beschränkt auf: Jini, SLP, Bluetooth
und UPnP. Darüber
hinaus unterstützen
viele I/O-Busse
wie LonWorks, USB und 1394 auch dynamische Auffindungsprotokolle.
Die verteilte Rechnerumgebung kann aus Auffindungstechnologien für Einrichtungen
Nutzen ziehen, indem sie ihre Implementierungen in ein API verpackt.
Das Ausnutzen anderer Auffindungsprotokolle für Einrichtungen und das Bereitstellen
eines Verfahrens zur Brückenbildung
zu anderen Auffindungsprotokollen kann es der verteilten Rechnerumgebung
ermöglichen,
Einrichtungen oder Dienste in einer großen Vielfalt von Netzwerk-
und I/O-Bussen ausfindig zu machen. Das Auffinden einer Einrichtung
in der verteilten Rechnerumgebung kann somit für einen großen Bereich von Einrichtungen
einschließlich
kleiner Einrichtungen wie PDAs anwendbar sein, auch wenn sie nicht
direkt Teil der verteilten Rechnerumgebung sind. Auffindungsprotokolle
können
auf der Nachrichtenschicht definiert werden.
-
Ein
Mechanismus zur Brückenbildung
bzw. Überbrückung kann
das "Einpacken" bzw. "Wrapping" eines oder mehrerer
spezifischer Auffindungsprotokolle für Einrichtungen wie des Auffindungsprotokolls
von Bluetooth in einem Nachrichten-API für die verteilte Rechnerumgebung
vorsehen. Das Einpacken kann das Einrahmen des Auffindungsprotokolls
für Einrichtungen
mit Code und/oder Daten (das API) umfassen, so daß das Protokoll
von Clients und/oder Diensten in der verteilten Rechnerumgebung
ausgeführt
werden kann, die sonst nicht in der Lage wäre, es auszuführen. Während der
Ausführung
kann der Mechanismus zur Brückenbildung
einen Auffindungsagenten vorsehen, der Einrichtungen durch ein spezifisches
Auffindungsprotokoll für Einrichtungen
ausfindig macht, um Dienste für
diese Einrichtungen in einem Space in der verteilten Rechnerumgebung
zu veröffentlichen.
Die Dienste präsentieren
eine Schnittstelle zu einem bzw. entsprechend einem XML-Nachrichtenschema
an Clients in der verteilten Rechnerumgebung, und sind in der Lage,
die verschiedenen Einrichtungen, die von dem spezifischen Auffindungsprotokoll
für Einrichtungen
ausfindig gemacht wurden, zu betreiben. Somit können die Dienstannoncen für die Dienste
veröffentlicht
werden, die die verschiedenen Einrichtungen betreiben, die von den
darunterliegenden, eingepackten Auffindungsprotokollen für Einrichtungen
ausfindig gemacht wurden. Die angekündigten Dienste bilden somit
eine Brücke
für Einrichtungen (oder
Dienste) außerhalb
der verteilten Rechnerumgebung zu Clients in der verteilten Rechnerumgebung.
-
27 stellt eine Ausführungsform einer verteilten
Rechnerumgebung mit einem Space 1200 dar. Ein oder mehrere
Auffindungsagenten 1204 können an einem externen Auffindungsprotokoll
beteiligt sein und eine Brücke
zu der verteilten Rechnerumgebung durch den Überbrückungsmechanismus 1202 bilden.
Wenn die eingepackten Auffindungsprotokolle für Einrichtungen ausgeführt werden,
können
die Auffindungsagenten 1204 die Dienstannoncen 1206a-1206c in
dem Space 1200 durch den Überbrückungsmechanismus 1202 veröffentlichen,
wobei jede der Annoncen 1206a-1206c einer Einrichtung
oder einem Dienst entspricht, die bzw. der durch eines der Auffindungsprotokolle 1204 außerhalb
der verteilten Rechnerumgebung ausfindig gemacht wurde. Clients
können
daraufhin auf die externen Einrichtungen mittels der Dienstannoncen 1206a-1206c in
dem Space 1200 zugreifen, um Dienste auf einem der Agenten 1204 zu
instantiieren, der die entsprechende externe Einrichtung oder den
entsprechenden externen Dienst betreibt.
-
Daher
können
Clients der verteilten Rechnerumgebung die Auffindungsagenten, die
Auffindungsprotokolle für
Einrichtungen verpacken, zum Auffinden von Einrichtungen verwenden.
Ein Dienst, der als Brücke für diese
Einrichtungen agiert, kann in einem Space veröffentlicht und angekündigt werden,
so daß Clients
der verteilten Rechnerumgebung auf die von den externen Einrichtungen
bereitgestellten Dienste zugreifen können. Der angekündigte Dienst
ist ein Dienst innerhalb der verteilten Rechnerumgebung, der in
der Lage ist, eine Einrichtung außerhalb der verteilten Rechnerumgebung
mittels eines anderen Protokolls oder einer anderen Umgebung aufzurufen,
wodurch er für
die außerhalb
befindliche Einrichtung/den außerhalb
befindlichen Dienst eine Brücke
zu der verteilten Rechnerumgebung bildet. Ein Client innerhalb der
verteilten Rechnerumgebung "sieht" nur den angekündigten
Dienst innerhalb der verteilten Rechnerumgebung und ist sich möglicherweise
nicht einmal der/des außerhalb
befindlichen Einrichtung/Dienstes bewußt.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung eine Version eines Nachrichtenprotokolls
zum Auffinden von Spaces wie das in dem Abschnitt über Spaces
beschriebene Protokoll vorsehen, das auf ein zugrundeliegendes Auffindungsprotokoll
für externe
Einrichtungen einschließlich
des oben beschriebenen eingepackten Auffindungsprotokolls für Einrichtungen
abgebildet werden kann. Das abgebildete Auffindungsprotokoll kann
sich bei einem Space registrieren oder kann bei einem Space z. B.
einem Standard-Space, registriert werden, indem eine Annonce in
diesen Space eingestellt wird. Für
jedes angekündigte Auffindungsprotokoll
kann ein anschließender
Ergebnis-Space zur Aufnahme der Ergebnisse des Auffindungsprotokolls
zur Verfügung
stehen.
-
28 stellt ein Beispiel des Auffindungsprotokolls
für Spaces
dar, das auf einen Bluetooth-Auffindungsdienst 1220 gemäß einer
Ausführungsform
abgebildet wird. Der Bluetooth-Auffindungsdienst 1220 kann sich
zuerst bei der verteilten Rechnerumgebung gemäß 1230 registrieren.
Der Bluetooth-Auffindungsdienst 1220 kann in einem Überbrückungs-API
eingepackt werden, und eine Annonce 1225 für den Auffindungsdienst 1220 kann
gemäß 1232 in
dem Space 1224 hinzugefügt
werden. Ein Client oder Dienst kann die Annonce 1225 des
Auffindungsdienstes in dem Space 1224 lokalisieren. Wenn
der Auffindungsdienst 1220 ausgeführt wird (unter Benutzung des
API-Wrapper als eine Brücke
zwischen dem Auffindungsprotokoll 1220 und der verteilten
Rechnerumgebung 1222), kann ein neuer Space 1226 gemäß 1234 erzeugt
werden, um die Ergebnisse des Auffindungsvorgangs zu speichern.
Der Auffindungsdienst 1220 kann die Ergebnisse (wieder durch
den API-Wrapper) in den Space 1226 für die Auffindungsergebnisse
als eine oder mehrere Annoncen 1227 speichern. Alternativ
können
Ergebnisse der Ausführung
des Auffindungsdienstes 1220 in den Space 1224 oder
andere, vorher existierende Spaces in der verteilten Rechnerumgebung
ge speichert werden. Ein ähnliches
Verfahren wie in 28 dargestellt kann zum Auffinden
von Einrichtungen und anderen Diensten mittels anderer zugrundeliegender
Auffindungsprotokolle verwendet werden.
-
Wie
oben erwähnt,
kann es Einrichtungen außerhalb
der verteilten Rechnerumgebung geben, die das von der verteilten
Rechnerumgebung implementierte Modell der Nachrichtenübergabe
nicht unterstützen.
Diese Einrichtungen können
Clients haben, die in der verteilten Rechnerumgebung bereitgestellte
Dienste nutzen wollen. Die verteilte Rechnerumgebung kann einen
Mechanismus bereitstellen, um eine Brücke für die externen Clients oder
Client-Einrichtungen zu der verteilten Rechnerumgebung zu bilden,
so daß die
Clients auf den externen Einrichtungen auf die Dienste in der verteilten
Rechnerumgebung zugreifen können.
-
Es
können
Agenten zur Verfügung
stehen, die als Clients in der verteilten Rechnerumgebung zum Brückenbilden
für externe
Clients zu der verteilten Rechnerumgebung dienen, wodurch externen
Clients ein Zugriff auf in der verteilten Rechnerumgebung veröffentlichten
Dienste ermöglicht
wird. In einer Ausführungsform kann
ein Agent einen XML-fähigen
Hintergrundrechner(back end), der zum Kommunizieren mit den Diensten in
der verteilten Rechnerumgebung unter Verwendung des Models zur Nachrichtenübergabe
in der Lage ist, und ein proprietäres Protokoll (z. B. ein von
der externen Einrichtung unterstütztes
Protokoll) auf der Eingangsseite bzw. dem Vorrechner (front end)
haben, um eine Schnittstelle zu der externen Einrichtung und somit
zu dem externen Client zu bilden. Dadurch kann ein Client außerhalb
der verteilten Rechnerumgebung einen Dienst in der verteilten Rechnerumgebung
durch den Brückenagenten
lokalisieren und auf den Dienst zugreifen und Anforderungen an Dienste
senden und Antworten von Diensten einschließlich Ergebnisdaten empfangen.
Zum Beispiel kann ein externer Client den Brückenagenten verwenden, um eine
Auffindung von Spaces in der verteilten Rechnerumgebung auszuführen, angekündigte Dienste
zu suchen und Dienste in der verteilten Rechnerumgebung aufzurufen.
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Überbrückungsmechanismus zum Zugriff
auf Jini-Dienste durch einen Client in der verteilten Rechnerumgebung
bereitstellen. Da Jini-Dienste Remote Method Invocation (RMI) erfordern
können
und da Clients in der verteilten Rechnerumgebung mit Diensten mittels
Nachrichten wie XML-Nachrichten kommunizieren können, kann ein Mechanismus
zur Brückenbildung
für Protokolle
zur Verfügung
stehen, um den Zugriff auf einen Jini-Dienst durch einen Client
in der verteilten Rechnerumgebung zu ermöglichen. In einer Ausführungsform
kann ein Verbindungsmechanismus definiert sein, der die dynamische
Annonce von Jini-Diensten in Spaces der verteilten Rechnerumgebung
ermöglicht
und der auch den Zugriff von Clients in der verteilten Rechnerumgebung
auf einen Proxy für
Jini-Dienste ermöglichen
kann. In einer Ausführungsform
kann es Jini-Dienste geben, für
die es keine Brücke
zu der verteilten Rechnerumgebung gibt.
-
In
einer Ausführungsform
kann ein Agent als ein Dienst in der verteilten Rechnerumgebung
zur Verfügung
stehen, der eine Brücke
für das
von Jini-Diensten verwendete Jini-RMI-Protokoll zu dem Senden von XML-Nachrichten
bildet, das von Clients der verteilten Rechnerumgebung ver wendet
wird. Wenn der Agent gestartet wird, kann der Agent eine Suche in
Jini-Spaces nach Jini-Diensten,
die einen Satz von Attributen haben, durchführen. Für jeden registrierten Jini-Dienst
kann der Agent eine XML-Annonce erzeugen, die dem Dienst entspricht,
und kann die Annonce in einem Space in der verteilten Rechnerumgebung
registrieren. In einer Ausführungsform
kann sich der Agent für
Ereignisnachrichten in dem Jini-Nachschlagedienst registrieren,
und kann daher informiert werden, wenn ein neuer Jini-Dienst registriert
wird. Wenn der Agent über
einen neuen Jini-Dienst informiert wird, kann er eine Suche in Jini-Spaces
durchführen,
um neu angekündigte
Jini-Dienste zu lokalisieren und den Space in der verteilten Rechnerumgebung
mit neuen XML-Annoncen für
die neuen Dienste zu aktualisieren. In einer Ausführungsform
kann der Agent in dem Fall, daß ein
Jini-Dienst entfernt
wird, ein Ereignis empfangen, das ihn über das Entfernen des Jini-Dienstes
informiert. Der Agent kann daraufhin die XML-Annonce für den Dienst
aus dem Space entfernen.
-
In
einer Ausführungsform
kann ein Client die Dienstannoncen in dem Space durchsuchen, um
einen Jini-Dienst mittels einer XML-Annonce in einem Space der verteilten
Rechnerumgebung aufzurufen, und kann gültige Nachrichten an den Agenten
senden, um auf den Dienst zuzugreifen. Der Agent kann den dem Jini-Dienst
entsprechenden Proxydienst aufrufen, indem er die entsprechende
Methode durch einen RMI-Aufruf an einen Dienstproxy aufruft. Wenn
der Proxy nicht instantiiert ist, kann der Agent den Proxy-Code
herunterladen und eine neue Instanz des Proxy-Objektes instantiieren.
In einer Ausführungsform
kann jede Clientverbindung eine unterschiedliche Proxy-Instanz haben. Die
eingehende Nachricht von dem Client kann durch den Agenten in einen
Methodenaufruf für
den Proxy konvertiert werden. Das Ergebnis des Methodenaufrufs kann an
den Client als eine ausgehende Nachricht zurückgegeben werden.
-
In
einer Ausführungsform
können
nur einfache Java-Typen als Argumente für eine RMI-Methode verwendet werden. Wenn komplexe
Java-Typen benötigt
werden, dann können
eine oder mehrere Annoncen als Argumente an den Aufruf übergeben
werden, wobei die Datenannoncen die Stelle und die Zugriffsmethode von
Daten für
die komplexen Java-Typen anzeigen können. In einer Ausführungsform
kann der Agent eine anfängliche
Konvertierung von XML-Nachrichten zu einem RMI-Methodenaufruf dynamisch
durchführen.
Da der Agent die Dienstschnittstelle kennt, kann er den entsprechenden
Satz von Nachrichten erzeugen, die dem Client angekündigt werden.
-
29 stellt die Brückenbildung für einen
Client 1250 außerhalb
der verteilten Rechnerumgebung zu einem Space 1254 in der
verteilten Rechnerumgebung dar. Der Überbrückungsagent 1252 kann
als das Zwischenstück
zwischen dem Client 1250 und dem Space 1254 dienen.
Der Überbrückungsagent 1252 kann
mit dem Client 1250 in einem Kommunikationsprotokoll kommunizieren,
das von dem Client 1250 verstanden werden kann. Der Überbrückungsagent 1252 kann
das Kommunikationsprotokoll des Client auf das Protokoll zum Senden
von XML-Nachrichten abbilden, das zum Kommunizieren mit dem Space 1254 notwendig
ist, um die von dem Space 1254 bereitgestellten Funktionen
durchzuführen.
Auf Anforderung des Client 1250 kann der Überbrückungsagent 1252 Dienste
in dem Space 1254 lokalisieren und ablaufen lassen. Zum
Beispiel kann der Client 1250 eine Liste aller Dienste
eines bestimmten Typs aus dem Space 1254 anfordern. Der Über brückungsagent 1252 kann
die Dienstannoncen 1256a-1256c lokalisieren und
die Ergebnisse an den Client 1250 zurückgeben. Alternativ können die
Ergebnisse in einem Ergebnis-Space bekanntgegeben und der Ort der
Ergebnisse kann an den Client 1250 ausgegeben werden. Der
Client 1250 kann daraufhin auswählen, die Dienstannonce 1256a auszuführen, und
kann eine Nachricht (in dem Kommunikationsprotokoll des Client 1250)
an den Überbrückungsagenten 1252 senden.
Der Überbrückungsagent 1252 kann
daraufhin die XML-Anforderungsnachricht(en) senden, die zum Ausführen des
durch die Dienstannonce 1256a repräsentierten Dienstes notwendig
sind, und kann die Ergebnisse des Dienstes an den Client 1250 zurückgeben.
Andere Verfahren zur Behandlung der Ergebnisse des Dienstes als
die direkte Lieferung der Ergebnisse an den Client 1250 können verwendet
werden, wie oben in dem Abschnitt mit dem Titel "Spaces" beschrieben. Der Überbrückungsagent 1252 kann
somit als ein Dienst des externen Client 1250 (über das
Protokoll des externen Client) und als ein Client innerhalb der
verteilten Rechnerumgebung agieren, um für den Dienst innerhalb der
verteilten Rechnerumgebung eine Brücke zu dem externen Client
zu bilden.
-
Manchmal
können
sogar innerhalb der verteilten Rechnerumgebung Clients und Dienste
nicht direkt miteinander kommunizieren, sondern nur mit einem gemeinsamen
Space. In diesem Fall erzeugt der Space-Dienst automatisch einen
Dienst-Proxy, der eine Brücke
für den
Client zu dem Dienst bildet. Die Hauptaufgabe des Proxy ist es,
Nachrichten zwischen dem Client und dem Dienst durch den Space zu
leiten. Der Dienst-Proxy kann dynamisch erstellt werden. Der Erstellungsmechanismus
kann von der Space-Implementierung abhängen. Siehe 30 für
eine Darstellung des Proxy-Mechanismus'. Ein Client 554 und ein Dienst 556 sind
eventuell nicht in der Lage, innerhalb der verteilten Rechnerumgebung
direkt zu kommunizieren, z. B. weil sie unterschiedliche Transport- oder Netzwerkprotokolle
unterstützen.
Sie sind jedoch vielleicht beide in der Lage, mit einem Space 552 zu
kommunizieren, der beide Protokolle unterstützt. Der Space-Dienst kann einen
Proxy 550 erstellen, um eine Brücke für den Client 554 zu
dem Dienst 556 zu bilden. Eine verbreitete Form eines Proxy
ist ein Browser-Proxy. Ein Browser-Proxy (am meisten verbreitet
als ein Servlet implementiert) kann herkömmliche Anforderungen von Webseiten
in Nachrichten übersetzen.
Siehe auch die Beschreibung von Space-Nachschlagediensten (und der
Proxies hierfür)
in dem Abschnitt zu Spaces.
-
Die
verteilte Rechnerumgebung kann einen Mechanismus zur Brückenbildung
für Clients
in der verteilten Rechnerumgebung zu unternehmensweiten Diensten
bereitstellen. In einer Ausführungsform
einer verteilten Rechnerumgebung kann ein Verfahren zur Brückenbildung
für Clients
zu unternehmensweiten Diensten einen Client innerhalb der verteilten
Rechnerumgebung, einen Überbrückungsdienst
innerhalb der verteilten Rechnerumgebung und einen unternehmensweiten
Dienst innerhalb der Unternehmensumgebung umfassen. Der Überbrückungsdienst
der verteilten Rechnerumgebung dient als ein Überbrückungsdienst zwischen dem Client
und dem unternehmensweiten Dienst. Ein Unternehmen kann ein Großunternehmen,
ein mittelständisches
Unternehmen bzw. ein Kleinunternehmen, eine nicht-kommerzielle Institution,
eine Regierungsinstitution oder eine andere Art von Organisation
sein. Ein Unternehmen kann eine Rechnerumgebung des Unternehmens zum
Durchführen
eines Teils seines Geschäftes
verwenden. Die Rechnerumgebung des Unternehmens kann verschiedene
Unternehmensdienste umfassen. Clients in der verteilten Rechnerumgebung
können Dienste
in der Rechnerumgebung des Unternehmens benutzen wollen. Ein Unternehmensdienst
kann auf einer Anzahl von Architekturen wie dreistufigen Client/Server-Architekturen
beruhen. Ein Beispiel einer Architektur, die zum Implementieren
eines Unternehmensdienstes verwendet werden kann, ist Enterprise
JavaBeans. Enterprise JavaBeans (EJB) ist eine Architektur zum Aufbau
von Programmkomponenten, geschrieben in der Java-Programmiersprache,
die in Serverteilen einer Unternehmensumgebung mittels eines Client/Server-Modells
ablaufen. In der objektorientierten Programmier- und verteilten
Objekt-Technologie ist eine Komponente ein wiederverwendbarer Block
zum Aufbau von Programmen, der mit anderen Komponenten in demselben oder
einem anderen Computer in einem verteilten Netzwerk kombiniert werden
kann, um eine Anwendung zu bilden. EJB ist auf der JavaBeans-Technologie
zum Verteilen von Programmkomponenten (Beans) an Clients in einem
Netzwerk aufgebaut. Um eine EJB-Bean oder -Komponente zu verwenden,
muß sie
Teil einer spezifischen Anwendung sein, die ein Container genannt
wird. In Enterprise JavaBeans gibt es zwei Arten von Beans: Sitzungs-Beans
und Entity-Beans. Eine Entity-Bean ist beschrieben als eine, die
anders als eine Sitzungs-Bean Dauerhaftigkeit besitzt und ihr ursprüngliches
Verhalten oder ihren Zustand beibehalten bzw. speichern kann. Mittels
EJB können
Programme über
im wesentlichen alle bedeutenden bzw. wichtigen Betriebssysteme
hinweg eingesetzt werden. Die Programmkomponenten von EJB sind im
allgemeinen als Servlets (kleine Serverprogramme) bekannt. Die Anwendung
oder der Container, der die Servlets ablaufen läßt, wird manchmal ein Applikationsserver
genannt.
-
Der
Brückendienst
interagiert mit dem Client mittels der Übergabe von XML-Nachrichten
zum Sammeln der benötigten
Eingabeparameter, um Anforderungen an den Unternehmensdienst außerhalb
der verteilten Rechnerumgebung zu stellen. Zum Beispiel kann der
Brückendienst
von dem Client genau wie jeder andere Dienst in der verteilten Rechnerumgebung
gesucht und instantiiert werden. Der Brückendienst kann daraufhin mit
dem Unternehmensdienst interagieren, um den Unternehmensdienst ablaufen
zu lassen. Diese Interaktion kann eine Architektur zur Interprozeßkommunikation
verwenden, die der Unternehmensdienst verstehen kann. Als ein Beispiel
kann ein Brückendienst
mit dem Unternehmensdienst mittels EJB kommunizieren, wenn ein Unternehmensdienst
mit Enterprise JavaBeans (EJB) implementiert ist. Der Brückendienst
kann dann Ergebnisse von dem Unternehmensdienst empfangen und kann
die Ergebnisse direkt an den Client (in XML-Nachrichten) zurückgeben oder kann die Ergebnisse
in einen Space in der verteilten Netzwerkumgebung (z. B. einen Ergebnis-Space)
einstellen. Dem Client erscheint der Brückendienst als der einzige
Dienst (der Unternehmensdienst ist dem Client verborgen), so daß der Client
die Architektur des Unternehmensdienstes nicht zu unterstützen braucht.
Mehrere Clients der verteilten Netzwerkumgebung können denselben
Brückendienst
zum Interagieren mit dem Unternehmensdienst verwenden (wobei jeder
ein eindeutiges Gatterpaar verwendet).
-
Der
Brückendienst
oder ein anderer Agent kann eine Annonce für den Brückendienst (und damit für den Unternehmensdienst)
in einem Space in der verteilten Rechnerumgebung veröffentlichen.
Zum Beispiel kann der Brückendienst
oder ein anderer Brückenagent
Java Reflection verwenden, um Beans für Dienste in einem mit EJB
implementierten Unternehmenssystem zu untersuchen und dann Dienstannoncen
für Brückendienste
zu den Beans erstellen und diese Annoncen in Spaces in der verteilten
Rechnerumgebung veröffentlichen.
Reflection ist ein Verfahren für
Java-Code zum Herausfinden
von Information über
die Felder, Methoden und Konstruktoren von Klassen und zum Verwenden
der reflektierten Felder, Methoden und Konstruktoren, um auf ihren
zugrundeliegenden Gegenstücken
auf Objekten innerhalb von Sicherheitsrestriktionen zu operieren.
Das Reflection-API versorgt Anwendungen, die Zugriff entweder auf
die öffentlichen
Teile eines Zielobjektes oder auf die von einer gegebenen Klasse
deklarierten Teile benötigen.
Sobald die Brückendienste
angekündigt
sind, können
Clients auf die Brückendienste
(und somit die entsprechenden Unternehmensdienste) in gleicher Weise
wie auf jedwede andere angekündigte
Dienste in der verteilten Netzwerkumgebung ohne Kenntnis der Architektur
des Unternehmensdienstes, der die Dienste bereitstellt, zugreifen.
-
Proxy-Dienste
-
Fremde
Geräte,
Clients, Dienste und Transporte können unter Verwendung von Proxy-Diensten über eine
Brücke
in die verteilte Rechnerumgebung einbezogen werden. Proxy-Dienste
können
aufweisen:
- • Geräte-Proxy – Ein Dienst,
der ein Proxy-Protokoll eines Gerätes implementiert (wie z. B.
SLP, Jini, UPnP usw.).
- • Client-Proxy – Ein Dienst,
der das Proxy-Protokoll der verteilten Rechnerumgebung für einen
fremden Client, wie z. B. einen Browser implementiert.
- • Dienst-Proxy – Ein Dienst,
welcher das Proxy-Protokoll der verteilten Rechnerumgebung für einen
fremden Dienst, wie z. B. einen SLP-Druckdienst, implementiert.
- • Transport-Proxy – Ein Dienst,
welcher Nachrichten in einer Datenrepräsentationssprache (beispielsweise XML)
zwischen zwei verschiedenen Nachrichtentransporten leitet, was manchmal
als eine Nachrichtenbrücke
bezeichnet wird.
-
Jede
Art eines Proxy kann entweder direkt auf die Entdeckung von Suchnachrichten
reagieren oder Proxy-Dienstanzeigen in einem Space (allgemeinen
Speicherraum) speichern.
-
Geräte-Proxies
-
Geräte-Protokolle
existieren für
beide Netzwerke (beispielsweise UPnP, SLP und Bluetooth) sowie I/O-Busse
(z. B. USB, LonWorks und 1396). Geräte-Proxies einer verteilten
Rechnerumgebung können
verwendet werden, um eine Brücke
zu beiden Arten von Geräten
in die verteilte Rechnerumgebung herzustellen. Für irgendeines dieser Geräteprotokolle
kann ein Geräte-Proxydienst
- • nach
Geräten
tasten (auf dem Netzwerk oder dem I/O-Bus)
- • Dienstanzeigen
für jedes
entdeckte Gerät
erzeugen
- • Dienstanzeigen
in einem Space speichern (oder direkt auf Suchanfragen nach einer
Dienstermittlung reagieren)
-
Client-Proxies
-
Clients
in der verteilten Rechnerumgebung können Inhalt einer Datenrepräsentationssprache
annehmen und können
Style Sheets unterstützen,
um eine Übersetzung
zwischen der Datenrepräsentationssprache und
anderen Inhaltstypen bereitzustellen, z. B. WML. Für diejenigen
Clients, die die Datenrepräsentationssprache
nicht direkt unterstützen,
kann ein Client-Proxy implementiert werden, der in die und aus den
von dem durch Proxy bedingten Client unterstützten Inhaltstypen und der
Datenrepräsentationssprache übersetzt.
-
Dienst-Proxies
-
Dienst-Provider
bzw. Service-Provider in der verteilten Rechnerumgebung können auf
das Protokollabteil der verteilten Rechnerumgebung reagieren. Für Dienste,
die die verteilte Rechnerumgebung nicht unterstützen, kann ein Dienst-Proxy
Nachrichten zu und von dem natürlichen
Aufrufmodell des durch Proxy bedingten Dienstes übersetzen.
-
Transport-Proxies
-
Transport-Proxies
leiten Nachrichten von einem Transporttyp zu einem anderen Transporttyp
(beispielsweise IRDA zu IP). Der Transport-Proxy darf keinerlei
Inhalt der Nachricht beeinflussen und kann daher sowohl für den Client
als auch für
den Dienst transparent sein.
-
Umgebungsbrücke auf
RMI-Basis
-
Eine
Umgebungs- (z. B. Jini) Brücke
auf RMI (entfernter Methodenaufruf – Remote Method Invocation)-Basis
kann zwei Proxies enthalten: Einen Client-Proxy der verteilten Rechnerumgebung
und einen Client-Proxy der Umgebung auf RMI-Basis. Der Client-Proxy
der verteilten Rechnerumgebung ermöglicht, daß der Client der verteilten
Rechnerumgebung auf Dienste der Umgebung auf RMI-Basis zugreifen
kann. Der Client-Proxy der Umgebung auf RMI-Basis ermöglicht es
Clients in der Umgebung auf RMI-Basis, auf Dienste in der verteilten
Rechnerumgebung zuzugreifen. Gemeinsam bilden diese beiden Proxies
eine transparente Brücke
zwischen der verteilten Rechner umgebung und einer Umgebung auf RMI-Basis,
wie z. B. Jini. Die Proxies können
getrennt voneinander arbeiten, was es möglicherweise erlaubt, daß Ein-Wege
oder Zwei-Wege-Brücken
verwendet werden. Ähnliche
Proxies können
verwendet werden, um andere (auf Nachrichtenbasis oder nicht auf
Nachrichtenbasis) Umgebungs-Clients und Dienste mit Diensten und
Clients in der nachrichtenbasierten, verteilten Rechnerumgebung
zu überbrücken, wie
es hier beschrieben wurde.
-
47-49:
Client-Proxy der verteilten Rechnerumgebung
-
47 zeigt einen Client in einer nachrichtenbasierten,
verteilten Rechnerumgebung, der gemäß einer Ausführungsform über einen
Client-Proxy nach Diensten in einer Umgebung auf RMI-Basis sucht. Der
Client-Proxy 1904 der verteilten Rechnerumgebung kann die
Dienste 1906 in einer RMI-basierten Umgebung 1902 (z.
B. Jini) in Räumen
bzw. Spaces 1908 in der verteilten Rechnerumgebung 1900 anzeigen.
In einer Ausführungsform
kann die Wahl, welche Dienste 1906 angezeigt werden sollen,
von der Proxy-Implementierung abhängen. Für jeden Dienst 1906,
der in einem Nachschlagedienst 1910 (siehe 1914)
einer RMI-basierten Umgebung 1902 (z. B. Jini) veröffentlicht
wird, erzeugt der Client-Proxy 1904 der verteilten Rechnerumgebung
eine Proxy-Anzeige und ein Nachrichtenschema (siehe 1918),
nachdem zunächst
in dem Dienst 1906 (siehe 1916) nachgeschlagen
wurde.
-
Das
Schema der Proxy-Nachricht kann Definitionen des Satzes von Nachrichten
in der Datenrepräsentationssprache
enthalten, die geeignet sind, ein Methodengatter aufzubauen, welches
denselben Satz von Methoden (beispielsweise Java-Methoden) implementiert,
wie sie durch den original RMI-Proxy implementiert wurden, der in
dem Nachschlagedienst 1910 veröffentlicht wurde. Die Anzeige
kann dann in einem oder mehreren Spaces 1908 (siehe 1920)
veröffentlicht
und in einen oder mehrere Clients 1912 heruntergeladen
werden, wo ein Dienstmethodengatter aufgebaut werden kann (siehe 1922).
-
Wenn
das Methodengatter durch die Gatterfabrik des Clients aufgebaut
worden ist, kann der Zugriff auf den über den Proxy angeschlossenen
Dienst 1906 in Ausführungsformen
bereitgestellt werden, wie sie in 48 dargestellt
sind. Ein Zugriffsprozeß ruft
entfernte Methoden (siehe 1924) auf und kann dann Ergebnisse
(siehe 1940) liefern. Für
jede aufgerufene Methode auf dem Methodengatter des Client 1912 werden
die Argumente der Methode in einer Nachricht verpackt und dann an
ein passendes Methodengatter innerhalb des Proxy 1904 (siehe 1926)
gesendet. Das Proxy-Methodengatter
entpackt die Methodenargumente zu Objekten (beispielsweise Java-Objekten)
innerhalb des Proxy-Haufens (z. B. Java-Haufen). Der Proxy kann
dann die RMI-Zielmethode aufrufen und die Objekte als Argumente
weiterleiten (siehe 1928 und 1930). Der Dienst 1906 erzeugt
anschließend
das erwartete Ergebnis (ein Objekt) und liefert dieses Objekt an
den Proxy 1904 unter Verwendung von standardmäßigen RMI-Prozeduren
(siehe 1932 und 1934). Der Client-Proxy kann dann
eine Anzeige und ein Nachrichtenschema für das Ergebnis erzeugen (siehe 1936).
-
Die
sich ergebende Anzeige wird dann an das Methodengatter des ursprünglichen
Client 1912 weitergeleitet (1938). Die Gatterfabrik
des Client 1912 wird dann durch das ursprüngliche
Me thodengatter aufgerufen, um ein Methodengatter eines neuen Ergebnisses
zu erzeugen. Schließlich
liefert das ursprüngliche
Methodengatter einen Objektaufruf bzw. -hinweis für die aufrufende
Anwendung oder einen anderen Prozeß (siehe 1940). Das
sich ergebende Methodengatter ist ein Objekt, welches die Schnittstelle
des Ergebnisobjektes implementiert, indem der Prozeß des entfernten
Methodenaufrufs unter Verwendung von Nachrichten wiederholt wird
(siehe 1924). Demnach erzeugen Methodengatter Ergebnismethodengatter,
wie es in 49 dargestellt ist. In einer
Ausführungsform
können
Methodengatter für
jedes der verschiedenen Ergebnisse vorab erzeugt werden. Dann besteht
die einzige Arbeit bei der Erzeugung eines Ergebnismethodengatters
darin, die Adresse (beispielsweise eine URI) des speziellen Ergebnisobjektes
auf dem Proxy 1904 anzugeben.
-
Wie
in einer Ausführungsform
in 49 dargestellt, ist ein Methodengatter eines Client 1912 ein
Objekt, welches die Schnittstelle eines entfernten Objektes durch
Senden von Nachrichten implementiert. Jedes Methodengatter eines
Dienstes 1906 kann an eine entsprechende Implementierung
gebunden sein, welche das Ergebnis erzeugt. Der Client-Proxy 1904 übersetzt
diese Nachrichten zurück
in klassische RMI-Methodenaufrufe und hat Teil an der Anzeige von
RMI-Ergebnissen
zurück
zu dem Methodengatter, welches verwendet wurde, um die entfernte
Methode aufzurufen.
-
50-51:
Client-Proxy der Umgebung auf RMI-Basis
-
Wie
in 50 dargestellt, zeigt der Client-Proxy 1904 der
RMI-basierten Umgebung 1902 (z. B. Jini) Dienste einer
verteilten Rechnerumgebung in einem Nachschlagedienst 1946 in
der RMI-basierten
Umgebung 1902 an und macht damit die Dienste der verteilten
Rechnerumgebung für
Clients 1948 der RMI-basierten Umgebung 1902 verfügbar. Die
Wahl, welche Dienste der verteilten Rechnerumgebung angezeigt werden,
kann von der Proxy-Implementierung abhängen. Für jeden veröffentlichten (siehe 1950)
Dienst 1942 für
den Proxy, lädt
der Proxy 1904 die Anzeige (siehe 1952) herunter
und erzeugt dann einen passenden RMI-Anschluß und ein Implementierungsskelett
(siehe 1953). Das Implementierungsskelett wird als ein
Methodengatter realisiert. Der Proxy 1904 veröffentlicht
dann den RMI-kompatiblen Anschluß-Proxy in einem Nachschlagedienst 1946 (siehe 1954).
Anschließend
sucht ein Client 1948 in dem RMI-Proxy und lädt ihn in
seinen Objekthaufen (beispielsweise einen Java-Objekthaufen) (siehe 1956).
-
Gemäß 51 ist der Client 1948 nunmehr bereit,
eine Methode (siehe 1950) aufzurufen, welche durch einen
RMI-Anschluß-Proxy
implementiert ist. Der RMI-Anschluß-Proxy bzw. -Stub-Proxy implementiert einen
RMI-kompatiblen Satz von Schnittstellen, welcher auch mit dem Nachrichtenschema übereinstimmt,
das durch den Dienst 1942 der verteilten Rechnerumgebung
angezeigt wird.
-
Das
Methodengatterskelett des Dienstes wird durch die RMI-Infrastruktur
aufgerufen (siehe 1952). Das Methodengatterskelett sendet
seinerseits Versionen der Objektargumente in der Datenrepräsentationssprache
an das passende Methodengatter des Dienstes 1942 der verteilten
Rech nerumgebung (siehe 1954). Der Dienst 1942 kann
dann Ergebnisse (1956) erzeugen und kann eine Ergebnisanzeige
an das Proxy-Methodengatter liefern (1958). Der Proxy 1904 baut
dann ein Ergebnismethodengatter auf (nicht dargestellt) und fordert
den aktuellen Ergebniswert, eine Darstellung eines Objektes in einer
Datenrepräsentationssprache (siehe 1960 und 1962),
an.
-
Dann
wandelt der Proxy das in einer Datenrepräsentationssprache wiedergegebene
Objekt in ein reales Objekt innerhalb des Haufens des Proxy 1904 um
(siehe 1964). Der Proxy 1904 liefert dann diese
Objekte an den Client 1948 unter Verwendung von RMI (siehe 1966).
RMI liefert dann den Objekthinweis an die Anwendung (siehe 1968).
-
Umgebungsagenten
auf RMI-Basis
-
Da
Dienste in der RMI-basierten Umgebung (z. B. Jini) RMI erfordern
und da ein Client in dem verteilten Rechnersystem Nachrichten in
einer Datenrepräsentationssprache
sendet, kann eine Protokolladaptertechnologie bereitgestellt werden,
um den Zugriff auf Dienste von einem Client des verteilten Rechnersystems auf
Dienste in der RMI-basierten Umgebung zu ermöglichen. Ein Anschluß des verteilten
Rechnersystems kann definiert werden, welcher dynamische Anzeigen
der Dienste der RMI-basierten Umgebung in einem Space eines verteilten
Rechnersystems und in Zugriff auf den Dienst-Proxy einer RMI-basierten
Umgebung von einem Client eines verteilten Rechnersystems ermöglicht.
-
Ein
Grundgerüst
für den
Zugriff auf einen Dienst einer RMI-basierten Umgebung von einem
Client eines verteilten Rechnersystems kann über einen RMI-basierten Umgebungsagenten
bereitgestellt werden. Der RMI-basierte Umgebungsagent ist ein Dienst
des verteilten Rechnersystems, der verwendet werde kann, um das
RMI-Protokoll der RMI-basierten Umgebung zu der Nachrichtengebung
des verteilten Rechnersystems zu überbrücken.
-
Wenn
ein Agent einer RMI-basierten Umgebung gestartet wird, kann er ein
Nachschlagen unter den Diensten der RMI-basierten Umgebung nach
allen Diensten durchführen,
die ein Attribut haben, welches es ermöglicht, daß von ihnen eine Brücke in das
verteilte Rechnersystem geschlagen werden kann. In einer Ausführungsform
kann nicht für
alle Dienste einer RMI-basierten Umgebung eine Brücke zu dem
verteilten Rechnersystem gebildet werden. Für jeden registrierten Dienst
kann der Agent eine Anzeige in dem verteilten Rechnersystem erzeugen,
welche dem Dienst entspricht und kann die Anzeige in einer Ereignismeldung
in dem Nachschlagedienst der RMI-basierten
Umgebung registrieren und damit informiert werden, wenn ein neuer Dienst
registriert wird. An diesem Punkt kann der Agent ein erneutes Nachschlagen,
um den Space des verteilten Rechnersystems mit neuen Anzeigen zu
aktualisieren.
-
Wenn
ein Client eines verteilten Rechnersystems einen Dienst in einer
RMI-basierten Umgebung in einem Space des verteilten Rechnersystems
aufruft, kann der Client in der Anzeige des Dienstes der RMI-basierten
Umgebung in dem Space des verteilten Rechnersystems nachschlagen
und Nachrichten an den Agenten senden, um auf den Dienst zuzugreifen.
Der Agent kann den Pro xy-Dienst aufrufen, welcher dem Dienst in
der RMI-basierten Umgebung entspricht, indem er die entsprechende
Methode durch einen RMI-Aufruf an den Dienst-Proxy aufruft. Wenn
der Proxy nicht instantiiert ist, kann der Agent den Proxy-Code
herunterladen und eine neue Instanz des Objektes einsetzen bzw.
instantiieren. In einer Ausführungsform
muß jede
Client-Verbindung eine andere Proxy-Instanz haben. Die Eingangsnachricht
von dem Client kann durch den Agenten auf dem Proxy in einen Methodenaufruf
umgewandelt werden. Das Ergebnis des Methodenaufrufs kann an den
Client als ausgehende Nachricht geliefert werden.
-
In
einer Ausführungsform
können
nur einfache Typen (beispielsweise Java-Typen) als Argumente für eine RMI-Methode
verwendet werden. Wenn komplexe Typen verwendet werden, können Datenanzeigen
als Argumente an den Aufruf weitergeleitet werden.
-
Die
anfängliche
Umwandlung von Nachrichten des verteilten Rechnersystems in einen
RMI-Methodenaufruf
kann durch den Agenten dynamisch durchgeführt werden. Da der Agent die
Dienstschnittstelle kennt, kann er den entsprechenden Satz von Nachrichten
erzeugen, die dem Client angezeigt werden.
-
Anzeigen beim Client
-
Es
gibt einige Verfahren, bei denen Ergebnisse von einem Dienst, der
von einem Client ausgeführt wird,
in einer verteilten Rechnerumgebung angezeigt werden können. Einrichtungen,
die Ergebnisse anzeigen können,
können
umfassen, sind jedoch nicht beschränkt auf: CRTs an Computern;
LCDs bei Laptops, Notebook-Anzeigen, etc.; Drucker; Lautsprecher;
und jede andere Einrichtung, die Ergebnisse des Dienstes in einem
visuellen, akustischen oder anderen wahrnehmbaren Format anzeigen
kann. Die Verfahren zum Anzeigen von Ergebnissen können umfassen,
sind jedoch nicht beschränkt
auf:
- • Der
Dienst kann Ergebnisse direkt oder per Referenz an einen Client
zurückgeben,
und der Client kann die Anzeige der Ergebnisse behandeln.
- • Der
Dienst kann Ergebnisse direkt oder per Referenz an einen Client
zurückgeben,
und der Client kann die Ergebnisse direkt oder per Referenz an einen
Anzeigedienst übergeben,
und der Anzeigedienst kann die Ergebnisse anzeigen.
- • Der
Dienst kann direkt das Anzeigen der Ergebnisse behandeln.
- • Der
Dienst kann die Ergebnisse direkt oder per Referenz an einen Anzeigedienst übergeben,
und der Anzeigedienst kann die Ergebnisse anzeigen.
-
Beim
dem letztgenannten Verfahren zum Anzeigen der Ergebnisse kann der
Client den Anzeigedienst angeben. Zum Beispiel kann es einen Anzeigedienst
auf der Einrichtung, auf der sich der Client befindet, oder dieser
zugeordnet geben, den der Client zur Anzeige der Ergebnisse des
Dienstes verwenden möchte.
Wenn der Client den Dienst ablaufen läßt, kann der Client eine Nachricht
an den Dienst senden, die die Dienstankündigung des Anzeigedienstes
des Client spezifiziert. Der Dienst kann daraufhin ein Gatter einrichten,
das ihm das Senden von Nachrichten an den Anzeigedienst des Client
ermöglicht.
Somit wird der von dem Client aufgerufene Dienst bei der Anzei ge
von Ergebnissen zu einem Client des Anzeigedienstes des Client und
sendet seine Ergebnisse (direkt oder per Referenz) zur Anzeige an
diesen Anzeigedienst. Nähere
Einzelheiten zu der Client-Dienst-Beziehung,
Gattern und dem Senden von Nachrichten sind in anderen Abschnitten
dieses Dokumentes enthalten.
-
Herkömmliche
Anwendungsmodelle beruhen typischerweise auf vorab festgelegten,
zum großen
Teil statischen Benutzerschnittstellen und/oder Eigenschaften von
Daten. Änderungen
an herkömmlichen
Anwendungen können
Codeänderung
und erneutes Kompilieren erfordern. Die zum Ankündigen von Diensten und zur
Spezifikation von XML-Nachrichtenschemata zur Kommunikation mit
den Diensten in der verteilten Rechnerumgebung beschriebenen Mechanismen
können
verwendet werden, um einen Mechanismus für Anwendungen (Clients, Dienste,
etc.) zum Beschreiben von dynamischen Anzeigeobjekten zur Verfügung zu
stellen. Mittels dynamischer Anzeigeobjekte kann das Verhalten einer
Anwendung geändert
werden, ohne neuen Code herunterladen oder die Anwendung erneut
kompilieren oder erneut binden zu müssen. Anzeigeschemata können zum
Anzeigen derselben Ergebnisse in unterschiedlichen Formaten, zum
Extrahieren von Teilen der Ergebnisse zur Anzeige und zum Anzeigen
von Ergebnissen auf unterschiedlichen Anzeigeeinrichtungen vorgesehen
werden.
-
31 stellt eine Ausführungsform eines Client 1300 mit
zugeordneter Anzeige 1302 und zugeordnetem Anzeigedienst 1304 gemäß einer
Ausführungsform
dar. Eine Annonce 1306 für den Anzeigedienst 1304 kann
in dem Space 1308 registriert werden. Eine Annonce 1312 für den Dienst 1310 kann
von dem Dienst 1310 in dem Space 1314 registriert
werden. Alternativ können
die Dienstannonce 1312 und die Annonce 1306 des
Anzeigedienstes in demselben Space registriert werden. Der Client 1300 kann
nach der Dienstannonce 1312 in dem Space 1314 suchen
und diese auffinden (1320) und kann daraufhin ein Gatter
zum Senden von Anforderungen an den (und zum Empfang von Ergebnissen
oder Antworten von dem) Dienst 1310 einrichten. In einer
Ausführungsform
können
die Nachrichten in der Form von in einem XML-Schema spezifizierten XML-Nachrichten vorliegen,
das als Teil der Annonce 1312 empfangen wurde. Der Client 1300 kann
eine oder mehrere Nachrichten an den Dienst 1310 senden
(1322). Die eine oder mehreren Nachrichten können Nachrichten
umfassen, um den Dienst 1310 ablaufen zu lassen und den
Dienst 1310 anzuweisen, Ergebnisse an den Anzeigedienst 1304 zur
Anzeige zu senden, und können
den Ort bzw. die Lage der Annonce 1306 des Anzeigedienstes
angeben. Der Ort der Annonce kann als ein Uniform Resource Identifier
(URI) angegeben werden.
-
Die
Nachrichten von dem Client 1300 können den Dienst 1310 anweisen,
eine oder mehrere Operationen durchzuführen, die anzeigbare Ergebnisse
erzeugen. Der Dienst 1310 kann die Annonce 1306 des
Anzeigedienstes basierend auf der von dem Client 1300 empfangenen
Ortsinformation aus dem Space 1308 holen. Die Dienstannonce
kann das XML-Schema und andere Information enthalten, die für die Verbindung
mit dem Anzeigedienst 1304 notwendig ist. Der Dienst 1310 kann
daraufhin ein Gatter zum Senden von Anforderungen an den (und zum
Empfangen von Ergebnissen von dem) Anzeigedienst 1304 aufbauen.
In anderen Ausführungsformen
können
Nach richten von dem Client 1300 an den Dienst 1310 das
XML-Schema und andere für
den Dienst 1310 notwendige Informationen zum Errichten
eines Gatters zu dem Anzeigedienst 1304 umfassen oder können ein
vorab erstelltes Gatter zu dem Anzeigedienst 1304 beinhalten.
-
Während oder
nach Abschluß der
von dem Client 1300 angeforderten Operationen kann der
Dienst 1310 die Ergebnisse der Operationen an den Anzeigedienst 1304 in
der durch das Schema für
den Anzeigedienst 1304 spezifizierten Weise senden (z.
B. eingekapselt in von dem XML-Nachrichtenschema
spezifizierten XML-Nachrichten oder per Referenz als Parameter für den Anzeigedienst).
In dieser Hinsicht kann der Dienst 1310 ein Client des
Anzeigedienstes 1304 sein. Der Anzeigedienst 1304 kann
daraufhin die Ergebnisse, die von dem Dienst 1310 empfangen
oder angegeben wurden, formatieren und auf der Anzeige 1302 für den Client
anzeigen.
-
Nach
einigen Ausführungsformen
kann der Dienst 1310 die Ergebnisse der Operationen einem
Space wie einem Ergebnis-Space bekanntmachen (nicht abgebildet).
Der Dienst 1310 kann danach eine Nachricht an den Anzeigedienst 1304 senden,
die eine Referenz bzw. einen Hinweis auf die gespeicherten Ergebnisse der
Operationen enthält.
In einer Ausführungsform
kann die Referenz in der Form eines URI sein. Der Anzeigedienst 1304 kann
daraufhin die Ergebnisse von dem Space abholen und die Ergebnisse
auf der Anzeige 1302 anzeigen.
-
Herkömmliche
Anwendungsmodelle beruhen typischerweise auf vorab festgelegten,
zum großen
Teil statischen Benutzerschnittstellen und/oder Eigenschaften von
Daten. Änderungen
an herkömmlichen
Anwendungen können
Codeänderung
und erneutes Kompilieren erfordern. Die zum Ankündigen von Diensten und zur
Spezifikation von XML-Nachrichtenschemata zur Kommunikation mit
den Diensten in der verteilten Rechnerumgebung beschriebenen Mechanismen
können
verwendet werden, um einen Mechanismus für Anwendungen (Clients, Diensten,
etc.) zum Beschreiben von dynamischen Anzeigeobjekten zur Verfügung zu
stellen. Mittels dynamischer Anzeigeobjekte kann das Verhalten einer
Anwendung geändert
werden, ohne neuen Code herunterladen oder die Anwendung erneut
kompilieren oder binden zu müssen.
-
Die
dynamischen Anzeigeobjekte können
in XML-Schemata beschrieben werden. Diese Schemata können in
Spaces angekündigt
werden. Diese Schemata können
als Anzeigeschemata oder Darstellungsschemata bezeichnet werden.
Eine Anwendung (oder andere Dienste, die im Namen der Anwendung
agieren) kann dann auf die Schemata aus den Dienstannoncen zur Anzeige
von Daten auf der Basis der Formatierung, des Datentyps und anderer
in den Schemata gespeicherter Information zugreifen.
-
Das
Folgende ist ein Beispiel eines Schemas, das dynamische Anzeigeobjekte
enthält:
-
Das
obenstehende Schema kann in das folgende geändert werden, ohne daß eine Anwendung
erneut kompiliert werden muß:
-
Die 32A und 32B stellen
Beispiele der Verwendung von Schemata von dynamischen Anzeigeobjekten
gemäß einer
Ausführungsform
dar. In 32A wurde die Anwendung 1320 (kann
ein Client, ein Dienst oder eine anderen Anwendung sein) mit der
in dem Space 1326 gespeicherten Annonce 1324 eines Darstellungsschemas
implementiert. Eine Annonce eines Darstellungsschemas kann Elemente
enthalten, die die Datentypen, Formatierungsspezifikationen, Zeichensätze, Positionen,
Farben und jede andere Information zur Anzeige von Daten für die Anwendung
auf der Anzeige 1322 enthalten. Es kann mehrere Annoncen
eines Darstellungsschemas für
die Anwendung 1320 geben. Zum Beispiel kann es ein Schema
für jede
Anzeigeseite in einer Reihe von Anzeigeseiten geben (zum Beispiel
Webseiten in einer Website).
-
In
einer Ausführungsform
kann die Anwendung 1320 einen Auffindungs- und/oder Nachschlagedienst aufrufen,
um Annoncen eines Darstellungsschemas zu lokalisieren. Der Auffindungs- und/oder Nachschlagedienst
kann ein XML-Dokument liefern, das eine oder mehrere Annoncen und
URIs zu jedem der ein bestimmtes Anzeigeformat beschreibenden Schemata,
etc. auflistet. Die Anwendung 1320 kann dann ein Darstellungsschema
oder -schemata aus dem XML-Dokument auswählen. Die Anwendung 1320 kann
danach das Schema analysieren und dabei die Elemente des Schemas
in Komponenten einer Benutzerschnittstelle aufbrechen. Die Komponenten
können
daraufhin verwendet werden, um Ergebnisdaten auf der passenden Anzeige
zu plazieren, zu formatieren und anzuzeigen. Die Ergebnisdaten können zum
Beispiel vom Ausführen
eines Dienstes oder aus einem Ergebnis-Space sein. Somit ist die
Anwendung 1320 im Unterschied zu einer statischen oder
vorab festgelegten Anzeige dafür
eingerichtet, Ergebnisse gemäß einem
Darstellungsschema anzuzeigen, das dynamisch geändert werden kann, ohne ein
erneutes Bauen anzuzeigen, das dynamisch geändert werden kann, ohne ein
erneutes Bauen der Anwendung zu erfordern.
-
Darstellungsschemata
können
zum Anzeigen desselben Ergebnisses in verschiedenen Formaten, zum
Extrahieren von Teilen der Ergebnisse zur Anzeige und zum Anzeigen
der Ergebnisse auf unterschiedlichen Anzeigeeinrichtungen bereitgestellt
werden.
-
In
einer Ausführungsform
können
eine oder mehrere Annoncen eines Darstellungsschemas in einem oder
mehreren Spaces in der verteilten Rechnerumgebung gespeichert werden.
Wenn Kopien einer Anwendung auf einer oder mehreren Einrichtungen
aufgerufen werden, kann jede Kopie der Anwendung eine Suche nach
Diensten ausführen,
um Annoncen für
von den Anwendungen verwendete Darstellungsschemata aufzufinden.
Somit kann ein zentraler, dauerhafter Speicher der Anzeigeinformation
für mehrere
Instanzen der Anwendung oder für
andere Anwendungen gehalten werden. Die Anzeigeinformation kann
an der zentralen Stelle geändert
werden, ohne daß das
erneute Kompilieren und/oder Installieren der Anwendungen erforderlich
ist.
-
In 32B kann der Client 1328 eine Dienstannonce
für den
Dienst 1330 in einem Space lokalisieren. Beim Aufruf des
Dienstes 1330 kann der Client 1328 einen Ort bzw.
eine Lage der Annonce 1324 des Darstellungsschemas in dem
Space 1326 an den Dienst 1330 übergeben. Wenn der Dienst 1330 bereit
ist, dem Client 1328 Ergebnisse bereitzustellen, kann er
die Ergebnisse mittels der Anzeigeinformation aus dem Darstellungsschema,
das durch die Annonce 1324 des Darstellungsschemas zur
Verfügung
gestellt wurde, auf der Anzeige 1322 anzeigen (die mit
der Einrichtung, auf der der Client 1328 abläuft, verbunden
sein kann). Um die Art und Weise, in der Ergebnisse angezeigt werden,
zu ändern,
können
die XML-Nachrichten in der Annonce 1324 des Darstellungsschemas
geändert
werden, oder es kann ein anderes Darstellungsschema ausgewählt werden, ohne Änderungen
bei dem Client 1328 oder dem Dienst 1330 zu erfordern.
Der Dienst 1330 kann ein Anzeigedienst sein.
-
Ein
Client, eine Anwendung oder ein Dienst können eine Mehrzahl von Anzeigeschemata
zum Anzeigen von Ergebnissen verschiedener Operationen, die von
einem oder mehreren Diensten bereitgestellt werden, vorsehen. Alternativ
kann ein Anzeigeschema Information zum Anzeigen einer Vielzahl von
Ergebnissen für
einen oder mehrere Clients beinhalten. Somit kann der Client 1328 ein
Anzeigeschema oder eine Mehrzahl von Anzeigeschemata verwenden.
Zwei oder mehr Anzeigeschemata können
zum Formatieren und Anzeigen derselben Ergebnisse mit unterschiedlichen
Formaten oder auf unterschiedlichen Anzeigen vorgesehen werden.
Zum Beispiel kann ein Anzeigeschema für einen Satz von Ergebnissen
zum Anzeigen von Ergebnissen auf einem Anzeigebildschirm und ein
anderes zum Drucken der Ergebnisse vorgesehen werden. Ebenso können Kopien
derselben Anwendung, desselben Client oder desselben Dienstes auf
Einrichtungen mit unterschiedlichen Anzeigefähigkeiten ablaufen, so daß zwei oder
mehr Anzeigeschemata zur Unterstützung
der Anzeigeerfordernisse auf den unterschiedlichen Einrichtungen
zur Verfügung
gestellt werden.
-
Zeichenkettenverwaltung
-
Die
Behandlung von Zeichenketten in herkömmlichen Systemen ist im allgemeinen
nicht sehr effizient, speziell für
Zeichenketten variabler Größe, und
kann Speicherplatz verschwenden, z. B. wenn die Zeichenkette in
dem Speicher kopiert und/oder verschoben wird. Diese Ineffizienz
bei der Behandlung von Zeichenketten kann insbesondere in Systemen
mit kleiner Speicherauslegung wie eingebetteten Systemen problematisch sein.
Die Menge von Speicher, besonders Stackspeicher und Speicher zum
dynamischen Belegen, kann in kleinformatigen Systemen eingeschränkt sein.
Daher ist ein effizienteres Verfahren zur Behandlung von Zeichenketten
in Programmen, die in kleinformatigen Systemen wie eingebetteten
Systemen ausgeführt
werden, wünschenswert.
-
33A stellt einen typische Zeichenkettenrepräsentation
in der Programmiersprache C dar. In C kann eine Zeichenkette durch
einen Zeichenzeiger 1450 (Zeichenkette 1 bzw. string1)
repräsentiert
werden, der eine Speicherstelle (Adresse) des ersten Zeichens einer
Zeichenkette 1452 enthält.
Andere Zeichen folgen dem ersten Zeichen in der Zeichenkette 1452 und
werden typischerweise in fortlaufend adressierbaren Byteplätzen im
Speicher gespeichert. Zeichen in C-Zeichenketten sind typischerweise 8-Bit-Werte.
Die Zeichen in C-Zeichenketten können
jedes beliebige ASCII-Zeichen sein. Eine C-Zeichenkette muß mit einem
NULL-Zeichen abgeschlossen werden. NULL ist plattformabhängig als
einer der 256 möglichen
8-Bit-Werte definiert, ist jedoch typischerweise der Binärwert 0b00000000.
Die Zeichenkette 1452 umfaßt 13 Bytes (12 Zeichen der Zeichenkette
plus das abschließende
Zeichen).
-
Ein
Beispiel einer Zeichenkettenoperation in C ist die Funktion strlen(),
die typischerweise bei Implementierungen der Standard-C-Bibliothek
zur Verfügung
steht. Die Funktion strlen() nimmt einen Zeichenkettenzeiger als
Eingabe und gibt die Länge
(in Bytes) der Zeichenkette ohne das abschließende Zeichen zurück. Zum
Beispiel würde
die Übergabe
des Zeichenzeigers 1450 an die Funktion strlen() die Länge 12 zurückliefern.
Die Funktion strlen() kann durch "Durchschreiten" der Zeichenkette bis zum Lokalisieren
des abschließenden
Zeichens implementiert werden, wobei jedes Zeichen gezählt wird.
-
Das
Kopieren von Zeichenketten in C wird typischerweise von einer der
C-Bibliothekffunktionen strcpy() oder strncpy() behandelt, die implementiert
sind als:
char *strcpy(char *dest, const char *src);
char
*strncpy(char *dest, const char *src, size_t n);
-
Die
Funktion strcpy() kopiert die Zeichenkette, auf die der Zeichenzeiger
src zeigt (einschließlich
des abschließenden
Zeichens) in die Zeichenkette, auf die der Zeichenzeiger dest zeigt.
Die Zeichenketten dürfen sich
nicht überlappen,
und die Zielzeichenkette muß groß genug
für die
Aufnahme der Kopie sein.
-
Die
Funktion strncpy() ist ähnlich,
außer
daß nicht
mehr als n Bytes von src kopiert werden. Wenn daher kein abschließendes Zeichen
unter den ersten n Bytes von src ist, ist das Ergebnis nicht abgeschlossen. Wenn
es gewünscht
wird, kann im Anschluß an
ein strncpy() eine Anweisung in den Code gesetzt werden, um ein
abschließendes
Zeichen an das Ende der Zeichenkette dest anzufügen. In dem Fall, daß die Länge von src
kürzer
als n ist, wird der Rest von dest mit Nullen aufgefüllt. Die
Funktionen strcpy() und strncpy() geben einen Zeiger auf die Zielzeichenkette
dest zurück.
-
33B stellt ein Beispiel der Ergebnisse der Funktion
strncpy() auf der Zeichenkette 1452 dar, wenn strncpy()
mit den folgenden Parametern aufgerufen wird:
strncpy(string2,
string1+3, 5);
wobei string2 ein Zeichenzeiger 1454 ist,
der auf das erste Byte hinter dem abschließenden Zeichen der Zeichenkette 1452 zeigt,
string1+3 ist der Zeichenzeiger 1450, inkrementiert um
3, und 5 ist die Anzahl von Zeichen (Bytes), die aus der Quellokation
string1+3 nach string2 zu kopieren ist. Nach dem Kopieren kann das nächste Zeichen
hinter den aus string1 kopierten fünf Zeichen auf ein abschließendes Zeichen
gesetzt werden (das Zeichen kann mit dem abschließenden Zeichen
vor dem Kopieren initialisiert worden sein). Somit belegen die beiden
Zeichenketten nun (13 + 6) = 19 Bytes im Speicher. Wenn die Funktion
strcpy() mit dem Zeichenzeiger 1450 als Quellzeichenkette
angewandt wurde, würden
die ursprüngliche
Zeichenkette 1452 und die resultierende neue Zeichenkette
(13·2)
= 26 Bytes belegen.
-
33C stellt ein effizientes Verfahren zur Repräsentation
und Verwaltung von Zeichenketten im allgemeinen und in kleinformatigen
Systemen wie eingebetteten Systemen im besonderen dar. Die Zeichenkette 1452 wird
im Speicher als 12 Bytes gespeichert (kein abschließendes Zeichen
ist erforderlich). Die Zeichenkettenstruktur 1460 enthält Zeiger
(Adresse(A) und Adresse(L)) auf das erste und letzte Zeichen der
Zeichenkette 1452. Mittels dieser Zeichenkettenstruktur
kann die Länge
der Zeichenkette effizient durch Subtrahieren des Zeigers auf das
ersten Zeichen von dem Zeiger auf das letzte Zeichen berechnet werden.
-
Operationen
wie die Zeichenkettenkopier-Operationen strcpy() und strncpy() können auch
effizienter behandelt werden. Mit den Zeichenkettenstrukturen wie
den in 33C dargestellten kann eine
neue Zeichenkettenstruktur 1462 erzeugt werden, und die
Zeiger auf das erste und letzte Zeichen können initialisiert werden, um
auf die entsprechenden Zeichen in der Zeichenkette 1452 zu
zeigen. Somit braucht ein Teil von der Zeichenkette 1452 oder
die gesamte Zeichenkette 1452 nicht in einen neuen Speicherplatz
für die
Zeichenkette kopiert zu werden. Da Zeichenketten Hunderte oder sogar
Tausende von Zeichen lang sein können,
kann der Speicher, der mittels der Zeichenkettenstrukturen und der
Zeichenkettenverfahren, die implementiert sind, um Vorteil aus ihnen
zu ziehen, gespart wird, beträchtlich
sein. Dieses Verfahren zur Behandlung von Kopien von Teilen einer
Zeichenkette oder einer gesamten Zeichenkette kann als "Teilzeichenketten-Verwaltung" bezeichnet werden,
da es mit der effizienten Behandlung von Teilen (Teilzeichenketten)
von Zeichenketten zu tun hat.
-
Andere
Zeichenkettenfunktionen aus der Standard-C-Zeichenketten-Bibliothek
können
durch Zeichenkettenfunktionen ersetzt werden, die Vorteil aus der
Zeichenkettenstruktur, wie in
33C dargestellt, ziehen.
Beispiele von anderen C-Zeichenkettenfunktionen umfassen, sind jedoch
nicht beschränkt
auf: strstr(), strcat() und sprintf(). Die Strukturen und Verfahren
zur Zei chenkettenbehandlung, wie in
33C beschrieben, können zusammen
mit der hierarchischen Struktur von XML-Dokumenten verwendet werden,
um eine effizientere Behandlung von XML-Text (wie XML-Nachrichten)
in Systemen mit kleinem Speicherausbau wie eingebettete Systeme
zur Verfügung
zu stellen. Das Folgende ist ein einfaches Beispiel eines XML-Schemas,
das einen Kaufauftrag beschreibt:
-
Die
hierarchische Struktur von XML-Dokumenten kann es ermöglichen,
sie in einer rekursiven Weise zu verarbeiten, wobei auf jeder Stufe
der Rekursion zunehmend kleinere Teile des Dokumentes verarbeitet werden.
Referenzen zu verschiedenen Teilen werden rekursiv aufgenommen und
verarbeitet. Zeichenkettenstrukturen, wie in Bezug auf 33C beschrieben, können zur Aufnahme der verschiedenen
Teile verwendet werden. Auf diese Weise kann der Inhalt des spezifischen
XML-Tags (eine Zeile in dem obigen Beispiel), In einer Ausführungsform
die kleinste Einheit des rekursiv verarbeiteten XML-Dokumentes,
effizient bestimmt werden. Dokumente mit wiederhol ten Tags im selben
Gültigkeitsbereich
können
auch effizient behandelt werden, da Tags innerhalb eines gegebenen
Gültigkeitsbereichs
aufgezählt
und effizient verarbeitet werden können.
-
Ein
rekursives Verfahren zum Verarbeiten eines XML-Dokumentes mittels ähnlicher
Zeichenkettenstrukturen wie den in 33C beschriebenen
kann eine Zeichenkettenstruktur akzeptieren, die das gesamte XML-Dokument
repräsentiert
und auf das erste Byte und das letzte Byte in der Dokument-Zeichenkette
zeigt. Das Verfahren kann dann den nächsten Unterabschnitt des Dokumentes
lokalisieren und eine Zeichenkettenstruktur, die die Teilzeichenkette
des gesamten Dokumentes repräsentiert,
die den Unterabschnitt enthält,
an eine Verarbeitungsfunktion für
den Typ des Unterabschnitts übergeben.
Der Unterabschnitt kann selbst in andere Stufen von Unterabschnitten
gebrochen werden, die durch Zeichenkettenstrukturen repräsentiert
werden, welche an Verarbeitungsfunktionen für den Typ des Unterabschnitts übergeben
werden. Das Verfahren kann mit der rekursiven Verarbeitung der Unterabschnitte
des XML-Dokumentes fortfahren, bis das gesamte Dokument verarbeitet
worden ist.
-
Die
Verwendung der Zeichenkettenstrukturen bei der rekursiven Verarbeitung
ermöglicht
es, daß die Verarbeitung
ohne Erzeugen von Kopien der Unterabschnitte zur Verarbeitung vorgenommen
wird. Das Kopieren von Unterabschnitten kann bei rekursiver Verarbeitung
besonders aufwendig sein, weil beim Tiefergehen der Rekursion mehr
und mehr Kopien derselben Daten gemacht werden. Mittels der Zeichenkettenstrukturen
braucht nur die Zeichenkettenstruktur, die die Zeiger auf das erste
und letzte Byte in dem Unterabschnitt enthält, erstellt und hinunter an
die nächste
Stufe übergeben
zu werden. Andere Operationen wie das Feststellen der Länge eines
Unterabschnittes können
effizient mittels der in den Zeichenkettenstrukturen gespeicherten
Adreßinformation
durchgeführt
werden. Auch sind durch das Verwendung der Zeichenkettenstrukturen
abschließende
Zeichen wie die zum Abschließen
von C-Zeichenketten verwendeten nicht notwendig, wodurch in kleinformatigen
Systemen wie eingebetteten Systemen Speicher gespart wird.
-
XML-Repräsentation
von Objekten
-
Wie
zuvor erwähnt
ist Jini-RMI möglicherweise
für einige
Clients wie Thin-Clients mit minimaler Speicherauslegung und minimaler
Bandbreite nicht praktikabel. Die mit Jini-RMI verbundene Serialisierung
ist langsam, groß,
erfordert das JVM-Reflection-API und ist eine Java-spezifische Objektrepräsentation.
Die Deserialisation von Java ist auch langsam, groß und erfordert
einen Parser für
serialisierte Objekte. Sogar Java-basierte Thin-Clients können nicht
in der Lage sein, sehr große
Java-Objekte (mit den benötigten
Klassen) zu akzeptieren, die (notwendigerweise) über das Netzwerk an den Client
zurückgeliefert
werden, wie in Jini erforderlich.
-
Ein
besser skalierbarer Mechanismus für verteilte Verarbeitung kann
durch Ausführungsformen
einer verteilten Rechnerumgebung bereitgestellt werden. Eine verteilte
Rechnerumgebung kann eine API-Schicht zur Erleichterung der verteilten
Verarbeitung beinhalten. Die API-Schicht stellt Leistungsmerkmale
bzw. Möglichkeiten
zum Senden und Empfangen von Nachrichten zwischen Clients und Diensten
bereit. Dieses API zum Senden von Nachrichten kann eine Schnittstelle für einfache
Nachrichten in einem Daten- oder Meta-Datenformat zur Repräsentation
wie in der eXtensible Mark-up Language (XML) vorsehen. Man beachte,
daß andere
Meta-Daten-artige Sprachen oder Formate in alternativen Ausführungsformen
verwendet werden können,
während
hier Ausführungsformen,
die XML einsetzen, beschrieben sind. Nach einigen Ausführungsformen
kann die API-Schicht auch eine Schnittstelle für Nachrichten zur Kommunikation
zwischen Objekten oder zur Übergabe
von Objekten wie Java-Objekten vorsehen. Objekte, auf die über die
API-Schicht 102 zugegriffen werden kann, werden durch ein
Datenformat zur Repräsentation
wie XML dargestellt. Somit kann eine XML-Repräsentation eines Objektes manipuliert
werden im Gegensatz zu dem Objekt selbst.
-
Die
API-Schicht kann oberhalb einer Nachrichtenschicht sitzen. Die Nachrichtenschicht
kann auf einem Datenformat zur Repräsentation wie XML basieren.
In einer Ausführungsform
werden XML-Nachrichten durch die Nachrichtenschicht gemäß Aufrufen
der API-Schicht erzeugt. Die Nachrichtenschicht sieht definierte, statische
Nachrichten vor, die zwischen Clients und Diensten gesendet werden
können.
Die Nachrichtenschicht kann auch dynamisch erzeugte Nachrichten
vorsehen. In einer Ausführungsform
kann ein wie ein Java-Objekt dynamisch in eine XML-Repräsentation
umgewandelt (kompiliert) werden. Das Objekt kann Code- und/oder
Daten-Anteile enthalten. Die Code- und/oder Daten-Anteile eines Objektes
können
in Code- und Datensegmente kompiliert werden, die in der XML-Repräsentation
durch XML-Tags identifiziert werden. Die Nachrichtenschicht kann
dann die XML-Objekt-Repräsentation
als eine Nachricht senden. Umgekehrt kann die Nachrichtenschicht
eine XML-Repräsentation
eines Objektes empfangen. Das Objekt kann dann aus dieser Nachricht
wieder aufgebaut (dekompiliert) werden. Der Wiederaufbau kann die
XML-Repräsentation
auf Tags untersuchen, die Code- und/oder Datensegmente der XML-Repräsentation
identifizieren, und die in den Tags gespeicherte Information verwenden,
um die Code- und/oder Daten-Anteile des Objektes zu identifizieren
und zu dekompilieren.
-
Erzeugen und Senden einer
XML-Repräsentation
eines Objektes
-
34 stellt einen Vorgang des Verschiebens von Java-Objekten
zwischen einem Client 1500 und einem Dienst 1502 gemäß einer
Ausführungsform
dar. Der Dienst 1502 kann irgendein Dienst sein, der in
der verteilten Rechnerumgebung unterstützt wird, einschließlich Space-Diensten.
Der Client 1500 setzt das Gatter 1504 ein, das
mittels eines aus einer Dienstannonce für den Dienst 1502 empfangenen
XML-Schemas erzeugt wurde, um mit einem entsprechenden Gatter 1506 für den Dienst 1502 zu
kommunizieren. Zu einem bestimmten Zeitpunkt kann der Client 1500 ein
Java-Objekt 1510 an
den Dienst 1502 zu senden haben. Das Java-Objekt 1510 kann
andere Objekte referenzieren, die ihrerseits andere Objekte referenzieren,
und so weiter. Das Java-Objekt 1510 und seine referenzierten
Objekte, die Objekte, die sie ihrerseits referenzieren, und so weiter, können als
ein Objekt-Graph bezeichnet werden.
-
Das
Java-Objekt 1510 kann an einen Kompilierungsprozeß 1512 für Java-Objekte
zum Kompilieren übergeben
werden, um eine XML-Repräsentation
des Objekt-Graphen zu erstellen. Die XML-Repräsentation des Objekt-Graphen
kann als ein XML-Datenstrom 1514 an das Gatter 1504 übergeben
werden. Der XML-Datenstrom 1514 kann eine XML-Repräsentation
aller Objekte in dem Objekt-Graphen beinhalten. In einer Ausführungsform
können
die Objekte in dem Objekt-Graphen rekursiv in dem XML-Datenstrom 1514 gespeichert sein.
-
Das
Gatter 1504 kann daraufhin den XML-Datenstrom 1514 in
eine Nachricht 1516 einpacken und die Nachricht 1516 an
das Gatter 1506 des Dienstes 1502 senden. Das
Gatter 1506 kann den XML-Datenstrom 1514 aus der
XML-Nachricht 1516 extrahieren und den XML-Datenstrom 1514 an
einen Dekompilierungsprozeß 1518 für XML-Datenströme zum Dekompilieren
senden, um das Objekt oder die Objekte, aus denen der Objekt-Graph
besteht, einschließlich
des Java-Objektes 1510, zu erstellen. In einer Ausführungsform
können die
Objekte in dem Objekt-Graphen rekursiv in dem XML-Datenstrom 1514 gespeichert
sein, und daher kann ein rekursiver Dekompilierungsprozeß verwendet
werden.
-
Wenn
der Dienst 1502 ein Java-Objekt an den Client 1500 senden
muß, kann
ein im Wesentlichen gleicher Vorgang verwendet werden. Das Java-Objekt 1520 kann
an den Kompilierungsprozeß 1512 für Java-Objekte
zum Kompilieren übergeben
werden, um eine XML-Repräsentation
des Objekt-Graphen zu erstellen. Die XML-Repräsentation des Objekt-Graphen
kann als ein XML-Datenstrom 1522 an
das Gatter 1506 übergeben
werden. Das Gatter 1506 kann daraufhin den XML-Datenstrom 1522 in
eine Nachricht 1524 einpacken und die Nachricht 1524 an
das Gatter 1504 des Client 1500 senden. Das Gatter 1504 kann
den XML-Datenstrom 1522 aus der XML-Nachricht 1524 extrahieren
und den XML-Datenstrom 1522 an einen Dekompilierungsprozeß 1518 für XML-Datenströme zum Dekompilieren
senden, um das Objekt oder die Objekte, aus denen der Objekt-Graph
besteht, einschließlich
des Java-Objektes 1520, zu erstellen.
-
In
einer anderen Ausführungsform
können
die Gatter für
das Kompilieren und Dekompilieren der Java-Objekte verantwortlich
sein. In dieser Ausführungsform
kann das Java-Objekt 1510 an das Gatter 1504 übergeben
werden. Das Gatter 1504 kann dann das Objekt 1510 an
einen Kompilierungsprozeß 1512 für Java-Objekte
zum Kompilieren übergeben,
um eine XML-Repräsentation
des Objekt-Graphen in einem XML-Datenstrom 1514 zu erstellen.
Das Gatter 1504 kann daraufhin den XML-Datenstrom 1514 in
eine Nachricht 1516 einpacken und die Nachricht 1516 an
das Gatter 1506 des Dienstes 1502 senden. Das
Gatter 1506 kann den XML-Datenstrom 1514 aus der
XML-Nachricht 1516 extrahieren
und den XML-Datenstrom 1514 an einen Dekompilierungsprozeß 1518 für XML-Datenströme zum Dekompilieren
senden, um das Objekt oder die Objekte, aus denen der Objekt-Graph
besteht, einschließlich
des Java-Objektes 1510, zu erstellen. Der Vorgang des Sendens
eines Java-Objektes von dem Dienst 1502 an den Client 1500 kann
im Wesentlichen der gleiche sein wie der Vorgang des Sendens eines
Objektes von dem Client an den Dienst.
-
In
einer Ausführungsform
können
der Kompilierungsprozeß 1512 für Objekte
und der Dekompilierungsprozeß 1518 für Objekte
beide auf dem Client 1500 und dem Dienst 1502 vorhanden
sein, und können programmiert
sein, um das Kompilieren und Dekompilieren auf den beiden Einrichtungen
im Wesentlichen in gleicher Weise durchzuführen, wodurch sichergestellt
wird, daß die Ausgabe
eines Objekts oder von Objekten an einem Ende im Wesentlichen identisch
mit der Eingabe eines Objekts oder von Objekten am anderen Ende ist.
In einer Ausführungsform
können
XML-Schemata einschließlich der
Beschreibungen von Java-Objekten sowohl auf dem Client als auch
auf dem Dienst oder nur auf einem von beidem in den Kompilierungs-
und Dekompilierungsprozessen verwendet werden. In einer Ausführungsform
können
das XML-Schema oder die XML-Schemata,
die beim Kompilieren und Dekompilieren der Java-Objekte zu verwenden
sind, von dem Dienst in einer Dienstannonce an den Client übergeben
werden.
-
XML
stellt ein sprach- und plattformunabhängiges Format zur Repräsentation
von Objekten dar. Daher braucht der Vorgang wie in 34 dargestellt, bei dem ein Objekt in eine XML-Repräsentation
des Objektes kompiliert wird und zur Wiederherstellung des Objektes
dekompiliert wird, nicht auf das Verschieben von Java-Objekten beschränkt zu werden,
sondern kann nach einigen Ausführungsformen
auf das Verschieben von Objekten anderer Typen zwischen Einheiten
in einem Netzwerk angewendet werden.
-
46 stellt einen Mechanismus zum Senden von Objekten
von Diensten an Clients mittels XML-Repräsentationen der Objekte dar.
In Schritt 2200 kann ein Client ein Objekt von einem Dienst
anfordern. In einer Ausführungsform
kann das Objekt ein Java-Objekt sein. In einer Ausführungsform
kann der Client eine Nachricht (z. B. eine XML-Nachricht) an den
Dienst senden, die das Objekt anfordert. In Schritt 2202 kann
der Dienst, nachdem er die Anforderung empfangen hat, das Objekt
einem Kompilierungsprozeß übergeben.
In einer Ausführungsform
kann der Kompilierungsprozeß in
der virtuellen Maschine, innerhalb welcher der Dienst ausgeführt wird,
integriert sein. In einer Ausführungsform
kann die virtuelle Maschine eine Virtuelle Java-Maschine (JVM) sein.
In einer Ausführungsform
kann der Kompilierungsprozeß als
eine Erweiterung der JVM bereitgestellt werden. In Schritt 2204 erzeugt
der Kompilierungsprozeß eine
Darstellung des Objektes in einer Datenrepräsentationssprache. In einer
Ausführungsform
ist die Datenrepräsentationssprache
XML. Die Darstellung des Objektes kann einen Namen oder Bezeichner
für das
Objekt und eine oder mehrere Instanzvariablen für das Objekt beinhalten. Eine
Instanzvariable in der Objekt-orientierten Programmierung ist eine
der Variablen einer Klassenvorlage, die verschiedene Werte für jedes
Objekt dieser Klasse haben kann. In Schritt 2206 kann der
Dienst die Darstellung des Objektes in der Datenrepräsentationssprache
an den Client senden. In einer Ausführungsform kann die Darstellung
in eine Nachricht eingepackt sein. In einer Ausführungsform liegt die Nachricht
in der Datenrepräsentationssprache
vor. Nachrichtengatter, wie hier an anderer Stelle beschrieben,
können
zur Übergabe
von Nachrichten zwischen dem Client und dem Dienst verwendet werden.
-
In
Schritt 2208 empfängt
der Client die Darstellung des Objektes in der Datenrepräsentationssprache und übergibt
die Darstellung an einen Dekompilierungsprozeß. In einer Ausführungsform
kann der Dekompilierungsprozeß in
der virtuellen Maschine, innerhalb welcher der Client ausgeführt wird,
integriert sein. In einer Ausführungsform
kann die virtuelle Maschine eine Virtuelle Java-Maschine (JVM) sein.
In einer Ausführungsform
kann der Dekompilierungsprozeß als
eine Erweiterung der JVM bereitgestellt werden. In Schritt 2210 kann
die Dekompilierung eine Kopie des Ob jektes aus der Darstellung des
Objektes in einer Datenrepräsentationssprache
erzeugen. Das Objekt kann dann an den Client weitergereicht werden.
-
JVM-Kompilierungs-/Dekompilierungs-API
-
Die 35a und 35b sind
Datenflußdiagramme,
die Ausführungsformen
darstellen, bei denen eine virtuelle Maschine (z. B. JVM) Erweiterungen
für das
Kompilieren von Objekten (z. B. Java-Objekten) in XML-Repräsentationen
der Objekte und für
das Dekompilieren von XML-Repräsentationen
von (Java-)Objekten in (Java-)Objekte beinhaltet. Die JVM kann eine
Anwendungsprogrammschnittstelle (Application Programming Interface,
API) zu den Kompilierungs-/Dekompilierungs-Erweiterungen
liefern. Der Client 1500 und der Dienst 1502 können innerhalb
von JVMs ausgeführt
werden. Die JVMs können
auf derselben Einrichtung oder auf verschiedenen Einrichtungen sein.
-
Sowohl
in 35a als auch in 35b kann das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 ein
Java-Objekt 1510 als Eingabe akzeptieren und eine XML-Repräsentation
des Objektes 1510 und aller von ihm referenzierten Objekte
(des Objektgraphen des Objektes 1510) in einem XML-Datenstrom 1514 ausgeben.
Darüber
hinaus kann das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 einen
XML-Datenstrom 1522 akzeptieren, der eine XML-Repräsentation
des Objektes 1520 und aller von ihm referenzierten Objekte
(des Objektgraphen des Objektes 1520) enthält, und
das Java-Objekt 1520 (und alle Objekte in seinem Objektgraphen)
ausgeben.
-
35a stellt eine Ausführungsform dar, in der der
Client beim Senden des Java-Objektes 1510 das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufruft.
Der Client 1500 übergibt
das Java-Objekt 1510 an das API 1530, welches
das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert
die XML-Repräsentation
in dem XML-Datenstrom 1514 und gibt den XML-Datenstrom 1514 aus.
Der Client kann daraufhin den XML-Datenstrom 1514 an das
Gatter 1504 übergeben.
Das Gatter 1504 kann dann den XML-Datenstrom 1514 in
eine XML-Nachricht 1516 verpacken und die Nachricht 1516 an
den Dienst 1502 senden.
-
Beim
Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann
das Gatter 1522 den XML-Datenstrom 1522 aus der
Nachricht 1524 extrahieren und den Datenstrom 1522 an
den Client 1500 übergeben.
Der Client 1500 kann daraufhin das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufrufen,
wobei er dem API 1530 den XML-Datenstrom 1522 übergibt.
Das API 1530 kann dann den XML-Datenstrom 1522 dekompilieren,
um das Java-Objekt 1520 und die anderen Objekte in seinem
Objektgraphen zu erstellen, wobei es die Objekte an den Client 1500 zurückgibt.
-
35b stellt eine andere Ausführungsform dar, bei der das
JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 beim
Senden des Java-Objektes 1510 von dem Gatter aufgerufen
wird. Der Client 1500 übergibt
das Java-Objekt 1510 an das Gatter 1504. Das Gatter 1504 übergibt
daraufhin das Objekt 1510 an das API 1530, das
das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert
die XML-Repräsentation
in dem XML-Datenstrom 1514 und gibt den XML- Datenstrom 1514 aus.
Das Gatter 1504 kann dann den XML-Datenstrom 1514 in
eine XML-Nachricht 1516 verpacken
und die Nachricht 1516 an den Dienst 1502 senden.
-
Beim
Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann
das Gatter 1522 den XML-Datenstrom 1522 aus der
Nachricht 1524 extrahieren und den Datenstrom 1522 an
das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 übergeben.
Das API 1530 kann dann den XML-Datenstrom 1522 dekompilieren,
um das Java-Objekt 1520 und die anderen Objekte in seinem
Objektgraphen zu erstellen. Das Gatter kann daraufhin das Java-Objekt 1520 und
die anderen Objekte an den Client 1500 senden.
-
In
einer Ausführungsform
können
der JVM-XML-Compiler und -Decompiler als integrierte Funktionen der
JVM implementiert sein. In einer anderen Ausführungsform können der
XML-Compiler und
-Decompiler in API-Methodenaufrufen in Standarderweiterungen der
JVM enthalten bzw. verkörpert
sein; dadurch braucht die Kern-JVM nicht geändert zu werden. Die JVM kann
das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 an
Prozesse (Clients und/oder Dienste) liefern, die innerhalb der JVM
ausgeführt
werden, um es dem Prozessen zu ermöglichen, auf die Funktionalität zum Kompilieren/Dekompilieren
von Java-Objekten zuzugreifen, die von der JVM bereitgestellt wird.
In einer Ausführungsform
muß die
JVM, innerhalb derer der Prozeß ausgeführt wird,
die JVM-XML-Compiler-/Decompiler-Funktionalität und das API 1530 haben,
damit ein Prozeß die
Kompilierung/Dekompilierung von Objekten nutzen kann.
-
Verfahren,
die zum Transformieren und Senden von Objekten Spiegelung bzw. Reflektion
und Serialisierung verwenden, sind typischerweise in Anwendungen
separat von der JVM implementiert. Die Anwendung muß wiederholt
auf die JVM zugreifen, um ein Objekt, ein Feld zu einem Zeitpunkt
auseinanderzupflücken,
während
die transitive Hülle
des Objektes dynamisch analysiert wird. Dies ist tendenziell ein
langsamer und mühsamer
Vorgang, der auch große
Mengen von Anwendungs- und JVM-Code benötigt.
-
Die
Funktionalität
zur Kompilierung/Dekompilierung von Java-Objekten innerhalb der
JVM zu implementieren, ist vorteilhaft, weil die JVM bereits das
Konzept und die Inhalte eines Objektgraphen versteht. Daher können die
Funktionen zur Kompilierung/Dekompilierung das Wissen (und die Wiederverwendung
von Code) der JVM beim Parsen bzw. Analysieren des Objektgraphen
zum Erzeugen der XML-Darstellung und beim Parsen der XML-Darstellung
zum Erzeugen des Objektgraphen wirksam einsetzen. Die Funktionen
zur Kompilierung/Dekompilierung brauchen daher die Funktionalität, die von
der JVM bereitgestellt wird, nicht zu duplizieren, wie es Verfahren
zum Versenden von Objekten tun, die Reflektion und Serialisation
verwenden. Dies kann es ermöglichen,
daß der
Codeumfang der Funktionen zur Kompilierung/Dekompilierung kleiner
ist als derjenige von Verfahren zum Versenden von Objekten, die
Reflektion und Serialisation verwenden. Auch kann ein Objekt durch
einen einzigen Aufruf des JVM-XML-Compiler-/Decompiler-API kompiliert
oder dekompiliert werden.
-
Darüber hinaus
kann es das Integrieren der Kompilierung/Dekompilierung von Objekten
mit der JVM ermöglichen,
daß die
Kompilierung und Dekompilierung von Objekten schneller durchge führt werden
als Verfahren, die Reflektion und Serialisation verwenden, weil
in dem Objekttraversierungsmodell, das mit Reflektion und Serialisation
implementiert ist, der Code außerhalb
der JVM nicht die Struktur oder den Graphen des Java-Objektes kennt
und daher den Objektgraphen traversieren muß, indem er ihn auseinander
zieht, und schließlich
wiederholt die JVM aufrufen muß,
um die Kompilierung (und den umgekehrten Prozeß für die Dekompilierung) zu verrichten.
Dieser Prozeß kann
durch die Notwendigkeit verlangsamt werden, wiederholte Aufrufe
der JVM außerhalb
des Codes vorzunehmen. Die Funktionalität zur Kompilierung und Dekompilierung in
der JVM integriert zu haben, wie hier beschrieben, vermeidet es,
wiederholte Aufrufe der JVM von Code außerhalb der JVM aus vornehmen
zu müssen.
In einer Ausführungsform
kann ein Objekt durch einen einzigen Aufruf des JVM-XML-Compiler-/Decompiler-API
kompiliert oder dekompiliert werden.
-
In
einer Ausführungsform
kann die Funktionalität
zum Kompilieren/Dekompilieren als ein Dienst in der verteilten Rechnerumgebung
implementiert werden. Der Dienst kann eine Dienstannonce in einem
Space veröffentlichen.
Ein Prozeß in
der verteilten Rechnerumgebung kann einen Such- oder Auffindungsdienst
zum Lokalisieren des Kompilierungs-/Dekompilierungsdienstes verwenden.
Der Prozeß (ein
Client des Dienstes) kann daraufhin den Dienst durch Übergabe
von Java-Objekten
zum Kompilieren in XML-Repräsentationen und/oder
von XML-Repräsentation
zum Dekompilieren in Java-Objekte an den Dienst verwenden.
-
Java-Objekte
können
Code (die Methoden des Objektes) und Daten beinhalten. Der Code
eines Objektes kann nicht-transient sein; der Code ändert sich
nicht, sobald ein Objekt kreiert wurde. Die Daten eines Objektes
können
jedoch transient sein. Zwei aus derselben Java-Klasse kreierte Objekte
können
identischen Code beinhalten, jedoch die Daten in den zwei Objekten
können
verschieden sein. In einer Ausführungsform kann
die Kompilierungsfunktion die Daten eines Java-Objektes in eine XML-Repräsentation
des Objektes kompilieren, aber den tatsächlichen Code des Objektes
nicht in die XML-Repräsentation
einbeziehen. In einer Ausführungsform
kann Information über
das Objekt in die kompilierte XML-Repräsentation aufgenommen werden,
um dem Empfänger
anzuzeigen, wie der Code für
das Objekt wiederzuerstellen ist. Die XML-Repräsentation kann dann in einem
XML-Datenstrom gespeichert und (z. B. in einer Nachricht) an einen
empfangenden Prozeß (Client
oder Dienst) gesendet werden. Der empfangende Prozeß kann dann
den XML-Datenstrom
an die Dekompilierungsfunktion übergeben.
Die Dekompilierungsfunktion kann daraufhin den XML-Datenstrom dekompilieren,
um das Java-Objekt einschließlich
seiner Daten zu erzeugen. In einer Ausführungsform kann der Code für das Objekt
durch die Dekompilierungsfunktion unter Verwendung der Information über das
Objekt, die in der XML-Repräsentation
enthalten ist, wiederhergestellt werden, wie auch der Code für ein Objekt statisch
definiert sein kann und die JVM, die das Objekt empfängt, in
der Lage sein kann, den Code (wenn nötig) unter Benutzung ihres
Wissens über
das Objekt wiederherzustellen.
-
In
einer Ausführungsform
kann die durch die Kompilierungsfunktion erzeugte XML-Repräsentation
eines Objektes die Daten des Java-Objektes und Information über das
Java-Objekt beinhalten. Die Information kann Klasseninformation
für das
Java-Objekt umfassen. Eine Objektsi gnatur kann in der Information
enthalten sein und kann verwendet werden, um die Klasse des Objektes,
etc. festzustellen. Die Dekompilierungsfunktion kann den Code für das Java-Objekt
unter Verwendung der Information über das Java-Objekt wieder
erzeugen und kann die Daten aus dem XML-Datenstrom in das Java-Objekt
dekompilieren. Somit kann ein vollständiges Objekt einschließlich seines
Codes und seiner Daten auf der JVM, die den empfangenden Client
oder Dienst ausführt,
aus den dekompilierten Daten und der das Objekt beschreibenden Information
wiederhergestellt werden. In einer Ausführungsform kann die das Objekt
beschreibende Information in einem oder mehreren XML-Tags gespeichert
werden. In einer Ausführungsform
kann der Client oder Dienst, der den XML-Datenstrom empfängt, ein
XML-Schema enthalten, das das Objekt beschreibt, und das XML-Schema
kann verwendet werden, um das Java-Objekt aus den dekompilierten
Daten und aus der Information über
das Java-Objekt wiederherzustellen. Der Dekompilierungsprozeß kann rekursiv
durch den Objektgraphen voranschreiten und dabei die Objekte, die
von dem Objekt referenziert werden, durch Dekompilieren der Daten
der referenzierten Objekte aus dem XML-Datenstrom und durch erneutes Erzeugen
des Codes der referenzierten Objekte aus der Information über die
referenzierten Objekte im XML-Datenstrom wiederherstellen.
-
In
einer Ausführungsform
kann die XML-Repräsentation
des Objektes, die von der Kompilierungsfunktion erzeugt wurde, die
Daten des Objektes und Information, die den Code eines Objektes
bezeichnet, enthalten. In einer Ausführungsform kann die Information,
die den Code des Objektes bezeichnet, in einem oder mehreren XML-Tags
in dem XML-Datenstrom gespeichert werden. Beim Empfang kann die
Dekompilierungsfunktion den Code für das Java-Objekt unter Verwendung
der Information über
den Code aus dem XML-Datenstrom wieder erzeugen und die Daten für das Objekt
aus dem XML-Datenstrom dekompilieren. Somit kann ein vollständiges Objekt
einschließlich
seines Codes und seiner Daten auf der JVM, die den empfangenden Client
oder Dienst ausführt,
aus den dekompilierten Daten und der Information, die den Code des
Objektes beschreibt, wiederhergestellt werden.
-
Zur
Erläuterung
werden einige Szenarien der Verwendung von XML-Repräsentationen
von Objekten zur Übertragung
von Objekten zwischen Gegeständen
bzw. Einheiten (typischerweise Clients und Dienste) in einer verteilten
Rechnerumgebung aufgenommen. Diese Szenarien sind beispielhaft und
sollen nicht einschränkend
sein.
-
In
einem ersten Szenario kann ein Dienst den XML-Compiler-/Decompiler
verwenden, um ein Java-Objekt in eine XML-Repräsentation des Objektes zu kompilieren,
und die XML-Repräsentation
an einen Client senden. Der Client kann daraufhin den XML-Compiler-/Decompiler
verwenden, um die XML-Repräsentation
zu dekompilieren und Operationen auf den Daten innerhalb des Objektes
durchzuführen,
und kann später den
XML-Compiler-/Decompiler verwenden, um das Objekt in eine XML-Repräsentation
des Objektes zu kompilieren und die XML-Repräsentation des Objektes an den
Dienst zurückzugeben.
-
In
einem zweiten Szenario kann ein Dienst den XML-Compiler-/Decompiler
verwenden, um ein Java-Objekt in eine XML-Repräsentation des Objektes zu kompilieren,
und die XML- Repräsentation
an einen Client senden. Der Client kann daraufhin die XML-Repräsentation
an einen anderen Dienst senden, der den XML-Compiler-/Decompiler
verwenden kann, um die XML-Repräsentation
zur Wiederherstellung des Objektes zu dekompilieren, kann Operationen
auf dem Objekt auf Anforderung des Client (möglicherweise zum Verändern der
Daten) durchführen,
den XML-Compiler-/Decompiler zum erneuten Kompilieren des veränderten
Objektes in seine XML-Repräsentation
verwenden und die XML-Repräsentation
des Objektes an den Client senden.
-
In
einem dritten Szenario kann ein Dienst den XML-Compiler-/Decompiler
verwenden, um ein Java-Objekt in eine XML-Repräsentation des Objektes zu kompilieren,
und die XML-Repräsentation
an einen Objekt-Behälter
bzw. ein Objekt-Repository oder einen Speicherplatz senden. Der
Dienst kann daraufhin eine Nachricht an einen Client senden, die
den Client über
den Ort der XML-Repräsentation
informiert. Die Nachricht kann einen Universal Resource Identifier
(URI) für
die XML-Repräsentation
enthalten. Der Client kann dann die XML-Repräsentation des Objektes aus
dem Speicherplatz holen und den XML-Compiler-/Decompiler verwenden,
um die Repräsentation
zur Wiederherstellung des Objektes zu dekompilieren, Alternativ
kann der Client den Ort der XML-Repräsentation
des Objektes zusammen mit einer Anforderung von auf dem Objekt durchzuführenden
Operationen an einen anderen Dienst senden. Der andere Dienst kann
daraufhin die XML-Repräsentation
des Objektes aus dem Speicherplatz holen, den XML-Compiler-/Decompiler
verwenden, um die XML-Repräsentation
zur Wiederherstellung des Objektes zu dekompilieren, und die angeforderten Operationen
auf dem Objekt durchführen.
-
In
einem vierten Szenario kann ein Prozeß (könnte ein Client oder ein Dienst
sein) einen Objekt-Behälter
oder einen Speicherplatz in der verteilten Rechnerumgebung durch
Suchen nach und Finden einer Dienstannonce für den Speicher-Space lokalisieren.
Der Prozeß kann
während
der Ausführung
eine Mehrzahl von Java-Objekten erzeugen und erhalten. Der Prozeß kann den
XML-Compiler-/Decompiler verwenden, um eines oder mehrere der Objekte
in XML-Repräsentationen
der Objekte zu kompilieren, und kann als ein Client des Speicher-Space-Dienstes
die XML-Repräsentationen
der Objekte an den Speicher-Space senden, um sie für einen
späteren
Zugriff oder für
eine Zugriff durch andere Prozesse zu speichern.
-
Sicherheitsaspekte beim
Dekompilieren von XML-Repräsentationen
von Objekten
-
Spaces
können
wie hier beschrieben als ein Dateisystem in der verteilten Rechnerumgebung
dienen. Für
Sicherheit der Dateien in dem System kann in der Form von Zugriffsrechten
gesorgt werden. Zugriffsrechte können
jedesmal überprüft werden,
wenn auf eine Datei zugegriffen (geöffnet, gelesen oder geschrieben)
wird. Somit kann ein Verfahren zur Bereitstellung von Sicherheit
beim Dateizugriff in der verteilten Rechnerumgebung wünschenswert
sein. Dieses Verfahren kann auch auf XML-Repräsentationen von Java-Objekten,
die in Spaces gespeichert und zwischen Clients und Diensten in der
verteilten Rechnerumgebung übermittelt
werden, angewendet werden.
-
In
einer Ausführungsform
kann ein Benutzer eines Client auf einer Einrichtung in der verteilten
Rechnerumgebung identifiziert und authentifiziert werden, wenn er
das erste Mal auf den Client zugreift. In einer Ausführungsform
kann der Benutzer eine physikalische Identifikation wie eine Smart-Card
zur Identifikation und Autorisierung eingeben. In einer anderen
Ausführungsform
kann ein Challenge-Response-Mechanismus (wie eine Benutzer-ID und
ein Paßwort)
zur Identifizierung und Autorisierung verwendet werden. Noch eine
andere Ausführungsform
kann eine elektronische Identifizierung wie eine digitale Unterschrift
zur Identifikation und Autorisierung verwenden. Jede andere Methode
zur Identifizierung und Autorisierung kann verwendet werden.
-
Sobald
der Benutzer einmal identifiziert und autorisiert ist, kann er dann
verschiedene Operationen auf dem Client durchführen, einschließlich des
Zugriffs auf einen oder mehrere Dienste in der verteilten Rechnerumgebung.
Während
dieser Operationen können
wie oben beschrieben ein oder mehrere Objekte (lokal) kreiert oder
von anderswoher erhalten werden (z. B. von Diensten oder aus Spaces).
Die Objekte können
modifiziert und in XML-Repräsentationen
der Objekte kompiliert und lokal von dem Client gespeichert oder
an einen Space-Dienst zur (transienten oder dauerhaften) Speicherung
gesendet werden. Einige der Objekte können von Diensten (Speicherdiensten
oder anderen Diensten) in der Form von XML-Repräsentationen der Objekte geholt
werden, die durch den XML-Compiler-/Decompiler zur Wiederherstellung
der Objekte auf dem Client dekompiliert werden können.
-
In
einer Ausführungsform
kann während
des Dekompilierens der XML-Repräsentation
von Objekten jede XML-Nachricht geprüft werden, um zu überprüfen, daß der Benutzer
Zugriffsrechte auf das Objekt hat. Wenn der Benutzer nicht die passenden
Zugriffsrechte besitzt, darf der XML-Compiler-/Decompiler die Objekte für den Benutzer
nicht dekompilieren. In einer Ausführungsform kann eine Sicherheitsausnahmebedingung von
dem XML-Compiler-/Decompiler aufgeworfen werden. In einer Ausführungsform
kann der Benutzer über die
Zugriffsverletzung informiert werden.
-
Information
zu Zugriffsrechten wie erlaubte Erzeuger- und Zugriffsstufen (nur
Zugriff durch Erzeuger, nur Lesen, Lesen/Schreiben, Löschen, Kopieren,
etc.) für
das Objekt kann in der XML-Nachricht
bzw. den XML-Nachrichten eingebettet sein, die die XML-Repräsentation
des Objektes enthält
bzw. enthalten. Die Zugriffsautorisierung kann während der Identifikation und
Autorsierung des Benutzers ermittelt werden. Zum Beispiel kann das
Objekt einen "nur
lesenden" Zugriff
für die
meisten Benutzer und einen "Schreib-/Lese-"Zugriff für den Erzeuger
des Objektes erlauben. Wenn der Benutzer auf ein Objekt mittels
Schreib-/Lese-Zugriffsrechten zuzugreifen versucht und der Benutzer
das Objekt nicht erzeugt hat, kann der Dekompilierungsprozeß dies als
eine Zugriffsverletzung erkennen und den Zugriff versagen und den
Benutzer verständigen.
-
In
einer Ausführungsform
kann der Benutzer sich abmelden oder anderweitig signalisieren,
daß der Benutzer
mit dem Client fertig ist (z. B. eine Smart-Card entfernen), wenn
der Benutzer mit der Verwendung des Client fertig ist. Objekte,
die auf dem Client durch Dekompilieren erzeugt wurden, können automatisch
gelöscht
werden, wenn der Client entdeckt, daß der Benutzer aufgehört hat.
Dies kann verhindern, daß zukünftige Benutzer
absichtlich oder versehentlich auf die Objekte des Benutzers zugreifen.
In einer Ausführungsform
können
alle durch Dekompilieren erzeugte Objekte gelöscht werden, wenn erkannt wird,
daß der
Benutzer aufgehört
hat. In einer anderen Ausfüh rungsform
kann ein Verfahren zur Verfügung
stehen, um zumindest einige der auf dem Client erzeugten Objekte
dauerhaft zu speichern (z. B. mit Zugriffsrechtinformation), so
daß der
Client später
auf die Objekte zugreifen kann oder die Objekte anderen Benutzern
zum Zugriff zur Verfügung
stellen kann.
-
In
einer Ausführungsform
kann der Benutzer eine "Smart-Card" oder eine andere
physikalische Einrichtung haben, um Zugriff auf den Client zu erlangen.
Der Benutzer kann die Smart-Card in die Clienteinrichtung einsetzen,
um die Sitzung zu beginnen. Wenn der Client fertig ist, kann der
Client bzw. Benutzer die Smart-Card entfernen. Der Client kann das
Entfernen der Smart-Card erkennen und somit erkennen, daß der Client
bzw. Benutzer fertig ist, und kann daraufhin fortfahren, die durch
Dekompilieren von XML-Repräsentationen
erzeugten Objekte zu löschen.
-
XML-basierte
Objekt-Depots
-
In
der verteilten Rechnerumgebung können
Prozesse (Dienste und/oder Clients) transiente und/oder dauerhafte
Speicherung von Objekten wie XML-Schemata, Dienstannoncen, von Diensten
erstellte Ergebnisse, XML-Repräsentationen
von Java-Objekten und/oder in anderen Sprachen implementierten Objekten,
etc. wünschen.
Vorhandene Technologien zur Speicherung von Objekten sind tendenziell
sprach- und/oder betriebssystem-spezifisch. Diese Speicherungssysteme
sind tendenziell auch zu kompliziert, um bei kleinformatigen Systemen
wie eingebetteten Systemen verwendet zu werden.
-
JavaSpaces
in Jini ist ein existierender Mechanismus eines Objekt-Depots. Ein
JavaSpace ist möglicherweise
nur in der Lage, Java-Objekte zu speichern und kann zu groß sein,
um in kleinen Einrichtungen mit begrenzter Speichermenge implementiert
zu werden. Jedes Objekt in einem JavaSpace kann wie zuvor beschrieben
serialisiert werden und hat somit dieselbe Beschränkungen,
wie zuvor für
die Reflektions- und Serialisationstechniken beschrieben.
-
Ein
Speicherungsmechanismus kann für
die verteilte Rechnerumgebung zur Verfügung stehen, der heterogen
sein kann (nicht sprach- oder betriebssystem-abhängig), der von kleinen bis
zu großen
Einrichtungen skaliert werden kann und der vorübergehende oder dauerhafte
Speicherung von Objekten zur Verfügung stellen kann. In einer
Ausführungsform
kann der Speichermechanismus in der verteilten Rechnerumgebung als
eine Web-Seite im Internet oder ein Satz von Seiten implementiert
sein, die in der XML-Auszeichnungssprache definiert sind. XML stellt
ein sprach- und plattform-unabhängiges
Format zur Objektrepräsentation
bereit, das Java- und Nicht-Java-Software in die Lage versetzt,
sprach-unabhängige
Objekte zu speichern und wieder zu holen. Da der Speichermechanismus
auf dem Web ist, können
Einrichtungen aller Arten und Größen (kleine
bis große)
auf den Speichermechanismus zugreifen. Web-Browser können zum
Ansehen des als Web-Seiten implementierten Speichermechanismus' verwendet werden.
Web-Suchmaschinen können
zum Suchen nach Inhalten in dem als Web-Seiten implementierten Speichermechanismus
verwendet werden. Internet-Verwaltungsmechanismen (bestehende und
zukünftige)
und XML-Werkzeuge können
zum Administrieren der XML-basierten Speichermechanismen verwendet
werden.
-
In
einer Ausführungsform
können
die Speichermechanismen zum Speichern von Objekten verwendet werden,
die in XML kreiert, dargestellt oder eingekapselt sind. Beispiele
von Objekten, die in den Speichermechanismen gespeichert werden
können,
umfassen, sind jedoch nicht beschränkt auf: XML-Schemata, XML-Repräsentationen
von Objekten (zum Beispiel Java-Objekte, die wie oben beschrieben
in XML-Repräsentationen
kompiliert wurden), Dienstannoncen und Ergebnisse von Diensten (Daten),
die in XML eingekapselt sind. In einer Ausführungsform kann zum Verhindern
von unautorisiertem Zugriff auf ein XML-Objekt ein Autorisierungsnachweise
wie eine digitale Unterschrift oder ein digitaler Berechtigungsnachweis
in dem XML-Objekt enthalten sein, und von einem Client, der auf
das XML-Objekt zugreifen möchte,
kann verlangt werden, den passenden Autorisierungsnachweis zum Zugriff
auf das XML-Objekt vorzuweisen. In einer Ausführungsform kann der Speichermechanismus
ein Space sein, wie hier in dem Abschnitt über Spaces beschrieben.
-
Die
Speichermechanismen können
Dienste in der verteilten Rechnerumgebung sein. Ein als Dienst implementierter
Speichermechanismus kann als "Speicherdienst" bezeichnet werden.
Ein Speicherdienst kann eine Annonce in einem Space veröffentlichen.
Der Space kann selbst ein Beispiel eines Speicherdienstes sein.
Einige Speicherdienste können
transient (vorübergehender
Natur) sein. Zum Beispiel kann ein Space-Dienst, der Dienstannoncen
speichert, ein transienter Speicher sein. Andere Speicherdienste
können dauerhaft
sein. Zum Beispiel kann ein Speicherdienst, der Ergebnisse von Diensten
speichert, ein dauerhafter Speicher sein.
-
36 stellt einen Client 1604 und einen
Dienst A 1606 dar, die auf die Speichermechanismen 1600 und 1602 in
der verteilten Rechnerumgebung gemäß einer Ausführungsform
zugreifen. Diese Darstellung soll beispielhaft sein und soll den
Anwendungs- bzw. Geltungsbereich dieser Erfindung nicht einschränken. In
einer Ausführungsform
können
die Speichermechanismen 1600 und 1602 jeweils
eine Internet-Webseite oder ein Satz von Webseiten sein, die in
XML definiert sind und über
einen Web-Browser und andere Internet-Werkzeuge zugänglich sind.
Der Speichermechanismus 1600 ist ein transienter Speicher,
der in der Lage ist, mittels XML implementierte Objekte zu speichern.
Der Speichermechanismus 1602 ist ein dauerhafter Speicher,
der auch in der Lage ist, mittels XML implementierte Objekte zu
speichern. Der Dienst A 1606 kann eine XML-Dienstannonce 1608 in
dem transienten Speicher 1600 veröffentlichen. Der dauerhafte
Speicher kann auch eine XML-Dienstannonce in dem transienten Speicher 1600 (oder
in einem anderen transienten Speicher in der verteilten Rechnerumgebung)
veröffentlichen.
Zu einem bestimmten Zeitpunkt kann der Client 1604 von dem
Dienst A 1606 bereitgestellte Funktionalität benötigen. Der
Client 1604 kann einen Auffindungs- und/oder Nachschlagedienst
zum Lokalisieren der Dienstannonce 1608 verwenden. Der
Client 1604 kann daraufhin ein Nachrichtengatter wie hier
beschrieben einrichten und die Kommunikation mit dem Dienst A 1606 beginnen. Der
Client 1604 kann eine oder mehrere XML-Anforderungsnachrichten
an den Dienst A 1606 senden. Der Dienst A 1606 kann
eine oder mehrere Funktionen in Reaktion auf die eine oder mehrere
Anforderungsnachrichten durchfüh ren.
Eine oder mehrere der vom Dienst A 1606 durchgeführten Funktionen
können
Ergebnisse erzeugen, die an den Client 1604 zu übergeben
sind.
-
Für transiente
Ergebnisse
1610 kann der Dienst A
1606 die Ergebnisse
in eine XML-Annonce
1612 einkapseln
und die Annonce
1612 in dem transienten Speicher
1600 (oder
in einem anderen transienten Speicher in der verteilten Rechnerumgebung)
veröffentlichen.
Der Dienst A
1606 kann dann den Client
1604 benachrichtigen,
daß die
Ergebnisse
1610 in der Annonce
1612 in dem transienten
Speicher
1600 gespeichert sind, oder der Client
1604 kann
durch andere hier beschriebene Mechanismen benachrichtigt werden.
Der Client
1604 kann daraufhin die transienten Ergebnisse
1610 aus
der Annonce
1612 holen. Die Annonce
1612 kann
ein XML-Schema enthalten, das die Formatierung, die Inhalte, den
Typ, etc. der transienten Ergebnisse
1610 beschreibt. Die
Ergebnisse können
in XML eingekapselt sein. Zum Beispiel können XML-Tags verwendet werden,
um Bestandteile der Daten zu beschreiben:
-
Für dauerhafte
Ergebnisse 1618 kann der Dienst A 1606 einen Dienst
oder andere hier beschriebene Mechanismen benutzen, um die XML-Dienstannonce 1616 für den dauerhaften
Speicher 1602 zu lokalisieren, und dann den dauerhaften
Speicher 1602 zum Speichern der dauerhaften Ergebnisse
verwenden. Alternativ kann der Client 1604 zuvor den dauerhaften
Speicher 1602 durch Lokalisieren seiner Dienstannonce 1616 lokalisiert
haben und dann einen Universal Resource Identifier (URI) für eine Speicherstelle
für die
dauerhaften Ergebnisse 1618 in einer XML-Nachricht an den
Dienst A senden. In einer Ausführungsform
können
dauerhafte Ergebnisse 1618 in einer Internet-Webseite oder
einem Satz von Webseiten, die in XML definiert und durch einen Web-Browser
zugänglich
sind, gespeichert werden. Der Dienst A 1606 kann dann die
dauerhaften Ergebnisse 1618 in dem dauerhaften Speicher 1602 speichern.
Der Dienst A 1606 kann daraufhin eine XML-Dienstannonce 1616 für die dauerhaften
Ergebnisse 1618 in dem transienten Speicher 1600 (oder
in einem anderen transienten Speicher in der verteilten Rechnerumgebung)
veröffentlichen
und den Ort bzw. die Ortsangabe der Annonce 1616 an den
Client 1604 zurückgeben.
Die Annonce 1616 kann ein XML-Schema enthalten, das die
Formatierung, die Inhalte, den Typ, etc. der dauerhaften Ergebnisse 1618 beschreibt.
Die Ergebnisse können
wie zuvor beschrieben in XML eingekapselt sein. Die Annonce kann
auch den URI der dauerhaften Ergebnisse 1618 enthalten.
Der Client 1604 kann daraufhin die Annonce 1616 holen
und verwenden, um die dauerhaften Ergebnisse 1618 zu lokalisieren
und zu holen. Alternativ kann der Dienst A 1606 keine Annonce
für die
dauerhaften Ergebnisse 1618 veröffentlichen, sondern stattdessen
einen URI für
die dauerhaften Ergebnisse 1618 an den Client 1604 zurückgeben,
so daß der
Client 1604 ohne Nachsehen in einer Annonce auf die Ergebnisse
zugreifen kann. Man beachte, daß in
einigen Ausführungsform
die verschiedenen in dem transienten Speicher 1600 abgebildeten
Annoncen jeweils in unterschiedlichen transienten Speichern oder
Spaces gespeichert sein können.
-
Somit
können
Speichermechanismen als XML-basierte Internet-Webseiten in der verteilten
Rechnerumgebung implementiert werden. Diese Speichermechanismen
können
auf einer Vielzahl von Einrichtungen in der Umgebung implementiert
werden und können
Dienstannoncen bereitstellen, um es Clients (die andere Dienste
sein können)
zu ermöglichen,
die Speichermechanismen zu lokalisieren und zu verwenden. Existierende
und zukünftige
Web- und XML-Werkzeuge können
zum Verwalten der Speichermechanismen verwendet werden. Die Speichermechanismen
können
in XML implementierte oder eingekapselte Objekte verschiedener Typen
speichern. Clients auf Einrichtungen von im Wesentlichen jeder Größe, von
kleinformatigen Einrichtungen bis zu Supercomputern, können auf
die Speichermechanismen zugreifen, um unterschiedliche Objekte auf
dem Internet zu speichern und wieder zu holen. Die Clients können Java-
oder Nicht-Java-Anwendungen sein, da XML ein sprach-unabhängiges Speicherformat
bereitstellt. Die transienten oder dauerhaften Objekt-Repositories
können
für ein
Dateisystem in der verteilten Rechnerumgebung sorgen und können Zugriffsprüfungen und
andere Sicherheitsmechanismen wie hier beschrieben umfassen.
-
Dynamische
Konvertierung eines Java-Objektes in ein XML-Dokument
-
In
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zum Konvertieren und
Darstellen einer Objektklasseninstanz in ein XML-Dokument bereitstellen.
Um eine Darstellung einer Klasseninstanz an einen anderen Dienst
zu senden, kann das Objekt als ein XML-Dokument konvertiert und
dargestellt werden. In einer Ausführungsform kann ein Programm
beim Empfang eines XML-Dokumentes eine Klasseninstanz instantiieren,
die dem durch das Dokument dargestellten Objekt entspricht. In einer
Ausführungsform
können
die Objekte Java-Objekte sein, und das Programm kann ein Java-Programm
sein.
-
In
einer Ausführungsform
kann ein Zwischenformat zur Darstellung eines XML-Dokumentes verwendet
und dynamisch verarbeitet werden, um eine Klasseninstanz zu erzeugen,
die das XML-Dokument
repräsentiert.
Die Klasse kann einen Satz von Instanzvariablen und Methoden zum "Setzen und Holen" bzw. "Set- und Get"-Methoden zum Zugriff
auf die Instanzvariablen definieren. Ein entsprechendes XML-Dokument
kann als ein Satz von Tags definiert werden, mit einem Tag für jede Instanzvariable.
Wenn das Dokument analysiert wird, kann eine Repräsentation,
aus der ein Hash erzeugt werden kann, erstellt werden, wobei der Hash-Schlüssel den
Namen der Instanzvariablen enthalten kann und der Wert den Wert
der Instanzvariablen enthalten kann. Wenn eine komplexe Instanzvariable
mehrfach vorkommt, kann ein Aufzählungswert
in einer Hash-Tabelle gespeichert werden. In einer Ausführungsform
kann der Prozeß auf
nur eine Stufe von komplexen Typen für die Instanzvariablen beschränkt werden,
und die Elemente können
homogen sein.
-
In
einer Ausführungsform
kann eine geschützte
Instanzvariable zu der Klassendefinition hinzugefügt werden,
die den Namen der zugehörigen
Klasse enthält.
Die Darstellung als XML-Dokument
kann den Klassennamen als den Typ des Dokuments verwenden. Die Erstellung
des Klassennamens in das Dokument kann eine dynamische Instantiierung
der richtigen Klasseninstanz ermöglichen,
wenn das Objekt wiederhergestellt wird.
-
In
einer Ausführungsform
kann beim Empfang eines Dokumentes eine Erzeugermethode für eine Klasseninstanz
verwendet werden, um den Klassentyp zu extrahieren und das Dokument
zum Erzeugen der Zwischendarstellung als Hash-Tabelle zu analysieren
bzw. zu parsen. Die Erzeugermethode kann eine neue Klasseninstanz
instantiieren und kann die Setz-Methoden verwenden, um die Objektinstanz
aus den Werten in der Hash-Tabelle zu initialisieren. In einer Ausführungsform
kann dieser Vorgang für
jede Klasse durchgeführt
werden, die der obigen Klassendefinition entspricht, da der Klassentyp
definiert und die Hash-Tabelle generisch ist.
-
In
einer Ausführungsform
kann auch der umgekehrte Vorgang durchgeführt werden, bei dem eine Klasseninstanz
in die Zwischendarstellung als Hash-Tabelle verarbeitet werden kann
und eine Erzeugermethode verwendet werden kann, um ein XML-Dokument
aus der Darstellung als Hash-Tabelle zu erzeugen. Dieser Vorgang
kann auch generisch gemacht werden, so daß er für jedes XML-Dokument durchgeführt werden kann,
das der obigen Spezifikation entspricht.
-
Dieses
Verfahren soll nicht auf Java-Klassen eingeschränkt werden und kann auf andere
computer-basierte Objekte einschließlich Objektinstanzen von Klassen
aus anderen Programmiersprachen angewendet werden. Darüber hinaus
soll das Verfahren nicht auf XML-Repräsentationen von Objektinstanzen
eingeschränkt
werden; andere Darstellungsformate einschließlich anderer Datenrepräsentationssprachen
(wie HTML) können
anstelle von XML eingesetzt werden.
-
XML-basierte
Prozeßmigration
-
Die
verteilte Rechnerumgebung kann die Verteilung und Verwaltung von
verteilten Anwendungen ermöglichen.
Zum Beispiel kann die verteilte Rechnerumgebung mobile Clients umfassen,
die an Stationen angedockt werden können, die Monitore, Drucker,
Tastaturen und verschiedene andere Eingabe/Ausgabe-Einrichtungen
bereitstellen, die typischerweise auf mobilen Einrichtungen wie
PDAs, Mobiltelefonen, etc. nicht verfügbar sind. Diese mobilen Clients
können
eine oder mehrere Anwendungen ablaufen lassen und können von
einer Station zu einer anderen in der verteilten Rechnerumgebung
migrieren. Daher kann eine Ausführungsform
der verteilten Rechnerumgebung ein Verfahren zur Migration einer
Anwendung (eines Prozesses), die bzw. der gerade ausgeführt wird,
mit ihrem bzw. seinem gesamten Zustand von einem mobilen Client
an einem Knoten zu demselben mobilen Client oder einem anderen mobilen
Client an einem anderen Knoten in der verteilten Rechnerumgebung
zur Verfügung
stellen.
-
In
einer Ausführungsform
kann eine XML-Repräsentation
des Zustandes eines Prozesses, der auf einem Client oder einem Dienst
ausgeführt
wird, erzeugt werden. In einer Ausführungsform kann die XML-Repräsentation
des Zustandes des Prozesses einen Rechenzustand der Einrichtung
und/oder der virtuellen Maschine beinhalten, auf der der Prozeß ausgeführt wird,
wobei der Rechenzustand der Einrichtung und/oder der virtuellen
Maschine Information über
den Ausführungszustand
des Prozesses auf der Einrichtung und/oder der virtuellen Maschine
aufweist. Ein Prozeßzustand
kann umfassen, ist jedoch nicht beschränkt auf: Threads (Stränge), alle
von den Threads referenzierte Objekte, während der Ausführung des
Prozesses erzeugte transiente Variable, Objek te und ihre Daten,
etc. In einer Ausführungsform
können
auch Daten in XML dargestellt und mit dem Prozeßzustand gespeichert werden,
die eine oder mehrere Überlassungen
beschreiben, die durch den Prozeß von Spaces erhaltene Zugriffsbewilligungen
auf externe Dienste repräsentieren,
wobei der eine oder die mehreren externen Dienste bezüglich der
Einrichtung und/oder der virtuellen Maschine extern sind, auf der
der Prozeß ausgeführt wird. Überlassungen
(Leasing) werden genauer in dem Abschnitt über Überlassungen in diesem Dokument
beschrieben.
-
Unter
Verwendung von XML und des Nachrichtensystems, wie hier beschrieben,
kann eine XML-Repräsentation
des Zustandes eines Prozesses von Knoten zu Knoten innerhalb der
verteilten Rechnerumgebung bewegt werden, z. B. von Knoten zu Knoten
im Internet. Die XML-Repräsentation
des Zustandes eines Prozesses kann auch als ein XML-Objekt in einem
XML-basierten Speichermechanismus,
wie oben beschrieben, gespeichert und später von dem Speichermechanismus
zurückgeholt
werden, um die Ausführung
des Prozesses auf demselben Knoten oder einem anderen Knoten in
der verteilten Rechnerumgebung wieder aufzunehmen. In einer Ausführungsform
kann der hier beschriebene Kompilierungs-/Dekompilierungsvorgang von
XML-Objekten beim
Erzeugen (Kompilieren) einer XML-Repräsentation des Zustandes eines
Prozesses und beim Wiederherstellen des Zustandes des Prozesses
durch Dekompilierung der XML-Repräsentation
des Zustandes des Prozesses verwendet werden.
-
Mittels
dieses Mechanismus' kann
eine XML-Repräsentation
des Zustandes eines Prozesses in einem XML-basierten Speichermechanismus
wie einem Space von einem anfänglichen
Knoten gespeichert werden. Anschließend kann ein anderen Knoten
den gespeicherten Zustand des Prozesses lokalisieren, den Zustand des
Prozesses herunterladen und den Prozeß aus dem heruntergeladenen,
gespeicherten Zustand an der Stelle wieder aufnehmen, an der er
ausgeführt
wurde, als der Zustand gespeichert wurde. Da der Prozeßzustand
in einem XML-Format gespeichert ist, können die hier beschriebenen
Werkzeuge und Suchmöglichkeiten
zum Speichern, Lokalisieren und Zurückholen von XML-Objekten in
XML-basierten Speichermechanismen verwendet werden, um die Migration
des Prozesses zu ermöglichen.
Eine Annonce der gespeicherten XML-Repräsentation
des Zustandes des Prozesses kann veröffentlicht werden, um einem
Client, der die Prozeßausführung auf
demselben Knoten oder einem anderen Knoten wieder aufnimmt, das
Lokalisieren des gespeicherten Zustandes und den Zugriff darauf
zu ermöglichen.
-
Die
XML-Repräsentation
des Zustandes eines Prozesses kann in einem XML-basierten, dauerhaften Speichermechanismus
gespeichert werden und daher eine dauerhafte Momentaufnahme des
Prozesses bereitstellen. Diese kann als ein Verfahren zur Wiederaufnahme
der Prozeßausführung auf
einem Knoten nach der Unterbrechung des Prozesses auf einem Knoten,
zum Beispiel wegen des absichtlichen oder unbeabsichtigten Herunterfahrens
des Knotens, verwendet werden. Eine Annonce des gespeicherten Zustandes
des Prozesses kann veröffentlicht
werden, um Clients das Lokalisieren des gespeicherten Zustandes
in der verteilten Rechnerumgebung zu ermöglichen. In einer Ausführungsform
kann ein Autorisierungsnachweis wie eine digitale Unterschrift oder
ein digitaler Berechtigungsnachweise bei dem gespeicherten Zustand
beinhaltet sein, um ei nen unautorisierten Zugriff auf eine XML-Repräsentation
des Zustandes eines Prozesses zu verhindern, und für einen
Client, der einen Prozeß aus
dem gespeicherten Zustand wieder aufnehmen möchte, kann es erforderlich
sein, über
den passenden Autorisierungsnachweis für den Zugriff auf den gespeicherten
Zustand zu verfügen.
-
37 stellt die Prozeßmigration unter Verwendung
einer XML-Repräsentation
des Zustandes eines Prozesses gemäß einer Ausführungsform
dar. Der Prozeß A 1636a kann
auf dem Knoten 1630 ausgeführt werden. Der Prozeß A 1636a kann
ein Client oder ein Dienst sein. Zu einem bestimmten Zeitpunkt während der
Ausführung
von Prozeß A 1636a kann
der Zustand der Ausführung
von Prozeß A 1636a erfaßt und in
einem XML-gekapselten Zustand von Prozeß A 1638 gespeichert
werden. Die Ausführung
von Prozeß A 1636a auf
dem Knoten 1630 kann daraufhin angehalten werden. Später kann
der Knoten 1632 den XML-gekapselten Zustand von Prozeß A 1638
lokalisieren und ihn zur Wiederaufnahme von Prozeß A 1636b auf
dem Knoten 1632 verwenden. Zu der Wiederaufnahme von Prozeß A kann
gehören,
den gespeicherten Zustand 1638 zu verwenden, um die Ausführung von
Threads wieder aufzunehmen, transiente Variable neu zu berechnen, überlassene
Ressourcen neu aufzubauen und jede andere notwendige Funktion zur
Wiederaufnahme der Ausführung
wie in dem gespeicherten XML-Zustand des Prozesses 1638 aufgezeichnet,
durchzuführen.
-
Das
Folgende ist ein Beispiel der Verwendung der XML-basierten Prozeßmigration
in der verteilten Rechnerumgebung, und soll nicht als Einschränkung verstanden
werden. Eine mobile Clienteinrichtung kann mit dem Knoten 1630 verbunden
sein und den Prozeß A 1636a ausführen. Der
Benutzer der mobilen Clienteinrichtung kann die Ausführung von
Prozeß A 1636a auf
dem Knoten 1630 anhalten und die Ausführung zu einem späteren Zeitpunkt
auf einem anderen (oder demselben) Knoten wieder aufnehmen wollen.
In einer Ausführungsform
kann der Benutzer mit einer Rückfrage
abgefragt werden, um zu ermitteln, ob der Benutzer den Zustand von
Prozeß A 1636a abspeichern
und die Ausführung
später
wieder aufnehmen möchte.
Wenn der Benutzer zustimmend antwortet, kann der XML-gekapselte
Zustand des Prozesses erfaßt
und in dem dauerhaften Speicher 1634 gespeichert werden.
Später
kann der Benutzer die mobile Recheneinrichtung bei Knoten 1632 anschließen. In
einer Ausführungsform
kann dann der Benutzer den Prozeß 1636b ausführen und eine
Option Wiederaufnahme von gespeichertem Zustand" auswählen. Der Knoten 1632 kann
daraufhin nach dem XML-gekapselten Zustand von Prozeß A 1638 suchen
und ihn lokalisieren, ihn herunterladen und ihn zur Wiederaufnahme
von Prozeß 1636b verwenden.
Alternativ kann der Prozeß selbst
wissen, daß er
auf einem anderen Knoten "unterbrochen" wurde, und die Ausführung aus
dem gespeicherten Zustand ohne Benutzereingabe wieder aufnehmen.
-
Anwendungen
-
Es
existieren Technologien, die einem Benutzer den Zugriff auf Netzwerkdaten
von einer abgesetzten bzw. entfernten Stelle aus ermöglichen,
wobei sie die entfernten Daten dem Benutzer als lokale Daten erscheinen
fassen, vorausgesetzt der Benutzer hat Zugriff auf einen Browser.
Sol che Technologien stellen jedoch keine automatische Infrastruktur
zur Verfügung,
um Netzwerke nahe der Stelle einer Clienteinrichtung abfragen zu
können.
Ein Mechanismus zum Auffinden von Information über Netzwerke und Dienste einer
Clienteinrichtung kann wünschenswert
sein. Zum Beispiel kann ein solcher Mechanismus verwendet werden,
um Information über
Restaurants, Wetter, Straßen-
bzw. Landkarten, Verkehr, Filminformation, etc. innerhalb einer
bestimmten Entfernung (Radius) von der Clienteinrichtung zu lokalisieren
und die gewünschte
Information auf der Clienteinrichtung anzuzeigen. Ein Beispiel der
Verwendung dieses Mechanismus' kann
ein Mobiltelefon sein, das zum automatischen Lokalisieren von Diensten
in einer lokalen Umgebung verwendet werden kann, zum Beispiel in
einem Filmtheater zur Anzeige der Titel und zum Zeigen der Zeiten
der aktuellen Vorstellungen in dem Filmtheater oder in einem Restaurant
zum Ansehen von Auszügen
aus der Speisekarte und der Preise. In der hier beschriebenen verteilten
Rechnerumgebung kann ein solcher Mechanismus verwendet werden, um Spaces
ausfindig zu machen, die lokale Information und/oder Dienste nahe
bei der Clienteinrichtung enthalten. Der Mechanismus kann auch in
anderen verteilten Rechnerumgebungen angewendet werden, zum Beispiel in
dem Jini-System von Sun Microsystems, Inc.
-
In
einer Ausführungsform
kann eine mobile Clienteinrichtung eine Global-Positioning-System-(GPS)-Funktionalität und drahtlose
Verbindungstechnologie enthalten. Lokale verteilte Rechnernetzwerke können bereitgestellt
werden. Zum Beispiel kann eine Stadt eine stadtweite, verteilte
Rechnerumgebung bereitstellen. Ein anderes Beispiel kann ein Einkaufszentrum
mit einer lokalen verteilten Rechnerumgebung sein. Eine lokale verteilte
Rechnerumgebung kann einen Auffindungsmechanismus beinhalten, um
es Clienteinrichtungen zu ermöglichen,
mit der verteilten Rechnerumgebung in Verbindung zu treten und Dienste
und Daten in der lokalen Umgebung ausfindig zu machen. Zum Beispiel
können
eine oder mehrere Einrichtungen in der Umgebung drahtlose Verbindungstechnologie
enthalten, um es mobilen Clienteinrichtungen zu ermöglichen, mit
dem Netzwerk Verbindung aufzunehmen und auf den Auffindungsmechanismus über das
XML-Nachrichtensystem wie zuvor beschrieben zuzugreifen. Eine lokale
verteilte Rechnerumgebung kann einen oder mehrere Spaces mit Annoncen
für Dienste
und/oder Daten enthalten, die mobilen Clients verfügbar gemacht
werden sollen. Zum Beispiel kann eine stadtweite, verteilte Rechnerumgebung
Spaces enthalten, die Einheiten wie Einkaufszentren, Filmtheater,
lokale Nachrichten, lokales Wetter, Verkehr, etc. beinhalten. Ein
Space kann individuelle Annoncen von Diensten und/oder Daten beinhalten,
um auf Dienste der Einheit und auf Information über die Einheit zuzugreifen,
die der Space repräsentiert.
Der Auffindungsmechanismus kann eine GPS-Lokation oder -Lokationen
der lokalen verteilten Rechnerumgebung, durch Space-Dienste innerhalb
der Umgebung repräsentierte
Einheiten und/oder die verschiedenen in den Spaces in der Umgebung
angekündigten
Dienste beinhalten.
-
In
einer Ausführungsform
können
verdrahtete bzw. Leitungsverbindungen zu einem lokalen verteilten Rechnernetzwerk
zur Verfügung
stehen. In dieser Umgebung kann sich ein Benutzer mit einer mobilen
Clienteinrichtung mittels einer "Docking
Station" mit einer
drahtgebundenen Verbin dung direkt in das Netzwerk "einstöpseln". Beispiele von drahtgebundenen
Verbindungen umfassen, sind jedoch nicht beschränkt auf: Universal Serial Bus
(USB), FireWire und verdrilltes (twistedpair) Ethernet. In einer
Ausführungsform
kann eine Docking Station auch Eingabe-/Ausgabe-Möglichkeiten
wie eine Tastatur, Maus und Anzeige für die mobile Clienteinrichtung
bereitstellen. In dieser Ausführungsform
kann der Standort der mobilen Clienteinrichtung dem Such- oder Auffindungsmechanismus
von der Docking Station zur Verfügung
gestellt werden.
-
In
einer Ausführungsform
kann eine mobile Clienteinrichtung mit einem verteilten Rechnernetzwerk Verbindung
aufnehmen. Während
der Benutzer der mobilen Clienteinrichtung innerhalb der drahtlosen
Kommunikationsreichweite des verteilten Rechnernetzwerks navigiert,
kann die mobile Clienteinrichtung konstant oder in verschiedenen
Intervallen einen Ortsvektor als Eingabe an den lokalen Such- oder
Auffindungsmechanismus übergeben.
Die mobile Clienteinrichtung kann den Ortsvektor aus einem GPS-System
erhalten, das in den mobilen Client eingebaut oder ihm zugeordnet
ist. In einer Ausführungsform
kann der Client seine Ortsinformation (z. B. mittels Senden von
XML-Nachrichten) an einen Auffindungsmechanismus für lokale
Dienste wie einen der hier beschriebenen Lokalisierungsmechanismen
für Spaces
senden. Zum Beispiel kann der Client das Space-Auffindungsprotokoll
für Spaces
ablaufen lassen, die Dienste innerhalb einer bestimmten Reichweite
vom Aufenthaltsort des Client anbieten, oder der Client kann einen
Space-Nachschlagedienst instantiieren, um nach Spaces zu suchen,
die für
die Nachbarschaft des Client bereitgestellte Dienste ankündigen.
-
Während sich
die mobile Clienteinrichtung in eine spezifizierte Reichweite eines
Space innerhalb der verteilten Rechnerumgebung bewegt, können die
in dem Space gespeicherten Dienste und/oder Daten für die mobile
Clienteinrichtung verfügbar
gemacht werden. In Ausführungsformen,
bei denen die Clienteinrichtung regelmäßig ihren Aufenthaltsort an
einen Auffindungsmechanismus übergibt,
können
lokale Dienste und/oder Daten automatisch für den Benutzer des Clients
verfügbar
gemacht werden. In einer Ausführungsform
kann der Benutzer der mobilen Clienteinrichtung die spezifizierte
Reichweite eines Space festlegen bzw. ermitteln. Zum Beispiel kann
der Benutzer wählen,
alle Restaurants innerhalb einer Meile vom aktuellen Standort aus anzuzeigen.
Alternativ kann die Reichweite in der Konfiguration des lokalen
verteilten Rechnernetzwerkes angegeben werden. Zum Beispiel kann
ein stadtweites, verteiltes Rechnernetzwerk eingerichtet werden,
um seine Dienste allen Benutzern innerhalb von drei Meilen von den
Stadtgrenzen zur Verfügung
zu stellen. In einer Ausführungsform
können
visuelle Indikatoren, zum Beispiel Icons, die die verschiedenen
von dem Space angebotenen Dienste und/oder Daten repräsentieren,
auf der mobilen Clienteinrichtung angezeigt werden. Der Client kann
dann auf einen oder mehrere der angezeigten Dienste und/oder Daten
zugreifen. In einer Ausführungsform
kann Information von zwei und mehr Spaces gleichzeitig auf der mobilen
Clienteinrichtung angezeigt werden. In einer Ausführungsform
kann der Benutzer auswählen,
welche Dienste und/oder Daten ausfindig gemacht werden sollen. Zum
Beispiel kann ein Benutzer mit einer mobilen Clienteinrichtung in
einem Einkaufszentrum wählen,
alle Schuhgeschäfte
in dem Einkaufszentrum anzeigen zu lassen.
-
In
einer Ausführungsform
kann ausführbarer
Code und/oder bei der Ausführung
des Codes verwendete Daten in eine mobile Clienteinrichtung heruntergeladen
werden, um dem Benutzer das Ausführen
einer von einem Dienst in dem Space bereitgestellten Anwendung zu
ermöglichen.
Zum Beispiel können
Kinogänger mit
mobilen Clienteinrichtungen interaktive Filmbesprechungen von Diensten
in einem Space für
das Kino herunterladen, und können
dadurch eine Echtzeit-Rückmeldung über den
Film durchführen,
den sie sich ansehen. In einer Ausführungsform kann ein Kompilierungs-/Dekompilierungsmechanismus
für XML-Objekte
wie hier an anderer Stelle beschrieben verwendet werden, um den
Code und/oder die Daten zum Erzeugen von XML-Repräsentationen
des Codes und/oder der Daten zu kompilieren und die XML-Repräsentationen
zum Wiederherstellen des Codes und/oder der Daten auf der mobilen
Clienteinrichtung zu dekompilieren. In einer Ausführungsform
kann eine ausführbare
Version eines Prozesses zuvor auf der mobilen Clienteinrichtung
vorhanden sein, und Daten für
den Prozeß können in
die mobile Clienteinrichtung heruntergeladen werden. Zum Beispiel
können
Daten zum Betrachten mit einem Betrachterprogramm in die mobile
Clienteinrichtung heruntergeladen werden. In einer Ausführungsform
kann eine ausführbare
Version eines Prozesses einschließlich des Codes und der Daten
zur Ausführung
des Prozesses zur Ausführung
in die mobile Clienteinrichtung heruntergeladen werden. In einer
Ausführungsform
kann der Dienst die Anwendung in der Ferne für die mobile Clienteinrichtung
ablaufen, und der Dienst und der Client können sich gegenseitig XML-Nachrichten
einschließlich
Daten und optional die Daten beschreibende XML-Schemata übergeben.
In einer Ausführungsform kann
ein Teil des Codes auf dem Dienst und ein Teil auf dem Client ausgeführt werden.
Zum Beispiel kann der Dienst Code zum Durchführen von Operationen auf einem
Satz von Daten wie numerische Berechnungen ausführen. Die mobile Clienteinrichtung
kann Code ausführen,
der Teile der von dem Dienst in XML-Nachrichten an den Client übergebenen
Daten anzeigen kann und es dem Benutzer der mobilen Clienteinrichtung
ermöglichen
kann, Daten einzugeben und/oder auszuwählen und die Daten an den Dienst
zum Durchführen
einer oder mehrerer Operationen auf den Daten zu senden.
-
In
einer Ausführungsform
kann eine mobile Clienteinrichtung gleichzeitig mit zwei oder mehr
Diensten in dem verteilten Rechnernetzwerk verbunden sein. Die Dienste
können
unabhängig
oder in Verbindung zur Durchführung
einer Reihe von Aufgaben verwendet werden. Zum Beispiel kann ein
Dienst von einer entfernten Clienteinrichtung verwendet werden,
um Operationen auf einem Satz von Daten zu lokalisieren und/oder durchzuführen, und
ein zweiter Dienst kann zum Drucken des Satzes von Daten verwendet
werden.
-
38 stellt eine mobile Clienteinrichtung beim Zugriff
auf Spaces in einem lokalen verteilten Rechnernetzwerk gemäß einer
Ausführungsform
dar. Ein Benutzer der GPS-fähigen
mobilen Rechnereinrichtung 1700 kann sich in die Nähe einer
lokalen verteilten Rechnerumgebung bewegen. Die mobile Clienteinrichtung 1700 kann
ihren von dem GPS 1702 angegebenen Standort an einen oder
mehrere Auffindungsmechanismen 1706 in dem lokalen verteilten
Rechnernetzwerk übergeben.
Der Auffindungsmechanismus 1706 kann die bereitgestellte
GPS-Ortsangabe der mobi len Clienteinrichtung und zuvor bestimmte
Ortsangaben von Spaces innerhalb der Umgebung verwenden, um festzustellen,
wenn der Benutzer sich innerhalb einer spezifizierten Reichweite
eines oder mehrerer Spaces oder einer von einem oder mehreren Spaces
innerhalb der Umgebung bedienten Nachbarschaft bewegt. Zum Beispiel
kann der Auffindungsmechanismus 1706 feststellen, daß die mobile
Clienteinrichtung 1700 sich innerhalb der Reichweite von
Space 1704 bewegt hat. Der Auffindungsmechanismus 1706 kann
daraufhin eine oder mehrere Annoncen 1710 aus dem Space 1704 der
mobilen Clienteinrichtung 1700 bereitstellen. Alternativ
kann der Auffindungsmechanismus 1706 einen Universal Resource Identifier
(URI) für
den Space 1704 oder für
eine oder mehrere Annoncen in dem Space 1704 der mobilen
Clienteinrichtung 1700 bereitstellen. Icons, welche die
verschiedenen durch die Dienstannoncen 1708 angekündigten
Dienste und/oder durch die Inhaltsannoncen 1710 repräsentierten
Daten darstellen, können
dann auf der mobilen Clienteinrichtung 1700 angezeigt werden.
Der Benutzer kann daraufhin eine oder mehrere der angekündigten
Dienste und/oder Daten zur Ausführung
und/oder Anzeige auf der mobilen Clienteinrichtung auswählen. Die
mobile Rechnereinrichtung 1700 kann eine drahtlose Verbindung
mit der Einrichtung, die den Dienst anbietet, aufbauen und mit dem
Dienst kommunizieren, um den Dienst unter Verwendung des XML-basierten
Nachrichtensystems, wie hier zuvor beschrieben, auszuführen. Alternativ
kann der Benutzer der mobilen Rechnereinrichtung 1700 die
Einrichtung an eine Docking Station anschließen. Der Standort der Docking Station
kann von dem Benutzer mittels eines Such- oder Auffindungsmechanismus' 1706 und
mittels Spaces, die Annoncen für
die Docking Stationen zum Auffinden des Ortes und der Verfügbarkeit
von Docking Stationen innerhalb einer angegebenen Reichweite des
Benutzers beinhalten, ausfindig gemacht worden sein.
-
Der
Auffindungsmechanismus 1706 kann auch erkennen, wenn sich
die mobile Clienteinrichtung 1700 in eine angegebene Reichweite
des Space 1714 bewegt. Die verschiedenen Dienstannoncen 1718 und
Inhaltsannoncen 1720 können
daraufhin dem Benutzer der mobilen Clienteinrichtung 1700 verfügbar gemacht werden.
Wenn sich die mobile Clienteinrichtung 1700 aus der angegebenen
Reichweite eines der Spaces herausbewegt, können die von diesem Space angebotenen
Annoncen aus der Anzeige der mobilen Clienteinrichtung 1700 entfernt
werden.
-
In
einer Ausführungsform
können
die Annoncen in einem Space Standortinformation für die Dienste und
Daten beinhalten, die sie zur Verfügung stellen. Somit kann der
Auffindungsmechanismus 1706 feststellen, wenn sich die
mobile Clienteinrichtung 1700 innerhalb einer angegebenen
Reichweite eines bestimmten in dem Space 1718 angekündigten
Dienstes bewegt, und die Dienstannonce basierend auf dem Aufenthaltsort der
mobilen Clienteinrichtung 1700 bereitstellen (oder entfernen).
-
Rechnereinrichtungen
werden kleiner, während
sie gleichzeitig Leistung und Funktionalität hinzugewinnen. Speichereinrichtungen,
CPUs, RAM, I/O ASICS, Stromversorgungen, etc. wurden in der Größe soweit reduziert,
daß kleine,
mobile Clienteinrichtungen viel von der Funktionalität eines
Personalcomputers voller Größe beinhalten
können.
Jedoch sind einige Komponenten eines Computersystems wegen des Humanfaktors
und anderer Faktoren nicht leicht zu verkleinern. Diese Komponenten
umfassen, sind jedoch nicht beschränkt auf: Tastaturen, Monitore,
Scanner und Drucker. Die Grenzen bzw. Schranken der Größenreduzierung
einiger Komponenten können
verhindern, daß mobile
Clienteinrichtungen wirklich die Rolle von Personalcomputern annehmen.
-
In
einer Ausführungsform
können
Docking Stationen bereitgestellt werden, die es Benutzern mit mobilen
Clienteinrichtungen ermöglichen,
sich an Komponenten anzuschließen
und diese zu verwenden, die auf der mobilen Clienteinrichtungen
wegen des Humanfaktors oder anderer Faktoren nicht verfügbar sind.
Zum Beispiel können
Docking Stationen an öffentlichen
Plätzen
wie Flughäfen
und Bibliotheken bereitgestellt werden. Die Docking Stationen können Monitore,
Tastaturen, Drucker oder andere Einrichtungen für Benutzer mit mobilen Clienteinrichtungen
bereitstellen. In einer Ausführungsform
können
die Docking Stationen ohne die Unterstützung einer realen Rechnereinrichtung
wie einer von einem Benutzer angeschlossenen mobilen Clienteinrichtungen
nicht vollständig
funktionieren. Die Docking Station kann Dienste wie verschiedene
Eingabe/Ausgabe-Funktionen
dem Client unter Verwendung der Rechnerleistung der mobilen Clienteinrichtung
zur Verfügung
stellen.
-
Eine
Docking Station kann einer mobilen Clienteinrichtung eine oder mehrere
Verbindungsoptionen bereitstellen. Die Verbindungsoptionen können drahtlose
Verbindungen und drahtgebundene Verbindungen umfassen. Beispiele
von drahtlosen Verbindungen umfassen, sind jedoch nicht beschränkt auf:
Infrarot wie IrDA und drahtlose Netzwerkverbindungen ähnlich zu
denjenigen, die von einer Netzwerkschnittstellenkarte (Network Interface
Card, NIC) in einem Notebook-Computer bereitgestellt werden. Beispiele
von drahtgebundenen Verbindungen umfassen, sind jedoch nicht beschränkt auf:
USB, FireWire und verdrilltes Ethernet.
-
Eine
mobile Clienteinrichtung kann den Standort von Docking Stationen
mittels eines Verfahrens ausfindig machen, das im Wesentlichen dem
oben für
mobile Clienteinrichtungen beschriebenen ähnlich ist. Der Standort einer
oder mehrerer Docking Stationen in einem lokalen, verteilten Rechnernetzwerk
kann mittels eines Auffindungsmechanismus' zum Auffinden von Spaces mit Annoncen
für die
Docking Stationen ausfindig gemacht werden. Die mobile Clienteinrichtung
kann einen Aufenthaltsort an den Auffindungsmechanismus übergeben.
In einer Ausführungsform
können
der Auffindungsmechanismus oder ein Suchmechanismus den Standort
einer oder mehrerer Docking Stationen nächst dem Aufenthaltsort der
mobilen Clienteinrichtung zurückgeben.
Alternativ kann der Auffindungsmechanismus oder Suchmechanismus
einen URI des Space zurückgeben,
der die Annoncen für
die Docking Stationen enthält,
und die mobile Clienteinrichtung kann dann mit dem Space in Verbindung
treten, um den Standort der einen oder mehreren Docking Stationen
nahe der Einrichtung zur Verfügung
zu stellen. In einer Ausführungsform
kann die mobile Clienteinrichtung dem Such- oder Auffindungsmechanismus
Information übergeben,
um Anforderungen wie Monitorauflösung,
Bildschirmgröße, Grafikfähigkeiten,
verfügbare
Einrichtungen wie Drucker und Scanner, etc. zu spezifizieren. In
einer Ausführungsform
kann Information über
die eine oder mehreren Docking Stationen einschließlich der
Verfügbarkeit
(verwendet ein anderer Benutzer gerade die Docking Station), der
Komponenten und der Leistungsmerkmale der verschiedenen Docking
Stationen an den Benutzer auf der mobilen Clienteinrichtung geliefert werden.
-
Wenn
ein Benutzer an eine Docking Station herankommt, kann ein Protokoll
zur Inanspruchnahme eingeleitet werden. Wenn die Docking Station
die Inanspruchnahme akzeptiert, können sichere Eingabe- und Ausgabeverbindungen
zwischen der mobilen Clienteinrichtung und der Docking Station aufgebaut
werden. Alternativ kann der Benutzer die Docking Station aus einer
oder mehreren mittels des Such- oder Auffindungsmechanismus' ausfindig gemachten
Docking Stationen auswählen,
die auf der mobilen Clienteinrichtung angezeigt werden. Wenn der
Benutzer die Docking Station auswählt, kann das Protokoll zur
Inanspruchnahme eingeleitet werden, um dem Benutzer für die Dauer
der Inanspruchnahme eine sichere, exklusive Verbindung zu der Docking
Station zu geben. Ein Verfahren zur Freigabe der Docking Station
kann auch vorgesehen werden, um dem Benutzer die Beendigung der
Sitzung an der Docking Station und die Freigabe der Docking Station
zur Verwendung durch andere Benutzer zu ermöglichen. In einer Ausführungsform
kann das Protokoll zur Inanspruchnahme eine Überlassung des Dienstes der
Docking Station, wie hier zuvor beschrieben, sein.
-
39a stellte einen Benutzer einer mobilen Clienteinrichtung
dar, der den Standort von Docking Stationen gemäß einer Ausführungsform
ausfindig macht. Die mobile Clienteinrichtung 1750 kann
mit dem Auffindungsmechanismus 1756 Verbindung aufnehmen.
Die mobile Clienteinrichtung 1750 kann eine mittels des GPS 1772 erhaltene
Ortsangabe dem Auffindungsmechanismus 1756 übergeben.
Die mobile Clienteinrichtung 1750 kann dem Auffindungsmechanismus 1756 auch
Anforderungen an Docking Stationen übergeben. Der Auffindungsmechanismus 1756 kann
einen oder mehrere Spaces 1754 nach Annoncen für Docking
Stationen 1758 durchsuchen, die die Anforderungen der mobilen
Clienteinrichtung 1750 erfüllen. In einer Ausführungsform
kann ein Such- oder Auffindungsmechanismus eine oder mehrere Docking
Stationen innerhalb einer angegebenen Reichweite der mobilen Clienteinrichtung 1750 durch
Vergleich der in den Annoncen 1758 gespeicherten Ortsinformation
mit der gelieferten Ortsangabe der mobilen Clienteinrichtung 1750 lokalisieren. Der
Auffindungsmechanismus 1756 kann dann den Standort von
einer oder mehreren Docking Stationen innerhalb der angegebenen
Reichweite der mobilen Clienteinrichtung 1750 bereitstellen.
Alternativ kann der Auffindungsmechanismus 1756 eine der
mobilen Clienteinrichtung 1750 nächstgelegene Docking Station
lokalisieren und die Ortsangabe an die mobile Clienteinrichtung 1750 übergeben.
-
39b stellt eine mobile Clienteinrichtung 1750 dar,
die gemäß einer
Ausführungsform
mit einer Docking Station 1760 in Verbindung tritt. In
einer Ausführungsform
kann der Benutzer die mobile Clienteinrichtung 1750 in
die drahtlose Reichweite der Docking Station 1760 bewegen
und eine drahtlose Verbindung zu der Docking Station 1760 herstellen.
In einer anderen Ausführungsform
kann der Benutzer eine drahtgebundene Verbindung zu der Docking
Station 1760 durch Verbinden eines oder mehrerer Kabel
zwischen der Docking Station 1760 und der mobilen Clienteinrichtung 1750 aufbauen.
In einer Ausführungsform
kann der Benutzer der mobilen Clienteinrichtung 1750 eine
Inanspruchnahme der Docking Station 1760 etablieren. Die
Inanspruchnahme kann sichere, exklusive Rechte an der Docking Station
für die
Dauer der Verbindung etablieren. In einer Ausführungsform kann der Mechanismus
zur Inanspruchnahme ein Überlassungsmechanismus
für eine
Ressource (die Docking Station) sein, wie vorstehend beschrieben.
In einer Ausführungsform
kann einem Benutzer die Verwendung der Docking Station in Rechnung
gestellt werden. Zum Beispiel kann der Benutzer eine Kreditkartennummer
als Teil des Vorgangs der Inanspruchnahme einer Docking Station übergeben.
Siehe die Beschreibung der Rechnungsgatter in dem Abschnitt über Nachrichtengatter.
Sobald die Verbindung besteht, kann der Benutzer die verschiedenen
von der Docking Station bereitgestellten Einrichtungen bzw. Facilities
wie Tastatur, Monitor, Drucker, etc. benutzen. Die Docking Station 1760 kann
auch eine Verbindung zu einem lokalen, verteilten Rechnernetzwerk
beinhalten und dadurch dem Benutzer der mit der Docking Station 1760 verbundenen
mobilen Clienteinrichtung 1750 mit Auffindungsdiensten
zum Lokalisieren von Dienst- und Inhaltsannoncen auf anderen Einrichtungen
innerhalb der Netzwerkes versehen, wodurch dem Benutzer das Lokalisieren
und Verwenden verschiedener Dienste und Inhalte in der verteilten
Rechnerumgebung wie zuvor hier beschrieben ermöglicht wird.
-
Wenn
er fertig ist, kann der Benutzer die mobile Clienteinrichtung 1750 von
der Docking Station 1760 trennen. In einer Ausführungsform
kann ein Mechanismus zur Freigabe einer Docking Station automatisch
eingeleitet werden, wenn die mobile Clienteinrichtung 1750 von
der Docking Station 1760 getrennt wird. Der Freigabemechanismus
kann jedwede von dem Benutzer der mobilen Clienteinrichtung 1750 etablierte
Inanspruchnahme der Docking Station 1760 löschen. In
einer Ausführungsform
kann der Freigabemechanismus den Auffindungsmechanismus 1756 und/oder
die Annonce 1758 der Docking Station benachrichtigen, daß die Docking
Station verfügbar
ist.
-
In
einer Ausführungsform
kann ein Benutzer eine mobile Clienteinrichtung an eine Docking
Station anschließen,
ohne den Auffindungsmechanismus zu verwenden. Zum Beispiel kann
ein Benutzer in einem Flughafen eine Docking Station ausfindig machen
und eine mobile Clienteinrichtung an sie anschließen. Ein
anderes Beispiel kann eine Bibliothek sein, die einen Raum für Docking
Stationen mit einer Mehrzahl von Docking Stationen zur Benutzung
bereitstellt, in dem Benutzer jede der Docking Stationen benutzen
können,
soweit sie verfügbar
sind.
-
Kleinformatige und/oder
eingebettete Einrichtungen
-
Einfache
eingebettete oder kleinformatige Einrichtungen können einen begrenzten Speicherumfang zum
Speichern und Ausführen
von Programmanweisungen haben. Eine einfache eingebettete Einrichtung muß möglicherweise
einen beschränkten
Satz von Kontroll- bzw. Steuereingaben zum Initiieren der Funktionalität der Einrichtung
und Ausgaben zum Melden des Zustandes der Einrichtung verstehen.
Ein Beispiel einer einfachen, eingebetteten Einrichtung ist ein "intelligenter" Schalter (wie ein
Lichtschalter) mit eingebetteten Schaltungen zum Steuern des Schalters
und somit der durch den Schalter gesteuerten Einrichtung. Der intelligente
Schalter muß möglicherweise
nur zwei Steueranforderungen (Ändern
des Zustandes der Einrichtung, Anfordern des Zustandes der Einrichtung)
verstehen und eine Zustandsnachricht (den Zustand der Einrichtung)
senden. Ein intelligenter Schalter kann die mit ihm verbundene Einrichtung
durch das Empfangen seiner Steueranforderungen von einem oder mehreren
Steuerungssystemen und das Melden von Zustandsnachrichten an ein
oder mehrere Steuerungssysteme verwalten.
-
Nach
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Rahmen (Protokoll) zum
Einbeziehen kleiner Einrichtungen bereitstellen, die nicht über die
Ressourcenauslegung (wie Speicher) verfügen, die zum Implementieren
des vollständigen
Protokolls der verteilten Rechnerumgebung nötig ist. Nach einer Ausführungsform
kann ein Agent als eine Brücke
zwischen dem Protokoll, zu dem kleine Einrichtungen fähig sind,
und dem vollständigen
Protokoll vorgesehen werden. Der Agent kann das vollständige Auffindungsprotokoll
für die
kleine Einrichtung durchführen,
so daß die
Einrichtung das vollständige
Auffindungsprotokoll und die vollständige Aktivierung von Diensten
nicht zu implementieren braucht. Nach einer Ausführungsform muß die kleine
Einrichtung möglicherweise
nur Dienst-spezifische Nachrichten senden. Nach einer Ausführungsform
können
diese Nachrichten auf der kleinen Einrichtung vorgefertigt sein,
so daß die
kleine Einrichtung möglicherweise
nur Nachrichten an den Agenten zu senden braucht, die Teil der Dienstaktivierung
sind. Der Agent kann die Dienstaktivierung mittels des vollständigen Protokolls
zu dem Dienst durchführen
und eintreffende Nachrichten von der Einrichtung an den Dienst weiterleiten
und/oder kann Antworten von dem Dienst an den Client weiterleiten.
Somit kann der Agent als ein Dienstvermittler für den kleinen Client fungieren.
-
Nach
einer Ausführungsform
der verteilten Rechnerumgebung kann eine eingebettete Einrichtung
darauf eingerichtet werden, einen spezifischen Satz von Steuerungsanforderungen
in der Form von XML-Nachrichten zu empfangen und einen spezifischen
Satz von XML-Nachrichten zum Erstellen von Anforderungen, eines
Zustandsberichtes, etc. zu senden. Nach einer Ausführungsform
kann ein Steuerungssystem darauf eingerichtet werden, eine Vielzahl
von Einrichtungen durch das Senden von für jede von ihm gesteuerte Einrichtung
oder Kategorie von Einrichtungen spezifische XML-Anforderungsnachrichten
und durch das Empfangen von XML-Nachrichten von den Einrichtungen
zu verwalten. Nach einer Ausführungsform
können
ein oder mehrere XML-Schemata verwendet werden, um den spezifischen
Satz von XML-Nachrichten einer eingebetteten Einrichtung zu definieren;
das Schema kann von der eingebetteten Einrichtung und/oder dem Steuerungssystem
beim Senden und Empfangen von XML-Nachrichten verwendet werden.
-
Eine
eingebettete Einrichtung kann eine "dünne" Implementierung
des XML-Nachrichtensystems
wie zuvor hier beschrieben beinhalten, die den spezifischen Satz
von Nachrichten zum Steuern und Überwachen der
einfachen eingebetteten Einrichtung unterstützt. Die Implementierung des
XML-Nachrichtensystems kann auf die Verwendung mit kleinformatigen,
einfachen eingebetteten Einrichtungen zugeschnitten sein, und kann dadurch
in den begrenzten Speicher der kleinformatigen Einrichtungen passen.
Nach einer Ausführungsform kann
das XML-Nachrichtensystem
in einem kleinen Format mit einer für kleinformatige, eingebettete
Einrichtungen ausgerichteten virtuellen Maschine (z. B. KVM) implementiert
sein. Ein Netzwerkstack (zur Unter stützung des Transportprotokolls
für die
Kommunikation mit einem oder mehreren Steuerungssystemen) kann der virtuellen
Maschine zugeordnet sein, und die Schicht zum Senden von XML-Nachrichten kann "oben auf" dem Netzwerkstack "sitzen". Man beachte, daß diese
Implementierung des Nachrichtensystems auch in anderen Einrichtungen
als kleinformatigen oder eingebetteten Einrichtungen verwendet werden
kann.
-
Nach
einer Ausführungsform
können
statische oder vorab erstellte Nachrichten für Anforderungen von den Steuerungssystemen
an die eingebetteten Einrichtungen verwendet werden. Die statischen
Nachrichten können
in den eingebetteten Einrichtungen vorab kompiliert und gespeichert
sein. Eine eintreffende Nachricht kann mit den gespeicherten statischen
Nachrichten verglichen werden, um eine Übereinstimmung für die Nachricht
zu finden und somit die durch die Nachricht angeforderte Funktion
durchzuführen,
wodurch der Codebedarf zum Analysieren bzw. Parsen von eintreffenden
Nachrichten reduziert oder eliminiert wird. Abgehende Nachrichten
können
direkt aus den gespeicherten statischen Nachrichten gelesen werden,
wodurch der Bedarf für
dynamisches Kompilieren abgehender Nachrichten reduziert oder eliminiert
wird. Somit können
statische Nachrichten zur Reduktion des Codeumfangs der Nachrichtenschicht
in eingebetteten Systemen verwendet werden. Zum Beispiel können statische
Java-Objekte (Java-Opcodes) für
Anforderungs- und
Zustandsnachrichten verwendet werden.
-
40a stellt eine Ausführungsform von eingebetteten
Einrichtungen 1804a und 1804b dar, die durch ein
Steuerungssystem 1800 gemäß einer Ausführungsform
gesteuert werden. Das Steuerungssystem 1800 kann mit den
Einrichtungen 1804a und 1804b, die es steuert,
auf vielfältige
Weise über
ein Netzwerk verbunden sein. Das Netzwerk 1810 kann drahtgebunden
(Ethernet, Koaxialkabel, verdrillte Kabel, Stromnetz, etc.) und/oder
drahtlos (IrDA, Mikrowellen, etc.) sein. Nach einer Ausführungsform
können
die eingebetteten Einrichtungen 1804a und 1804b eine
dünne Implementierung
des XML-Nachrichtensystems zur Kommunikation mit dem Steuerungssystem 1800 über das
Netzwerk 1810 beinhalten. Das Steuerungssystem 1800 kann über eine
Implementierung des XML-Nachrichtensystems zum Senden von Anforderungen
an und Empfang von Antworten von den eingebetteten Einrichtungen 1804a und 1804b verfügen. Nach
einer Ausführungsform kann
das Steuerungssystem 1800 Software und Hardware beinhalten,
die dafür
eingerichtet ist, eine Schnittstelle darzustellen, um einem Benutzer
das Anzeigen des Zustandes und die Steuerung der eingebetteten Einrichtungen 1804a und 1804b aus
der Ferne zu ermöglichen.
Nach einer Ausführungsform
kann das Steuerungssystem 1800 Software und/oder Hardware
zur automatischen Steuerung der eingebetteten Einrichtungen 1804a und 1804b beinhalten.
-
Nach
einer Ausführungsform
können
die eingebetteten Einrichtungen 1804a und 1804b Teil
einer anderen Umgebung sein. Die Einrichtungen unterstützen das
von der verteilten Rechnerumgebung implementierte Modell zur Nachrichtenübergabe
möglicherweise
nicht. Zum Beispiel können
die Einrichtungen Knoten in einem vernetzten Automatisierungs- und
Steuerungssystem wie einem LonWorks-Netzwerk sein. Das Steuerungssystem 1800 kann
eine Steuerungssystem-Hardware und/oder -Software zur Steuerung
der Einrichtungen in der anderen Umgebung beinhalten. Das Steuerungssystem 1800 kann
als eine Brücke
zwischen der verteilten Rechnerumgebung und der anderen Umgebung
dienen. Die verteilte Rechnerumgebung kann auch ein Verfahren oder
(mehrere) Verfahren bereitstellen, um vorhandene Auffindungsprotokolle
für Einrichtungen zum
Auffinden von Einrichtungen für
einen Zugriff aus der verteilten Netzwerkumgebung zu umhüllen. Protokolle
zur Brückenbildung
und zum Umhüllen
sind in dem Abschnitt zur Überbrückung weiter
beschrieben.
-
Das
Steuerungssystem 1800 kann entfernt oder lokal an ein oder
mehrere andere Systeme in der verteilten Rechnerumgebung angeschlossen
sein. 40a zeigt das Steuerungssystem 1800,
das über
das Internet 1802 an den Client 1806 angeschlossen
ist. Der Client 1806 kann indirekt den Zustand der eingebetteten Einrichtungen 1804a und 1804b anfordern
und Steuerungsanforderungen an die eingebetteten Einrichtungen 1804a und 1804b senden.
Somit kann das Steuerungssystem 1800 als ein Proxy oder
eine Brücke
für die
eingebetteten Einrichtungen 1804a und 1804b dienen.
Siehe den Abschnitt zur Überbrückung. Um
eine differenzierte Kommunikation zwischen dem Client 1806 und
dem Steuerungssystem 1800 zu ermöglichen, können der Client und das Steuerungssystem
andere Implementierungen des XML-Nachrichtensystems als die dünne Implementierung
auf den eingebetteten Einrichtungen 1804a und 1804b haben.
Nach einer Ausführungsform kann
der Client 1806 Software und Hardware beinhalten, die dafür eingerichtet
ist, eine Schnittstelle darzustellen, um einem Benutzer des Client 1806 das
Anzeigen des Zustandes der eingebetteten Einrichtungen 1804a und 1804b und
die Steuerung der eingebetteten Einrichtungen 1804a und 1804b aus
der Ferne zu ermöglichen.
Nach einer Ausführungsform
muß der
Client 1806 dem Steuerungssystem 1800 den richtigen
Autorisierungsnachweis vorlegen, um dem Client 1806 einen
Zugriff auf die eingebetteten Einrichtungen 1804a und 1804b zu
ermöglichen.
Nach einer Ausführungsform
kann dem Client 1806 der Zugriff auf verschiedenen Stufen
gewährt
werden. Zum Beispiel kann der Client 1806 nur in der Lage
sein, den Zustand der eingebetteten Einrichtungen 1804a und 1804b anzusehen,
jedoch ist ihm die Steuerung der Einrichtungen aus der Ferne möglicherweise
nicht erlaubt. Nach einer Ausführungsform
kann das Steuerungssystem 1800 ein Dienst sein, kann eine
in der verteilten Rechnerumgebung veröffentlichte Dienstannonce haben,
und somit kann darauf durch einen Client 1806 mittels der
Client-Dienst-Verfahren wie zuvor in diesem Dokument beschrieben
zugegriffen werden. Nach einer Ausführungsform kann der Client 1806 in
der Lage sein, den Zustand des Steuerungssystems 1800 zu
betrachten und das Steuerungssystem 1800 aus der Ferne
zu steuern.
-
40b stellt das Client-Steuerungssystem 1808 dar,
das gemäß einer
Ausführungsform über das
Internet 1802 mit den eingebetteten Einrichtungen 1804c und 1804d verbunden
ist. Nach einer Ausführungsform können die
eingebetteten Einrichtungen 1804c und 1804d eine
dünne Implementierung
des XML-Nachrichtensystems zur Kommunikation mit dem Client-Steuerungssystem 1808 über das
Internet 1802 beinhalten. Das Client-Steuerungssystem 1808 kann
eine Implementierung des XML-Nachrichtensystems zum Senden von Anforderungen
an die und zum Empfang von Antworten von den eingebetteten Einrichtungen 1804c und 1804d beinhalten.
Nach einer Ausführungsform
kann das Client-Steuerungssystem 1808 Software und Hardware
beinhalten, die dafür eingerichtet
ist, eine Schnittstelle darzustellen, um einem Benutzer das Anzeigen des
Zustandes der eingebetteten Einrichtungen 1804c und 1804d und
die Steuerung der eingebetteten Einrichtungen 1804c und 1804d aus
der Ferne zu ermöglichen.
Nach einer Ausführungsform
kann das Client-Steuerungssystem 1808 Software
und/oder Hardware zur automatischen Steuerung der eingebetteten Einrichtungen 1804c und 1804d beinhalten,
-
Ein
Unterschied zwischen 40a und 40b besteht darin, daß in der in 40b dargestellten Ausführungsform auf die eingebetteten
Einrichtungen 1804c und 1804d von einem oder mehreren
Clients in der verteilten Rechnerumgebung zugegriffen werden kann,
ohne einen Proxy (z. B. ein Steuerungssystem) zu benötigen. Die
eingebetteten Einrichtungen 1804c und 1804d können Dienste
zum Zugriff auf die Funktionalität
der Einrichtungen umfassen, können
Dienstannoncen in der verteilten Rechnerumgebung veröffentlicht haben
und auf sie kann somit mittels des Client-Dienst-Verfahrens, wie
zuvor in diesem Dokument beschrieben zugegriffen werden.
-
Die
verteilte Rechnerumgebung kann einen Mechanismus für bezüglich ihrer
Ressourcen beschränkte Clients
zum Holen von per Universal Resource Identifier (URI) adressierten
Ressourcen umfassen. Zum Beispiel kann ein Client, der nur zum Senden
und Empfangen von Nachrichten über
eine IrDA-Verbindung in der Lage ist, nicht in der Lage sein, eine
URI-Verbindung zum Abholen von Ergebnissen aus einem Ergebnis-Space
aufzubauen. Nach einer Ausführungsform
kann ein Dienst als eine Brücke
zwischen dem Client und der URI-Ressource bereitgestellt werden.
Der Brücken-Dienst
kann mit dem Client mittels XML-Nachrichten interagieren, um Eingabeparameter
aufzunehmen. Das Folgende ist als ein Beispiel einer Syntax von XML-Eingabenachrichten
aufgenommen und soll in keiner Weise einschränkend sein:
-
Daraufhin
kann der Brücken-Dienst
außerhalb
der verteilten Rechnerumgebung eine URI-Verbindung aufbauen und die Ressource
abholen. Die Ressource kann dann von dem Brücken-Dienst als eine Nutzlast in eine oder
mehrere XML-Nachrichten eingekapselt und an den Client gesendet
werden.
-
Die
folgende Darstellung einer möglichen
Verwendung von eingebetteten Einrichtungen mit dünnen Implementierungen des
XML-Nachrichtensystems ist für
Beispielzwecke aufgenommen und soll nicht einschränkend sein.
Ein Gebäude
kann eine Mehrzahl von elektronischen Einrichtungen beinhalten,
die Energie verbrauchen (z. B. Lichter, Klimaanlagen, Büroausstattung),
und kann somit ein System zum Aufrechterhalten eines optimalen Niveaus
des Energieverbrauchs benötigen.
Die Mehrzahl von Einrichtungen kann jeweils eine eingebettete Einrichtung
zur Steuerung der elektronischen Einrichtungen beinhalten. Die eingebetteten
Einrichtungen können
dünne Implementierung
des XML-Nachrichtensystems enthalten. Ein oder mehrere Steuerungssysteme
können
mit den Einrichtungen in einem Netzwerk, zum Beispiel einem Gebäude-LAN
oder sogar dem Internet, gekoppelt sein. Ein Steuerungssystem kann
ein Softwarepaket für
das Gebäudemanagement
und eine Implementierung des XML-Nachrichtensystems speichern und
ausführen,
das dafür
eingerichtet ist, von dem Softwarepaket zur Überwachung und Steuerung der
Einrichtungen verwendet zu werden. Das Steuerungssystem kann eine
Eingabe von Benutzern entgegennehmen und kann Zustandsinformation
für das Gebäudeenergieverbrauchssystem
anzeigen und anderweitig ausgeben, einschließlich der Zustandsinformation
jeder von der Mehrzahl der Einrichtungen. Der Energieverbrauch kann
durch Empfang von XML-Zustandsnachrichten von jeder von der Mehrzahl
der Einrichtungen überwacht
werden. Wenn die Energieverbrauchsniveaus angepaßt werden müssen, können XML-Steuerungsmeldungen
an eine oder mehrere von den Einrichtungen gesendet werden, um eine Änderung
des Energieverbrauchs zu veranlassen.
-
Implementieren
von Diensten
-
Nach
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zur Implementierung
von Diensten als Servlets bereitstellen. Der Mechanismus kann Funktionalität zur Entwicklung
von Diensten für
die verteilte Rechnerumgebung vorsehen.
-
Nach
einer Ausführungsform
kann eine Anwendungsprogramm-Schnittstelle (Application Programming
Interface, API) zur Verfügung
stehen, die die Funktionalität
bereitstellt, um die Initialisierung von Diensten und das Registrieren
von Diensten in einem Space ermöglichen.
Nach einer Ausführungsform
kann das API verwendet werden, um die Initialisierung des Dienstes
aufzurufen und eine Initialisierungsstatusseite, zum Beispiel eine
HTML-Seite, zu erzeugen, die den Zustand des Dienstes definieren
kann. Ein Benutzer kann auf den Zustand des Dienstes durch Zugriff
auf die Statusseite von einem Browser aus zugreifen. Nach einer
Ausführungsform
kann das API verwendet werden, um eingehende Nachrichten zu verarbeiten
und Dokumente in Beantwortung der Nachrichten zu erzeugen.
-
Eine
Ausführungsform
des Servlet-Mechanismus' kann
verschiedene Funktionen zur Verfügung
stellen, einschließlich,
jedoch nicht beschränkt
auf:
Verwaltung der Clientverbindung zu dem Dienst (eindeutige
Sitzungs-ID)
Verwaltung eines Aktivierungs-Space, der zum Speichern
der Ergebnisannoncen verwendet werden kann
Verwaltung von Überlassungen
von Verbindungen, Sitzungen und Ergebnissen in Aktivierungs-Spaces
Speicherbereinigung
von Sitzungen und Ergebnissen
Authentisierung von Clients
Erzeugen
von Fähigkeiten
von Clients pro Sitzung
-
Nach
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zur Kaskadierung
von Diensten zur Verfügung
stellen, durch den neue, komplexe Dienste aus anderen vorhandenen
Diensten aufgebaut werden können.
Zum Beispiel kann das Kombinieren des Trans formations- und Druckdienstes aus
einem Dienst zur JPEG-zu-PostScript-Transformation und aus einem
Druckdienst einen dritten, kaskadierten Dienst erzeugen. Nach einer
Ausführungsform
können
zwei oder mehr Dienste in einen komplexen Dienst dadurch kombiniert
werden, daß die
Zugriffsmethoden der zwei oder mehr Dienste als die Zugriffsmethoden des
kaskadierten Dienstes definiert werden. Die folgende Dienstannonce
für einen
kaskadierten Dienst ist zu Beispielzwecken aufgenommen und soll
in keiner Weise einschränkend
sein:
-
Schlußfolgerung
-
Verschiedene
Ausführungsformen
können
ferner das Empfangen, Senden oder Speichern von Befehlen und/oder
Daten umfassen, die gemäß der vorstehenden
Beschreibung auf einem Trägermedium
implementiert sind. Allgemein gesprochen kann ein Trägermedium
sowohl Festspeichermedien oder Arbeitsspeichermedien wie magnetische
oder optische Medien, z. B. Platte oder CD-ROM, flüchtige oder
nicht-flüchtige Medien
wie RAM (z. B. SDRAM, RDRAM, SRAM, etc.), ROM, etc. als auch Übertragungsmedien
oder Signale wie elektrische, elektromagnetische oder digitale Signale
umfassen, die über
ein Kommunikationsmedium wie ein Netzwerk und/oder eine kabellose
Verbindung transportiert werden.
-
Verschiedene
Abwandlungen und Änderungen
können
vorgenommen werden, wie sie einer Fachperson auf diesem Gebiet mit
der Unterstützung
dieser Offenbarung bzw. Offenlegung offensichtlich würden. Es ist
beabsichtigt bzw. es ist so gedacht, daß die Erfindung alle solche
Abwand lungen und Änderungen
einschließt
bzw. umfaßt
und dementsprechend die Spezifikationen, Anhänge und Zeichnungen eher in
einem veranschaulichenden als in einem einschränkenden Sinn zu betrachten
sind.