-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf verteilte Rechnerumgebungen
einschließlich
webzentrierter und internetzentrierter verteilter Rechnerumgebungen
und genauer gesagt auf eine heterogene, verteilte Rechnerumgebung
auf der Basis eines nachrichtenübergebenden
Modells für
die Verbindung von Clients und Diensten eines Netzwerks.
-
2. Beschreibung der relevanten
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-Computem, 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 Zeitspanne. 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 Flashspeicher
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 aufwerten 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 unter 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-Deseralisierung 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.
-
K.
Edwards "Core jini" Juni 1999 (1999-06),
Prentice Hall Ptr, 1. Ausgabe XP002212109 offenbart einen Speicherdienst,
nämlich
den sogenannten JavaSpaces, der ein Verfahren für die Teilung von Objekten zwischen
Anwendungen für
Jini-fähige
Clients und Dienste vorsiecht.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
oben skizzierten Probleme werden zum großen Teil gelöst durch
verschiedene Ausführungsformen
eines Systems und eines Verfahrens, wie in den beiliegenden Ansprüchen aufgezeigt,
zum Anzeigen, Adressieren und/oder Zugreifen auf Dienste innerhalb
einer verteilten Rechner- bzw. Computerumgebung. Eine verteilte
Rechnerumgebung kann auf "Spaces" bzw. "Speicherräumen" oder Objektspeichern
beruhen, um einen Rendezvous-Mechanismus oder Katalysator für die Interaktion
zwischen Clients und Dienstleistungen bereitzustellen. Die Dienstleistungsbereitsteller
(Service Provider) können
Dienste in einem annoncieren. Space können die Annoncen in einem
Space finden und die Information von einer Annonce verwenden, um auf
einen Dienst zuzugreifen, indem ein XML- (Extensible Markup-Language – erweiterte
Kennzeichnungssprache) Nachrichtenmechanismus der verteilten Rechnerumgebung.
Es können
viele Spaces (Speicherräume)
existieren, die jeweils XML-Annoncen enthalten, welche Dienstleistungen
oder einen Inhalt beschreiben. Demnach kann ein Space ein Lagerplatz
von XML-Annoncen
von Diensten und/oder XML-Daten sein, welche Rohdaten oder Annoncen
für Daten,
wie z.B. Ergebnisse, sein können.
-
In
einer Ausführungsform
ist ein Space selbst ein Dienst. Wie jeder Dienst hat ein Space
eine Annonce, welche ein Client des Space zunächst erhalten muß, um in
der Lage zu sein, den Dienst dieses Space laufenzulassen. Die eigene
Annonce des Space kann ein XML-Schema, einen Berechtigungsnachweis
oder Berechtigungsnachweise und einen URI (Uniform Resource Identifier – einheitliche
Ressourcenkennung) enthalten, welche anzeigen, wie auf den Space
zuzugreifen ist. Ein Client kann ein Gate aus der Annonce für einen Dienst
des Space aufbauen, um auf den Space zuzugreifen. Ein Client eines
Space kann selbst ein Service Provider sein, der versucht, in diesem
Space eine Annonce aufzugeben oder eine existierende Annonce zu modifizieren.
Oder ein Client eines Space kann eine Anwendung sein, die versucht,
auf einen Dienst oder einen Inhalt, der durch den Space aufgelistet
wird, zuzugreifen. Demnach können
Spaces Katalysatoren für
die Interaktion zwischen Clients und Diensten in der verteilten
Rechnerumgebung bereitstellen.
-
Ein
Space kann eine Sammlung von mit Namen versehenen Annoncen enthalten.
Ein Space kann erzeugt werden mit einer einzelnen Basis- bzw. Stammannonce,
welche den Space selbst beschreibt. Zusätzliche Annoncen können einem
Space hinzugefügt
werden. Der Name einer Annonce kann die Annonce innerhalb des Spaces
lokalisieren, einschließlich
der Angabe irgendwelcher notwendiger Informationen zur graphischen
Darstellung, wie z.B. eine Hierarchie von Namen. In einer bevorzugten
Ausführungsform
wird die Struktur eines Space nicht durch die verteilte Rechnerumgebung
festgelegt. Das heißt,
Spaces können
beispielsweise als ein ebener Satz von nicht zusammenhängenden
Annoncen oder eine graphische Darstellung zusammenhängender
Annoncen (beispielsweise eine kommerzielle Datenbank) sein. Da in
einer bevorzugten Ausführungsform
die verteilte Rechnerumgebung nicht festlegt, wie ein Space tatsächlich seinen
Inhalt speichert, können
Spaces durch kleine oder größere Einrichtungen
unterstützt
werden. Beispielsweise kann ein einfacher Space so gestaltet sein,
daß er
auf kleine Geräte,
wie z.B. PDAs, paßt.
Fortgeschrittenere Spaces können
auf großen
Servern implementiert sein, welche große kommerzielle Datenbanken
verwenden.
-
Wie
oben erwähnt,
kann ein Space Annoncen für
Dienste in der verteilten Rechnenumgebung enthalten. Eine Annonce
kann einen Mechanismus für
das Adressieren von und das Zugreifen auf Dienste und/oder den Inhalt
innerhalb der verteilten Rechnerumgebung bereitstellen. Eine Annonce
kann eine URI für
einen Dienst angeben. In einigen Ausführungsformen kann es die URI
ermöglichen,
daß der
Dienst über
das Internet zugänglich
ist. Eine Annonce kann auch ein XML-Schema für den Dienst enthalten. Das
XML-Schema kann einen Satz von Nachrichten spezifizieren, welche
Clients des Dienstes an den Dienst senden können, um die Funktionen des
Dienstes aufzurufen. Das XML-Schema kann die Schnittstelle zwischen
Client und Service definieren. Gemeinsam können die URI und die XML, die
in einer Annonce spezifiziert sind, anzeigen, wie der Service zu
adressieren und wie auf ihn zuzugreifen ist. Sowohl die URI als
auch das Schema können
in XML als eine Annonce in einem Space bereitgestellt werden. Demnach
kann ein Mechanismus für
die Adressierung des Dienstes und den Zugriff auf diesen in einer
verteilten Rechnerumgebung als Annonce in einem Space veröffentlicht
werden. Clients können
einen Space auffinden und dann nach individuellen Annoncen für Dienste
oder Inhalte nachschlagen. Spaces und alle Annoncen innerhalb eines
Space können
unter Verwendung von URIs adressiert werden. In einer Ausführungsform
können
Space- und Annoncennamen den URL- (Uniform Resource Locator – einheitlicher
Ressourcenlokalisierer) Namensgebungskonventionen entsprechen. Die
Verwendung von URIs, beispielsweise URLs, für die Adressierung von Spaces
kann es ermöglichen,
daß Spaces
in einigen Ausführungsformen über das
Internet adressierbar sind.
-
Sobald
ein Client eines Space die Annonce eines Spacedienstes findet, kann
dieser Client des Space den Spacedienst laufen lassen, wie auch
jeden anderen Dienst. Man beachte, daß der Client des Spacedienstes
ein anderer Dienst sein kann (beispielsweise ein Dienst, der versucht,
eine Annonce in dem Space aufzugeben). In einer Ausführungsform
kann der Client des Space, um einen Dienst des Space laufenzulassen,
zunächst
einen Berechtigungsdienst für
den Space laufenlassen, um ein Berechtigungstoken (Berechtigungsmarke)
zu erhalten. Der Berechtigungs- bzw.
Authentisierungsdienst kann in der Dienstleistungsannonce des Dienstes
des Space spezifiziert sein. Der Client des Space verwendet das
Berechtigungstoken, das XML-Schema des Space (aus der Annonce für den Dienst
des Space) und die URI des Space (aus der Annonce des Dienstes des
Space), um ein Gate bzw. einen Zugang für den Space aufzubauen. Der
Client des Space kann dann den Dienst des Space laufenlassen, indem
er das Gate bzw. den Zugang verwendet, um Nachrichten an den Dienst
des Space zu senden.
-
Für Ausführungsformen,
welche eine Authentisierung bzw. Berechtigung verwenden, wenn der
Dienst des Space die erste Nachricht von dem Client empfängt, wobei
das Berechtigungstoken dabei verwendet wird, verwendet der Dienst
des Space denselben Berechtigungsdienst (in der Annonce des Dienstes
des Dienstes des Space spezifiziert), um den Client für echt zu
erklären
und damit seine Identität
bereitzustellen. Der Dienst des Space kann die Fähigkeiten bzw. Möglichkeiten
des Client festlegen und sie an den Echtheitstoken binden.
-
Ein
Client eines Space kann verschiedene Einrichtungen des Space laufenlassen,
indem er Nachrichten an den Dienst des Space sendet. In einer Ausführungsform
leitet ein Client eines Space, wenn er eine Anforderung an den Dienst
des Space sendet, sein Echtheitstoken in der Anforderung, so daß der Dienst
des Space die Anforderung anhand der speziellen Möglichkeiten
bzw. Berechtigungen dieses Client überprüft.
-
Jeder
Space ist typischerweise ein Dienst und kann ein XML-Schema haben,
welches die Kernfunktionalität
des Dienstes des Space definiert. Das XML-Schema kann die Clientsschnittstelle zu
dem Dienst des Space spezifizieren. In einer Ausführungsform
können
alle Dienste des Space ein Grundniveau von Nachrichten, die sich
auf den Space beziehen, bereitstellen. Die Grundniveaufunktionen
des Space können
in der grundlegenden Funktion des Space bestehen, die von den meisten
Clients verwendet werden kann, einschließlich kleiner Einrichtungen,
wie z.B. PDAs. Es kann wünschenswert
sein, zusätzliche
Funktionalität
bereitzustellen, beispielsweise für fortgeschrittenere Clients.
Erweiterungen des Space auf Grundniveau können erreicht werden durch
Hinzufügen
weiterer Nachrichten zu dem XML-Schema, welches den Space anzeigt bzw.
bewirbt. Beispielsweise prägen
die Nachrichten des Grundniveaus keinerlei graphische Darstellung
der Beziehung den Annoncen auf. Nachrichten, die beispielsweise
eine Hierarchie von Annoncen durchlaufen sollen, können eine
Spaceerweiterung sein. Das Bereitstellen einer solchen zusätzlichen
Funktionalität
kann erfolgen durch Bereitstellen eines oder mehrerer erweiterter
XML-Spaceschemata
oder Schemaerweiterungen für
einen Space. Die erweiterten Schemata können das Basisschema enthalten,
so daß Clients
eines erweiterten Space auf den Space weiterhin wie auf einen BasisSpace
zugreifen können.
-
In
einer Ausführungsform
kann ein Space eine Einrichtung für einen Client bereitstellen,
um einen Dienst, der in dem Space beworben bzw. angezeigt wird,
einzusetzen. Das Einsetzen bzw. Anlegen eines Dienstes ist die Initialisierung,
die es einem Client ermöglicht,
daß er
in der Lage ist, einen Dienst ablaufen zu lassen. Um einen Dienst
einzusetzen, kann ein Client zunächst
eine der Dienstannoncen auswählen,
die in dem Space veröffentlicht
werden. Der Client kann die verschiedenen Einrichtungen verwenden,
wie z.B. die Nachschlageeinrichtung, die durch den Space bereitgestellt
wird, um unter den verschiedenen Annoncen in dem Space nachzuschlagen.
Dann kann der Client eine Anforderung an den Space richten, den
Dienst einzurichten.
-
In
einer Ausführungsform
kann die Einrichtung eines Dienstes die folgenden Aktionen umfassen. Nachdem
der Client an den Dienst des Space die Anforderung gerichtet hat,
den ausgewählten
Dienst einzurichten, kann der Dienst des Space dann verifizieren,
ob der Client die Zulassung hat, den angeforderten Dienst einzurichten.
Der Dienst des Space kann diese Verifizierung durchführen, indem
er ein Echtheitstoken untersucht, welches in der Nachricht des Client
enthalten ist. Das Echtheitstoken ist der Berechtigungsnachweis,
welchen der Client empfangen hat, als er eine Sitzung mit dem Dienst
des Space eingerichtet hat. Der Dienst des Space kann entsprechend
dem Echtheitstoken des Client und der Fähigkeiten bzw. Berechtigungen,
die für
diesen Client angezeigt sind, verifizieren, ob der Client die Zulassung
hat, den angeforderten Dienst einzurichten.
-
Unter
der Annahme, daß der
Client die Berechtigung hat, kann der Dienst des Space auch eine
Miete für
die Annonce des Dienstes für
den Client erhalten, wobei die Zeit für die Mietanforderung durch
den Client angegeben wird. Der Dienst des Space kann dann eine Nachricht
an den Client senden, welcher die zugeordnete Miete und die Dienstannonce
des Dienstes enthält.
In einer Ausführungsform
kann der Client einen Echtheitsdienst laufenlassen, der in der Dienstannonce
spezifiziert ist und ein Echtheitstoken erhalten. Als nächstes kann
der Client einen Zugang zu dem Dienst aufbauen (beispielsweise unter
Verwendung des Echtheitstokens und des XML-Schemas und der Service-URI
aus der Annonce). Die oben beschriebene Kommunikation zwischen dem
Client und dem Dienst des Space wird ausgeführt unter Verwendung der XML-Nachrichten der verteilten
Rechnerumgebung. Der Client kann dann den Dienst unter Verwendung
des aufgebauten Zugangs und der XML-Benachrichtigungen laufenlassen.
Der Dienst kann in ähnlicher
Weise einen Dienstzugang für
eine XML-Nachrichtenkommunikation mit dem Client aufbauen.
-
Spaces
bzw. Speicherräume
können
einen bequemen Mechanismus für
das Speichern von Ergebnissen von einem Dienst bieten, den ein Client
ablaufen läßt. Die
Verwendung eines Spaces für
Ergebnisse kann es einem kleinen Client ermöglichen, die Ergebnisse des
laufenden Dienstes stückweise
zu empfangen. Einige Dienste erzeugen möglicherweise eine große Menge
an Ergebnissen. Durch Verwendung eines Space für das Speichern der Ergebnisse
von einem Dienst können
Clients, die nicht die Resourcen haben, um die vollständigen Ergebnisse
auf einmal zu empfangen, dennoch den Dienst benutzen. Darüber hinaus
kann aufgrund der Verwendung eines Space das Speichern von Ergebnissen
ein Dienst, der auf einem schnellen intensiv beschäftigten
Server läuft,
von der direkten Interaktion mit einem langsamen Client befreit
werden, wenn er Ergebnisse in großem Umfang liefert. Demnach
kann der Dienst für
die Verwendung durch andere Clients früher freigegeben werden.
-
Ein
Space kann einen bequemen Mechanismus für das Zugreifen auf ein Ergebnis
durch unterschiedliche Clients und/oder zu unterschiedlichen Zeitpunkten
bieten. Beispielsweise ist ein Client möglicherweise nicht in der Lage,
das gesamte Ergebnis zu verwenden, jedoch könnte ein Benutzer wünschen,
auf den übrigen
Teil des Ergebnisses später
unter Verwendung eines anderen Client zuzugreifen, der darauf zugreifen kann.
Beispielsweise könnte
das Ergebnis eine Information über
einen Börsenwert
sein, welcher den aktuellen Preis einer Aktie anzeigt (zugänglich durch
ein PDA), und könnte
eine Tafel von Aktienpreisen zeigen (auf die später durch einen Laptop zugegriffen
werden kann). Außerdem
kann die Benutzung eines Space bzw. Speicherraums für Ergebnisse
in der verteilten Rechnerumgebung es einem Client ermöglichen,
das Ergebnis eines Dienstes einem anderen Dienst zuzuführen, ohne
daß es
notwendig ist, das Ergebnis zuerst herunterzuladen. Beispielsweise
könnte
im Fall der oben erwähnten
Information über
Aktienkurse die PDA die Karte in einen anderen Dienst eingeben,
welcher die Karte bzw. den Plan druckt, ohne daß die PDA die Karte selbst herabladen
muß. Demnach
kann ein Ergebnisspeicherraum bzw. – space einen Mechanismus für einen
Client bereitstellen, um eine Weiterleitung an einen anderen Client
oder Service vorzunehmen, ohne daß der Client die Ergebnisse
handhaben oder empfangen muß.
-
In
einer Ausführungsform
bedeutet die Benutzung eines Speicherraums für Ergebnisse nicht notwendigerweise,
daß der
Dienst alle Ergebnisse in diesem Speicherraum ablegen muß. Es kann
verschiedene Alternativen für
irgendein Ergebnis geben, das ein Dienst erzeugt. Beispielsweise
könnte
ein Teil des Ergebnisses oder alle Ergebnisse in einer Nachricht
in-line an den Client gesendet werden. Alternativ kann das Ergebnis
in dem Speicherraum abgelegt werden und dann kann eine Benachrichtigung
an den Client gesendet werden, die auf das Ergebnis Bezug nimmt (beispielsweise
einschließlich
einer URI für
das Ergebnis oder für
eine Anzeige für
das Ergebnis). Eine weitere Option kann darin bestehen, das Ergebnis
in dem Speicherraum abzulegen mit einer Benachrichtigung über ein
Ereignis aus dem Raum. Beispielsweise können der Client und der Dienst übereinkommen,
das Ergebnis mit einem bestimmten Namen zu bezeichnen und dann kann
der Client sich bei dem Speicherraum registrieren (unter Verwendung
einer Einrichtung wie oben beschrieben), um ein Ereignis zu empfangen,
wenn ein Ergebnis unter diesem Namen dem Space hinzugefügt wird.
Siehe die obige Beschreibung bei einem Hinweis auf ein Ereignis.
-
Demnach
können
mehrere verschiedene Mechanismen in der verteilten Rechnerumgebung
verwendet werden, damit ein Dienst Ergebnisse an eine Client liefert.
Die aktuellen Ergebnisse können
an den Client als Wert in einer XML- Nachricht geliefert werden
oder die Ergebnisse können
an den Client unter Bezug auf die tatsächlichen Ergebnisse geliefert
werden (oder Anzeigen für
die tatsächlichen
Ergebnisse), die in einem Speicherraum abgelegt sind, und der Client
kann eine Nachricht empfangen, welche auf die Ergebnisse in dem Speicherraum
Bezug nimmt. Darüber
hinaus können
Ergebnisse oder Anzeigen für
Ergebnisse in einem Speicherraum angeordnet werden und der Client
kann durch ein Ereignis benachrichtigt werden.
-
Ein
weiterer Mechanismus für
die Handhabung von Ergebnissen kann darin liegen, daß der Client
einen anderen Dienst spezifiziert, in welchen die Ergebnisse eingegeben
werden sollen. Wenn beispielsweise ein Client einen Dienst ablaufen
läßt, der
Ergebnisse erzeugt, so kann der Client diesen Dienst anweisen (zum Beispiel
durch eine XML-Nachricht), daß er
die Ergebnisse für
die weitere Verarbeitung an einen anderen Dienst liefert. Dies kann
beinhalten, daß der
Client die URI einer Anzeige für
den anderen Dienst anzeigt, so daß der das Ergebnis erzeugende
Dienst ein Gatter zu dem anderen Dienst erzeugen kann, um den anderen Dienst
laufen zu lassen und an ihn die Ergebnisse weiterzuleiten. In diesem
Beispiel kann der das Ergebnis erzeugende Dienst ein Client des
anderen Dienstes sein. Ein Beispiel eines Dienstes für die weitere
Verarbeitung ist ein Anzeigedienst, der die Ergebnisse für den ursprünglichen
Client anzeigen kann. Dieser Anzeigedienst kann demselben Gerät zugeordnet
sein wie der Client.
-
Die
Ergebnisspeicherräume
können
es ermöglichen,
daß die
verteilte Rechnerumgebung einen einfachen Fernmethodenaufruf bereitstellt,
der für
einfache Clients mit minimalen Speichermöglichkeiten und minimaler Bandbreite
praktisch ist, da er die nachteiligen Nebeneffekte großer Programmobjekte
(zusammen mit den erforderlichen Klassen) nicht haben muß, die (notwendigerweise) über das
Netzwerk an den Client zurückgegeben
werden, wie bei konventionellen Techniken des entfernten Methodenaufrufs.
Statt dessen können
Ergebnisse an einen Ergebnisspeicherraum geliefert werden und nur
falls es gewünscht
ist (und wenn sie auf dem Client residieren können), werden die eigentlichen
Objekte für
den Client heruntergeladen.
-
In
verschiedenen Ausführungsformen
können
Ergebnisse auf eine Vielzahl von Weisen an einen Client zurückgeliefert
werden: beispielsweise in einer Nachricht, in einem Speicherraum,
in einem Speicherraum, wobei der Client über ein Ereignis benachrichtigt
wird, unter Verwendung einer Anzeige, die in einer Nachricht zurückgeliefert
wird, unter Verwendung einer Anzeige, die in einen Speicherraum
geliefert wird und unter Verwendung einer Anzeige, die in einen
Speicherraum geliefert wird, wobei der Client über ein Ereignis benachrichtigt
wird. Die Verfügbarkeit
dieser Vielzahl von Methoden kann die Flexibilität und Anpassungsfähigkeit
der verteilten Rechnerumgebung an eine Vielfalt von Situationen
verbessern, wie zum Beispiel für
Clients, die unterschiedliche Fähigkeiten
haben. Für
eine zusätzliche
Flexibilität
können
die Ergebnisse in effektiver Weise auch an einen anderen Dienst
geleitet werden.
-
Ein
Client kann eine erste Nachricht an einen Dienst senden, um den
Aufruf einer oder mehrerer Funktionen des Dienstes anzufordern.
Ein Schema für
den Dienst kann eine Mehrzahl von Nachrichten, einschließlich der
ersten Nachricht, spezifizieren, die verwendbar sind, um die Funktionen)
des Dienstes aufzurufen. Die Nachrichten und das Schema können in
einer plattformunabhängigen
und/oder programmsprachenunabhängigen
Datenrepräsentationssprache,
wie zum Beispiel XML ausgedrückt
werden. In Reaktion auf die erste Nachricht kann bzw. können die
Funktionen) des Dienstes aufgerufen werden. Der Dienst kann dann
einen Satz von Ergebnissen erzeugen. Die Ergebnisse können in
der Datenrepräsentationssprache
(beispielsweise XML) ausgedrückt
werden. Der Dienst kann den Satz von Ergebnissen an einer Stelle
in einem Speicherraum speichern, wobei der Speicherraum eine Netzwerk
adressierbare Speicherstelle aufweist.
-
In
einer Ausführungsform
kann der Speicherraum bei der Vorbereitung zum Speichern des Satzes
von Ergebnissen erzeugt werden. In einer Ausführungsform kann ein Ereignis
erzeugt und an den Client gesendet werden, um den Client zu benachrichtigen,
daß die
Ergebnisse in dem Speicherraum gespeichert sind. Ein Client kann
dann auf den Satz von Ergebnissen aus dem Speicherraum zugreifen
und diesen lesen. In einer Ausführungsform
kann ein zweiter Client (d.h. ein Client, der sich von demjenigen
unterscheidet, welcher die Nachricht für das Aufrufen der Funktionen)
gesendet hat) den Satz von Ergebnissen aus dem Speicherraum lesen. Auf
diese Weise kann ein Benutzer einen zweiten Client verwenden, um
Ergebnisse zu lesen und anzuzeigen, wenn der erste Client möglicherweise
keine ausreichenden Resourcen hat, um eine solche Aufgabe zu erfüllen.
-
In
einer Ausführungsform
können
die Ergebnisse, anstatt daß sie
in einem Speicherraum gespeichert werden, in einer Nachricht an
den Client gesendet werden. Die Nachricht kann in der Datenrepräsentationssprache
(beispielsweise XLM) ausgedrückt
werden und kann in einer Ausführungsform
in dem Schema für
den Dienst spezifiziert werden.
-
In
einer Ausführungsform
können
Ergebnisse unter Verwendung einer Anzeige für die Ergebnisse geliefert
werden. Wie zuvor beschrieben, kann ein Client eine erste Nachricht
an einen Dienst senden, um den Aufruf einer oder mehrerer Funktionen
des Dienstes anzufordern. In Reaktion auf die erste Nachricht kann bzw.
können
die Funktionen) des Dienstes aufgerufen werden, und der Dienst kann
dann einen Satz von Ergebnissen erzeugen. In einer Ausführungsform
kann der Dienst den Satz von Ergebnissen an einer Stelle in einem
Speicherraum speichern, wobei der Speicherraum eine Netzwerk adressierbare
Speicherstelle aufweist. Der Dienst kann eine Anzeige für die Ergebnisse
erzeugen. Die Anzeige kann Information enthalten, die verwendbar
ist, um auf die Ergebnisse zuzugreifen und diese zu leisen, beispielsweise
aus dem Speicherraum.
-
Beispielsweise
kann die Anzeige eine einheitliche Resourcenkennung (URI – Uniform
Resource Identifier) aufweisen, unter welcher auf die Ergebnisse
zugegriffen werden kann. In einer Ausführungsform kann die Anzeige
ein Schema enthalten (beispielsweise ein XML-Schema), welches ein
Format der Ergebnisse spezifiziert. In einer Ausführungsform
kann die Anzeige in einer Datenrepräsentationssprache, wie zum
Beispiel XML, ausgedrückt
werden.
-
In
einer Ausführungsform
kann der Dienst eine Nachricht einschließlich der Anzeige an den Client
senden. Die Nachricht kann in der Datenrepräsentationssprache (zum Beispiel
XML) ausgedrückt
werden und kann in einer Ausführungsform
in dem Schema für
den Dienst spezifiziert sein. In einer weiteren Ausführungsform
kann die Anzeige in einem Speicherraum gespeichert werden. Der Speicherraum
kann derselbe sein wie der Speicherraum, in welchem die Ergebnisse
gespeichert wurden oder er kann von diesem verschieden sein. Der
Client kann die Anzeige aus dem Speicherraum lesen. In einer Ausführungsform
kann ein Ereignis erzeugt und an den Client gesendet werden, um
den Client zu benachrichtigen, daß die Anzeige für die Ergebnisse
in dem Raum gespeichert ist.
-
Ein
Client kann dann unter Verwendung der Anzeige auf den Satz von Ergebnissen
zugreifen und diese lesen. In einer Ausführungsform kann ein zweiter
Client (d.h. ein Client, der sich von demjenigen, welcher die Nachricht
zum Aufrufen der Funktionen) abgesandt hat, unterscheidet) unter
Verwendung der Anzeige die Ergebnisse lesen.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist
eine Darstellung eines Stack nach herkömmlicher, verteilter IT-Technologie;
-
2 ist
eine Darstellung eines Programmiermodells für eine verteilte Rechnerumgebung
gemäß einer
Ausführungsform;
-
3 ist
eine Darstellung von Nachrichten- und Netzwerkschichten für eine verteilte
Rechnerumgebung gemäß einer
Ausführungsform;
-
4 ist
eine Darstellung eines Auffindungs- bzw. Discoverydienstes zum Auffinden
von Räumen bzw.
Plätzen,
die Objekte oder Dienste in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform anzeigen
bzw. bekannt geben;
-
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 gemäß einer
Ausführungsform
Dienste in Räumen
bzw. Spaces angezeigt bzw. bekanntgegeben werden;
-
9 ist
eine Darstellung eines verteilten Verarbeitungsmodells, in dem Ergebnisse
gemäß einer
Ausführungsform
in Räumen
bzw. Spaces gespeichert werden;
-
10a ist eine Darstellung von Client- und Dienst-Gattern
als Endpunkte von Nachrichten in einem verteilten Verarbeitungsmodell
gemäß einer
Ausführungsform;
-
10b ist eine Darstellung der Erzeugung eines Endpunktes
von Nachrichten gemäß einem
Schema für
den Zugriff auf Dienste 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-Clients für einen
herkömmlichen
Browser, um an der verteilten Rechnerumgebung gemäß einer
Ausführungsform
teilzunehmen;
-
14 stellt die Verwendung eines Nachrichtengatters
dar, um eine Schnittstelle zum entfernten Methodenaufruf für einen
Dienst in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
bereitzustellen;
-
15 ist eine Darstellung der Verwendung eines Raumes
bzw. Space in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform;
-
16 stellt eine Anzeige- bzw. Bekanntmachungsstruktur
gemäß einer
Ausführungsform
dar;
-
17 stellt ein Beispiel eines Zustandsübergangs
bei der Bekanntmachung dar, den eine Bekanntmachung während ihrer
Lebensdauer gemäß einer
Ausführungsform
erfahren kann;
-
18 ist eine Darstellung verschiedener Mechanismen
zur Lokalisierung von Räumen
bzw. Spaces in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform;
-
19 ist eine Darstellung von Vereinigungen bzw.
Föderationen
von Räumen
bzw. Spaces in einer verteilten Rechnerumgebung 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 Typenhierarchie
von Space-Ereignissen 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 Default-Space in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform;
-
24 stellt ein Beispiel einer Einrichtung dar,
die gemäß einer
Ausführungsform
eine Brücke
für nahegelegene
Einrichtungen zu einem anderen Transportmechanismus schlägt, um zu
ermöglichen,
daß auf
die Dienste, die von den nahegelegenen Einrichtungen zur Verfügung gestellt
werden, von Einrichtungen außerhalb
des Nachbarschaftsbereiches der Einrichtungen zugegriffen werden
kann;
-
25 ist eine Darstellung der Verwendung von Überlassungsverlä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 den Schritt 1002 von 26a erweitert und einen Authentifizierungsdienst
darstellt, der gemäß einer
Ausführungsform
einen Authentifizierungsnachweis erzeugt;
-
27 stellt eine Ausführungsform eines Brückenschlags-
bzw. Überbrückungs-Mechanismus' dar;
-
28 stellt ein Beispiel eines Protokolls zum Auffinden
von Spaces dar, das gemäß einer
Ausführungsform
auf einen externen Auffindungs- bzw. Discovery-Dienst abgebildet
ist;
-
29 stellt den Brückenschlag für einen
Client, der außerhalb
der verteilten Rechnerumgebung ist, zu einem Space in der verteilten
Rechnerumgebung gemäß einer
Ausführungsform
dar;
-
30 ist eine Darstellung eines Proxy-Mechanismus' gemäß einer
Ausführungsform;
-
31 stellt eine Ausführungsform eines Client mit
einer zugeordneten Anzeige und einem zugeordneten Anzeigedienst
gemäß einer
Ausführungsform
dar;
-
32A und 32B stellen
Beispiele der Verwendung von Schemen dynamischer Anzeigeobjekte gemäß einer
Ausführungsform
dar;
-
33A stellt eine typische Darstellung als Zeichenketten
in der Programmiersprache C dar;
-
33B stellt ein Beispiel einer herkömmlichen
Zeichenkettenfunktion dar;
-
33C stellt ein effizientes Verfahren zur Darstellung
und Verwaltung von Zeichenketten in allgemeinen und in kleinformatigen
Systemen wie eingebetteten Systemen im besonderen gemäß einer
Ausführungsform
dar;
-
34 stellt einen Prozeß des Bewegens von Objekten
zwischen einem Client und einem Dienst gemäß einer Ausführungsform
dar;
-
35a und 35b sind
Datenflußdiagramme,
die Ausführungsformen
darstellen, bei denen eine virtuelle Maschine (z.B. JVM) Erweiterungen
zum Kompilieren von Objekten (z.B. Java-Objekten) in XML-Darstellungen der Objekte
und zum Dekompilieren der XML-Darstellungen von (Java-)Objekten
in (Java-)Objekte enthält;
-
36 stellt einen Client und einen Dienst dar, die
auf Speichermechanismen in der verteilten Rechnerumgebung gemäß einer
Ausführungsform
zugreifen;
-
37 stellt eine Prozeßmigration unter Verwendung
einer XML-Darstellung des Zustands eines Prozesses gemäß einer
Ausführungsform
dar;
-
38 stellt eine mobile Client-Einrichtung dar,
die auf Spaces in einem lokalen, verteilten Rechnernetzwerk gemäß einer
Ausführungsform
zugreift;
-
39a stellt einen Benutzer einer mobilen Einrichtung
dar, der den Standort von Docking-Stationen gemäß einer Ausführungsform
erkundet bzw. 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
Geräten
bzw. Einrichtungen dar, die durch eine Steuersystem gesteuert werden
und innerhalb der verteilten Rechnerumgebung gemäß einer Ausführungsform
zugreifbar sind;
-
40b stellt ein Gerätesteuerungssystem dar, das über ein
Netzwerk (z. B. das Internet) mit eingebetteten Einrichtungen verbunden
ist, auf die innerhalb der verteilten Rechnerumgebung gemäß einer
Ausführungsform
zugegriffen werden kann;
-
41 ist ein Flußdiagramm, welches das Besetzen
eines neuen Space in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
veranschaulicht,
-
42 ist ein Flußdiagramm, welches das sichere
Besetzen eines neuen Space in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
zeigt,
-
43 ist ein Flußdiagramm, welches eine Suche
nach Spaces zeigt, welche einen Suchdienst verwendet, und zwar in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform,
-
44a ist ein Flußdiagramm, welches ein Verfahren
zum Speichern von Ergebnissen eines Dienstes in einem Space in einer
verteilten Computerumgebung gemäß einer
Ausführungsform
zeigt,
-
44b ist ein Flußdiagramm, welches ein Verfahren
zum Speichern von Ergebnissen eines Dienstes in einem Space und
die Meldung an einen Client unter Verwendung eines Ereignisses zeigt,
in einer verteilten Rechnerumgebung gemäß einer Ausführungsform,
-
44c ist ein Flußdiagramm, welches ein Verfahren
für das
Senden von Ergebnissen eines Dienstes in einer Nachricht an einen
Client in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
zeigt,
-
44d ist ein Flußdiagramm, welches ein Verfahren
für das
Zurückliefern
von Ergebnissen eines Dienstes unter Verwendung einer Annonce in
einer verteilten Rechnerumgebung gemäß einer Ausführungsform
zeigt,
-
44e ist ein Flußdiagramm, welches ein Verfahren
zum Liefern von Ergebnissen eines Dienstes unter Verwendung einer
Annonce zeigt, die an einen Client in einer Nachricht gesendet wird,
und zwar in einer verteilten Rechnerumgebung gemäß einer Ausführungsform,
-
44f ist ein Flußdiagramm, welches ein Verfahren
zum Liefern von Ergebnissen eines Dienstes unter Verwendung einer
Annonce, die in einem Space gespeichert ist, in einer verteilten
Rechnerumgebung gemäß einer
Ausführungsform
der Erfindung zeigt,
-
44g ist ein Flußdiagramm, welches ein Verfahren
zum Liefern von Ergebnissen eines Dienstes unter Verwendung einer
Annonce, die in einem Space gespeichert ist, und unter Meldung an
einen Client unter Verwendung eines Ereignisses in einer verteilten
Rechnerumgebung gemäß einer
Ausführungsform
zeigt,
-
45 ist ein Flußdiagramm, welches ein Verfahren
zum Senden von Ergebnissen eines Dienstes an einen anderen Dienst
in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
zeigt,
-
46a und 46b sind
Darstellungen eines Suchdienstes und seiner Interaktion mit einem
Client in einer verteilten Rechnerumgebung gemäß einer Ausführungsform,
-
47 ist ein Flußdiagramm, welches eine Suche
nach Dokumenten innerhalb eines Space in einer verteilten Rechnerumgebung
gemäß einer
Ausführungsform
zeigt, und
-
48 ist ein Flußdiagramm, welches die Adressierung
eines Dienstes unter Verwendung einer Annonce, die innerhalb eines
Space gespeichert ist, in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
zeigt.
-
DETAILLIERTE BESCHREIBUNG
VON AUSFÜHRUNGSFORMEN
DER ERFINDUNG
-
Überblick über 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
eine 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. Nach 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. Nach 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. Nach 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.
-
Nach
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 Rechnenumgebung
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. Nach einer Ausführungsform
können
das Objekt und der Client-spezifische Name als Parameter übergeben werden.
Nach 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. Nach 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. Nach 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.
Nach 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. Nach 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 nach 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.
-
Nach
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.
-
Nach
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.
-
Nach
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.
Nach 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 nach 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. Nach 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 nach
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. Nach 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.
Nach einer Ausführungsform
kann, sobald die unteilbare Einheit von Code und Daten für ein Nachrichtengatter
eingerichtet wurden, dieses nicht mehr bezüglich seiner Typisierung, Nachrichtendeskriptoren
und Senderidentifikation geändert
werden. Nach 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.
Nach 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.
Nach einer Ausführungsform
kann das Nachrichtengatter beim Dienst erzeugt werden, wenn der
Dienst die erste Nachricht von dem Nachrichtengatter beim Client
empfängt.
Nach 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. Nach 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. Nach 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.
Nach 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. Nach 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 Gattenfabrik 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. Nach 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). Nach 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. Nach 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
Gattenfabrik 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 nach 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.
-
Nach
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 sicheren 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 Generierungswerkzeug
kann einen XML-Parser, einen Codegenerator und einen Codecompiler
enthalten. Nach 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. Nach 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 nach 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.
Nach 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. Nach 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. Nach 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).
-
Nach
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. Nach 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).
Nach 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. Nach 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.
-
Nach
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.
-
Nach
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.
-
Nach
einer Ausführungsform
eine verteilten Rechnerumgebung können Eingangsrechner bzw. Datenstationen
für Dienste
(Dienstschnittstellen) in Clients eingebaut sein. Nach einer Ausführungsform
kann die Dienstschnittstelle eine vorab eingerichtete Benutzerschnittstelle
sein, die dem Client von dem Dienst bereitgestellt wird. Nach 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. Nach 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. Nach einer Ausführungsform
kann eine Dienstschnittstelle für
einen Dienst in einem Web-Browser auf dem Client implementiert sein.
-
Nach
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. Nach einer Ausführungsform kann
die Nachrichtenleitung in Code geschrieben sein, der im Wesentlichen
of jeder beliebigen Plattform ablaufen kann. Nach einer Ausführungsform
kann die Nachrichtenleitung in der Sprache Java geschrieben sein. Nach
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. Nach 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.
-
Nach
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 nach 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. Nach 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. Nach
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. Nach 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. Nach 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.
-
Nach
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 nach einer Ausführungsform nur
eine Ergebnisreferenz oder -referenzen (Ergebnishinweise) 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). Nach 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. Nach 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.
-
Nach
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. Nach 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.
-
Nach
einer Ausführungsform
können
die Methodengatter und entfernten Methoden in Java vorliegen. Nach
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.
Nach 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 unten wegen weiterer Diskussion über die Verwendung von Spaces
für Ergebnisse.
-
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.
Nach 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.
Nach einer Ausführungsform
ist das XML-Ereignisdokument der einzige an die Callback-Methode übergebene
Parameter für
die (Ereignis-) Handhabung.
-
Nach
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 Ereigniserzeugerdienst 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überprü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ßkontrolle
und Ressourcenüberwachung
unterstützen.
-
Mechanismus zum Auffinden
von Diensten
-
Nach
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:
- Auffinden eines Dienstes unter Verwendung flexibler Suchkriterien.
- Anfordern eines Authentisierungsmechanismus', zum Beispiel eines Authentisierungsnachweises,
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. Nach 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. Nach
einer Ausführungsform
kann jede Clientanforderung eine Sammlung von Daten enthalten, die
auch in dazu passenden Antworten gegeben werden können, wodurch
es möglich
wird, daß die
Anforderungen und Antworten aufeinander bezogen bzw. miteinander
korreliert werden.
-
Nach
einer Ausführungsform
der verteilten Rechnerumgebung kann ein Mechanismus zum Auffinden von
Diensten ein flexibles Suchkriterium, das auf einer erweiterbaren
Grammatik beruht, vorsehen. Nach 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. Nach 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. Nach einer Ausführungsform können die
Dienstnamen und Diensttypen mit den Typen der Elemente in der XML-Dienstannonce
hinsichtlich ihrer Typen überprüft werden.
-
Nach
einer Ausführungsform
kann eine verteilte Rechnerumgebung einen Mechanismus beinhalten, damit
Clients Zugriffsrechte auf Dienste aushandeln können. Nach 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.
-
Nach
einer Ausführungsform
kann es der Mechanismus zum Auffinden von Diensten einem Client
ermöglichen,
einen Sicherheitsfunktions- bzw. -eigenschaftsnachweis von einem
Dienst anzufordern. Nach 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.
-
Nach
einer Ausführungsform
kann die verteilte Rechnenumgebung 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.
-
Nach
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. Nach 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.
Nach 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 gewährt bekommen
hat. Nach einer Ausführungsform
kann dem Client Zugriff nur auf die angeforderten Eigenschaften
eingeräumt
werden, und zu denen der Client Zugriffsprivilegien hat.
-
Nach
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. Nach 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. Nach 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.
-
Nach
einer Ausführungsform
kann die verteilte Rechnerumgebung einen Mechanismus zum Verfolgen von
Suchanforderungen zum Auffinden von Diensten und von Antworten auf
die Anforderungen beinhalten. Nach einer Ausführungsform können Suchanforderungs-
und – antwortnachrichten
ein Feld beinhalten, das verwendet werden kann, um eine Zeichenkette
oder ein XML-Dokument einzuschließen. Nach einer Ausführungsform
wird die Zeichenkette oder das XML-Dokument, das in dem Feld einer Anforderungsnachricht
enthalten ist, auch in der Antwortnachricht zurückgegeben. Nach einer Ausführungsform
muß die
Zeichenkette oder das XML-Dokument in der Antwortnachricht zurückgegeben
werden. Nach 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. Nach einer
Ausführungsform
kann dieser Mechanismus beim Debugging komplexer Systeme verwendet
werden. Nach 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. Nach 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.
-
Nach
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. Nach 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. Nach 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.
-
Nach
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. Nach einer Ausführungsform kann der Mechanismus
zum Abgleich von Spezifikationsschnittstellen die Fähigkeit
bereitstellen, zwischen verschiedenen Revisionen derselben Komponente
zu unterscheiden.
-
Nach
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. Nach 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.
-
Nach
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. Nach 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. Nach 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.
-
Nach
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.
-
Nach
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 Archivierungsdienst
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 Wiederlinden
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
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.
-
Nach
einer Ausführungsform
wird der archivierte, dauerhafte Zustand nicht verwendet. Nach dieser Ausführungsform
werden auch die Zustandsänderungen
3 und 4 nicht verwendet. Nach 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. Nach 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. Nach 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).
Nach 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:
http://java.sun.com/spacename/advertisement/element/attribute.
-
Nach
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.
Nach 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. Nach einer Ausführungsform
kann einer Sitzung eine eindeutige Sitzungs-Identifikationsnummer (Sitzungs-ID)
zugewiesen werden. Die Sitzungs-ID kann eine Client-Space-Verbindung eindeutig
identifizieren. Nach 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. Nach 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. Nach 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. Nach
einer Ausführungsform
kann ein XML-Schema verwendet werden, um die Nachricht zu überprüfen. Der
Client kann danach mittels des Authentisierungsnachweises authentifiziert
werden. Nach 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. Nach einer Ausführungsform kann jedem Client
eines Space seine eigene Menge von Leistungsmerkmalen zur Nutzung
des Space zugewiesen werden. Nach 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. Nach 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. Nach einer Ausführungsform
kann jeder Client-Space-Verbindung eine eindeutige Sitzungs-ID zugewiesen
werden. Nach 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. Nach einer Ausführungsform kann ein Aktivierungsspace
verwendet werden, um Ergebnisse von Diensten für den Client zu speichern,
wenn er den Space verwendet. Nach 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. Nach 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. Nach 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. Nach einer Ausführungsform
kann es erforderlich sein, daß der
Client den Verbindungsvorgang wiederholt.
-
Nach
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.
Nach 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.
-
Nach
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.
-
Nach
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. Nach einer Ausführungsform
können
Space-Dienste in der verteilten Rechnerumgebung das Multicast Announcement
Protocol (mutticast 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. Nach 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.
-
Nach
einer Ausführungsform
kann das Auffindungsprotokoll für
Spaces der verteilten Rechnerumgebung einen Satz von XML-Nachrichten
und ihre Antworten definieren, die dem Client 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 Wegen 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.
-
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. Nach 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 Internetsuchen 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). Nach 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.
Nach 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. Nach 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
nach 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.
-
Nach
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 nach 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.
-
Nach
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. Nach 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. Nach 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 erweiterten XML-Schema für den Space, der die Schnittstellen
für Dauerhaftigkeit
definiert, spezifiziert werden.
-
Nach
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. Nach 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. Nach 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 Eintrags überprüfen, bevor er das Hinzufügen des
Eintrags erlaubt. Zum Beispiel kann jeder Eintrag, der zu einem
Space hinzugefügt
wird, einer benutzerspezifischen Zeichenkette zugeordnet werden,
die den Eintrag identifiziert und die verwendet werden kann, um
die Eindeutigkeit des Eintrags zu überprüfen.
-
Nach
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. Nach einer Ausführungsform
kann eine Space-Funktion einen Mechanismus bereitstellen, um einen
Space-Eintrag durchzusehen, der 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. Nach 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. Nach
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.
-
Nach
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.
Nach 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. Nach 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. Nach einer Ausführungsform kann ein Ereignis
ein XML-Dokument sein, das auf ein anderes XML-Dokument verweist.
-
Nach
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. Nach einer Ausführungsform kann eine Ereignisanmeldung
mittels eines Überlassungs-
bzw. Pachtmechanismus, der an anderer Stelle beschrieben wird, überlassen
bzw. gepachtet werden. Nach einer Ausführungsform kann eine Anmeldung
gestrichen werden, wenn die Überlassung
gestrichen wird oder erlischt. Nach einer Ausführungsform kann das Erneuern
der Überlassung
einer Anmeldung eine Anmeldung erneuern.
-
Nach
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. Nach 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. Nach 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.
-
43 ist ein Flußdiagramm, welches eine Suche
nach Spaces veranschaulicht, die einen Suchdienst in einer verteilten
Rechnerumgebung gemäß einer
Ausführungsform
verwendet. In einer Ausführungsform kann
ein Client auf einer Einrichtung mit einem Suchdienst auf derselben
oder einer anderen Einrichtung in Kontakt bzw. Wechselwirkung treten,
um Spaces zu finden (d.h. Ablagen von Objekten, die über das
Netzwerk zugänglich
sind) für
eine Speicherung oder Wiedergewinnung von Daten. Ausführungsformen
dieser Interaktion sind in den 46a und 46b noch weiter dargestellt. Der Client 110 kann
eine Suchanforderung an den Suchdienst 2102 senden, wie
es bei 2000 angezeigt ist. Die Suchanfrage kann eine oder
mehrere gewünschte
Eigenschaften enthalten, die in bzw. aus einem Space gesucht werden.
In einer Ausführungsform wird
die Suchanfrage in einer Datenrepräsentationssprache ausgedrückt, wie
z.B. der erweiterbaren Kennzeichnungssprache (Extensible Markup-Language – XML).
In einer Ausführungsform
können
die gewünschten Eigenschaften
in der Suchanfrage ein oder mehrere Stichworte enthalten. Der Client
kann ein Programm 2100 einbeziehen, welches die Kennworte
akzeptiert und sie an den Suchdienst 2102 sendet. In einer
Ausführungsform
können
die Stichworte als XML-Nachrichten 2106 und/oder durch
Verwendung von Zugängen
gesendet werden, wie es hier beschrieben wird.
-
Auf
der Grundlage der Suchanfrage kann der Suchdienst 2102 eine
Suche durchführen.
In einer in 46a dargestellten Ausführungsform
kann der Suchdienst 2102 beim Durchführen der Suche mit einer Suchmaschine 2104,
wie z.B. einer Internetsuchmaschine, zusammenarbeiten. Auf diese
Weise kann der Suchdienst als ein Proxy (Server) zwischen dem Client
und der Suchmaschine wirken. Ein Proxy kann insbesondere für einen
Client in einer kleinen Einrichtung wünschenswert sein, der nicht
die Ressourcen hat, um mit der Suchmaschine in Interaktion zu treten,
wie z.B. durch Verwenden eines Webbrowsers oder durch Empfang eines
vollständigen
Satzes von Suchergebnissen. Die Suchmaschine kann eine über das
Netzwerk zugängliche
Suchmaschine eines Dritten aufweisen, wie z.B. eine über einen
Browser zugängliche
Internetsuchmaschine. In einer in 46b dargestellten
Ausführungsform
kann der Suchdienst 2102 die Suchmaschine 2104 enthalten
oder in sonstiger Weise eng mit dieser verbunden sein. Der Suchdienst 2102 kann
die Suchanfrage aus der Datendarstellungssprache (beispielsweise
XML) in ein Textformat übersetzen,
welches von der Suchmaschine 2104 verwendet werden kann,
wie es bei 2002 angedeutet wird. Der Suchdienst 2102 kann
dann die übersetzte
Suchanfrage an die Suchmaschine 2104 senden, wie es bei
2004 angedeutet ist.
-
Wie
bei 2006 angegeben, kann die Suche durch die Suchmaschine 2104 ausgeführt werden,
um Suchergebnisse zu erzeugen. Die Suchergebnisse können Orte
bzw. Positionen (beispielsweise URIs) eines oder mehrerer resultierender
Spaces, wie z.B. 2120a, 2120b und 2120c enthalten.
In einer Ausführungsform können die
Spaces eine oder mehrere Webseiten erhalten, die über das
Internet 2110 zugänglich
sind. Die Webseiten können
ein kennzeichnendes Stichwort enthalten, welches die Webseiten als
Spaces in der verteilten Rechnerumgebung identifiziert. Die Suchanfrage
kann dieses Stichwort zusammen mit einem oder mehreren weiteren
Stichworten enthalten, welche die Eigenschaften beschreiben, die
für die
Spaces gewünscht werden.
-
Wie
bei 2008 gezeigt, kann der Suchdienst 2102 die
Suchergebnisse von der Suchmaschine 2104 im Textformat
erhalten. Der Suchdienst 2102 kann dann die Suchergebnisse
im Textformat in Suchergebnisse in der Datendarstellungssprache
(beispielsweise XML) übersetzen
und die Ergebnisse an den Client 110 senden, wie es bei 2010 angezeigt
wird. In einer Ausführungsform
kann der Suchdienst 2102 eine Annonce des Dienstes für jeden
der resultierenden Spaces 2120a, 2120b und 2120c erhalten.
Jede Dienstannonce enthält
Information, die verwendbar ist, um auf den entsprechenden Space
zuzugreifen. Der Suchdienst 2102 kann Referenzen bzw. Hinweise
(beispielsweise einheitliche Ressourcenkennungen) dieser Annoncen
oder die Annoncen selbst als Suchergebnisse senden, um den Client
in die Lage zu versetzen, auf die resultierenden Spaces an ihren
jeweiligen Orten zuzugreifen, wie es bei 2012 angezeigt
wird. In einer Ausführungsform
können
die Positionen der resultierenden Spaces einheitliche Ressourcenkennungen
(URIs) enthalten.
-
In
einer Ausführungsform
kann der Suchdienst 2102 beim Senden der Suchergebnisse
an den Client 110 die Suchergebnisse in einem Ergebnisspace
(beispielsweise einer über
das Netzwerk zugänglichen
Speicherablage) speichern und die Adresse des Ergebnisspace an den
Client 110 senden. Der Client 110 kann dann zu
gegebener Zeit auf die Suchergebnisse in dem Ergebnisspace zugreifen.
Die Verwendung eines Ergebnisspace kann insbesondere für einen
kleinen Client wünschenswert
sein, der nicht die Ressourcen besitzt, um einen vollen Satz von
Ergebnissen zu empfangen und anzuzeigen. In dieser Situation kann
der Benutzer die Ergebnisse aus dem Ergebnisspace lesen, indem er
gemäß einer
Ausführungsform
einen anderen Client verwendet.
-
In
einigen Ausführungsformen
kann ein Suchdienst Spaces begrenzen oder filtern, die durch den Suchdienst
gefunden werden, oder Clients auf das Suchen nur weniger unterstützter Spaces
innerhalb der verteilten Rechnerumgebung beschränken. Das Ausmaß der erlaubten
Suche kann entsprechend der Authentisierung bzw. Berechtigung des
Client bestimmt werden.
-
47 ist ein Flußdiagramm, welches eine Suche
nach Dokumenten innerhalb eines Space in einer verteilten Rechnerumgebung
gemäß einer
Ausführungsform
zeigt. In einer Ausführungsform
kann ein Client mit einem Space über
Nachschlagenachrichten in Interaktion treten, um Dokumente innerhalb
des Space zu finden. Ein Client kann eine Nachschlagenachricht an
einen Space senden, wie es bei 2200 angezeigt wird. Der
Space kann eine netzwerkadressierbare Speicherstelle aufweisen,
die so betreibbar ist, daß sie
eines oder mehrere Dokumente speichert. Die gespeicherten Dokumente
können
in einer Datendarstellungssprache, wie z.B. der erweiterbaren Kennzeichnungssprache
(Extensible Markup-Language – XML)
ausgedrückt
werden. Die Nachschlagenachricht kann gewünschte Eigenschaften der gespeicherten
Dokumente angeben. In einer Ausführungsform
können
die Dokumente XML-Dienstannoncen und XML-Einrichtungsannoncen ebenso wie XML-Vielzweckdokumente
enthalten. Beispielsweise können
die XML-Dokumente in dem Space die Ergebnisse eines Dienstes enthalten,
wie sie in XML ausgedrückt
werden.
-
Ein
Satz von Dokumenten, der zu der Nachschlagenachricht paßt, kann
entdeckt werden, wie es bei 2202 angezeigt ist. Die gefundenen
Dokumente können
irgendwelche gespeicherten Dokumente enthalten, die die gewünschten
Eigenschaften erfüllen,
die in der Nachschlagenachricht spezifiziert sind. Keines oder auch
mehrere gespeicherte Dokumente können
die gewünschten
Eigenschaften erfüllen.
In einer Ausführungsform
kann die Nachschlagenachricht einen gewünschten Namen enthalten. In
einer Ausführungsform kann
der in der Nachschlagenachricht spezifizierte, gewünschte Name
eine oder mehrere Wildcards bzw. Platzhalter enthalten. Jedes der
gefundenen Dokumente kann dann einen Namen haben, der mit dem gewünschten
Namen übereinstimmt
und die Namen können
die gefundenen Dokumente innerhalb des Space kennzeichnen. In einer
Ausführungsform
kann die Nachschlagenachricht ein gewünschtes Schema enthalten, welches
in der Datendarstellungssprache ausgedrückt wird. Jedes der gefundenen
Dokumente kann ein Schema oder einen Teil eines Schemas haben, welches
mit dem gewünschten
Schema übereinstimmt.
In einer Ausführungsform
kann die Nachschlagenachricht sowohl einen gewünschten Namen als auch ein
gewünschtes Schema
enthalten. In diesem Fall kann der Satz von gefundenen Dokumenten
sowohl gefundene Dokumente enthalten, die einen Namen haben, der
mit dem gewünschten
Namen übereinstimmt,
als auch gefundene Dokumente, die ein Schema haben, welches mit
dem gewünschten
Schema übereinstimmt.
In einer Ausführungsform
kann die Nachschlagenachricht weder einen gewünschten Namen noch ein gewünschtes
Schema enthalten. In diesem Fall ist die Nachschlagenachricht letztlich
eine Anfrage nach sämtlichen
Dokumenten in dem Space und der Satz der gefundenen Dokumente kann
im wesentlichen sämtliche
Dokumente enthalten, die in dem Space gespeichert sind.
-
Nachdem
passende Dokumente gefunden wurden, kann der Space eine Nachschlageantwortnachricht
an den Client senden, wie es bei 2204 angezeigt wird. In
einer Ausführungsform
kann die Nachschlageantwortnachricht die Namen der gefundenen Dokumente
enthalten. In einer Ausführungsform
kann die Nachschlageantwortnachricht eine Annonce für jedes
der null oder mehreren gefundenen Dokumente enthalten. Jede Annonce
kann Information enthalten, die für den Client verwendbar ist,
um das entsprechende, gefundene Dokument zu erhalten oder auf die
Ressource bzw. Quelle (beispielsweise einen Dienst) zuzugreifen, welche
das Dokument anzeigt. In einer Ausführungsform kann jede Annonce
eine gleichförmige
Ressourcenkennung (URI) enthalten, bei welcher das entsprechende
gefundene Dokument (oder die Quelle, wie z.B. ein Dienst, der durch
das Dokument angezeigt wird) zugänglich
ist. In einer Ausführungsform
kann das zumindest eine der gefundenen Dokumente eine Annonce für einen
Dienst sein. Die Annonce für
den Dienst kann ein Schema enthalten, wobei das Schema eine oder
mehrere Nachrichten spezifiziert, die verwendbar sind, um eine oder
mehrere Funktionen des Dienstes aufzurufen. Die Annoncen können in
der Datendarstellungssprache, wie z.B. XML, ausgedrückt werden.
-
In
einer Ausführungsform
werden die Nachschlagenachricht und die Nachschlageantwortnachricht
in einer Datendarstellungssprache, wie z.B. XML, ausgedrückt. Ein
Schema für
den Space kann die Form der Nachschlagenachricht und der Nachschlageantwortnachricht
spezifizieren. In einer Ausführungsform
kann dieses Paar von Nachrichten folgendermaßen in XML ausgedrückt werden.
-
-
In
der XML-Nachschlagenachricht kann Name den Wert einer Zeichenkette
haben und kann eine eindeutige Kennung innerhalb des Space angeben.
Wenn ein Platzhalter bzw. eine Wildcard verwendet wird, so ist die
Kennung mäglicherweise
nicht eindeutig. AncSchema ist ein Schema, zu welchem das Nachschlagen passen
soll. In einer Ausführungsform
sind beide Felder optional. In der XML-Nachschlageantwortnachricht
ist Anc eine Gruppe von null oder mehreren passenden Annoncen und
Namen ist eine Gruppe von Namen, die den Annoncen entsprechen.
-
48 ist ein Flußdiagramm, welches die Adressierung
eines Dienstes unter Verwendung einer Annonce zeigt, die in einem
Space in einer verteilten Rechnerumgebung gemäß einer Ausführungsform
gespeichert ist. In einer Ausführungsform
kann ein Dienst eine Dienstannonce in einem Space veröffentlichen,
wie es bei 2300 angezeigt wird. Der Space kann eine netzwerkadressierbare
Speicherstelle sein, welche Dokumente, wie z.B. Dokumente der erweiterbaren
Markierungssprache (XML-Dokumente) speichert. Das Veröffentlichen
von Annoncen wird genauer an anderer Stelle in dieser Beschreibung
erläutert.
In einer Ausführungsform
kann die Annonce eine einheitliche Ressourcenkennung (URI) enthalten
sowie ein Schema für
den Dienst. Die URI kann eine Netzwerkadresse spezifizieren, unter
welcher auf den Dienst zugegriffen werden kann, und das Schema kann
eine oder mehrere Nachrichten spezifizieren, die verwendbar sind,
um eine oder mehrere Funktionen des Dienstes aufzurufen. In einer
Ausführungsform
können
das Schema und die Nachrichten in einer Datendarstellungssprache,
wie z.B. XML, ausgedrückt
werden. Ein Client kann auf den Space zugreifen und die Annonce
finden, wie es bei 2302 angezeigt wird. Beispielsweise
kann der Client einen Suchdienst verwenden, um den Space zu finden
und dann einen Nachschlagedienst verwenden, um die Annonce innerhalb
des Space zu finden, wie es z.B. durch 47 dargestellt
wird.
-
In
einer Ausführungsform
umfaßt
die Annonce im wesentlichen die gesamte Information, die für den Client
erforderlich ist, um auf den betreffenden Dienst zuzugreifen. Der
Client kann die Annonce aus dem Space lesen, wie bei 2304 angezeigt.
In einer Ausführungsform
kann der Client die URI und das Schema in der Annonce verwenden,
um einen Zugang für
den Zugriff auf den Dienst aufzubauen. Wie bei 2305 angezeigt, kann
der Client eine erste Nachricht an den Dienst unter der URI senden,
wobei die erste Nachricht in dem Schema spezifiziert ist, um eine
oder mehrere Funktionen des Dienstes aufzurufen. In Reaktion darauf
können die
Funktionen) des Dienstes aufgerufen werden, wie es bei 2308 angezeigt
wird. In einer Ausführungsform kann
der Dienst eine zweite Nachricht (beispielsweise eine Nachricht,
welche die Ergebnisse der aufgerufenen Funktionen) enthält) an den
Client senden, wobei die zweite Nachricht in dem Schema für den Dienst
spezifiziert ist.
-
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:
-
-
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, Objekt-orientierten
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.
-
Nach
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.
Nach 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. Nach
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. Nach 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 nach 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. Nach 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
Netzwerkadressen 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. Nach anderen
Ausführungsformen
kann ein Nachschlagedienst 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 benutzen. 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. Nach 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.
-
Nach
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.
-
41 ist ein Flußdiagramm, welches das Besetzen
eines Space in einer verteilten Rechnerumgebung gemäß einer
Ausführungsform
darstellt. Wie bei 1900 angezeigt, kann ein Client auf
einen ersten Dienst eines Space zugreifen (d.h. eine Verbindung
zu diesem herstellen). (Ein Dienst kann für den Zweck des Zugreifens
oder der sonstigen Verwendung eines Space als ein Client wirken.)
Der erste Dienst des Space kann eine oder mehrere Dienstannoncen
und/oder anderen Inhalt in einem ersten Space speichern und jede
der Dienstannoncen kann Information enthalten, die verwendbar ist,
um einen entsprechenden Dienst zuzugreifen und diesen auszuführen. Der
Dienst des ersten Space kann ein erstes Schema enthalten, welches
eine oder mehrere Nachrichten spezifiziert, die verwendbar sind,
um Funktionen des Dienstes des ersten Space aufzurufen. Beispielsweise
kann das erste Schema Verfahren für das Lesen von Annoncen aus
dem ersten Space und das Veröffentlichen
von Annoncen in dem ersten Space spezifizieren. Das erste Schema
und die Dienstannoncen können
in einer Objektdarstellungssprache ausgedrückt werden, wie z.B. in der
erweiterbaren Markierungssprache (XML). Beim Zugreifen auf den Dienst
des ersten Space kann der Client Information, wie z.B. eine XML-Nachricht
(wie es in dem ersten Schema spezifiziert ist), an den Dienst des
ersten Space unter einer ersten Internetadresse (beispielsweise
URI) senden. Beim Zugreifen auf den Dienst des ersten Space kann der
Client die eine oder die mehreren Dienstannoncen suchen, die in
dem ersten Space gespeichert wurden.
-
In
einer Ausführungsform
können
die Spaces eine Einrichtung zum Besetzen neuer Spaces enthalten. Wie
es bei 1902 angezeigt wird, kann die Erzeugung eines zweiten
Space angefordert werden, wie z.B. indem der Client eine geeignete
Anforderung an eine Schnittstelle des ersten Space sendet. In einer
Ausführungsform
kann die Anforderung entsprechend dem ersten Schema für den ersten
Space als eine XML-Nachricht formatiert werden. In Reaktion darauf
kann ein Dienst eines zweiten Space in einem zweiten Space erzeugt werden,
wie z.B. unter einer zweiten Internetadresse (beispielsweise einer
URI), wie es bei 1904 angezeigt wird. Wie oben kann der
Dienst des zweiten Space ein zweites Schema enthalten, welches eine
oder mehrere Nachrichten spezifiziert, die verwendbar sind, um Funktionen
des Dienstes des zweiten Space aufzurufen. Das zweite Schema kann
zumindest das erste Schema umfassen und das zweite Schema kann ebenso
auch zusätzliche
Funktionen beinhalten. In einer Ausführungsform kann das Schema
des zweiten Space einen Teil des ersten Schemas enthalten oder das
zweite Schema kann zum Zeitpunkt der Erzeugung des zweiten Space spezifiziert
werden. Wie bei 1906 angezeigt, kann der Client dann auf
den zweiten Space zugreifen, indem er an den zweiten Space zumindest
eine der in dem zweiten Schema spezifizierten Nachrichten sendet.
Das Besetzen eines Space kann eine Initialisierung der Verwaltung
beinhalten, wie z.B. zur Sicherung. In einer Ausführungsform
ist, wenn ein Anforderer soeben einen Space besetzt hat, anfänglich nur
der Anforderer berechtigt, auf den besetzten Space zuzugreifen.
Ein solches Begrenzen des Zugriffs des besetzten Space kann zweckmäßig sein,
wenn ein Client und ein Dienst den besetzten Space verwenden, um
Ergebnisse zu speichern. Für
weitere Information über
Echtheit und Sicherheit des besetzten Space wird hier auf den Abschnitt Echtheit
und Sicherheit verwiesen. Wenn ein Client einen neuen Space besetzt
hat, so kann er einen Zugang aufbauen, um auf den besetzten Space
zuzugreifen.
-
In
verschiedenen Ausführungsformen
können
daher Ergebnisse an einen Client auf eine Vielzahl von Arten geliefert
werden: beispielsweise in einer Nachricht in einem Space, in einem
Space, wobei dem Client über
ein Ereignis berichtet wird, unter Verwendung einer Annonce, die
in einer Nachricht zurückgeliefert
wird, unter Verwendung einer Annonce, die in einen Space zurückgeliefert
wird, und Verwenden einer Annonce, die in einen Space zurückgeliefert
wird, wobei der Client über
ein Ereignis benachrichtigt wird. Diese verschiedenen Verfahren
des Lieferns von Ergebnissen sind in den 44a bis 44g wiedergegeben. Die Verfügbarkeit dieser Vielzahl von
Methoden kann die Flexibilität
und Anpassungsfähigkeit
der verteilten Rechnerumgebung für
eine Vielfalt von Situationen verbessern, wie z.B. für Clients,
die unterschiedliche Fähigkeiten
bzw. Berechtigungen haben. Für
eine zusätzliche
Flexibilität
können
Ergebnisse auch in effizienter Weise an einen anderen Dienst weitergeleitet
werden, wie es in 45 dargestellt ist.
-
44a ist ein Flußdiagramm, welches ein Verfahren
zum Speichern des Ergebnisses eines Dienstes in einem Space in einer
verteilten Rechnerumgebung gemäß einer
Ausführungsform
zeigt. Wie bei 2050 angezeigt, kann ein Client eine erste
Nachricht an den Dienst senden, um den Aufruf einer oder mehrerer
Funktionen des Dienstes anzufordern. Ein Schema für den Dienst
kann eine Mehrzahl von Nachrichten spezifizieren, einschließlich der
ersten Nachricht, die verwendbar ist, um die Funktionen) des Dienstes
aufzurufen. Die Nachrichten und das Schema können in einer plattformunabhängigen und/oder
programmiersprachenunabhängigen
Datendarstellungssprache, wie z.B. XML, ausgedrückt werden.
-
In
Reaktion auf die erste Nachricht können die Funktionen) des Dienstes
aufgerufen werden, wie es bei 2052 angezeigt wird. Der
Dienst kann dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt. Die
Ergebnisse können
in der Datendarstellungssprache (beispielsweise XML) ausgedrückt werden.
Wie bei 2056 angezeigt, kann der Dienst den Satz von Ergebnissen
an einer Stelle in einem Space speichern, wobei der Space eine netzwerkadressierbare
Speicherstelle aufweist. In einer Ausführungsform kann der Space bei der
Vorbereitung des Speicherns des Satzes von Ergebnissen erzeugt werden.
-
Wie
bei 2058 gezeigt, kann ein Client dann auf den Satz von
Ergebnissen aus dem Space zugreifen und diese lesen. In einer Ausführungsform
kann ein zweiter Client (d.h. ein anderer Client als derjenige,
der die Nachricht für
das Aufrufen der Funktionen) gesendet hat) den Satz von Ergebnissen
aus dem Space lesen. Auf diese Weise kann ein Benutzer einen zweiten
Client benutzen, um Ergebnisse zu lesen und anzuzeigen, wenn der
erste Client möglicherweise
keine ausreichenden Ressourcen hat, um eine solche Aufgabe zu bewerkstelligen.
In einer Ausführungsform
kann der Client eine Nachricht an den Dienst senden, um anzufordern, daß der Dienst
die Adresse des Satzes von Ergebnissen an einen zweiten Dienst weiterleitet,
so daß der
zweite Dienst den Satz von Ergebnissen aus der Adresse in dem Space
lesen kann. Die zweite Nachricht kann eine einheitliche Ressourcenkennung
(URI) einer Annonce für
den zweiten Dienst enthalten, wobei die Annonce für den zweiten
Dienst Information aufweist, die verwendbar ist, um auf den zweiten
Dienst zuzugreifen. Auf diese Weise können die Ergebnisse in effizienter
Weise von dem ersten Dienst an den zweiten Dienst weitergeleitet werden,
ohne daß sie
an den Client weitergeleitet werden müssen.
-
44b ist ein Flußdiagramm, welches ein Verfahren
zum Speichern von Ergebnissen eines Dienstes in einem Space und
das Benachrichtigen eines Client unter Verwendung eines Ereignisses
zeigt, und zwar gemäß einer
Ausführungsform.
Wie bei 2050 angezeigt, kann ein Client eine erste Nachricht
an einen Dienst senden, um einen Aufruf einer oder mehrerer Funktionen
von dem Dienst anzufordern. In Reaktion auf die erste Nachricht
kann bzw. können
die Funktionen) des Dienstes aufgerufen werden, wie es bei 2052 angezeigt
wird. Der Dienst kann dann einen Satz von Ergebnissen erzeugen,
wie es bei 2054 angezeigt wird. Die Ergebnisse können in
der Datendarstellungssprache (beispielsweise XML) ausgedrückt werden.
Wie bei 2056 angezeigt, kann der Dienst den Satz von Ergebnissen
an einer Stelle in einem SpeicherSpace speichern, wobei der SpeicherSpace
eine netzwerkadressierbare Speicherstelle aufweist. Wie bei 2057 angezeigt,
kann ein Ereignis erzeugt und an den Client gesendet werden, um
den Client zu benachrichtigen, daß die Ergebnisse in dem Space
gespeichert sind. Wie bei 2058 angezeigt, kann ein Client
dann in Reaktion auf das Ereignis auf den Satz von Ergebnissen aus
dem Space zugreifen und diesen lesen.
-
44c ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Senden von Ergebnissen eines Dienstes in einer
Nachricht an einen Client zeigt. Wie bei 2050 angezeigt,
kann ein Client eine erste Nachricht an einen Dienst senden, um
den Aufruf einer oder mehrerer Funktionen des Dienstes anzufordern.
In Reaktion auf die erste Nachricht kann bzw. können die Funktionen) des Dienstes
aufgerufen werden, wie es bei 2052 angezeigt wird. Der
Dienst kann dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt.
Die Ergebnisse können
in der Datendarstellungssprache (beispielsweise XML) ausgedrückt werden.
Wie bei 2055 angezeigt, kann der Dienst dann an den Client eine
Nachricht senden, welche die Ergebnisse enthält. Die Nachricht kann in der
Datendarstellungssprache (beispielsweise XML) ausgedrückt werden
und kann in einer Ausführungsform
in dem Schema für
den Dienst spezifiziert werden.
-
44d ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Liefern von Ergebnissen eines Dienstes unter Verwendung
einer Annonce veranschaulicht. Wie bei 2050 angezeigt,
kann ein Client eine erste Nachricht an einen Dienst senden, um
den Aufruf einer oder mehrerer Funktionen des Dienstes anzufordern.
In Reaktion auf die erste Nachricht kann bzw. können die Funktionen) des Dienstes
aufgerufen werden, wie bei 2052 angezeigt. Der Dienst kann
dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt.
Die Ergebnisse können
in der Datendarstellungssprache (beispielsweise XML) ausgedrückt werden.
In einer Ausführungsform
kann der Dienst den Satz von Ergebnissen an einer Stelle bzw. einem
Ort in einem Speicher speichern, wobei der Space eine netzwerkadressierbare
Speicherstelle aufweist. Wie bei 2060 angezeigt, kann der
Dienst eine Annonce für
die Ergebnisse erzeugen. Die Annonce kann Information enthalten,
die verwendbar ist, um auf die Ergebnisse zuzugreifen und diese
zu lesen, wie z.B. aus dem Space. Beispielsweise kann die Annonce
eine einheitliche Ressourcenkennung (URI) enthalten, unter welcher
auf die Ergebnisse zugegriffen werden kann. In einer Ausführungsform
kann die Annonce ein Schema (beispielsweise ein XML-Schema) enthalten,
welches ein Format der Ergebnisse spezifiziert. In einer Ausführungsform
kann die Annonce in einer Datendarstellungssprache, wie z.B. XML,
ausgedrückt
werden. Wie es bei 2068 angezeigt wird, kann der Client
dann unter Verwendung der Annonce auf den Satz von Ergebnissen zugreifen
und diesen lesen. In einer Ausführungsform
kann ein zweiter Client (d.h. ein anderer Client als derjenige,
welcher die Nachricht für
das Aufrufen der Funktionen) gesendet hat) die Ergebnisse unter
Verwendung der Annonce lesen.
-
44e ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Liefern von Ergebnissen eines Dienstes zeigt,
der eine in einer Nachricht an einen Client gesendete Annonce verwendet. Wie
bei 2050 angezeigt, kann ein Client eine erste Nachricht
an einen Dienst senden, um das Aufrufen einer oder mehrerer Funktionen
des Dienstes anzufordern. In Reaktion auf die erste Nachricht kann
bzw. können die
Funktionen) des Dienstes aufgerufen werden, wie bei 2052 angezeigt.
Der Dienst kann dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt.
Die Ergebnisse können
in der Datendarstellungssprache (beispielsweise XML) dargestellt
werden. In einer Ausführungsform
kann der Dienst den Satz von Ergebnissen an einem Ort in einem Space
speichern, wobei der Space über
ein Netzwerk adressierbare Speicherstellen bzw. -orte aufweist.
Wie bei 2060 angezeigt, kann der Dienst eine Annonce für die Ergebnisse
erzeugen. Die Annonce kann Information enthalten, welche verwendbar
ist, um auf die Ergebnisse zuzugreifen und diese zu lesen, wie z.B.
von dem Space. Beispielsweise kann die Annonce eine einheitliche
Ressourcenkennung (URI) enthalten, unter welcher auf die Ergebnisse
zugegriffen werden kann. In einer Ausführungsform kann die Annonce
ein Schema (beispielsweise ein XML-Schema) enthalten, welches ein
Format der Ergebnisse spezifiziert. In einer Ausführungsform
kann die Annonce in einer Datendarstellungssprache, wie z.B. XML,
ausgedrückt
werden. Wie bei 2061 angezeigt, kann der Dienst eine Nachricht
einschließlich
der Annonce an den Client senden. Die Nachricht kann ausgedrückt werden
in der Datendarstellungssprache (z.B. XML) und kann in einer Ausführungsform
in dem Schema für
den Dienst spezifiziert werden. Wie bei 2068 angezeigt,
kann ein Client dann unter Verwendung der Annonce auf den Satz von
Ergebnissen zugreifen und diesen lesen.
-
44f ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Liefern von Ergebnissen eines Dienstes unter Verwendung
einer in einem Space gespeicherten Annonce. Wie bei 2050 angezeigt,
kann ein Client eine erste Nachricht an einen Dienst senden, um
den Aufruf von einer oder mehreren Funktionen des Dienstes anzufordern.
In Reaktion auf die erste Nachricht kann bzw. können die Funktionen) des Dienstes
aufgerufen werden, wie bei 2052 angezeigt. Der Dienst kann
dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt.
Die Ergebnisse können
in der Datendarstellungssprache (beispielsweise XML) ausgedrückt werden.
In einer Ausführungsform
kann der Dienst den Satz von Ergebnissen an einer Stelle in einem
Space speichern, wobei der SpeicherSpace netzwerkadressierbare Speicherstellen
aufweist. Wie bei 2056 angezeigt, kann der Dienst den Satz
von Ergebnissen an einer Stelle in einem Space speichern, wobei
der Space netzwerkadressierbare Speicherstellen aufweist. Wie bei 2060 angezeigt,
kann der Dienst eine Annonce für
die Ergebnisse erzeugen. Die Annonce kann Information enthalten,
die verwendbar ist, um auf die Daten zuzugreifen und diese zu lesen,
wie z.B. aus dem Space. Beispielsweise kann die Annonce eine einheitliche
Ressourcenkennung (URI) enthalten, unter welcher die Ergebnisse
zugänglich
sind. In einer Ausführungsform
kann die Annonce ein Schema (beispielsweise ein XML-Schema) enthalten,
welches ein Format der Ergebnisse spezifiziert. In einer Ausführungsform
kann die Annonce in einer Datendarstellungssprache, wie z.B. XML,
ausgedrückt
werden. Wie bei 2062 angezeigt, kann die Annonce in einem Space
gespeichert werden. Der Space kann derselbe sein oder auch ein anderer
als der, in welchem die Ergebnisse gemäß 2056 gespeichert
wurden. Ein Client kann die Annonce aus dem Space lesen, wie bei 2066 angezeigt. In
einer Ausführungsform
kann ein zweiter Client (d.h. ein Client, der sich von demjenigen,
welcher die Nachricht zum Aufrufen der Funktionen) gesendet hat,
verschieden ist) die Annonce aus dem Space lesen. Wie bei 2068 angezeigt,
kann der Client dann unter Verwendung der Annonce auf den Satz von
Ergebnissen aus dem Space zugreifen und diesen lesen.
-
44g ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Liefern von Ergebnissen eines Dienstes zeigt,
unter Verwendung einer Annonce, die in einem Space gespeichert ist
und unter Benachrichtigung eines Client unter Verwendung eines Ereignisses.
Wie bei 2050 angezeigt, kann ein Client eine erste Nachricht
an einen Dienst senden, um den Aufruf von einer oder mehreren Funktionen
des Dienstes anzufordern. In Reaktion auf die erste Nachricht kann
bzw. können
die Funktionen) des Dienstes aufgerufen werden, wie bei 2052 angezeigt.
Der Dienst kann dann einen Satz von Ergebnissen erzeugen, wie bei 2054 angezeigt.
Die Ergebnisse können
in der Datenrepräsentationssprache
(beispielsweise XML) ausgedrückt
werden. In einer Ausführungsform
kann der Dienst den Satz von Ergebnissen an einer Stelle in einem Space
speichern, wobei der Space netzwerkadressierbare Speicherstellen
aufweist. Wie bei 2056 angezeigt, kann der Dienst den Satz
von Ergebnissen an einer Stelle in einem Space speichern, wobei
der Space netzwerkadressierbare Speicherstellen aufweist. Wie bei 2060 angezeigt,
kann der Dienst eine Annonce für
die Ergebnisse erzeugen. Die Annonce kann Information enthalten,
welche verwendbar ist, um auf die Ergebnisse zuzugreifen und diese
zu lesen, wie z.B. aus dem Space. Beispielsweise kann die Annonce
eine einheitliche Ressourcenkennung (URI) enthalten, unter welcher
auf die Ergebnisse zugegriffen werden kann. In einer Ausführungsform
kann die Annonce ein Schema (beispielsweise XML-Schema) enthalten,
welches ein Format der Ergebnisse spezifiziert. In einer Ausführungsform
kann die Annonce in einer Datendarstellungssprache, wie z.B. XML,
ausgedrückt
werden. Wie bei 2062 angezeigt, kann die Annonce in einem Space
gespeichert werden. Der Space kann derselbe sein wie derjenige,
in welchem die Ergebnisse gemäß 2056 gespeichert
wurden oder kann von diesem verschieden sein. Wie bei 2064 angezeigt,
kann ein Ereignis erzeugt und an den Client gesendet werden, um
den Client zu benachrichtigen, daß die Annonce der Ergebnisse
in dem Space gespeichert ist. Der Client kann die Annonce aus dem
Space lesen, wie bei 2066 angezeigt. Wie bei 2068 angezeigt, kann
der Client dann unter Verwendung der Annonce auf den Satz von Ergebnissen
aus dem Space zugreifen und diesen lesen.
-
45 ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
ein Verfahren zum Senden von Ergebnissen eines Dienstes zu einem
anderen Dienst in einer verteilten Rechnerumgebung zeigt. Wie bei 2070 angezeigt,
kann ein Client eine erste Nachricht an einen ersten Dienst senden,
um den Aufruf einer oder mehrerer Funktionen des Dienstes anzufordern
und auch die Weiterleitung der Ergebnisse der Funktionen an einen
zweiten Dienst anzufordern. Ein Schema für den ersten Dienst kann eine
Mehrzahl von Nachrichten spezifizieren, einschließlich der
ersten Nachricht, welche verwendbar sind, um die Funktionen des
ersten Dienstes aufzurufen. Die Nachrichten und das Schema können in
einer plattformunabhängigen
Datendarstellungssprache, wie z.B. XML, ausgedrückt werden. In einer Ausführungsform
kann die erste Nachricht eine einheitliche Ressourcenkennung (URI)
einer Annonce für
den zweiten Dienst erhalten, wobei die Annonce für den zweiten Dienst Information
aufweist, die verwendbar ist, um auf den zweiten Dienst zuzugreifen.
-
In
Reaktion auf die erste Nachricht können die Funktionen des ersten
Dienstes aufgerufen werden, wie bei 2072 angezeigt. Der
erste Dienst kann dann einen Satz von Ergebnissen erzeugen, wie
bei 2074 angezeigt. Die Ergebnisse können ausgedrückt werden
in der Datendarstellungssprache (beispielsweise XML). Wie bei 2076 angezeigt,
kann der erste Dienst die Ergebnisse in einer Nachricht an den zweiten
Dienst senden, ohne die Ergebnisse direkt an den Client zu senden.
Auf diese Weise können
die Ergebnisse in effizienter Weise von dem ersten Dienst zu dem
zweiten Dienst weitergeleitet werden, ohne daß sie zu dem Client geleitet werden.
-
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. Nach einer Ausführungsform kann die Instantiierung
eines Objektes das Erzeugen oder Abspalten eines Ergebnis-Space
beinhalten. Nach 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,
Einträge
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.
Nach 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.
-
Nach
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. Nach 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.
Nach 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
Einichtung 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 Einichtung beim Aufbau einer Verbindung
an die veröffentlichende
Einrichtung gesendet werden, wie oben beschrieben. Nach 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öffentlichenden
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. Nach 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. Nach 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. Nach 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. Nach
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)).
Nach 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. Nach einer Ausführungsform
kann ein Wert von –1
verwendet werden, um eine unbestimmte Überlassung anzugeben.
-
Nach
einer Ausführungsform
kann eine Dienstannonce eine oder mehrere Überlassungsadressen beinhalten.
Nach 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 Überlassungen
für Ressourcen
des Dienstes beinhalten. Nach 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. Nach 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).
Nach 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.
Nach 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.
-
Nach
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 Erneuerungsnachrichten
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.
-
Erneuerungsnachrichten
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. Nach einer Ausführungsform kann das Gatter
es Clients ermöglichen,
eine Behandlungsroutine für Überlassungsereignisse
zu registrieren, um verschiedene Isolationsstufen in der Antwortnachricht
anzugeben.
-
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. Nach 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.
-
Nach
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.
-
Nach
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-Schicht implementiert
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 dauerhaftem
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
Inhaltsannoncen 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 Leistungsmerkmale
ankündigen
bzw. bekanntmachen. Clients können
sich innerhalb derselben Netzwerkeinrichtung 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 Inhalt
und Nachrichtenendpunkten gibt der verteilten Rechnerumgebung ein
leistungsstarkes 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. Einträge, 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 Eintrag erlaubt wird als auch welche Operationen
autorisierte Clients auf diesem Eintrag durchführen dürfen.
-
Der
hohe Grad von Zugriff, der durch die verteilte Rechnerumgebung bereitgestellt
wird, kann durch geeignete Authentisierung und Sicherheitssysteme
und -verfahren kontrolliert werden. Authentisierung und Sicherheit
in der verteilten Rechnerumgebung kann umfassen, ist jedoch nicht
beschränkt
auf: Überprüfen der Richtigkeit
der Typen von XML-Inhalt 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 realisiert
werden. Die unteilbare Einheit von Code und Daten kann dynamisch
erzeugt werden. Nach 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
möglicherweise
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 Nachrichtenendpunkt 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. Nach 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. Nach 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. Nach 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.
-
Nach
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. Nach 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.
Nach 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. Nach einer Ausführungsform
ist ein Authentisierungsnachweis ein nicht-durchsichtiges Objekt,
das jedesmal vorgewiesen werden muß, wenn ein Client einen Dienst
benutzt. Nach 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 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.
Nach 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. Nach 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.
-
Nach
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. Nach 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 einen) 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. Nach einer Ausführungsform
kann der Dienst jegliche Authentisierungsrichtlinie zu seiner Verfügung verwenden.
Nach einer Ausführungsform
kann der Authentisierungsdienst die Authentisierungsrichtlinie im
Namen des Dienstes administrieren, 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
Eintrag (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 Gatererzeugung können
sicherstellen, daß ein
Client die Berechtigung hat, einige oder alle Leistungsmerkmale
des Dienstes zu benutzen, die durch das XML-Nachrichtenschema bestimmt
sind. Nach 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.
-
Nach
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.
Nach 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 Hardwarebasiertes
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. Nach 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. Nach 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.
-
42 ist ein Flußdiagramm, welches gemäß einer
Ausführungsform
das sichere Besetzen eines neuen Space in einer verteilten Rechnerumgebung
veranschaulicht. Wie bei 1950 angezeigt, kann ein Client auf
einen Dienst eines ersten Space zugreifen (z.B. eine Verbindung
zu diesem herstellen). (Ein Dienst kann für den Zweck des Zugriffs auf
einen Space oder der sonstigen Verwendung eines Space als ein Client
wirken.) Wie bei 1952 angezeigt, kann die Erzeugung eines
zweiten Space angefordert werden, wie z.B. dadurch, daß der Client
eine passende Anforderung an eine Schnittstelle des ersten Space
sendet. Ein Client (einschließlich eines
Dienstes, der als Client des Dienstes eines Space wirkt), welcher
die Erzeugung des Space anfordert, kann als der anfordernde Client
bezeichnet werden. In Reaktion darauf kann ein Dienst eines zweiten
Space mit einem zweiten Space an einer zweiten Internetadresse erzeugt
werden, wie bei 1954 angezeigt. Wie oben kann der Dienst
des zweiten Space ein zweites Schema enthalten, welches eine oder
mehrere Nachrichten spezifiziert, die verwendbar sind, um Funktionen
des Dienstes des zweiten Space aufzurufen. Das zweite Schema kann
zumindest das erste Schema enthalten und das zweite Schema kann
ebenso auch zusätzliche Funktionen
enthalten.
-
Der
zweite Space kann zunächst
so ausgestaltet sein, daß er
einen Zugriff nur für
den anfordernden Client gewährt.
In einer Ausführungsform
wird, wie bei 1956 angezeigt, ein grundlegendes Echtheitstoken
für den
zweiten Space erzeugt. Wie ebenfalls bei 1956 angezeigt,
kann der Echtheitsdienst, der zu dem zweiten Space gehört, initialisiert
werden, wodurch der zweite Space so konfiguriert wird, daß er nur
einem Client Zugang gewährt,
welcher das grundlegende Echtheitstoken hält. Wie bei 1958 angezeigt,
kann das grundlegende Echtheitstoken an den anfordernden Client
oder Dienst gesendet werden. Wie bei 1960 angezeigt, kann
der anfordernde Client dann auf den zweiten Space zugreifen, indem
er zumindest eine der Nachrichten, die in dem zweiten Schema spezifiziert
sind, und indem er das grundlegende Echtheitstoken verwendet, an
den zweiten Space sendet.
-
In
einer Ausführungsform
wird es daher, wenn ein Anforderer einen Space besetzt hat, nur
dem Anforderer erlaubt, auf den besetzten Space zuzugreifen. Beispielsweise
kann der besetzte Space für
das Speichern von Ergebnissen aus einem Dienst vorgesehen sein,
die der Client in gesicherter Form halten muß. In einer Ausführungsform
kann diese Sicherheit folgendermaßen sichergestellt werden:
-
Wie
bei 1956 angezeigt, wird ein ursprüngliches, grundlegendes Echtheitstoken
erzeugt und der Echtheitsdienst des besetzten Space wird initialisiert,
so daß der
Echtheitsdienst nur das grundlegende Echtheitstoken als echt erklärt und so
daß er
keine anderen Echtheitstoken liefert (anfänglich werden keine anderen Clients
für den
besetzten Space zugelassen).
-
Initialisieren
von Sicherheitspolicen des besetzten Space, so daß die Basisidentität, die zu
dem grundlegenden Echtheitstoken gehört, Zugriff auf alle Einrichtungen
des Space hat, einschließlich
der Sicherheitsverwaltungseinrichtungen.
-
Wie
bei 1958 angezeigt, Liefern bzw. Rückgabe des grundlegenden Echtheitstokens
und der Dienstannonce des besetzten Space an den Anforderer des
besetzten 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. Nach 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 Rechnenumgebung 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 Rechnerumgebung 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.
-
Figur 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. Nach 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. Nach 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. Nach 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.
-
Nach
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. Nach einer Ausführungsform
wird das Nachrichtengatter des Client von einer Gattenfabrik 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 Authentisierungsnachweis erstellen
kann, weiß der
Dienst, daß der
Client den Authentisierungsnachweis nicht gefälscht hat. Nach 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.
-
Nach
einer Ausführungsform
kann ein Dienst einen vorab bereitgestellten Berechtigungsnachweis
haben, den alle Clients des Dienstes benutzen sollen. Nach 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. Nach einer Ausführungsform
kann der Client nach einer Dienstannonce für den gewünschten Dienst suchen und sie
lokalisieren. Nach einer Ausführungsform
kann die Dienstannonce eine Annonce für den Authentisierungsdienst
enthalten, der zum Erhalt eines Authentisienungsnachweises zu verwenden
ist, der beim Zugriff auf den Dienst zu benutzen ist. Nach einer
Ausführungsform
kann die Dienstannonce eine Adresse wie einen URI für den Authentisierungsdienst
beinhalten. Nach einer Ausführungsform
kann der Client Information an den Authentisierungsdienst senden,
die den Authentisierungsnachweis anfordert. Nach 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. Nach 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.
Nach einer Ausführungsform
kann der Authentisierungsnachweis direkt an den Client zurückgeliefert
werden. Nach einer Ausführungsform
kann der Authentisierungsnachweis an einen Prozeß zur Gattererzeugung, zum
Beispiel eine Gatterfabrik, zurückgeliefert
werden, der daraufhin den Authentisierungsnachweis beim Erzeugen
eines Gatters verwenden kann.
-
Figur 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
nach einer Ausführungsform
ein Client-Token
und ein Dienst-Token erhalten. Nach einer anderen Ausführungsform
kann der Authentisierungsdienst nur ein Client-Token erhalten. Nach
einer Ausführungsform
kann das Client-Token
ein eindeutiger Bezeichner für
den Client in der verteilten Rechnerumgebung sein. Nach 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. Nach 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.
Nach 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. Nach
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. Nach 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. Nach 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. Nach
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.
Nach 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. Nach einer Ausführungsform
kann der Authentisierungsnachweis ein Authentisierungstoken enthalten,
das nur der Authentisierungsdienst erzeugen kann. Nach einer Ausführungsform
kann der Authentisierungsdienst das Client-Token und das Dienst-Token
beim Erzeugen des Authentisierungsnachweises verwenden. Nach 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. Nach 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.
-
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 bilden, 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.
-
Nach
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
gespeichert 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. Nach 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.
-
Nach
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. Nach 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. Nach einer Ausführungsform
kann es Jini-Dienste geben, für
die es keine Brücke
zu der verteilten Rechnerumgebung gibt.
-
Nach
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
verwendet 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. Nach 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. Nach 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.
-
Nach
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.
Nach 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.
-
Nach
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. Nach 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 Überbrü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. Nach 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 Regierungseinheit 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 objekt-orientierten 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.
-
Anzeigen beim Client
-
Es
gibt einige Verfahren, wie 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
letzten 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 Dienstannonce 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 Anzeige
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. Nach 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.
Nach anderen Ausführungsformen
können
Nachrichten 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.
Nach 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).
-
Nach
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 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.
-
Nach
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 (Zeichenkette1 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-Bibliothekfunktionen
strcpy() oder strncpy() behandelt, die implementiert sind als:
-
-
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 Zeichenkettenbehandlung, 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), nach einer Ausführungsform
die kleinste Einheit des rekursiv verarbeiteten XML-Dokumentes,
effizient bestimmt werden. Dokumente mit wiederholten 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 Javaspezifische 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.
Nach 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. Nach einer Ausführungsform
kann ein Objekt 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. Nach 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. Nach 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.
-
Nach
einer anderen Ausführungsform
können
die Gatter für
das Kompilieren und Dekompilieren der Java-Objekte verantwortlich
sein. Nach 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.
-
Nach
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. Nach 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. Nach 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.
-
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-AP1 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.
-
Nach
einer Ausführungsform
können
der JVM-XML-Compiler und -Decompiler als integrierte Funktionen
der JVM implementiert sein. Nach 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.
Nach 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 durchgefü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.
Nach einer Ausführungsform
kann ein Objekt durch einen einzigen Aufruf des JVM-XML-Compiler-/Decompiler-API
kompiliert oder dekompiliert werden.
-
Nach
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. Nach 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. Nach 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. Nach 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.
-
Nach
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 Objektsignatur 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. Nach einer Ausführungsform kann die das Objekt
beschreibende Information in einem oder mehreren XML-Tags gespeichert
werden. Nach 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.
-
Nach
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. Nach 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 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.
-
Sicherheitsprobleme 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.
-
Nach
einer Ausführungsform
kann ein Benutzer eines Client auf einer Einrichtung in der verteilten Rechnerumgebung
identifiziert und authentifiziert werden, wenn er das erste Mai
auf den Client zugreift. Nach einer Ausführungsform kann der Benutzer
eine physikalische Identifikation wie eine Smart-Card zur Identifikation
und Autorisierung eingeben. Nach 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.
-
Nach
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. Nach einer Ausführungsform kann eine Sicherheitsausnahmebedingung von
dem XML-Compiler-/Decompiler aufgeworfen werden. Nach 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
Autorisierung 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.
-
Nach
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.
Nach einer Ausführungsform
können
alle durch Dekompilieren erzeugte Objekte gelöscht werden, wenn erkannt wird,
daß der
Benutzer aufgehört
hat. Nach einer anderen Ausführungsform
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.
-
Nach
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-Behälter bzw.
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. Nach 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.
-
Nach
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. Nach 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. Nach 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. Nach 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ühren.
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. Nach 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
-
Nach
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. Nach einer Ausführungsform
kann ein Programm beim Empfang eines XML-Dokumentes eine Klasseninstanz
instantiieren, die dem durch das Dokument dargestellten Objekt entspricht.
Nach einer Ausführungsform
können
die Objekte Java-Objekte
sein, und das Programm kann ein Java-Programm sein.
-
Nach
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. Nach 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.
-
Nach
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.
-
Nach
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. Nach 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.
-
Nach
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
computerbasierte 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.
-
Nach
einer Ausführungsform
kann eine XML-Repräsentation
des Zustandes eines Prozesses, der auf einem Client oder einem Dienst
ausgeführt
wird, erzeugt werden. Nach 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, Objekte und ihre Daten,
etc. Nach 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. Nach 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. Nach einer Ausführungsform
kann ein Autorisierungsnachweis wie eine digitale Unterschrift oder
ein digitaler Berechtigungsnachweise bei dem gespeicherten Zustand
beinhaltet sein, um einen 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.
Nach 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. Nach
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
lassen, vorausgesetzt der Benutzer hat Zugriff auf einen Browser.
Solche 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.
-
Nach
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.
-
Nach
einer Ausführungsform
können
drahtgebundene Verbindungen 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 Verbindung direkt in das Netzwerk "einstöpseln". Beispiele von drahtgebundenen
Verbindungen umfassen, sind jedoch nicht beschränkt auf: Universal Serial Bus
(USB), FireWire und verdrilltes (twisted-pair) Ethernet. Nach einer
Ausführungsform
kann eine Docking Station auch Eingabe-/Ausgabe-Möglichkeiten wie eine Tastatur,
Maus und Anzeige für
die mobile Clienteinrichtung bereitstellen. Nach dieser Ausführungsform
kann der Standort der mobilen Clienteinrichtung dem Such- oder Auffindungsmechanismus
von der Docking Station zur Verfügung
gestellt werden.
-
Nach
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. Nach 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. Nach 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. Nach 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. Nach einer Ausführungsform
kann Information von zwei und mehr Spaces gleichzeitig auf der mobilen
Clienteinrichtung angezeigt werden. Nach 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.
-
Nach
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. Nach 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. Nach 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. Nach 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. Nach 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. Nach
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.
-
Nach
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 mobilen 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. Nach 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.
-
Nach
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. Nach 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.
Nach 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. Nach 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. Nach
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. Nach 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. Nach 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. Nach
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.
Nach 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.
Nach 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. Nach einer Ausführungsform kann der Mechanismus
zur Inanspruchnahme ein Überlassungsmechanismus
für eine
Ressource (die Docking Station) sein, wie vorstehend beschrieben.
Nach 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. Nach 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. Nach
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.
-
Nach
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 frei 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 Unterstü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-Nachichtensystems 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 Transformations- 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
Abwandlungen 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.