-
Die
vorliegende Erfindung betrifft eine Vorrichtung und ein Verfahren
zum Sharing von Diensten auf einem Netzwerk und im Besonderen, jedoch
nicht ausschließlich
ein Verfahren zum Sharing und Verwalten von Diensten zwischen jeder
Netzwerkvorrichtung.
-
Mit
dem schnellen Fortschritt der Digitaltechnologie und der schnellen
Zunahme der Popularität des
Internets wird die Infrastruktur von digitalen Heimen entwickelt,
um mannigfaltige Dienste bereitzustellen, die für das tägliche Leben von Verbrauchern hilfreich
und nützlich
sind, indem derartige Fortschritte genutzt werden. Die digitale
Heimtechnologie zielt darauf ab, qualitativ hochwertige Dienste
bereitzustellen, indem gut ausgestattete externe Kommunikationsinfrastrukturen
genutzt werden, die komplexer sind als die einfacheren Heimnetzwerke.
-
Man
kann sagen, dass das digitale Heim ein neues Paradigma des Kultivierens
neuer Dienstmärkte
durch Integrieren verschiedener ITs (Informationstechnologien) ist
wie beispielsweise Heimnetzwerk-Technologie, elektronische Informationsanwendungstechnologie,
Software-Plattformen, Lösungen und
Inhalte.
-
Die
Terminologie in Bezug auf das Heim der Zukunft mit der Heim-Netzwerkinfrastruktur
kann durch die folgenden Ausführungen
beispielhaft dargestellt werden: vernetztes Heim, mitdenkendes Heim,
digitales Heim und so fort. Während
die Nutzung vieler Teile ein gemeinsames Konzept bei jeder Infrastruktur
ist, legt das vernetzte Heim besonderes Gewicht auf die Verbindung
der im Heim befindlichen digitalen Geräte. Insbesondere legt das mitdenkende Heim
besonders viel Gewicht auf Heimautomatisierungsdienste, die in der
Lage sind, im Heim befindliche, digitale Geräte lokal oder entfernt zu steuern/zu verwalten.
Im Gegensatz dazu legt das digitale Heim Gewicht auf das Sharing
(die gemeinsame Nutzung) digitaler Multimedia wie beispielsweise
Musik, Bilder, Video und so weiter, und stellt digitale Inhaltsdienste in
Zusammenarbeit mit dem Internet bereit.
-
Zum
Aufbau des digitalen Heims sind verschiedene Technologien von Heimnetzwerken,
Zugangsnetzwerke, Inhalte und Lösungen
erforderlich.
-
Die
Technologie der Heimnetzwerke umfasst kabelgebundene/kabellose Netzwerktechnologie
wie beispielsweise die Übermittlung
von Daten übers Stromnetz
(power line communication – PLC), Übermittlung
von Daten über
die Telefonleitung, kabelgebundenes LAN (local area network), IEEE1394, drahtloses
LAN, drahtloses 1394 und so fort; Middleware-Technologie wie beispielsweise HAVi
(Home Audio Video Interoperability – Interoperabilität im Heim
zwischen Audio und Video), Jini (Java intelligent Network Infra-structure – intelligente
Netzwerk-Infrastruktur mit Java), UPnP (Universal Plug and Play – Universelle,
sofort betriebsbereite Systeme) und so weiter, die eine Sofort-Betriebsbereit-Funktion
unterstützen;
Heim- oder Haushalts-Gateway-Technologie zum Bereitstellen eines externen
Zugangsnetzwerkes mit einer Netzanschlussfunktion sowie einer Modemfunktion
und zum Bereitstellen einer Funktion für die Zusammenarbeit der Netzwerke;
sowie Dienstplattform-Technologie zum
Senden und Verwalten mehrerer Dienste an elektronische Informationsgeräte, die über ein
Zugangsnetzwerk an einem entfernten Standort mit Heimnetzwerken
verbunden sind.
-
Hier
ist ein Beispiel einer digitalen Heimdienstplattform eine OSGi (Open
Services Gateway Initiative)-Dienstplattform.
-
Die
Bezeichnung OSGi ist die Abkürzung
für "Open Services Gateway
Initiative". Die
OSGi war eine gemeinnützige
Standardisierungsorganisation, die von 15 in der Industrie führenden
Unternehmen im März
1999 gebildet wurde, darunter Ericsson, Sun Microsystems und IBM,
und darauf abzielte, einen offenen Standard zu schaffen, mit dem
verschiedene Dienste in dem Netzwerk an lokale Netzwerke oder Geräte geliefert
und die gelieferten Dienste betrieben werden.
-
Die
OSGi definiert sowohl Rahmenbedingungen (ein Framework) für das Bereitstel-len/Verwalten von
Diensten als auch ein OSGi-Bündel (bundle).
Das OSGi-Bündel
ist eine Einheit, die hergestellt und eingebaut werden kann und
mit einer Schnittstelle, Konfigurationsinformationen, ausführbarem
Code und einer digitalen Signatur kombiniert wird.
-
Die
OSGi-Version 1.0 besteht aus Rahmenbedingungen, die auf dem OSGi-Standard
beruhen, einem Protokolldienst, einem HTTP-Dienst und einem Gerätemanager.
Die Rahmenbedingungen ermöglichen
es Anwendungsdiensten, eine Java-Virtuelle Maschine gemeinsam zu
nutzen, sie verwalten die Lebenszyklen von Bündeln, Java-Paketen, die Abhängigkeit
zwischen den Bündeln
und so weiter und besitzen Dienstregistrierungen (service re gistries)
für eine
Zusammenarbeit zwischen den Bündeln.
Der Protokolldienst stellt Dienste bereit, die innerhalb der Rahmenbedingungen
erzeugte Ereignisse schreiben und lesen können. Dem HTTP-Dienst ist es
gestattet, einen Zugriff auf Dienstplattformen über ein Netz bereitzustellen.
Der Gerätemanager stellt
ein Modell zum Herunterladen von dynamischen Gerätetreibern bereit.
-
In
der OSGi-Version 2, veröffentlicht
im Oktober 2001, werden zusätzlich
zu den Funktionen der Version 1 Dienste wie beispielsweise eine
Paketverwaltung, Genehmigungsverwaltung und Benutzerverwaltung bereitgestellt.
-
In
der OSGi-Version 3, veröffentlicht
im März 2003,
werden zusätzlich
zu den Funktionen der Version 2 Dienste wie beispielsweise Start-Level-Management,
Jini und UPnP bereitgestellt. Darüber hinaus werden viele Dienste
zu der OSGi-Version 3 hinzugefügt,
um einen Gateway für
ein Fahrzeug sowie einen Gateway für SOHO (Small Office Home Office – kleines
Büro oder
häusliches
Arbeitszimmer) zu unterstützen.
-
Die
OSGi-Dienstplattform konzentriert sich im Allgemeinen auf drei Bereiche:
erstens Verbindung und Steuerung zwischen den Diensten, zweitens
Verbindung und Steuerung zwischen dem Dienst und den OSGi-Rahmenbedingungen
und drittens Verbindung und Steuerung zwischen den OSGi-Rahmenbedingungen
und dem externen Dienstverwaltungssystem. Somit ist die OSGi-Dienstplattform
zwischen ein externes Netzwerk wie beispielsweise das Hochgeschwindigkeits-Netzwerk
und ein Netzwerk zum Verbinden von im Heim befindlichen Geräten zwischengeschaltet.
-
In
der externen Netzwerkumgebung führt
ein Dienstanbieter die Dienstbereitstellung und -verwaltung durch.
in der im Heim befindlichen Netzwerkumgebung müssen sich zahlreiche Geräte und unterschiedliche
Protokolle reibungslos miteinander verbinden und sich selbst und
einander steuern. Die OSGi-Dienstplattform ist schlussendlich ein
Vermittler für
die externen und die im Heim befindlichen Netzwerkumgebungen.
-
Der
OSGi-Standard wurde erschaffen, um auf Basis einer Java-Virtuellen
Maschine zu operieren. Die Java-Virtuelle Maschine fungiert als
Zwischenspeicher für
Unterschiede zwischen einem eingebetteten OS (Operating system – Betriebssystem) und
einer eingebetteten CPU (Central Processing Unit – Prozessor).
-
Alle
OSGi-Dienste sind in einem physikalischen Paket enthalten, das ein „Bündel" (bundle) genannt
wird.
-
Eine
Vielzahl von OSGi-Diensten kann in einem Bündel enthalten sein, das aus
einer Grundeinheit für
die Nutzbarmachung und Verwaltung von Bündeln besteht.
-
Die
Bündel
werden von den Rahmenbedingungen verwaltet. Die Rahmenbedingungen
besitzen eine Dienstregistrierung, die Registrierung, Anfrage, Ausführung, Löschung und
so weiter von Diensten durchführt.
Darüber
hinaus wickeln die Rahmenbedingungen Ereignisse, das Erkennen sowie
die Zähler-Verarbeitung
der Ereignisse ab. Hier ist das Ereignis ein logisches Ereignis,
das auf einer Erzeugungsvorrichtung (Generator) für drei Arten
von Ereignissen basiert: Dienst, Bündel und Rahmenbedingungen.
Das Ereignis ist logisch, unabhängig
von einem physikalischen, von den Geräten erzeugten Ereignis.
-
Mit
anderen Worten, man kann sagen, dass der OSGi-Standard eine Middleware
zum Einfügen, Steuern
und Verwalten verschiedener Vorrichtungen und Dienste in der Heimnetzwerk-Umgebung
ist. Der bis zum jetzigen Zeitpunkt entwickelte OSGi-Standard kann
auf Grund des Standortes eines einzelnen OSGi-Servers beschrieben
werden, und zwar, ob sich dieser entweder in dem Heim-Gateway befindet oder
ein einzelnes Gerät
in der Umgebung des physikalisch vernetzten Heim-Netzwerkes ist.
Somit werden alle Dienste im Ganzen verwaltet und die innerhalb
der OSGi-Rahmenbedingungen registrierten Vorrichtungen und Dienste
sind darin leicht verfügbar.
-
In 1 wird
ein Verfahren zum Betreiben von Bündeln unter herkömmlichen
OSGi-Rahmenbedingungen
dargestellt.
-
Die
OSGi-Rahmenbedingungen 100 und 150 registrieren
und verwalten die Bündel 120, 130, 170 und 180 durch
die Einrichtung der Bündelkontexte 110 und 160.
Jeder der Bündelkontexte 110 und 160 kann
so groß sein
wie die Anzahl der Bündel, und
somit wird eine Eins-zu-Eins-Mapping-Architektur erstellt. Jeder
Bündelkontext übernimmt
Funktionen des Installierens des Bündels und des Aufrufens von
Diensten, bearbeitet Ereignisse, die von den jeweiligen Rahmenbedingungen 100 und 150 erzeugt wurden,
und steuert Einzelheiten, die an der Ausführung des Bündels beteiligt sind.
-
Wie
in 1 dargestellt, wird das Bündel von den OSGi-Rahmenbedingungen
nicht ge meinsam genutzt. Daher muss das Bündel, das getrennt gewünscht wird,
innerhalb der Rahmenbedingungen selbst eingebaut und registriert
werden. Das getrennt gewünschte
Bündel
wird durch die Bündelkontexte 110 und 160 innerhalb
einer selbst ausführbaren
Umgebung aufgerufen und aktiviert. Selbst wenn es dieselbe Funktion
durchführt,
ist es dem identischen Bündel
nicht erlaubt, einen geeigneten Dienst bereitzustellen, bis es mit
seinen eigenen Rahmenbedingungen registriert ist. Wenn beispielsweise
das Bündel
C 180 erforderlich ist, um das Bündel B 130 in den Rahmenbedingungen
A 100 auszuführen,
nutzt der Stand der Technik die Ressource der Rahmenbedingungen
B 150 nicht. Folglich wird nach dem Stand der Technik das
Bündel
C 180 wiederholt in die Rahmenbedingungen A 100 installiert.
-
Da
der oben genannte Stand der Technik für die einzelnen OSGi-Rahmenbedingungen
konzipiert wurde, ist es unmöglich,
die gemeinsamen Dienste zwischen allen Rahmenbedingungen gemeinsam
zu nutzen, und daher muss jede Vorrichtung innerhalb ihrer eigenen
OSGi-Rahmenbedingungen wiederholt installiert und registriert werden.
Darüber
hinaus besteht in dem Fall eines Geschäftsmodells, das Leasing, Verkauf
und dergleichen von Diensten involviert, eine Unbequemlichkeit dahingehend,
das der Benutzer oder Leasingnehmer doppelt für jede Vorrichtung zahlen muss,
um denselben Dienst zu erhalten. Wenn darüber hinaus ein anderer Dienst,
der zum Bereitstellen eines von einer aktuellen Vorrichtung angeforderten
Dienstes benötigt
wird, innerhalb von OSGi-Rahmenbedingungen registriert und verwaltet
wird, die von einer anderen Vorrichtung ausgeführt werden, gibt es kein Verfahren,
bei dem die aktuelle Vorrichtung in der Lage wäre, entweder den Dienst zu
einer anderen Vorrichtung anzufordern oder den Dienst mit seinen
eigenen OSGi-Rahmenbedingungen zu registrieren. Aus diesem Grund
wird ein neues Verfahren zum Lösen
der Probleme benötigt.
-
Das
US-Patent Nummer 6430599
B1 offenbart leichte Eingrenzungs-Rahmenbedingungen, die gemeinsam
nutzbare Programmmodule unterstützen.
Die Eingrenzungs-Rahmenbedingungen
stellen Modulverwaltungsdienste wie beispielsweise Modulregistrierung,
Suche (lookup), Verfolgen von Instanzen (instance tracking) und
dergleichen zur Verfügung.
Der Basis-Funktionsblock kann durch Hinzufügen von Systemmodulen in die
Rahmenbedingungen erweitert werden.
-
In
dem Dokument Design and Implementation of the Home Networking Service
Agent Federation Using Open Service Gateway" (Feng-Chao Yang), Integration of Knowledge
Intensive Multi-Agent Systems, 2003, international Conference, wird
ein Dienstagenten- Gesellschaftsmechanismus
(service agent society mechanism) der Heimnetzwerk-Gemeinschaft durch
Verwenden einer OSGi-Plattform offenbart.
-
Gemäß der vorliegenden
Erfindung werden eine Vorrichtung und ein Verfahren bereitgestellt,
wie in den angehängten
Ansprüchen
dargelegt. Bevorzugte Eigenschaften der Erfindung sind aus den abhängigen Ansprüchen und
der folgenden Beschreibung ersichtlich.
-
Vorteilhafterweise
stellen Ausführungsformen
der vorliegenden Erfindung ein Verfahren zum Sharing und Recycling
(Wiederverwenden) von Ressourcen und Dienst-Bündeln bereit, die zwischen
einer Vielzahl von OSGi-Rahmenbedingungen benötigt werden, wenn jede der
Rahmenbedingungen an einer gesonderten Vorrichtung betrieben wird.
-
Für ein besseres
Verständnis
der Erfindung und zum Darlegen der Umsetzung ihrer Ausführungsformen
wird im Folgenden beispielhaft auf die beigefügten diagrammatischen Darstellungen
Bezug genommen, in denen:
-
in 1 ein
Verfahren zum Betreiben von Bündeln
unter herkömmlichen
OSGi-Rahmenbedingungen
dargestellt wird;
-
2 stellt
eine Gesamt-Modulstruktur in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung dar;
-
3 stellt
eine Konfiguration eines dynamischen entfernten Bündel-Laders
in Übereinstimmung mit
einer Ausführungsform
der vorliegenden Erfindung dar;
-
4 stellt
einen Betrieb zwischen unterschiedlichen dynamischen entfernten
Bündel-Ladern in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung dar; und
-
5 stellt
den Betrieb eines Gesamtsystems in Übereinstimmung mit einer Ausführungsform der
vorliegenden Erfindung dar;
-
6 stellt
ein Blockdiagramm einer Vorrichtung für das Sharing von Diensten
auf einem Netzwerk gemäß einer
beispielhaften Ausführungsform der
vorliegenden Erfindung dar.
-
Im
Folgenden werden eine Vorrichtung und ein Verfahren zum Sharing
von Diensten auf ei nem Netzwerk in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung in Bezug auf die angehängten Zeichnungen
beschrieben.
-
Für ein besseres
Verständnis
der vorliegenden Erfindung wird die vorliegende Erfindung mit einem
System auf Basis von OSGi-Rahmenbedingungen als ein Beispiel beschrieben,
sie kann jedoch auch auf Middleware mit einer Funktion ähnlich der der
OSGi-Rahmenbedingungen
angewendet werden.
-
2 stellt
eine Gesamt-Modulstruktur in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung dar.
-
Eine
lokale Vorrichtung 200 umfasst Rahmenbedingungen 205,
Bündelkontexte 220 und 222, Bündel 230 und 232,
Dienste 240, 242, 244 und 246, die
zu den jeweiligen Bündeln
gehören,
sowie einen dynamischen entfernten Bündel-Lader 210. Gleichermaßen umfasst
eine entfernte Vorrichtung 250 Rahmenbedingungen 255,
Bündelkontexte 270 und 272, Bündel 280 und 282,
Dienste 290, 292 und 294, die zu den
jeweiligen Bündeln
gehören,
sowie einen dynamischen entfernten Bündel-Lader 260. Hier
stellt jedes Modul die folgende Funktion dar.
-
Die
beiden Rahmenbedingungen 205 und 255 stehen für OSGi-Rahmenbedingungen.
Im Folgenden werden die Rahmenbedingungen der Vorrichtung, die das
Bündel
anfordert, „lokale
Rahmenbedingungen" genannt,
während
die Rahmenbedingungen der Vorrichtung, die die Anforderung des Bündels empfängt, „entfernte
Rahmenbedingungen" genannt
werden.
-
Jeder
der lokalen Bündelkontexte 220 und 222 ist
ein Modul, das die Installation und Registrierung der Bündel, den
Aufruf der Dienste und so weiter in den lokalen Rahmenbedingungen 205 verwaltet,
mit denen die Bündel
und Dienste, die aktuell ausgeführt
werden, registriert sind. Jeder lokale Bündelkontext überprüft, ob das
von dem aktuell ausgeführten
Dienst angeforderte Bündel
registriert ist oder nicht. Wenn sich das angeforderte Bündel bereits
in den aktuellen lokalen Rahmenbedingungen 205 befunden
hat, sendet jeder lokale Bündelkontext
einen Referenzstandort dieses Bündels,
der innerhalb der lokalen Vorrichtung 200 existiert. Wenn
jedoch das angeforderte Bündel
aktuell nicht in den lokalen Rahmenbedingungen 205 registriert
ist, benachrichtigt der lokale Bündelkontext
den dynamischen entfernten Bündel-Lader 210,
dass der lokale Bündelkontext selbst
das angeforderte Bündel
anfordert, und wartet die Antwort ab.
-
Die
entfernten Bündelkontexte 270 und 272 überprüfen eine
Liste von mit der entfernten Vorrichtung 250 registrierten
Bündeln
gemäß einer
Anforderung des Bündels,
das von dem dynamischen entfernten Bündel-Lader 260 auf
der entfernten Seite der Rahmenbedingungen empfangen wurde. Wenn dann
bestätigt
wurde, dass das dem angeforderten Bündel entsprechende Bündel vorliegt,
sendet jeder entfernte Bündelkontext
einen Referenzstandort von diesem Bündel an den dynamischen entfernten
Bündel-Lader 210 der
lokalen Vorrichtung 200.
-
Jedes
der Bündel 230, 232, 280 und 282 ist ein
Paket von einem oder mehreren zugehörigen Diensten, die eine Reihe
von Diensten genannt werden können.
Hier werden die Dienste zwischen allen Vorrichtungen in einer Bündeleinheit
gemeinsam genutzt.
-
Jeder
der dynamischen entfernten Bündel-Lader 210 und 260 ist
ein Modul, das eine Anforderung der Bündel und seiner Antwortfunktionen durch
Austauschen von Mitteilungen mit den Bündelkontexten 220, 222, 270 und 272 durchführt. Auf
der Seite der lokalen Vorrichtung 200 des Anforderns der Bündel wird
eine Spezifizierung über
die Bündel
mit jeder der Anforderungen der Bündelkontexte 220 und 222 an
die entfernte Vorrichtung 250 gesendet. Auf der Seite der
entfernten Vorrichtung 250 werden die Bündel an die lokale Vorrichtung 200 gesendet,
die von den Bündelkontexten 270 und 272 bereitgestellt wurden.
-
3 stellt
eine Konfiguration eines dynamischen entfernten Bündel-Laders
in Übereinstimmung mit
einer Ausführungsform
der vorliegenden Erfindung dar.
-
Ein
dynamischer entfernter Bündel-Lader 300 umfasst
eine Bündelsende-/-empfangseinheit 310,
eine Bündel-Analyseeinheit
(bundle parsing unit) 320, einen Bündel-Lader 330 sowie
einen Bündel-Entlader 340.
Alternativ können
der Bündel-Lader 330 und
der Bündel-Entlader 340 ein
einziges Modul sein. Die folgende Beschreibung erfolgt hinsichtlich
der Funktionen der Komponenten des dynamischen entfernten Bündel-Laders 300.
-
Die
Bündelsende-/-empfangseinheit 310 ist eine
Einheit, die das Senden von Mitteilungen, das Anfordern von Bündeln oder
das Senden/Empfangen der angeforderten Bündel übernimmt. Die Nachricht, die
das Bündel
anfordert, wird mit Multicast über
den gesamten Bereich gesendet, der über das Heimnetzwerk verbunden
ist. In den Rahmenbedingungen einer anderen Vorrichtung, die die
angeforderte Nachricht empfängt,
wird überprüft, ob das
angeforderte Bündel
enthalten ist oder nicht, und als eine Antwort auf die Anforderung
wird das enthaltene Bündel selbst über einen
HTTP-Dienst an die Bündelsende-/-empfangseinheit der
Vorrichtung gesendet, die das Bündel
angefordert hat. Die Vorrichtung auf der Anforderungsseite empfängt das
gesendete Bündel und
führt die
Installation und Registrierung des empfangen Bündels in seinen eigenen Rahmenbedingungen
durch. Die Bündelsende-/-empfangseinheit 310 kann
ein Bündel-Multicast-Sendemodul
(nicht dargestellt) sowie ein Bündel-Multicast-Empfangsmodul (nicht
dargestellt) umfassen, wobei das Bündel-Multicast-Sendemodul das
Senden einer Anforderungsnachricht der Vorrichtung, die das Bündel anfordert, sowie
das Senden des Bündels
der Vorrichtung übernimmt,
die die Anforderung des Bündels
empfängt, während die
Bündel-Multicast-Empfangsmodul
den Empfang der Anforderungsnachricht von der Anforderungsseite
sowie des Bündels
von der Antwortseite sicherstellt.
-
Die
Bündel-Analyseeinheit 320 überprüft die Spezifizierung
des angeforderten Bündels
und fordert den Bündelkontext
an, das Bündel
zu suchen, das der Spezifizierung des angeforderten Bündels entspricht
und das in der Rahmenbedingungs-Umgebung der Vorrichtung, die das
Bündel
anfordert, ordnungsgemäß implementiert
werden kann. Da es möglich
ist, dass das angeforderte Bündel
nicht in der Vorrichtung implementiert ist, die das Bündel gemäß einem
Betriebssystem anfordert, bei dem die Rahmenbedingungen sowie eine
Systemressource betrieben werden, wird ein Prozess benötigt, der
die Spezifizierung des angeforderten Bündels überprüft. Darüber hinaus sendet die Bündel-Analyseeinheit 320 einen
Referenzstandort des gesuchten Bündels an
die Bündelsende-/-empfangseinheit 310,
um zu ermöglichen,
dass das Bündel
gesendet wird.
-
Der
Bündel-Lader 330 ist
ein Modul zum Installieren und Registrieren des empfangenen Bündels innerhalb
der Rahmenbedingungen. Wenn das Bündel mit den Rahmenbedingungen
registriert ist, wird das registrierte Bündel in Bezug auf den Dienst implementiert,
der das Bündel
angefordert hat.
-
Wenn
das implementierte Bündel
immer noch in den Rahmenbedingungen bleibt, besteht die Möglichkeit,
dass es ein Problem hervorruft, da es eine unerwartete Systemressource
belegt. Daher wird das Bündel,
das seine Aufgabe erfüllt
hat, aus den Rahmenbedingungen wieder entfernt und vollständig aus
einem Speicher gelöscht,
und daher müssen
die Rahmenbedingungen wieder in ihren ursprünglichen Zustand gebracht werden,
der bestand, als das Bündel
angefordert wurde. Diese Funktion wird von dem Bündel-Entlader 340 durchgeführt. Hier kann
das Bündel
aus den Rahmenbedingungen entfernt werden, sobald seine Aufgabe
erfüllt
ist, es ist jedoch möglich,
das Bündel
unter der gewünschten Bedingung
oder eine vorgegebene Zeitdauer entsprechend der Systemressource
in den Rahmenbedingungen zu behalten.
-
4 stellt
einen Betrieb zwischen unterschiedlichen dynamischen entfernten
Bündel-Ladern in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung dar.
-
Ein
dynamischer entfernter Bündel-Lader
A (400) fordert sein eigenes erforderliches Bündel in
einer Multicast-Art hinsichtlich anderer dynamischer entfernter
Bündel-Lader
B, C und D (410, 420 und 430) jeder Vorrichtung
an, die über
ein Netzwerk (450) miteinander verbunden sind. Jeder der
dynamischen entfernten Bündel-Lader
B, C und D (410, 420 und 430) überprüft jeweils,
ob er das angeforderte Bündel
enthält
oder nicht, und anschließend,
wenn das angeforderte Bündel
vorliegt, analysiert er, ob das angeforderte Bündel geeignet ist, um an dem
dynamischen entfernten Bündel-Lader
A (400) implementiert zu werden, der das Bündel (452)
angefordert hat. Aus diesem Grund sind Informationen über das
System, in dem der dynamische entfernte Bündel-Lader A (400)
betrieben wird, in der Anforderungsnachricht enthalten, wenn die
Anforderungsnachricht gesendet wird.
-
In
diesem Fall befindet sich der dynamische entfernte Bündel-Lader
A (400) in einem Wartezustand, bis eine Antwort von den
anderen dynamischen entfernten Bündel-Ladern
B, C und D (410, 420 und 430) erfolgt
ist (454).
-
Unter
den anderen dynamischen entfernten Bündel-Ladern B, C und D (410, 420 und 430)
sendet derjenige dynamische entfernte Bündel-Lader, der das Bündel enthält, das
dem angeforderten Bündel angepasst
ist, das angepasste Bündel
als Antwort an den dynamischen entfernten Bündel-Lader A (400). In
diesem Fall empfängt
der dynamische entfernte Bündel-Lader A (400)
die erste gesendete Antwort (456), vernachlässigt jedoch
die folgenden (458 und 460).
-
Beim
Empfangen des angeforderten Bündels
registriert der dynamische entfernte Bündel-Lader A (400) das empfangene
Bündel
(462). Anschließend
implementiert der dynamische entfernte Bündel-Lader A (400)
den Dienst, nutzt dazu das registrierte Bündel (464) und löscht das
registrierte Bündel im
Register, wenn die Implementierung des Dienstes abgeschlossen ist
(466).
-
5 stellt
den Betrieb eines Gesamtsystems in Übereinstimmung mit einer Ausführungsform der
vorliegenden Erfindung dar.
-
In 5 sind
eine lokale Vorrichtungsseite und eine entfernte Vorrichtungsseite
voneinander durch eine fette Punktlinie getrennt, die der Länge nach
zwischen einem dynamischen entfernten Bündel-Lader A (520)
und einem dynamischen entfernten Bündel-Lader B (530)
dargestellt wird. Hier bezieht sich die entfernte Vorrichtungsseite
nicht auf eine einzelne Vorrichtung oder ein einzelnes System, sondern
auf alle Vorrichtungen, die mit den lokalen Vorrichtungen über das
Netzwerk verbunden sind, und umfasst dynamisch verknüpfende Bündel-Lader. Der
Einfachheit halber wird 5 beschrieben, wobei die einzelne
Vorrichtung als ein Beispiel genutzt wird.
-
Zu
Beginn ihres Betriebes (552) implementieren lokale Rahmenbedingungen 500 einen
vorgegebenen Dienst (554). Hier bezieht sich der Dienst auf
alle Arten von Diensten, die Funktionen nicht nur mit Hilfe eines
anderen Dienstes in einer zusammengesetzten Weise, sondern darüber hinaus
auch ohne die Hilfe eines anderen Dienstes auf eine unabhängige Weise
durchführen.
Wenn es notwendig ist, einen zweiten Dienst zu implementieren, fordern
die lokalen Rahmenbedingungen 500 einen lokalen Bündelkontext 510 auf,
ein Bündel
für den
zweiten Dienst zu senden (556). Anschließend sucht
der lokale Bündelkontext 510 eine
Bündel-Liste
(558). Wenn das angeforderte Bündel vorliegt, wird das angeforderte
Bündel
mit den lokalen Rahmenbedingungen 500 registriert. Daher
wird der zweite Dienst erneut implementiert (582).
-
Wenn
jedoch das angeforderte Bündel
in dem Schritt 558 noch nicht registriert wurde, stoppen die
lokalen Rahmenbedingungen 500 das Implementieren des zweiten
Dienstes, analysieren einen Kennwert des zweiten Dienstes und erzeugen
ein Ereignis, das ein Bündel
anfordert, das für
den analysierten Dienst erforderlich ist. Anschließend wird
das Ereignis an den dynamischen entfernten Bündel-Lader A (520)
gesendet.
-
Eine
Bündel-Analyseeinheit 562 des
dynamischen entfernten Bündel-Laders 520 sucht
eine Geschichte des fraglichen Bündels
(564). Insbesondere in dem Fall, dass dasselbe Bündel bereits
vorher von einer anderen Vorrichtung empfangen wurde, werden Informationen
des empfangenen Bündels
getrennt gespeichert. Somit wird dasselbe Bündel genutzt, wenn es erneut
angefordert wird.
-
Wenn
es keine Informationen über
das Bündel
gibt, das die Bündel-Analyseeinheit 562 nach
einer Suche seiner Geschichte anfordern will, sendet eine Bündelsende-/-empfangseinheit 566 eine
Bündel-Anforderungsnachricht
in der Multicast-Art.
-
Wenn
jedoch die Informationen des Bündels vorliegen,
sendet die Bündelsende-/-empfangseinheit 566 eine
Bündel-Anforderungsnachricht
in der Unicast-Art. Zu diesem Zweck können die Informationen des
Bündels
Standort-Informationen über
das Netzwerk wie beispielsweise einen URL (uniform resource locator)
der Vorrichtung, die das Bündel
enthält,
sowie eine kurze Spezifizierung des Bündels enthalten. Wenn es auf
Grund einer Änderung
oder einer Anomalie der Konfiguration des Netzwerkes keine Antwort
auf die in der Unicast-Art gesendete Bündel-Anforderungsnachricht
gibt, wird die Bündel-Anforderungsnachricht
in der Multicast-Art erneut gesendet.
-
In
einer Bündelsende-/-empfangseinheit 568 des
dynamischen entfernten Bündel-Laders
B (530), der sich in anderen Rahmenbedingungen befindet, die
mit den lokalen Rahmenbedingungen 500 über das Netzwerk verbunden
sind, wird die gesendete Bündel-Anforderungsnachricht
empfangen und an eine Bündel-Analyseeinheit 570 gesendet.
-
Nach
dem Überprüfen der
Spezifizierung des angeforderten Bündels veranlasst die Bündel-Analyseeinheit 570,
dass ein entfernter Bündelkontext 540 das
angeforderte Bündel
sucht (572). Der entfernte Bündelkontext 540 sucht
eine Liste registrierter Bündel
(574). Findet der entfernte Bündelkontext 540 eines
der registrierten Bündel,
das an das angeforderte Bündel
angepasst ist, sendet er einen Referenzstandort des gefundenen Bündels an die
Bündelsende-/-empfangseinheit 568 (576).
-
Nach
dem Empfangen des Referenzstandortes des gefundenen Bündels sendet
die Bündelsende-/-empfangseinheit 568 das
gefundene Bündel selbst
an die Vorrichtung, die das gefundene Bündel angefordert hat, und nutzt
hierzu den empfangenen Referenzstandort des gefundenen Bündels. Hier
ist das gesendete Bündel
vorzugsweise ein Code, der in Java-Sprache beschrieben ist, und es kann
den HTTP-Dienst nutzen. Die Bündelsende-/-empfangseinheit 566 des
dynamischen entfernten Bündel-Laders
A (520), der das Bündel
angefordert hat, empfängt
eine erste Antwort auf die Bündel-Anforderungsnachricht
und vernachlässigt
andere Antworten, bis das von der Antwortseite gesendete Bündel normal
mit seinen eigenen Rahmenbedingungen registriert ist.
-
Wenn
das Senden des angeforderten Bündels
als ein Ergebnis der Antwort abgeschlossen ist, veranlasst ein Bündel-Lader 578 des
dynamischen entfernten Bündel-Laders
A (520), der das Bündel angefordert
hat, dass der lokale Bündelkontext 510 das
empfangene Bündel
mit den lokalen Rahmenbedingungen 500 registriert (580).
Wenn es jedoch keine Antwort auf die Anforderung gibt, wird ein
Prozess für
eine vorgegebene Anzahl von erneuten Versuchen durchgeführt. Wenn
es jedoch nach den erneuten Versuchen immer noch keine Antwort gibt,
ist es unmöglich,
den fraglichen Dienst in den lokalen Rahmenbedingungen 500 zu
implementieren. Diese Information wird an das Betriebssystem der
Vorrichtung gesendet, in der die lokalen Rahmenbedingungen 500 betrieben
werden. Die Anzahl der erneuten Versuche kann von einem gesonderten
Prozess eingestellt werden.
-
Wenn
die Installation und die Registrierung des angeforderten Bündels in
den lokalen Rahmenbedingungen 500 abgeschlossen sind, wird
der Dienst, der das Bündel
zuerst angefordert hat und dessen Implementierung gestoppt wurde,
erneut aufgerufen und implementiert. Das mit den lokalen Rahmenbedingungen 500 registrierte
Bündel
führt einen mit
den Anforderungen des Dienstes, der das Bündel angefordert hat, kompatiblen
Betrieb durch (582). Wenn eine Reihe von Diensten beendet
wird (584), informieren die lokalen Rahmenbedingungen 500 einen
Bündel-Entlader 588 des
dynamischen entfernten Bündel-Laders
A (520), dass die Dienste beendet wurden (586).
Der Bündel-Entlader 588 veranlasst, dass
der lokale Bündelkontext 510 das
mit den lokalen Rahmenbedingungen 500 registrierte Bündel entfernt.
Hier wird das angeforderte Bündel
von den lokalen Rahmenbedingungen 500 entfernt und aus dem
Speicher gelöscht.
Das Ziel besteht darin, die Systemressourcen der lokalen Rahmenbedingungen 500 aufrecht
zu erhalten und eine Konsistenz der Systemverwaltung beizubehalten.
-
Der
Bündel-Entlader 588 zeichnet
Informationen über
den Dienst, der das Bündel
angefordert hat, zusammen mit einer Spezifizierung und der Antwort-Standort-Information
des angeforderten Bündels
auf (592). Wenn dann eine Anforderung für dasselbe Bündel vorliegt,
bestimmt der dynamische entfernte Bündel-Lader A (520),
ob die Anforderungsnachricht direkt auf die Unicast-Art gesendet
wurde oder einem Suchprozess in der Multicast-Art unterliegt, hierfür werden
Informationen über
das aufgezeichnete Bündel
genutzt.
-
6 stellt
ein Blockdiagramm einer Vorrichtung für das Sharing von Diensten
auf einem Netzwerk gemäß einer
beispielhaften Ausführungsform der
vorliegenden Erfindung dar. Die Vorrichtung 600 umfasst
eine Empfangseinheit 610 und eine Überprüfungseinheit 620 zum Empfangen
einer Nachricht, die einen vorgegebenen Dienst von einer eingebetteten
Vorrichtung anfordert, die über
das Netzwerk verbunden ist, beziehungsweise zum Überprüfen, ob eine Codeinformation
zum Implementieren des Dienstes zurückbehalten wird oder nicht.
Wenn der Dienst zurückbehalten
wird, wird die Codeinformation an die eingebettete Vorrichtung gesendet.
Die Codeinformation zum Implementieren des Dienstes kann in Java-Sprache beschrieben
werden.
-
Gemäß Ausführungsformen
der vorliegenden Erfindung können
Dienste, die nicht mit einer aktuellen Rahmenbedingung registriert
sind, automatisch und ohne die Intervention eines Benutzers implementiert
werden, so dass Dienste fortgesetzt bereitgestellt werden können. Der
Dienst wird nur während
seiner Implementierung registriert und genutzt und nach seiner Implementierung
automatisch entfernt, so dass eine Systemumgebung nicht verändert wird.
Darüber
hinaus ist es möglich,
dasselbe Dienst-Bündel
gemeinsam zu nutzen, das zwischen den Vorrichtungen benötigt wird,
wenn die OSGi-Rahmenbedingung in Betrieb ist. Während die Architektur der bestehenden
OSGi-Rahmenbedingungen beibehalten wird, arbeiten die Vorrichtungen
und nutzen dazu ein Bündel,
das von den Rahmenbedingungen bereitgestellt wurde. Somit ist keine
gesonderte Korrektur erforderlich, um diese Funktion zu realisieren.