DE60102234T2 - Verfahren und vorrichtung zur ermittlung von benachbarten diensten - Google Patents

Verfahren und vorrichtung zur ermittlung von benachbarten diensten Download PDF

Info

Publication number
DE60102234T2
DE60102234T2 DE60102234T DE60102234T DE60102234T2 DE 60102234 T2 DE60102234 T2 DE 60102234T2 DE 60102234 T DE60102234 T DE 60102234T DE 60102234 T DE60102234 T DE 60102234T DE 60102234 T2 DE60102234 T2 DE 60102234T2
Authority
DE
Germany
Prior art keywords
service
client
space
message
gate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60102234T
Other languages
English (en)
Other versions
DE60102234D1 (de
Inventor
L. Gregory SLAUGHTER
E. Thomas SAULPAUGH
A. Bernard TRAVERSAT
J. Michael DUIGOU
M. Mohamed ABDELAZIZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/656,588 external-priority patent/US7412518B1/en
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE60102234D1 publication Critical patent/DE60102234D1/de
Application granted granted Critical
Publication of DE60102234T2 publication Critical patent/DE60102234T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Bereich der Erfindung
  • Diese Erfindung bezieht sich auf verteilte Rechnerumgebungen einschließlich Webzentrierter und Internet-zentrierter verteilter Rechnerumgebungen und genauer gesagt auf eine heterogene, verteilte Rechnerumgebung, die auf einem Nachrichtenübergabemodell zum Verbinden von Netzwerk-Clients und Diensten und dem Ausfindigmachen von Diensten in einer solchen Umgebung beruht.
  • 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-Computern, Desktop-Computern, Arbeitsplatzrechnern bis zu Mainframes bzw. Großcomputern; sogar Super-Computern. Netzwerke werden auch zu einem zunehmend verbreiteten Mittel, um intelligente Einrichtungen miteinander zu verbinden, so daß sie miteinander kommunizieren können. Es bestehen jedoch große Unterschiede bei der Computerleistung und den Speicherfähigkeiten der verschiedenen intelligenten Einrichtungen. Einrichtungen mit beschränkteren Fähigkeiten können als Schmalspur-Einrichtungen oder "Thin"-Devices bezeichnet werden. Thin-Devices sind möglicherweise nicht in der Lage, an Netzwerken, die leistungsfähigere Einrichtungen miteinander verbinden, teilzunehmen. Es kann aber dennoch wünschenswert sein, eine breite Vielfalt von verschiedenen Arten von intelligenten Einrichtungen miteinander zu verbinden.
  • Der Wunsch, die Netzwerkfähigkeiten zu verbessern, nimmt weiter zu. Geschäfts- bzw. Firmennetzwerke werden erweitert, um eine direkte Interaktion mit den Lieferanten bzw. Zulieferern und Kunden aufzunehmen. Mobiltelefone, Persönliche Digitale Assistenten und Internet-fähige Computer sind sowohl in Unternehmen als auch zuhause alltäglich. Netzwerke im Haus stehen zur Verbindung von Audio-/Video-Ausrüstung wie Fernsehgeräten und Stereoanlagen mit Heimcomputern und anderen Einrichtungen zum Steuern intelligenter Systeme wie Sicherheitssysteme und Temperaturkontrollthermostate zur Verfügung. Medien mit hoher Bandbreite wie Kabel und ADSL ermöglichen verbesserte Dienste wie Internetzugang für Video-on-Demand, E-Commerce etc. Netzwerksysteme werden allgegenwärtig. Auch ohne ein formelles bzw. förmliches Netzwerk ist es bei intelligenten Einrichtungen dennoch wünschenswert, miteinander zu kommunizieren und Ressourcen gemeinsam zu nutzen.
  • Derzeit sind herkömmliche Netzwerke kompliziert aufzubauen, zu erweitern und zu verwalten. Zum Beispiel erfordert das Hinzufügen von Hardware oder Software zu einem Netzwerk häufig einen Netzwerk-Administrator, um Treiber zu laden und Systeme zu konfigurieren. Kleine Änderungen an einer Netzwerk-Konfiguration vorzunehmen, kann es erfordern, daß das gesamte Netzwerk für eine Zeitspanne heruntergefahren wird. Darüber hinaus kann es sein, daß bestimmte intelligente Einrichtungen die benötigten Schnittstellen nicht unterstützen, um auf einem gegebenen Netzwerk zu kommunizieren.
  • Was benötigt wird, ist eine einfache Möglichkeit, verschiedene Arten von intelligenten Einrichtungen anzuschließen bzw. zu verbinden, um eine Kommunikation und das gemeinsame Nutzen von Ressourcen zu ermöglichen, während die bei herkömmlichen Netzwerken vorhandenen Interoperabilitäts- und komplizierten Konfigurationsprobleme vermieden werden. Es gibt verschiedene Technologien, um das Hinzufügen von Einrichtungen zu einem Netzwerk zu verbessern. Zum Beispiel helfen viele moderne I/O-Busse wie der Universelle Serielle Bus, 1394 und PCI Plug&Play oder dynamische Discovery- bzw. Entdeckungsprotokolle dabei, das Hinzufügen einer neuen Einrichtung an dem Bus zu vereinfachen. Jedoch sind diese Lösungen auf spezielle Peripheriebusse beschränkt und sind für allgemeine Netzwerk nicht geeignet.
  • Eine neuere Technologie, Jini von Sun Microsystems Inc., ist darauf ausgerichtet, die Verbindung und die gemeinsame Nutzung von Einrichtungen wie Druckern und Plattenlaufwerken in einem Netzwerk zu vereinfachen. Eine Einrichtung, die Jini einbezieht bzw. umfaßt, kann sich selbst dem Netzwerk gegenüber bekannt machen, kann einige Einzelheiten über ihre Fähigkeiten bereitstellen bzw. übergeben und kann sofort für andere Einrichtungen in dem Netzwerk zugänglich werden. Jini ermöglicht verteilte Verarbeitung, wobei die Fähigkeiten der verschiedenen Einrichtungen in einem Netzwerk gemeinsam genutzt werden. Die Jini-Technologie strebt an, Benutzer in die Lage zu versetzen, Dienste und Ressourcen über ein Netzwerk gemeinsam zu nutzen. Ein anderes Ziel der Jini-Technologie ist es, Benutzern einen einfachen Zugang zu bzw. Zugriff auf Ressourcen irgendwo im Netzwerk zu gewähren, während die Anordnung bzw. die Lokation des Benutzers im Netzwerk sich ändern kann. Jini strebt auch an, die Aufgabe der Errichtens, Unterhaltens und Änderns eines Netzwerkes von Einrichtungen, Software und Benutzern zu vereinfachen.
  • Jini erfordert, daß jedes Jini-fähige Gerät eine bestimmte Menge von Speicher und Rechenleistung hat. Typischerweise ist eine Jini-fähige Einrichtung mit einer virtuellen Java-Maschine ausgerüstet. Daher sind Jini-Systeme auf die Java-Technologie ausgerichtet. Java ist eine objektorientierte, hohe Programmiersprache, die von Sun Microsystems Inc. entwickelt wurde. Java-Quellcode kann in ein Bytecode genanntes Format kompiliert werden, das dann von einer virtuellen Java-Maschine ausgeführt werden kann.
  • Bytecode ist Computerquellcode, der von einer virtuellen Maschine anstelle des "realen" Computers, des Hardwareprozessors, verarbeitet wird. Die virtuelle Maschine wandelt verallgemeinerte Maschinenbefehle (den Bytecode) in spezifische Maschinenbefehle um (Befehle, die der Prozessor des Computers versteht). Unter Verwendung einer Sprache, die mit einer virtuellen Maschine für jede Plattform geliefert wird, brauchen die Quellsprachenanweisungen nur einmal kompiliert werden und können danach auf jeder Plattform ablaufen, die die virtuelle Maschine unterstützt. Die Programmiersprache Java ist ein Beispiel einer solchen Sprache, und die Virtuelle Java-Maschine (JVM) ist ein Beispiel einer virtuellen Maschinenplattform, die in der Programmiersprache Java geschriebene Programme unterstützt.
  • Da virtuelle Java-Maschinen für die meisten Computerplattformen bereitgestellt werden können, sorgen Java und somit Jini in einem gewissen Umfang für Plattformunabhängigkeit. Die Jini-Architektur setzt die Voraussetzung wirksam ein, daß die Programmiersprache Java die Implementationssprache für die Komponenten des Jini-Systems ist. Die Fähigkeit, Java-Code dynamisch herunterzuladen und ablaufen zu lassen, ist zentral für viele Eigenschaften bzw. Fähigkeiten der Jini-Architektur.
  • Der Zweck der Jini-Architektur ist, Gruppen von Einrichtungen bzw. Geräten und Softwarekomponenten zu einem einzelnen, dynamisch verteilten System zu vereinigen bzw. zu verbünden. Ein Schlüsselkonzept innerhalb der Jini-Architektur ist das eines Dienstes. Ein Dienst ist eine Einheit bzw. eine Instanz, die von einer Person, einem Programm oder einem anderen Dienst verwendet werden kann. Zwei Beispiele von Diensten sind das Drucken eines Dokumentes und das Übersetzen von einem Textverarbeitungsformat in ein anderes. Jini ermöglicht es den Mitgliedern eines Jini-Systems, den Zugang zu bzw. den Zugriff auf Dienste(n) gemeinsam zu nutzen. Dienste in einem Jini-System kommunizieren miteinander unter Verwendung eines Dienstprotokolls, welches ein Satz bzw. eine Menge von Schnittstellen ist, die in der Programmiersprache Java geschriebenen sind. Dienste werden in einem Jini-System von einem Nachschlagedienst bzw. Nachschlagedienst gefunden und aufgelöst. Ein Nachschlagedienst bildet Schnittstellen, die die von einem Dienst bereitgestellte Funktionalität angeben, auf Mengen von Objekten ab, die den Dienst implementieren.
  • Beschreibende Einträge können auch einem Dienst zugeordnet sein. Einrichtungen und Anwendungen verwenden einen Prozeß, der als die Entdeckung bzw. Discovery bekannt ist, um sich bei dem Jini-Netzwerk zu registrieren. Sobald die Einrichtung oder die Anwendung registriert ist, setzt bzw. stellt sie sich in den Nachschlagedienst. Der Nachschlagedienst kann nicht nur Zeiger auf diese Dienste in dem Netzwerk speichern, sondern kann auch den Code für den Zugriff auf diese Dienste speichern. Wenn sich zum Beispiel ein Drucker bei dem Nachschlagedienst registriert, lädt er seinen Druckertreiber und/oder eine Schnittstelle zu dem Treiber in den Nachschlagedienst. Wenn ein Client den Drucker verwenden möchte, werden der Treiber und die Treiberschnittstelle aus dem Nachschlagedienst in den Client heruntergeladen. Diese Codemobilität bedeutet, daß Clients aus den Diensten des Netzwerkes einen Vorteil ziehen bzw. sich die Dienste des Netzwerks zunutze machen können, ohne Treiber oder andere Software vorab zu installieren oder zu laden.
  • Die Kommunikation zwischen den Diensten in einem Jini-System wird erreicht, indem ein abgesetzter bzw. entfernter Methodenaufruf von Java (Java Remote Method Invocation, RMI) verwendet wird. RMI ist eine für die Programmiersprache Java angepaßte Erweiterung für herkömmliche Mechanismen zum abgesetzten bzw. entfernten Prozeduraufruf. RMI erlaubt es nicht nur, daß Daten von Objekt zu Objekt in dem Jini-Netzwerk übergeben werden, sondern auch vollständige Objekte, die auch Code enthalten. Jini-Systeme hängen von dieser Fähigkeit ab, Code über das Netzwerk in einer Form herumzuschieben, die in einem Java-Objekt eingekapselt ist.
  • Zugriff auf Dienste in einem Jini-System beruht auf Pacht bzw. Überlassung. Eine Pacht bzw. Überlassung bzw. ein Leasing ist ein Einräumen eines garantierten Zugriffs für eine 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-Deserialisierung macht es erforderlich, daß die Anwendung eng mit der JVM zusammenarbeitet, um das Objekt, ein Feld zu einem Zeitpunkt, wieder herzustellen, während der transitive Abschluß des Objektes dynamisch analysiert wird. Somit ist die Java-Serialisierung/Deserialisierung langsam und schwerfällig, während sie gleichzeitig sowohl eine große Menge von Anwendungs- und JVM-Code als auch dauerhaften Speicherplatz benötigt.
  • Auch für Thin-Clients, die Java unterstützen, ist das Jini-RMI möglicherweise nicht praktizierbar für Thin-Clients mit minimalem Speicherplatz und minimaler Bandbreite. Die mit Jini-RMI verbundene Serialisierung ist langsam, umfangreich, benötigt das Reflektions-API der JVM und ist eine Java-spezifische Objektdarstellung. Die Java-Deserialisierung ist auch langsam, umfangreich und erfordert einen Parser für serialisierte Objekte. Auch Java-basierte Thin-Clients sind möglicherweise nicht in der Lage, riesige Java-Objekte (zusammen mit den benötigten Klassen) zu akzeptieren, die (notwendigerweise) über das Netzwerk an den Client zurückgeliefert werden, wie in Jini erforderlich. Ein besser skalierbarer Mechanismus der verteilten Verarbeitung wird benötigt. Es ist vielleicht wünschenswert, daß ein besser skalierbarer Mechanismus der verteilten Verarbeitung Sicherheitsbedenken berücksichtigt und erweiterbar ist, um die Übergabe von Objekten wie Java-Objekten zu ermöglichen, und es sogar zu ermöglichen, daß ein Prozeß von einem Netzwerkmodus zu einem anderen migriert.
  • Objektbasierte Systeme zur verteilten Verarbeitung erfordern dauerhaften Speicher. Wie oben diskutiert, sind jedoch die Versuche, Objektspeicher zu realisieren, häufig sprach- und betriebssystemspezifisch. Darüber hinaus sind diese Objektspeichersysteme zu kompliziert, um bei vielen kleinen, eingebetteten Systemen verwendet zu werden. Zum Beispiel verwendet die Jini-Technologie JavaSpaces als dauerhafte Objektcontainer. Jedoch kann ein JavaSpace nur Java-Objekte speichern und kann nicht in kleinen Systemen implementiert werden. Jedes Objekt in einem JavaSpace ist serialisiert und bezahlt mit den oben beschriebenen Strafen, die mit der Java-Serialisation verbunden sind. Es kann wünschenswert sein, einen heterogenen Objektcontainer für die verteilte Verarbeitung zu haben, der von kleinen bis zu großen Einrichtungen skalierbar ist.
  • JavaSpaces von Sun Microsystems Inc. zieht Nutzen aus der Arbeit über parallele Verarbeitung von David Gelernter, einem Professor der Computerwissenschaften an der Yale Universität. Gelernter Satz von Funktionen namens "Linda" erzeugt einen gemeinsam genutzten Speicherplatz, der ein TupleSpace genannt wird, in den Ergebnisse von Prozessen eines Computers oder die Prozesse selbst zum Zugriff durch mehrere CPUs gespeichert werden können. Linda stellt daher einen globalen, gemeinsam genutzten Speicher für mehrere Prozessoren zur Verfügung.
  • Eine andere Technologie, die Linda erweitert, ist TSpaces von IBM Corporation. TSpaces erweitert das grundlegende TupleSpace-Rahmenwerk von Linda um reale Datenverwaltung und die Möglichkeit, neue Datentypen und neue semantische Funktionalität herunterzuladen. TSpaces stellt einen Satz von Puffern für die Netzwerkkommunikation und einen Satz von APIs zum Zugriff auf diese Puffer zur Verfügung. Wie viele der oben diskutierten Lösungen verwendet TSpaces daher ein codezentriertes Programmiermodell und teilt die Nachteile eines solchen Modells. Darüber hinaus ist TSpaces in der Programmiersprache Java implementiert und erfordert daher eine Virtuelle Java-Maschine oder andere Möglichkeiten zur Ausführung von Java-Bytecode wie einen Java-fähigen Mikroprozessor. Daher ist TSpaces möglicherweise ungeeignet für kleindimensionierte Einrichtungen, die nicht genügend Ressourcen zur Ausführung von Java-Bytecode bereitstellen können.
  • Es ist in objektorientierten verteilten Systemen wünschenswert, in der Lage zu sein, Objektbehälter zu lokalisieren und bestimmte Objekte in diesem Behälter zu finden. Wie oben erwähnt ist der Jini-Nachschlagedienst möglicherweise für kleine Einrichtungen mit kleinen Speicherdimensionen nicht praktizierbar. Ein effizienterer Mechanismus zum Lokalisieren von Objektspeichern kann wünschenswert sein.
  • Es kann wünschenswert sein, daß in einem verteilten Netzwerkverarbeitungsmodell Clients die Fähigkeit besitzen, Dienste zu lokalisieren. Aktuelle Netzwerkprotokolle stellen entweder nur eine einzige Zugangsschnittstelle für einen Standarddienst bzw. standardmäßige Zugangsschnittstelle für einen Dienst zur Verfügung, die nicht für Sicherheit sorgt, wenn auf einen Netzwerkdienst zugegriffen wird, oder stellt einen "Alles-oder-Nichts"-Zugang auf dem vollen Umfang der Diensteigenschaften bzw. -fähigkeiten zur Verfügung, der Administrator- oder privilegierte Funktionen umfassen kann. Ebenso stellen aktuelle Netzwerkprotokolle zum Lokalisieren von Diensten keinen flexiblen Mechanismus zum Finden von Diensten zur Verfügung. Aktuelle Protokolle stellen entweder überhaupt keine selektive Suchmöglichkeit zur Verfügung (z.B. UPnP) oder stellen nur einen primitiven Grammatikmechanismus mit Schlüsselwort und Attribut zur Verfügung (z.B. SLP). Daher können aktuelle Mechanismen zum Ausfindigmachen von Diensten in ihren Mechanismen zu Sicherheit und Suchkriterien zu unflexibel sein.
  • Aktuelle Modelle zum Ausfindigmachen von Diensten haben auch ein symmetrisches Modell zum Lokalisieren von Diensten. Es kann jedoch eine Verschwendung von Ressourcen darstellen, für gewisse Diensteinrichtungen, wie z.B. Einrichtungen, für welche die Verfügbarkeit der Funktionalität auf der Nähe beruht, das Auffindungsmodell zu unterstützen. Dies liegt daran, daß solche Einrichtungen bereits nach der Nähe zueinander angeordnet sind (z.B. indem eine Einrichtung physikalisch auf eine andere zeigt). Daher kann auch ein alternativer, leichtgewichtiger Auffindungsmechanismus für solche Einrichtungen wünschenswert sein.
  • Ein verteilter Objektzugriff strebt einen gerechten und effizienten Mechanismus der gemeinsamen Nutzung an. Wie oben beschrieben verwendet Jini aktuell einen Überlassungs- bzw. Pachtmechanismus, um Objekte gemeinsam zu nutzen. Jedoch sind die Überlassungen von Jini zeitbasiert, was zu einer Reihe von Problemen führen kann. Zum Beispiel könnte der aktuelle Halter eines Objektes keine Vorstellung darüber haben, wie lange er ein Objekt pachten soll, und er hält es womöglich zu lange. Darüber hinaus kann es die Verwendung von Überlassungen auf Zeitbasis erforderlich machen, daß die Zeit zwischen mehreren Maschinen synchronisiert ist. Weiterhin kann Überlassen auf Zeitbasis eine Unterstützung durch das Betriebssystem erfordern. Darüber hinaus werden Jini-Überlassungen mittels RMI eingerichtet und freigegeben. Somit leidet der Überlassungsmechanismus von Jini unter den oben erkannten Problemen bei der Verwendung von RMI. Darüber hinaus stellt der Überlassungsmechanismus von Jini keinen Sicherheitsmechanismus für das Einrichten, Erneuern und Aufgeben von Überlassungen bereit. Andere Überlassungsmechanismen sind möglicherweise wünschenswert.
  • Allgemein gesprochen ist es wünschenswert, daß mobile Clienteinrichtungen mit kleindimensioniertem Speicher in der Lage sind, eine Vielzahl von Diensten, sowohl hergebrachte als auch neue, in einer verteilten Umgebung ablaufen zu lassen. Die Arten von kleinen Clients können Mobiltelefone und PDAs mit einer Vielzahl von verschiedenen Netzwerkschnittstellen, typischerweise mit niedriger Bandbreite, umfassen. Häufig haben diese Einrichtungen sehr kleine Anzeigen mit eingeschränkter Grafik, aber sie können auch Laptops und Notebook-Computer umfassen, die eine größere Anzeige und anspruchsvollere grafische Fähigkeiten besitzen. Die Dienste können ein weiter Bereich sowohl von Anwendungen als auch von Steuerprogrammen für Geräte bzw. Einrichtungen wie Drucker sein. Es ist wünschenswert, daß ein mobiler Client in der Lage ist, diese Dienste zu verwenden, wo auch immer sie sein mögen.
  • Ein mobiler Client befindet sich häufig an einer temporären, dynamischen Netzwerkadresse, so daß Netzwerknachrichten, die er sendet, nicht über die Netzwerkschnittstelle hinaus geleitet werden können (ansonsten kann es Kollisionen geben, wenn zwei verschiedene Clients auf verschiedenen Netzwerken dieselbe dynamische Adresse haben). Mobile Clients haben häufig nicht die Fähigkeit bzw. Möglichkeit für einen Browser mit vollem Funktionsumfang oder andere anspruchsvolle Software. Die Anzeige kann den Client einschränken, gewisse Anwendungen ablaufen zu lassen. Traditionelle Anwendungsmodelle beruhen auf vorher festgelegten Benutzerschnittstellen- oder Dateneigenschaften. Jede Änderung der Anwendung erfordert eine Neukompilierung der Anwendung.
  • Es kann wünschenswert sein, daß solche Clients über einen Mechanismus verfügen, um verteilte Anwendungen oder Dienste zu finden und aufzurufen. Der Client kann sogar große Altlastanwendungen ablaufen lassen müssen, die möglicherweise nicht in die Speicherdimensionierung des Clients passen würden. Wie oben diskutiert ist die aktuelle Technologie wie Jini für kleinformatige Einrichtungen bzw. Geräte möglicherweise nicht praktikabel. Die Verbreitung von mobilen Thin-Clients kann auch zusätzliche Anforderungen aufkommen lassen. Zum Beispiel kann es wünschenswert sein, einen Dienst bezogen auf den physikalischen Aufenthaltsort des Benutzers und seines mobilen Client zu lokalisieren. Zum Beispiel kann Information über die Dienste in der lokalen Nachbarschaft wie lokale Restaurants, Wetter, Verkehrskarten und Kinoinformation sehr hilfreich sein. In ähnlicher Weise kann Information über Verarbeitungsressourcen wie Drucker an einer bestimmten Stelle hilfreich sein. Aktuelle Technologien sehen keinen automatischen Mechanismus vor, um Dienste auf der Basis des physikalischen Ortes des Clients zu lokalisieren. Ein anderer Bedarf, der durch mobile Thin-Clients aufgekommen ist, ist die Berücksichtigung des menschlichen Faktors. Mobile Thin-Clients enthalten typischerweise keine ergonomischen Tastaturen und Monitore. Die Bereitstellung solcher Dienste, die den menschlichen Faktor betreffen, und/oder die Fähigkeit, solche Dienste in einer verteilten Rechnerumgebung zu lokalisieren, kann wünschenswert sein.
  • Ein verteiltes IT-Modell sollte Clients mit einer Möglichkeit versorgen, transiente Dokumente und Dienste zu finden. Es kann wünschenswert sein, einen Mechanismus zum Finden von Mehrzweck-Dokumenten (einschließlich Diensten und/oder Dienstannoncen) zu haben, bei dem die Dokumente in einer plattform- und sprachunabhängigen Schreibweise wie derjenigen, die durch die eXtensible Markup Language (XML) bereitgestellt wird, ausgedrückt sind. Aktuelle Ansätze einschließlich Suchmechanismen von Jini, Universal Plug and Play (UPnP) und das Service Location Protocol (SLP) unterstützen einen solchen Suchmechanismus für Mehrzweck-Dokumente nicht. Zum Beispiel ist der Suchmechanismus von Jini auf Schreiben bzw. Eingabe in der Sprache Java beschränkt und ist daher nicht sprachunabhängig. UPnP und SLP unterstützen ein Auffindungsprotokoll nur für Dienste, nicht für Mehrzweck-Dokumente.
  • MUNSON M. ET AL: 'Flexible internetworking of devices and controls' INDUSTRIAL ELECTRONICS SOCIETY, 1999, IECON '99 PROCEEDINGS, THE 25TH ANNUAL CONFERENCE OF THE IEEE SAN JOSE, CA, USA 29. NOV.-3. DEC. 1999, PISCATAWAY, NJ, USA, IEEE, US, 29. November 1999 (1999-11-29), Seiten 1139-1145, beschreibt die Verwendung von Anwendungs-Middleware (TSpaces), die eine gleichförmige Schicht der Umleitung zwischen Komponenten bereitstellt, um eine integrierte Steuerung von heterogenen Einrichtungen in heterogenen Steuernetzwerken zu ermöglichen.
  • ZUSAMMENFASSUNG
  • Für einige Einrichtungen, die einen Dienst auf einer lokalen oder Nachbarschafts-Basis anbieten, kann es ineffizient sein, den Overhead zur Unterstützung eines Mechanismus' zum breiten Anzeigen ihrer Dienste zu unterhalten und diese Anzeige auf dem Laufenden zu halten. Nach einer Ausführungsform können Dienste auf einigen Einrichtungen ihre Anzeigen als Antwort auf Verbindungsanforderungen übermitteln, statt Dienstanzeigen bzw. -angebote breit gestreut zu veröffentlichen. Zum Beispiel unterhält eine Druckereinrichtung mit einem Druckerdienst, der auf Nachbarschaftsbasis bzw. in der Nähe verfügbar ist, möglicherweise keine Anzeige in einem Space (auf der Einrichtung oder außerhalb der Einrichtung). Stattdessen kann der Druckerdienst die Dienstangebote übermitteln, wenn eine andere Einrichtung eine Verbindung mit der Druckereinrichtung aufbaut (zum Beispiel ein Benutzer mit einem Laptop, auf dem ein Client abläuft, der ein Dokument drucken möchte), um das XML-Dienstschema zum Verbinden mit dem Dienst und Ablaufen-Lassen des Dienstes bereitzustellen, der die Druckfunktionalität auf der Druckereinrichtung zur Verfügung stellt. Ebenso unterhalten einige Einrichtungen möglicherweise nur Anzeigen für ihre Dienste in einer bestimmten näheren Umgebung oder einem lokalen Netzwerk. Eine solche Einrichtung soll womöglich keine Transportmittel für breitere Zugänglichkeit unterstützen oder hat womöglich keinen Zugang dazu.
  • Ein Beispiel einer Diensteinrichtung, in der es für eine Einrichtung wünschenswert sein kann, das Unterhalten von Dienstangeboten (im Sinne von Anzeigen) in einem Space zu vermeiden oder einzuschränken, ist eine Einrichtung, deren Funktionalität nur auf Nachbarschaftsbasis verfügbar ist. Dienste auf Nachbarschaftsbasis können Angebote ihrer Funktionalität auf Anforderung zur Verfügung stellen. Auf diese Angebote kann möglicherweise nicht in breitem Maße zugegriffen werden. Zum Beispiel können in einem drahtlosen Kommunikationssystem oder einem IrDA-System Dienste auf Nachbarschaftsbasis zur Verfügung stehen. Einige Nachbarschaftseinrichtungen benötigen Sichtverbindung oder physikalische Nähe, um mit einer anderen Einrichtung Verbindung aufzunehmen.
  • Es kann ein Mechanismus zum Auffinden von Diensten zur Verfügung stehen, den Clients zum Auffinden von Diensten ohne Verwendung separater, allgemein verfügbarer Rendezvous-Punkte benutzen können. Ein Beispiel einer auf Nähe basierenden Rechnerumgebung ist eine IrDA-Punkt-zu-Punkt-Rechnerumgebung. In einer auf Nähe basierenden Rechnerumgebung kann der Nachbarschaftsmechanismus den "physikalischen" (räumlichen) Standort des Dienstes für den Client finden. Zum Beispiel kann die Clienteinrichtung in einer IrDA-Umgebung auf die Einrichtung einschließlich des Dienstes oder der Dienste, die der Client benutzen möchte, hingewiesen werden.
  • Ein Auffindungsprotokoll für auf Nähe basierende Dienste kann es Clients ermöglichen, Dienste auf der Basis der Nähe ausfindig zu machen. Eine Diensteinrchtung, die einen oder mehrere Rechendienste zur Verfügung stellt, kann eine Nachbarschaftskommunikationsverbindung unterstützen. Eine Clienteinrichtung kann eine Nachbarschaftskommunikationsverbindung mit der Diensteinrichtung bilden. Die Clienteinrichtung kann direkt von der Diensteinrichtung ein Dokument anfordern, das eine Schnittstelle zum Zugriff auf einen Dienst beschreibt, der von der Diensteinrichtung bereitgestellt wird. Die Anforderung kann eine Nachricht zur Verbindungsanforderung oder zur Anforderung einer Dienstanzeige sein. Die Anforderungsnachricht kann in einer Datenrepräsentationssprache wie XML vorliegen bzw. verfaßt sein. Die Diensteinrchtung kann das Schnittstellendokument über die Nachbarschaftskommunikationsverbindung direkt an die Clienteinrichtung übergeben.
  • Das Dienstschnittstellendokument kann in einer Antwortnachricht, die auch in der Datenrepräsentationssprache verfaßt ist, übergeben werden. Das Dokument kann eine Dienstanzeige für den Dienst beinhalten, und die Dienstanzeige kann ein Schema (z. B. ein XML-Schema) beinhalten, das eine Schnittstelle zu mindestens einem Teil des Dienstes spezifiziert. Die Clienteinrichtung kann die Information aus dem Dokument verwenden, um auf den Dienst zuzugreifen. Der Client kann ein Nachrichtengatter gemäß einem Nachrichtenschema, das in der Anzeige bereitgestellt wird, einrichten. Die Anzeige definiert Nachrichten, die zwischen dem Client und dem Dienst gesendet werden können, damit der Client den Dienst benutzen kann. Das Gatter kann jede Nachricht, die gesendet und/oder empfangen wird, auf Übereinstimmung mit dem Schema überprüfen.
  • Der Mechanismus zum Auffinden von auf Nähe basierenden Diensten kann Clients in die Lage versetzen, direkt nach Dienstanzeigen zu suchen, anstatt eine Suchanforderung an einen Space oder andere Rendezvous-Punkte zu senden, um nach Dienstanzeigen zu suchen. Da die Clienteinrichtung eine Nachbarschaftsverbindung zu der Diensteinrichtung aufgebaut haben kann, kann der Client direkt den gewünschten Dienst anfordem. Zum Beispiel kann eine PDA-Clienteinrichtung eine Nachbarschaftsverbindung zu einer Druckereinrichtung aufbauen; der Client kann "wissen", wie man eine Verbindung zum Druckerdienst auf der Druckereinrichtung anfordert.
  • Nach einer Ausführungsform kann der Client eine Nachricht zum Auffinden von auf Nähe basierenden Diensten an die Diensteinrichtung senden. Die Nachricht kann Information umfassen, 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 von auf Nähe basierenden Diensten antworten und kann dem Client die Dienstanzeige senden, die der Client zum Aufnehmen einer Verbindung zu dem gewünschten Dienst verwenden kann. Die Nachricht zum Auffinden von auf Nähe basierenden Diensten kann auch Information beinhalten, die zum Authentisieren des Clients und zum Aufbau bzw. Bereitstellen der Fähigkeiten des Client auf dem Dienst verwendet werden kann. Unter Verwendung der empfangenen Dienstanzeige kann der Client ein Gatter einrichten, um Kommunikation mit dem gewünschten Dienst aufzunehmen.
  • Die Clienteinrichtung kann zusätzlich zu der Nachbarschaftskommunikationsverbindung eine Transportverbindung unterstützen, und die Clienteinrichtung kann das Dokument anderen Einrichtungen über die Transportverbindung verfügbar machen. Somit kann die Clienteinrichtung eine Brücke von der Transportverbindung zu der Nachbarschaftskommunikationsverbindung bereitstellen, so daß andere Einrichtungen aus einer verteilten Rechnerumgebung auf den Dienst zugreifen können. Die Transportverbindung kann eine Verbindung zu einem Netzwerk wie einem LAN, WAN oder dem Internet beinhalten.
  • 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, das das Ausfindigmachen von Diensten gemäß einer Ausführungsform darstellt;
  • 42 ist ein Flußdiagramm, das ein Beispiel der Lokalisierung von Dienstanzeigen gemäß einer Ausführungsform darstellt;
  • 43 ist eine Darstellung, die den Unterschied in dem Auffindungsvorgang vergleicht, wenn die veröffentlichte Anzeige eine vollständige Anzeige im Vergleich zu einer geschützten Anzeige gemäß einer Ausführungsform ist;
  • 44 ist ein Blockdiagramm eines Beispiels eines Systems, in dem gemäß einer Ausführungsform eine Clienteinrichtung direkt einen Dienst auf einer Diensteinrichtung über eine Nachbarschaftsverbindung ausfindig macht; und
  • 45 ist ein grundlegendes Flußdiagramm, das das Ausfindigmachen eines auf Nähe beruhenden Dienstes durch den Client gemäß einer Ausführungsform darstellt.
  • 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 Rechnerumgebung teilnehmen.
  • Somit ist die Grundlage für die verteilte Rechnerumgebung eine einfache, Nachrichten übergebende Schicht, die oberhalb einer zuverlässigen Verbindung und/oder von unzuverlässigen Datagrammen implementiert ist. Die Nachrichtentechnologie ist sehr verschieden von Kommunikationstechnologien, die in anderen verteilten Verarbeitungssystemen wie Jini, welches die Java Remote Method Invocation (RMI) verwendet, eingesetzt werden, Die Nachrichten übergebende Schicht 104 unterstützt einen asynchronen, zustandslosen Stil von verteilter Programmierung anstelle eines synchronen, zustandsbehafteten Stils, der auf RMI beruht. Mehr noch gründet sich die Nachrichten übergebende Schicht 104 auf einen Datenrepräsentationssprache wie XML und kopiert somit, anders als RMI, Daten, jedoch keinen Code, von der Quelle zum Ziel. Durch Verwendung einer Datenrepräsentationssprache wie XML kann die Nachrichtenschicht 104 mit Nicht-Java- und Nicht-Jini-Plattformen in einer nahtlosen Weise interoperieren, weil Java-Code auf der sendenden oder empfangenden Seite einer Nachricht nicht vorausgesetzt wird. Darüber hinaus benötigt die Nachrichtenschicht 104 anders als RMI keinen zuverlässigen Transportmechanismus wie TCP/IP.
  • Die Nachrichten übergebende Schicht kann einfache send()- und receive()-Methoden zur Verfügung stellen, um eine zum Beispiel als ein Array oder eine Kette von Bytes angegebene Nachricht zu senden. Die send()-Methode kann sofort zurückkehren, wobei die Datenübertragung asynchron durchgeführt wird. Zum Zweck der Flußkontrolle kann eine Callback-Methode geliefert werden, die im dem Fall aufgerufen wird, daß die send()-Methode eine Ausnahmebedingung aufwirft, die anzeigt, daß sie die send()-Anforderung nicht behandeln kann, Die receive()-Methode kann synchron sein und die nächste verfügbare Nachricht zurückliefern.
  • Die Nachrichten übergebende Schicht kann auch Methoden zum Speichern von XML-Darstellungen von Objekten, Diensten und Inhalt in "Räumen" bzw. "Spaces" zur Verfügung stellen. Ein Space wird in einem Netzwerk mittels eines URI (Uniform Resource Identifier) mit einem Namen versehen und es wird damit auf ihn zugegriffen. Der URI kann ein URL (Uniform Resource Locator) oder eine einfachere Version eines URL sein. In einigen Ausführungsformen kann die URL-Klasse zu groß sein. Für solche Ausführungsformen kann ein einfacherer Ressourcenlokator verwendet werden, der das Protokoll zum Bewegen der Nachrichten zwischen Client und Server, die protokollabhängige Host-ID, die protokollabhängige Anschluß- bzw. Port-ID und einen Space-Namen angibt.
  • Eine XML-Darstellung eines Objektes kann einem Space hinzugefügt werden, indem eine von der Nachrichtenschicht zur Verfügung gestellte write()-Methode verwendet wird. 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 Gatterfabrik 140 haben, die zuverlässigen Code beim Client zum Generieren von Gattern auf der Grundlage von XML-Dienstbeschreibungen darstellt. Die Verwendung der Gatterfabrik 140 kann sicherstellen, daß das Gatter, das es erzeugt, auch zuverlässigen Code darstellt und daß der Code bezüglich der Serverannonce korrekt ist. Wie in 11b gezeigt, kann ein Gatter 130c auch bei einem Dienst 112 generiert werden. Das Clientgatter 130a und das Dienstgatter 130c stellten Nachrichtenendpunkte zur Kommunikation zwischen dem Client und dem Dienst bereit. 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 Gatterfabrik 140 kann für einen Client mit einem Dienst aushandeln, daß ein Gatter zum Senden von Nachrichten an den Dienst erzeugt wird. In ähnlicher Weise kann bei dem Dienst ein Gatter zum Empfang von Nachrichten von dem Clientgatter und zum Senden von Nachrichten an das Clientgatter eingerichtet werden. Zusammen können die Client- und Dienstgatter einen sicheren, bidirektionalen Kommunikationskanal bilden.
  • Eine Gatterfabrik kann eine Abstraktionsstufe beim Erzeugen eines Gatters bieten. Wenn zum Beispiel ein Client einen Dienst verwenden möchte, kann das Gatter von einer Gatterfabrik als Teil des Instantiieren des Dienstes erzeugt werden, anstatt daß der Client ein Gatter zum Zugriff auf den Dienst erzeugt.
  • Die Gatterfabrik kann ihre eigenes, zuverlässiges Nachrichtengatter erzeugen oder enthalten, das verwendet wird, um mit einem Authentisierungsdienst zu kommunizieren (z. B. durch die Dienstannonce angegeben), um einen Authentisierungsnachweis für das Gatter, das eingerichtet wird, zu empfangen. Für Dienste, die den Zugriff bzw. Zugang nicht einschränken, kann ein Gatter ohne einen Authentisierungsnachweis eingerichtet werden. Die Gatter für solche Dienste brauchen möglicherweise nicht mit jeder Nachricht einen Authentisierungsnachweis zu senden, weil der Dienst den Zugang nicht einschränkt. Der Authentisierungsdienst ist ein Beispiel eines Dienstes, der 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. am-lä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 Authentisienungsnachweis zur Laufzeit durchzuführen.
  • Ein Generierungswerkzeug kann für das Vorgenerieren von Gattern vorgesehen sein. Das Genefrienungswerkzeug 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 Bezeichnen (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 erforderich 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 Eneigniserzeugerdienst an. Ein Client kann auch das Interesse kündigen, was dazu führt, daß das Gatter sich bei dem Dienst, der das Ereignis erzeugt, abmeldet bzw. deregistriert.
  • Ein Ereignisgatter kann unter Verwendung des XML-Schemas eine Typü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 Authentisienungsnachweis 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 Ressouncenü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 Rechnerumgebung einen Mechanismus beinhalten, damit ein Client Zugriffrechte auf Dienste aushandeln und dann einen Sicherheitsnachweis oder ein Sicherheitsdokument erhalten kann, der oder das verwendet werden kann, um die Zugangsschnittstelle des Dienstes der Menge oder Teilmenge von Diensteigenschaften oder -funktionen darzustellen, die von dem Client angefordert wurde.
  • 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:
  • Figure 00450001
  • 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.
  • Somit kann das Protokoll zum Auffinden von Diensten es Clients ermöglichen, nach Diensten (sowohl Space-Diensten als auch spezifischen Diensten oder Arten von Diensten) zu suchen. Dienstanbieter (oder ein Horcher-Agent) können auf Suchanforderungen antworten, indem sie entsprechende Anzeigen oder URIs zu entsprechenden Anzeigen veröffentlichen oder bereitstellen. Wenn ein Dienstanbieter auf eine Suchanforderungen zum Ausfindigmachen antwortet (entweder direkt oder durch einen Horcher-Agenten), kann der Anbieter wählen, eine geschützte oder eine ungeschützte (vollständige) Anzeige zu veröffentlichen. Eine geschützte Anzeige kann die Menge von Information beinhalten, die nötig ist, um eine vollständige Anzeige zu erhalten. Eine geschützte Anzeige zu veröffentlichen, zwingt den Client dazu, vor dem Empfang der vollständigen, ungeschützten Anzeige von dem Dienstanbieter einen gültigen Berechtigungsnachweis von einem Authentisierungsdienst zu erhalten. Eine vollständige, ungeschützte Anzeige ist nötig, um ein Gatter zu erstellen und somit den Dienst zu benutzen. Clients zu zwingen, vor dem Empfang einer Anzeige einen gültigen Berechtigungsnachweis zu erhalten, kann für den Dienstanbieter eine zusätzliche Sicherheitsstufe bereitstellen. Der Sicherheitsnachweis, der zum Empfang der vollständigen Anzeige erhalten werden muß, kann derselbe Sicherheitsnachweis sein, der zur Einrichtung eines Gatters zum Kommunizieren mit dem Dienst benutzt wird, wobei das Gatter den Sicherheitsnachweis in jede Nachricht an den Dienst einbettet.
  • Ob ein Dienstanbieter eine geschützte oder eine vollständige Anzeige veröffentlicht oder nicht, kann von der vom Dienstanbieter gewünschten Sicherheitsstufe abhängen. Vollständige Anzeigen enthalten den Nachrichtenendpunkt-URI des Dienstes. Diese Adresse zu verbergen, kann eine wünschenswerte Sicherheitseigenschaft in vielen Arten von Netzwerken und Einsatzumgebungen sein. Jedoch überprüfen einfache Nachbarschaftsnetzwerke wie IrDA Clients, indem sie von dem Client verlangen, daß er sich sehr nahe bei dem Dienstanbieter aufhält. Die IRDA-Nachrichtenadresse vor einem Client in unmittelbarer Nähe zu verbergen, kann geradezu überflüssig oder zu aufwendig sein. In jedem Fall kann die Wahl der Antwort auf einen Suchvorgang dem Dienstanbieter überlassen werden. Nach einer bevorzugten Ausführungsform sind Clients (oder Fabriken für Clientgatter) dafür eingerichtet, jede beliebige Antwort auf einen Suchvorgang zu verarbeiten.
  • In 41 ist ein Flußdiagramm dargestellt, das gemäß einer Ausführungsform das Ausfindigmachen von Diensten veranschaulicht. Ein Client lokalisiert eine oder mehrere Anzeigen für einen Dienst oder für Dienste, die der Client verwenden möchte, wie bei 2072 angegeben. Nach einer Ausführungsform kann der Client Dienste durch das Senden einer Suchnachricht lokalisieren. In 42 ist ein Flußdiagramm dargestellt, das ein detaillierteres Beispiel des Lokalisierens von Dienstanzeigen für eine Ausführungsform veranschaulicht. Der Client kann eine Suchnachricht senden (z. B. rundsenden, an viele Empfänger bzw. per Multicast senden), die einen Dienstnamen und/oder Suchkriterien für Arten von Diensten beinhaltet, wie bei 2071 angegeben.
  • Das Folgende ist für eine Ausführungsform ein Beispiel einer Suchnachricht, die auf einem oder mehreren verfügbaren Nachrichtentransportmitteln gesendet werden kann, wenn ein Client nach Diensten suchen möchte:
  • Figure 00460001
  • Die Suchnachricht ist gemäß einer Datenrepräsentationssprache formatiert. Die Such- und Auffindungs-Tags können notwendig sein. Die Such-Tags können eine optionale Menge von Suchkriterien enthalten, die zum Einschränken der möglichen, von den Dienstanbietern zurückgelieferten Ergebnisse nützlich sind. Die optionalen Suchkriterienkomponenten können einen Namen (z. B. einen String bzw. eine Zeichenkette) umfassen. Der Name wird mit dem Namen eines Dienstes verglichen. Wenn der Suchname mit dem Anfang des Namens oder dem ganzen Namen des Dienstes übereinstimmt, kann eine Übereinstimmung für diesen Dienst deklariert werden. Nach einer Ausführungsform werden alle Dienstnamen als übereinstimmend angesehen, wenn kein Name angegeben ist.
  • Die optionalen Suchkriterienkomponenten können auch eine Art bzw. einen Typ (z. B. einen String) umfassen. Der Typ kann mit den Typ des Dienstes, z. B. in dem "Title"-Feld der Dienstbeschreibung, verglichen werden. Wenn der Suchtyp mit dem Anfang des Typs oder dem ganzen Typ des Dienstes übereinstimmt, kann eine Übereinstimmung deklariert werden. Nach einer Ausführungsform werden alle Diensttypen als übereinstimmend angesehen, wenn kein Typ angegeben ist. Zum Beispiel kann die Typzeichenkette beim Betrieb auf einem großen Netzwerk "space" oder beim Betrieb in einem Nachbarschaftsnetzwerk "service" sein. Zusätzliche Abstufungen von Typen können angewandt werden.
  • Somit können, wie bei 2072 in 42 angegeben, die Suchkriterien Dienstname und/oder Diensttyp mit dem Namen und der Typinformation für Dienste innerhalb der verteilten Rechnerumgebung verglichen werden. Jeder Dienstanbieter, der die Suchnachricht empfängt, kann diesen Vergleich durchführen. Oder es kann ein Horcher-Agent den Vergleich für Dienste durchführen, die bei dem Horcher-Agenten registriert sind.
  • Die optionalen Suchkriterienkomponenten können auch einen Kommentar (z. B. einen String bzw. eine Zeichenkette) umfassen. Die Kommentarzeichenkette kann im Hauptteil der Antwortnachricht zurückgegeben werden und kann ein nützliches Werkzeug zum Verfolgen von Auffindungsnachrichten darstellen. Zum Beispiel könnte ein Zeitstempel eine nützliche Kommentarzeichenkette sein.
  • Daraufhin kann eine Suchantwort an den Client zurückgeliefert werden, die Anzeigen für Dienste angibt, die die Suchkriterien erfüllen. Das Folgende ist für eine Ausführungsform ein Beispiel einer Antwortnachricht, die von einem Dienstanbieter als Antwort auf eine Suchnachricht gesendet (z. B. an einen Empfänger bzw. per Unicast gesendet) werden kann:
  • Figure 00470001
  • Die Antwortnachricht kann den Satz von Anzeigen beinhalten, der die Suchkriterien erfüllt. Nach einer Ausführungsform werden alle verfügbaren Anzeigen als passend definiert, wenn keine Suchkriterien angegeben wurden. Nach einer Ausführungsform enthält die Antwort auch denselben Kommentar, wenn eine Kommentarzeichenkette angegeben wurde, möglicherweise mit einem zusätzlichen Kommentar, der an das Ende der ursprünglichen Zeichenkette angehängt ist.
  • Wie oben erwähnt kann ein Dienst entweder eine geschützte Anzeige oder eine vollständige Anzeige veröffentlichen. Daher können die in einer Antwort auf eine Suche angegebenen Anzeigen geschützte oder vollständige Anzeigen sein. Eine geschützte Anzeige gibt möglicherweise nicht den tatsächlichen URI oder das tatsächliche Schema an, die benutzt werden können, um auf den Dienst zuzugreifen. Stattdessen kann eine geschützte Anzeige Information darüber enthalten, wie eine vollständige Anzeige erhalten werden kann, die den URI und das Schema zum Zugriff auf einige oder alle Fähigkeiten eines Dienstes enthält. Nach einer Ausführungsform kann eine geschützte Anzeige die folgende Information enthalten:
    • – Name und Typ des Dienstes
    • – Beschreibung der Fähigkeit des Dienstes
    • – UUID des Dienstes
    • – URI des Authentisierungsdienstes, der einen passenden Zugriffs-(Fähigkeiten)-Berechtigungsnachweis für den Client zurückliefert
    • – URI, wohin der Berechtigungsnachweis und die UUID gesendet werden kann, um eine vollständige Dienstanzeige zu erzeugen.
  • Eine geschützte Anzeige kann ein kleineres, Stellvertreterfragment eines XML-Dokumentes (eine Meta-Anzeige) sein. Eine geschützte Anzeige kann eine Stufe der Umlenkung zwischen dem Client und der wirklichen Anzeige vorsehen, wodurch es für den Client erforderlich ist, um den Zugriff auf die wirkliche Anzeige zu verhandeln. Eine geschützte Anzeige anstatt einer vollständigen Anzeige zu veröffentlichen, zwingt den Client dazu, einen gültigen Berechtigungsnachweis von einem Authentisierungsdienst zu erhalten, bevor er die vollständige, ungeschützte Anzeige von dem Dienstanbieter erhält.
  • Gemäß 41 kann der Client, nachdem er eine Antwort auf seine Suche empfangen hat, eine der Anzeigen für einen der Dienste auswählen, für den er den Zugang durch Anfordern eines Fähigkeitsberechtigungsnachweises aushandeln möchte, wie bei 2074 angegeben. Dieser Vorgang des Aushandelns der Anzeige kann für zusätzliche Sicherheit in der verteilten Rechnerumgebung sorgen (z. B. durch das Verbergen wirklicher Anzeigen), während er gleichzeitig zusätzliche Flexibilität bietet. Zum Beispiel kann ein Client während des Vorgangs des Aushandelns der Anzeige einen angepaßten Satz von Nachrichten zum Zugriff auf den Dienst anfordern. Der Client kann den gewünschten Namen und Typ der Schnittstelle übergeben. Ein Beispiel für das Anfordern eines angepaßten Satzes von Nachrichten kann sein, nur "Lese"-Zugriff im Gegensatz zu "Lese"- und "Schreib"-Zugriff auf einen Dienst anzufordern. Beim Anfordern eines angepaßten Satzes von Nachrichten kann der Client wünschen, nur eine Teilmenge der vollständigen Fähigkeiten (Nachrichten) des Dienstes zu benutzen. Das Recht zum Benutzen des angeforderten Satzes von Nachrichten kann während der Aushandlung überprüft werden. Wenn der Client nicht die passenden Zugriffsrechte für die angeforderten Fähigkeiten hat, scheitert das Aushandeln, ansonsten wird ein gültiger Berechtigungsnachweis an den Client zurückgeliefert.
  • Ein Client kann auch zusätzliche Zugriffsnachrichtensätze anfordern. Der Client kann den gewünschten Namen und Typ der Schnittstelle übergeben. Einige Clients können die Verwendung von mehr als nur den Basiszugriffsnachrichten anfordern. Ein Client kann einen Satz von zusätzlichen Zugriffsnachrichten anfordern. Einige von diese Zugriffsnachrichten können sogar plattformspezifische Sachverhalte wie Leistung bzw. Durchsatz und Größe der Speicherauslegung behandeln.
  • Ein Client kann auch anfordern, daß ein Nicht-XML-Inhaltstyp verwendet werden soll, um die in den Nachrichten zwischen Client und Dienst übergebenen Daten zu repräsentieren. Einige Clients unterstützen XML möglicherweise nicht, möchten aber dennoch auf Dienste innerhalb der verteilten Rechnerumgebung zugreifen. Um Nicht-XML-Clients Zugriff auf Dienste zu ermöglichen, kann Nicht-XML-Inhalt innerhalb einer XML-Nachricht getunnelt werden. Der Nicht-XML-Inhalt kann mit einem XML-Tag auf der sendenden Seite eingepackt und dann auf der empfangenden Seite extrahiert werden.
  • Dienstanbieter können von der Verwendung geschützter Anzeigen in verschiedener Hinsicht profitieren. Wie bereits erwähnt verhindern geschützte Anzeigen, daß nicht autorisierte Clients vollständige Anzeigen erhalten, und ermöglichen das Aushandeln der Fähigkeiten. Geschützte Anzeigen können auch die dynamische Erzeugung von Anzeigen ermöglichen. Wenn ein Client wegen einer vollständigen Anzeige verhandelt, besteht die Gelegenheit zum Erzeugen einer ad hoc angepaßten Anzeige. Diese Möglichkeit erlaubt es, kleinere XML-Dokumentfragmente in die Clients herunterzuladen, da eine vollständige Anzeige nur so groß wie nötig zu sein braucht. Diese Möglichkeit erlaubt es auch, daß ein Dienst für Clientanforderungen spezifische Anzeigen effektiv veröffentlicht.
  • Geschützte Anzeigen können auch Dienstanfragen erleichtern. Geschützte Anzeigen können anstelle von vollständigen Anzeigen veröffentlicht werden, um dynamische Suchen nach Diensten zu erleichtern, die zu dem vom Client angeforderten Satz von Fähigkeiten passen. Geschützte Anzeigen können die Fähigkeiten eines Dienstes in einem durchsuchbaren Format anzeigen, ohne ein vollständiges Nachrichtenschema für diese Eigenschaften zu beinhalten.
  • Nach einer Ausführungsform kann eine geschützte Anzeige die folgenden XML-Dokumentelemente umfassen:
    • – Name (für Menschen lesbare, nicht-kanonische Zeichenkette)
    • – Kanonischer Name des Dienstes (z. B. UUID)
    • – Beschreibung der Schnittstelle mit Basismethoden (Beschreibung der Nachrichtenschnittstelle)
    • – Titel (Standardname der Nachrichtenschnittstelle, der einen Typ mitteilt)
    • – Name des Bereitstellers (Name eines Standardisierungsgremiums)
    • – Version (Version des implementierten Standards (Typs))
    • – Info-URI (Webseite des Standardisierungsgremiums)
    • – Zusätzliche Beschreibungen der Zugriffsmethodenschnittstelle
    • – Liste von Beschreibungen, die enthält: Titel, Bereitsteller, Version, Info-URI.
    • – Beschreibungen des Inhaltstyps
    • – Liste von Beschreibungen, die enthält: Titel, Bereitsteller, Version, Info-URI.
    • – Berechtigungsnachweis
    • – Berechtigungsnachweis des Dienstes, um dem Client das Authentisieren des Dienstes zu ermöglichen
    • – Authentisierungs-URI
    • – Eine Nachricht kann hier gesendet werden, um einen passenden Berechtigungsnachweis zu erhalten, der Zugriff auf diesen Dienst gewährt.
    • – URI zum Erzeugen der realen Anzeige
    • – Eine Nachricht kann hier gesendet werden, um eine vollständige Anzeige zu einer vorliegenden geschützten Anzeige zu erzeugen, die die angeforderten Fähigkeiten des Client enthält.
  • Um eine vollständige Anzeige zu einer vorliegenden geschützten Anzeige zu erhalten, erhält der Client (z. B. die Gatterfabrik des Client) einen Fähigkeitsberechtigungsnachweis von dem angegebenen Authentisierungsdienst, indem er eine Nachricht zur Anforderung des Berechtigungsnachweises sendet, wie bei 2074 in 41 angegeben. Die Nachricht zur Anforderung des Berechtigungsnachweises kann an einen URI eines Authentisierungsdienstes gesendet werden, der in der Anzeige für den Dienst, auf den der Client zugreifen möchte, enthalten ist. Wenn die Anforderung des Client empfangen wird, wird ein Fähigkeitsberechtigungsnachweis erzeugt, wie bei 2075 angegeben. Der Fähigkeitsberechtigungsnachweis kann gemäß den von dem Client angeforderten Fähigkeiten und/oder der Autorisierungsstufe des Client erzeugt werden. Der Client empfängt daraufhin den Fähigkeitsberechtigungsnachweis in der Antwort auf seine Anforderung, wie bei 2076 angegeben. Die Antwort kann den zum Erzeugen einer vollständigen Anzeige nötigen Berechtigungsnachweis beinhalten. Dieser Berechtigungsnachweis kann derselbe Berechtigungsnachweis sein, den das Clientgatter in jede an den Dienst gesendete Nachricht einfügt.
  • Wenn die Anzeige eine geschützte Anzeige war, kann der Client danach eine Nachricht zur Anforderung der Anzeige senden, die den Fähigkeitsberechtigungsnachweis und eine Identifikation (z. B. eine UUID) des Dienstes enthält, an den zweiten, in der geschützten Anzeige angegebenen URI senden, wie bei 2078 angegeben. Der Client empfängt dann eine vollständige Anzeige, wie bei 2080 angegeben. Die Antwort auf diese zweite Nachricht ist die vollständige Anzeige des angegebenen Dienstes. Wenn die in der Anforderung eines Berechtigungsnachweises angegebene Anzeige bereits eine vollständige Anzeige war, können 2078 und 2080 übersprungen werden. 43 vergleicht den Unterschied in dem Auffindungsvorgang, wenn die veröffentlichte Anzeige eine vollständige Anzeige gegenüber einer geschützten Anzeige ist. Gemäß 42 können eine vollständige Anzeige und der Fähigkeitsberechtigungsnachweis daraufhin verwendet werden, um ein Gatter einzurichten, wie bei 2082 angegeben.
  • Es folgt gemäß einer Ausführungsform ein Beispiel einer Nachricht zur Anforderung des Berechtigungsnachweises:
  • Figure 00510001
  • Die Nachricht zur Anforderung des Berechtigungsnachweises kann eine Identifikation (z. B. eine UUID) des Dienstes beinhalten, auf den Zugriff gewünscht wird. Die Nachricht zur Anforderung des Berechtigungsnachweises kann auch einen Anzeigen-URI beinhalten, der auf die Anzeige verweist, oder die Anzeige (in Form eines Wertes) beinhaltet. Die Anzeige kann während dieses Aushandlungsvorgangs als Wert oder als Referenz übergeben werden. Anzeigen können vollständig oder geschützt sein. Wenn die in der Nachricht zur Anforderung des Berechtigungsnachweises übergebene Anzeige bereits eine vollständige Anzeige ist (z. B. der Dienst hat sie in der Suchantwort zurückgegeben), dann erlaubt der von dem Dienst zurückgegebene Berechtigungsnachweis Zugriff auf alle Fähigkeiten des Dienstes (all Zugriffsmethoden + alle Nachrichten).
  • Eine geschützte Anzeige kann so editiert bzw. herausgegeben werden, daß sie nur den gewünschten Satz von Zugriffsmethoden und Inhaltsbeschreibungen enthält. Die editierte geschützte Anzeige kann in einer Nachricht zur Anforderung des Berechtigungsnachweises übergeben werden. Somit kann ein Client seinen Satz von angeforderten Fähigkeiten durch Editieren der Anzeige oder durch Kopieren der relevanten Information von der ursprünglichen in eine neue Instanz aufbauen und ausdrücken.
  • Ein Beispiel einer Antwortnachricht auf eine Anforderung des Berechtigungsnachweises gemäß einer Ausführungsform ist wie folgt:
  • Figure 00510002
  • Wenn der Client eine passende Autorisierung besitzt, beinhaltet die Antwortnachricht auf eine Anforderung des Berechtigungsnachweises einen Fähigkeitsberechtigungsnachweis, der dem Client den angeforderten Zugriff auf den angegebenen Dienst gibt (z. B. durch die UUID bezeichnet), einschließlich des Satzes von Fähigkeiten, die in der geschützten Anzeige definiert sind. Dieser Berechtigungsnachweis kann daraufhin in dem Gatter des Client gespeichert und danach jeder an den Dienst gesendeten Nachricht hinzugefügt werden. Der Dienst verwendet dann diesen Berechtigungsnachweis zum Überprüfen der Rechte des Client, die Fähigkeiten eines Dienstes zu benutzen.
  • Die Struktur und Inhalte eines Fähigkeitsberechtigungsnachweises können durch den Dienst definiert werden. Nach einer Ausführungsform umfaßt der Berechtigungsnachweis mindestens eine Referenz auf die geschützte Anzeige, die während des Aushandelns verwendet wurde, und einen Sicherheitsschlüssel zum Validieren der Identität des Client. Wenn die in der Nachricht zur Anforderung des Berechtigungsnachweises übergebene Anzeige bereits eine vollständige Anzeige ist (z. B. der Dienst hat sie in der Suchantwort zurückgegeben), dann erlaubt der vom Dienst zurückgegebene Berechtigungsnachweis den Zugriff auf alle Fähigkeiten des Dienstes. Wenn der Dienstanbieter Berechtigungsnachweise überhaupt nicht unterstützt oder benötigt, kann die Antwortnachricht einen leeren Berechtigungsnachweis (Null) enthalten.
  • Nach einigen Ausführungsformen kann ein Fähigkeitsberechtigungsnachweis verwendet werden, um den Begriff einer Sitzung zu unterstützen. Ein Dienstanbieter kann eine Sitzungs-ID innerhalb des Berechtigungsnachweises einbetten und sicher sein, daß das Clientgatter ihn (den Berechtigungsnachweis mit der ID) in jeder Nachricht an den Dienstanbieter übergibt. Der ganze Berechtigungsnachweis kann durch den Dienstanbieter definiert werden und kann folglich jede beliebige Anzahl von Feldern einschließlich einer Sitzungs-ID oder anderer IDs zum Demultiplexen, etc. enthalten.
  • Gemäß einer Ausführungsform sieht ein Beispiel einer Nachricht zum Anfordern einer Anzeige folgendermaßen aus:
  • Figure 00520001
  • Die Nachricht zum Anfordern einer Anzeige beinhaltet den Berechtigungsnachweis aus der Antwortnachricht auf eine Anforderung des Berechtigungsnachweises. Nach einer Ausführungsform beinhaltet dieser Berechtigungsnachweis genügend Information zum Identifizieren der ursprünglichen geschützten Anzeige.
  • Ein Beispiel einer Antwortnachricht auf eine Anforderung einer Anzeige gemäß einer Ausführungsform ist wie folgt:
    Figure 00530001
    Die Antwortnachricht auf eine Anforderung einer Anzeige beinhaltet die vollständige Anzeige, die von der (editierten) geschützten Anzeige referenziert wird. Man beachte, daß der in der vollständigen Anzeige gefundene Berechtigungsnachweis der Berechtigungsnachweis des Gatters sein kann, der in jeder Nachricht übergeben wird.
  • Spaces werden von Diensten vom Typ Space implementiert. Das Auffinden eines Space kann entweder durch Angabe des "Space"-Typs in den Suchkriterien oder durch syntaktisches Analysieren des Satzes von Suchergebnissen und anschließendes Extrahieren aller "Space"-Anzeigen bewerkstelligt werden. Spaces können mit Anzeigen (geschützten oder ungeschützten) mittels des oben beschriebenen Auffindungsprotokolls besetzt bzw. gefüllt werden. Die Bestückung kann von dem Space-Dienst selbst oder von einem anderen Netzwerkdienstagenten in die Wege geleitet werden.
  • Sobald ein Space aufgefunden ist, wird sein Inhalt mittels standardmäßiger Space-Dienst-Navigationsnachrichten oder wie in der Anzeige des Space-Dienstes definiert überprüft. Für jede Anzeige innerhalb des Space kann eine Gatterfabrik des Client ein Gatter aufbauen (unter Verwendung des Berechtigungsnachweises und der Nachricht zum Anfordern einer Anzeige), um auf den genannten Dienst zuzugreifen.
  • Nach einer Ausführungsform enthalten alle Anzeigen (geschützte und vollständige) einen Berechtigungsnachweis des Dienstes. Clients können die Gültigkeit dieses Berechtigungsnachweises prüfen, bevor sie einen Fähigkeitsberechtigungsnachweis eines Client anfordern. Dieser Vorgang kann verhindern, daß unautorisierte Dienste Anzeigen mittels des Auffindungsprotokolls veröffentlichen.
  • Ein Beispiel für eine Implementierung eines Auffindungsprotokolls kann das Protokoll das Datenformat auf dem Draht(kabel) sein, das auf viele verschiedene Weisen abhängig von dem zugrundeliegenden Transportmedium implementiert sein kann. Die Implementierung des Auffindungsprotokolls kann in einer Plattformanbindung definiert sein. Zum Beispiel kann eine mögliche IP-Implementierung eine sein, in der Space-Dienste auf UDP-Aussendungen an mehrere Adressaten bzw. UDP-Multicasts von Suchnachrichten nach Spaces horchen. Ein Client/Dienst kann eine Suchnachricht nach Spaces, die eine Anzeige enthalten, gleichzeitig an mehrere Adressaten bzw. per Multicast senden und wartet auf eine Antwort. Space-Dienste können eine eine Anzeige enthaltende Antwortnachricht auf eine Suche nach Spaces an einen Adressaten bzw. per Unicast senden.
  • 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.
  • Wegen eines Beispiels von Feldern in Anforderungs- und Antwortnachrichten wird auf das SearchComment-Feld in der oben beschriebenen Suchnachricht und Antwort auf eine Suchnachricht verwiesen.
  • 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.
  • In einigen Situationen kann ein Client physikalisch die Einrichtung gefunden haben, die Dienste enthält, die der Client ablaufen lassen möchte. Zum Beispiel kann sich eine Person mit einem PDA-Client in enger Nachbarschaft zu einem Drucker aufhalten, der Teil der verteilten Rechnerumgebung ist. Verschiedene Szenarien können bei Einrichtungen in enger Nachbarschaft auftreten. Wenn sich Clients in enger Nachbarschaft von (z. B. Dienste veröffentlichenden) Einrichtungen aufhalten, kann vieles von dem Auffindungsvorgang vereinfacht werden. In diesen Fällen kann der Benutzer die Einrichtung auswählen. Zum Beispiel zeigen IRDA-Einrichtungen gegenseitig aufeinander, um eine Auffindungsverbindung aufzubauen.
  • Einrichtungen in enger Nachbarschaft, für die Sicherheit kein Problem ist (wie IRDA-Drucker) können vollständige Anzeigen veröffentlichen. Anstatt Dienste in Spaces zu kapseln, können Einrichtungen in enger Nachbarschaft direkt auf das Auffindungsprotokoll antworten.
  • Einrichtungen in enger Nachbarschaft, für die Sicherheit ein Problem ist (z. B. ein Geldausgabeautomat bzw. ATM), können auf Auffindungsanforderungen mit geschützten Space-Anzeigen antworten. Der Space kann alle Dienste beinhalten, die von der Einrichtung unterstützt werden. Sobald Zugriff auf den Space gewährt wurde, können Clients die vollständigen, in dem Space gespeicherten Anzeigen durchsuchen. Dieses Modell geht davon aus, daß alle in dem Space gespeicherten Dienste aus dem Sicherheitsmodell des Space Nutzen ziehen können und kein separates Modell vorsehen. Alternativ können Einrichtungen in enger Nachbarschaft, für die Sicherheit ein Problem ist, auf Auffindungsanforderungen mit geschützten Anzeigen für jeden Dienst antworten. Jeder Dienst kann seinen eigenen Authentisierungsdienst bereitstellen. Kombinationen jedes Szenarios bei Nachbarschaftseinrichtungen werden ebenfalls in Betracht gezogen.
  • 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.
  • Ein Beispiel eines Systems, in dem eine Clienteinrichtung direkt einen Dienst auf einer Diensteinrichtung über eine Nachbarschaftsverbindung auffindet, ist in 44 dargestellt. Eine Clienteinrichtung 2150 beinhaltet einen Nachbarschaftsanschluß (z. B. einen IrDA-Anschluß) 2156, der dafür eingerichtet ist, eine direkte Punkt-zu-Punkt-Kommunikationsverbindung oder Nachbarschaftsverbindung zu bilden. Die Clienteinrichtung 2150 kann einen Client 2152 beinhalten, der einen Dienst über die Nachbarschaftsverbindung benutzen möchte. Der Client 2150 kann eine Anwendung oder eine Kombination von Schaltungen und Software sein. Eine Clientschnittstelle 2154 kann dafür eingerichtet sein, über die Nachbarschaftsverbindung direkt ein Dokument anzufordern, das eine Schnittstelle zum Zugriff auf einen gewünschten Dienst beschreibt. Die Schnittstelle 2154 kann auch dafür eingerichtet sein, ein solches Dokument direkt über die Punkt-zu-Punkt-Kommunikationsverbindung zu empfangen und die Information aus dem Dokument zum Zugriff auf den Dienst wie durch das Einrichten eines Gatters zu verwenden.
  • Eine Diensteinrichtung 2170 kann einen Nachbarschaftsanschluß 2172 beinhalten und kann eine Nachbarschaftsverbindung mit der Clienteinrichtung 2150 bilden. Die Diensteinrichtung 2170 kann Code und/oder Hardware zum Implementieren eines oder mehrerer Dienste 2176 beinhalten. Die Diensteinrichtung 2170 kann auf dafür eingerichtet sein, ein oder mehrere Dokumente 2178 oder Anzeigen über eine Nachbarschaftsverbindung zu übergeben. Eine Anzeige 2178 kann ein Nachrichtenschema zum Zugriff auf einen Dienst 2176 beschreiben, der von der Diensteinrichtung 2170 bereitgestellt wird. Eine Dienstschnittstelle 2174 kann dafür eingerichtet sein, von einem Client über eine Nachbarschaftsverbindung eine Anforderung eines Dokumentes 2178 zu empfangen, das eine Schnittstelle zum Zugriff auf einen Dienst 2176 beschreibt. Die Schnittstelle 2174 kann auch dafür eingerichtet sein, das Dokument über die Nachbarschaftsverbindung direkt an einen Client zu übergeben und einen Nachrichtenendpunkt (z. B. ein Gatter) zur Kommunikation mit einem Client bereitzustellen. Die Dienstschnittstelle kann auch einen Mechanismus zum Authentisieren von Anforderungen des Clients, auf den Dienst zuzugreifen, zur Verfügung stellen.
  • 45 stellt ein grundlegendes Flußdiagramm dar, das die Auffindung eines Nachbarschaftsdienstes durch einen Client veranschaulicht. Ein Client kann eine Nachbarschaftsverbindung zu einer Diensteinrichtung bilden bzw. aufbauen, wie bei 2190 angegeben. Zum Beispiel kann eine Clienteinrichtung ein persönlicher digitaler Assistent (Personal Digital Assistant, PDA) mit einem Adreßbuch-Client sein. Der Client könnte den Bedarf haben, einen Teil des Adreßbuchs auszudrucken. Der PDA kann einen IrDA-Anschluß beinhalten und kann sich in der Nähe eines Druckers mit einem IrDA-Anschluß befinden. Der Client kann eine Nachbarschaftsverbindung zu dem Drucker aufbauen. Der Client kann danach, wie bei 2192 angegeben, eine Dienstanzeige wie eine Anzeige des Druckdienstes über die Nachbarschaftsverbindung anfordern. Der Client kann dann eine Anzeige empfangen, die seiner Anforderung entspricht, wie bei 2194 angegeben. Die Anzeige kann über die Nachbarschaftsverbindung direkt von der Diensteinrichtung empfangen werden. Der Client kann dann gemäß der Anzeige ein Gatter zum Zugriff auf den Dienst aufbauen, wie bei 2196 angegeben.
  • Somit können Nachbarschaftseinrichtungen den Overhead bzw. die Zusatzlast der Verwendung von Spaces als Rendezvous-Punkt für Clients zum Auffinden von Diensten vermeiden. 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 Einrichtung kann eine lokal veröffentlichte Dienstannonce für die nachbarschaftsbezogene Einrichtung mit einem Auffindungs- und/oder Nachschlagedienst lokalisieren, oder alternativ kann die Dienstannonce von der lokalen Diensteinrichtung nicht veröffentlicht werden, sondern stattdessen von der lokalen Einrichtung beim Aufbau einer Verbindung an die veröffentlichende Einrichtung gesendet werden, wie oben beschrieben. 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.
  • 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 Wiederfinden von Annoncen und zur Darstellung des Zustandes von Annoncenelementen bereitstellen, das ausreicht, um das Annoncenobjekt oder die Annoncenobjekte wiederherzustellen. Annoncen können auch in anderen Formaten gespeichert werden, abhängig von der Implementierung des Archivierungsdienstes. Der Vorgang, eine veröffentlichte Annonce dauerhaft zu machen, kann die Annonce für den Zustand "dauerhaft archiviert" vorbereiten. Dauerhafte Annoncen können für eine zukünftige Verwendung in einer dauerhaften Speicherstelle wie einer Datei oder einer Datenbank gespeichert werden (z. B. von einem Archivierungsdienst). Ein Space kann es durch den Archivierungsvorgang möglich machen, daß Annoncen gespeichert werden, jedoch spielt der Space nicht notwendigerweise eine Rolle dabei, wie dauerhafte Annonceneinträge tatsächlich gespeichert werden. Wie dauerhafte Annoncen gespeichert werden, kann von dem Archivierungsdienst der Annonce bestimmt werden. Typischerweise werden keine Ereignisse im Namen von archivierten Annoncen erzeugt. Ebenso kann es sein, daß Änderungen an Annoncen in dem Zustand "dauerhaft archiviert" nicht erlaubt sind.
  • Annoncen 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 (multicast UDP) verwenden, um sich auf einem LAN anzukündigen. Ein Horcher-Agent kann diese Information aufzeichnen. Eine Einrichtung (entweder ein Client oder eine Dienst) kann das Multicast Request Protocol (multicast UDP) verwenden, um das Auffinden eines Space-Managers in die Wege zu leiten. 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.
  • Jede 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 Erweiterurng 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 spezifizier 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.
  • Wenn sich ein Client eines Space anmeldet, um benachrichtigt zu werden, wenn ein XML-Dokument oder XML-Dokumente (z. B. eine Dienstanzeige) hinzugefügt oder aus dem Space entfernt werden, kann der Client eine Überlassung bzw. Pacht auf diese Anmeldung für Benachrichtigungen erhalten. Die Überlassung kann es dem Space-Dienst ermöglichen zu wissen, ob er mit dem Senden von Benachrichtigungen an einen bestimmten Client weitermachen soll. Zum Beispiel kann eine Überlassung auf die Benachrichtigungsfunktion nach einer bestimmten Zeit ablaufen bzw. erlöschen, wenn sie nicht erneuert wird. Man beachte, daß eine Überlassung möglicherweise nicht nötig ist, während ein Client eine aktive Sitzung mit einem Space aufgebaut hat. Sobald ein Client eine aktive Sitzung mit einem Space abgebrochen bzw. unterbrochen hat, kann der Client weiter Ereignisbenachrichtigungen gemäß seiner Ereignisanmeldung empfangen, solange seine entsprechenden Überlassungen aktiv bleiben. Siehe den Abschnitt über Überlassungen (leasing) unten.
  • Ein Client kann sich für unterschiedliche Arten von Ereignissen anmelden. Beispiele sind das Hinzufügen einer Dienstanzeige oder das Entfernen einer Dienstanzeige aus einem Space, wie oben beschrieben. Ein Client kann auch benachrichtigt werden, wenn Ergebnisse von einem Dienst, die von einem Client (oder von jemandem sonst) veranlaßt wurden, in einen Space gestellt werden. Zum Beispiel können der Client und der Dienst gegenseitig einen Namen zum Referenzieren auf die Ergebnisse des Dienstes wählen. Der Client kann sich bei dem Space-Dienst registrieren, dem die Ergebnisse bekannt gegeben oder angekündigt werden sollen, um ein Ereignis zu empfangen, wenn ein mit dem gewählten Namen aufgerufenes Ergebnis dem Space hinzugefügt wird.
  • Ein Space kann verschiedene Arten von Ereignissen bzw. Veranstaltungen erzeugen, für die sich ein Client anmelden kann. Wenn sich die Zusammensetzung eines Space ändert, können Ereignisse für diejenigen Clients und Dienste erzeugt werden, die sich für solche Ereignisse angemeldet haben. Nach einer Ausführungsform kann es zwei Hauptkategorien von Space-Ereignissen geben, diejenigen, die sich auf den Space (Einfügen und Entfernen von Anzeigen) beziehen und diejenigen, die zur Anzeige von Änderungen einer Anzeige (Hinzufügen, Entfernen, Ändern eines Elementes oder Attributs) verwendet werden. Welche Ereignisse unterstützt werden, kann in dem XML-Nachrichtenschema für den Space angegeben werden.
  • Die folgenden Ereignisse sind Beispiele von Ereignissen, die von einem Space-Dienst erzeugt werden können, um ein Space- oder Anzeigenereignis anzuzeigen:
  • Tabelle 1 Space-Ereignisse
    Figure 00760001
  • 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.
  • 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.
  • Ü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:
  • Figure 00840001
  • 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 denn 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 tyrpisierte 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 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 dart. Da die Gatter sicherstellen können, daß jeder Nachricht den Authentisierungsnachweis enthält, kann der Dienst dann jede Anforderung, wenn sie empfangen wird, gegen die Leistungsmerkmale des authentisierten Client prüfen.
  • Die Prüfungen bei der Gattererzeugung können sicherstellen, daß ein Client die Berechtigung hat, einige oder alle Leistungsmerkmale des Dienstes zu benutzen, die durch das XML-Nachrichtenschema bestimmt sind. 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 Identifikationsvertahren 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. Wenn ein Anforderer einen Space erzeugt hat, kann es nur dem Anforderer erlaubt sein, auf den erzeugten Space zuzugreifen. Zum Beispiel kann der erzeugte Space zum Speichern von Ergebnissen von einem Dienst vorgesehen sein, die der Client gesichert halten muß. Diese Sicherheit kann sichergestellt werden durch:
    • – Erzeugen eines anfänglichen Wurzel-Authentisierungsnachweises und Initialisieren des Authentisierungsdienstes des erzeugten Space, so daß der Authentisierungsdienst nur den Wurzel-Authentisierungsnachweis authentisiert und so daß er keine anderen Authentisierungsnachweise zurückliefert (keine anderen Clients des erzeugten Space sind anfänglich zugelassen).
    • – Initialisieren der Sicherheitsrichtlinien des erzeugten Space, so daß die dem Wurzel-Authentisierungsnachweis zugeordnete Wurzel-Identität auf alle Funktionen des Space einschließlich der Funktionen für die Sicherheitsverwaltung Zugriff hat.
    • – Zurückliefern des Wurzel-Authentisierungsnachweises und der Dienstannonce des erzeugten Space an den Anforderer des erzeugten 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 Rechnerumgebung verwendet werden.
  • Bluetooth ist ein aufkommender Peer-to-Peer-Standard für drahtlose Kommunikation. Die Algorithmen zum Erzeugen von Schlüsseln bei Bluetooth können in der verteilten 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.
  • Fig. 26a – Ein Authentisierungsdienst, der einen Authentisierungsnachweis für einen Client bereitstellt
  • 26a ist ein Flußdiagrarnm, 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 Gatterfabrik erstellt, die den Authentisierungsnachweis in das Nachrichtengatter aufnimmt, wodurch das Nachrichtengatter den Authentisierungsnachweis in jede Nachricht einbezieht, die im Namen des Client an den Dienst gesendet wird. Beim Empfang eine Nachricht kann der Dienst dann den Authentisierungsnachweis überprüfen. Da nur der Authentisierungsdienst den 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 Authentisierungsnachweises 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.
  • Fig. 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 Bezeichnen 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 Entetprise 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:
  • Figure 01120001
  • Das obenstehende Schema kann in das folgende geändert werden, ohne daß eine Anwendung erneut kompiliert werden muß:
  • Figure 01120002
  • 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 (Zeichenkettel bzw. stringl) 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:
    • char *strcpy(char *dest, const char *src);
    • char *strncpy(char *dest, const char *src, size_tn);
  • 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 Rest 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:
    Figure 01150001
    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:
  • Figure 01160001
  • Figure 01170001
  • 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-API 1530 ein Java-Objekt 1510 als Eingabe akzeptieren und eine XML-Repräsentation des Objektes 1510 und aller von ihm referenzierten Objekte (des Objektgraphen des Objektes 1510) in einem XML-Datenstrom 1514 ausgeben. Darüber hinaus kann das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 einen XML-Datenstrom 1522 akzeptieren, der eine XML-Repräsentation des Objektes 1520 und aller von ihm referenzierten Objekte (des Objektgraphen des Objektes 1520) enthält, und das Java-Objekt 1520 (und alle Objekte in seinem Objektgraphen) ausgeben.
  • 35a stellt eine Ausführungsform dar, in der der Client beim Senden des Java-Objektes 1510 das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufruft. Der Client 1500 übergibt das Java-Objekt 1510 an das API 1530, welches das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert die XML-Repräsentation in dem XML-Datenstrom 1514 und gibt den XML-Datenstrom 1514 aus. Der Client kann daraufhin den XML-Datenstrom 1514 an das Gatter 1504 übergeben. Das Gatter 1504 kann dann den XML-Datenstrom 1514 in eine XML-Nachricht 1516 verpacken und die Nachricht 1516 an den Dienst 1502 senden.
  • Beim Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann das Gatter 1522 den XML-Datenstrom 1522 aus der Nachricht 1524 extrahieren und den Datenstrom 1522 an den Client 1500 übergeben. Der Client 1500 kann daraufhin das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufrufen, wobei er dem API 1530 den XML-Datenstrom 1522 übergibt. Das API 1530 kann dann den XML-Datenstrom 1522 dekompilieren, um das Java-Objekt 1520 und die anderen Objekte in seinem Objektgraphen zu erstellen, wobei es die Objekte an den Client 1500 zurückgibt.
  • 35b stellt eine andere Ausführungsform dar, bei der das JVM-XML-Kompilierungs/Dekompilierungs-API 1530 beim Senden des Java-Objektes 1510 von dem Gatter aufgerufen wird. Der Client 1500 übergibt das Java-Objekt 1510 an das Gatter 1504. Das Gatter 1504 übergibt daraufhin das Objekt 1510 an das API 1530, das das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert die XML-Repräsentation in dem XML-Datenstrom 1514 und gibt den XML-Datenstrom 1514 aus. Das Gatter 1504 kann dann den XML-Datenstrom 1514 in eine XML-Nachricht 1516 verpacken und die Nachricht 1516 an den Dienst 1502 senden.
  • Beim Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann das Gatter 1522 den XML-Datenstrom 1522 aus der Nachricht 1524 extrahieren und den Datenstrom 1522 an das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 übergeben. Das API 1530 kann dann den XML-Datenstrom 1522 dekompilieren, um das Java-Objekt 1520 und die anderen Objekte in seinem Objektgraphen zu erstellen. Das Gatter kann daraufhin das Java-Objekt 1520 und die anderen Objekte an den Client 1500 senden.
  • 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 Mal 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:
  • Figure 01290001
  • 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 computer-basierte Objekte einschließlich Objektinstanzen von Klassen aus anderen Programmiersprachen angewendet werden. Darüber hinaus soll das Verfahren nicht auf XML-Repräsentationen von Objektinstanzen eingeschränkt werden; andere Darstellungsformate einschließlich anderer Datenrepräsentationssprachen (wie HTML) können anstelle von XML eingesetzt werden.
  • XML-basierte Prozeßmigration
  • Die verteilte Rechnerumgebung kann die Verteilung und Verwaltung von verteilten Anwendungen ermöglichen. Zum Beispiel kann die verteilte Rechnerumgebung mobile Clients umfassen, die an Stationen angedockt werden können, die Monitore, Drucker, Tastaturen und verschiedene andere Eingabe/Ausgabe-Einrichtungen bereitstellen, die typischerweise auf mobilen Einrichtungen wie PDAs, Mobiltelefonen, etc. nicht verfügbar sind. Diese mobilen Clients können eine oder mehrere Anwendungen ablaufen lassen und können von einer Station zu einer anderen in der verteilten Rechnerumgebung migrieren. Daher kann eine Ausführungsform der verteilten Rechnerumgebung ein Verfahren zur Migration einer Anwendung (eines Prozesses), die bzw. der gerade ausgeführt wird, mit ihrem bzw. seinem gesamten Zustand von einem mobilen Client an einem Knoten zu demselben mobilen Client oder einem anderen mobilen Client an einem anderen Knoten in der verteilten Rechnerumgebung zur Verfügung stellen.
  • 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 XMLbasierten 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 Clienteinrchtung 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 Vertü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 Benutzerjede 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-Nachrchtensystems zum Senden von Anforderungen an und Empfang von Antworten von den eingebetteten Einrichtungen 1804a und 1804b verfügen. Nach einer Ausführungsform kann das Steuerungssystem 1800 Software und Hardware beinhalten, die dafür eingerichtet ist, eine Schnittstelle darzustellen, um einem Benutzer das Anzeigen des Zustandes und die Steuerung der eingebetteten Einrichtungen 1804a und 1804b aus der Ferne zu ermöglichen. Nach einer Ausführungsform kann das Steuerungssystem 1800 Software und/oder Hardware zur automatischen Steuerung der eingebetteten Einrichtungen 1804a und 1804b beinhalten.
  • Nach einer Ausführungsform können die eingebetteten Einrichtungen 1804a und 1804b Teil einer anderen Umgebung sein. Die Einrichtungen unterstützen das von der verteilten Rechnerumgebung implementierte Modell zur Nachrichtenübergabe möglicherweise nicht. Zum Beispiel können die Einrichtungen Knoten in einem vernetzten Automatisierungs- und Steuerungssystem wie einem LonWorks-Netzwerk sein. Das Steuerungssystem 1800 kann eine Steuerungssystem-Hardware und/oder -Software zur Steuerung der Einrichtungen in der anderen Umgebung beinhalten. Das Steuerungssystem 1800 kann als eine Brücke zwischen der verteilten Rechnerumgebung und der anderen Umgebung dienen. Die verteilte Rechnerumgebung kann auch ein Verfahren oder (mehrere) Verfahren bereitstellen, um vorhandene Auffindungsprotokolle für Einrichtungen zum Auffinden von Einrichtungen für einen Zugriff aus der verteilten Netzwerkumgebung zu umhüllen. Protokolle zur Brückenbildung und zum Umhüllen sind in dem Abschnitt zur Überbrückung weiter beschrieben.
  • Das Steuerungssystem 1800 kann entfernt oder lokal an ein oder mehrere andere Systeme in der verteilten Rechnerumgebung angeschlossen sein. 40a zeigt das Steuerungssystem 1800, das über das Internet 1802 an den Client 1806 angeschlossen ist. Der Client 1806 kann indirekt den Zustand der eingebetteten Einrichtungen 1804a und 1804b anfordern und Steuerungsanforderungen an die eingebetteten Einrichtungen 1804a und 1804b senden. Somit kann das Steuerungssystem 1800 als ein Proxy oder eine Brücke für die eingebetteten Einrichtungen 1804a und 1804b dienen. Siehe den Abschnitt zur Überbrückung. Um eine differenzierte Kommunikation zwischen dem Client 1806 und dem Steuerungssystem 1800 zu ermöglichen, können der Client und das Steuerungssystem andere Implementierungen des XML-Nachrichtensystems als die dünne Implementierung auf den eingebetteten Einrichtungen 1804a und 1804b haben. Nach einer Ausführungsform kann der Client 1806 Software und Hardware beinhalten, die dafür eingerichtet ist, eine Schnittstelle darzustellen, um einem Benutzer des Client 1806 das Anzeigen des Zustandes der eingebetteten Einrichtungen 1804a und 1804b und die Steuerung der eingebetteten Einrichtungen 1804a und 1804b aus der Ferne zu ermöglichen. Nach einer Ausführungsform muß der Client 1806 dem Steuerungssystem 1800 den richtigen Autorisierungsnachweis vorlegen, um dem Client 1806 einen Zugriff auf die eingebetteten Einrichtungen 1804a und 1804b zu ermöglichen. Nach einer Ausführungsform kann dem Client 1806 der Zugriff auf verschiedenen Stufen gewährt werden. Zum Beispiel kann der Client 1806 nur in der Lage sein, den Zustand der eingebetteten Einrichtungen 1804a und 1804b anzusehen, jedoch ist ihm die Steuerung der Einrichtungen aus der Ferne möglicherweise nicht erlaubt. Nach einer Ausführungsform kann das Steuerungssystem 1800 ein Dienst sein, kann eine in der verteilten Rechnerumgebung veröffentlichte Dienstannonce haben, und somit kann darauf durch einen Client 1806 mittels der Client-Dienst-Verfahren wie zuvor in diesem Dokument beschrieben zugegriffen werden. Nach einer Ausführungsform kann der Client 1806 in der Lage sein, den Zustand des Steuerungssystems 1800 zu betrachten und das Steuerungssystem 1800 aus der Ferne zu steuern.
  • 40b stellt das Client-Steuerungssystem 1808 dar, das gemäß einer Ausführungsform über das Internet 1802 mit den eingebetteten Einrichtungen 1804c und 1804d verbunden ist. Nach einer Ausführungsform können die eingebetteten Einrichtungen 1804c und 1804d eine dünne Implementierung des XML-Nachrichtensystems zur Kommunikation mit dem Client-Steuerungssystem 1808 über das Internet 1802 beinhalten. Das Client-Steuerungssystem 1808 kann eine Implementierung des XML-Nachrichtensystems zum Senden von Anforderungen an die und zum Empfang von Antworten von den eingebetteten Einrichtungen 1804c und 1804d beinhalten. Nach einer Ausführungsform kann das Client-Steuerungssystem 1808 Software und Hardware beinhalten, die dafür eingerichtet ist, eine Schnittstelle darzustellen, um einem Benutzer das Anzeigen des Zustandes der eingebetteten Einrichtungen 1804c und 1804d und die Steuerung der eingebetteten Einrichtungen 1804c und 1804d aus der Ferne zu ermöglichen. Nach einer Ausführungsform kann das Client-Steuerungssystem 1808 Software und/oder Hardware zur automatischen Steuerung der eingebetteten Einrichtungen 1804c und 1804d beinhalten, Ein Unterschied zwischen 40a und 40b besteht darin, daß in der in 40b dargestellten Ausführungsform auf die eingebetteten Einrichtungen 1804c und 1804d von einem oder mehreren Clients in der verteilten Rechnerumgebung zugegriffen werden kann, ohne einen Proxy (z. B. ein Steuerungssystem) zu benötigen. Die eingebetteten Einrichtungen 1804c und 1804d können Dienste zum Zugriff auf die Funktionalität der Einrichtungen umfassen, können Dienstannoncen in der verteilten Rechnerumgebung veröffentlicht haben und auf sie kann somit mittels des Client-Dienst-Verfahrens, wie zuvor in diesem Dokument beschrieben zugegriffen werden.
  • Die verteilte Rechnerumgebung kann einen Mechanismus für bezüglich ihrer Ressourcen beschränkte Clients zum Holen von per Universal Resource Identifier (URI) adressierten Ressourcen umfassen. Zum Beispiel kann ein Client, der nur zum Senden und Empfangen von Nachrichten über eine IrDA-Verbindung in der Lage ist, nicht in der Lage sein, eine URI-Verbindung zum Abholen von Ergebnissen aus einem Ergebnis-Space aufzubauen. Nach einer Ausführungsform kann ein Dienst als eine Brücke zwischen dem Client und der URI-Ressource bereitgestellt werden. Der Brücken-Dienst kann mit dem Client mittels XML-Nachrichten interagieren, um Eingabeparameter aufzunehmen. Das Folgende ist als ein Beispiel einer Syntax von XML-Eingabenachrichten aufgenommen und soll in keiner Weise einschränkend sein:
  • Figure 01440001
  • 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:
  • Figure 01450001
  • Figure 01460001
  • 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.

Claims (40)

  1. Verfahren für das Zugreifen auf benachbarte Dienste, das aufweist: eine Clientvorrichtung (2150), die eine direkte Punkt-zu-Punkt-Kommunikationsverbindung mit einer Serviceeinrichtung (2170) bildet (2190), wobei die Clienteinrichtung direkt bei der Serviceeinrichtung ein Dokument abfragt (2190), das eine Schnittstelle für den Zugriff auf einen Dienst, der von der Serviceeinrichtung bereitgestellt wird, beschreibt, wobei die Clientvorrichtung das Dokument direkt von der Serviceeinrichtung empfängt (2194), wobei das Dokument Information aufweist, die beschreibt, wie auf den Service zuzugreifen ist, wobei das Abfragen und das Empfangen über die direkte Punkt-zu-Punkt-Kommunikationsverbindung durchgeführt wird, und wobei die Clientvorrichtung die Information von dem Dokument verwendet, um auf den Service bzw. den Dienst zuzugreifen (2196).
  2. Verfahren nach Anspruch 1, wobei das Abfragen aufweist, daß der Client eine Abfrageankündigungsnachricht für den Dienst zu der Diensteinrichtung über die direkte Punktzu-Punkt-Kommunikationsverbindung sendet, wobei die Abfrageankündigungsnachricht in einer Datendarstellungssprache ist.
  3. Verfahren nach Anspruch 2, wobei die Datendarstellungsnachricht die eXtensible-Mark-up-Sprache (XML) ist.
  4. Verfahren nach einem der vorherigen Ansprüche, wobei das Dokument eine Dienstankündigung (2178) für den Dienst aufweist, wobei die Dienstankündigung ein Schema aufweist, das eine Schnittstelle zu zumindest einem Teil des Dienstes spezifiziert.
  5. Verfahren nach Anspruch 4, wobei das Schema ein eXtensible-Markup-Language (XML)-Schema ist, das XML-Nachrichten definiert, damit ein Client auf der Clientvorrichtung diese zu dem Dienst und der Dienst diese zu dem Client sendet, um für den Client Zugriff auf die Fähigkeiten des Dienstes zu haben.
  6. Verfahren nach Anspruch 5, in dem die Clienteinrichtung, die die Informationen von dem Dokument verwendet, den Client aufweist, der ein oder mehrere der XML-Nachrichten zu dem Dienst über die direkte Punkt-zu-Punkt-Kommunikationsverbindung sendet.
  7. Verfahren nach einem der vorherigen Ansprüche, wobei das Empfangen des Dokumentes in einer Anfrageankündigungsantwortnachricht aufweist, die von dem Dienst über die direkte Punkt-zu-Punkt-Kommunikationsverbindung gesendet wird, wobei die Anfrageankündigungsantwortnachricht in einer Datendarstellungssprache ist.
  8. Verfahren nach Anspruch 7, wobei die Datendarstellungssprache die eXtensible-Markup-Language (XML) ist.
  9. Verfahren nach einem der vorherigen Ansprüche, wobei die Clienteinrichtung in physischer Nähe zu der Dienst- bzw. Serviceeinrichtung ist.
  10. Verfahren nach einem der Ansprüche 1 bis 8, wobei die direkte Punkt-zu-Punkt-Kommunikationsverbindung eine IrDA-Infrarotverbindung ist.
  11. Verfahren nach einem der Ansprüche 1 bis 8, wobei die Clientvorrichtung in Funknähe der Serviceeinrichtung ist.
  12. Verfahren nach einem der vorherigen Ansprüche, wobei das Abfragen das Einbeziehen eines Clientsicherheitsberechtigungsnachweises in einer Anfrage an die Serviceeinrichtung für dieses Dokument aufweist, und wobei die Serviceeinrichtung den Clientsicherheitsberechtigungsnachweis authentifiziert, bevor es das Dokument zu der Clienteinrichtung sendet.
  13. Verfahren nach einem der vorherigen Ansprüche, wobei die Clienteinrichtung, die die Information von dem Dokument verwendet, um auf den Dienst zuzugreifen, aufweist: einen Client auf der Clienteinrichtung, die einen Sicherheitsberechtigungsnachweis von einem Authentifizierungsservice abfragt, der in dem Dokument spezifiziert ist, wobei der Client den Sicherheitsberechtigungsnachweis empfängt, und wobei der Client den Sicherheitsberechtigungsnachweis in einer nachfolgenden Anfrage zu dem Dienst aufnimmt, um auf eine Fähigkeit des Dienstes zuzugreifen.
  14. Verfahren nach Anspruch 13, das weiterhin den Dienst des Verifizierens des Sicherheitsberechtigungsnachweises des Clients vor dem Erlauben des Zugriffs auf die Fähigkeit aufweist.
  15. Verfahren nach Anspruch 14, wobei der Authentifizierungsdienst von der Serviceeinrichtung bereitgestellt wird.
  16. Verfahren nach einem der vorherigen Ansprüche, wobei die Clienteinrichtung eine Transportverbindung zusätzlich zu der direkten Punkt-zu-Punkt-Kommunikationsverbindung unterstützt, wobei die Clienteinrichtung, die die Information von dem Dokument verwendet, um auf den Dienst zuzugreifen, die Clienteinrichtung aufweist, die das Dokument anderen Einrichtungen über die Transportverbindung verfügbar macht, wobei die Clienteinrichtung eine Brücke von der Transportverbindung zu der direkten Punkt-zu-Punkt-Kommunikationsverbindung bereitstellt, so daß die anderen Einrichtungen auf den Dienst zugreifen können.
  17. Verfahren nach Anspruch 16, wobei die Transportverbindung eine Netzwerkverbindung aufweist.
  18. Verfahren nach Anspruch 17, wobei die Netzwerkverbindung eine Internetverbindung aufweist.
  19. System, das aufweist: eine Serviceeinrichtung (2170), die derart konfiguriert ist, daß sie eine direkte Punkt-zu-Punkt-Kommunikationsverbindung unterstützt und einen Dienst bereitstellt, eine Clienteinrichtung (2150), die derart konfiguriert ist, daß sie die direkte Punkt-zu-Punkt-Kommunikationsverbindung mit der Serviceeinrichtung bildet, wobei die Clienteinrichtung weiterhin derart konfiguriert ist, daß sie direkt von der Serviceeinrichtung ein Dokument anfordert, das eine Schnittstelle beschreibt, um auf den Dienst zuzugreifen, wobei die Serviceeinrichtung weiterhin derart konfiguriert ist, daß sie das Dokument direkt über die direkte Punkt-zu-Punkt-Kommunikationsverbindung der Clienteinrichtung zur Verfügung stellt, und wobei die Clienteinrichtung weiterhin derart konfiguriert ist, daß sie die Information von dem Dokument verwendet, um auf den Dienst zuzugreifen.
  20. System nach Anspruch 19, wobei die Clientvorrichtung derart konfiguriert ist, daß sie das Dokument durch Senden einer Abfrageankündigungsnachricht für den Dienst zu der Diensteinrichtung über die direkte Punkt-zu-Punkt-Kommunikationsverbindung sendet, wobei die Abfrageankündigungsnachricht in einer Datendarstellungssprache ist.
  21. System nach Anspruch 20, wobei die Datendarstellungssprache die eXtensible-Markup-Language (XML) ist.
  22. System nach einem der Ansprüche 19 bis 21, wobei das Dokument eine Dienstankündigung (2178) für den Dienst aufweist, wobei die Dienstankündigung ein Schema aufweist, das eine Schnittstelle zu zumindest einem Teil des Dienstes spezifiziert.
  23. System nach Anspruch 22, wobei das Schema ein eXtensible-Markup-Language (XML)-Schema ist, das XML-Nachrichten definiert, damit ein Client auf der Clientvorrichtung diese zu dem Dienst und der Dienst diese zu dem Client sendet, um für den Client Zugriff auf die Fähigkeiten des Dienstes zu haben.
  24. System nach Anspruch 23, wobei die Clienteinrichtung derart konfiguriert ist, daß sie die Information von dem Dokument verwendet, um ein oder mehrere der XML-Nachrichten zu dem Dienst über die direkte Punkt-zu-Punkt-Kommunikationsverbindung zu senden.
  25. System nach einem der Ansprüche 19 bis 24, wobei die Clienteinrichtung derart konfiguriert ist, daß sie das Dokument in einer Anfrageankündigungsantwortnachricht empfängt, die von dem Dienst für die direkte Punkt-zu-Punkt-Kommunikationsverbindung gesendet wird, wobei die Anfrageankündigungsantwortnachricht in einer Datendarstellungssprache ist.
  26. System nach Anspruch 25, wobei die Datendarstellungssprache die eXtensible-Markup-Language (XML) ist.
  27. System nach einem der Ansprüche 19 bis 26, wobei die Clienteinrichtung in physischer Nähe zu der Serviceeinrichtung ist.
  28. System nach einem der Ansprüche 19 bis 26, wobei die direkte Punkt-zu-Punkt-Kommunikationsverbindung eine IrDA-Infrarotverbindung ist.
  29. System nach einem der Ansprüche 19 bis 26, wobei die Clienteinrichtung in Funknähe der Serviceeinrichtung ist.
  30. System nach einem der Ansprüche 19 bis 29, wobei die Clienteinrichtung derart konfiguriert ist, daß sie ein Clientsicherheitsberechtigungsnachweis in einer Anfrage zu der Serviceeinrichtung für dieses Dokument einbindet, und wobei die Serviceeinrichtung derart konfiguriert ist, daß sie den Clientsicherheitsberechtigungsnachweis authentifiziert, bevor das Dokument zu der Clienteinrichtung gesendet wird.
  31. System nach einem der Ansprüche 19 bis 30, wobei die Clienteinrichtung derart konfiguriert ist, um: ein Sicherheitsberechtigungsnachweis von einem Authentifizierungsdienst, der in dem Dokument spezifiziert wird, anzufordern, den Sicherheitsberechtigungsnachweis zu empfangen und den Sicherheitsberechtigungsnachweis in einer nachfolgende Anfrage an den Dienst einzubinden, um auf eine Fähigkeit des Dienstes zuzugreifen.
  32. System nach Anspruch 31, wobei der Dienst derart konfiguriert ist, daß er den Sicherheitsberechtigungsnachweis verifiziert, bevor der Zugriff auf die Fähigkeit erlaubt wird.
  33. System nach Anspruch 32, wobei der Authentifizierungsdienst von der Serviceeinrichtung bereitgestellt wird.
  34. System nach Anspruch 19, wobei die Clienteinrichtung derart konfiguriert ist, daß sie eine Transportverbindung zusätzlich zu der direkten Punkt-zu-Punkt-Kommunikationsverbindung trägt bzw. unterstützt, wobei die Clienteinrichtung weiterhin derart konfiguriert ist, daß sie das Dokument anderen Einrichtungen über die Transportverbindung verfügbar macht und eine Brücke von der Transportverbindung zu der direkten Punkt-zu-Punkt-Kommunikationsverbindung bereitstellt, so daß die anderen Einrichtungen auf den Dienst zugreifen können.
  35. System nach Anspruch 34, wobei die Transportverbindung eine Netzwerkverbindung aufweist.
  36. System nach Anspruch 25, wobei die Netzwerkverbindung eine Internetverbindung aufweist.
  37. Clienteinrichtung (2150), die aufweist: einen Anschluß (2156), der derart konfiguriert ist, daß er eine direkte Punkt-zu-Punkt-Kommunikationsverbindung mit einer Serviceeinrichtung bildet, ein Interface (2154), das derart konfiguriert ist, daß es direkt über die Punkt-zu-Punkt-Kornmunikationsverbindung ein Dokument abfragt, das eine Schnittstelle zu dem Zugriff auf einen Dienst beschreibt, wobei die Schnittstelle weiterhin derart konfiguriert ist, daß sie das Dokument direkt von dem Dienst über die Punkt-zu-Punkt-Kommunikationsverbindung empfängt und wobei die Schnittstelle weiterhin derart konfiguriert ist, daß sie die Information von dem Dokument verwendet, um auf den Dienst zuzugreifen.
  38. Serviceeinrichtung (2170), die aufweist: einen Anschluß (2172), der derart konfiguriert ist, daß er eine direkte Punkt-zu-Punkt-Kommunikationsverbindung mit einer Clienteinrichtung bildet, eine Schnittstelle (2174), die derart konfiguriert ist, daß sie über die Punkt-zu-Punkt-Kommunikationsverbindung eine Anfrage von einem Client nach einem Dokument (2178) empfängt, das eine Schnittstelle beschreibt, um auf den Dienst (2176) zuzugreifen, wobei die Schnittstelle weiterhin derart konfiguriert ist, daß sie das Dokument direkt dem Client über die Punkt-zu-Punkt-Kommunikationsverbindung bereitstellt und eine Serviceeinheit, die derart konfiguriert ist, daß auf sie von dem Client entsprechend einer Information, die in dem Dokument spezifiziert ist, zugegriffen werden kann.
  39. Trägermedium, das Programmbefehle aufweist, wobei die Programmbefehle auf einer Clienteinrichtung (2150) computerausführbar sind, um zu implementieren: das Bilden einer direkten Punkt-zu-Punkt-Kommunikationsverbindung mit einer Serviceeinrichtung (2170), das direkte Abfragen eines Dokumentes von der Serviceeinrichtung, das eine Schnittstelle beschreibt, um auf einen Service zuzugreifen, der von der Serviceeinrichtung bereitgestellt wird, das Empfangen des Dokuments direkt von der Serviceeinrichtung, wobei das Dokument Information aufweist, die beschreibt, wie auf den Service zuzugreifen ist, wobei das Abfragen und das Empfangen über die direkte Punkt-zu-Punkt-Kommunikationsverbindung durchgeführt wird und das Verwenden der Information von dem Dokument, um auf den Service bzw. Dienst zuzugreifen.
  40. Computerprogramm, das computerausführbare Befehle aufweist für das Implementieren des Verfahrens nach einem der Ansprüche 1 bis 18.
DE60102234T 2000-05-09 2001-05-09 Verfahren und vorrichtung zur ermittlung von benachbarten diensten Expired - Fee Related DE60102234T2 (de)

Applications Claiming Priority (13)

Application Number Priority Date Filing Date Title
US20297500P 2000-05-09 2000-05-09
US202975P 2000-05-09
US20801100P 2000-05-26 2000-05-26
US208011P 2000-05-26
US20914000P 2000-06-02 2000-06-02
US20943000P 2000-06-02 2000-06-02
US209430P 2000-06-02
US209140P 2000-06-02
US20952500P 2000-06-05 2000-06-05
US209525P 2000-06-05
US09/656,588 US7412518B1 (en) 2000-05-09 2000-09-07 Method and apparatus for proximity discovery of services
US656588 2000-09-07
PCT/US2001/015099 WO2001086486A2 (en) 2000-05-09 2001-05-09 Method and apparatus for proximity discovery of services

Publications (2)

Publication Number Publication Date
DE60102234D1 DE60102234D1 (de) 2004-04-08
DE60102234T2 true DE60102234T2 (de) 2005-02-24

Family

ID=27558947

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60102234T Expired - Fee Related DE60102234T2 (de) 2000-05-09 2001-05-09 Verfahren und vorrichtung zur ermittlung von benachbarten diensten

Country Status (6)

Country Link
EP (1) EP1285354B1 (de)
JP (1) JP2004501428A (de)
AT (1) ATE261145T1 (de)
AU (1) AU2001263033A1 (de)
DE (1) DE60102234T2 (de)
WO (1) WO2001086486A2 (de)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7024662B2 (en) 2001-03-14 2006-04-04 Microsoft Corporation Executing dynamically assigned functions while providing services
US7302634B2 (en) 2001-03-14 2007-11-27 Microsoft Corporation Schema-based services for identity-based data access
US7343428B2 (en) 2001-09-19 2008-03-11 International Business Machines Corporation Dynamic, real-time integration of software resources through services of a content framework
US7035944B2 (en) 2001-09-19 2006-04-25 International Business Machines Corporation Programmatic management of software resources in a content framework environment
US7603469B2 (en) * 2002-01-15 2009-10-13 International Business Machines Corporation Provisioning aggregated services in a distributed computing environment
WO2003061242A1 (en) * 2002-01-15 2003-07-24 Avaya Technology Corp. Communication application server for converged communication services
DE10203409B4 (de) * 2002-01-28 2004-09-16 Wincor Nixdorf International Gmbh Computersystem mit einem Anwendungsserver, einer Gerätesteuerung mit angeschlossenen Peripheriegeräten und einem Verzeichnisserver
DE10203403B4 (de) * 2002-01-28 2005-01-27 Wincor Nixdorf International Gmbh Computersystem mit Gerätesteuerungen für Peripheriegeräte, die von einem Anwendungsserver genutzt werden, sowie einem Konfigurationsserver
US9886309B2 (en) 2002-06-28 2018-02-06 Microsoft Technology Licensing, Llc Identity-based distributed computing for device resources
US20040059704A1 (en) * 2002-09-20 2004-03-25 International Business Machines Corporation Self-managing computing system
US7346927B2 (en) 2002-12-12 2008-03-18 Access Business Group International Llc System and method for storing and accessing secure data
US7467399B2 (en) 2004-03-31 2008-12-16 International Business Machines Corporation Context-sensitive confidentiality within federated environments
JP2006171917A (ja) * 2004-12-13 2006-06-29 Sony Internatl Europ Gmbh 無線マルチホップアドホックネットワークのためのプロトコル
US7577125B2 (en) 2005-07-08 2009-08-18 Microsoft Corporation Direct wireless client to client communication
US8478300B2 (en) * 2005-12-20 2013-07-02 Microsoft Corporation Proximity service discovery in wireless networks
US8559350B2 (en) 2005-12-20 2013-10-15 Microsoft Corporation Mechanism to convey discovery information in a wireless network
US7613426B2 (en) 2005-12-20 2009-11-03 Microsoft Corporation Proximity service discovery in wireless networks
KR100788693B1 (ko) * 2006-01-12 2007-12-26 삼성전자주식회사 원격 사용자 인터페이스의 상태 정보를 저장하고 복구하는방법 및 장치
KR100813969B1 (ko) * 2006-01-18 2008-03-14 삼성전자주식회사 원격 사용자 인터페이스의 상태 정보를 저장하고 복구하는방법 및 장치
US10681151B2 (en) 2006-05-15 2020-06-09 Microsoft Technology Licensing, Llc Notification framework for wireless networks
US8681691B2 (en) 2007-07-25 2014-03-25 Microsoft Corporation Base station initiated proximity service discovery and connection establishment
US9105031B2 (en) 2008-02-22 2015-08-11 Microsoft Technology Licensing, Llc Authentication mechanisms for wireless networks
CN102668647B (zh) 2009-11-17 2015-11-25 三星电子株式会社 用于调查在WiFi直连网络中的WiFi显示服务的方法和装置
US20130012120A1 (en) * 2011-07-05 2013-01-10 Te-Chuan Liu Reminding Method and Non-Transitory Machine Readable Media thereof
US9143889B2 (en) 2011-07-05 2015-09-22 Htc Corporation Method of establishing application-related communication between mobile electronic devices, mobile electronic device, non-transitory machine readable media thereof, and media sharing method
US9628438B2 (en) 2012-04-06 2017-04-18 Exablox Consistent ring namespaces facilitating data storage and organization in network infrastructures
US9552382B2 (en) 2013-04-23 2017-01-24 Exablox Corporation Reference counter integrity checking
EP3008647A4 (de) 2013-06-12 2017-01-25 Exablox Corporation Sammlung hybrider abfälle
US9715521B2 (en) 2013-06-19 2017-07-25 Storagecraft Technology Corporation Data scrubbing in cluster-based storage systems
US9934242B2 (en) 2013-07-10 2018-04-03 Exablox Corporation Replication of data between mirrored data sites
US10248556B2 (en) 2013-10-16 2019-04-02 Exablox Corporation Forward-only paged data storage management where virtual cursor moves in only one direction from header of a session to data field of the session
US9985829B2 (en) 2013-12-12 2018-05-29 Exablox Corporation Management and provisioning of cloud connected devices
US10693623B2 (en) 2014-01-31 2020-06-23 Apple Inc. Reference subframes for synchronization and cell measurements
US9774582B2 (en) 2014-02-03 2017-09-26 Exablox Corporation Private cloud connected device cluster architecture
JP2017504924A (ja) 2014-02-04 2017-02-09 エグザブロックス・コーポレーション ファイルシステムのコンテンツベースの編成
US9906432B2 (en) 2014-12-09 2018-02-27 International Business Machines Corporation Partner discovery in control clusters using shared VLAN
US20170060924A1 (en) 2015-08-26 2017-03-02 Exablox Corporation B-Tree Based Data Model for File Systems
US9846553B2 (en) 2016-05-04 2017-12-19 Exablox Corporation Organization and management of key-value stores

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69309485T2 (de) * 1992-11-13 1997-07-10 Microsoft Corp Verfahren zur verteilung von schnittstellenzeigern fur fernprozeduranrufe

Also Published As

Publication number Publication date
JP2004501428A (ja) 2004-01-15
AU2001263033A1 (en) 2001-11-20
EP1285354A2 (de) 2003-02-26
WO2001086486A3 (en) 2002-11-21
DE60102234D1 (de) 2004-04-08
WO2001086486A2 (en) 2001-11-15
ATE261145T1 (de) 2004-03-15
EP1285354B1 (de) 2004-03-03

Similar Documents

Publication Publication Date Title
DE60102234T2 (de) Verfahren und vorrichtung zur ermittlung von benachbarten diensten
DE60123289T2 (de) Ereignisnachricht-endstelle in einer verteilten rechnerumgebung
DE60104678T2 (de) Mechanismus und vorrichtung um dienst-ergebnissen einer verteilten rechnerumgebung zurückzuliefern
DE60102305T2 (de) Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung
DE60101911T2 (de) Verfahren und vorrichtung zum zugriff und zur adressierung von diensten in einer verteilten rechnerumgebung
US7171415B2 (en) Distributed information discovery through searching selected registered information providers
US6970869B1 (en) Method and apparatus to discover services and negotiate capabilities
US7716492B1 (en) Method and apparatus to obtain service capability credentials
US7412518B1 (en) Method and apparatus for proximity discovery of services
US6862594B1 (en) Method and apparatus to discover services using flexible search criteria
US6643650B1 (en) Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US7395333B1 (en) Method and apparatus to obtain negotiated service advertisement
US6789077B1 (en) Mechanism and apparatus for web-based searching of URI-addressable repositories in a distributed computing environment
US7080078B1 (en) Mechanism and apparatus for URI-addressable repositories of service advertisements and other content in a distributed computing environment
US6973493B1 (en) Mechanism and apparatus for security of newly spawned repository spaces in a distributed computing environment
US7370091B1 (en) Method and apparatus for obtaining space advertisements
WO2001086421A2 (en) Message gates in a distributed computing environment
WO2002091243A2 (en) Method and system of routing messages in a distributed search network
JP2004504657A (ja) 分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール
DE60101740T2 (de) Transformation von objekten zwischen einer rechnerprogrammiersprache und einer daten-darstellungssprache
EP1380941A2 (de) Transformation von Objekten zwischen einer Rechnerprogrammiersprache und einer Daten-Darstellungssprache
DE60121605T2 (de) Aufruf einer entfernten funktion mit nachrichten in einer verteilten rechnerumgebung
DE60121371T2 (de) Verbindung zwischen einer auf datendarstellungssprache und auf nachrichten basierter verteilter rechnerumgebung und anderen umgebungen
WO2001086393A2 (en) Message authentication using message gates in a distributed computing environment
JP2003533767A (ja) コンピュータ・プログラミング言語とデータ表現言語との間のオブジェクトの変換

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee