DE60102305T2 - Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung - Google Patents

Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung Download PDF

Info

Publication number
DE60102305T2
DE60102305T2 DE60102305T DE60102305T DE60102305T2 DE 60102305 T2 DE60102305 T2 DE 60102305T2 DE 60102305 T DE60102305 T DE 60102305T DE 60102305 T DE60102305 T DE 60102305T DE 60102305 T2 DE60102305 T2 DE 60102305T2
Authority
DE
Germany
Prior art keywords
service
client
representation
space
language
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 - Lifetime
Application number
DE60102305T
Other languages
English (en)
Other versions
DE60102305D1 (de
Inventor
L. Gregory SLAUGHTER
E. Thomas SAULPAUGH
A. Bernard TRAVERSAT
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
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE60102305D1 publication Critical patent/DE60102305D1/de
Application granted granted Critical
Publication of DE60102305T2 publication Critical patent/DE60102305T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime 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
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G06F9/4862—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate
    • 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/542—Event management; Broadcasting; Multicasting; Notifications
    • 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/101—Access control lists [ACL]
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • 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/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • 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 virtuelle Maschinen und genauer gesagt auf die Umsetzung bzw. Transformation zwischen Computerprogrammiersprachen-Objekten und Darstellungen in einer Datenrepräsentationssprache der Objekte.
  • 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 kornplizierten 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 Implemen tationssprache 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 geschnebenen 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 Intemet 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 aufwerfen kann. Jini arbeitet bzw. funktioniert, indem Clients und Ressourcen durch die Übergabe von Code und Daten kommunizieren. Wenn ein Client einen Jini-Dienst aktiviert, kann der Dienst seine Ergebnisse an den Client zurückgeben, was eine große Menge von Code oder Inhalt umfassen kann. In Jini kann ein Client eine Methode aufrufen, und ein großes Objekt kann zurückgeliefert und somit heruntergeladen werden. Der Client hat möglicherweise nicht die Ressourcen, das zurückgelieferte Objekt anzunehmen. Darüber hinaus benötigen RMI und Java selbst eine Menge Speicher. Viele Einrichtungen mit kleiner Standfläche haben eventuell nicht die Ressourcen, um effektiv oder überhaupt an aktuellen verteilten IT-Technologien teilzuhaben.
  • Ein andere Sorge bei bestehenden verteilten IT-Technologien ist, daß sie häufig bestimmte Stufen von Verbindungsmöglichkeiten und -protokollen erfordern. Zum Beispiel setzt Jini das Vorhandensein eines Netzwerks von angemessener Geschwindigkeit zur Verbindung von Computern und Einrichtungen voraus. Jini erfordert auch, daß Einrichtungen das TCP/IP-Netzwerk-Transportprotokoll unterstützen. Jedoch haben viele kleinere Einrichtungen möglicherweise beschränkte Verbindungsfähigkeiten. Kleine Einrichtungen können eine hohe Verzögerung oder Netzwerkverbindungen mit niedriger Geschwindigkeit haben und TCP/IP eventuell nicht unterstützen.
  • Wie oben erwähnt erfordert Jini es, daß Einrichtungen Java unterstützen und somit eine Virtuelle Java-Maschine enthalten, was eine gewisse Menge von Rechen- und Speicherfähigkeiten erfordert, die bei vielen kleinen Einrichtungen womöglich nicht vorhanden ist. Dies schränkt auch die Flexibilität von Jini dahingehend ein, daß Nicht-Java-Einrichtungen nicht direkt an einem Jini-System beteiligt sein können. Da Jini Java benötigt, kann man es sich als eine homogene Umgebung vorstellen. Es ist jedoch wünschenswert, eine verteilte IT-Einrichtung bzw. -Anlage für heterogene, verteilte Verarbeitung zu haben, die von extrem kleinen, eingebetteten Einrichtungen über PDAs und Mobiltelefonen zu Laptops und sogar über die leistungsfähigsten Computer hinaus skalierbar ist.
  • Es gibt andere heterogene Lösungen wie die Common Object Request Broker Architecture (CORBA). CORBA ist eine Architektur, die Programmobjekte in die Lage versetzt, miteinander zu kommunizieren unabhängig von der Programmiersprache, in der sie geschrieben wurden, oder 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 zwi schen 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 Plattform unabhä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 JVMabhä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.
  • Das Dokument GB-A-2,332,288 bezieht sich auf ein Netzwerk, welches eine Anzahl physikalischer Ressourcen aufweist, die über eine CORBA-Plattform kommunizieren, wobei eine Anzahl von Agentenberechnungsentitäten an den Ressourcen sitzen und miteinander unter Verwendung einer Agentenkommunikationssprache kommunizieren.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung ist in den anhängenden Ansprüchen definiert.
  • Ein Mechanismus für das Wandern bzw. Verschieben von Prozessen unter Verwendung von Darstellungen der Prozesse in einer Datenrepräsentationssprache (wie z. B. XML) in einer verteilten Rechnerumgebung. Ein aktueller Berechnungszustand eines Prozesses, der innerhalb einer ersten Einrichtung abläuft, kann in eine Darstellung des aktuellen Berechnungszustandes in einer Datenrepräsentationssprache umgewandelt werden, einschließlich der Information über den Ausführungszustand des Prozesses innerhalb der ersten Einrichtung. Diese Information kann, ohne darauf beschränkt zu sein, Information über einen oder mehrere Stränge bzw. "Threads" des Prozesses, Information über eine oder mehrere Überlassungen (Leasing) an von dem Prozeß gehaltene Dienste und Information über ein oder mehrere Objekte des Prozesses (wie z. B. Objekte, die durch die "Threads" gehalten werden) umfassen, wobei ein Objekt eine Instanz einer Klasse in einer Computerprogrammiersprache ist (wie z. B. der Java-Programmiersprache).
  • Die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datenrepräsentationssprache kann gespeichert werden. In einer Ausführungsform kann die Darstellung lokal gespeichert werden. In einer Ausführungsform kann die Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache in einen Raum bzw. "Space" gespeichert werden unter Verwendung eines "Space"-Dienstes. In einer Ausführungsform kann die Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache in einer oder in mehreren Nachrichten an den Space-Dienst gesendet werden.
  • Eine zweite Einrichtung kann auf die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datenrepräsentationssprache zugreifen. Der Prozeß kann in dem aktuellen Berechnungszustand innerhalb der zweiten Einrichtung aus der Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache, auf welche zugegriften wurde, wieder aufgebaut werden. Der Prozeß kann dann die Ausführung innerhalb der zweiten Einrichtung, von dem aktuellen Berechnungszustand ausgehend, wiederaufnehmen.
  • Alternativ kann die Prozeßausführung im Anschluß an das Umwandeln des aktuellen Berechnungszustandes auf der ersten Einrichtung beendet werden. Die erste Einrichtung kann dann nachfolgend auf die gespeicherte Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache wieder zugreifen. Der Prozeß kann dann in dem aktuellen Berechnungszustand innerhalb der ersten Einrichtung aus der Darstellung des Berechnungszustandes des Prozesses in der Datenrepräsentationssprache wiederhergestellt werden und die Ausführung des Prozesses kann innerhalb der ersten Einrichtung aus dem aktuellen Berechnungszustand wiederaufgenommen werden.
  • In einer anderen Alternative kann die Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache direkt an die zweite Einrichtung gesendet werden (d. h. durch Nachrichtengatter in einer oder mehreren Nachrichten der Datenrepräsentationssprache). Der Prozeß kann dann in dem aktuellen Berechnungszustand innerhalb der zweiten Einrichtung aus der empfangenen Darstellung des aktuellen Berechnungszustandes des Prozesses in der Datenrepräsentationssprache wieder aufgebaut werden. Der Prozeß kann dann innerhalb der zweiten Einrichtung aus dem aktuellen Berechnungszustand heraus die Ausführung wiederaufnehmen.
  • 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 Erzeugen eines Gatters gemäß einer Ausführungsform darstellt;
  • 42a ist ein Flußdiagramm, das einen Client darstellt, der gemäß einer Ausführungsform eine Nachricht an einen Dienst sendet;
  • 42b ist ein Flußdiagramm, das einen Dienst darstellt, der gemäß einer Ausführungsform eine Nachricht von einem Client empfängt und einen Authentisierungsdienst verwendet, um die Nachricht zu authentisieren;
  • 42c ist ein Flußdiagramm, das den allgemeinen Ablauf eines Client und eines Dienstes darstellt, die gemäß einer Ausführungsform Nachrichten mit eingebetteten Authentisierungsnachweisen austauschen;
  • 43 ist ein Flußdiagramm, das einen Mechanismus zum Prüfen der Integrität von Nachrichten gemäß einer Ausführungsform darstellt;
  • 44 ist ein Flußdiagramm, das einen Mechanismus zum Überlassen von Ressourcen gemäß einer Ausführungsform darstellt;
  • 45a–45d sind Flußdiagramme, die verschiedene Ausführungsformen von einem Mechanismus Zum Kommunizieren zwischen Clients und Diensten unter Verwendung von Methodengattern darstellen;
  • 46 ist ein Flußdiagramm, das einen Mechanismus zum Senden von Objekten von Diensten an Clients unter Verwendung von XML-Repräsentationen der Objekte darstellt;
  • 47 ist ein Flußdiagramm, das einen Mechanismus zur sicheren Dekompilierung eines Objektes auf einem Client darstellt; und
  • 48 ist ein Flußdiagramm, das einen Mechanismus zum Migrieren von Prozessen unter Verwendung von Darstellungen in einer Datenrepräsentationssprache der Prozesse in einer verteilten Rechnerumgebung.
  • 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 Data grammen 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 XMLbasierte 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 klei neres 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 Zielen titä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 Nachnchtenstrom 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 Servenannonce). 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 Authentisienungsdienst 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 vonkonstruierten 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. amlängsten-nicht-verwendet aus dem Gattercache entfernt werden. Wenn die Gatterfabrik aufgerufen wird, um ein Gatter einzurichten, prüft sie zunächst den Gattercache, um nachzusehen, ob ein passendes Gatter bereits existiert, so daß das Einrichten eines neuen Gatters vermieden werden kann.
  • Der Bau eines Gatters kann durch geeignete Wiederverwendung von Teilen, die zum Aufbau anderer Gatter verwendet werden bzw. wurden, leicht bzw. einfach gemacht werden. Gewisse Anteile eines jeden Gatters können gleich sein und können somit von Gatter zu Gatter wiederverwendet werden wie Teile des Codes zur Überprüfung der Nachrichten. Ebenso kann für einige Einrichtungen gemeinsamer Gattercode in die Systemsoftware für die Einrichtung eingebaut und von allen Gattern auf der Einrichtung gemeinsam genutzt werden. Daher kann es die Gatterfabrik vermeiden, diesen gemeinsamen Code für jedes Gatter neu aufzubauen. Stattdessen kann die Gatterfabrik einfach das Gatter an diesen Teil der Systemsoftware binden. Zum Beispiel kann ein Teil der Systemsoftware bereitstehen, um die Nachrichtenschicht über einem Transportmedium, welches auch immer auf der Einrichtung zur Verfügung steht, zu behandeln.
  • Insbesondere können Space-Dienste gute Kandidaten für viele der oben beschriebenen Optimierungen beim Aufbau eines Gatters sein, da ein Dienstgatter, das für einen Space-Dienst eingerichtet wurde, viele von denselben Funktionen wie andere Dienstgatter für diesen Space-Dienst durchführen kann. Siehe den Abschnitt über Spaces unten hinsichtlich weiterer Information zu Space-Diensten.
  • In manchen Fällen kann eine effizientere Form des Methodenaufrufs existieren. Wenn zum Beispiel der Zieldienst auf derselben virtuellen Javamaschine abläuft wie die Clientanwendung, kann es eine effizientere Form des Methodenaufrufs sein, eine dynamische Java-Proxyklasse für den Dienst zu erzeugen. In einem solchen Fall kann der Aufruf einer Methode von java.lang.reflect schneller sein, als eine Nachricht zu senden. Eine Prozedur bzw. ein Vorgang zur Bindezeit eines Gatters kann hinsichtlich einer solchen Optimierung prüfen und sie verwenden, anstatt die Gatterfabrik ablaufen zu lassen bzw. auszuführen, um ein Gatter zu erzeugen oder ein existierendes Gatter zu binden.
  • Nach einer Ausführungsform wie für spezielle Clients oder kleine, eingebettete Einrichtungen bzw. Geräte ist die Erzeugung von Gattercode zur Laufzeit wegen des Speicherverbrauchs und der Zeit zum Generieren des Codes möglicherweise nicht wünschenswert. Daher können nach einigen Ausführungsformen Gatter vorgeneriert und in die Einrichtung eingebaut werden, anstatt eine Gatterfabrik zu haben, die Gatter zur Laufzeit erzeugt. Zum Beispiel können Nachrichtengatter während des Erstellens von eingebetteter Software als ein Mittel bzw. Verfahren zum Einbeziehen eines sicheren Nachrichtenendpunktes erzeugt werden, der nicht zur Laufzeit eingerichtet werden muß. Daher braucht ein Client mit eingebauten Gattern möglicherweise keine vollständige Gatterfabrik oder benötigt eventuell nur eine partielle Gatterfabrik, um gewisse Bindevorgänge an ein eingebautes Gatter wie für den URI und/oder den Authentisierungsnachweis zur Laufzeit durchzuführen.
  • Ein Generierungswerkzeug kann für das Vorgenerieren von Gattern vorgesehen sein. Das Generierungswerkzeug kann einen XML-Parser, einen Codegenerator und einen Codecompiler enthalten. Nach einer Ausführungsform kann der Codegenerator ein Generator von Java-Quellcode und der Codecompiler eine Java-Codecompiler sein. Während des Erstellen von Software, für die eingebaute Nachrichtengatter gewünscht sind, wird das Generierungswerkzeug mit der Eingabe aus allen relevanten XML-Schemata ausgeführt, für die Gatter gewünscht werden.
  • Wenn es zum Beispiel für eine Einrichtung gewünscht ist, ein eingebautes Nachrichtengatter zu haben, das Nachrichten von einer digitalen Kamera senden und empfangen kann, kann das Erstellen der Software für die Einrichtung beinhalten, das Generierungswerkzeug für Gatter mit dem XML-Nachrichtenschema der Kamera als Eingabe laufen zu lassen bzw. auszuführen. Das XML-Schema kann von dem XML-Parser analysiert werden, der das XML-Schema in eine interne Form umwandeln kann, die für einen schnellen Zugriff während eines Vorgangs zur Überprüfung der Nachricht geeignet ist. Der Codegenerator des Werkzeugs kann Quellcode für ein Gatter bereitstellen, der dem Schema der Kamera entspricht. Nach einigen Ausführungsformen kann das Generierungswerkzeug auch den Quellcode kompilieren und der Gattercode kann in das Softwarepaket für die Einrichtung bzw. das Gerät eingebunden werden. Zur Laufzeit kann der Kameradienst in der verteilten Rechnerumgebung ausfindig gemacht werden. Der Nachrichten-URI für den Kameradienst kann an das eingebaute Gatter für die Kamera innerhalb des Gerätes gebunden werden. Das Binden des URI an das vorab eingerichtete Gatter kann von einem Gatterkonstrukteur bzw. -errichter innerhalb des Gerätes durchgeführt werden. Der Gattererrichten kann eine viel kleinere, einfachere Gatterfabrik sein. Wenn der Kameradienst eingerichtet ist, wird der URI für den Kameradienst an den Gatterernichter als eine XML-Nachricht übergeben. Der Gatterernichter 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 Gatterfabnik 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 Generienungswerkzeuge 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 henuntergeladen werden kann, der auf diesen Dienst zugreifen möchte. Jedoch kann heruntengeladener 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 Zielgattenadresse 152, ein gültiges XML-Schema (oder eine interne Form davon) 154 und einen Transport-URI 153 beinhalten. Nach anderen Ausführungsformen kann ein Gatter auch einen Authentisierungsnachweis 156 enthalten. Einige Gatter können auch eine Überlassung bzw. eine Pacht 158 und/oder eine Nachrichtenleitung 160 enthalten, um die Reihenfolge der Nachrichten zu überprüfen. Der Name 150 eines Gatters kann eine eindeutige ID sein, die (für die Lebensdauer des Gatters) nur auf dieses verweist. Ein Gatter kann mittels seines Gatternamens 150 adressiert werden. Nach einer Ausführungsform können Gatternamen als eine Kombination einer Zeichenkette aus einem XML-Schema (z. B. aus einer Dienstannonce) und eine Zufallszahl wie einer 128-Bit langen Zufallszahl erzeugt werden. Der Name 150 kann es Clients und Diensten ermöglichen, über das Netzwerk zu migrieren und immer noch zusammenzuarbeiten. Nach einer bevorzugten Ausführungsform ist die Gatteradresse unabhängig von der physikalischen Transportadresse der Nachricht und/oder der Socket-Schicht. Somit kann ein Gattername eine virtuelle Adresse des Nachrichtenendpunktes bereitstellen, die an eine Transportadresse der Nachricht gebunden und von dieser wieder gelöst werden kann. Nach einer Ausführungsform kann der Name eines Gatters ein universeller eindeutiger Bezeichner (Universal Unique Identifier, UUID) sein, der für die Lebensdauer des Gatters nur auf dieses verweist.
  • Ein Gattername kann solange bestehen, wie das Gatter besteht, so daß verschiedene Anwendungen und Clients, die innerhalb derselben Einrichtung ausgeführt werden, ein bestimmtes Gatter wiederholt lokalisieren und verwenden können. Zum Beispiel kann ein Gatter für einen ersten Clientprozeß, der innerhalb der Einrichtung ausgeführt wird, erzeugt werden, um auf einen Dienst zuzugreifen. Nachdem der erste Clientprozeß seine Aktivität mit dem Dienst abgeschlossen hat, kann er das Gatter freigeben. Das Freigeben eines Gatters kann mit dem Lösen des Gatters von der Nachrichten-Transportadresse des ersten Client (z. B. der IP- und/oder Port-Adresse) einhergehen. Das Gatter kann in einem Gattercache oder -vorratsspeicher gespeichert werden. Ein zweiter innerhalb derselben Einrichtung ausgeführter Clientprozeß, der denselben Dienst auszuführen bzw. ablaufen zu lassen wünscht, kann das Gatter mittels seines Namens lokalisieren und es verwenden, um auf den Dienst zuzugreifen. Um das Gatter zu verwenden, kann der zweite Clientprozeß das Gatter an seine Nachrichten-Transportadresse binden, so daß der Nachrichtenendpunkt für den zweiten Clientprozeß eine Kombination aus dem Gatternamen und der Transportadresse des zweiten Clientprozesses ist. In einem anderen Beispiel kann ein Client eine dynamische IP-Adresse erhalten (z. B. ein mobiler Client). Wenn sich die Transportadresse des Client ändert, kann ein Gatter- name (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 Barunterliegenden 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 ErbringerDienstnachrichten oder den gesamten Client- und Erbringer-Dienstnachrichten oder einer spezifischen Nachricht entweder von den Client-Dienstnachrichten oder von den Erbringer-Dienstnachrichten. Darüber hinaus kann ein Client, sobald ein Gatter eingerichtet wurde, hinsichtlich der Fähigkeiten des Dienstes anfragen, ohne daß das Gatter tatsächlich eine Nachricht sendet, sondern stattdessen die Menge von Nachrichten des Gatters inspiziert.
  • Wie oben beschrieben kann ein Nachrichtengatter überprüfen, ob der Sender der Nachricht einen Authentisierungsnachweis verwendet, und den Nachrichteninhalt auf Typsicherheit und gemäß einem XML-Schema überprüfen. Jedoch kann es ebenso wünschenswert sein zu überprüfen, daß Nachrichten zwischen einem Client und einem Dienst in der richtigen Reihenfolge gesendet werden. Es kann wünschenswert sein, daß es möglich ist, Anwendungen (Dienste) für Clients vorzusehen, die ohne irgendeine vorab existierende, spezifische Funktionalität bezüglich der Anwendung auf dem Client ablaufen sollen (z. B. kein GUI für die Anwendung auf dem Client). Zum Beispiel kann auf dem Client ein Web-Browser als das GUI für einen Dienst verwendet werden, anstatt ein anwendungsspezifisches GUI zu erforderlich zu machen. Von den möglichen Nachrichten in dem XML-Schema, muß der Client möglicherweise wissen, welche Nachricht als nächstes an den Dienst zu senden ist. Es kann wünschenswert sein, daß der Client in der Lage ist festzustellen, welche Nachricht als nächstes zu senden ist, ohne es erforderlich zu machen, daß der Client spezifische Kenntnisse des Dienstes hat. Nach einer Ausführungsform kann der Dienst kontinuierlich Antwortnachrichten senden, die die nächste Eingabe anzeigen, die er benötigt. Der Dienst würde dann von dem Client nur entsprechende Nachrichten mit der angegebenen erforderlichen Eingabe akzeptieren. Eine andere Ad-Hoc-Maßnahme bzw. -Vorgabe für die Reihenfolge der Nachrichten kann ebenso eingesetzt werden.
  • Nach einer anderen Ausführungsform kann eine Nachrichtenleitung 160 in dem Gatter oder dem Gatter zugeordnet eingesetzt werden, um die richtige Reihenfolge von Nachrichten zu überprüfen, im Gegensatz zum Überprüfen der Syntax jeder Nachricht (was bereits in dem Gatter gemäß dem Schema durchgeführt sein kann). Die Nachrichtenleitung 160 kann einen allgemeineren Ansatz für das Bereitstellen von bzw. für Anwendungen vorsehen. Die Nachrichtenleitung 160 kann in der Annonce eines Dienstes angegeben werden. Die Angabe der Nachrichtenleitung in einem Schema kann es ermöglichen, daß Code während der Einrichtung eines Gatters auf dem Client erzeugt oder in den Client heruntergeladen wird, der die benötigte Choreographie bereitstellt, um zu entscheiden, welche Nachricht als nächstes an den Dienst zu senden ist. Eine Nachrichtenleitung kann als eine Java-Anwendung, ein Java Script, ein WML-Skript oder in einer Programmier- oder Skriptsprache implementiert sein.
  • Nach einer Ausführungsform kann die Nachrichtenleitung als Eingabe ein XML-Dokument (z. B. aus einer Dienstannonce) akzeptieren, das die gültige Reihenfolge oder Choreographie für Nachrichten übergibt, die zwischen einem Client und einem Dienst gesendet werden können. Dieses XML-Dokument kann auch die Information über die Benutzerschnittstelle und andere Regeln angeben. Die Leitung kann dieses XML-Dokument analysieren und in eine interne Form überführen und eine Reihenfolge der Nachrichten (und/oder andere Regeln) gemäß der enthaltenen Information zur Reihenfolge erzwingen. Die Leitung kann verhindern, daß Nachrichten außer der Reihe gesendet werden. Oder wenn eine Nachricht außer der Reihe gesendet wird, kann eine Ausnahmebedingung innerhalb der sendenden Einrichtung aufgeworfen bzw. verursacht werden. Wenn eine Nachricht außer der Reihe empfangen wird, kann die Leitung eine automatische Antwortnachricht zurücksenden, die den Fehler in der Reihenfolge meldet. Der Sender kann dann Nachrichten in der richtigen Reihenfolge erneut senden. Man beachte, daß nach einigen Ausführungsformen eine Teil einer Leitung oder die gesamte Leitung mit mehreren Gattern gemeinsam genutzt werden können. Daher kann eine Leitung mit mehreren Gattern gebunden werden.
  • Nach einer Ausführungsform eine verteilten Rechnerumgebung können Eingangsrechner bzw. Datenstationen für Dienste (Dienstschnittstellen) in Clients eingebaut sein. Nach einer Ausführungsform kann die Dienstschnittstelle eine vorab eingerichtete Benutzerschnittstelle sein, die dem Client von dem Dienst bereitgestellt wird. Nach einer Ausführungsform kann die Dienstschnittstelle dem Client in der Dienstannonce bereitgestellt bzw. übergeben werden. Die Dienstschnittstelle kann auf dem Client mit dem Benutzer des Dienstes interagieren, um eine Eingabe zur Ausführung des Dienstes zu erhalten und kann danach die Ergebnisse der Ausführung des Dienstes auf dem Client anzeigen. Ein "Benutzer" kann ein Mensch, ein eingebettetes System, ein anderer Client oder Dienst, etc. sein. Nach einer Ausführungsform ist eine Clienteinrichtung womöglich nicht in der Lage, beliebige Dienste bereitzustellen, da die Clienteinrichtung womöglich nur in der Lage ist, Dienste auszuführen, für die sie eine Datenstation eingebaut hat. Nach einer Ausführungsform kann eine Dienstschnittstelle für einen Dienst in einem Web-Browser auf dem Client implementiert sein.
  • Nach einer Ausführungsform können eine Nachrichtenleitung und/oder eine Dienstschnittstelle extern zu dem Gatter und somit von dem Gatter und Client abstrahiert sein. Die abstrahierte Nachrichtenleitung für die Bereitstellung beliebiger Dienste für irgendeine Clienteinrichtung sorgen. Nach einer Ausführungsform kann die Nachrichtenleitung in Code geschrieben sein, der im Wesentlichen of jeder beliebigen Plattform ablaufen kann. Nach einer Ausführungsform kann die Nachrichtenleitung in der Sprache Java geschreben 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üh rungsform 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, trokkenes 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 Nachrichtempfä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 Gattenpaars 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 Abrechnungs richtlinie 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 voll-stä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 Senner) 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 Methoden nachrichten 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.
  • Methodengatter stellen Clients eine Methodenschnittstelle statt nur eine rohe Nachrichtenschnittstelle zur Verfügung. Nach einer Ausführungsform kann ein Methodengatter über einem Nachrichtengatter implementiert werden. Das Nachrichtengatter sieht für das Methodengatter Zugang zum Transportmedium, Überprüfung des Nachrichteninhaltes und Zugriff auf den Nachnchteninhalt vor (Verfahren des Lesens (Get) und Einstellens (Set) von Inhalt). Nach einer Ausführungsform veranlaßt jeder Methodenaufruf in dem erzeugte Code (d. h. in dem Methodengatter), daß eine einzelne synchrone Nachricht an den Dienst gesendet wird, der die eingepackten Methodenparameter enthält. Das Methodengatter kann dann veranlassen, daß der aktuelle Thread (Strang) blockiert wird, indem er auf die Antwortnachricht von dem Dienst wartet.
  • Nach einer Ausführungsform werden einige Ergebnisse, die von einem Dienst erzeugt werden, in einem Space angekündigt, und schließlich wird auf sie mittels eines Ergebnisgatters zugegriffen. Das Ergebnisgatter kann denselben Sicherheitsnachweis wie das Eingabegatter, das zum Erzeugen der Ergebnisse verwendet wurde, beinhalten oder nicht. Weil die Eingabe für einen Dienst asynchron von seiner Ausgabe (dem Ergebnis) ist, kann mit den Ergebnissen ein unterschiedlicher Satz von Zugriffsrechten verbunden sein. Unter Verwendung eines B2B-Szenarios kann ein Gehaltslistendienst einer jeweils anderen Menge von Benutzern erlauben, die Gehaltsliste zu initiieren, bzw. die Ergebnisse des Gehaltslistendienstes (Gehaltsschecks) zu lesen.
  • Nach einer Ausführungsform kann die Erzeugung eines Ergebnisgatters für Ergebnisse von Nachrichtengattern manuell eingeleitet werden. Auf Inline-Ergebnisse (z. B. XML-Dokumente, die als eine Antwort von einem Dienst gesendet werden) kann unter Verwendung der Zugriffsmethoden (z. B. Get & Set) auf dem Nachrichteninhalt zugegriffen werden, die auf Nachrichtengattern verfügbar sind. Die Erzeugung von Methodenergebnisgattern kann automatisch eingeleitet werden. Das Methodengattermodell der Programmierung verbirgt die Erzeugung von Ergebnisgattern, indem ein nahtloses Programmiermodell des entfernten Methodenaufrufs erzeugt wird ohne den Overhead des Klassenladens oder des Erfordernisses für den Anwendungsprogrammierer, Ergebnisgatter manuell zu erzeugen.
  • Die 45a–45d sind Flußdiagramme, die verschiedene Ausführungsformen der Mechanismen zur Kommunikation zwischen Clients und Diensten in einer verteilten Rechnerumgebung unter Verwendung von Methodengattern darstellen. In 45a kann ein Clientprozeß, der innerhalb einer Clienteinrichtung ausgeführt wird, bei Schritt 2100 einen Methodenaufruf vollziehen (d. h. die Methode aufrufen). Nach einer Ausführungsform kann der Methodenaufruf ein Aufruf einer Java-Methode sein. Nach einer Ausführungsform braucht die aufgerufene Methode nicht lokal auf der Clienteinrichtung implementiert zu sein, sondern ist auf einer Diensteinrichtung außerhalb der Clienteinrichtung implementiert. In Schritt 2102 kann ein Client-Methodengatter auf der Clienteinrichtung den Methodenaufruf empfangen. Das Client-Methodengatter kann dann den Methodenaufruf in eine Nachricht in einer Datenrepräsentationssprache verpacken. Nach einer Ausführungsform ist die Datenrepräsentationssprache XML. Die Nachricht kann einen Bezeichnen der Methode und einen oder mehrere Parameterwerte der Methode enthalten. Der Bezeichner kann eine Name, eine Zahl oder ein anderer Wert sein, der zur Kennzeichnung der Methode gegenüber dem Empfänger der Nachricht verwendet wird. Ein Methodenaufruf kann einen oder mehrere Parameter enthalten, und der Aufrufende liefert beim Aufruf Werte für diese Parameter. Nach einer Ausführungsform können sich mehr als ein Methodenaufruf denselben Bezeichner teilen, und sie können durch die Parameter der Methode unterschieden werden.
  • In Schritt 2104 kann das Client-Methodengatter die Nachricht an die Diensteinrichtung senden. Nach einer Ausführungsform kann das Client-Methodengatter die Nachricht direkt an das Dienst-Methodengatter senden. Nach einer anderen Ausführungsform, die in 45b dargestellt ist, kann das Client-Methodengatter die Nachricht an ein Client-Nachrichtengatter in Schritt 2120 übergeben. Das Client-Nachrichtengatter kann dann die Nachricht in Schritt 2122 an ein Dienst-Nachrichtengatter senden. Das Dienst-Nachrichtengatter kann dann die Nachricht in Schritt 2124 an das Dienst-Methodengatter übergeben. Die in 45b dargestellte Ausführungsform befreit die Methodengatter von der Verantwortung, das Senden und Empfangen von Nachrichten zu behan deln, und vereinfacht das Programmiermodell der verteilten Rechnerumgebung durch das Aufteilen der RMI-Funktionalität und der Funktionalität der Nachrichtenbehandlung in einzelne Teile.
  • Gemäß 45a kann das Dienst-Methodengatter in Schritt 2106 den Methodenaufruf und die Parameter des Methodenaufrufs aus der empfangenen Nachricht entpacken und dann die von der empfangenen Nachricht angegebene Methode aufrufen und die entpackten Parameterwerte an die aufgerufene Methode übergeben. Das Dienst-Methodengatter kann den in der Nachricht enthaltenen Bezeichner verwenden, um die Vorlage bzw. das Template für den Methodenaufruf zu lokalisieren. Das Dienst-Methodengatter kann eine Menge von Methoden implementieren oder kann mit dieser verknüpft werden, die der Menge von Methodennachrichten entspricht, 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 mit dem Methodengatter des Dienstes verknüpft sind, und den Methodennachrichten geben, die von dem XML-Schema des Dienstes definiert werden.
  • In Schritt 2108 kann die aufgerufene Methode implementiert oder auf dem Dienst durchgeführt werden. In Schritt 2110 kann die aufgerufene Methode eine Ergebnisausgabe aus dem Aufruf gemäß der in dem Methodenaufruf empfangenen Parameterwerten erzeugen. In Schritt 2112 können die Ergebnisse des Methodenaufrufs an den Clientprozeß übergeben werden, der ursprünglich die Methode aufgerufen hat. Nach einer Ausführungsform kann der Dienst die Ergebnisse direkt an den Client in einer oder mehreren Ergebnismeldungen übergeben. Nach einer anderen Ausführungsform kann der Dienst die Ergebnisse in einen Space stellen und kann eine Ergebnisannonce an den Client übergeben, um auf die Ergebnisse zuzugreifen. Die 45c und 45d veranschaulichen andere Ausführungsformen, bei denen ein Ergebnisgatter dem Client zum Zugriff auf die Ergebnisse zur Verfügung gestellt wird.
  • In 45c kann das Dienst-Methodengatter eine Ergebnisreferenz auf das Dienst-Nachrichtengatter zur Verfügung stellen. Nach einer Ausführungsform kann die Ergebnisreferenz eine Annonce de Ergebnisse sein. Nach einer anderen Ausführungsform kann die Ergebnisreferenz eine Adresse, z. B. ein URI, für die Ergebnisse sein. In Schritt 2132 kann das Dienst-Nachrichtengatter die Ergebnisreferenz in einer Nachricht an das Client-Nachrichtengatter senden. In Schritt 2134 kann der Client nach dem Empfang der Nachricht ein Ergebnisgatter aus der Nachricht mit der Ergebnisreferenz erzeugen. Zum Beispiel kann eine Ergebnisannonce in der Nachricht übergeben werden, und der Client kann das Ergebnisgatter gemäß der Ergebnisannonce in einer ähnlichen Weise wie das Erzeugen von Nachrichtengattern aus Annoncen, wie oben beschrieben, erzeugen. In Schritt 2136 kann der Client das Ergebnisgatter zum Zugriff auf die Ergebnisse verwenden. Zum Beispiel können die Ergebnisse auf der Diensteinrichtung liegen, und der Dienst kann ein Dienst-Ergebnisgatter erzeugt haben. Das Client-Ergebnisgatter kann erzeugt werden, um mit dem Dienst-Ergebnisgatter zu kommunizieren, z. B. kann der URI des Dienst-Ergebnisgatters in der Ergebnisannonce enthalten gewesen sein. Alternativ kann der Dienst die Ergebnisse anderswo in der verteilten Rechnerumgebung gespeichert haben, und das Client-Ergebnisgatter kann dafür eingerichtet sein, mit einem Ergebnisgatter, das für die Ergebnisse eingerichtet wurde, zu kommunizie ren. Zum Beispiel können die Ergebnisse in einem Space sein, und das Client-Ergebnisgatter kann mit einem Ergebnisgatter in dem Space kommunizieren.
  • In 45d kann der Dienst ein Ergebnisgatter in Schritt 2140 erzeugen. Der Dienst kann dann das Ergebnisgatter in Schritt 2142 an den Client (in einer Nachricht) senden. Das empfangene Ergebnisgatter kann dann von dem Client zum Zugriff auf die Ergebnisse verwendet werden. Diese Ausführungsform befreit den Client von der Verantwortung, das Ergebnisgatter einzurichten.
  • Für den Clientprozeß, der ursprünglich die Methode aufgerufen hat, ist der Vorgang des RMI wie hier beschrieben transparent. Für den Clientprozeß sieht es so aus, als ob die Methode lokal aufgerufen würde und die Ergebnisse lokal zur Verfügung gestellt würden. Daher können die Methodengatter in Kombination mit dem Mechanismus zur Nachrichtenübergabe es "dünnen" Clients ermöglichen, Prozesse auszuführen, die ansonsten zu groß und/oder zu komplex wären, um auf den Clients ausgeführt zu werden.
  • Ein mögliches Implementierungsbeispiel eines Methodengatters auf einer Java-Plattform folgt. Die tatsächliche Implementierung des Methodengatters in Java für irgendeine Java-Plattform ist in der Plattformbindung der verteilten Rechnerumgebung definiert. Jedes Java-Methodengatter, das Zugriff auf ein Ergebnis gewährt, ist tatsächlich eine Instanz einer Java-Klasse (ein Objekt), die die Ergebnisschnittstelle implementiert. Wenn zum Beispiel das Ergebnis ein Objekt vom Typ Tabelle wäre, kann die Klasse des Ergebnis-Methodengatters wie folgt definiert werden:
    Figure 00430001
  • Das TableMethodGate-Objekt wird in den Typ Table umgewandelt, bevor es als das Ergebnis des Methodenaufrufs zurückgegeben wird. Der Vorgang ist rekursiv. Das heißt, wenn die get-NextCell-Methode aufgerufen wird, werden eine CellMethodGate-Klasse und -Objektinstanz erzeugt, um das getNextCell-Ergebnis zu repräsentieren:
    public class CellMethodGate implements Cell {}
  • Die Auswahl, welcher Gattertyp (Nachricht oder Methode) bei einem bestimmten Dienst zu verwenden ist, wird in Kombination durch die Plattformbindung und jede Dienstannonce angesprochen bzw. behandelt. Einige Plattformen können Methodengatter möglicherweise nicht unterstützen. Wenn eine Plattform Methodengatter unterstützt, kann die Bindung ihre genaue Implementierung definieren. Zweitens kann sich die Schnittstelle einer Dienstannonce für RMI-artige Programmierung eignen oder nicht. Diejenigen Dienstschnittstellen, die ein RMI-artiges Programmierungsmodell unterstützen, werden mit dem folgenden XML-Attribut markiert:
    <MethodGateInterface=true>
  • Nachrichtengatter können auch eine Nachrichtenübergabe gemäß Publizieren und Abonnieren bzw. Vorbestellen für Ereignisse unterstützen. Nachrichtengatter mit Ereignisunterstützung können als Ereignisgatter bezeichnet werden. Das XML-Schema eines Dienstes kann eine Menge von einem oder mehreren Ereignissen angeben, die von einem Dienst veröffentlicht werden können. Ein Ereignisgatter kann aus dem XML-Schema aufgebaut werden. Das Ereignisgatter kann dafür eingerichtet werden, einige oder alle aus der Menge von Ereignissen, die von einem Dienst veröffentlicht werden, zu erkennen, diese Ereignisse zu abonnieren und jedes Ereignis zu verteilen, wenn das Ereignis von dem Dienst erzeugt wird.
  • Die Menge von Ereignissen für einen Dienst kann in dem XML-Nachrichtenschema des Dienstes beschrieben werden. Für jede Ereignisnachricht in dem XML-Schema kann das Ereignisgatter sich als einen Verbraucher bzw. Abnehmer für dieses Ereignis anmelden. Nach einer Ausführungsform kann ein Ereignisgatter alle Ereignisse bestellen, die von dem XML-Schema angegeben werden. Jede Ereignisnachricht kann unter Verwendung eines XML-Tag benannt werden. Das Ereignisgatter kann sich durch das Senden einer Bestellnachricht, die das XML-Tag enthält, für das Ereignis anmelden, um es zu abonnieren.
  • Wenn ein entsprechendes Ereignis bei dem Dienst eintritt, kann der Dienst eine Ereignisnachricht an Abonnenten senden, die das Eintreten des Ereignisses angibt. Die Ereignisnachricht kann ein XML-Ereignisdokument enthalten und kann an jedes angemeldete Gatter gesendet werden. Wenn ein angemeldetes Gatter die Ereignisnachricht empfängt, wird das XML-Ereignisdokument aus der Nachricht entfernt, und der Verteilvorgang beginnt. Ereignisverteilung ist der Vorgang, das Ereignisdokument innerhalb der Client-Plattform auszuhändigen. Jeder Abnehmer eines Ereignisses innerhalb der Client-Plattform kann sich bei dem Ereignisgatter für jeden Typ von Ereignis anmelden. Auf Java-Plattformen ist das Typisierungssystem Java (aus dem XML-Ereignistyp umgewandelt). Der Ereignisabnehmer kann dem Ereignisgatter eine Callback-Methode zur Ereignisbehandlung übergeben. Das Ereignisgatter kann eine Liste dieser Anmeldungen bzw. Abonnements speichern. Bei Ankunft der jeweiligen Ereignisnachricht bei dem Gatter (von dem Dienst, der das Ereignis erzeugt), geht das Gatter durch die Liste der Clientabnehmer und ruft jedes Handhabungsverfahren auf, wobei es das XML-Ereignisdokument als einen Parameter übergibt. Nach einer Ausführungsform ist das XML-Ereignisdokument der einzige an die Callback-Methode übergebene Parameter für die (Ereignis-) Handhabung.
  • Nach einer Ausführungsform meldet sich das Ereignisgatter automatisch im Namen der lokalen Abnehmerclients für Ereignisse an. Wenn Clients bei dem Gatter Interesse bekunden, meldet das Gatter Interesse bei dem Ereigniserzeugerdienst an. Ein Client kann auch das Interesse kündigen, was dazu führt, daß das Gatter sich bei dem Dienst, der das Ereignis erzeugt, abmeldet bzw. deregistriert.
  • Ein Ereignisgatter kann unter Verwendung des XML-Schemas eine Typüberprüfung des Ereignisdokuments durchführen, genau wie ein reguläres Nachrichtengatter bei der oben beschriebenen, standardmäßigen Art der Nachrichtenübergabe mittels Anforderung und Antwort es tut. Ein Ereignisgatter kann auch einen Authentisierungsnachweis in Nachrichten, die es sendet, aufnehmen und die Authentisierungsnachweise von empfangenen Ereignisnachrichten überprüfen.
  • Man beachte, daß jede Kombination der oben beschriebenen Gattenfunktionalität in einem einzelnen Gatter unterstützt werden kann. Jeder Typ ist nur der Klarheit halber separat beschrieben worden. Zum Beispiel kann ein Gatter ein Nachrichtengatter, ein Methodengatter und eine Ereignisgatter sein und kann Flußkontrolle und Ressourcenüberwachung unterstützen.
  • Mechanismus zum Auffinden von Diensten
  • Nach einer Ausführungsform kann die verteilte Rechnerumgebung einen Mechanismus zum Auffinden bzw. Ausfindig-Machen von Diensten beinhalten, der für Clients Methoden bereitstellt, um Dienste zu finden und die Rechte zum Benutzen einiger oder aller der Funktionen des Dienstes auszuhandeln. Man beachte, daß ein Space ein Beispiel eines Dienstes ist. Der Mechanismus zum Auffinden von Diensten kann sicher sein und kann ausgehende Anforderungen von Clients verfolgen und mit ankommenden Antworten von Diensten in Einklang bringen.
  • Ein Mechanismus zum Auffinden von Diensten kann verschiedene Eigenschaften bzw. Funk- tionen 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 Au thentisierungsnachweis 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 00460001
  • Die verteilte Rechnerumgebung kann einen Mechanismus beinhalten, der es Clients ermöglichen kann auszuhandeln, wie ein Dienst Ergebnisse eines Dienstaufrufes zurückgeben soll. Nach einer Ausführungsform kann während einer Anforderung eines Leistungsmerkmalsnachweises eine Einrichtung, durch die eine von den Verfahren zur Rückgabe von Ergebnissen gewählt werden kann, an den Dienst überbracht werden. Der Dienst kann dann eine angepaßte Dienstannonce erzeugen, die dem Client sowohl den Ergebnismechanismus, der zu verwenden ist, als auch die Dienstschnittstelle mitteilt.
  • Nach einer Ausführungsform kann die verteilte Rechnerumgebung einen Mechanismus zum Verfolgen von Suchanforderungen zum Auffinden von Diensten und von Antworten auf die Anforderungen beinhalten. Nach einer Ausführungsform können Suchanforderungs- und – antwortnachrichten ein Feld beinhalten, das verwendet werden kann, um eine Zeichenkette oder ein XML-Dokument einzuschließen. Nach einer Ausführungsform wird die Zeichenkette oder das XML-Dokument, das in dem Feld einer Anforderungsnachricht enthalten ist, auch in der Antwortnachricht zurückgegeben. Nach einer Ausführungsform muß die Zeichenkette oder das XML-Dokument in der Antwortnachricht zurückgegeben werden. Nach einer Ausführungsform kann die Zeichenkette oder das XML-Dokument zusätzliche Information enthalten, die in die Zeichenkette oder das XML-Dokument eingefügt oder an diese(s) angehängt wird, wenn sie oder es in der Antwortnachricht zurückgegeben wird. Nach einer Ausführungsform kann dieser Mechanismus beim Debugging komplexer Systeme verwendet werden. Nach einer Ausführungsform kann dieser Mechanismus auch ein Verfahren für Clients bereitstellen, um Dienste auszuwählen, die zugreifen, indem die Zeichenkette oder das XML-Dokument in der Weise verwendet wird, daß angepaßte bzw. auf den speziellen Fall zugeschnittene Suchinformation zwischen einem Client und einem Dienst übergeben wird, die nur von dem Client und dem Dienst verstanden werden kann.
  • Schnittstellen passender bzw. übereinstimmender Komponenten (Dienste)
  • Die verteilte Rechnerumgebung kann einen Mechanismus bereitstellen, um die Spezifikationsschnittstelle einer Komponente (zum Beispiel eines Dienstes) bzw. die Schnittstelle einer Komponentenspezifikation mit einer angeforderten Schnittstelle bezüglich Übereinstimmung abzugleichen. Zum Beispiel kann ein Client (der ein Dienst sein kann) einen Dienst wünschen, der einen Satz von Schnittstellenanforderungen erfüllt. Jede Komponente kann eine Beschreibung der Schnittstelle haben, mit der sie konform ist. Der Mechanismus zum Abgleich von Spezifikationsschnittstellen kann es ermöglichen, daß eine Komponente lokalisiert wird, die am besten mit den Schnittstellenanforderungen eines Anforderers übereinstimmt. Der Mechanismus zum Abgleich von Spezifikationsschnittstellen kann auch "unscharfe" bzw. "fuzzy" Übereinstimmung bzw. Abgleich von Schnittstellenanforderungen ermöglichen. Mit anderen Worten kann der Mechanismus einen Abgleich ermöglichen, ohne die genaue Spezifikation aller Aspekte der Schnittstelle zu verlangen, wodurch ein (Fuzzy)-Mechanismus einer nächstkommenden Übereinstimmung zur Verfügung steht. Nach einer Ausführungsform kann der Mechanismus zum Abgleich von Spezifikationsschnittstellen als ein mehrschichtiges Modell, das Unterklassen bildet, implementiert werden, statt Spezifikation auf einer einzelnen Schnittstellenstufe bzw. -niveau zu erfordern.
  • Nach einer Ausführungsform kann eine Komponente eine XML-Schema-Definitionssprache (XML Schema Definition Language, XSDL) verwenden, um seine Schnittstelle zu beschreiben. XSDL kann eine von Menschen interpretierbare Sprache zum Beschreiben der Schnittstelle vorsehen, wodurch Aktivitäten, die eine Intervention durch Menschen erfordert, wie das Debugging vereinfacht werden. Nach einer Ausführungsform kann die Schnittstellenbeschreibung als Teil einer Annonce (zum Beispiel einer Dienstannonce) bereitgestellt werden, wie an anderer Stelle in diesem Dokument beschrieben.
  • Unter Verwendung des Mechanismus zum Abgleich von Spezifikationsschnittstellen kann eine einfache bzw. grundsätzliche, gewünschte Schnittstelle mit einem Satz bzw. einer Menge von Beschreibungen von Schnittstellenkomponenten bzw. von Schnittstellen von Komponenten verglichen werden. Eine oder mehrere Komponenten, die mit der einfachen, gewünschten Schnittstelle übereinstimmen, können identifiziert werden. Die Schnittstellenbeschreibungen können Beschreibungen von Unterklassen enthalten, die die von den Komponenten bereitgestellten Schnittstellen spezieller beschreiben. Bei dem Suchvorgang kann die Klassentyphierarchie überprüft werden, um festzustellen, ob eine gegebene Klasse eine Unterklasse des gesuchten Typs ist. Nach einer Ausführungsform können Unterklassen Eigenschaften von der Basisklasse erben, und somit braucht die Unterklassen-spezifische Information in dieser Phase nicht überprüft zu werden. Daher kann die Suche generisch durchgeführt werden. Die identifizierten Komponenten können auf der nächsten (Unterklassen-) Stufe gesucht werden. Die Suche kann für die Unterklasse spezifisch werden und kann durchgeführt werden, indem die Unterklassen-Information, die in der Schnittstellenbeschreibung enthalten ist, interpretiert wird. Die Suche kann sich durch eine oder mehrere Unterklassen fortsetzen, bis eine oder mehrere Komponenten bestimmt sind, die die nächstkommende Übereinstimmung mit der gewünschten Schnittstelle des Anforderers liefern.
  • Nach einer Ausführungsform kann ein Mechanismus zum Abgleich von Spezifikationsschnittstellen die Fähigkeit bzw. Möglichkeit bereitstellen, zwischen zwei oder mehr Komponenten zu unterscheiden, die ähnliche Schnittstellen implementieren. Nach einer Ausführungsform kann der Mechanismus zum Abgleich von Spezifikationsschnittstellen die Fähigkeit bereitstellen, zwischen verschiedenen Revisionen derselben Komponente zu unterscheiden.
  • Nach einer Ausführungsform kann eine Komponentenbeschreibung bereitgestellt werden, die eine Spezifikation der Schnittstelle enthält, zu der die Komponente konform ist. Die Komponentenbeschreibung kann auch Information über die Komponente selbst enthalten. Die Schnittstellenbeschreibung und/oder die Komponenteninformation kann verwendet werden, um zwischen verschiedenen Implementierungen einer gegebenen Schnittstelle zu differenzieren. Die Komponentenbeschreibungen können einen kanonischen Bezeichnen 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 Bezeichnen 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. -erbringen 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 Annoncernamen 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 Anforde rung 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 Verbin dung 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ül len, 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 Intemet 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 Antworizeichenketten zurück an den Client senden. Somit kann ein Client Spaces über das Internet lokalisieren, ohne ein Programm wie einen Web-Browser unterstützen zu müssen. Leistungsfähigere Einrichtungen können die Verwendung eines Proxy vermeiden und einen Nachschlagedienst auf Internet-Basis direkt initiieren.
  • Ein vierter Weg, wie ein Client einen Space lokalisieren kann, ist durch das Erhalten oder Empfangen von Information über einen neu eingerichteten, leeren Space oder einen abgeteilten Space, wenn ein vorhandener Space geteilt wird. Ein vorhandener Space kann eine Schnittstelle zum Abtrennen eines leeren Space mit derselben Funktionalität (z. B. demselben XML-Schema) wie der Space enthalten, von dem er abgetrennt wird. Das Abtrennen bzw. Aufteilen von Spaces ist unten näher beschrieben.
  • Sobald ein Client eines Space die Annonce eines Space-Dienstes findet, kann dieser Client des Space den Space-Dienst ablaufen lassen, wie er es mit jedem anderen Dienst tun könnte. Man beachte, daß der Client des Space-Dienstes ein anderer Dienst sein kann (z. B. ein Dienst, der eine Annonce in einem Space machen möchte). Nach einer Ausführungsform, wie in 20 dargestellt, kann der Client des Space, wenn er einen Space-Dienst ablaufen lassen möchte, zuerst einen Authentisierungsdienst für den Space ablaufen lassen, um einen Authentisierungsnachweis zu erhalten, wie bei 300 dargestellt. Der Authentisierungsdienst kann in der Dienstannonce des Space-Dienstes angegeben sein. Der Client des Space verwendet den Authentisierungsnachweis, das XML-Schema des Space (aus der Dienstannonce des Space) und den URI des Space (aus der Dienstannonce des Space), um ein Gatter für den Space einzurichten, wie bei 302 angegeben. Der Client des Space kann dann den Space-Dienst unter Verwendung des Gatters ablaufen lassen, um Nachrichten an den Space-Dienst zu senden. Eine erste solche Nachricht ist bei 304 angegeben.
  • Für Ausführungsformen, die Authentisierung einsetzen, verwendet der Space-Dienst dann, wenn der Space-Dienst die erste Nachricht von dem Client mit dem eingebetteten Authentisierungsnachweis empfängt, denselben Authentisierungsdienst (der in der Dienstannonce des Space-Dienstes angegeben ist), um den Client zu authentisieren und dadurch seine Identität zu ermitteln, wie bei 306 angegeben. Der Space-Dienst kann die Leistungsmerkmale des Client feststellen und sie an den Authentisierungsnachweis binden, wie bei 308 angegeben.
  • Wie bei 310 angegeben, kann ein Client eines Space verschiedene Spacefunktionen durch Senden von Nachrichten an den Space-Dienst ausführen. Nach einer Ausführungsform übergibt ein Client eines Space seinen Authentisierungsnachweis in der Anforderung, wenn er eine Anforderung an den Space-Dienst sendet, so daß der Space-Dienst die Anforderung gegen die spezifischen Leistungsmerkmale des Client prüfen kann.
  • Jeder Space ist typischerweise ein Dienst und kann ein XML-Schema haben, das die Hauptfunktionalität des Space-Dienstes definiert. Das XML-Schema kann die Clientschnittstelle zu dem Space-Dienst spezifizieren. Nach einer Ausführungsform können alle Space-Dienste eine Basisstufe von Space-bezogenen Nachrichten bereitstellen. Die Basisstufe der Space-Funktionalität kann die grundlegende Space-Funktionalität sein, die von den meisten Clients einschließlich kleiner Einrichtungen bzw. Geräte wie PDAs verwendet werden kann. Es kann wünschenswert sein, zusätzliche Funktionalität vorzusehen, z. B. für höher entwickelte Clients. Erweiterungen zu der Basisstufe eines Space können bewerkstelligt werden, indem mehr Nachrichten dem XML-Schema, das den Space ankündigt, hinzugefügt werden. Zum Beispiel führen nach einer Ausführungsform die Basisstufen-Nachrichten keinen Beziehungsgraphen auf den Annoncen ein. Zum Beispiel können Nachrichten zum Traversieren einer Hierarchie von Annoncen eine Space-Erweiterung sein. Solche zusätzliche Funktionalität kann durch ein oder mehrere erweiterte XML-Space-Schemata oder Schemaerweiterungen für einen Space bereitgestellt werden. Die erweiterten Schemata können das Basis-Schema umfassen, so daß Clients eines erweiterten Space immer noch auf den Space als einen Basis-Space zugreifen können.
  • Nach einer Ausführungsform kann ein Basis-Space-Dienst ein transientes Behältnis von XML-Dokumenten (z. B. Annoncen von Diensten, Ergebnisse von laufenden Diensten) bereitstellen. Jedoch kann ein Basis-Space-Dienst nach einer Ausführungsform eventuell keine hochentwickelten Funktionen bereitstellen, um die Dauerhaftigkeit von Space-Inhalt, Navigation oder Erzeugung von Space-Struktur (z. B. Hierarchie) und ein Transaktionsmodell zur Verfügung zu stellen. Ein Mechanismus zum Unterstützen von Dauerhaftigkeit, Hierarchie und/oder Transaktionen ist die Erweiterung des XML-Schemas. Da erweiterte Spaces immer noch das grundlegende XML-Schema enthalten, können Clients erweiterte Spaces immer noch als Basis-Spaces behandeln, wenn gerade die Basis-Space-Funktionalität alles ist, was gebraucht wird oder unterstützt werden kann.
  • Nach einer Ausführungsform kann der Basis-Space transient sein. Der Basis-Space kann aus vielen Gründen akzeptabel sein. Dienstanbieter können ihre Dienste in verschiedenen Spaces registrieren. Nach einer Ausführungsform müssen Dienste ständig Überlassungen beim Veröffentlichen von Information in den Spaces erneuern. Deswegen können die Dienstannoncen insofern transient sein, als sie oft neu aufgebaut und/oder neu bestätigt werden. Es kann jedoch wünschenswert sein, für eine gewisse Dauerhaftigkeit in einem Space zu sorgen. Zum Beispiel kann ein Space, der Ergebnisse hat, eine gewisse Dauerhaftigkeit für Benutzer bereitstellen, die sicher sein wollen, daß Ergebnisse für eine bestimmte Zeit nicht verloren gehen. Nach einer Ausführungsform kann für Dauerhaftigkeit gesorgt werden, indem eine Space-Schnittstelle spezifiziert wird, bei der der Client steuern kann, welche Objekte in dem Space von einem dauerhaften Speicher unterstützt werden, und das Beibehalten dieses Dauerspeichers verwalten kann. Die Dauerschnittstelle kann mit einem erweiterten XML-Schema für den Space, der die Schnittstellen für Dauerhaftigkeit definiert, spezifiziert werden.
  • Nach einer Ausführungsform kann ein Basis-Space eine Schnittstelle vorsehen, über die ein XML-Dokument zu einem Space hinzugefügt und mittels einer Zeichenkette identifiziert werden kann. Der Basis-Space sieht möglicherweise keine Hierarchie für die verschiedenen, so benannten XML-Dokumente in dem Space vor. In Ausführungsformen, in denen eine Unterstützung einer Hierarchie gewünscht wird, können zusätzliche Schnittstellen definiert werden (die das XML-Schema erweitern), über die der Benutzer eine Hierarchie definieren kann. Andere Schnittstellen können bereitgestellt werden, um in der Hierarchie zu navigieren oder in einem Beziehungsgraphen per Position zu navigieren. Jedoch können andere Benutzer die Schnittstelle des Basis-Space immer noch benutzen, um auf dieselben Dokumente ohne jegliche Hierarchie zuzugreifen. Schnittstellen für eine andere Space-Struktur können ebenso in erweiterten Space-Schemata vorgesehen werden.
  • Erweiterte XML-Space-Schnittstellen können auch für Space-Transaktionsmodelle vorgesehen werden. Zum Beispiel kann ein erweitertes Space-XML-Schema bereitgestellt werden, das eine Schnittstelle für ACID-Transaktionen spezifiziert. ACID ist ein Akronym, das verwendet wird, um vier Eigenschaften von Transaktionen auf Unternehmensniveau zu beschreiben. ACID steht für Unteilbarkeit (Atomicity), Konsistenz (Consistency), Entkopplung bzw. Trennung (Isolation) und Dauerhaftigkeit (Durability). Unteilbarkeit bedeutet, daß eine Transaktion vollständig vollzogen oder gar nicht vollzogen werden sollte. Im Falle eines Scheiterns sollten alle Operationen und Vorgänge rückgängig gemacht werden und alle Daten sollten in ihren vorherigen Zustand zurückgesetzt werden. Konsistenz bedeutet, daß eine Transaktion ein System von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen sollte. Entkopplung bedeutet, daß jede Transaktion unabhängig von anderen Transaktionen, die zur selben Zeit auftreten, geschehen sollte. Dauerhaftigkeit bedeutet, daß abgeschlossene Transaktionen permanent bestehen bleiben sollten, z. B. auch während eines Systemausfalls. Es können auch andere Transaktionsmodelle in erweiterten Space-Schemata spezifiziert werden.
  • Erweiterte Space-Schemata können XML-Dokumente sein, die die Nachrichtenschnittstelle (z. B. XML-Nachrichten) zur Benutzung der erweiterten Space-Eigenschaften, -Funktionalität oder Einrichtungen spezifizieren. Ein Space kann ein Basis-Schema und mehrere erweiterte Schemata haben. Dies kann es erleichtern, abhängig von der Authentisierung der Clients unterschiedlichen Clients unterschiedliche Stufen von Diensten zur Verfügung zu stellen.
  • Neben Erweiterungen für die Dauerhaftigkeit eines Space, seine Struktur und Transaktionen können auch andere Space-Erweiterungen nach Bedarf spezifiziert werden. Zum Beispiel können Erweiterungen vorgesehen werden, um Annoncen auf der Element- oder Attributebene zu manipulieren: Lesen, Schreiben oder Wegnehmen von Annoncenelementen; Lesen, Schreiben oder Wegnehmen von Annoncenattributen; und Anmelden für Nachrichten mit Ereignismeldungen zu Annoncen. Ein Space kann praktisch jede beliebige Anzahl von Funktionen bereitstellen und sie nach Wunsch in Basis- und erweiterte Schemata anordnen. Nach einer Ausführungsform müssen alle Basis-Spaces Funktionen zum Lesen, Schreiben, Wegnehmen und Durchsuchen von Annoncen und für Anmeldungen für Space-Ereignisse bereitstellen.
  • Verschiedene Space-Funktionen können bereitgestellt werden. Nach einigen Ausführungsformen kann eine Funktion zum Aufbau einer Sitzung mit dem Space vorgesehen werden. Nach einer solchen Ausführungsform ist der Rest der Space-Funktionalität nicht verfügbar, bis dies erfolgt ist. Nach anderen Ausführungsformen ist der Begriff einer Sitzung nicht vorgesehen oder er ist optional und/oder implementierungsabhängig.
  • Eine weitere Space-Funktion kann sein, eine Dienstannonce zu einem Space hinzuzufügen oder sie aus einem Space zu entfernen. Eine Space-Funktion kann auch zum Hinzufügen oder Entfernen eines XML-Dokumentes (nicht einer Annonce, aber vielleicht eines Ergebnisses in einen Space) zur Verfügung gestellt werden. Der Space-Dienst kann die Eindeutigkeit eines Eintrags überprüfen, bevor er das Hinzufügen des Eintrags erlaubt. Zum Beispiel kann jeder Eintrag, der zu einem Space hinzugefügt wird, einer benutzerspezifischen Zeichenkette zugeordnet werden, die den Eintrag identifiziert und die verwendet werden kann, um die Eindeutigkeit des Eintrags zu überprüfen.
  • Nach einer Ausführungsform kann ein Client eine Auflistung, einen Baum oder eine andere Darstellung aller Dienste anfordern, die in dem Space angekündigt werden. Der Benutzer kann daraufhin durch die Annoncen durchblättern oder durch den gewünschten Dienst manövrieren und auswählen. Ein Space kann auch eine Funktion zum Durchsuchen vorsehen, die es einem Client ermöglicht, nach einem Dienst durch Angabe von Schlüsselwörtern oder Namensketten zu suchen. Nach einer Ausführungsform kann eine Space-Funktion einen Mechanismus bereitstellen, um einen Space-Eintrag durchzusehen, der dem Space hinzugefügt wurde. Die Funktion zum Durchsuchen kann nach Zeichenketten suchen, die einem Namen, einer Wildcard oder sogar einer Datenbankanfrage entsprechen. Die Funktion zum Durchsuchen kann mehrere Einträge zurückliefern, aus denen der Client einen auswählen oder eine einengende Suche durchführen kann. Nach einer Ausführungsform kann die Funktion zum Durchsuchen einen Mechanismus vorsehen, um eine Dienstannonce zu lokalisieren, die einem bestimmten XML-Schema entspricht. Der Client kann ein bestimmtes XML-Schema oder einen Teil eines bestimmten XML- Schemas angeben, nach dem innerhalb des Space gesucht wird. Damit kann innerhalb eines Space nach einem Dienst entsprechend seiner Schnittstellenfunktionalität gesucht werden.
  • Eine weitere Space-Funktion, die in der verteilten Rechnerumgebung bereitgestellt wird, ist ein Mechanismus, der es Diensten und Clients ermöglicht, transiente Dokumente zu finden, die auf einem Modell zur Typisierung wie XML beruhen. Der Mechanismus kann ein allgemein verwendeter Mechanismus zum Durchsuchen von typisierten Dokumenten sein. Nach einer Ausführungsform kann der Mechanismus zum Durchsuchen auf XML beruhen. Der Mechanismus zum Durchsuchen kann es Clients und Diensten ermöglichen, Dokumente im allgemeinen zu finden, einschließlich Diensten durch Dienstannoncen.
  • Nach einer Ausführungsform kann ein Paar von Space-Durchsuch- und Antwortnachrichten verwendet werden, um es Clients und Diensten zu ermöglichen, XML-Dokumente zu finden, die innerhalb eines transienten Dokumentenspeichers im Netzwerk (Space) gespeichert sind. Der Space kann ein Dokumenten-Space sein, der verwendet wird, um eine Vielzahl von Dokumenten zu speichern. Nach einer Ausführungsform sind die Dokumente XML-Dokumente oder Nicht-XML-Dokumente, die in XML eingekapselt sind. Spaces sind an anderer Stelle weitergehend beschrieben. Die Durchsuch-Nachrichten können auf jede Art von XML-Dokument wirken, das in dem Space gespeichert ist, einschließlich Dienstannoncen und Annoncen von Gerätetreibern. Nach einer Ausführungsform kann ein Client (der ein anderer Dienst sein kann) einen Auffindungsmechanismus verwenden, wie an anderer Stelle beschrieben, um einen oder mehrere Dokumenten-Spaces zu finden. Daraufhin kann der Client Durchsuch-Nachrichten für Spaces verwenden, um in dem Space gespeicherte Dokumente zu lokalisieren.
  • Die verteilte Rechnerumgebung kann einen Mechanismus beinhalten, der es Diensten und Clients ermöglicht, sich für Ereignisse über die Veröffentlichung von XML-Dokumenten anzumelden und Ereignisse über die Veröffentlichung von XML-Dokumenten zu empfangen. Ereignisse können die Veröffentlichung und das Entfernen von XML-Dokumenten in und aus einem transienten Behältnis für XML-Dokumente wie einem Space umfassen. Nach einer Ausführungsform kann ein Ereignis ein XML-Dokument sein, das auf ein anderes XML-Dokument verweist.
  • Nach einer Ausführungsform kann ein Paar von Ereignis-Anmeldungs- und Antwortnachrichten verwendet werden, um es Clients und Diensten zu ermöglichen, sich für Ereignisse bezüglich Dokumenten anzumelden, die zu einem Space hinzugefügt oder daraus entfernt werden. Nach einer Ausführungsform kann eine Ereignisanmeldung mittels eines Überlassungs- bzw. Pachtmechanismus, der an anderer Stelle beschrieben wird, überlassen bzw. gepachtet werden. Nach einer Ausführungsform kann eine Anmeldung gestrichen werden, wenn die Überlassung gestrichen wird oder erlischt. Nach einer Ausführungsform kann das Erneuern der Überlassung einer Anmeldung eine Anmeldung erneuern.
  • Nach einer Ausführungsform kann eine Ereignisanmeldungsnachricht ein XML-Schema enthalten, das als ein Mechanismus zum Erkennen bzw. Feststellen von übereinstimmenden Dokumenten verwendet werden kann. Dokumente, die mit dem Schema übereinstimmen, können durch die Anmeldung abgedeckt werden. Nach einer Ausführungsform kann jedes Dokument, das zu einem Space hinzugefügt wird und mit dem XML-Schema übereinstimmt, eine Space-Ereignisnachricht erzeugen.
  • Es kann auch eine Space-Funktion bereitstehen, für die sich ein Client registrieren (und wieder abmelden) kann, um eine Benachrichtigung zu erhalten, wenn etwas zu einem Space hinzugefügt oder aus ihm entfernt wird. Ein Space kann einen transienten Inhalt enthalten, der Dienste repräsentiert, die zu einem Space hinzugefügt werden und aus ihm entfernt werden. Es kann ein Mechanismus vorgesehen werden, um einen Client zu benachrichtigen, wenn zum Beispiel ein Dienst verfügbar wird oder nicht mehr verfügbar ist. Ein Client kann sich bei einem Ereignisdienst registrieren, um solche Benachrichtigungen zu erhalten. Nach einer Ausführungsform kann sich ein Client registrieren, um benachrichtigt zu werden, wenn ein Dienst mit einem Namen, der mit einer angegebenen Zeichenkette übereinstimmt, oder mit einem Schema, das mit einem angegebenen Schema (oder Teil eines Schemas) übereinstimmt, zu einem Space hinzugefügt oder aus ihm entfernt wird. Somit kann die Anfrage, sich bei einer Benachrichtigungsfunktion für Space-Ereignisse zu registrieren, dasselbe oder etwas ähnliches sein wie eine Anfrage an eine oben beschriebene Suchfunktion nach Diensten.
  • 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 alte 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 AdvElementValue-ChangeEvent verfügbar sein.
  • Eine Typhierarchie von Space-Ereignissen für eine Ausführungsform ist in 21 dargestellt. Typen können in XML definiert und in Java oder in irgendeiner anderen geeigneten, objektorientierten Sprache wie C++ verwendet werden.
  • Ein Space kann eine Funktion zum Instantiieren eines in dem Space angekündigten Dienstes für einen Client zur Verfügung stellen. Die Instantiierung eines Dienstes heißt, die Initialisierung ausgeführt zu haben, die es einem Client ermöglicht, einen Dienst ablaufen lassen zu können. Eine Ausführungsform der Instantiierung von Diensten ist in 22 dargestellt. Zum Instantiieren eines Dienstes kann ein Client zuerst eine der in dem Space veröffentlichten Dienstannoncen auswählen, wie bei 320 angegeben. Der Client kann verschiedene Funktionen wie die Funktion zum Durchsu chen 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 eX tensible 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 Dia gramm 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.
  • 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 Drukkereinrichtung aufbaut (zum Beispiel ein Benutzer mit einem Laptop, der einen Client ausführt, möchte ein Dokument drucken), um das XML-Schema des Dienstes zum Herstellen einer Verbindung mit dem Dienst und zum Ausführen des Dienstes zu übergeben, der die Druckfunktionalität auf der Druckereinrichtung zur Verfügung stellt. Einige Einrichtungen können auch nur Annoncen für ihre Dienste in einer bestimmter Nähe bzw. Umgebung oder einem lokalen Netzwerk unterhalten. Eine solche Einrichtung möchte möglicherweise keinen Zugang unterstützen oder hat möglicherweise keinen Zugang zu Transportmitteln für eine breitere Zugangsmöglichkeit.
  • Ein Beispiel einer Diensteinrichtung, in der es für die Einrichtung wünschenswert sein kann, das Beibehalten von Dienstannoncen in einem Space zu vermeiden oder zu begrenzen, ist eine Einrichtung, deren Funktionalität auf Nachbarschaftsbasis verfügbar ist. Auf Nähe beruhende Dienste können Annoncen ihrer Funktionalität auf Anforderung bereitstellen. Diese Annoncen sind möglicherweise nicht allgemein zugänglich. Zum Beispiel können auf Nähe beruhende Dienste in einem drahtlosen Kommunikationssystem zur Verfügung gestellt werden. Der Begriff "drahtlos" kann sich auf ein System zur Kommunikation, Überwachung oder Steuerung beziehen, in dem elektromagnetische oder akustische Wellen ein Signal durch den atmosphärischen Raum anstatt entlang eines Drahtes übertragen. In den meisten drahtlosen Systemen werden Funk- (Radio Frequency, RF) oder Infrarot- (IR) Wellen verwendet. Typischerweise muß in einem auf Nähe beruhenden drahtlosen System eine Einrichtung, die einen Sende-/Empfänger bzw. Transceiver aufweist, innerhalb der Reichweite (Nähe) einer anderen Einrichtung sein, um einen Kommunikationskanal aufzubauen und aufrecht zu halten. Eine Einrichtung kann ein Netzknoten bzw. Hub sein, um andere Einrichtungen mit einem drahtlosen lokalen Netzwerk (Local Area Network, LAN) zu verbinden.
  • Wie bereits erwähnt können Ausführungsformen der verteilten Rechnerumgebung einen Mechanismus unter Verwendung eines Such-Space zur Verfügung stellen, der es Clients ermöglicht, mit Diensten in Kontakt zu treten. In einer nachbarschaftsbezogen Rechnerumgebung kann eine Ausführungsform der verteilten Rechnerumgebung einen Mechanismus zum Auffinden von Diensten bereitstellen, den Clients verwenden können, um Dienste zu finden, ohne Such-Spaces als Treffpunkte zu benutzen. Ein Beispiel einer nachbarschaftsbezogen Rechnerumgebung ist eine IrDA-Punkt-zu-Punkt-Kommunikationsumgebung. In einer nachbarschaftsbezogen Rechnerumgebung kann der Nachbarschaftsmechanismus den "physikalischen" Standort des Dienstes für den Client finden. Zum Beispiel kann in einer IrDA-Umgebung bei der Einrichtung, die den Dienst oder die Dienste enthält, die der Client verwenden möchte, physikalisch bzw. räumlich auf die Clienteinrichtung gezeigt werden.
  • Der Mechanismus zum Auffinden von Diensten in der Nähe kann es dem Client ermöglichen, direkt nach Dienstannoncen zu suchen, anstatt eine Suchanforderung an einen Such-Space zu senden, um nach Dienstannoncen zu suchen. Da die Clienteinrichtung eine Nachbar- bzw. Nachbarschaftsverbindung zu der Diensteinrichtung aufgebaut haben kann, kann der Client direkt den gewünschten Dienst anfordern. Zum Beispiel kann eine PDA-Clienteinrichtung eine Nachbarschaftsverbindung zu einer Druckereinrichtung aufbauen; der Client "weiß" möglicherweise, wie eine Verbindung zu einem Druckdienst auf der Druckereinrichtung anzufordern ist.
  • Nach einer Ausführungsform kann der Client eine Nachricht zum Auffinden eines Dienstes in der Nähe an die Diensteinrichtung senden. Die Nachricht kann Information beinhalten, die einen gewünschten Dienst auf der Diensteinrichtung spezifiziert, zu der die Clienteinrichtung eine Nachbarschaftsverbindung hat. Nach einer Ausführungsform kann ein Dienst auf der Diensteinrichtung auf die Nachricht zum Auffinden eines Dienstes in der Nähe antworten und eine Dienstannonce an den Client senden, die der Client verwenden kann, um mit dem gewünschten Dienst Verbindung aufzunehmen. Die Nachricht zum Auffinden eines Dienstes in der Nähe kann auch Information beinhalten, die verwendet werden kann, um den Client zu authentisieren und die Leistungsmerkmale des Client auf dem Dienst einzurichten. Unter Verwendung der empfangenen Dienstannonce kann der Client ein Gatter einrichten, um eine Kommunikation mit dem gewünschten Dienst aufzubauen. Gleichwohl kann es immer noch wünschenswert sein, Annoncen für Dienste zu veröffentlichen, die ihre Annoncen nicht in einem Space, der allgemein zugänglich ist, unterhalten möchten oder können. Nach einer Ausführungsform einer verteilten Rechnerumgebung kann eine Einrichtung, die eine Verbindung mit einer Einrichtung aufbaut, die ihre Dienstannonce(en) nicht veröffentlicht wie eine nachbarschaftsbezogene Einrichtung, Dienstannoncen veröffentlichen, die sie von der nicht veröf fentlichenden 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.
  • Überlassungen bzw. Pachten
  • Überlassungen (Leasing) können in der verteilten Rechnerumgebung verwendet werden, um mit teilweisem Ausfall, Synchronisation von Ressourcen (Zeitplanung bzw. Scheduling) umzugehen und für einen ordnungsgemäßen Vorgang zum Aufräumen von Ressourcen zu sorgen. Überlassungen können das gesamte verteilte System dabei unterstützen, unabhängige Clients und Dienste, die kommen und gehen können, zu verwalten. Die verschiedenen Ressourcen, die Clients von Diensten (einschließlich Space-Diensten) erhalten, können von diesen Diensten überlassen werden. Im allgemeinen kann oder braucht nicht jede Ressource überlassen (zu) werden. Nach einer Ausführungsform ist es Sache der Implementierung jedes einzelnen Dienstes festzulegen, welche seiner Ressourcen überlassen bzw. gepachtet werden müssen. Insbesondere brauchen Ressourcen, die von einer großen Zahl von Clients gleichzeitig verwendet werden, möglicherweise nicht überlassen zu werden oder erfordern stattdessen angepaßte Überlassungsprotokolle. Diese Klasse von Überlassung kann dem Dienstanbieter überlassen sein. Angepaßte Protokolle wie zum Beispiel diejenigen zum Implementieren von Transaktionen können auf dem grundlegenden Überlassungsschema bzw. -system aufgebaut werden. Nach einer Ausführungsform ist das grundlegende Überlassungsmodell ein relatives Modell auf Zeitbasis.
  • Dienste können Überlassungen an Clients herausgeben und Operationen auf diesen Überlassungen zur Verfügung stellen. Nach einer Ausführungsform ist die gesamte derartige Funktionalität eines Dienstes zur Überlassung Teil des XML-Schemas dieses Dienstes. Somit kann ein Client sein Gatter (das dem Dienst entspricht und für das XML-Schema des Dienstes eingerichtet ist) verwenden, um Überlassungsoperationen durchzuführen. Nach einer Ausführungsform stellen alle Dienste, die Überlassungen herausgeben, die folgenden Überlassungsoperationen (nur möglich für die Besitzer der Überlassung) bereit: (i) Erneuern einer Überlassung (angegebene Parameter: Überlassung (z. B. Überlassungs-ID, Überlassungsnachweis), neue angeforderte Überlassungszeit bzw. -dauer), und (ii) Streichen bzw. Löschen einer Überlassung (angegebene Parameter: Überlassung (z. B. Überlassungs-ID, Überlassungsnachweis)). Nach einer Ausführungsform werden alle Überlassungen für eine bestimmte relative Zeitspanne (Dauer der Überlassung) gewährt, die ausgehandelt werden kann. Der Anforderer kann eine bestimmte Zeitspanne (z. B. in Sekunden) angeben, und der Geber bzw. Gewährende kann die Überlassung für jede Dauer bis zu dieser Zeitspanne gewähren. Nach einer Ausführungsform kann ein Wert von –1 verwendet werden, um eine unbestimmte Überlassung anzugeben.
  • Nach einer Ausführungsform kann eine Dienstannonce eine oder mehrere Überlassungsadressen beinhalten. Nach einer Ausführungsform können die Überlassungsadressen URIs sein. Standardüberlassungsnachrichten zum Erneuern und Löschen von Überlassungen von Dienstressourcen können an einen Überlassungs-URI gesendet werden. Ein Beispiel für einen Überlassungs-URI:
    <leaser>service1://resource1</leaser>
  • Eine Annonce kann auch verschiedene Überlassungsnachrichten wie oben beschrieben beinhalten. Überlassungsnachrichten können Nachrichten zum Erneuern und Löschen von Überlassungen für Ressourcen des Dienstes beinhalten. Nach einer Ausführungsform können die Nachrichten in einem XML-Schema in der Annonce enthalten sein.
  • Der Überlassungsmechanismus kann einen Mechanismus zum Erkennen eines Dienst- und Client-Ausfalls bereitstellen. Überlassungen können auch einen Mechanismus vorsehen, um gemeinsam genutzten und exklusiven Zugrift 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 zugegriften). 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 Barunterliegenden 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, (ü) 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). Emeuerungsnachrichten 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.
  • Standard-Überlassungsnachrichten können in der verteilten Rechnerumgebung definiert sein. Nach einer Ausführungsform können zusätzliche Überlassungsnachrichten durch angepaßte Überlassungsmodelle definiert werden. Nach einer Ausführungsform kann jeder Dienst, der Überlassungen herausgibt, einen URI angeben, an den Nachrichten zur Erneuerung und zum Löschen von Überlassungen gesendet werden können. Überlassungsnachrichten können eingebettete Berechtigungsnachweise enthalten, um den Sender der Nachricht zu authentisieren. Nach einer Aus führungsform kann ein Client den Berechtigungsnachweis (z. B. einen Authentisierungsnachweis) von einem Authentisierungsdienst bei der Instantiierung des Dienstes und den Berechtigungsnachweis in Nachrichten einbetten, die er an den Dienst sendet. Nach einer Ausführungsform kann der Authentisierungsdienst in der Dienstannonce für den Dienst angegeben worden sein. Der Dienst kann dann den Berechtigungsnachweis authentisieren, wenn er in einer Nachricht von dem Client empfangen wird. Nach einer Ausführungsform kann der Dienst den Berechtigungsnachweis, wenn er zum ersten Mal empfangen wurde, an denselben Authentisierungsdienst senden, der von dem Client verwendet wurde, um den Berechtigungsnachweis zu erzeugen. Somit kann das Ausgeben und Einbetten von Berechtigungsnachweisen in Überlassungsnachrichten verwendet werden, um für eine sichere Überlassungsumgebung zu sorgen. Zum Beispiel kann das Einbetten eines Berechtigungsnachweises in einer Nachricht zum Löschen einer Überlassung effektiv verhindern, daß irgend jemand außer dem autorisierten, durch Berechtigung ausgewiesenen Client (und dem Dienst, der die Überlassung ausgibt) die Überlassung löscht. Siehe den Abschnitt "Authentisierung und Sicherheit" zu weiteren Einzelheiten.
  • 44 ist ein Flußdiagramm, das einen Mechanismus zur Überlassung von Ressourcen darstellt. In Schritt 2000 kann ein Client eine Überlassung einer Ressource anfordern, die von einem Dienst bereitgestellt wird. Nach einer Ausführungsform erfolgen Überlassungen möglicherweise auf Zeitbasis, d. h. sie werden dem Client für eine Zeitspanne gewährt. Nach einer anderen Ausführungsform erfolgen Überlassungen möglicherweise nicht auf Zeitbasis und bleiben erhalten, bis sie von dem Client oder dem Dienst gelöscht werden. Nach einer Ausführungsform kann der Dienst ein Space-Dienst sein, und die Ressource kann eine Dienstannonce für einen anderen Dienst sein und dem Client von dem Space-Dienst überlassen werden. Nach einer Ausführungsform kann der Dienst ein Space-Dienst sein, der Client kann selbst ein Dienst sein, und die Ressource kann die Veröffentlichung einer Dienstannonce durch den Space-Dienst im Namen des Client/Dienstes sein. Nach einer Ausführungsform kann der Client eine Anforderungsnachricht an den Dienst senden, die die Ressource angibt und die Überlassung der Ressource anfordert. Nach einer Ausführungsform kann die Nachricht eine angeforderte Überlassungsdauer spezifizieren. Nach einer Ausführungsform kann ein Nachrichtengatter im Client die Nachricht zur Anforderung einer Überlassung im Namen des Client an den Dienst senden. Nach einer Ausführungsform kann die Nachricht zur Anforderung einer Überlassung eine XML-Nachricht sein.
  • In Schritt 2002 kann der Dienst die Überlassung der Ressource dem Client gewähren. Nach einer Ausführungsform kann der Dienst eine Nachricht zur Anforderung einer Überlassung von dem Client empfangen. Der Dienst kann daraufhin die Überlassung der Ressource gewähren. Nach einer Ausführungsform kann die Nachricht zur Anforderung einer Überlassung eine angeforderte Überlassungsdauer enthalten. Nach einer Ausführungsform kann der Dienst die Überlassung für eine gewährte Überlassungsdauer kleiner oder gleich der angeforderten Überlassungsdauer einräumen. Nach einer Ausführungsform kann die angeforderte Überlassungsdauer für eine unbestimmte Überlassung (d. h. die Zeitspanne läuft nicht ab) sein. Nach dieser Ausführungsform muß der Client oder der Dienst die Überlassung löschen, da die Überlassung selbst nicht abläuft.
  • Die dem Client zur Verfügung gestellte Dienstannonce kann bei der Einrichtung einer anfänglichen Überlassung einer Ressource oder von Ressourcen verwendet werden, die von dem Dienst bereitgestellt und von dem Client während des Zugriffs auf den Dienst angefordert werden. Nach einer Ausführungsform kann die Überlassung der Ressource zum Zeitpunkt der Instantiierung des Dienstes gewährt werden. Nach dieser Ausführungsform sendet der Client womöglich keine Nachricht zur Anforderung einer Überlassung an den Dienst senden, um die Überlassung anzufordern. Nach dieser Ausführungsform kann der Dienst eine anfängliche Überlassung der Ressource oder der Ressourcen an den Client gewähren, wenn er aus der Dienstannonce instantiiert wird. Zum Beispiel kann ein Space-Dienst als Reaktion auf eine Anforderungsnachricht von einem Client einen Dienst aus einer Dienstannonce auf dem Space-Dienst instantiieren. Der Dienst kann die Überlassungen an den Client für eine oder mehrere von dem Dienst bereitgestellten Ressourcen gewähren, wenn er instantiiert wird, ohne es erforderlich zu machen, daß der Client explizit eine Nachricht sendet, die die Überlassungen anfordert.
  • In Schritt 2004 kann der Client eine Erneuerung der Überlassung anfordern. Nach einer Ausführungsform kann der Dienst eine Anforderungsnachricht zur Erneuerung einer Überlassung an den Client senden. Nach einer Ausführungsform kann die Anforderungsnachricht zur Erneuerung einer Überlassung vor dem Ablauf des zuvor gewährten Überlassungszeitraumes an den Client gesendet werden. Der Client kann auf die Nachricht dem Dienst mit einer Antwortnachricht zur Erneuerung einer Überlassung antworten, die eine Erneuerung der Überlassung anfordert. Nach einer Ausführungsform, die Überlassen auf Zeitbasis verwendet, kann die Antwortnachricht zur Erneuerung einer Überlassung eine angeforderte Überlassungszeitspanne enthalten. Nach einer anderen Ausführungsform, die nicht-zeitbasiertes Überlassen verwendet, kann die Antwortnachricht zur Erneuerung einer Überlassung anfordern, daß die Überlassung fortgesetzt wird. Nach einer Ausführungsform kann der Client eine Antwortnachricht zur Erneuerung einer Überlassung zurückgeben, die den Dienst darüber in Kenntnis setzt, daß die Überlassung nicht weiter benötigt wird. Nach einer Ausführungsform sendet der Client möglicherweise keine Antwortnachricht zur Erneuerung einer Überlassung, und der Dienst könnte annehmen, wenn er keine Antwortnachricht empfängt, daß der Client die Überlassung nicht weiter benötigt. Zum Beispiel kann der Client vom Netzwerk getrennt worden sein. Dies versorgt den Dienst mit einem Mechanismus zum Entdecken nicht verwendeter Überlassungen und zur Bereinigung von Ressourcen einschließlich Überlassungsressourcen.
  • Nach einer Ausführungsform sendet der Dienst möglicherweise keine Anforderungsnachricht zur Erneuerung einer Überlassung an den Client. Nach dieser Ausführungsform kann der Client stattdessen eine gewährte Überlassungszeitspanne überwachen und eine Nachricht zur Emeuerung der Überlassung an den Dienst senden, bevor die gewährte Überlassungszeitspanne abläuft. Die Nachricht zur Emeuerung der Überlassung kann die Ressource angeben, die überlassen wird, und eine angeforderte, neue Überlassungszeitspanne für die Überlassung der Ressource. Nach einer Ausführungsform kann die angeforderte Überlassungszeitspanne für eine unbestimmte Überlassung (d. h. die Zeitspanne läuft nicht ab) vorgesehen sein. Wenn der Client die Überlassung nicht mehr wünscht, braucht der Client kein Erneuerungsnachricht zu senden und kann dadurch die Überlassung aufgeben.
  • Nach einer Ausführungsform kann ein Nachrichtengatter des Client die Erneuerung von Überlassungen im Namen des Clientprozesses behandeln, wodurch der Clientprozeß von der Verantwortung, das Aufrecht-Erhalten von Überlassungen zu behandeln, freigestellt wird. Nach einer Ausführungsform kann das Nachrichtengatter des Client automatisch auf von dem Dienst gesendete Anforderungsnachrichten zur Erneuerung einer Überlassung antworten. Nach einer Ausführungsform kann eine Standard-Antwortnachricht zur Erneuerung von Überlassungen in ein Gatter kompiliert werden und automatisch an den Dienst gesendet werden, wenn das Gatter die Anforderungsnachricht zur Erneuerung einer Überlassung empfängt. Nach einer anderen Ausführungsform sendet der Dienst möglicherweise keine Anforderungsnachrichten zur Erneuerung einer Überlassung. Nach dieser Ausführungsform kann das Clientgatter automatisch Nachrichten zur Erneuerung einer Überlassung senden. Nach einer Ausführungsform kann das automatische Senden periodisch durchgeführt werden. Nach einer Ausführungsform kann das Clientgatter eine aktuell gewährte Überlassungszeitspanne überwachen und kann eine Nachricht zur Erneuerung einer Überlassung senden, bevor die aktuell gewährte Überlassungszeitspanne abläuft.
  • Nach einer Ausführungsform kann eine Überlassung auf einer von mehreren Zugangsstufen einschließlich exklusivem Zugang und gemeinsam genutztem Zugang vorliegen. Exklusiver Zugang gibt dem Client exklusive Rechte auf die Ressource, indem sie während der Dauer der Überlassung anderen Clients den Zugang zu der Ressource verbietet. Gemeinsam genutzter Zugang gibt anderen Clients das Recht, dieselbe Ressource wie der Client zeitgleich überlassen zu bekommen, das heißt eine Überlassung der Ressource zu erhalten, die die Zeitspanne der von dem Client gehaltenen Überlassung überlappt. Nach einer Ausführungsform kann der Client eine Überlassung auf einer Zugangsstufe halten und eine Nachricht zur Erneuerung der Überlassung senden, die die Überlassung auf einer anderen Zugangsstufe anfordert.
  • In Schritt 2006 kann der Dienst im Anschluß an den Empfang einer Nachricht zur Erneuerung der Überlassung von dem Client eine Erneuerung der Überlassung der Ressource dem Client gewähren. Die Nachricht zur Erneuerung der Überlassung kann als Antwort auf eine Nachricht zur Anforderung der Erneuerung einer Überlassung, die von dem Dienst an den Client gesendet wurde, gesendet worden sein oder kann automatisch vom Client vor Ablauf einer zuvor gewährten Überlassungszeitspanne gesendet worden sein. Nach einer Ausführungsform kann die Überlassung für eine eingeräumte Überlassungszeitspanne gewährt werden. Nach einer Ausführungsform kann die Nachricht zur Erneuerung einer Überlassung eine Erneuerungszeitspanne der Überlassung anfordern. Nach einer Ausführungsform kann die gewährte Überlassungszeitspanne kleiner oder gleich der angeforderten Überlassungszeitspanne sein. Nach einer Ausführungsform kann der Dienst die Anforderung der Erneuerung der Überlassung von dem Client ablehnen. Zum Beispiel kann der Client eine maximale, kumulierte Überlassungszeitdauer überschritten haben oder ein anderer Client kann einen exklusiven Überlassungszugang zu der Ressource anfordern. Nach einer Ausführungsform kann der Dienst die Überlassung für weniger als die angeforderte Überlassungszeitspanne gewäh ren. Nach einer Ausführungsform kann der Dienst eine Nachricht an den Client senden, um den Client zu informieren, ob die Überlassung erneuert wurde. Nach einer Ausführungsform kann die Nachricht die gewährte Überlassungszeitspanne enthalten.
  • In Schritt 2008 kann der Client eine Nachricht an den Dienst senden, die die Löschung der Überlassung anfordert. Die Nachricht kann die Ressource angeben, für die der Client eine Überlassung hält, die gelöscht werden soll. In Schritt 2010 kann der Dienst die Überlassung löschen. Der Dienst kann die Überlassung als Reaktion auf den Empfang einer Anforderungsnachricht zur Löschung einer Überlassung löschen, wie in Schritt 2008 beschrieben. Nach einer Ausführungsform Kann der Dienst die Überlassung auch löschen, wenn eine gewährte Überlassungszeitspanne abläuft, ohne eine Nachricht zur Erneuerung der Überlassung vom Client zu empfangen. Der Dienst kann die Überlassung auch aus einer Vielzahl von anderen Gründen löschen. Zum Beispiel kann ein anderer Client exklusiven Zugang zu der Ressource anfordern, oder die Ressource kann nicht mehr verfügbar sein. Nach einer Ausführungsform kann der Dienst eine Nachricht an den Client senden, um ihn zu informieren, daß die Überlassung gelöscht wurde.
  • Nach einer Ausführungsform kann ein Sicherheitsnachweis wie ein unten beschriebener Authentisierungsnachweis in den Überlassungsnachrichten enthalten sein, die zwischen dem Client und dem Dienst, wie in 44 beschrieben, gesendet werden. Zum Beispiel kann der Client den Sicherheitsnachweis in den Nachrichten zur Erneuerung einer Überlassung und zum Anfordern der Löschung einer Überlassung, die an den Dienst gesendet werden, einbetten. Der Dienst kann beim Empfang einer Nachricht den Berechtigungsnachweis untersuchen, um zu überprüfen, daß er von dem Halter der Überlassung stammt, um damit die Authentizität der Nachricht zu überprüfen. Dies sorgt für Sicherheit in dem Überlassungsmechanismus, indem Einheiten, die nicht die richtigen Berechtigungsnachweise besitzen, daran gehindert werden, die aktuelle(n) Überlassungen) des Clients beim Dienst zu ändern.
  • Nach einer Ausführungsform können die Überlassungsnachrichten, die zwischen dem Client und dem Dienst gesendet werden, alle in einer Datenrepräsentationssprache vorliegen. Nach einer Ausführungsform kann die Datenrepräsentationssprache die eXtensible Markup Language (XML) sein. Nach einer Ausführungsform können alle Nachrichten von einem Nachrichtengatter des Dienstes und einem Nachrichtengatter des Client gesendet und empfangen werden. Nach einer Ausführungsform können die Überlassungsnachrichten in einem XML-Nachrichtenschema beschrieben sein, das dem Client zur Verfügung gestellt wird und verwendet wird, um das Nachrichtengatter des Client einzurichten. Nach einer Ausführungsform kann das XML-Nachrichtenschema von dem Client in einer Dienstannonce beschafft werden, z. B. von einem Space-Dienst geholt werden.
  • Der Überlassungsmechanismus kann auch einen Mechanismus vorsehen, um veraltete bzw. abgelaufene Annoncen zu entdecken. Wenn ein Dienst seine Annoncen in einem Space veröffentlicht, erhält dieser Dienst eine Überlassung dieser Veröffentlichung seiner Annoncen. Jede Annonce kann eine Zeit enthalten, zu der der Dienst zusagt, die Annonce zu erneuern. 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ündig te 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), (ü) das Objekt in dem Space lesen (readShared) und (iii) das Objekt in dem Space exklusiv lesen (readExclusive).
  • Authentisierung und Sicherheit
  • Die verteilte Rechnerumgebung sieht spontane und heterogene, verteilte Systeme vor, die auf einem asynchronen Modell zur Nachrichtenübergabe beruhen, wobei Daten und/oder Objekte in einer Datenrepräsentationssprache wie XML dargestellt werden können. In der verteilten Rechnerumgebung können Clients zum Beispiel über das Internet mit Diensten Verbindung aufnehmen. Die verteilte Rechnerumgebung kann eine große Anzahl von Netzwerkeinrichtungen in die Lage versetzen, in einer zuverlässigen, dynamischen und sicheren Weise zusammenzuarbeiten. Die verteilte Rechnerumgebung kann ein Protokoll definieren, das im wesentlichen die Interoperabilität zwischen konformen Softwarekomponenten (Clients und Diensten) ermöglicht.
  • Im Kontext der verteilten Rechnerumgebung kann eine Einrichtung eine im Netzwerk verbundene, auf der Transportschicht adressierbare Einheit sein. Clients und Dienste können als mittels Universellen Ressourcenkennzeichnern (Universal Resource Identifier, URI) adressierbare Instanzen von Software oder Firmware implementiert sein, die auf Einrichtungen ablaufen.
  • Der Internet-Space ist durch viele Inhaltspunkte besiedelt. Ein URI ist ein Verfahren, das verwendet wird, um irgendeinen dieser Inhaltspunkte zu kennzeichnen, sei es eine Textseite, ein Video- oder Sound-Clip, ein Bild, Software, Firmware oder anderer Internet-Inhalt. Die verbreitetste Form eines URI ist die Webseiten-Adresse, die eine bestimmte Form oder Teilmenge eines URI ist, die Uniform Resource Locator (URL) genannt wird. Ein URI beschreibt typischerweise den Mechanismus, der verwendet wird, um auf die Ressource zuzugreifen, den spezifischen Computer, der die Ressource beherbergt und den spezifischen Namen der Ressource (typischerweise ein Dateiname) auf dem Computer.
  • Clients und Dienste (beide können auf Einrichtungen als Software und/oder Firmware implementiert sein) können über das Internet, ein firmeneigenes Intranet, ein dynamisches nachbarschaftsbezogenes Netzwerk innerhalb eines einzelnen Computers oder durch andere Netzwerkverbindungsmodelle verbunden sein. Die Größe und Komplexität der Einrichtungen, die Clients und Dienste unterstützen, kann zum Beispiel von einem einfachen Lichtschalter bis zu einem komplexen, hochverfügbaren Server rangieren. Beispiele für Einrichtungen umfassen, sind jedoch nicht beschränkt auf: PDAs; Mobiltelefone, Notebook, Laptop, und leistungsfähigere PCs; und leistungsfähigere Computersysteme bis hin zu Supercomputern. Nach einigen Ausführungsformen kann von der Entfernung, der Verzögerung und der Implementierung von Clients und Diensten mittels einer allgemeinem Methodologie zur Auffindung und Kommunikation abstrahiert werden, was einen "Blackbox"-Effekt erzeugt. Dieser Definitionsansatz ermöglicht es, daß Belange der Softwareimplementierung von der zugrundeliegenden Plattform abgehandelt werden, was zu einem lose gekoppelten System führt, das auf Internet-Proportionen skaliert werden kann.
  • Die verteilte Rechnerumgebung kann ein Internet-zentriertes Programmiermodell zur Verfügung stellen einschließlich der Repräsentation von WEB- und XML-Inhalten, dynamischer Auffindung von Einrichtungen und sicherer Kommunikation zwischen Eirichtungen, die von einer breiten Spanne von Netzwerkeinrichten zugänglich ist. Die verteilte Rechnerumgebung kann ein Netzwerk-Programmiermodell bereitstellen, das über das CPU-Niveau abstrahiert ist. Das Programmiermodell kann die folgenden Eigenschaften umfassen:
    • – URI-Adressen
    • – Streng typisierte Daten, die als Inhalt bezeichnet werden (adressiert mittels URIs)
    • – Eine im Wesentlichen unbeschränkte Menge von dauerhaftem Inhaltsspeicher (z. B. Speicher), (der XML- und Nicht-XML-Inhalt wie den durch MIME-Typen gekennzeichneten enthält)
    • – Eine im Wesentlichen unbeschränkte Menge von transientem Inhaltsspeicher, der Spaces genannt wird (der XML-Inhalt enthält),
    • – beschreibende Inhaltsannoncen mit XML-Metadaten (Daten über Daten), die in einem Space gespeichert werden können, um interessierte Clients zu benachrichtigen bzw. in Kenntnis zu setzen.
    • – Eine im Wesentlichen unbeschränkte Anzahl von Instruktionen (ausgedrückt als Nachrichten)
    • – Sichere Nachrichten-Endpunkte (Gatter), die durch URIs adressiert werden
    • – Unterstützung für Datenfluß (Ereignisnachrichten), um den Arbeitsablauf bzw. Informationsfluß zwischen verteilten Softwareprogrammen zu koordinieren
  • Dienste und Clients können als Programme innerhalb der verteilten Rechnerumgebung ablaufen. Dienste können Clients, die den Dienst benutzen möchten, ihre Leistungsmerkmale ankündigen bzw. bekanntmachen. Clients können sich innerhalb derselben Netzwerkeinrichtung befinden oder auch nicht, und die Codeausführungsumgebung dieser Einrichtung kann die Java-Plattform unterstützen oder auch nicht. Die Verwendung von URIs zur Adressierung von Inhalt und Nachrichtenendpunkten gibt der verteilten Rechnerumgebung ein leistungsstarkes Adressierungsschema. Die Adresse kann den Ort bzw. die Lage des Inhaltes oder des Endpunktes angeben, und kann den zu verwendenden Weg bzw. die zu verwendende Route (oder das zu verwendende Transportprotokoll) angeben. Einträge, die mittels URIs adressiert werden, können auch einen zugeordneten Sicherheitsnachweis haben. Der Sicherheitsnachweis kann zur Kontrolle bzw. Steuerung verwendet werden, welchen Clients ein Zugriff auf den Eintrag erlaubt wird als auch welche Operationen autorisierte Clients auf diesem Eintrag durchführen dürfen.
  • Der hohe Grad von Zugriff, der durch die verteilte Rechnerumgebung bereitgestellt wird, kann durch geeignete Authentisierung und Sicherheitssysteme und -verfahren kontrolliert werden. Authentisierung und Sicherheit in der verteilten Rechnerumgebung kann umfassen, ist jedoch nicht beschränkt auf: Überprüfen der Richtigkeit der Typen von XML-Inhalt in einer Nachricht; sicheres Identifizieren des Senders gegenüber dem Empfänger; einen Mechanismus zum Prüfen der Integrität von Nachrichten, die von einem Client an einen Dienst gesendet werden und umgekehrt; und einen Mechanismus, um einem Client den Satz von akzeptierten Nachrichten eines Dienstes zu beschreiben und die Anforderungen an Nachrichten bei Nachrichten, die bei dem Dienst empfangen werden, durchzusetzen. Die oben aufgelisteten Sicherheits- und Autorisierungseigenschaften bzw. -funktionen können in einer einzelnen, unteilbaren Einheit von Code und Daten realisiert werden. Die unteilbare Einheit von Code und Daten kann dynamisch erzeugt werden. Nach einer Ausführungsform kann die unteilbare Einheit von Code und Daten, sobald sie kreiert wurde, einen Nachrichtenendpunkt (Gatter) repräsentieren und darf nach den während der Erzeugung implementierten Sicherheits- und Autorisierungsrichtlinien möglicherweise nicht verändert werden.
  • Ein Gatter kann die Befugnis repräsentieren, einige oder alle Leistungsmerkmale eines Dienstes zu verwenden. Jedes Leistungsmerkmal kann als eine Nachricht ausgedrückt werden, die an einen Dienst gesendet werden kann. Gatter können auch zum Erkennen von Fehlerfällen verwendet werden, wenn ein Client Ressourcen überlassen bekommt bzw. pachtet.
  • Authentisierung und Sicherheit kann auch einen Mechanismus umfassen, der überprüft, daß ein Client, der einen Dienst zu benutzen versucht, autorisiert ist, den Dienst zu benutzen; daß der Space, von dem der Client die Dienstannonce empfängt, autorisiert ist, die Dienstannonce bereitzustellen; und/oder daß die Dienstannonce selbst autorisiert ist.
  • Die Übergabe von Nachrichten kann in einer Nachrichtenschicht als die Möglichkeit implementiert sein, Anforderungen von Clients zu Diensten zu kommunizieren, und daß Dienste den Clients mit Ergebnissen antworten können. Die Nachrichtenschicht der verteilten Rechnerumgebung kann im Wesentlichen sicherstellen, daß gültige XML-Nachrichten gesendet werden, und kann Mechanismen bereitstellen, die ein sprachunabhängiges Sicherheitsmodell ermöglichen. In der Nach richtenschicht kann ein sendender Nachrichtenendpunkt mit einem empfangenden Nachrichtenendpunkt verbunden sein bzw. werden. Die zwei zugeordneten Nachrichtenendpunkte können einen sicheren, unteilbaren, bidirektionalen Nachrichtenkanal bereitstellen, der für die Übergabe von Anforderungs-Antwort-Nachrichten zwischen einem Client und einem Dienst geeignet ist.
  • Nach Ausführungsformen einer verteilten Rechnerumgebung kann eine Annonce für einen Dienst in einem Space veröffentlicht werden. Eine Annonce kann ein XML-Dokument sein, das das XML-Schema und den URI des Dienstes enthält. Der Dienst kann auch ein Dienst-ID-Token oder einen Berechtigungsnachweis in der Annonce enthalten und kann einen Authentisierungsdienst in der Annonce angeben, der sowohl von dem Client als auch von dem Dienst zu verwenden ist. Ein Client kann dann die Dienstannonce auf dem Space lokalisieren und die Annonce verwenden, um ein Nachrichtengatter auf dem Client zu instantiieren. Der Client kann den in der Annonce angegebenen Authentisierungsdienst benutzen, um eine Authentisienungsbestä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 Nachrichtengater 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 Authentisierrungsnachweises 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 ent schlüsseln können (mit dem passenden öffentlichen Schlüssel), um die von der Einheit gesendeten Nachrichten zu überprüfen.
  • Nach einer Ausführungsform können Nachrichten in der verteilten Rechnerumgebung verschiedene Stufen von verschlüsselten öffentlichen Schlüsseln zum Autorisieren der Einheiten in dem Client-Dienst-Kommunikationsmodell beinhalten. Nach einer Ausführungsform kann ein Dienst einen Berechtigungsnachweis C1 aufbauen, der seinen öffentlichen Schlüssel X1 beinhaltet. Der Dienst kann dann den Berechtigungsnachweis mittels seines privaten Schlüssels Y1 verschlüsseln. Der Dienst kann den verschlüsselten Berechtigungsnachweis C1 in einem Space als Teil seiner Dienstannonce einbeziehen. Der Space kann daraufhin einen neuen Berechtigungsnachweis C2 aufbauen, der den Berechtigungsnachweis C1 und den öffentlichen Schlüssel X2 des Space enthält. Der Space kann danach den Berechtigungsnachweis C2 mit seinem privaten Schlüssel Y2 verschlüsseln. Wenn ein Client den Dienst von dem Space anfordert, sendet der Space die Dienstannonce und den Berechtigungsnachweis C2 an den Client. Wenn der Client ein Gatter einrichtet, läßt er das Gatter Nachrichten an den Dienst senden, die einen weiteren Berechtigungsnachweis C3 enthalten, der den verschlüsselten Berechtigungsnachweis C2 und den öffentlichen Schlüssel X3 des Client enthält. C3 kann vor dem Senden mittels des privaten Schlüssels Y3 des Client verschlüsselt werden. Der öffentliche Schlüssel X3 des Client und der öffentliche Schlüssel X2 des Space können auch mit den Nachrichten gesendet werden. Nach einer Ausführungsform kann der öffentliche Schlüssel X2 des Space in C3 enthalten und somit in C3 verschlüsselt sein. Nach dieser Ausführungsform kann der öffentliche Schlüssel X3 des Client unverschlüsselt in den Nachrichten gesendet werden. Nach einer anderen Ausführungsform können der öffentliche Schlüssel X3 des Client und der öffentliche Schlüssel X2 des Space unverschlüsselt in den Nachrichten gesendet werden.
  • Nachdem die Gatter erzeugt wurden, kann der Client nach einer Ausführungsform eine Nachricht an den Dienst senden, die den verschlüsselten Berechtigungsnachweis C3 und den öffentlichen Schlüssel X3 enthält. Nach einer Ausführungsform kann der öffentliche Schlüssel X2 des Space in C3 enthalten sein. Nach einer anderen Ausführungsform kann der öffentliche Schlüssel X2 (unverschlüsselt) extern zu C3 in der Nachricht enthalten sein. Wenn der Dienst die Nachricht empfängt, kann er den Berechtigungsnachweis C3 mittels des empfangenen öffentlichen Schlüssels X3 des Client entschlüsseln und den öffentlichen Schlüssel X3, der in dem entschlüsselten Berechtigungsnachweis C3 enthalten ist, gegen den empfangenen öffentlichen Schlüssel X3 überprüfen, der verwendet wurde, um die Nachricht zu entschlüsseln, wodurch überprüft wird, daß die Nachricht von einem autorisierten Client stammt. Der Dienst kann dann den Berechtigungsnachweis C2 (der aus dem entschlüsselten Berechtigungsnachweis C3 extrahiert wurde) mit dem öffentlichen Schlüssel X2 des Space entschlüsseln und den öffentlichen Schlüssel X2, der in dem entschlüsselten Berechtigungsnachweis C2 eingebettet ist, gegen den öffentlichen Schlüssel X2 des Space überprüfen und somit überprüfen, daß der Berechtigungsnachweis C2 des Space von einem autorisierten Space kam. Nach einer Ausführungsform kann der öffentliche Schlüssel X2 des Space in dem Berechtigungsnachweis C3 enthalten gewesen sein. Nach einer anderen Ausführungsform kann der öffentliche Schlüssel X2 des Space in der Nachricht enthalten gewesen sein, außerhalb von C3. Nach noch einer anderen Ausführungsform kann der Dienst den öffentlichen Schlüssel X2 des Space von woanders her erhalten, zum Beispiel von dem Space selbst. Schließlich kann der Dienst den Berechtigungsnachweis C1 (der aus dem entschlüsselten Berechtigungsnachweis C2 extrahiert wurde) mit dem öffentlichen Schlüssel X1 des Dienstes entschlüsseln und den entschlüsselten Berechtigungsnachweis prüfen, um sicherzustellen, daß der Berechtigungsnachweis von dem Dienst erzeugt wurde (der Berechtigungsnachweis sollte den öffentlichen Schlüssel des Dienstes enthalten).
  • Verschiedene Algorithmen zur Erzeugung von Schlüsseln können in der verteilten Rechnerumgebung verwendet werden. Die Zusammensetzung bzw. der Aufbau von Schlüsseln kann sowohl vor Clients als auch vor Diensten verborgen werden; somit brauchen sich der Client und der Dienst nicht darum zu kümmern, welcher Algorithmus zur Erzeugung von Schlüsseln verwendet wird.
  • Ein Kerberos-Ticket ist ein Beispiel eines Sicherheitsnachweises, der in der verteilten Rechnerumgebung verwendet werden kann. Kerberos ist ein sicheres Verfahren zur Authentisierung einer Anforderung eines Dienstes in einem Computernetzwerk. Kerberos läßt einen Benutzer ein verschlüsseltes "Ticket" von einem Authentisierungsprozeß anfordern, das daraufhin verwendet werden kann, um einen bestimmten Dienst anzufordern. Das Paßwort des Benutzers braucht nicht durch das Netzwerk übergeben zu werden.
  • Von der verteilten Rechnerumgebung können Mechanismen zur Verfügung gestellt werden, um im Wesentlichen zu garantieren, daß zwischen Clients und Diensten gesendete Nachrichten nicht gefährdet werden. Nach einer Ausführungsform kann ein Sender ein Token einbetten, das Information enthält, die von den Empfänger zur Überprüfung verwendet werden kann, daß die Nachricht nicht verändert wurde. Es gibt verschiedene Verfahren zum Erzeugen von Information, die in die Nachricht eingebettet werden soll. Nach einer Ausführungsform kann ein Hash der Nachricht berechnet und mit der Nachricht gesendet werden. Das Erzeugen eines Hash kann die Transformation einer Zeichenkette in einen üblicherweise kürzeren Wert oder Schlüssel fester Länge umfassen, der die ursprüngliche Kette repräsentiert. Beim Empfang der Nachricht kann der Empfänger den Hash neu berechnen und ihn gegen den gesendeten Hash prüfen. Wenn die Nachricht geändert wurde, ist es höchst unwahrscheinlich, daß derselbe Hash erzeugt wird. Der Sender kann den Hash verschlüsseln und den entsprechenden öffentlichen Schlüssel in der verschlüsselten Nachricht senden, um im Wesentlichen sicherzustellen, daß der Hash nicht beeinträchtigt wird.
  • Nach anderen Ausführungsformen kann ein Schema zur Fehlerentdeckung wie eine zyklische Redundanzprüfung verwendet werden. Eine zyklische Redundanzprüfung ist ein Verfahren zum Prüfen auf Fehler in Daten, die auf einer Kommunikationsverbindung übertragen werden. Nach einer Ausführungsform, die zyklische Redundanzprüfung benutzt, wendet der Sender ein n-Bit Polynom auf die Nachricht an und hängt den sich ergebenden zyklischen Redundanzcode (Cyclic Redundancy Code, CRC) an die Nachricht an. Der Empfänger wendet dasselbe Polynom (das auch in der Nachricht übergeben werden kann) auf die Nachricht an und vergleicht sein Ergebnis mit dem vom Sender angehängten Ergebnis. Wenn sie übereinstimmen, wurde die Nachricht erfolgreich empfangen. Falls nicht, kann der Sender benachrichtigt werden, um die Nachricht erneut zu senden.
  • Gatterfabriken können auch eine Rolle bei der Sicherheit spielen, da eine Gatterfabrik "vertrauenswürdiger" Code sein kann. Das Verwenden einer vertrauenswürdigen Gatterfabrik zum Erzeugen von Gattern kann helfen sicherzustellen, daß Gatter vertrauenswürdigen Code darstellen und daß der Code bezogen auf die Dienstannonce korrekt ist. Von Clients kann die Übergabe eines Client-ID-Token oder -Berechtigungsnachweises an die Gatterfabrik als ein Mittel zur Authentisierung verlangt werden. Dienste können einen) Dienst-ID-Token oder -Berechtigungsnachweis an Clients übergeben (z. B. durch eine Annonce), wenn ein Client ein Gatter erzeugen möchte. Wie hier diskutiert, kann ein Client- und Dienst-Token-Paar zum Erzeugen eines dritten Berechtigungsnachweises benutzt werden, der verwendet werden kann, um dem Client das Senden von Nachrichten an den Dienst zu ermöglichen. Dieser dritte Berechtigungsnachweises kann als Authentisierungsnachweis bezeichnet werden. Ein Authentisierungsnachweis kann von einem Authentisierungsdienst während des Authentisierungsvorgangs erzeugt werden. Nach einer Ausführungsform kann der Dienst jegliche Authentisierungsrichtlinie zu seiner Verfügung verwenden. Nach einer Ausführungsform kann der Authentisierungsdienst die Authentisierungsrichtlinie im Namen des Dienstes administrieren, und somit muß der Dienst die genaue Authentisierungsrichtlinie nicht kennen, die verwendet wird.
  • Der Client kann sein Gatter mittels eines Authentisierungsnachweises einrichten, das der Client durch das Ablaufen-Lassen eines in der Dienstannonce angegebenen Authentisierungsdienstes empfängt. Das kann dem eingerichteten Gatter das Senden des Authentisierungsnachweises mit jeder Nachricht an den Dienst ermöglichen. Wenn der Dienst den ersten Authentisierungsnachweis in einer ersten Nachricht von dem Client empfängt. kann der Dienst den in der Dienstannonce angegebenen Authentisierungsdienst zur Authentisierung des Client verwenden und dadurch eine Bindung des Authentisierungsnachweises an die Identität des Client einrichten.
  • Wie zuvor diskutiert, können einige von einem Dienst erzeugte Ergebnisse in einem Space angekündigt werden, und auf sie kann letztlich mittels eines Ergebnisgatters zugegriffen werden. Das Ergebnisgatter kann denselben Sicherheitsnachweis wie das Eingabegatter, das zum Erzeugen der Ergebnisse verwendet wurde, enthalten oder auch nicht. Da die Eingabe an einen Dienst asynchron von seiner Ausgabe (den Ergebnissen) sein kann, kann den Ergebnissen ein unterschiedlicher Satz von Zugriffsrechten zugeordnet sein. Zum Beispiel kann ein Dienst zur Gehaltsabrechnung die Initiierung der Gehaltsabrechnung einer anderen Menge von Clients erlauben als das Lesen der Ergebnisse des Gehaltsabrechnungsdienstes (Gehaltsschecks). Daher muß ein Client möglicherweise durch einen separaten Authentisierungsvorgang gehen, um Zugriffsrechte auf die Ergebnisse zu erhalten, was den Empfang eines Authentisierungsnachweises für die Ergebnisse von einem in der Annonce für die Ergebnisse angegebenen Authentisierungsdienst umfassen kann.
  • Nachrichtengatter können den Diensten die meisten Sicherheitsüberprüfungen abnehmen. Dienste können sich auf das Bereitstellen von Leistungsmerkmalen und das Authentisieren von Clients konzentrieren. Ein Prinzip des geringsten Privilegs kann dadurch unterstützt werden, daß Clients nur zu denjenigen Leistungsmerkmalen Zugang erhalten, die angefordert (oder zugewiesen) wurden.
  • Sicherheitsüberprüfungen können auftreten, wenn ein Gatter erzeugt und/oder wenn ein Gatter verwendet wird (wenn Nachrichten gesendet und/oder empfangen werden). Wenn ein Client Zugriff auf einen angekündigten Eintrag (Dienst) anfordert, kann der Vorgang der Gattererzeugung beginnen. Während dieses Vorgangs kann die Client-Gatterfabrik mit dem Dienst arbeiten, um sich gegenseitig zu authentisieren. Die zum Zeitpunkt der Gattererzeugung durchgeführten Prüfungen können extensiv sein und können die Anzahl der während der Nutzung des Gatters durchgeführten Prüfungen minimieren. Nachdem der Dienst den Client authentisiert hat, kann der Dienst spezifische Fähigkeiten bzw. Möglichkeiten für den Client festlegen (z. B. was der Client auf dem Dienst tun darf), und kann die Leistungsmerkmale dem Authentisierungsnachweis des Client zuordnen. Diese spezifischen Leistungsmerkmale können angeben, welche Operationen der Client auf dem Dienst durchführen darf. Da die Gatter sicherstellen können, daß jeder Nachricht den Authentisierungsnachweis enthält, kann der Dienst dann jede Anforderung, wenn sie empfangen wird, gegen die Leistungsmerkmale des authentisierten Client prüfen.
  • Die Prüfungen bei der 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 Identifikationsverfahren zum Authentisieren des Client verwendet werden. Zum Beispiel kann der Benutzer eine physikalische Identifikation wie eine Smart-Card zur Identifikation und Autorisierung liefern. Andere Mechanismen zur Authentisierung können in anderen Ausführungsformen verwendet werden.
  • Nach einer Ausführungsform, welches Mittel auch immer zum Authentisieren des Client verwendet wird, kann die Authentisierung sowohl für den Client als auch für den Dienst unsichtbar sein, die Gatterfabrik kann wissen, welcher Authentisierungsdienst zu verwenden ist und der Authentisierungsdienst behandelt den Authentisierungsmechanismus und die Authentisierungsrichtlinien. Gatterfabriken können produkt- und umgebungsabhängig sein oder können sogar durch ein Konfigurationsmanagementsystem gesteuert werden. Nach einer Ausführungsform kann der Grad und das Verfahren der Isolation von Clients plattformabhängig, jedoch der Gatterfabrik bekannt sein. Nach einigen Ausführungsformen kann ein Hardware-basiertes physikalisches Identifikationsverfahren zum Authentisieren des Client verwendet werden. Zum Beispiel kann der Benutzer eine physikalische Identifikation wie eine Smart-Card zur Identifikation und Autorisierung liefern. Andere Mechanismen zur Authentisierung können in anderen Ausführungsformen verwendet werden.
  • Nachrichtengatter in der verteilten Rechnerumgebung sind typischerweise einem einzelnen Client zugeordnet. Die Gatterfabrik kann das Mittel der Zuordnung festlegen. Die zum Zeitpunkt des Sendens einer Nachricht durchgeführten Prüfungen können sicherstellen, daß der richtige Client das Gatter verwendet. 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.
  • 26a – Ein Authentisierungsdienst, der einen Authentisierungsnachweis für einen Client bereitstellt
  • 26a ist ein Flußdiagramm, das einen Authentisierungsdienst darstellt, der einen Authentisierungsnachweis für einen Client gemäß einer Ausführungsform bereitstellt. Ein Client in der verteilten Rechnerumgebung kann wünschen, daß ein Dienst eine oder mehrere Funktionen im Namen des Client durchführt. Nach einer Ausführungsform kann ein Authentisierungsdienst zum Gebrauch durch den Client und den Dienst zur Verfügung stehen, wenn ein sicherer Nachrichtenkanal aufgebaut wird. Ein Authentisierungsdienst kann für den Client und/oder den Dienst Funktionen ausführen einschließlich der Authentisierung des Client und/oder des Dienstes und des Verhandelns der gewünschten Sicherheitsstufe und der Menge von Nachrichten, die zwischen dem Client und dem Dienst übergeben werden können. Der Authentisierungsdienst kann ein Prozeß sein, der innerhalb der verteilten Rechnerumgebung ausgeführt wird. Der Authentisierungsdienst kann auf derselben Einrichtung wie der Dienst und/oder der Client ausgeführt werden, oder der Authentisierungsdienst kann alternativ auf einer separaten Einrichtung wie einem Authentisierungsserver ausgeführt werden. Nach einer Ausführungsform kann der Authentisierungsdienst ein Internet-basierter Dienst sein. Der Authentisierungsdienst kann seine eigene Adresse haben, zum Beispiel einen Universal Resource Identifier (URI), über die der Client und/oder Dienst mit dem Authentisierungsdienst kommunizieren kann. Nach einer Ausführungsform kann die Adresse des Authentisierungsdienstes dem Client in der Dienstannonce für den Dienst zur Verfügung gestellt werden. Die gemeinsame Nutzung des Authentisierungsdienstes durch den Client und den Dienst hilft sicherzustellen, daß ein sicherer Nachrichtenkanal zwischen dem Client und dem Dienst aufgebaut wird, da jedes von mehreren Sicherheits- und Authentisierungsprotokollen in dem Nachrichtenkanal verwendet werden kann.
  • Nach einer Ausführungsform kann ein Client ein Token oder einen Berechtigungsnachweis zur Identifizierung des Client dem Authentisierungsdienst übergeben. Das Client-Token oder der Berechtigungsnachweis des Client kann ausreichend fälschungssicher sein, um als Beweis für die Identität des Client verwendet zu werden. Der Authentisierungsdienst kann daraufhin das Token oder den Berechtigungsnachweis zur Identifizierung des Client überprüfen und an den Client einen Authentisierungsnachweis ausgeben, den nur der Authentisierungsdienst erstellen kann. Der Authentisierungsnachweis, der an den Client zurückgegeben wird, wird dann in jeder Nachricht von dem Client an den Dienst gesendet. Nach einer Ausführungsform wird das Nachrichtengatter des Client von einer 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.
  • 26b – Ein Authentisierungsdienst, der einen Authentisierungsnachweis erzeugt
  • 26b ist ein Flußdiagramm, das Schritt 1002 von 26a erweitert und einen Authentisierungsdienst darstellt, der einen Authentisierungsnachweis gemäß einer Ausführungsform erzeugt. In Schritt 1002a kann der Authentisierungsdienst nach einer Ausführungsform ein Client- Token und ein Dienst-Token erhalten. Nach einer anderen Ausführungsform kann der Authentisierungsdienst nur ein Client-Token erhalten. Nach einer Ausführungsform kann das Client-Token ein eindeutiger Bezeichner für den Client in der verteilten Rechnerumgebung sein. Nach einer Ausführungsform kann das Dienst-Token ein eindeutiger Bezeichner für den Dienst in der verteilten Rechnerumgebung sein. Zum Beispiel können die öffentlichen Schlüssel von einem Verschlüsselungsmechanismus mit öffentlichen/privaten Schlüsseln als eindeutige Bezeichner für den Client und den Dienst verwendet werden. Nach einer Ausführungsform kann der Client das Dienst-Token in der Dienstannonce empfangen, und der Client kann das Client-Token und das Dienst-Token an den Authentisierungsdienst übergeben. Nach einer anderen Ausführungsform kann der Client das Dienst-Token und den URI der Dienstannonce an den Authentisierungsdienst übergeben, und der Authentisierungsdienst kann das Dienst-Token aus der Dienstannonce abholen.
  • In Schritt 1002b kann der Authentisierungsdienst den Client und/oder den Dienst überprüfen. Nach einer Ausführungsform kann der Authentisierungsdienst die in Schritt 1002a erhaltenen Client- und Dienst-Token zum Überprüfen des Client und/oder des Dienstes verwenden. Nach einer anderen Ausführungsform wurde in Schritt 1002a nur ein Client-Token erhalten, und somit wird in Schritt 1002b nur das Client-Token zum Überprüfen des Client verwendet. Nach einer Ausführungsform kann der Client sein Client-Token zuvor bei dem Authentisierungsdienst registriert haben, und der Authentisierungsdienst kann das empfangene Client-Token mit dem registrierten Client-Token vergleichen, um den Client als einen gültigen Client zu überprüfen. Nach einer Ausführungsform kann der Client auf den Authentisierungsdienst mittels eines Challenge/Response-Mechanismus wie z. B. eine Anmeldekennung mit Paßwort zugreifen und somit als ein gültiger Client überprüft werden. Nach einer Ausführungsform kann der Dienst sich zuvor bei dem Authentisierungsdienst registriert haben und kann sein Dienst-Token an den Authentisierungsdienst übergeben haben. Der Authentisierungsdienst kann dann überprüfen, ob der Client auf einen gültigen Dienst zuzugreifen versucht, indem er das empfangene Dienst-Token mit dem zuvor registrierten Dienst-Token vergleicht. Andere Arten von Client- und Dienst-Authentisierung können ebenso verwendet werden. Zum Beispiel kann der Client eine digitale Unterschrift oder einen digitalen Berechtigungsnachweis bereitstellen, die bzw. den der Authentisierungsdienst zur Authentisierung des Client und/oder zur Authentisierung des Dienstes, auf den der Client zuzugreifen versucht, verwenden kann.
  • In Schritt 1002c kann der Authentisierungsdienst einen Authentisierungsnachweis erzeugen. Nach einer Ausführungsform kann der Authentisierungsnachweis ein Authentisierungstoken enthalten, das nur der Authentisierungsdienst erzeugen kann. Nach einer Ausführungsform kann der Authentisierungsdienst das Client-Token und das Dienst-Token beim Erzeugen des Authentisierungsnachweises verwenden. Nach einer anderen Ausführungsform kann der Authentisierungsdienst nur das Client-Token zum Erzeugen des Authentisierungsnachweises verwenden. Nach noch einer anderen Ausführungsform verwendet der Authentisierungsdienst möglicherweise kein erhaltenes Token zum Erzeugen des Authentisierungsnachweises, sondern kann stattdessen einen Algorithmus zum Erzeugen eines Authentisierungsnachweises verwenden, um einen im Wesentlichen nicht fälschbaren Authentisierungsnachweis zu erzeugen. Nach einer Ausführungsform kann der Authen tisierungsdienst das Dienst-Token und das Client-Token zum Erzeugen eines eindeutigen bzw. einzigartigen Authentisierungsnachweises kombinieren. Zum Beispiel können das Dienst-Token und das Client-Token 64-Bit-Werte sein, und die zwei Token können zum Erzeugen eines 128-Bit-Authentisierungsnachweises kombiniert werden. Andere Ausführungsformen können andere Verfahren zum Erzeugen eines Authentisierungsnachweises verwenden.
  • 41 – Erzeugen eines Gatters
  • 41 ist ein Flußdiagramm, welches gemäß einer Ausführungsform das Erzeugen eines Gatters für einen Client darstellt. Nach einer Ausführungsform kann eine Gatterfabrik vertrauenswürdiger Code auf dem Client zum Herstellen von Gattern basierend auf XML-Dienstbeschreibungen sein. Nach einer anderen Ausführungsform kann sich die Gatterfabrik auf einer separaten Einrichtung befinden und kann von dem Client zum Erzeugen von Gattern verwendet werden. Zum Beispiel kann ein Gatterfabrik-Dienst von dem Client zum Erzeugen von Gattern zugreifbar sein. Die Verwendung der Gatterfabrik kann sicherstellen, daß die erzeugten Gatter vertrauenswürdiger Code sind und daß der Code bezüglich der Dienstannonce korrekt ist.
  • Sicherheitsüberprüfungen, die zum Zeitpunkt der Erzeugung eines Gatters durchgeführt werden, können ausführlich bzw. umfangreich sein und damit die Anzahl von Sicherheitsüberprüfungen minimieren, die während der Verwendung eines Gatters durchgeführt werden müssen. Sicherheitsüberprüfungen während der Erzeugung eines Gatters können dazu beitragen, sicherzustellen, daß der Client die Berechtigung zum Benutzen der Menge von Dienstleistungsmerkmalen hat, die in dem aus der Dienstannonce geholten Nachrichtenschema angegeben ist. Nach einer Ausführungsform können die Sicherheitsüberprüfungen mittels Zugriffskontrollisten (Access Control Lists, ACLs) in Verbindung mit einem Authentisierungsdienst implementiert werden. Nach einer Ausführungsform kann eine Challenge-Response-Sequenz (wie eine Anmelde- und Paßwortkennung) zum Authentisieren eines Client verwendet werden. Nach einer Ausführungsform kann das Authentisieren eines Client und die Sicherheitsüberprüfungen beim Erzeugung eines Gatters vor dem Client und dem Dienst verborgen bleiben, womöglich nur die Gatterfabrik kann den zu verwendenden Authentisierungsdienst kennen, und der Authentisierungsdienst kann den Authentisierungsmechanismus und die Authentisierungsrichtlinien kennen.
  • In Schritt 1010 kann die Gatterfabrik einen Authentisierungsnachweis für den Client zur Verwendung bei der Kommunikation mit einem Dienst erhalten. Nach einer Ausführungsform kann der Client zuvor den Authentisierungsnachweis von einem Authentisierungsdienst erhalten haben und kann dann den Authentisierungsnachweis der Gatterfabrik übergeben. Nach einer anderen Ausführungsform kann die Gatterfabrik den Authentisierungsnachweis von dem Authentisierungsdienst erhalten.
  • Nach einer Ausführungsform kann die Gatterfabrik auch ein Nachrichtenschema für den Dienst erhalten. Nach einer Ausführungsform kann die Gatterfabrik das Nachrichtenschema von dem Client erhalten. Nach einer anderen Ausführungsform kann die Gatterfabrik das Nachrichtenschema aus einer Dienstannonce empfangen. Zum Beispiel kann der Client einen URI für die Dienstannonce an die Gatterfabrik liefern, und die Gatterfabrik kann mit der Dienstannonce mittels des URI Verbindung aufnehmen, um das Nachrichtenschema zu erhalten. Das Nachrichtenschema kann die Menge von Nachrichten beschreiben, die an den Dienst gesendet werden oder von dem Dienst empfangen werden können. Zum Beispiel können Nachrichten beschrieben werden, die von einem Client an einen Dienst gesendet werden können, um den Dienst aufzurufen oder Aspekte des Dienstes aufzurufen. Ebenso können Nachrichten beschrieben werden, die von dem Dienst an den Client gesendet werden können, wie Antwortnachrichten und Nachrichten für Ereignismeldungen. Nach einer Ausführungsform können die Nachrichten XML-Nachrichten sein, und das Nachrichtenschema kann ein XML-Nachrichtenschema sein.
  • In Schritt 1012 kann die Gatterfabrik ein Nachrichtengatter des Client erzeugen. Nach einer Ausführungsform kann die Gatterfabrik den Authentisierungsnachweis als Daten in das erzeugte Nachrichtengatter einbetten, so daß der Code des Nachrichtengatters auf den Authentisierungsnachweis zugreifen kann. Nach einer anderen Ausführungsform kann der Authentisierungsnachweis außerhalb des Nachrichtengatters auf dem Client gespeichert sein. Nach einer Ausführungsform kann ein URI für den Dienst von der Gatterfabrik in das Gatter eingebettet oder dem Gatter zur Verfügung gestellt werden.
  • In Schritt 1012 kann die Gatterfabrik auch das Nachrichtenschema beim Erzeugen des Nachrichtengatters des Client verwenden. Das Nachrichtenschema kann zur Definition der Menge von Nachrichten verwendet werden, die der Client über das Nachrichtengatter an den Dienst senden kann. Die Gatterfabrik kann das Nachrichtenschema in das Gatter kompilieren. Das Nachrichtenschema kann von der Gatterfabrik in einer internen Form, die für einen schnellen Zugriff während des Überprüfungsvorgangs einer Nachricht geeignet ist, in das Gatter kompiliert sein. Der Zugriff auf einen Dienst kann für einen bestimmten Client mittels des Schemas eingeschränkt werden, wodurch dem Client weniger als der volle Zugriff auf den Dienst gegeben wird. Wenn der Client nach einer Ausführungsform die Dienstannonce zum Beispiel von einem Space erhält, kann basierend auf den Leistungsmerkmalen und/oder Zugriffsrechten des Client ein eingeschränktes Nachrichtenschema für den Dienst dem Client zur Verfügung gestellt werden. Daher kann die Gatterfabrik ein eingeschränktes Nachrichtenschema in das Nachrichtengatter des Client kompilieren, wodurch der Zugriff des Client auf den Dienst eingeschränkt wird. Nach einer Ausführungsform kann der Authentisierungsdienst eine Teilmenge der Gesamtmenge von Nachrichten festlegen, die der Client an den Dienst senden kann. Eine oder mehrere Zugriffsstufen können für einen Dienst in der verteilten Rechnerumgebung vorgesehen sein. Eine Zugriffsstufe kann einen Client des Dienstes mit dem Zugriff auf alle angeforderten Nachrichten in dem Nachrichtenschema für den Dienst und somit im Wesentlichen auf alle Funktionen versehen, die von dem Dienst für Clients in der verteilten Rechnerumgebung bereitgestellt werden. Andere Stufen können einen Client des Dienstes mit Zugriff auf verschiedene Teilmengen der angeforderten Nachrichten in dem Nachrichtenschema und somit zu verschiedenen Teilmengen der Funktionalität des Dienstes versehen. Nach einer Ausführungsform können Zugriffsstufen auch durch die Leistungsmerkmale eines Client festgelegt sein. Zum Beispiel ist ein Thin-Client möglicherweise nicht in der Lage, große Datendateien herunterzuladen und somit von der Verwendung einer Nachricht, die das Herunterladen einer großen Datendatei anfordert, ausgeschlossen.
  • Nach einer Ausführungsform kann der Client Information über den Client dem Authentisierungsdienst zur Verfügung stellen, um eine Zugriffsstufe für den Client festzulegen. Nach einer Ausführungsform kann die Information eine Anforderung für eine spezifische Zugriffsstufe auf den Dienst enthalten. Nach einer Ausführungsform kann die Gatterfabrik die Information dem Authentisierungsdienst zur Verfügung stellen, um die Zugriffsstufe des Client festzulegen. Somit kann die Gatterfabrik ein Nachrichtengatter des Client erzeugen, das in der Lage ist, eine Teilmenge der gesamten Menge der in dem Nachrichtenschema beschriebenen Nachrichten an den Dienst zu senden basierend auf den Leistungsmerkmalen und/oder der Zugriffsstufe des Client.
  • In Schritt 1014 hat die Gatterfabrik das Nachrichtengatter des Client erzeugt und kann den Client benachrichtigen, daß das Gatter erzeugt wurde. Nach einer Ausführungsform ist das Nachrichtengatter des Client ein ausgeprägtes Codemodul, auf das von dem Client zugegriffen werden kann. Nach einer Ausführungsform kann sich das Nachrichtengatter des Client auf dem Client befinden. Der Client kann daraufhin Nachrichten erzeugen und die Nachrichten an das Nachrichtengatter des Client übergeben, das die Nachrichten überprüfen und an den Dienst senden kann. Ausführungsformen eines Gattenpaar-Mechanismus' für den Client und den Dienst zum Austausch von Nachrichten sind in den 42a–42c weiter beschrieben. Ausführungsformen von Gatterfabriken werden an anderer Stelle weiter beschrieben.
  • Ein Gatter weist Code und Daten auf und kann somit selbst in einer Nachricht übergeben werden. Dies stellt eine alternatives Verfahren zum Herstellen von Gattern auf Clients und/oder Diensten zur Verfügung. Nach einer Ausführungsform kann ein in einer Nachricht übergebenes Gatter geklont werden, wenn ein neuer Client das Gatter verwenden möchte. Der Klonierungsvorgang kann einen neuen Satz von Sicherheitsüberprüfungen beim Erzeugen von Gattern einschließlich der Authentisierung des neuen Client durchführen. Ein neuer, eindeutiger Authentisierungsnachweis kann für den neuen Client erzeugt und in das geklonte Gatter eingebettet werden.
  • 42a – Ein Client, der eine Nachricht an einen Dienst sendet
  • 42a ist ein Flußdiagramm, das einen Client darstellt, der gemäß einer Ausführungsform eine erste Nachricht an einen Dienst sendet. In Schritt 1020 kann der Client eine Nachricht an das Nachrichtengatter des Client senden. Nach einer Ausführungsform kann die Nachricht eine XML-Nachricht sein. In Schritt 1022 kann das Nachrichtengatter vor dem Senden der Nachricht einen Authentisierungsnachweis in die Nachricht einbetten. Nach einer Ausführungsform kann der Authentisierungsnachweis von einem Authentisierungsdienst als Teil der Gattererstellung wie oben beschrieben zur Verfügung gestellt worden sein.
  • Nach einer Ausführungsform kann das Nachrichtengatter die Richtigkeit der Typen der Datenrepräsentationssprache, der Syntax etc. in der Nachricht überprüfen. Nach einer Ausführungsform kann das Nachrichtengatter die Nachricht mit einer Nachrichtenvorlage in einem Nachrichtenschema in einer Datenrepräsentationssprache vergleichen, um die Richtigkeit der Typen der Daten repräsentationssprache in der Nachricht zu ermitteln. Nach einer Ausführungsform kann die Nachricht eine XML-Nachricht sein, und das Nachrichtengatter kann die Nachricht gegen ein XML-Nachrichtenschema prüfen. Nach einer Ausführungsform kann das Nachrichtenschema von einem Authentisierungsdienst als Teil der Gattenerstellung wie oben beschrieben zur Verfügung gestellt worden sein. Nach einer Ausführungsform kann das Nachrichtengatter eine Nachrichtenvorlage für die Nachricht in dem Schema lokalisieren und die verschiedenen Einträge oder Felder in der Nachricht mit der Nachrichtenvorlage vergleichen, um die Richtigkeit der Typen der Einträge zu ermitteln.
  • Nach einer Ausführungsform kann die erste Nachricht eine Anforderungsnachricht sein, die von dem Client empfangen wurde, um an den Dienst gesendet zu werden, und das Nachrichtengatter kann herausfinden, ob die Nachricht und/oder die angeforderte(n) Dienstfunktion(en), die von der Nachricht angegeben werden, in der erlaubten Teilmenge der Nachrichten und/oder Dienstfunktionen liegt bzw. liegen, die der Client an den Dienst senden darf. Nach einer Ausführungsform kann das Nachrichtengatter die Nachricht mit der Teilmenge der erlaubten Nachrichten in dem Nachrichtenschema vergleichen, um herauszufinden, ob die Nachricht erlaubt ist. Nach einer Ausführungsform kann eine Zugriffsstufe zu dem Dienst, die dem Client von einem Authentisierungsdienst zur Verfügung gestellt wird, verwendet werden, um die Teilmenge der erlaubten Nachrichten zu ermitteln, die der Client an den Dienst senden darf. Nach einer Ausführungsform kann die erste Nachricht den Dienst auffordern, einen Kommunikationskanal mit dem Client aufzubauen. Nach einer Ausführungsform kann der Kommunikationskanal ein Gatterpaar aufweisen. Das Gatterpaar kann ein Nachrichtengatter des Client und ein Nachrichtengatter des Dienstes aufweisen. Nach einer Ausführungsform ist das Nachrichtengatter des Dienstes möglicherweise auf dem Dienst nicht vorhanden, wenn die erste Nachricht an den Dienst gesendet wird.
  • In Schritt 1024 kann das Nachrichtengatter des Client diese erste Nachricht über den Kommunikationskanal, der den Client mit dem Dienst verbindet, an den Dienst senden. Nach einer Ausführungsform kann das Nachrichtengatter des Client die Nachricht an einen Dienst-URI senden. Nach einer Ausführungsform kann der Dienst-URI dem Client in der Dienstannonce bereitgestellt worden sein. Nach einer Ausführungsform kann das Nachrichtengatter des Client für eine spezifische Dienst-URI erstellt worden sein, so daß alle Nachrichten an den spezifischen Dienst-URI gesendet werden, wodurch ein Nachrichtenkanal von dem Client zu dem Dienst erzeugt wird. Nach einer Ausführungsform kann die Anforderungsnachricht eine Adresse für das Nachrichtengatter des Client beinhalten, so daß der Dienst über das Nachrichtengatter des Client eine Kommunikationsverbindung zu dem Client aufbauen kann. Beispiele von Adressen, die für Nachrichtengatter verwendet werden können, umfassen, sind jedoch nicht eingeschränkt auf: Universal Unique Identifiers (UUIDs) oder URIs. Der Vorgang eines Dienstes, der eine erste Nachricht von einem Client empfängt, ist in 42b dargestellt und beschrieben.
  • 42b – Eine Dienst, der eine Nachricht von einem Client empfängt
  • 42b ist ein Flußdiagramm, das einen Dienst darstellt, der eine Nachricht von einem Client empfängt und einen Authentisierungsdienst zum Authentisieren der Nachricht gemäß einer Ausführungsform verwendet. In Schritt 1030 kann der Dienst eine erste Nachricht von dem Client empfangen. Nach einer Ausführungsform ist das Nachrichtengatter des Dienstes möglicherweise nicht auf dem Dienst vorhanden, wenn die erste Nachricht von dem Dienst empfangen wird. Nach einer Ausführungsform kann das Nachrichtengatter des Client eine erste Nachricht an den URI bei dem Dienst senden, und der Dienst kann die erste Nachricht von dem Client empfangen und daraufhin ein Nachrichtengatter des Dienstes erzeugen. Nach einer Ausführungsform kann ein Mechanismus auf dem Dienst eingerichtet werden, um allgemein Nachrichten einschließlich Nachrichten von Clients an einem URI zu empfangen, der dem Client in der Dienstannonce zur Verfügung gestellt wurde. Beim Empfang einer ersten Nachricht von einem Client kann der Dienst ein Dienstgatter errichten, um dadurch einen Nachrichtenkanal mit dem Client durch das Gatterpaar aufzubauen, das aus dem Nachrichtengatter des Dienstes und dem Nachrichtengatter des Client besteht. Nach einer Ausführungsform kann eine Adresse (zum Beispiel ein UUID oder ein URI) für das Nachrichtengatter des Client dem Dienst in der ersten Nachricht von dem Client übergeben werden und kann zum Erstellen des Nachrichtengatters des Dienstes verwendet werden. Nach einer Ausführungsform kann das Nachrichtengatter des Dienstes nur mit dem Nachrichtengatter des Client und somit mit dem dem Nachrichtengatter zugeordneten Client kommunizieren. Somit kann es nach einigen Ausführungsformen mindestens ein eindeutiges Nachrichtengatters des Dienstes für jeden Client geben, der aktuell in Kommunikation mit dem Dienst steht.
  • Wie oben beschrieben, kann das Nachrichtengatter des Client einen Authentisierungsnachweis in der ersten Nachricht eingebettet haben, die an den Dienst gesendet wird. In Schritt 1032 kann der Dienst den Authentisierungsnachweis an einen Authentisierungsdienst senden. Nach einer Ausführungsform kann der Authentisierungsdienst derselbe Authentisierungsdienst sein, der von dem Client zum Erzeugen des Authentisierungsnachweises verwendet wurde. Nach einer Ausführungsform kann das Nachrichtengatter des Dienstes den Authentisierungsnachweis an den Authentisierungsdienst senden. Nach einer Ausführungsform kann die gesamte Nachricht an den Authentisierungsdienst gesendet werden.
  • In Schritt 1034 kann der Authentisierungsdienst eine Überprüfung des Authentisierungsnachweises durchführen. Nach einer Ausführungsform kann der Authentisierungsdienst eine Kopie des Authentisierungsnachweises aus der Erzeugung des Authentisierungsnachweises enthalten. Nach einer Ausführungsform kann der Authentisierungsdienst den von dem Dienst empfangenen Authentisierungsnachweis mit der Kopie des Authentisierungsnachweises vergleichen. Wenn die Authentisierungsnachweise übereinstimmen, kann der Authentisierungsdienst in Schritt 1036 den Dienst benachrichtigen, daß der Authentisierungsnachweis überprüft wurde und gültig zu sein scheint. Wenn der Überprüfungsvorgang fehlschlägt, kann der Authentisierungsdienst den Dienst benachrichtigen, daß der Authentisierungsnachweis ungültig zu sein scheint.
  • Nach einer Ausführungsform kann der Authentisierungsdienst eine Zugriffsstufe für den Client einrichten, um auf die Funktionalität des Dienstes zuzugreifen. Nach einer Ausführungsform kann der Client eine Zugriffsstufe für den Dienst bei dem Authentisierungsdienst eingerichtet haben. Nach einer Ausführungsform kann der Authentisierungsdienst den Dienst über die Zugriffsstufe des Client benachrichtigen. Die Zugriffsstufe des Client kann von dem Dienst verwendet werden, um eine Teilmenge von Anforderungsnachrichten, wie in dem Nachrichtenschema des Dienstes beschrieben, festzulegen, die der Client an den Dienst senden kann.
  • In Schritt 1038 kann der Dienst ein Nachrichtengatter des Dienstes erzeugen, wenn der Authentisierungsdienst den Dienst benachrichtigt hat, daß der Authentisierungsnachweis in Schritt 1036 gültig ist, um mit dem Clientgatter ein Gatterpaar zu bilden. Das Nachrichtengatter des Dienstes kann den Authentisierungsnachweis beinhalten, um ihn in Nachrichten einzubetten, die von dem Dienst an den Client gesendet werden, und zum Vergleich mit dem Authentisierungsnachweis in Nachrichten, die von dem Client empfangen werden. Das Nachrichtengatter des Dienstes kann auch eine Adresse (wie einen UUID oder einen URI) für das Nachrichtengatter des Client beinhalten. Das Nachrichtengatter des Dienstes kann auch Information über die Zugriffsstufe für den Client enthalten, um zu überprüfen, daß von dem Client empfangene Nachrichten in der Teilmenge von erlaubten Nachrichten liegen, die der Client an den Dienst senden darf. Das Nachrichtengatter des Dienstes kann auch ein Nachrichtenschema zur Typprüfung und Überprüfung der Syntax von vom Client empfangenen Nachrichten und zur Verwendung bei der Überprüfung enthalten, ob Nachrichten in der erlaubten Teilmenge von Nachrichten liegen. Nach einer Ausführungsform kann der Dienst ein neues Nachrichtengatter des Dienstes erzeugen. Nach einer anderen Ausführungsform kann ein Nachrichtengatter des Dienstes bereits vor dem Schritt 1038 vorhanden sein, das zur Erzeugung des Nachrichtengatters des Dienstes zur Kommunikation mit dem Client verwendet werden kann. Nach dieser Ausführungsform erzeugt der Dienst möglicherweise kein neues Gatter, sondern kann stattdessen das vorhandene Gatter mit Information über den Nachrichtenkanal aktualisieren, der zwischen dem Client und dem Dienst aufzubauen ist.
  • Nach einer Ausführungsform kann der Dienst eine Nachricht an den Client senden, nachdem der Dienst das Nachrichtengatter des Dienstes erzeugt hat. Die Nachricht kann Information enthalten, um das Nachrichtengatter des Dienstes gegenüber dem Nachrichtengatter des Client zu identifizieren und somit den Kommunikationskanal zwischen dem Client und dem Dienst mittels des Nachrichtengatterpaares aufzubauen. Nach einer Ausführungsform kann die Nachricht eine Adresse (wie einen UUID oder einen URI) für das Nachrichtengatter des Dienstes enthalten.
  • 42c – Austausch von Nachrichten mit eingebetteten Authentisierungsnachweisen
  • 42c ist ein Flußdiagramm, das den allgemeinen Vorgang des Nachrichtenaustauschs zwischen einem Client und einem Dienst mit eingebettetem Authentisierungsnachweis gemäß einer Ausführungsform darstellt. Nach einer Ausführungsform brauchen der Client und der Dienst nicht mehr die Dienste des Authentisierungsdienstes, nachdem das Nachrichtengatter des Client und das Nachrichtengatter des Dienstes eingerichtet sind. Beim Senden von Nachrichten können die Nachrichtengatter des Client und des Dienstes den Authentisierungsnachweis in die Nachrichten einbetten. Beim Empfang von Nachrichten können die Nachrichtengatter des Client und des Dienstes die Nachricht durch Vergleich des eingebetteten Authentisierungsnachweises mit der in dem Gatter enthaltenen Kopie des Authentisierungsnachweises überprüfen.
  • In Schritt 1040 kann das Nachrichtengatter des Senders (Client oder Dienst) einen Authentisierungsnachweis in eine Nachricht vor dem Senden der Nachricht einbetten. Nach einer Ausführungsform kann der Authentisierungsnachweis von einem Authentisierungsdienst zur Verfügung gestellt worden sein. Nach einer Ausführungsform kann die Nachricht eine XML-Nachricht sein.
  • Nach einer Ausführungsform kann das Nachrichtengatter des Senders die Richtigkeit der Typen in der Datenrepräsentationssprache, die Syntax, etc. der Nachricht vor dem Senden der Nachricht überprüfen. Nach einer Ausführungsform kann das Nachrichtengatter des Senders die Nachricht mit einer Nachrichtenvorlage in einem Nachrichtenschema vergleichen, um die Richtigkeit der Typen in der Nachricht zu ermitteln. Zum Beispiel kann die Nachricht eine XML-Nachricht sein, und das Nachrichtengatter kann ein XML-Nachrichtenschema enthalten. Das Nachrichtengatter des Senders kann eine Nachrichtenvorlage für die Nachricht in dem Schema lokalisieren und die verschiedenen XML-Einträge oder -Felder in der Nachricht mit der Nachrichtenvorlage vergleichen, um die Richtigkeit der Typen bei den Einträgen zu ermitteln.
  • Nach einer Ausführungsform kann das Nachrichtengatter des Senders die Zulässigkeit der Nachricht überprüfen. Nach einer Ausführungsform kann die Nachricht eine Anforderungsnachricht sein, die von einem Client zum Senden an einen Dienst empfangen wurde, und das Nachrichtengatter kann feststellen, ob die durch die Nachricht angeforderte(n) Funktionen) in der Teilmenge von Funktionen liegen, die dem Client durch die Zugriffsstufe zur Verfügung stehen, die der Client mit dem Dienst durch den Authentisierungsdienst eingerichtet hat. Nach einer Ausführungsform kann das Nachrichtengatter die Nachricht mit einer Teilmenge von erlaubten Anforderungsnachrichten in einem Nachrichtenschema vergleichen, um festzustellen, ob die Nachricht erlaubt ist. Nach einer Ausführungsform wird die Nachricht möglicherweise nicht auf Zulässigkeit überprüft, wenn die Nachricht eine Antwortnachricht von einem Dienst an einen Client ist. Nach einer anderen Ausführungsform können Antwortnachrichten von dem Dienst an den Client durch das Nachrichtengatter des Client überprüft werden, um sicherzustellen, daß der Client zum Empfang der Antwortnachricht autorisiert ist.
  • In Schritt 1042 kann das Nachrichtengatter des Senders (Client oder Dienst) daraufhin die Nachricht an das Nachrichtengatter des Zieles (Client oder Dienst) über den Kommunikationskanal senden, der die Quelle (Client oder Dienst) mit dem Ziel (Client oder Dienst) verbindet. Nach einer Ausführungsform können die Nachrichtengatter beim Empfang der Nachricht den Sender der Nachricht durch Vergleich des eingebetteten Authentisierungsnachweises mit der in dem Gatter enthaltenen Kopie des Authentisierungsnachweises überprüfen.
  • Nach einer Ausführungsform kann die Nachricht vor dem Senden verschlüsselt werden. Nach einer Ausführungsform kann das Nachrichtengatter die Verschlüsselung durchführen. Nach einer anderen Ausführungsform kann ein Prozeß, der zu dem Nachrichtengatter extern ist, die Verschlüsselung durchführen. Zum Beispiel kann das Nachrichtengatter die vervollständigte Nachricht an einen Treiberprozeß für einen Kommunikationskanal übergeben, und der Treiberprozeß kann die Verschlüsselung der Nachricht durchführen. Nach einer Ausführungsform kann die Verschlüsselung und die Entschlüsselung von Nachrichten von einem Transportmechanismus (z. B. HTTPS) durchgeführt werden.
  • In Schritt 1044 kann das Nachrichtengatter des Empfängers (Client oder Dienst) die in Schritt 1042 gesendete Nachricht empfangen. Nach einer Ausführungsform kann die Nachricht, wenn sie verschlüsselt ist, durch einen Prozeß entschlüsselt werden, bevor sie von dem Nachrichtengatter empfangen wird. Nach einer anderen Ausführungsform kann das Nachrichtengatter die Nachricht entschlüsseln, wenn sie verschlüsselt ist. In Schritt 1046 kann das Nachrichtengatter des Empfängers den Sender der Nachricht durch Vergleich des eingebetteten Authentisierungsnachweises mit der in dem Empfängergatter enthaltenen Kopie des Authentisierungsnachweises authentisieren.
  • Nach einigen Ausführungsformen können bestimmte Dienste zumindest für einige Clients keine Authentisierungsnachweise benötigen. Nach einer Ausführungsform kann ein Client, der auf einen Dienst zugreifen möchte, für den kein Authentisierungsnachweis für den Client erforderlich ist, ein Nachrichtengatter ohne Verwendung eines Authentisierungsdienstes erzeugen. Nach einer anderen Ausführungsform kann ein Authentisierungsdienst eine Null, einen leeren oder anderweitig generischen Authentisierungsnachweis an einen Client zurückgeben, der keine Authentisierung zur Nutzung eines Dienstes benötigt. Nach einer Ausführungsform ohne erforderliche Authentisierung können die Nachrichtengatter Nachrichten ohne Einbetten von Authentisierungsnachweisen senden. Nach einer anderen Ausführungsform kann eine Null, ein leerer oder anderweitig generischer Authentisierungsnachweis von den Nachrichtengattern in Nachrichten eingebettet werden.
  • Nach einer Ausführungsform kann das Nachrichtengatter des Empfängers beim Empfang der Nachricht die Richtigkeit der Typen, die Syntax, etc. einer Nachricht in der Datenrepräsentationssprache überprüfen. Nach einer Ausführungsform kann das Nachrichtengatter des Empfängers die Nachricht mit einer Nachrichtenvorlage in einem Nachrichtenschema vergleichen, um die Richtigkeit der Typen in der Nachricht zu ermitteln. Zum Beispiel kann die Nachricht eine XML-Nachricht sein, und das Nachrichtengatter kann ein XML-Nachrichtenschema enthalten. Das Nachrichtengatter des Empfängers kann eine Nachrichtenvorlage für die Nachricht in dem Schema lokalisieren und die verschiedenen XML-Einträge oder -felder in der Nachricht mit der Nachrichtenvorlage vergleichen, um die Richtigkeit der Typen in den Einträgen zu ermitteln.
  • Nach einer Ausführungsform kann das Nachrichtengatter des Empfängers die Zulässigkeit der Nachricht prüfen. Nach einer Ausführungsform kann die Nachricht eine Anforderungsnachricht von einem Client sein, und das Nachrichtengatter kann feststellen, ob die in der Nachricht angeforderte(n) Funktionen) in der Teilmenge von Funktionen liegen, die dem Client durch die Zugriffsstufe zur Verfügung stehen, die der Client mit dem Dienst über den Authentisierungsdienst eingerichtet hat. Nach einer Ausführungsform kann das Nachrichtengatter des Empfängers die Nachricht mit einer Teilmenge von erlaubten Anforderungsnachrichten in einem Nachrichtenschema vergleichen, um zu ermitteln, ob die Nachricht erlaubt ist.
  • Nach einer Ausführungsform können der Sender und der Empfänger die Nachricht auf Richtigkeit der Typen und/oder Zulässigkeit überprüfen. Nach einer anderen Ausführungsform kann der Sender ein Überprüfung der Nachricht durchführen. Nach noch einer anderen Ausführungsform braucht der Sender keine Überprüfung der Nachricht durchzuführen, und der Empfänger kann ein Überprüfung der Nachricht durchführen. Nach noch einer weiteren Ausführungsform braucht keine Überprüfung durchgeführt zu werden.
  • Einige Clients können zu "dünn" bzw. "thin" sein, um die vollständige Funktionalität eines Nachrichtengatter des Clients zu unterstützen. Diese Clients brauchen einiges oder alles von der Überprüfung der Anforderungsnachrichten vor dem Senden von Anforderungsnachrichten und von der Überprüfung der Antwortnachrichten im Anschluß an den Empfang von Antwortnachrichten wie oben beschrieben nicht durchzuführen. Zum Beispiel können einige einfache Clienteinrichtungen eine kleine Menge von Anforderungsnachrichten, die an einen Dienst gesendet werden können, und eine kleine Menge von Antworten, die von dem Dienst akzeptiert werden können, beinhalten. Nach einer Ausführungsform kann ein minimales Nachrichtengatter eines Client für die Clienteinrichtung eingerichtet werden, das Anforderungsnachrichten sendet und Antwortnachrichten empfängt, ohne die oben beschriebene Überprüfung der Nachrichten durchzuführen. Nach einer anderen Ausführungsform kann ein Proxy-Nachrichtengatter eines Client auf einer anderen Einrichtung aufgebaut werden, das einiges oder alles von dem Überprüfen, Senden und Empfangen der Nachrichten, wie oben für den Client beschrieben, zur Verfügung stellt.
  • 43 – Prüfen der Integrität von Nachrichten
  • 43 ist ein Flußdiagramm, das einen Mechanismus zum Prüfen der Integrität von Nachrichten gemäß einer Ausführungsform darstellt. In Schritt 1050 kann das Sendergatter, das im Namen eines Client oder eines Dienstes agiert, ein Token in eine zu sendende Nachricht einbetten. Dieses Token ist separat und verschieden von dem oben beschriebenen Authentisierungsnachweis. Das Token kann Information enthalten, die das empfangende Gatter in die Lage versetzt zu überprüfen, daß die Nachricht nicht beschädigt oder geändert wurde. Zum Beispiel kann der Sender einen Hash oder eine Prüfsumme der Nachricht berechnen, der oder die von dem Empfänger überprüft werden kann. Der Sender kann dieses Token und/oder die gesamte Nachricht auch mittels des privaten Schlüssels des Senders verschlüsseln und in die verschlüsselte Nachricht den entsprechenden öffentlichen Schlüssel einbeziehen, so daß der Empfänger überprüfen kann, daß das Token nicht verändert wurde. In Schritt 1052 kann das Sendergatter die Nachricht senden. In Schritt 1054 kann das Empfängergatter, das im Namen eines Dienstes oder eines Client agiert, die Nachricht empfangen. In Schritt 1056 kann das Empfängergatter die Nachricht und das eingebettete Token untersuchen, um zu überprüfen, daß die Nachricht nicht beeinträchtigt wurde.
  • Es gibt einige Verfahren zum Erzeugen des Token, um es in die Nachricht einzubetten. Nach einer Ausführungsform kann ein Hash der Nachricht berechnet und mit der Nachricht gesendet werden. Das Bilden eines Hash kann die Umwandlung einer Zeichenkette in einen üblicherweise kürzeren Wert oder Schlüssel fester Länge umfassen, der die ursprüngliche Zeichenkette repräsentiert. Beim Empfang der Nachricht kann der Empfänger den Hash neu berechnen und ihn gegen den gesendeten Hash prüfen. Wenn die Nachricht geändert wurde, ist es höchst unwahrscheinlich, daß derselbe Hash erzeugt wird. Der Sender kann den Hash verschlüsseln und den entsprechenden öffentlichen Schlüssel in der verschlüsselten Nachricht senden, um im Wesentlichen sicherzustellen, daß der Hash nicht beschädigt wurde. Nach anderen Ausführungsformen kann ein Verfahren zur Fehlerentdeckung wie eine zyklische Redundanzprüfung verwendet werden. Eine zyklische Redundanzprüfung ist ein Verfahren zum Prüfen auf Fehlern in Daten, die auf einer Kommunikationsverbindung übertragen werden. 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 übertragen. Falls nicht, kann der Sender benachrichtigt werden, um die Nachricht erneut zu senden. Andere Ausführungsformen können andere Verfahren zum Erzeugen, Einbetten und Prüfen von Token zum Prüfen der Nachrichten auf Fehler oder böswilliges Verfälschen beinhalten.
  • Brückenbildende Einrichtungen zu der verteilten Rechnerumgebung
  • Es kann Einrichtungen außerhalb der verteilten Rechnerumgebung geben, die das von der verteilten Rechnerumgebung implementierte Modell zur Nachrichtenübergabe nicht unterstützen. Diese Einrichtungen können Dienste zur Verfügung stellen, die für Clients in der verteilten Rechnerumgebung nützlich sein können. Die verteilte Rechnerumgebung kann einen Mechanismus enthalten, um für solche externen Einrichtungen eine Brücke zu der verteilten Rechnerumgebung zu 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 Auf findungsprotokolls 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 Vorrechnen (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 125b 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ükkungsagent 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-Anforderungsnachrichten) 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 untemehmensweiten Dienst innerhalb der Unternehmensumgebung umfassen. Der Überbrückungsdienst der verteilten Rechnerumgebung dient als ein Überbrückungsdienst zwischen dem Client und dem unternehmensweiten Dienst. Ein Unternehmen kann ein Großunternehmen, ein mittelständisches Unternehmen bzw. ein Kleinunternehmen, eine nicht-kommerzielle Institution, eine Regierungseinheit oder eine andere Art von Organisation sein. Ein Unternehmen kann eine Rechnerumgebung des Unternehmens zum Durchführen eines Teils seines Geschäftes verwenden. Die Rechnerumgebung des Unternehmens kann verschiedene Unternehmensdienste umfassen. Clients in der verteilten Rechnerumgebung können Dienste in der Rechnerumgebung des Unternehmens benutzen wollen. Ein Unternehmensdienst kann auf einer Anzahl von Architekturen wie dreistufigen Client/Server-Architekturen beruhen. Ein Beispiel einer Architektur, die zum Implementieren eines Unternehmensdienstes verwendet werden kann, ist Enterprise JavaBeans. Entenprise JavaBeans (EJB) ist eine Architektur zum Aufbau von Programmkomponenten, geschrieben in der Java-Programmiersprache, die in Serverteilen einer Unternehmensumgebung mittels eines Client/Server-Modells ablaufen. In der objektorientierten Programmier- und verteilten Objekt-Technologie ist eine Komponente ein wiederverwendbarer Block zum Aufbau von Programmen, der mit anderen Komponenten in demselben oder einem anderen Computer in einem verteilten Netzwerk kombiniert werden kann, um eine Anwendung zu bilden. EJB ist auf der JavaBeans-Technologie zum Verteilen von Programmkomponenten (Beans) an Clients in einem Netzwerk aufgebaut. Um eine EJB-Bean oder -Komponente zu verwenden, muß sie Teil einer spezifischen Anwendung sein, die ein Container genannt wird. In Entenprise 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 Entenprise 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 Gattenpaar 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üh rungsform 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 01150001
  • Das obenstehende Schema kann in das folgende geändert werden, ohne daß eine Anwendung erneut kompiliert werden muß:
  • Figure 01150002
  • Die 32A und 32B stellen Beispiele der Verwendung von Schemata von dynamischen Anzeigeobjekten gemäß einer Ausführungsform dar. In 32A wurde die Anwendung 1320 (kann ein Client, ein Dienst oder eine anderen Anwendung sein) mit der in dem Space 1326 gespeicherten Annonce 1324 eines Darstellungsschemas implementiert. Eine Annonce eines Darstellungsschemas kann Elemente enthalten, die die Datentypen, Formatierungsspezifikationen, Zeichensätze, Positionen, Farben und jede andere Information zur Anzeige von Daten für die Anwendung auf der Anzeige 1322 enthalten. Es kann mehrere Annoncen eines Darstellungsschemas für die Anwendung 1320 geben. Zum Beispiel kann es ein Schema für jede Anzeigeseite in einer Reihe von Anzeigeseiten geben (zum Beispiel Webseiten in einer Website).
  • Nach einer Ausführungsform kann die Anwendung 1320 einen Auffindungs- und/oder Nachschlagedienst aufrufen, um Annoncen eines Darstellungsschemas zu lokalisieren. Der Auffindungs- und/oder Nachschlagedienst kann ein XML-Dokument liefern, das eine oder mehrere Annoncen und URIs zu jedem der ein bestimmtes Anzeigeformat beschreibenden Schemata, etc. auflistet. Die Anwendung 1320 kann dann ein Darstellungsschema oder -schemata aus dem XML-Dokument auswählen. Die Anwendung 1320 kann danach das Schema analysieren und dabei die Elemente des Schemas in Komponenten einer Benutzerschnittstelle aufbrechen. Die Komponenten können daraufhin verwendet werden, um Ergebnisdaten auf der passenden Anzeige zu plazieren, zu formatieren und anzuzeigen. Die Ergebnisdaten können zum Beispiel vom Ausführen eines Dienstes oder aus einem Ergebnis-Space sein. Somit ist die Anwendung 1320 im Unterschied zu einer statischen oder vorab festgelegten Anzeige dafür eingerichtet, Ergebnisse gemäß einem Darstellungsschema anzuzeigen, das dynamisch geändert werden kann, ohne ein erneutes Bauen der Anwendung zu erfordern.
  • Darstellungsschemata können zum Anzeigen desselben Ergebnisses in verschiedenen Formaten, zum Extrahieren von Teilen der Ergebnisse zur Anzeige und zum Anzeigen der Ergebnisse auf unterschiedlichen Anzeigeeinrichtungen bereitgestellt werden.
  • Nach einer Ausführungsform können eine oder mehrere Annoncen eines Darstellungsschemas in einem oder mehreren Spaces in der verteilten Rechnerumgebung gespeichert werden. Wenn Kopien einer Anwendung auf einer oder mehreren Einrichtungen aufgerufen werden, kann jede Kopie der Anwendung eine Suche nach Diensten ausführen, um Annoncen für von den Anwendungen verwendete Darstellungsschemata aufzufinden. Somit kann ein zentraler, dauerhafter Speicher der Anzeigeinformation für mehrere Instanzen der Anwendung oder für andere Anwendungen gehalten werden. Die Anzeigeinformation kann an der zentralen Stelle geändert werden, ohne daß das erneute Kompilieren und/oder Installieren der Anwendungen erforderlich ist.
  • In 32B kann der Client 1328 eine Dienstannonce für den Dienst 1330 in einem Space lokalisieren. Beim Aufruf des Dienstes 1330 kann der Client 1328 einen Ort bzw. eine Lage der Annonce 1324 des Darstellungsschemas in dem Space 1326 an den Dienst 1330 übergeben. Wenn der Dienst 1330 bereit ist, dem Client 1328 Ergebnisse bereitzustellen, kann er die Ergebnisse mittels der Anzeigeinformation aus dem Darstellungsschema, das durch die Annonce 1324 des Darstellungsschemas zur Verfügung gestellt wurde, auf der Anzeige 1322 anzeigen (die mit der Einrichtung, auf der der Client 1328 abläuft, verbunden sein kann). Um die Art und Weise, in der Ergebnisse angezeigt werden, zu ändern, können die XML-Nachrichten in der Annonce 1324 des Darstellungsschemas geändert werden, oder es kann ein anderes Darstellungsschema ausgewählt werden, ohne Änderungen bei dem Client 1328 oder dem Dienst 1330 zu erfordern. Der Dienst 1330 kann ein Anzeigedienst sein.
  • Ein Client, eine Anwendung oder ein Dienst können eine Mehrzahl von Anzeigeschemata zum Anzeigen von Ergebnissen verschiedener Operationen, die von einem oder mehreren Diensten bereitgestellt werden, vorsehen. Alternativ kann ein Anzeigeschema Information zum Anzeigen einer Vielzahl von Ergebnissen für einen oder mehrere Clients beinhalten. Somit kann der Client 1328 ein Anzeigeschema oder eine Mehrzahl von Anzeigeschemata verwenden. Zwei oder mehr Anzeigeschemata können zum Formatieren und Anzeigen derselben Ergebnisse mit unterschiedlichen Formaten oder auf unterschiedlichen Anzeigen vorgesehen werden. Zum Beispiel kann ein Anzeigeschema für einen Satz von Ergebnissen zum Anzeigen von Ergebnissen auf einem Anzeigebildschirm und ein anderes zum Drucken der Ergebnisse vorgesehen werden. Ebenso können Kopien derselben Anwendung, desselben Client oder desselben Dienstes auf Einrichtungen mit unterschiedlichen Anzeigefähigkeiten ablaufen, so daß zwei oder mehr Anzeigeschemata zur Unterstützung der Anzeigeerfordernisse auf den unterschiedlichen Einrichtungen zur Verfügung gestellt werden.
  • Zeichenkettenverwaltung
  • Die Behandlung von Zeichenketten in herkömmlichen Systemen ist im allgemeinen nicht sehr effizient, speziell für Zeichenketten variabler Größe, und kann Speicherplatz verschwenden, z. B. wenn die Zeichenkette in dem Speicher kopiert und/oder verschoben wird. Diese Ineffizienz bei der Behandlung von Zeichenketten kann insbesondere in Systemen mit kleiner Speicherauslegung wie eingebetteten Systemen problematisch sein. Die Menge von Speicher, besonders Stackspeicher und Speicher zum dynamischen Belegen, kann in kleinformatigen Systemen eingeschränkt sein. Daher ist ein effizienteres Verfahren zur Behandlung von Zeichenketten in Programmen, die in kleinformatigen Systemen wie eingebetteten Systemen ausgeführt werden, wünschenswert.
  • 33A stellt einen typische Zeichenkettenrepräsentation in der Programmiersprache C dar. In C kann eine Zeichenkette durch einen Zeichenzeiger 1450 (Zeichenkette1 bzw. string1) repräsentiert werden, der eine Speicherstelle (Adresse) des ersten Zeichens einer Zeichenkette 1452 enthält. Andere Zeichen folgen dem ersten Zeichen in der Zeichenkette 1452 und werden typischerweise in fortlaufend adressierbaren Byteplätzen im Speicher gespeichert. Zeichen in C-Zeichenketten sind typischerweise 8-Bit-Werte. Die Zeichen in C-Zeichenketten können jedes beliebige ASCII-Zeichen sein. Eine C-Zeichenkette muß mit einem NULL-Zeichen abgeschlossen werden. NULL ist plattformabhängig als einer der 256 möglichen 8-Bit-Werte definiert, ist jedoch typischerweise der Binärwert 0b00000000. Die Zeichenkette 1452 umfaßt 13 Bytes (12 Zeichen der Zeichenkette plus das abschließende Zeichen).
  • Ein Beispiel einer Zeichenkettenoperation in C ist die Funktion stylen(), die typischerweise bei Implementierungen der Standard-C-Bibliothek zur Verfügung steht. Die Funktion stylen() 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 stylen() die Länge 12 zurückliefern. Die Funktion stylen() 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_t n);
  • Die Funktion strcpy() kopiert die Zeichenkette, auf die der Zeichenzeiger src zeigt (einschließlich des abschließenden Zeichens) in die Zeichenkette, auf die der Zeichenzeiger dest zeigt. Die Zeichenketten dürfen sich nicht überlappen, und die Zielzeichenkette muß groß genug für die Aufnahme der Kopie sein.
  • Die Funktion strncpy() ist ähnlich, außer daß nicht mehr als n Bytes von src kopiert werden. Wenn daher kein abschließendes Zeichen unter den ersten n Bytes von src ist, ist das Ergebnis nicht abgeschlossen. Wenn es gewünscht wird, kann im Anschluß an ein strncpy() eine Anweisung in den Code gesetzt werden, um ein abschließendes Zeichen an das Ende der Zeichenkette dest anzufügen. In dem Fall, daß die Länge von src kürzer als n ist, wird der Rest von dest mit Nullen aufgefüllt. Die Funktionen strcpy() und strncpy() geben einen Zeiger auf die Zielzeichenkette dest zurück.
  • 33B stellt ein Beispiel der Ergebnisse der Funktion strncpy() auf der Zeichenkette 1452 dar, wenn strncpy() mit den folgenden Parametern aufgerufen wird:
    strncpy(string2, string1 + 3, 5);
    wobei string2 ein Zeichenzeiger 1454 ist, der auf das erste Byte hinter dem abschließenden Zeichen der Zeichenkette 1452 zeigt, string1 + 3 ist der Zeichenzeiger 1450, inkrementiert um 3, und 5 ist die Anzahl von Zeichen (Bytes), die aus der Quellokation string1 + 3 nach string2 zu kopieren ist. Nach dem Kopieren kann das nächste Zeichen hinter den aus string1 kopierten fünf Zeichen auf ein abschließendes Zeichen gesetzt werden (das Zeichen kann mit dem abschließenden Zeichen vor dem Kopieren initialisiert worden sein). Somit belegen die beiden Zeichenketten nun (13 + 6) = 19 Bytes im Speicher. Wenn die Funktion strcpy() mit dem Zeichenzeiger 1450 als Quellzeichenkette angewandt wurde, würden die ursprüngliche Zeichenkette 1452 und die resultierende neue Zeichenkette (13*2) = 26 Bytes belegen.
  • 33C stellt ein effizientes Verfahren zur Repräsentation und Verwaltung von Zeichenketten im allgemeinen und in kleinformatigen Systemen wie eingebetteten Systemen im besonderen dar. Die Zeichenkette 1452 wird im Speicher als 12 Bytes gespeichert (kein abschließendes Zeichen ist erforderlich). Die Zeichenkettenstruktur 1460 enthält Zeiger (Adresse(A) und Adresse(L)) auf das erste und letzte Zeichen der Zeichenkette 1452. Mittels dieser Zeichenkettenstruktur kann die Länge der Zeichenkette effizient durch Subtrahieren des Zeigers auf das ersten Zeichen von dem Zeiger auf das letzte Zeichen berechnet werden.
  • Operationen wie die Zeichenkettenkopier-Operationen strcpy() und strncpy() können auch effizienter behandelt werden. Mit den Zeichenkettenstrukturen wie den in 33C dargestellten kann eine neue Zeichenkettenstruktur 1462 erzeugt werden, und die Zeiger auf das erste und letzte Zeichen können initialisiert werden, um auf die entsprechenden Zeichen in der Zeichenkette 1452 zu zeigen. Somit braucht ein Teil von der Zeichenkette 1452 oder die gesamte Zeichenkette 1452 nicht in einen neuen Speicherplatz für die Zeichenkette kopiert zu werden. Da Zeichenketten Hunderte oder sogar Tausende von Zeichen lang sein können, kann der Speicher, der mittels der Zeichenkettenstrukturen und der Zeichenkettenverfahren, die implementiert sind, um Vorteil aus ihnen zu ziehen, gespart wird, beträchtlich sein. Dieses Verfahren zur Behandlung von Kopien von Teilen einer Zeichenkette oder einer gesamten Zeichenkette kann als "Teilzeichenketten-Verwaltung" bezeichnet werden, da es mit der effizienten Behandlung von Teilen (Teilzeichenketten) von Zeichenketten zu tun hat.
  • Andere Zeichenkettenfunktionen aus der Standard-C-Zeichenketten-Bibliothek können durch Zeichenkettenfunktionen ersetzt werden, die Vorteil aus der Zeichenkettenstruktur, wie in 33C dargestellt, ziehen. Beispiele von anderen C-Zeichenkettenfunktionen umfassen, sind jedoch nicht beschränkt auf: strstr(), strcat() und sprintf(). Die Strukturen und Verfahren zur 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 01190001
  • Figure 01200001
  • 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 einpakken 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.
  • 46 stellt einen Mechanismus zum Senden von Objekten von Diensten an Clients mittels XML-Repräsentationen der Objekte dar. In Schritt 2200 kann ein Client ein Objekt von einem Dienst anfordern. Nach einer Ausführungsform kann das Objekt ein Java-Objekt sein. Nach einer Ausführungsform kann der Client eine Nachricht (z. B. eine XML-Nachricht) an den Dienst senden, die das Objekt anfordert. In Schritt 2202 kann der Dienst, nachdem er die Anforderung empfangen hat, das Objekt einem Kompilierungsprozeß übergeben. Nach einer Ausführungsform kann der Kompilierungsprozeß in der virtuellen Maschine, innerhalb welcher der Dienst ausgeführt wird, integriert sein. Nach einer Ausführungsform kann die virtuelle Maschine eine Virtuelle Java-Maschine (JVM) sein. Nach einer Ausführungsform kann der Kompilierungsprozeß als eine Erweiterung der JVM bereitgestellt werden. In Schritt 2204 erzeugt der Kompilierungsprozeß eine Darstellung des Objektes in einer Datenrepräsentationssprache. Nach einer Ausführungsform ist die Datenrepräsentationssprache XML. Die Darstellung des Objektes kann einen Namen oder Bezeichner für das Objekt und eine oder mehrere Instanzvariablen für das Objekt beinhalten. Eine Instanzvariable in der Objekt-orientierten Programmierung ist eine der Variablen einer Klassenvorlage, die verschiedene Werte für jedes Objekt dieser Klasse haben kann. In Schritt 2206 kann der Dienst die Darstellung des Objektes in der Datenrepräsentationssprache an den Client senden. Nach einer Ausführungsform kann die Darstellung in eine Nachricht eingepackt sein. Nach einer Ausführungsform liegt die Nachricht in der Datenrepräsentationssprache vor. Nachrichtengatter, wie hier an anderer Stelle beschrieben, können zur Übergabe von Nachrichten zwischen dem Client und dem Dienst verwendet werden.
  • In Schritt 2208 empfängt der Client die Darstellung des Objektes in der Datenrepräsentationssprache und übergibt die Darstellung an einen Dekompilierungsprozeß. Nach einer Ausführungsform kann der Dekompilierungsprozeß in der virtuellen Maschine, innerhalb welcher der Client ausgeführt wird, integriert sein. Nach einer Ausführungsform kann die virtuelle Maschine eine Virtuelle Java-Maschine (JVM) sein. Nach einer Ausführungsform kann der Dekompilierungsprozeß als eine Erweiterung der JVM bereitgestellt werden. In Schritt 2210 kann die Dekompilierung eine Kopie des Objektes aus der Darstellung des Objektes in einer Datenrepräsentationssprache erzeugen. Das Objekt kann dann an den Client weitergereicht werden.
  • JVM-Kompilierungs-/Dekompilierungs-API
  • Die 35a und 35b sind Datenflußdiagramme, die Ausführungsformen darstellen, bei denen eine virtuelle Maschine (z. B. JVM) Erweiterungen für das Kompilieren von Objekten (z. B. Java-Objekten) in XML-Repräsentationen der Objekte und für das Dekompilieren von XML-Repräsentationen von (Java-)Objekten in (Java-)Objekte beinhaltet. Die JVM kann eine Anwendungsprogrammschnittstelle (Application Programming Interface, API) zu den Kompilierungs/Dekompilierungs-Erweiterungen liefern. Der Client 1500 und der Dienst 1502 können innerhalb von JVMs ausgeführt werden. Die JVMs können auf derselben Einrichtung oder auf verschiedenen Einrichtungen sein.
  • Sowohl in 35a als auch in 35b kann das JVM-XML-Kompilierungs/Dekompilierungs-API 1530 ein Java-Objekt 1510 als Eingabe akzeptieren und eine XML-Repräsentation des Objektes 1510 und aller von ihm referenzierten Objekte (des Objektgraphen des Objektes 1510) in einem XML-Datenstrom 1514 ausgeben. Darüber hinaus kann das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 einen XML-Datenstrom 1522 akzeptieren, der eine XML-Repräsentation des Objektes 1520 und aller von ihm referenzierten Objekte (des Objektgraphen des Objektes 1520) enthält, und das Java-Objekt 1520 (und alle Objekte in seinem Objektgraphen) ausgeben.
  • 35a stellt eine Ausführungsform dar, in der der Client beim Senden des Java-Objektes 1510 das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufruft. Der Client 1500 übergibt das Java-Objekt 1510 an das API 1530, welches das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert die XML-Repräsentation in dem XML-Datenstrom 1514 und gibt den XML-Datenstrom 1514 aus. Der Client kann daraufhin den XML-Datenstrom 1514 an das Gatter 1504 übergeben. Das Gatter 1504 kann dann den XML-Datenstrom 1514 in eine XML-Nachricht 1516 verpacken und die Nachricht 1516 an den Dienst 1502 senden.
  • Beim Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann das Gatter 1522 den XML-Datenstrom 1522 aus der Nachricht 1524 extrahieren und den Datenstrom 1522 an den Client 1500 übergeben. Der Client 1500 kann daraufhin das JVM-XML-Kompilierungs-/Dekompilierungs-API 1530 aufrufen, wobei er dem API 1530 den XML-Datenstrom 1522 übergibt. Das API 1530 kann dann den XML-Datenstrom 1522 dekompilieren, um das Java-Objekt 1520 und die anderen Objekte in seinem Objektgraphen zu erstellen, wobei es die Objekte an den Client 1500 zurückgibt.
  • 35b stellt eine andere Ausführungsform dar, bei der das JVM-XML-Kompilierungs/Dekompilierungs-API 1530 beim Senden des Java-Objektes 1510 von dem Gatter aufgerufen wird. Der Client 1500 übergibt das Java-Objekt 1510 an das Gatter 1504. Das Gatter 1504 übergibt daraufhin das Objekt 1510 an das API 1530, das das Objekt kompiliert, um seine XML-Repräsentation zu erstellen, speichert die XML-Repräsentation in dem XML-Datenstrom 1514 und gibt den XML-Datenstrom 1514 aus. Das Gatter 1504 kann dann den XML-Datenstrom 1514 in eine XML-Nachricht 1516 verpacken und die Nachricht 1516 an den Dienst 1502 senden.
  • Beim Empfang der XML-Nachricht 1524 von dem Dienst 1502 kann das Gatter 1522 den XML-Datenstrom 1522 aus der Nachricht 1524 extrahieren und den Datenstrom 1522 an das JVM-XML-Kompilienungs-/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 Er zeugen 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 vonehmen 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 darauf hin 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 Autorsierung des Benutzers ermittelt werden. Zum Beispiel kann das Objekt einen "nur lesenden" Zugriff für die meisten Benutzer und einen "Schreib-/Lese-'Zugriff für den Erzeuger des Objektes erlauben. Wenn der Benutzer auf ein Objekt mittels Schreib-/Lese-Zugriffsrechten zuzugreifen versucht und der Be nutzer 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.
  • 47 stellt einen Mechanismus zum sicheren Dekompilieren von Objekten auf einer Clienteinrichtung dar. In Schritt 2240 kann ein Benutzer auf eine Clienteinrichtung zugreifen. Nach einer Ausführungsform kann der Benutzer dem Client eine Identifikation übergeben. Nach einer Ausführungsform kann sich der Benutzer bei dem Client zum Beispiel mit einem Benutzernamen und einem Paßwort anmelden. Nach einer Ausführungsform kann der Benutzer ein physikalisches Identifikationsmittel, z. B. eine Smart-Card, an die Clienteinrichtung übergeben, um die Identität des Benutzers auf der Einrichtung festzustellen.
  • Nachdem der Benutzer authentisiert ist, kann der Client während des Zugriffs durch den Benutzer ein oder mehrere Objekte von einem oder mehreren Diensten anfordern. Nach einer Ausführungsform können die Objekte Java-Objekte sein. Nach einer Ausführungsform kann der Client Nachrichten (z. B. XML-Nachrichten) zum Anfordern der Objekte an die Dienste senden. Die Dienste können nach dem Empfang der Anforderungen die Darstellungen der Objekte in einer Datenrepräsentationssprache an den Client senden. Nach einer Ausführungsform können die Darstellungen in Nachrichten eingepackt sein. Nachrichtengatter, wie hier an anderer Stelle beschrieben, können zur Übergabe von Nachrichten zwischen dem Client und dem Dienst verwendet werden.
  • In Schritt 2242 empfängt der Client die Darstellungen der Objekte in einer Datenrepräsentationssprache und übergibt die Darstellungen an einen Dekompilierungsprozeß. Nach einer Ausführungsform kann der Dekompilierungsprozeß in die virtuelle Maschine, innerhalb deren der Client ausgeführt wird, integriert sein. Nach einer Ausführungsform kann die virtuelle Maschine eine Virtuelle Java-Maschine (JVM) sein. Die Dekompilierung kann Kopien der Objekte aus den Darstellungen der Objekte in einer Datenrepräsentationssprache erzeugen. Nach einer Ausführungsform können die Nachrichten geprüft werden, um sicherzustellen, daß der Client Zugriffsprivilegien auf die angeforderten Objekte hat. Die Objekte können dann an den Client übergeben werden, damit sie zur Verwendung während des Zugriffs durch den Benutzer verfügbar sind.
  • In Schritt 2244 kann der Benutzer den Zugriff auf die Clienteinrichtung beenden. Zum Beispiel kann sich der Benutzer abmelden oder eine Identifikationseinrichtung wie eine Smart-Card entfernen, wenn eine benutzt wurde, um der Clienteinrichtung zu signalisieren, daß der Benutzer den Zugriff auf dem Client beendet. Beim Erkennen, daß der Client bzw. Benutzer den Zugriff beendet hat, kann die Clienteinrichtung automatisch jedwede Objekte löschen, die für den Benutzer während des Zugriffs durch den Benutzer dekompiliert wurden. Das Löschen der Objekte kann sicherstellen, daß die Objekte nicht zum versehentlichen oder absichtlichen Zugriff durch nachfolgende Benutzer der Einrichtung auf der Clienteinrichtung verbleiben.
  • Alternativ werden eines oder mehrere der Objekte möglicherweise nicht gelöscht, wenn der Benutzer den Zugriff beendet. Stattdessen können die Objekte (entweder lokal oder anderswo in der verteilten Rechnerumgebung) für einen späteren Zugriff durch den Benutzer gespeichert werden. Nach einer Ausführungsform kann die Zugriffsinformation des Client mit den Objekten gespeichert werden, um unautorisierte Benutzer vom Zugriff auf die Objekte abzuhalten.
  • 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 Kom munikation 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 01330001
  • 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 XML-basierten Speichermechanismus, wie oben beschrieben, gespeichert und später von dem Speichermechanismus zurückgeholt werden, um die Ausführung des Prozesses auf demselben Knoten oder einem anderen Knoten in der verteilten Rechnerumgebung wieder aufzunehmen. Nach einer Ausführungsform kann der hier beschriebene Kompilierungs-/Dekompilierungsvorgang von XML-Objekten beim Erzeugen (Kompilieren) einer XML-Repräsentation des Zustandes eines Prozesses und beim Wiederherstellen des Zustandes des Prozesses durch Dekompilierung der XML-Repräsentation des Zustandes des Prozesses verwendet werden.
  • Mittels dieses Mechanismus' kann eine XML-Repräsentation des Zustandes eines Prozesses in einem XML-basierten Speichermechanismus wie einem Space von einem anfänglichen Knoten gespeichert werden. Anschließend kann ein anderen Knoten den gespeicherten Zustand des Prozesses lokalisieren, den Zustand des Prozesses herunterladen und den Prozeß aus dem heruntergeladenen, gespeicherten Zustand an der Stelle wieder aufnehmen, an der er ausgeführt wurde, als der Zustand gespeichert wurde. Da der Prozeßzustand in einem XML-Format gespeichert ist, können die hier beschriebenen Werkzeuge und Suchmöglichkeiten zum Speichern, Lokalisieren und Zurückholen von XML-Objekten in XML-basierten Speichermechanismen verwendet werden, um die Migration des Prozesses zu ermöglichen. Eine Annonce der gespeicherten XML-Repräsentation des Zustandes des Prozesses kann veröffentlicht werden, um einem Client, der die Prozeßausführung auf demselben Knoten oder einem anderen Knoten wieder aufnimmt, das Lokalisieren des gespeicherten Zustandes und den Zugriff darauf zu ermöglichen.
  • Die XML-Repräsentation des Zustandes eines Prozesses kann in einem XML-basierten, dauerhaften Speichermechanismus gespeichert werden und daher eine dauerhafte Momentaufnahme des Prozesses bereitstellen. Diese kann als ein Verfahren zur Wiederaufnahme der Prozeßausführung auf einem Knoten nach der Unterbrechung des Prozesses auf einem Knoten, zum Beispiel wegen des absichtlichen oder unbeabsichtigten Herunterfahrens des Knotens, verwendet werden. Eine Annonce des gespeicherten Zustandes des Prozesses kann veröffentlicht werden, um Clients das Lokalisieren des gespeicherten Zustandes in der verteilten Rechnerumgebung zu ermöglichen. Nach einer Ausführungsform kann ein Autorisierungsnachweis wie eine digitale Unterschrift oder ein digitaler Berechtigungsnachweise bei dem gespeicherten Zustand beinhaltet sein, um einen unauto risierten 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.
  • 48 stellt einen Mechanismus zur Prozeßmigration unter Verwendung von Darstellungen in einer Datenrepräsentationssprache (wie XML) von Prozessen in einer verteilten Rechnerumgebung dar. In Schritt 2260 wird ein Prozeß innerhalb einer ersten Einrichtung ausgeführt. In Schritt 2262 wird ein aktueller Rechenzustand des Prozesses in eine Darstellung in einer Datenrepräsentationssprache des aktuellen Rechenzustandes konvertiert, wobei der Rechenzustand des Prozesses Information über der Ausführungszustand des Prozesses innerhalb der ersten Einrichtung aufweist.
  • Diese Information kann umfassen, ist jedoch nicht beschränkt auf, Information über einen oder mehrere Threads des Prozesses, Information über eine oder mehrere Überlassungen von Diensten, die von dem Prozeß gehalten werden, und Information über ein oder mehrere Objekte des Prozesses (wie von den Threads gehaltene Objekte), wobei ein Objekt eine Instanz einer Klasse in einer Computerprogrammiersprache (wie der Programmiersprache Java) ist.
  • In Schritt 2264 kann die Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache gespeichert werden. Nach einer Ausführungsform kann die Darstellung lokal gespeichert werden. Nach einer Ausführungsform kann die Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache mittels eines Space-Dienstes in einen Space gespeichert werden. Nach einer Ausführungsform kann die Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache in einer oder mehreren Nachrichten an den Space-Dienst gesendet werden.
  • In Schritt 2266 kann eine zweite Einrichtung auf die gespeicherte Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache zugreifen. Nach einer Ausführungsform kann eine Annonce für die gespeicherte Darstellung in einer Datenrepräsentationssprache zur Verfügung stehen, und die zweite Einrichtung kann die Annonce empfangen oder auf sie zugreifen und die Information in der Annonce verwenden, um die gespeicherte Darstellung in einer Datenrepräsentationssprache zu lokalisieren und darauf zuzugreifen. In Schritt 2268 kann der Prozeß innerhalb der zweiten Einrichtung aus der Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache, auf die zugegriffen wird, in dem aktuellen Rechenzustand wieder eingerichtet werden. Der Prozeß kann daraufhin innerhalb der zweiten Einrichtung die Ausführung bei dem aktuellen Rechenzustand wieder aufnehmen.
  • Alternativ kann die Ausführung des Prozesses auf der ersten Einrichtung im Anschluß an Schritt 2264 beendet werden. Die erste Einrichtung kann dann anschließend auf die gespeicherte Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache zugreifen. Der Prozeß kann daraufhin innerhalb der ersten Einrichtung aus der Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache in dem aktuellen Rechenzustand wieder eingerichtet werden, und die Ausführung des Prozesses kann innerhalb der ersten Einrichtung bei dem aktuellen Rechenzustand wieder aufgenommen werden.
  • In einer anderen Alternative kann die bei Schritt 2262 erzeugte Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache direkt an die zweite Einrichtung gesendet werden (z. B. in einer oder mehreren Nachrichten in einer Datenrepräsentationssprache über Nachrichtengatter). Der Prozeß kann daraufhin innerhalb der zweiten Einrichtung aus der empfangenen Darstellung des aktuellen Rechenzustandes des Prozesses in einer Datenrepräsentationssprache in dem aktuellen Rechenzustand wieder eingerichtet werden. Der Prozeß kann daraufhin innerhalb der zweiten Einrichtung die Ausführung bei dem aktuellen Rechenzustand 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 ei ner mobilen Clienteinrichtung mittels einer "Docking Station" mit einer drahtgebundenen Verbindung direkt in das Netzwerk "einstöpseln". Beispiele von drahtgebundenen Verbindungen umfassen, sind jedoch nicht beschränkt auf: Universal Serial Bus (USB), FireWire und verdrilltes (twisted-pair) Ethernet. Nach einer Ausführungsform kann eine Docking Station auch Eingabe-/Ausgabe-Möglichkeiten wie eine Tastatur, Maus und Anzeige für die mobile Clienteinrichtung bereitstellen. Nach dieser Ausführungsform kann der Standort der mobilen Clienteinrichtung dem Such- oder Auffindungsmechanismus von der Docking Station zur Verfügung gestellt werden.
  • Nach einer Ausführungsform kann eine mobile Clienteinrichtung mit einem verteilten Rechnernetzwerk Verbindung aufnehmen. Während der Benutzer der mobilen Clienteinrichtung innerhalb der drahtlosen Kommunikationsreichweite des verteilten Rechnernetzwerks navigiert, kann die mobile Clienteinrichtung konstant oder in verschiedenen Intervallen einen Ortsvektor als Eingabe an den lokalen Such- oder Auffindungsmechanismus übergeben. Die mobile Clienteinrichtung kann den Ortsvektor aus einem GPS-System erhalten, das in den mobilen Client eingebaut oder ihm zugeordnet ist. Nach einer Ausführungsform kann der Client seine Ortsinformation (z. B. mittels Senden von XML-Nachrichten) an einen Auffindungsmechanismus für lokale Dienste wie einen der hier beschriebenen Lokalisierungsmechanismen für Spaces senden. Zum Beispiel kann der Client das Space-Auffindungsprotokoll für Spaces ablaufen lassen, die Dienste innerhalb einer bestimmten Reichweite vom Aufenthaltsort des Client anbieten, oder der Client kann einen Space-Nachschlagedienst instantiieren, um nach Spaces zu suchen, die für die Nachbarschaft des Client bereitgestellte Dienste ankündigen.
  • Während sich die mobile Clienteinrichtung in eine spezifizierte Reichweite eines Space innerhalb der verteilten Rechnerumgebung bewegt, können die in dem Space gespeicherten Dienste und/oder Daten für die mobile Clienteinrichtung verfügbar gemacht werden. In Ausführungsformen, bei denen die Clienteinrichtung regelmäßig ihren Aufenthaltsort an einen Auffindungsmechanismus übergibt, können lokale Dienste und/oder Daten automatisch für den Benutzer des Clients verfügbar gemacht werden. Nach einer Ausführungsform kann der Benutzer der mobilen Clienteinrichtung die spezifizierte Reichweite eines Space festlegen bzw. ermitteln. Zum Beispiel kann der Benutzer wählen, alle Restaurants innerhalb einer Meile vom aktuellen Standort aus anzuzeigen. Alternativ kann die Reichweite in der Konfiguration des lokalen verteilten Rechnernetzwerkes angegeben werden. Zum Beispiel kann ein stadtweites, verteiltes Rechnernetzwerk eingerichtet werden, um seine Dienste allen Benutzern innerhalb von drei Meilen von den Stadtgrenzen zur Verfügung zu stellen. Nach einer Ausführungsform können visuelle Indikatoren, zum Beispiel Icons, die die verschiedenen von dem Space angebotenen Dienste und/oder Daten repräsentieren, auf der mobilen Clienteinrichtung angezeigt werden. Der Client kann dann auf einen oder mehrere der angezeigten Dienste und/oder Daten zugreifen. Nach einer Ausführungsform kann Information von zwei und mehr Spaces gleichzeitig auf der mobilen Clienteinrichtung angezeigt werden. Nach einer Ausführungsform kann der Benutzer auswählen, welche Dienste und/oder Daten ausfindig gemacht werden sollen. Zum Beispiel kann ein Benutzer mit einer mobilen Clienteinrichtung in einem Einkaufszentrum wählen, alle Schuhgeschäfte in dem Einkaufszentrum anzeigen zu lassen.
  • Nach einer Ausführungsform kann ausführbarer Code und/oder bei der Ausführung des Codes verwendete Daten in eine mobile Clienteinrichtung heruntergeladen werden, um dem Benutzer das Ausführen einer von einem Dienst in dem Space bereitgestellten Anwendung zu ermöglichen. Zum Beispiel können Kinogänger mit mobilen Clienteinrichtungen interaktive Filmbesprechungen von Diensten in einem Space für das Kino herunterladen, und können dadurch eine Echtzeit-Rückmeldung über den Film durchführen, den sie sich ansehen. Nach einer Ausführungsform kann ein Kompilierungs-/Dekompilierungsmechanismus für XML-Objekte wie hier an anderer Stelle beschrieben verwendet werden, um den Code und/oder die Daten zum Erzeugen von XML-Repräsentationen des Codes und/oder der Daten zu kompilieren und die XML-Repräsentationen zum Wiederherstellen des Codes und/oder der Daten auf der mobilen Clienteinrichtung zu dekompilieren. Nach einer Ausführungsform kann eine ausführbare Version eines Prozesses zuvor auf der mobilen Clienteinrichtung vorhanden sein, und Daten für den Prozeß können in die mobile Clienteinrichtung heruntergeladen werden. Zum Beispiel können Daten zum Betrachten mit einem Betrachterprogramm in die mobile Clienteinrichtung heruntergeladen werden. Nach einer Ausführungsform kann eine ausführbare Version eines Prozesses einschließlich des Codes und der Daten zur Ausführung des Prozesses zur Ausführung in die mobile Clienteinrichtung heruntergeladen werden. Nach einer Ausführungsform kann der Dienst die Anwendung in der Ferne für die mobile Clienteinrichtung ablaufen, und der Dienst und der Client können sich gegenseitig XML-Nachrichten einschließlich Daten und optional die Daten beschreibende XML-Schemata übergeben. Nach einer Ausführungsform kann ein Teil des Codes auf dem Dienst und ein Teil auf dem Client ausgeführt werden. Zum Beispiel kann der Dienst Code zum Durchführen von Operationen auf einem Satz von Daten wie numerische Berechnungen ausführen. Die mobile Clienteinrichtung kann Code ausführen, der Teile der von dem Dienst in XML-Nachrichten an den Client übergebenen Daten anzeigen kann und es dem Benutzer der mobilen Clienteinrichtung ermöglichen kann, Daten einzugeben und/oder auszuwählen und die Daten an den Dienst zum Durchführen einer oder mehrerer Operationen auf den Daten zu senden.
  • Nach einer Ausführungsform kann eine mobile Clienteinrichtung gleichzeitig mit zwei oder mehr Diensten in dem verteilten Rechnernetzwerk verbunden sein. Die Dienste können unabhängig oder in Verbindung zur Durchführung einer Reihe von Aufgaben verwendet werden. Zum Beispiel kann ein Dienst von einer entfernten Clienteinrichtung verwendet werden, um Operationen auf einem Satz von Daten zu lokalisieren und/oder durchzuführen, und ein zweiter Dienst kann zum Drukken 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 ver wenden, um festzustellen, wenn der Benutzer sich innerhalb einer spezifizierten Reichweite eines oder mehrerer Spaces oder einer von einem oder mehreren Spaces innerhalb der Umgebung bedienten Nachbarschaft bewegt. Zum Beispiel kann der Auffindungsmechanismus 1706 feststellen, daß die mobile Clienteinrichtung 1700 sich innerhalb der Reichweite von Space 1704 bewegt hat. Der Auffindungsmechanismus 1706 kann daraufhin eine oder mehrere Annoncen 1710 aus dem Space 1704 der mobilen Clienteinrichtung 1700 bereitstellen. Alternativ kann der Auffindungsmechanismus 1706 einen Universal Resource Identifier (URI) für den Space 1704 oder für eine oder mehrere Annoncen in dem Space 1704 der mobilen Clienteinrichtung 1700 bereitstellen. Icons, welche die verschiedenen durch die Dienstannoncen 1708 angekündigten Dienste und/oder durch die Inhaltsannoncen 1710 repräsentierten Daten darstellen, können dann auf der mobilen Clienteinrichtung 1700 angezeigt werden. Der Benutzer kann daraufhin eine oder mehrere der angekündigten Dienste und/oder Daten zur Ausführung und/oder Anzeige auf der mobilen Clienteinrichtung auswählen. Die mobile Rechnereinrichtung 1700 kann eine drahtlose Verbindung mit der Einrichtung, die den Dienst anbietet, aufbauen und mit dem Dienst kommunizieren, um den Dienst unter Verwendung des XML-basierten Nachrichtensystems, wie hier zuvor beschrieben, auszuführen. Alternativ kann der Benutzer der mobilen Rechnereinrichtung 1700 die Einrichtung an eine Docking Station anschließen. Der Standort der Docking Station kann von dem Benutzer mittels eines Such- oder Auffindungsmechanismus' 1706 und mittels Spaces, die Annoncen für die Docking Stationen zum Auffinden des Ortes und der Verfügbarkeit von Docking Stationen innerhalb einer angegebenen Reichweite des Benutzers beinhalten, ausfindig gemacht worden sein. Der Auffindungsmechanismus 1706 kann auch erkennen, wenn sich die mobile Clienteinrichtung 1700 in eine angegebene Reichweite des Space 1714 bewegt. Die verschiedenen Dienstannoncen 1718 und Inhaltsannoncen 1720 können daraufhin dem Benutzer der mobilen Clienteinrichtung 1700 verfügbar gemacht werden. Wenn sich die mobile Clienteinrichtung 1700 aus der angegebenen Reichweite eines der Spaces herausbewegt, können die von diesem Space angebotenen Annoncen aus der Anzeige der mobilen Clienteinrichtung 1700 entfernt werden. Nach einer Ausführungsform können die Annoncen in einem Space Standortinformation für die Dienste und Daten beinhalten, die sie zur Verfügung stellen. Somit kann der Auffindungsmechanismus 1706 feststellen, wenn sich die mobile Clienteinrichtung 1700 innerhalb einer angegebenen Reichweite eines bestimmten in dem Space 1718 angekündigten Dienstes bewegt, und die Dienstannonce basierend auf dem Aufenthaltsort der mobilen Clienteinrichtung 1700 bereitstellen (oder entfernen).
  • Rechnereinrichtungen werden kleiner, während sie gleichzeitig Leistung und Funktionalität hinzugewinnen. Speichereinrichtungen, CPUs, RAM, I/O ASICS, Stromversorgungen, etc. wurden in der Größe soweit reduziert, daß kleine, mobile Clienteinrichtungen viel von der Funktionalität eines Personalcomputers voller Größe beinhalten können. Jedoch sind einige Komponenten eines Computersystems wegen des Humanfaktors und anderer Faktoren nicht leicht zu verkleinern. Diese Komponenten umfassen, sind jedoch nicht beschränkt auf: Tastaturen, Monitore, Scanner und Drucker. Die Grenzen bzw. Schranken der Größenreduzierung einiger Komponenten können verhindern, daß mobile Clienteinrichtungen wirklich die Rolle von Personalcomputern annehmen.
  • Nach einer Ausführungsform können Docking Stationen bereitgestellt werden, die es Benutzern mit mobilen Clienteinrichtungen ermöglichen, sich an Komponenten anzuschließen und diese zu verwenden, die auf der mobilen Clienteinrichtungen wegen des Humanfaktors oder anderer Faktoren nicht verfügbar sind. Zum Beispiel können Docking Stationen an öffentlichen Plätzen wie Flughäfen und Bibliotheken bereitgestellt werden. Die Docking Stationen können Monitore, Tastaturen, Drucker oder andere Einrichtungen für Benutzer mit mobilen Clienteinrichtungen bereitstellen. Nach einer Ausführungsform können die Docking Stationen ohne die Unterstützung einer realen Rechnereinrichtung wie einer von einem Benutzer angeschlossenen mobilen Clienteinrichtungen nicht vollständig funktionieren. Die Docking Station kann Dienste wie verschiedene Eingabe/Ausgabe-Funktionen dem Client unter Verwendung der Rechnerleistung der mobilen Clienteinrichtung zur Verfügung stellen.
  • Eine Docking Station kann einer mobilen Clienteinrichtung eine oder mehrere Verbindungsoptionen bereitstellen. Die Verbindungsoptionen können drahtlose Verbindungen und drahtgebundene Verbindungen umfassen. Beispiele von drahtlosen Verbindungen umfassen, sind jedoch nicht beschränkt auf: Infrarot wie IrDA und drahtlose Netzwerkverbindungen ähnlich zu denjenigen, die von einer Netzwerkschnittstellenkarte (Network Interface Card, NIC) in einem Notebook-Computer bereitgestellt werden. Beispiele von drahtgebundenen Verbindungen umfassen, sind jedoch nicht beschränkt auf: USB, FireWire und verdrilltes Ethernet.
  • Eine mobile Clienteinrichtung kann den Standort von Docking Stationen mittels eines Verfahrens ausfindig machen, das im Wesentlichen dem oben für mobile Clienteinrichtungen beschriebenen ähnlich ist. Der Standort einer oder mehrerer Docking Stationen in einem lokalen, verteilten Rechnernetzwerk kann mittels eines Auffindungsmechanismus' zum Auffinden von Spaces mit Annoncen für die Docking Stationen ausfindig gemacht werden. Die mobile Clienteinrichtung kann einen Aufenthaltsort an den Auffindungsmechanismus übergeben. Nach einer Ausführungsform können der Auffindungsmechanismus oder ein Suchmechanismus den Standort einer oder mehrerer Docking Stationen nächst dem Aufenthaltsort der mobilen Clienteinrichtung zurückgeben. Alternativ kann der Auffindungsmechanismus oder Suchmechanismus einen URI des Space zurückgeben, der die Annoncen für die Docking Stationen enthält, und die mobile Clienteinrichtung kann dann mit dem Space in Verbindung treten, um den Standort der einen oder mehreren Docking Stationen nahe der Einrichtung zur Verfügung zu stellen. Nach einer Ausführungsform kann die mobile Clienteinrichtung dem Such- oder Auffindungsmechanismus Information übergeben, um Anforderungen wie Monitorauflösung, Bildschirmgröße, Grafikfähigkeiten, verfügbare Einrichtungen wie Drucker und Scanner, etc. zu spezifizieren. Nach einer Ausführungsform kann Information über die eine oder mehreren Docking Stationen einschließlich der Verfügbarkeit (verwendet ein anderer Benutzer gerade die Docking Station), der Komponenten und der Leistungsmerkmale der verschiedenen Docking Stationen an den Benutzer auf der mobilen Clienteinrichtung geliefert werden.
  • Wenn ein Benutzer an eine Docking Station herankommt, kann ein Protokoll zur Inanspruchnahme eingeleitet werden. Wenn die Docking Station die Inanspruchnahme akzeptiert, können sichere Eingabe- und Ausgabeverbindungen zwischen der mobilen Clienteinrichtung und der Docking Station aufgebaut werden. Alternativ kann der Benutzer die Docking Station aus einer oder mehreren mittels des Such- oder Auffindungsmechanismus' ausfindig gemachten Docking Stationen auswählen, die auf der mobilen Clienteinrichtung angezeigt werden. Wenn der Benutzer die Docking Station auswählt, kann das Protokoll zur Inanspruchnahme eingeleitet werden, um dem Benutzer für die Dauer der Inanspruchnahme eine sichere, exklusive Verbindung zu der Docking Station zu geben. Ein Verfahren zur Freigabe der Docking Station kann auch vorgesehen werden, um dem Benutzer die Beendigung der Sitzung an der Docking Station und die Freigabe der Docking Station zur Verwendung durch andere Benutzer zu ermöglichen. Nach einer Ausführungsform kann das Protokoll zur Inanspruchnahme eine Überlassung des Dienstes der Docking Station, wie hier zuvor beschrieben, sein.
  • 39a stellte einen Benutzer einer mobilen Clienteinrichtung dar, der den Standort von Docking Stationen gemäß einer Ausführungsform ausfindig macht. Die mobile Clienteinrichtung 1750 kann mit dem Auffindungsmechanismus 1756 Verbindung aufnehmen. Die mobile Clienteinrichtung 1750 kann eine mittels des GPS 1772 erhaltene Ortsangabe dem Auffindungsmechanismus 1756 übergeben. Die mobile Clienteinrichtung 1750 kann dem Auffindungsmechanismus 1756 auch Anforderungen an Docking Stationen übergeben. Der Auffindungsmechanismus 1756 kann einen oder mehrere Spaces 1754 nach Annoncen für Docking Stationen 1758 durchsuchen, die die Anforderungen der mobilen Clienteinrichtung 1750 erfüllen. Nach einer Ausführungsform kann ein Such- oder Auffindungsmechanismus eine oder mehrere Docking Stationen innerhalb einer angegebenen Reichweite der mobilen Clienteinrichtung 1750 durch Vergleich der in den Annoncen 1758 gespeicherten Ortsinformation mit der gelieferten Ortsangabe der mobilen Clienteinrichtung 1750 lokalisieren. Der Auffindungsmechanismus 1756 kann dann den Standort von einer oder mehreren Docking Stationen innerhalb der angegebenen Reichweite der mobilen Clienteinrichtung 1750 bereitstellen. Alternativ kann der Auffindungsmechanismus 1756 eine der mobilen Clienteinrichtung 1750 nächstgelegene Docking Station lokalisieren und die Ortsangabe an die mobile Clienteinrichtung 1750 übergeben.
  • 39b stellt eine mobile Clienteinrichtung 1750 dar, die gemäß einer Ausführungsform mit einer Docking Station 1760 in Verbindung tritt. Nach einer Ausführungsform kann der Benutzer die mobile Clienteinrichtung 1750 in die drahtlose Reichweite der Docking Station 1760 bewegen und eine drahtlose Verbindung zu der Docking Station 1760 herstellen. Nach einer anderen Ausführungsform kann der Benutzer eine drahtgebundene Verbindung zu der Docking Station 1760 durch Verbinden eines oder mehrerer Kabel zwischen der Docking Station 1760 und der mobilen Clienteinrichtung 1750 aufbauen. Nach einer Ausführungsform kann der Benutzer der mobilen Clienteinrichtung 1750 eine Inanspruchnahme der Docking Station 1760 etablieren. Die Inanspruchnahme kann sichere, exklusive Rechte an der Docking Station für die Dauer der Verbindung etablieren. Nach einer Ausführungsform kann der Mechanismus zur Inanspruchnahme ein Überlassungsmechanismus für eine Ressource (die Docking Station) sein, wie vorstehend beschrieben. Nach einer Ausführungsform kann einem Benutzer die Verwendung der Docking Station in Rechnung gestellt werden. Zum Beispiel kann der Benutzer eine Kreditkartennummer als Teil des Vorgangs der Inanspruch nahme 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 Dokking Station anschließen, ohne den Auffindungsmechanismus zu verwenden. Zum Beispiel kann ein Benutzer in einem Flughafen eine Docking Station ausfindig machen und eine mobile Clienteinrichtung an sie anschließen. Ein anderes Beispiel kann eine Bibliothek sein, die einen Raum für Docking Stationen mit einer Mehrzahl von Docking Stationen zur Benutzung bereitstellt, in dem Benutzer jede der Docking Stationen benutzen können, soweit sie frei sind.
  • Kleinformatige und/oder eingebettete Einrichtungen
  • Einfache eingebettete oder kleinformatige Einrichtungen können einen begrenzten Speicherumfang zum Speichern und Ausführen von Programmanweisungen haben. Eine einfache eingebettete Einrichtung muß möglicherweise einen beschränkten Satz von Kontroll- bzw. Steuereingaben zum Initiieren der Funktionalität der Einrichtung und Ausgaben zum Melden des Zustandes der Einrichtung verstehen. Ein Beispiel einer einfachen, eingebetteten Einrichtung ist ein "intelligenter" Schalter (wie ein Lichtschalter) mit eingebetteten Schaltungen zum Steuern des Schalters und somit der durch den Schalter gesteuerten Einrichtung. Der intelligente Schalter muß möglicherweise nur zwei Steueranforderungen (Ändern des Zustandes der Einrichtung, Anfordern des Zustandes der Einrichtung) verstehen und eine Zustandsnachricht (den Zustand der Einrichtung) senden. Ein intelligenter Schalter kann die mit ihm verbundene Einrichtung durch das Empfangen seiner Steueranforderungen von einem oder mehreren Steuerungssystemen und das Melden von Zustandsnachrichten an ein oder mehrere Steuerungssysteme verwalten.
  • Nach einer Ausführungsform kann die verteilte Rechnerumgebung einen Rahmen (Protokoll) zum Einbeziehen kleiner Einrichtungen bereitstellen, die nicht über die Ressourcenauslegung (wie Speicher) verfügen, die zum Implementieren des vollständigen Protokolls der verteilten Rechnerumgebung nötig ist. Nach einer Ausführungsform kann ein Agent als eine Brücke zwischen dem Protokoll, zu dem kleine Einrichtungen fähig sind, und dem vollständigen Protokoll vorgesehen werden. Der Agent kann das vollständige Auffindungsprotokoll für die kleine Einrichtung durchführen, so daß die Einrichtung das vollständige Auffindungsprotokoll und die vollständige Aktivierung von Diensten nicht zu implementieren braucht. Nach einer Ausführungsform muß die kleine Einrichtung möglicherweise nur Dienst-spezifische Nachrichten senden. Nach einer Ausführungsform können diese Nachrichten auf der kleinen Einrichtung vorgefertigt sein, so daß die kleine Einrichtung möglicherweise nur Nachrichten an den Agenten zu senden braucht, die Teil der Dienstaktivierung sind. Der Agent kann die Dienstaktivierung mittels des vollständigen Protokolls zu dem Dienst durchführen und eintreffende Nachrichten von der Einrichtung an den Dienst weiterleiten und/oder kann Antworten von dem Dienst an den Client weiterleiten. Somit kann der Agent als ein Dienstvermittler für den kleinen Client fungieren.
  • Nach einer Ausführungsform der verteilten Rechnerumgebung kann eine eingebettete Einrichtung darauf eingerichtet werden, einen spezifischen Satz von Steuerungsanforderungen in der Form von XML-Nachrichten zu empfangen und einen spezifischen Satz von XML-Nachrichten zum Erstellen von Anforderungen, eines Zustandsberichtes, etc. zu senden. Nach einer Ausführungsform kann ein Steuerungssystem darauf eingerichtet werden, eine Vielzahl von Einrichtungen durch das Senden von für jede von ihm gesteuerte Einrichtung oder Kategorie von Einrichtungen spezifische XML-Anforderungsnachrichten und durch das Empfangen von XML-Nachrichten von den Einrichtungen zu verwalten. Nach einer Ausführungsform können ein oder mehrere XML-Schemata verwendet werden, um den spezifischen Satz von XML-Nachrichten einer eingebetteten Einrichtung zu definieren; das Schema kann von der eingebetteten Einrichtung und/oder dem Steuerungssystem beim Senden und Empfangen von XML-Nachrichten verwendet werden.
  • Eine eingebettete Einrichtung kann eine "dünne" Implementierung des XML-Nachrichtensystems wie zuvor hier beschrieben beinhalten, die den spezifischen Satz von Nachrichten zum Steuern und Überwachen der einfachen eingebetteten Einrichtung unterstützt. Die Implementierung des XML-Nachrichtensystems kann auf die Verwendung mit kleinformatigen, einfachen eingebetteten Einrichtungen zugeschnitten sein, und kann dadurch in den begrenzten Speicher der kleinformatigen Einrichtungen passen. Nach einer Ausführungsform kann das XML-Nachrichtensystem in einem kleinen Format mit einer für kleinformatige, eingebettete Einrichtungen ausgerichteten virtuellen Maschine (z. B. KVM) implementiert sein. Ein Netzwerkstack (zur Unterstützung des Transportprotokolls für die Kommunikation mit einem oder mehreren Steuerungssystemen) kann der virtuellen Maschine zugeordnet sein, und die Schicht zum Senden von XML-Nachrichten kann "oben auf' dem Netzwerkstack "sitzen". Man beachte, daß diese Implementierung des Nachrichtensystems auch in anderen Einrichtungen als kleinformatigen oder eingebetteten Einrichtungen verwendet werden kann.
  • Nach einer Ausführungsform können statische oder vorab erstellte Nachrichten für Anforderungen von den Steuerungssystemen an die eingebetteten Einrichtungen verwendet werden. Die statischen Nachrichten können in den eingebetteten Einrichtungen vorab kompiliert und gespeichert sein. Eine eintreffende Nachricht kann mit den gespeicherten statischen Nachrichten verglichen werden, um eine Übereinstimmung für die Nachricht zu finden und somit die durch die Nachricht angeforderte Funktion durchzuführen, wodurch der Codebedarf zum Analysieren bzw. Parsen von eintreffenden Nachrichten reduziert oder eliminiert wird. Abgehende Nachrichten können direkt aus den gespeicherten statischen Nachrichten gelesen werden, wodurch der Bedarf für dynamisches Kompilieren abgehender Nachrichten reduziert oder eliminiert wird. Somit können statische Nachrichten zur Reduktion des Codeumfangs der Nachrichtenschicht in eingebetteten Systemen verwendet werden. Zum Beispiel können statische Java-Objekte (Java-Opcodes) für Anforderungs- und Zustandsnachrichten verwendet werden.
  • 40a stellt eine Ausführungsform von eingebetteten Einrichtungen 1804a und 1804b dar, die durch ein Steuerungssystem 1800 gemäß einer Ausführungsform gesteuert werden. Das Steuerungssystem 1800 kann mit den Einrichtungen 1804a und 1804b, die es steuert, auf vielfältige Weise über ein Netzwerk verbunden sein. Das Netzwerk 1810 kann drahtgebunden (Ethernet, Koaxialkabel, verdrillte Kabel, Stromnetz, etc.) und/oder drahtlos (IrDA, Mikrowellen, etc.) sein. Nach einer Ausführungsform können die eingebetteten Einrichtungen 1804a und 1804b eine dünne Implementierung des XML-Nachrichtensystems zur Kommunikation mit dem Steuerungssystem 1800 über das Netzwerk 1810 beinhalten. Das Steuerungssystem 1800 kann über eine Implementierung des XML-Nachrichtensystems zum Senden von Anforderungen an und Empfang von Antworten von den eingebetteten Einrichtungen 1804a und 1804b verfügen. Nach einer Ausführungsform kann das Steuerungssystem 1800 Software und Hardware beinhalten, die dafür eingerichtet ist, eine Schnittstelle darzustellen, um einem Benutzer das Anzeigen des Zustandes und die Steuerung der eingebetteten Einrichtungen 1804a und 1804b aus der Ferne zu ermöglichen. Nach einer Ausführungsform kann das Steuerungssystem 1800 Software und/oder Hardware zur automatischen Steuerung der eingebetteten Einrichtungen 1804a und 1804b beinhalten.
  • Nach einer Ausführungsform können die eingebetteten Einrichtungen 1804a und 1804b Teil einer anderen Umgebung sein. Die Einrichtungen unterstützen das von der verteilten Rechnerumgebung implementierte Modell zur Nachrichtenübergabe möglicherweise nicht. Zum Beispiel können die Einrichtungen Knoten in einem vernetzten Automatisierungs- und Steuerungssystem wie einem LonWorks-Netzwerk sein. Das Steuerungssystem 1800 kann eine Steuerungssystem-Hardware und/oder -Software zur Steuerung der Einrichtungen in der anderen Umgebung beinhalten. Das Steuerungssystem 1800 kann als eine Brücke zwischen der verteilten Rechnerumgebung und der anderen Umgebung dienen. Die verteilte Rechnerumgebung kann auch ein Verfahren oder (mehrere) Verfahren bereitstellen, um vorhandene Auffindungsprotokolle für Einrichtungen zum Auffinden von Einrichtungen für einen Zugriff aus der verteilten Netzwerkumgebung zu umhüllen. Protokolle zur Brückenbildung und zum Umhüllen sind in dem Abschnitt zur Überbrückung weiter beschrieben.
  • Das Steuerungssystem 1800 kann entfernt oder lokal an ein oder mehrere andere Systeme in der verteilten Rechnerumgebung angeschlossen sein. 40a zeigt das Steuerungssystem 1800, das über das Internet 1802 an den Client 1806 angeschlossen ist. Der Client 1806 kann indi rekt 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 01490001
  • 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 01500001
  • Figure 01510001
  • Schlußfolgerunq
  • Verschiedene Ausführungsformen können weiterhin das Empfangen, Senden oder Speichern von Anweisungen und/oder Daten umfassen, welche gemäß der vorstehenden Beschreibung auf einem Trägermedium implementiert sind. Allgemein gesprochen kann ein Trägermedium ein Speichermedium, wie z. B. magnetische oder optische Medien, z. B. eine Diskette oder eine CD-ROM, flüchtige oder nicht-flüchtige Medien wie RAM (z. B. SDRAM, RDRAM, SRAM, etc.), ROM, etc. ebenso wie Sendemedien oder Signale, wie z. B. elektrische, elektromagnetische oder digitale Signale umfassen, die über ein Kommunikationsmedium, wie z. B. ein Netzwerk und/oder eine kabellose Verbindung transportiert werden.

Claims (31)

  1. Verfahren zum Darstellen eines Zustands eines Prozesses in einer Datendarstellungssprache in einer verteilten Rechnerumgebung, wobei das Verfahren aufweist: Ausführen des Prozesses mit einer ersten Einrichtung, Umwandeln eines aktuellen Berechnungszustands des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache, wobei der Berechnungszustand des Prozesses Information über den Ausführungszustand des Prozesses innerhalb der ersten Einrichtung umfaßt, und Speichern der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, wobei die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache für die Verwendung beim Wiederherstellen des Prozesses und beim Wiederaufnehmen der Ausführung des Prozesses ausgelegt ist.
  2. Verfahren nach Anspruch 1, wobei die Darstellung des aktuellen Zustands des Prozesses in der Datendarstellungssprache in einem Speicherraum unter Verwendung eines Speicherraumdienstes gespeichert wird, wobei der Speicherraum so betreibbar ist, daß er Dokumente speichert, welche Dokumente in der Datendarstellungssprache in der verteilten Rechnerumgebung umfaßt, und wobei der Speicherraumdienst so betreibbar ist, daß er Dokumente in dem Speicherraum speichert und wiederholt für Prozesse in der verteilten Rechnerumgebung.
  3. Verfahren nach Anspruch 2, wobei das Speichern der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache das Senden der Darstellung in der Datendarstellungssprache an den Speicherraumdienst in einer oder in mehreren Nachrichten umfaßt.
  4. Verfahren nach Anspruch 3, wobei die eine oder die mehreren Nachrichten in der Datendarstellungssprache vorliegen.
  5. Verfahren nach einem der Ansprüche 1 bis 4, welches weiterhin aufweist: eine zweite Einrichtung, welche auf die gespeicherte Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache zugreift, Wiederherstellen des Prozesses in dem aktuellen Berechnungszustand in der zweiten Einrichtung aus der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, und Wiederaufnehmen des Ausführens des Prozesses innerhalb der zweiten Einrichtung aus dem aktuellen Berechnungszustand.
  6. Verfahren nach Anspruch 5, welches weiterhin aufweist: Erzeugen einer Anzeige für die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, wobei die Anzeige Information aufweist, um den Zugriff auf die gespeicherte Darstellung in der Datendarstellungssprache zu ermöglichen, und wobei das Zugreifen der zweiten Einrichtung auf die gespeicherte Darstellung in der Datendarstellungssprache aufweist: Zugreifen der zweiten Einrichtung auf die Anzeige für die gespeicherte Darstellung in der Datendarstellungssprache, und Lokalisieren der gespeicherten Darstellung in der Datendarstellungssprache durch die zweite Einrichtung unter Verwendung der Information in der Anzeige.
  7. Verfahren nach Anspruch 6, wobei die Anzeige für die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache in einem Speicherraum unter Verwendung eines Speicherraumdienstes gespeichert wird, wobei der Speicherraum in der Lage ist, Dokumente einschließlich Anzeigen in der verteilten Rechnerumgebung zu speichern, und wobei der Speicherraumdienst so betreibbar ist, daß er Dokumente in dem Raum für Prozesse in der verteilten Rechnerumgebung speichert und wiedergewinnt, und wobei das Zugreifen auf die Anzeige das Wiedergewinnen der Anzeige aus dem Speicherraum unter Verwendung des Speicherraumdienstes umfaßt.
  8. Verfahren nach einem der Ansprüche 1 bis 7, welches weiterhin aufweist: Beenden der Ausführung des Prozesses innerhalb der ersten Einrichtung, wobei die erste Einrichtung auf die von dem Speicherraumdienst gespeicherte Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache zugreift, der Prozeß in dem aktuellen Berechnungszustand in der ersten Einrichtung aus der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache wiederhergestellt wird, und die Ausführung des Prozesses innerhalb der ersten Einrichtung aus dem aktuellen Berechnungszustand wiederaufgenommen wird.
  9. Verfahren nach einem der Ansprüche 1 bis 8, wobei der aktuelle Berechnungszustand des Prozesses ein oder mehrere Stränge (Threads) des Prozesses umfaßt, wobei das Umwandeln eines aktuellen Berechnungszustands des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache aufweist: Einbeziehen von Information, welche einen oder mehrere Stränge in der Darstellung des aktuellen Berechnungszustands in der Datendarstellungssprache beschreibt, wobei die Information, welche den einen oder die mehreren Stränge beschreibt, für die Verwendung beim erneuten Starten des einen oder der mehreren Stränge ausgelegt ist, wenn die Ausführung des Prozesses wiederaufgenommen wird.
  10. Verfahren nach einem der Ansprüche 1 bis 9, wobei der aktuelle Berechnungszustand des Prozesses eines oder mehrere Rechte an den Diensten umfaßt, die von dem Prozeß gehalten werden, und wobei das Umwandeln eines aktuellen Berechnungszustands des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache aufweist: Einbeziehen von Information, welche das eine oder die mehreren Rechte in der Darstellung des aktuellen Berechnungszustands in der Datendarstellungssprache beschreibt, wobei die Information, welche das eine oder die mehreren Rechte beschreibt, für die Verwendung beim erneuten Bereitstellen des einen oder der mehreren Rechte an den Diensten für den Prozeß ausgelegt ist, wenn die Ausführung des Prozesses wiederaufgenommen wird.
  11. Verfahren nach einem der Ansprüche 1 bis 10, wobei der aktuelle Berechnungszustand des Prozesses ein oder mehrere Objekte des Prozesses umfaßt, wobei ein Objekt eine Instanz einer Klasse in einer Computerprogrammiersprache ist und wobei das Umwandeln eines aktuellen Berechnungszustands des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache aufweist: Umwandeln des einen oder der mehreren Objekte in Darstellungen des einen oder der mehreren Objekte in der Datendarstellungssprache, und Einbeziehen der Darstellungen des einen oder der mehreren Objekte in der Datendarstellungssprache in die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, wobei die Darstellungen des einen oder der mehreren Objekte in der Datendarstellungssprache dafür ausgelegt sind, für das Erzeugen von Kopien des einen oder der mehreren Objekte verwendet zu werden.
  12. Verfahren nach Anspruch 11, wobei Computerprogrammiersprache die Java-Programmiersprache ist.
  13. Verfahren nach einem der Ansprüche 1 bis 12, wobei der Prozeß in einer virtuellen Maschine ausgeführt wird, die in der ersten Einrichtung arbeitet bzw. ausgeführt wird.
  14. Verfahren nach Anspruch 13, wobei die virtuelle Maschine eine virtuelle Java-Maschine (JVM) ist.
  15. Verfahren nach einem der Ansprüche 1 bis 14, wobei die Datendarstellungssprache die erweiterte Markierungssprache (Extensible Markup Language (XML)) ist.
  16. Verteiltes Computersystem für das Überführen eines Zustands eines Prozesses in eine Datendarstellungssprache, welches aufweist: eine erste Einrichtung, die so betreibbar ist, daß sie den Prozeß ausführt, und eine zweite Einrichtung, wobei die erste Einrichtung dafür ausgelegt ist, daß sie einen aktuellen Berechnungszustand des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache umwandelt, wobei der Berechnungszustand des Prozesses Information über den Ausführungszustand des Prozesses innerhalb der ersten Einrichtung aufweist, und Senden der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache an die zweite Einrichtung, wobei die zweite Einrichtung dafür ausgelegt ist, daß sie die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache von der ersten Einrichtung empfängt, den Prozeß in dem aktuellen Berechnungszustand von der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache wiederherstellt, und die Ausführung des Prozesses aus dem aktuellen Berechnungszustand wiederaufnimmt.
  17. System nach Anspruch 16, wobei die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache in einer oder mehreren Nachrichten an die zweite Einrichtung gesendet wird.
  18. System nach Anspruch 17, wobei die eine oder die mehreren Nachrichten in der Datendarstellungssprache vorliegen.
  19. System nach einem der Ansprüche 16 bis 18, wobei der aktuelle Berechnungszustand des Prozesses umfaßt: einen oder mehrere Stränge (Threads) des Prozesses, ein oder mehrere Rechte auf Dienstleistungen, die von dem Prozeß gehalten bzw. bereitgestellt werden, und ein oder mehrere Objekte des Prozesses, wobei ein Objekt eine Instanz einer Klasse in einer Computerprogrammiersprache ist, wobei beim Umwandeln eines aktuellen Berechnungszustands des Prozesses in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache die erste Einrichtung weiterhin dafür ausgelegt ist, daß sie Information einbezieht, welche den einen oder die mehreren Stränge in der Darstellung des aktuellen Berechnungszustands in der Datendarstellungssprache beschreibt, wobei die Information, welche den einen oder die mehreren Stränge beschreibt, für die Verwendung beim erneuten Starten des einen oder der mehreren Stränge ausgelegt ist, wenn die Ausführung des Prozesses wiederaufgenommen wird, Information einbezieht, welche das eine oder die mehreren Rechte an der Darstellung des aktuellen Berechnungszustands in der Datendarstellungssprache beschreibt, wobei die Information, welche die einen oder mehreren Rechte beschreibt, für die Verwendung beim Wiederbereitstellen des einen oder der mehreren Rechte an Diensten für den Prozeß ausgelegt ist, wenn die Ausführung des Prozesses wiederaufgenommen wird, die einen oder mehreren Objekte in Darstellung des einen oder der mehreren Objekte in einer Datendarstellungssprache umwandelt, und die Darstellungen des einen oder der mehreren Objekte in einer Datendarstellungssprache in die Darstellung des aktuellen Berechnungszustands des Prozesses in einer Datendarstellungssprache einbezieht, wobei die Darstellungen des einen oder der mehreren Objekte in der Datendarstellungssprache für die Verwendung beim Erzeugen von Kopien des einen oder der mehreren Objekte ausgelegt sind.
  20. System nach einem der Ansprüche 16 bis 19, welches weiterhin eine virtuelle Maschine aufweist, die innerhalb der ersten Einrichtung ausführbar ist, und eine zweite virtuelle Maschine aufweist, die innerhalb der zweiten Einrichtung ausführbar ist, wobei der Prozeß innerhalb der ersten virtuellen Maschine auf der ersten Einrichtung ausführbar ist, und wobei der Prozeß wiederhergestellt und in der zweiten virtuellen Maschine der zweiten Einrichtung ausgeführt wird.
  21. System nach Anspruch 20, wobei die erste virtuelle Maschine und die zweite virtuelle Maschine virtuelle Java-Maschinen (JVMs) sind.
  22. System nach einem der Ansprüche 16 bis 21, wobei die Datendarstellungssprache die erweiterbare Markierungssprache (Extensible Markup Language (XML)) ist.
  23. Trägermedium, welches Programmanweisungen aufweist, wobei die Programmanweisungen durch einen Computer ausführbar sind, um folgendes zu implementieren: Umwandeln eines aktuellen Berechnungszustands eines Prozesses, der innerhalb einer ersten Einrichtung abläuft, in eine Darstellung des aktuellen Berechnungszustands in einer Datendarstellungssprache, wobei der Berechnungszustand des Prozesses Information über den Ausführungszustand des Prozesses innerhalb der ersten Einrichtung aufweist, und Speichern der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, wobei die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache für die Verwendung beim Wiederherstellen des Prozesses und Wiederaufnehmen der Ausführung des Prozesses ausgelegt ist.
  24. Trägermedium nach Anspruch 23, wobei die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache in einem Speicherraum unter Verwendung eines Speicherraumdienstes gespeichert wird, wobei der Speicherraum so betreibbar ist, daß er Dokumente, welche Dokumente in der Datendarstellungssprache umfassen, in der verteilten Rechnerumgebung speichert, und wobei der Speicherraumdienst so betreibbar ist, daß er Dokumente in dem Raum für Prozesse in der verteilten Rechnerumgebung speichert und wieder hervorholt.
  25. Trägermedium nach Anspruch 24, wobei beim Speichern der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache die Programmanweisungen weiterhin durch Computer ausführbar sind, um das Senden der Darstellung in der Datendarstellungssprache an den Speicherraumdienst in einer oder mehreren Nachrichten in der Datendarstellungssprache zu implementieren.
  26. Trägermedium nach einem der Ansprüche 23 bis 25, wobei die Programmanweisungen weiterhin durch Computer ausführbar sind, um folgendes zu implementieren: Zugreifen einer zweiten Einrichtung auf die gespeicherte Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, Wiederherstellen des Prozesses in dem aktuellen Berechnungszustand innerhalb der zweiten Einrichtung aus der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, und Wiederaufnehmen des Ausführens des Prozesses innerhalb der zweiten Einrichtung aus dem aktuellen Berechnungszustand heraus.
  27. Trägermedium nach Anspruch 26, wobei die Programmanweisungen weiterhin durch einen Computer ausführbar sind, um folgendes zu implementieren: Erzeugen einer Anzeige für die Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, wobei die Anzeige Information aufweist, um einen Zugriff auf die gespeicherte Darstellung in der Datendarstellungssprache freizugeben, und wobei das Zugreifen auf die gespeicherte Darstellung in der Datendarstellungssprache durch die zweite Einrichtung aufweist: Zugreifen der zweiten Einrichtung auf die Anzeige für die gespeicherte Darstellung der Datendarstellungssprache, und Lokalisieren der gespeicherten Darstellung in der Datendarstellungssprache durch die zweite Einrichtung unter Verwendung der Information in der Anzeige.
  28. Trägermedium nach Anspruch 27, wobei die Anzeige der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache unter Verwendung eines Speicherraumdienstes in einem Speicherraum gespeichert wird, wobei der Speicherraum derart betreibbar ist, daß er Dokumente einschließlich Anzeigen in der verteilten Rechnerumgebung speichert, und wobei der Speicherraumdienst derart betreibbar ist, daß er Dokumente in dem Speicherraum für Prozesse in der verteilten Rechnerumgebung speichert und wiedergewinnt, und wobei beim Zugreifen auf die Anzeige die Programmanweisungen weiterhin durch einen Computer ausführbar sind, um das Wiedergewinnen der Anzeige aus dem Speicherraum unter Verwendung des Speicherraumdienstes zu implementieren.
  29. Trägermedium nach einem der Ansprüche 23 bis 28, wobei die Programmanweisungen weiterhin durch Computer ausführbar sind, um folgendes zu implementieren: Beenden der Ausführung des Prozesses innerhalb der ersten Einrichtung, Zugreifen auf die gespeicherte Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache in dem Speicherraum durch die erste Einrichtung, Wiederherstellen des Prozesses im aktuellen Berechnungszustand innerhalb der ersten Einrichtung aus der Darstellung des aktuellen Berechnungszustands des Prozesses in der Datendarstellungssprache, und Wiederaufnehmen der Ausführung des Prozesses innerhalb der ersten Einrichtung aus dem aktuellen Berechnungszustand heraus.
  30. Trägermedium nach einem der Ansprüche 23 bis 29, wobei der Prozeß innerhalb einer virtuellen Java-Maschine ausgeführt wird, welche innerhalb der ersten Einrichtung arbeitet.
  31. Trägermedium nach einem der Ansprüche 23 bis 30, wobei die Datendarstellungssprache die erweiterbare Markup-Sprache (Extensible Markup Language (XML)) ist.
DE60102305T 2000-05-09 2001-05-09 Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung Expired - Lifetime DE60102305T2 (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
US209140P 2000-06-02
US209430P 2000-06-02
US20952500P 2000-06-05 2000-06-05
US209525P 2000-06-05
US663564 2000-09-15
US09/663,564 US7200848B1 (en) 2000-05-09 2000-09-15 Migrating processes using data representation language representations of the processes in a distributed computing environment
PCT/US2001/015132 WO2001086440A2 (en) 2000-05-09 2001-05-09 Migrating processes using data representation language representations of the processes in a distributed computing environment

Publications (2)

Publication Number Publication Date
DE60102305D1 DE60102305D1 (de) 2004-04-15
DE60102305T2 true DE60102305T2 (de) 2004-07-22

Family

ID=27558951

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60102305T Expired - Lifetime DE60102305T2 (de) 2000-05-09 2001-05-09 Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung

Country Status (7)

Country Link
US (1) US7200848B1 (de)
EP (1) EP1309915B1 (de)
JP (1) JP2003534588A (de)
AT (1) ATE261596T1 (de)
AU (1) AU2001261386A1 (de)
DE (1) DE60102305T2 (de)
WO (1) WO2001086440A2 (de)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7117239B1 (en) * 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US7215887B2 (en) * 2000-08-15 2007-05-08 Lockheed Martin Corporation Method and apparatus for infrared data communication
US7386238B2 (en) * 2000-08-15 2008-06-10 Lockheed Martin Corporation Method and system for infrared data communications
US7055143B2 (en) * 2001-07-10 2006-05-30 Microsoft Corporation System and methods for providing a declarative syntax for specifying SOAP-based web services
US7200567B2 (en) * 2002-01-04 2007-04-03 Lockheed Martin Corporation Purchasing aid logistics appliance and method for use
ES2298336T3 (es) * 2002-07-22 2008-05-16 Motorola, Inc. Aplicacion de persistencia en un sistema de comunicaciones inalambricas.
US20040139144A1 (en) * 2002-12-31 2004-07-15 Batra Virinder M. Using web services to access computational grids by non-members of the grid
US20040140986A1 (en) * 2003-01-16 2004-07-22 Boldon John Leland Systems and methods for facilitating printing through interface exportation
EP1614254A1 (de) * 2003-04-04 2006-01-11 Computer Associates Think, Inc. Verfahren und system zur alarmmitteilung
US20050108331A1 (en) * 2003-10-31 2005-05-19 Osterman Lawrence W. Presence tracking for datagram based protocols with search
KR100560424B1 (ko) * 2003-11-05 2006-03-13 한국전자통신연구원 접근이 제한되는 고비도 검증키를 갖는 변형된 디지털서명을 이용한 안전한 프로그래머블 패킷 전송 방법
US7716286B2 (en) * 2003-12-10 2010-05-11 Heins Douglas B Method and apparatus for utility computing in ad-hoc and configured peer-to-peer networks
US9262743B2 (en) 2003-12-10 2016-02-16 Zerotouchdigital, Inc. Method and apparatus for sociable computing in ad-hoc and configured peer-to-peer networks
FR2864398A1 (fr) * 2003-12-23 2005-06-24 France Telecom Terminal de telecommunication a deux espaces d'execution
US20070208835A1 (en) * 2003-12-24 2007-09-06 Arjan Te Marvelde Radio Base Station Controlled by a Monitor Coordinating Xml-Defined Tasks, Method of Operating Such a Radio Base Station, and Corresponding Computer Program Product
FR2864871A1 (fr) * 2004-01-06 2005-07-08 Thomson Licensing Sa Methode de decouverte d'un reseau domestique et appareil implementant la methode
US7484220B2 (en) * 2004-05-26 2009-01-27 Qualcomm Incorporated Method, software and apparatus for using application state history information when re-launching applications
US7779410B2 (en) * 2004-12-17 2010-08-17 Sap Ag Control interfaces for distributed system applications
CN100454836C (zh) * 2005-10-22 2009-01-21 华为技术有限公司 一种业务跟踪的方法和系统
WO2007124507A2 (en) * 2006-04-21 2007-11-01 Topia Technology Integration of disparate applications on a network
US9043391B2 (en) 2007-02-15 2015-05-26 Citrix Systems, Inc. Capturing and restoring session state of a machine without using memory images
US20080201414A1 (en) 2007-02-15 2008-08-21 Amir Husain Syed M Transferring a Virtual Machine from a Remote Server Computer for Local Execution by a Client Computer
US20120011509A1 (en) * 2007-02-15 2012-01-12 Syed Mohammad Amir Husain Migrating Session State of a Machine Without Using Memory Images
US9014973B2 (en) * 2007-02-23 2015-04-21 At&T Intellectual Property I, L.P. Methods for obtaining a navigation track between a first and a second location at a client device using location information obtained from a server device and related devices and computer program products
US20080300898A1 (en) * 2007-05-30 2008-12-04 Belkacem Bacha Document processing services
US8301726B2 (en) * 2007-12-21 2012-10-30 International Business Machines Corporation Method and system for bit streaming for data centric applications
US7882120B2 (en) * 2008-01-14 2011-02-01 Microsoft Corporation Data description language for record based systems
US20090276795A1 (en) * 2008-04-30 2009-11-05 Microsoft Corporation Virtual automata
US9455992B2 (en) * 2009-06-12 2016-09-27 Microsoft Technology Licensing, Llc Trusted hardware component for distributed systems
US8782434B1 (en) 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time
US20130145281A1 (en) * 2010-08-17 2013-06-06 Qianqian Sun Data sending and receiving system related to touch screen
US9268578B2 (en) * 2010-11-05 2016-02-23 Mark Cummings Integrated circuit design and operation for determining a mutually compatible set of configuration for cores using agents associated with each core to achieve an application-related objective
US8667490B1 (en) * 2011-07-29 2014-03-04 Emc Corporation Active/active storage and virtual machine mobility over asynchronous distances
US9507630B2 (en) 2012-02-09 2016-11-29 Cisco Technology, Inc. Application context transfer for distributed computing resources
US8694961B2 (en) * 2012-04-03 2014-04-08 Microsoft Corporation Thread-agile execution of dynamic programming language programs
WO2014016695A2 (en) * 2012-07-27 2014-01-30 Assa Abloy Ab Presence-based credential updating
US9122873B2 (en) 2012-09-14 2015-09-01 The Research Foundation For The State University Of New York Continuous run-time validation of program execution: a practical approach
US9069782B2 (en) 2012-10-01 2015-06-30 The Research Foundation For The State University Of New York System and method for security and privacy aware virtual machine checkpointing
US9215075B1 (en) 2013-03-15 2015-12-15 Poltorak Technologies Llc System and method for secure relayed communications from an implantable medical device
US9483997B2 (en) 2014-03-10 2016-11-01 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using infrared signaling
US9696414B2 (en) 2014-05-15 2017-07-04 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using sonic signaling
US10070291B2 (en) 2014-05-19 2018-09-04 Sony Corporation Proximity detection of candidate companion display device in same room as primary display using low energy bluetooth
CN107077358B (zh) * 2014-09-25 2020-08-25 甲骨文国际公司 用于在分布式计算环境中支持可执行代码的动态部署的系统和方法
US9934019B1 (en) * 2014-12-16 2018-04-03 Amazon Technologies, Inc. Application function conversion to a service
US10116658B2 (en) * 2015-04-29 2018-10-30 Cyberark Software Ltd. Privileged access to target services
US10129361B2 (en) 2015-07-01 2018-11-13 Oracle International Corporation System and method for multi-version remote function execution control in a distributed computing environment
FR3043814B1 (fr) * 2015-11-18 2020-01-10 Bull Sas Procede de generation d'un ensemble de donnees definissant un message pour une application contrainte
US10606573B2 (en) * 2017-06-07 2020-03-31 Syntel, Inc. System and method for computer language migration using a re-architecture tool for decomposing a legacy system and recomposing a modernized system
KR102066870B1 (ko) * 2019-07-18 2020-02-11 주식회사 이글루시스템즈 사용자　패턴 학습에 기반한 동기화 시스템
US11249821B1 (en) * 2021-04-07 2022-02-15 Microsoft Technology Licensing, Llc Cross-platform context activation

Family Cites Families (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491946A (en) 1981-03-09 1985-01-01 Gould Inc. Multi-station token pass communication system
JPH0640302B2 (ja) 1984-01-30 1994-05-25 株式会社日立製作所 図式・ソ−スプログラム自動生成方法
US4823122A (en) 1984-06-01 1989-04-18 Digital Equipment Corporation Local area network for digital data processing system
US4809160A (en) 1985-10-28 1989-02-28 Hewlett-Packard Company Privilege level checking instruction for implementing a secure hierarchical computer system
US4713806A (en) 1986-03-14 1987-12-15 American Telephone And Telegraph Company, At&T Bell Laboratories Communication system control arrangement
US4939638A (en) 1988-02-23 1990-07-03 Stellar Computer Inc. Time sliced vector processing
US5287511A (en) 1988-07-11 1994-02-15 Star Semiconductor Corporation Architectures and methods for dividing processing tasks into tasks for a programmable real time signal processor and tasks for a decision making microprocessor interfacing therewith
US5133075A (en) 1988-12-19 1992-07-21 Hewlett-Packard Company Method of monitoring changes in attribute values of object in an object-oriented database
US5109486A (en) 1989-01-06 1992-04-28 Motorola, Inc. Distributed computer system with network and resource status monitoring
US5088036A (en) 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
US5297283A (en) 1989-06-29 1994-03-22 Digital Equipment Corporation Object transferring system and method in an object based computer operating system
US5257369A (en) 1990-10-22 1993-10-26 Skeen Marion D Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5187787B1 (en) 1989-07-27 1996-05-07 Teknekron Software Systems Inc Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5218699A (en) 1989-08-24 1993-06-08 International Business Machines Corporation Remote procedure calls in heterogeneous systems
CA2047737A1 (en) 1989-12-26 1991-06-27 Shigeru Aoe Object oriented distributed processing system
GB2242293A (en) 1990-01-05 1991-09-25 Apple Computer Apparatus and method for dynamic linking of computer software components
AU628753B2 (en) 1990-08-14 1992-09-17 Digital Equipment Corporation Method and apparatus for implementing server functions in a distributed heterogeneous environment
EP0737921B1 (de) 1990-09-17 2000-06-28 Cabletron Systems, Inc. System und Verfahren zur Modellierung eines Computer-Netzwerks
EP0501610B1 (de) 1991-02-25 1999-03-17 Hewlett-Packard Company Objektorientiertes verteiltes Rechnersystem
EP0501613A3 (en) 1991-02-28 1993-09-01 Hewlett-Packard Company Heterogeneous software configuration management apparatus
US5293614A (en) 1991-04-08 1994-03-08 Texas Instruments Incorporated System and method for hard real-time garbage collection requiring a write barrier but no read barrier
US5481721A (en) 1991-07-17 1996-01-02 Next Computer, Inc. Method for providing automatic and dynamic translation of object oriented programming language-based message passing into operation system message passing using proxy objects
DE4131380A1 (de) 1991-09-20 1993-03-25 Siemens Ag Verfahren zur adaption einer objektorientierten applikation
US5390328A (en) 1992-03-30 1995-02-14 International Business Machines Corporation Data processing system and method for providing notification in a central processor of state changes for shared data structure on external storage
US5412717A (en) 1992-05-15 1995-05-02 Fischer; Addison M. Computer system security method and apparatus having program authorization information data structures
KR100287045B1 (ko) 1992-07-06 2001-04-16 존 비. 메이슨 객체의 명명 및 결합들 위한 방법 및 시스템
US5307490A (en) 1992-08-28 1994-04-26 Tandem Computers, Inc. Method and system for implementing remote procedure calls in a distributed computer system
JP2524472B2 (ja) 1992-09-21 1996-08-14 インターナショナル・ビジネス・マシーンズ・コーポレイション 電話回線利用の音声認識システムを訓練する方法
US5423042A (en) 1992-10-23 1995-06-06 International Business Machines Corporation Remote procedure execution
US5561785A (en) 1992-10-29 1996-10-01 International Business Machines Corporation System for allocating and returning storage and collecting garbage using subpool of available blocks
US5515536A (en) 1992-11-13 1996-05-07 Microsoft Corporation Method and system for invoking methods of an object through a dispatching interface
EP0669020B1 (de) 1992-11-13 1997-04-02 Microsoft Corporation Verfahren zur verteilung von schnittstellenzeigern fur fernprozeduranrufe
US5386568A (en) 1992-12-01 1995-01-31 Yamaha Corporation Apparatus and method for linking software modules
EP0602263A1 (de) 1992-12-15 1994-06-22 International Business Machines Corporation Programmgenerator für Benutzerschnittstelle
US5560003A (en) 1992-12-21 1996-09-24 Iowa State University Research Foundation, Inc. System and hardware module for incremental real time garbage collection and memory management
US5452459A (en) 1993-01-08 1995-09-19 Digital Equipment Corporation Method and apparatus for allocating server access in a distributed computing environment
EP0613083B1 (de) 1993-02-25 2002-01-23 Sun Microsystems, Inc. Transaktionsverwaltung in objektorientiertem System
US5832593A (en) 1993-04-14 1998-11-10 Minnesota Mining And Manufacturing Company Splice head for insulated telecommunication wires
US5603031A (en) 1993-07-08 1997-02-11 General Magic, Inc. System and method for distributed computation based upon the movement, execution, and interaction of processes in a network
US5844553A (en) 1993-08-30 1998-12-01 Hewlett-Packard Company Mechanism to control and use window events among applications in concurrent computing
US5617537A (en) 1993-10-05 1997-04-01 Nippon Telegraph And Telephone Corporation Message passing system for distributed shared memory multiprocessor system and message passing method using the same
US5455952A (en) 1993-11-03 1995-10-03 Cardinal Vision, Inc. Method of computing based on networks of dependent objects
US5742848A (en) 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5581704A (en) 1993-12-06 1996-12-03 Panasonic Technologies, Inc. System for maintaining data coherency in cache memory by periodically broadcasting invalidation reports from server to client
US5594921A (en) 1993-12-17 1997-01-14 Object Technology Licensing Corp. Authentication of users with dynamically configurable protocol stack
AU1522095A (en) 1994-01-05 1995-08-01 Peter J. Covey Dynamic-state, multi-dimensional, multi-media database
US5832219A (en) 1994-02-08 1998-11-03 Object Technology Licensing Corp. Distributed object networking service
US5675796A (en) 1994-04-08 1997-10-07 Microsoft Corporation Concurrency management component for use by a computer program during the transfer of a message
US5680617A (en) 1994-05-16 1997-10-21 Apple Computer, Inc. Computer-human interface which provides for user customization of object behavior
EP0684553B1 (de) 1994-05-26 2004-06-16 Sun Microsystems, Inc. Verfahren und Gerät zur Erzeugung und Verwendung kurzer Operationsidentifizierer in objektorientierten Systemen
US5655148A (en) 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5680573A (en) 1994-07-12 1997-10-21 Sybase, Inc. Method of buffering data objects in a database
US5778228A (en) 1994-08-16 1998-07-07 International Business Machines Corporation Method and system for transferring remote procedure calls and responses over a network
US5555367A (en) 1994-09-30 1996-09-10 General Electric Company Method and system for generating computer programs for queries formed by manipulating object-oriented diagrams
JP4058118B2 (ja) 1994-11-15 2008-03-05 株式会社日立製作所 プログラム生成システム及び方法
US5577231A (en) 1994-12-06 1996-11-19 International Business Machines Corporation Storage access authorization controls in a computer system using dynamic translation of large addresses
US5553282A (en) 1994-12-09 1996-09-03 Taligent, Inc. Software project history database and method of operation
US5644768A (en) 1994-12-09 1997-07-01 Borland International, Inc. Systems and methods for sharing resources in a multi-user environment
EP0717337B1 (de) 1994-12-13 2001-08-01 International Business Machines Corporation Verfahren und System zur gesicherten Programmenverteilung
US5889988A (en) * 1995-01-03 1999-03-30 Intel Corporation Debugger for debugging tasks in an operating system virtual device driver
US5872928A (en) 1995-02-24 1999-02-16 Cabletron Systems, Inc. Method and apparatus for defining and enforcing policies for configuration management in communications networks
US5628005A (en) 1995-06-07 1997-05-06 Microsoft Corporation System and method for providing opportunistic file access in a network environment
US5761656A (en) 1995-06-26 1998-06-02 Netdynamics, Inc. Interaction between databases and graphical user interfaces
US5802367A (en) 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
US5745703A (en) 1995-07-18 1998-04-28 Nec Research Institute, Inc. Transmission of higher-order objects across a network of heterogeneous machines
US5774551A (en) 1995-08-07 1998-06-30 Sun Microsystems, Inc. Pluggable account management interface with unified login and logout and multiple user authentication services
JP2964926B2 (ja) 1995-08-29 1999-10-18 富士ゼロックス株式会社 データベース管理装置及び方法
US5671225A (en) 1995-09-01 1997-09-23 Digital Equipment Corporation Distributed interactive multimedia service system
US5737607A (en) 1995-09-28 1998-04-07 Sun Microsystems, Inc. Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats
US5864862A (en) 1996-09-30 1999-01-26 Telefonaktiebolaget Lm Ericsson (Publ) System and method for creating reusable components in an object-oriented programming environment
US5872973A (en) 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5860153A (en) 1995-11-22 1999-01-12 Sun Microsystems, Inc. Memory efficient directory coherency maintenance
US5745695A (en) 1996-01-16 1998-04-28 Motorola Inc. Radio system with suspension of packet data service during non-data service connection
US5754849A (en) 1996-01-30 1998-05-19 Wayfarer Communications, Inc. Self-describing object providing dynamic manipulation of heterogeneous data values and semantic identity between memory and transmission representations
US5845129A (en) 1996-03-22 1998-12-01 Philips Electronics North America Corporation Protection domains in a single address space
US5706502A (en) 1996-03-25 1998-01-06 Sun Microsystems, Inc. Internet-enabled portfolio manager system and method
US5790548A (en) 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
US5815709A (en) 1996-04-23 1998-09-29 San Microsystems, Inc. System and method for generating identifiers for uniquely identifying object types for objects used in processing of object-oriented programs and the like
US5778368A (en) 1996-05-03 1998-07-07 Telogy Networks, Inc. Real-time embedded software respository with attribute searching apparatus and method
US5778187A (en) 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US5835737A (en) 1996-05-10 1998-11-10 Apple Computer, Inc. Method and apparatus for arbitrating access to selected computer system devices
US5813013A (en) 1996-06-06 1998-09-22 Microsoft Corporation Representing recurring events
US5768532A (en) 1996-06-17 1998-06-16 International Business Machines Corporation Method and distributed database file system for implementing self-describing distributed file objects
US5727145A (en) 1996-06-26 1998-03-10 Sun Microsystems, Inc. Mechanism for locating objects in a secure fashion
US5809507A (en) 1996-07-01 1998-09-15 Sun Microsystems, Inc. Method and apparatus for storing persistent objects on a distributed object network using a marshaling framework
US5748897A (en) 1996-07-02 1998-05-05 Sun Microsystems, Inc. Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer
US5818448A (en) 1996-07-02 1998-10-06 Sun Microsystems, Inc. Apparatus and method for identifying server computer aggregation topologies
US5860004A (en) 1996-07-03 1999-01-12 Sun Microsystems, Inc. Code generator for applications in distributed object systems
US5757925A (en) 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US5875335A (en) 1996-09-30 1999-02-23 Apple Computer, Inc. Parameter marshaling techniques for dynamic object-oriented programming languages
US5787425A (en) 1996-10-01 1998-07-28 International Business Machines Corporation Object-oriented data mining framework mechanism
US5832529A (en) 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
US5884024A (en) 1996-12-09 1999-03-16 Sun Microsystems, Inc. Secure DHCP server
US5787431A (en) 1996-12-16 1998-07-28 Borland International, Inc. Database development system with methods for java-string reference lookups of column names
US5854897A (en) * 1996-12-27 1998-12-29 Quantum Systems, Inc. Network communications marketing system
US5815149A (en) 1997-02-19 1998-09-29 Unisys Corp. Method for generating code for modifying existing event routines for controls on a form
US5864866A (en) 1997-03-26 1999-01-26 International Business Machines Corporation Apparatus and method for providing externalization in an object-oriented environment
US5808911A (en) 1997-06-19 1998-09-15 Sun Microsystems, Inc. System and method for remote object resource management
US5878411A (en) 1997-06-27 1999-03-02 International Business Machines Corporation Dependent object class and subclass mapping to relational data store
GB2332288A (en) * 1997-12-10 1999-06-16 Northern Telecom Ltd agent enabling technology
US6496871B1 (en) * 1998-06-30 2002-12-17 Nec Research Institute, Inc. Distributed agent software system and method having enhanced process mobility and communication in a computer network
US6125391A (en) * 1998-10-16 2000-09-26 Commerce One, Inc. Market makers using documents for commerce in trading partner networks
US6668271B1 (en) * 1999-05-19 2003-12-23 Richo Company, Ltd. System for distributing, installing and running web applications (agents)
US6594700B1 (en) * 1999-06-14 2003-07-15 International Business Machines Corporation System and method for implementing a universal service broker interchange mechanism
US6574655B1 (en) * 1999-06-29 2003-06-03 Thomson Licensing Sa Associative management of multimedia assets and associated resources using multi-domain agent-based communication between heterogeneous peers
US6763334B1 (en) * 1999-12-09 2004-07-13 Action Click Co., Ltd. System and method of arranging delivery of advertisements over a network such as the internet
US6854120B1 (en) * 2000-01-14 2005-02-08 International Business Machines Corporation Accessing a ERP application over the internet using strongly typed declarative language files
JP2003529825A (ja) * 2000-02-14 2003-10-07 ジオフェニックス， インコーポレイテッド グラフィカルプログラミングのための方法およびシステム

Also Published As

Publication number Publication date
EP1309915B1 (de) 2004-03-10
DE60102305D1 (de) 2004-04-15
EP1309915A2 (de) 2003-05-14
US7200848B1 (en) 2007-04-03
WO2001086440A2 (en) 2001-11-15
AU2001261386A1 (en) 2001-11-20
JP2003534588A (ja) 2003-11-18
WO2001086440A3 (en) 2003-03-13
ATE261596T1 (de) 2004-03-15

Similar Documents

Publication Publication Date Title
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
DE60123289T2 (de) Ereignisnachricht-endstelle in einer verteilten rechnerumgebung
DE60104678T2 (de) Mechanismus und vorrichtung um dienst-ergebnissen einer verteilten rechnerumgebung zurückzuliefern
DE60102234T2 (de) Verfahren und vorrichtung zur ermittlung von benachbarten diensten
US6970869B1 (en) Method and apparatus to discover services and negotiate capabilities
US9110711B2 (en) Dynamic displays in a distributed computing environment
US7716492B1 (en) Method and apparatus to obtain service capability credentials
US7412518B1 (en) Method and apparatus for proximity discovery of services
US6792466B1 (en) Trusted construction of message endpoints in a distributed computing environment
US6862594B1 (en) Method and apparatus to discover services using flexible search criteria
US7072967B1 (en) Efficient construction of message endpoints
US6789126B1 (en) Addressing message gates in a distributed computing environment
US6643650B1 (en) Mechanism and apparatus for using messages to look up documents stored in spaces in a distributed computing environment
US6950875B1 (en) Message conductors in a distributed computing environment
US7395333B1 (en) Method and apparatus to obtain negotiated service advertisement
US7010573B1 (en) Message gates using a shared transport in a distributed computing environment
US7370091B1 (en) Method and apparatus for obtaining space advertisements
WO2001086428A2 (en) Mechanism and apparatus for uri-addressable repositories of service advertisements and other content in a distributed computing environment
JP2004504657A (ja) 分散コンピューティング環境でのセキュア・メッセージングを用いるリモート・メソッド・コール
WO2001086487A2 (en) Mechanism and apparatus for web-based searching of uri-addressable repositories in a distributed computing environment
WO2001086421A2 (en) Message gates in a distributed computing environment
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

Legal Events

Date Code Title Description
8364 No opposition during term of opposition