-
Die
vorliegende Erfindung bezieht sich auf das Zugreifen auf ein In-Haus-Netzwerk, insbesondere
auf ein HAVi-basiertes Netzwerk, von einer Fernbedienung aus, insbesondere über das
Internet.
-
Mit
dem Aufkommen neuer In-Haus-Netzwerktechnologien, wie IEEE 1394
und Bluetooth, hat die Wahrscheinlichkeit einer breiten Verwendung
derartiger Netzwerke zur Kommunikation zwischen CE-Anordnungen,
insbesondere Audio/Video-Anordnungen zugenommen. Für CCE-Anordnungen,
die auf A/V fokussieren, wurden die Protokolle höherer Pegel (Applikationsprotokolle)
neulich durch HAVi (Home Audio/Video Zusammenarbeitsfähigkeitsarchitektur)
beschrieben. Der Erfolg von Großraumnetzwerken,
insbesondere Internet und Mobiltelefonsysteme, haben zu dem Wunsch
geführt,
von Fernstellen aus auf In-Haus-Netzwerke zugreifen zu können. Dies
würde beispielsweise
einem Benutzer in den Stand setzen, seinen Heim-VCR vom Büro-PC aus
zu programmieren oder über
ein WAP-Telefon Bilder einer Sicherheitskamera zu betrachten. Es ist
bekannt, über
eine Zwischenanordnung, meistens ein PC, der mit Schnittstellen
zu dem In-Haus-Netzwerk sowie zu dem Großraumnetzwerk versehen ist,
Fernzugriff auf ein In-Haus-Netzwerk zu schaffen. In einer Situation,
in der die beiden Netzwerke dieselben Applikationsprotokolle schaffen,
spielt die Zwischenanordnung die Rolle einer Brücke oder eines Verteilers.
In einer Situation, in der die Applikationsprotokolle verschieden sind,
verwandelt die Zwischenanordnung auch die Applikationsprotokolle
des Großraumnetzwerkes
in die des In-Haus-Netzwerkes und umgekehrt. Eine derartige Anordnung
wird meistens als ein Tor ("Gateway") bezeichnet.
-
In
dem Fall einer Verbindung eines In-Haus-Netzwerkes, wie HAVi, mit
einer Fern-Internet-Anordnung, ist eine Fernanordnung weder mit
HAVi-Protokollen, noch mit Applikationsprogrammen, wie HAVi-Applets,
zur Steuerung von HAVi-Anordnungen versehen. Ist ist erwünscht, dass
HAVi-Anordnungen von Fernanordnungen, wie einen Büro-PC oder
einem WAP-Telefon, aus gesteuert werden können.
-
Es
ist nun u. a. eine Aufgabe der vorliegenden Erfindung, Kommunikation
von einer Fernanordnung aus zu Anordnungen in einem In-Haus-Netzwerk
auf eine benutzerfreundliche Art und Weise zu ermöglichen. Es
ist insbesondere eine Aufgabe der vorliegenden Erfindung ein Verfahren
und ein Kommunikationssystem zu schaffen, wobei die Kommunikation
zwischen der Fernanordnung und dem In-Haus-Netzwerk mit geringem Aufwand
seitens des Benutzers aufgebaut werden kann.
-
Zum
Erfüllen
der Aufgabe nach der vorliegenden Erfindung umfasst das Kommunikationssystem
ein In-Haus-Netzwerk und eine Fernanordnung; wobei das In-Haus-Netzwerk eine
Anzahl In-Haus-Anordnungen aufweist, die unter Anwendung vorbestimmter
In-Haus-Protokolle mit einem In-Haus-Applikationsprotokoll kommunizieren;
wobei wenigsten eine der In-Haus-Anordnungen als Zwischenanordnung
bezeichnet wird, die ebenfalls unter Anwendung vorbestimmter Fernprotokolle
mit einem Fern-Applikationsprotokoll, das anders ist als das In-Haus-Applikationsprotokoll,
mit der Fernanordnung kommuniziert; wobei
- – die Fernanordnung
ein tragbares Applikationsprogramm ladet zur Steuerung wenigstens
einer der In-Haus-Anordnungen dadurch, dass eine Applikationsprogramm-Schnittstelle
(API) des In-Haus-Protokolls abgerufen wird; und einen API-Emulator
ladet, und zwar zum Schaffen einer abrufbaren Schnittstelle für Funktionen
des In-Haus-Protokolls, und zum Liefern dieser API-Funktionalität durch
Kommunikation mit einem Modul in der Zwischenanordnung unter Anwendung
der Fern-Protokolle; und
- – die
Zwischenanordnung Folgendes umfasst:
- – eine
API zum Schaffen einer Schnittstellenfunktionalität für die Funktionen
des In-Haus-Applikationsprotokolls
durch Steuerung der Zwischenanordnung und/oder zum Kommunizieren
mit (einer) anderen In-Haus-Anordnungen) entsprechend Applikationsnachrichten
des In-Haus-Applikationsprotokolls; und
- – das
Modul zur Kommunikation zwischen dem API-Emulator in der Fernanordnung
und dem API in der Schnittstellenanordnung, wobei eine im Wesentlichen
transparente Kommunikationsstrecke zwischen dem tragbaren Applikationsprogramm
in der Fernanordnung und dem API in der Zwischenanordnung geschaffen
wird.
-
Auf
diese Weise kann das tragbare Applikationsprogramm, das zur Anwendung
in dem In-Haus-Netzwerk entwickelt worden ist, und meistens bereits
in diesem Netzwerk vorhanden und dem Benutzer durchaus bekannt ist,
auf einfache Art und Weise in die Fernanordnung geladen werden.
Folglich wird dieselbe Funktionalität und dieselbe Benutzerschnittstelle
auch außerhalb
des In-Haus-Netzwerkes verfügbar.
Die Fernanordnung und die Zwischenanordnung kommunizieren nach wie
vor miteinander, und zwar unter Anwendung der Fernprotokolle. Die
für das
Applikationsprogramm in der Fernanord nung erforderliche Schnittstelle
(API) wird dem Programm dadurch geliefert, dass es emuliert wird.
Die emulierten Funktionen werden durch Kommunikation mit einem Modul
in der Zwischenanordnung über
die Fernprotokolle durchgeführt.
In diesem Prozess werden alle relevanten Informationen von der Fernanordnung
zu der Zwischenanordnung übertragen
(und umgekehrt). In der Zwischenanordnung ist eine herkömmliche
API vorhanden (und wird auf die normale Art und Weise durch Kommunikation
mit den In-Haus-Anordnungen unter Anwendung der In-Haus-Protokolle
durchgeführt).
Das Modul gewährleistet,
dass diese API auf die richtige Art und weise abgerufen wird um
den Aufruf zu erfüllen,
der durch das Applikationsprogramm zu dem API-Emulator in der Fernanordnung
gemacht wurde.
-
Nach
der Maßnahme
des Unteranspruchs 2 erfolgt das Emulieren des Applikationsprotokolls
API dadurch, dass das Applikationsprotokoll auf eine herkömmliche
Art und weise wirklich durchgeführt
wird (nur das Applikationsprotokoll und nicht die darunter liegenden
In-Haus-Protokolle) und dass Aufrufe durch das Applikationsprotokoll
zu dem darunter liegenden In-Haus-Benachrichtungssystemprotokoll
emuliert werden. Applikationsprotokolle für ein In-Haus-Netzwerk definieren
viele abrufbare Nachrichten zur Steuerung von Anordnungen oder zum
Erhalten von Information von Anordnungen. Eine typische API zu den
HAVi-Applikationsprotokollen bietet mehrere Hundert Abrufe. Das
Applikationsprotokoll codiert/decodiert diese Nachrichten und gewährleistet
eine Übertragung
durch Abruf des unterliegenden Benachrichtigungsprotokolls. Ein
Benachrichtigungsprotokoll schafft typischerweise weniger Funktionalität und hat
als solches eine viel einfachere Schnittstelle (Benachrichtigungssystem
API). In dem Fall von HAVi schafft das Benachrichtigungssystem API
etwa 20 abrufbare Funktionen. Durch Emulierung der Benachrichtigungs-API
und durch Übertragung
der Information auf dem Benachrichtigungspegel über die Fernprotokolle, wird
die Komplexität
der Emulierung wesentlich reduziert.
-
Ausführungsbeispiele
der Erfindung sind in der Zeichnung dargestellt und werden im vorliegenden
Fall näher
beschrieben. Es zeigen:
-
1 die
HAVI-Architektur,
-
2 die
Interaktion zwischen einem HAVi-Kunden und dem Server,
-
3 ein
Blockschaltbild des Systems nach der vorliegenden Erfindung,
-
4 die bekannte Protokollarchitektur und
die Architektur nach der vorliegenden Erfindung,
-
5 eine
Darstellung der HAVi API durch Emulierung der API des Benachrichtigungssystems,
und
-
6 eine
Unterteilung in HJA-Teile.
-
DETAILLIERTE BESCHREIBUNG
-
Die
Beschreibung wird für
ein HAVI-In-Haus-Netzwerk gegeben. Es dürfte einleuchten, dass die
gleichen Konzepte auch für
andere In-Haus-Netzwerke gelten. Das HAVI-In-Haus-Netzwerk besteht
aus einem Satz von Audio- und Video-Anordnungen, wie Fernsehgeräten, VCRen,
Modems, "Web Proxy
Anordnungen", Kameras
und CD-Spielern. Das Home-Netzwerk kann auch Informationverarbeitungs-
oder Speicheranordnungen wie PCs enthalten. Die Anordnungen sind
durch IEEE 1394 miteinander verbunden und können über das Haus verteilt sein.
Alle HAVi-kompatiblen Anordnungen enthalten HAVi-Steuersoftware und kommunizieren auf
eine verteilte, direkte Art und weise zum Austauschen von Steuerinformation
und AudioNideo-Inhalt. Auf diese Weise arbeitet das HAVi-Netzwerk als eine
verteilte Rechenumgebung.
-
Die
HAVi-Steuersoftware in den jeweiligen Anordnungen in einem Heimnetzwerk
arbeitet zusammen zum Schaffen eines Satzes von Diensten für die Applikationen 10 über die
HAVi API ("Application
Program Interface" auf
dem Pegel des Applikationsprotokolls). Die Applikationen (auch als
Applikationsprogramme bezeichnet) sind Kunden des HAVi Netzwerkes.
Es wird erwartet, dass ein Benutzer über eine Applikation, die eine
freundliche Benutzerschnittstelle schafft und auf die HAVi API zugreift,
dies zum Nutzen des Benutzers, mit einem HAVi Netzwerk interaktiv
sein will. Eine spezielle Form einer Applikation ist eine tragbare
Applikation, geschrieben in Java. Ein derartiges Applet, geeignet
zur Anwendung innerhalb einer HAVi-Umgebung, wird als HAVI-Applet
oder Havlet bezeichnet. Dargestellt sind drei Havlets 12.
-
Die
HAVi-Architektur schafft die Zusammenarbeitsfähigkeit API 20 (auch
als Applikationsprotokoll API bezeichnet), dargestellt in 1 und
bildet die Middleware zwischen der "Vendor Specific Platform" (Anordnungen und
Software) und den Applikationen. Es entspricht einem Operationssystem,
das Anordnungen niedrigen Pegels in einem Rechensystem steuert und
schafft einen Satz von Diensten zu Applikationen. Einige Hauptdienste,
die in HAVi geliefert werden, sind die "Registry 22" zur Aufzeichnung aller Software-Elemente an
dem Knotenpunkt, "Event
Manager 24" zum
Aufzeichnen und Senden von Ereignissen, wenn bestimmte Bedingungen
erreicht sind, "Stream
Manager 26" zum
Verwalten von Verbindungen und der asynchronen Datenübertragung,
und "Resource Manager 28" zum Verwalten der
Anordnungszuordnung. Der DCM Manager 30 ist verantwortlich
für die
Verwaltung von DCMs ("Device
Control Modules") 32 oder
abstrakten Anordnungen.
-
Die
jeweiligen Software Module an verschiedenen Knotenpunkten kommunizieren
miteinander über die
Nachrichtensystemschicht 40. Direkter Eigen IEEE 1394 Bus
Zugriff kann über
den 1394 "Communication Media
Manager" 50 erfolgen.
Jedes Software Modul, das imstande ist, HAVi Nachrichten zu senden
und zu empfangen, ist ein "HAVi
Object" und wird
als "Software Element" bezeichnet.
-
Applikationsdurchführung in
HAVi
-
HAVi
Kunden (Endverbraucher und Software Applikationen) können auf
HAVi Dienste, die an jeder Anordnung vorhanden sind, die mit dem
HAVi Heimnetzwerk verbunden ist, dadurch zugreifen, dass HAVi API Aufrufe
durchgeführt
werden. Auf HAVi Dienste wird über
typische Kunde-Serverinteraktionen, wie in 2 dargestellt,
zugegriffen. Die HAVi Java Applikation 510 in dem Kunden 500 umfasst
Aufrufe zu der HAVi Java API 520. Diese Aufrufe werden
dem eigenen HAVi Server über
das Benachrichtigungssystem 530 und das HAVi Netzwerk 540 (arbeitend
oben auf IEEE 1394) zugesendet. Der Server 550 umfasst
einen HAVi Server 560, der die Information über sein
Benachrichtigungssystem 570 empfängt und extrahiert den ursprünglichen HAVi
Java API Aufruf, führt
in durch und führt
das Ergebnis über
die Rückführungsstrecke
zu der Kundenapplikation zurück.
-
3 zeigt
ein Kommunikationssystem 100 nach der vorliegenden Erfindung.
Das System umfasst wenigstens eine Anordnung 110, auch
als Fernanordnung bezeichnet, die über ein Großraumnetzwerk 120 mit einer
Anordnung 130 mit dem In-Haus-Netzwerk 140 verbunden ist.
Diese Anordnung 130 wird als Zwischenanordnung bezeichnet.
Dargestellt sind zwei weitere Anordnungen 150 und 160 an
dem In-Haus-Netzwerk 140. Das System wird detailliert beschrieben
für eine
Situation, in der das Großraumnetzwerk
Internet ist und das In-Haus-Netzwerk HAVi funktioniert oben auf
dem IEEE 1394 Bus. Es dürfte
einleuchten, dass auch andere Großraumnetzwerke verwendet werden
können.
Im Grunde kann statt eines Großraumnetzwerkes 120 auch
ein zweites In-Haus- Netzwerk
verwendet werden. In einem derartigen Szenario sind zwei verschiedene Typen
von In-Haus-Netzwerken über
die Zwischenanordnung 130 miteinander gekoppelt. Dieses
Szenario wird an dieser Stelle nicht weiter beschrieben, obschon
der Fachmann imstande sein wird, die hier beschriebenen Grundlagen
auch auf ein derartiges System anzuwenden. Stattdessen wird die
Aufmerksamkeit dem Zugreifen auf das In-Haus-Netzwerk von einer
Fernanordnung aus über
das Internet geschenkt.
-
4A zeigt
eine Darstellung der bekannten Protokollstapel. Die Fernanordnung 110 umfasst
herkömmliche
Internet Protokolle, wie TCP/IP 210. Diese Protokolle umfassen
auch die Telecom Protokolle eines niedrigeren Pegels, wie V90, die
nicht dargestellt sind. Die Zwischenanordnung umfasst einen entsprechenden Internet
Protokollstapel 230. Außerdem unterstützt sie
die Kommunikationsprotokolle zur Kommunikation über das In-Haus-Netzwerk 140.
Dargestellt sind die 1394 Protokolle 232 (meistens hauptsächlich in
Hardware implementiert) und die HAVi Protokolle 234. Wenigstens
eine der Anordnungen in dem In-Haus-Netzwerk kann durch ein assoziiertes
Applikationsprogramm gesteuert werden, das in tragbarem Code, wie
Java, geschrieben worden ist. Das Applikationsprogramm kommuniziert
mit der assoziierten Anordnung unter Anwendung von Applikationsprotokollnachrichten,
spezifisch für
das In-Haus-Netzwerk. Wenn das Programm in Java codiert ist, wird
es meistens als ein Applet bezeichnet. Damit übereinstimmend wird ein Applet,
das zur Kommunikation unter Anwendung von HAVi Applikationsprotokollnachrichten
entworfen worden ist, als Havlet bezeichnet. In dem hier detailliert
beschriebenen Beispiel ist das Applikationsprogramm ein HAVi Java
Applet (Havlet), das HAVi Nachrichten über Aufrufe zu dem HAVi Java
API (HJA) sendet/empfängt.
HJA ist ein Satz von Java Klassen und Paketen, deren Schnittstellen
und Verhalten durch den HAVi Standard definiert ist. Es betrifft
zwei Sachen:
- – Das Schaffen einer Art und
Weise zum Präsentieren
einer Benutzerschnittstelle (HAVi Pegel 2 UI), d.h. der Pakete org.havi.ui
und org.havi.ui.event.
- – Das
Schaffen von Zugriff auf die verschiedenen HAVi Infrastrukturelemente
(System und nicht System Software-Elemente), d.h. alle Pakete, ausgenommen
org.havi.ui und org.havi.ui.event. Havlets sind das Äquivalent
des Java Applet Konzeptes. Sie können
zu einem HAVi FAV ("Full
AN device") mit
einer Wiedergabeanordnung hochgeladen werden. Diese FAVs sollen
(ihre eigene Implementierung der) HJA schaffen, so dass das Havlet
annehmen kann, dass diese Klassen verfügbar sind.
-
Das
tragbare Applikationsprogramm (Havlet) kann in der Anordnung untergebracht
sein, die es steuert (als assoziierte Anordnung bezeichnet) oder
kann auf diese Anordnung über
das In-Haus-Netzwerk zugreifen. Auf die HAVi Protokolle kann über die
HJA Schnittstelle 236, wie in 4A dargestellt,
zugegriffen werden. Diese Schnittstelle ermöglicht es, dass das Havlet 238 mit
den anderen Anordnungen in dem In-Haus-Netzwerk 140 kommuniziert.
Selbstverständlich
gewährleistet,
wenn das Havlet 238 dieselbe Anordnung steuert, in der
das Havlet durchgeführt
wird, die HJA, dass die von dem Havlet gegebenen Instruktionen von
der Anordnung durchgeführt
werden. Die eigene Art und Weise der örtlichen Durchführung der
HJA Funktionen ist nicht dargestellt. Weiterhin ist noch eine In-Haus-Anordnung 150 dargestellt
mit entsprechenden 1394 Protokollen 252 und HAVi Protokollen 254.
Nicht dargestellt ist ein eigene Art und Weise der Durchführung von
HAVi Nachrichten durch die Anordnung 150.
-
4B zeigt
eine Darstellung des Protokollstapels nach der vorliegenden Erfindung.
Das Havlet 238 wird nun in die Fernanordnung 110 geladen.
Es wird vorausgesetzt, dass die Fernanordnung das Havlet durchführen kann.
Dies ist der Fall für
eine herkömmliche
Internet Anordnung, die mit einem Stöberer versehen ist, der imstande
ist, Java Applets durchzuführen
oder zu implementieren. Außerdem
soll die spezifische HAVi Funktionalität, die über die HAVi Java API (HJA)
zugreifbar ist, für
das Havlet in der Fernanordnung 110 zugreifbar gemacht
werden. Dazu wird ein HJA Emulator 310 in die Fernanordnung 110 geladen.
Sie bietet dem HAVi Applet 238 die HJA Schnittstelle. Im
Gegensatz zu der reellen HJA Schicht 236, wie in 4A dargestellt, liefert
der HJA Emulator 310 keine HAVi Nachrichten unmittelbar
zu einer HAVi Anordnung. Stattdessen gewährleistet der Emulator 310,
dass die Interaktion zwischen ihm und dem Havlet 238 zu
einer gleichen Interaktion mit der reellen HJA 236 führt, die
in Wirklichkeit die Funktionalität
schaff. Auf diese Weise wird die HJA Schicht durch den HJA Emulator 310 "nachgeahmt", und zwar dadurch,
dass die Tatsache gemeldet wird, dass HJA von dem HAVi Applet 238 angerufen
wurde und Einzelheiten über
den Aufruf (wie Parameter) zu der Zwischenanordnung 130.
Die Zwischenanordnung 130 wird mit einem zusätzlichen
Modul 330 geladen, das die Information wiedergewinnt, die
demselben von dem HJA Emulator 310 geliefert wird und liefert
den entsprechenden Aufruf zu der HJA Schnittstelle 236.
Dies wird normalerweise dazu führen,
dass der HAVi Anordnung (eine) Nachrichten) zugesendet werden (wird).
Es dürfte
einleuchten, dass Informationen/Nachrichten von einer HAVi Anordnung
in umge kehrter Reihenfolge zurückgeführt werden.
Vorzugsweise findet der Austausch von Information zwischen dem HJA
Emulator 310 und dem Modul 330 über Standard
Internet Protokolle, wie durch Anwendung von TCP/IP statt. Vorzugsweise
ist die der Zwischenanordnung 130 zuzuführende Information in XML Nachrichten
eingebettet, und zwar unter Anwendung von SOAP Technik von Microsoft,
wodurch Einbettung einer API in XML Nachrichten ermöglicht wird
und wodurch an sich eine Form eines Fernprozedur-Aufrufmechanismus
geschaffen wird. In einem derartigen System gewinnt das Modul 330 die
API Information aus eine XML Nachricht zurück und ruft die HJA 236 an.
In der umgekehrten Reihenfolge wird das Modul 330 durch
die HJA 236 getriggert und bettet die gelieferte Information
in einer XML Antwortnachricht ein, die dem HJA Emulator 310 zugesendet
wird. Das Modul 330 kann auch Information durchlassen,
wie Ereignisse, die von der gesteuerten Anordnung auf eine asynchrone
Weise gesendet werden. Diese Information ist auch in XML Nachrichten
verpackt. Der HJA Emulator 310 triggert in Reaktion auf
den Empfang einer XML Nachricht das Havlet 238, als wäre es unmittelbar
von der HJA 236 getriggert.
-
5 zeigt
eine bevorzugte Ausführungsform
zum Emulieren der API (in diesem Fall der HAVi Java API). Statt
einer direkten Emulierung der ganzen von der HAVi Java API Funktionalität (d.h. Übersetzung
aller Aufrufe unmittelbar (beispielsweise unter Verwendung von XML/SOAP)),
umfasst die Fernanordnung 110 in ihrer Rolle als Kunde
einen Teil einer herkömmlichen
HAVi Java API Implementierung. Wie für 1 beschrieben,
werden Aufrufe zu der HAVi API 20 in Aufrufe zu dem HAVi
Benachrichtigungssystem 40 übersetzt. Die API des Benachrichtigungssystems
umfasst wesentlich weniger Aufrufe, wodurch es einfacher gemacht
wird, das Benachrichtigungssystem API zu emulieren. Wie in 5 dargestellt,
ist die Kundenapplikation in der Fernanordnung 150 über das
Internet mit dem HAVi Heimnetzwerk verbunden und das Kunden Benachrichtigungssystem
wird durch ein Benachrichtigungssystem Proxy 532 ersetzt.
Die Verarbeitung an der Kundenseite entspricht derjenigen, die für 2 beschrieben
wurde, ausgenommen dass die Benachrichtigungssystem Proxy Schicht 532 das
Benachrichtigungssystem API in Internetnachrichten codiert, vorzugsweise
unter Anwendung von XML und SOAP, und dieses aufs Internet 120 setzt,
vorzugsweise unter Anwendung von HYYP. An der Heimseite ist eine
Wohntoranordnung 130 mit einem Internetserver erforderlich,
ebenso wie eine Verbindung mit dem HAVI Heimnetzwerk 540.
Die Wohntoranordnung 130 ist eine HAVi Anordnung, die ein
spezielles Modul aufweist, das als "RemoteAcces" bezeichnet wird, das Zugriff auf Fern
HAVI Applikationen ermöglicht.
Die Elemente dieses Moduls sind vorzugsweise ein http Server 232,
eine HAViML Schicht 332 und ein Applikation Proxy Verwalter 334.
Diese Elemente empfangen die Nachricht von dem Internet, entfernen
die XML- und die SOAP-Codierung und senden den decodierten Benachrichtigungssystem
API Aufruf zu dem richtigen Applikation Proxi 236. Dieses
bevorzugte Verfahren benutzt die Struktur der HAVI Architekturschichten
und hat eine relativ einfache Art und Weise der Übersetzung der ganzen HAVi
API durch Anpassung des HAVi Benachrichtigungssystems mit den bestehenden
Technologien XML und SOAP. Alle anderen HAVi Java API Aufrufe werden
in binäre
Daten übersetzt
und in den im Voraus geladenen Parameter eines Benachrichtigungssystem
API Aufrufs getragen. Dieses Verfahren der Übersetzung von HAVi API in
XML/SOAP wird als HAViML (HAVi Markup Language) bezeichnet.
-
Da
viele Fernkundenapplikationen auf das HAVi Heimnetzwerk zugreifen
können
, kann es viele Applikation Proxy Elemente geben so dass jede Applikation
Proxy eine bestimmte Fernapplikation in HAVi darstellt. Es gibt
aber nur einen Applikation Proxy Verwalter, der verantwortlich ist
zum Einsparen der Darstellung zwischen der Fernapplikation und der
Proxy und sendet den Benachrichtigungssystem API Aufruf zu der geeigneten
Applikation Proxy. Beim Empfang eines Benachrichtigungssystem API
Aufrufs sendet die Applikation Proxy 236 diesen zu dem
richtigen HAVi Server 150, und zwar über das Benachrichtigungssystem 234 und das
HAVi Heimnetzwerk 540 auf die übliche Art und Weise, wie für 2 beschrieben.
Die Antwort wird durch den HAVi Server zu der Applikation Proxy
zurückgesendet,
die sie zu dem Applikation Proxy Verwalter sendet zur Rücksendung
zu der Fernapplikation.
-
Es
gibt mehrere Szenarien um den HAVi bezogenen Kundenstapel (HAVi
Applikation, HAVi Java API, und Benachrichtigungssystem Proxy) an
der Kundenseite zur Verfügung
zu stellen: und zwar Folgendes umfassend:
- – Voreingestellter
Kundenstapel: Der ganze HAVi Kundenstapel soll von einer Website
oder einer Disk voreingestellt werden. So könnte beispielsweise der Hersteller
von CE-Anordnungen
(beispielsweise auf seiner Internetsite) herunterladbare Programme
zur Verfügung
stellen um seine CE-Anordnungen zu steuern. In diesem Szenario ist
eine Installation erforderlich bevor eine Fern HAVi Applikation
das erste Mal läuft, aber
wenn die Installation einmal durchgeführt worden ist, gibt es bei
nachfolgenden Durchführungen
der Ap plikation keinen Mehraufwand mehr. Eine Fernzugriffsession
kann zu jeder Zeit gestartet werden, und zwar durch Sendung einer
Auslösenachricht
zu dem Heimtor.
- – Herunterladen
von der Zwischenanordnung: In diesem Szenario braucht der HAVi Kundenstapel
zunächst nicht
an der Fernseite vorhanden zu sein. Zum Ermöglichen der Herunterladung
des Havlets und möglicherweise
anderer Teile des Kundenstapels von der Zwischenanordnung 130 zu
der Fernanordnung 110 ist die Zwischenanordnung 130 vorteilhafterweise
als ein HTTP Server ausgestattet. Die dazu erforderliche Funktionalität ist durchaus
bekannt und wird an dieser Stelle nicht weiter beschrieben. Durch
Verwendung des HTTP Servers kann die Fernanordnung 110 auf
einfache Weise auf das Havlet 238 zugreifen und unter Verwendung
von Standardprotokollen und verfügbarer
Software das Havlet 238 zurückgewinnen. Durch Verwendung
derartiger Protokolle ist ein Stöberer
an der Kundenseite 110 erforderlich zur Verbindung mit der
Zwischenanordnung (Heimtor) 130 über die URL-Adresse. Wenn diese
Verbindung einmal aufgebaut worden ist, bietet das Heimtor vorzugsweise
ein Menü von
Fernapplikationen. Wenn eine Selektion gemacht wird, wird der Kundenstapel
mit der Applikation zu dem Kunden als ein Applet heruntergeladen
und die Durchführung
startet. Für
jede neue Applikation kann der ganze Stapel oder gerade die Applikation
herunter geladen werden. Das herunter geladene Havlet kann einfach
sein, wobei beispielsweise nur die Steuerung (eines Teils) der Zwischenanordnung 130 ermöglicht wird.
Auf vorteilhafte Weise ermöglicht
das Havlet dem Benutzer mehrere AN Anordnungen zu steuern und schafft
eine geeignete Benutzerschnittstelle für mehrere A/V Anordnungen an
dem HAVi Netzwerk. Auf diese Weise kann ein Benutzer ferngesteuert
auf A/V Anordnungen zugreifen, und dennoch die Heimbenutzerschnittstelle
zur Steuerung der Anordnungen daheim benutzten.
- – Herunterladen
des Havlets über
die Zwischenanordnung: Zusätzlich
zu dem oben beschriebenen Szenario ist die Zwischenanordnung vorzugsweise
imstande, das HAVi Applet 238 von der einen oder der anderen
Anordnung in dem Heimnetzwerk 140 herunter zu laden. Auf
diese Weise kann beispielsweise eine Benutzerschnittstelle und/oder
ein Steuerapplikationsprogramm eines VCR, geschrieben in tragbarem
Code, zunächst
herunter geladen (oder hochgeladen) werden zu der Zwischenanordnung
(wie einem PC oder einer Set Top Box). Die Funktionalität zum Laden
eines Havlets ist standrd verfügbar
in einer spezifischen Klasse von HAVi Anordnungen, auch als Full
AV Anordnung (FAV) bezeichnet. Danach wird das Programm in die Fernanordnung
geladen (beispielsweise in ei nem Büro), wodurch Steuerung des
VCRs auf genau dieselbe Art und Weise erhalten wird, wie wenn der
Benutzer die Anordnung direkt betreiben würde. Auch kann dieselne Benutzerschnittstelle
vorgesehen werden.
- – Java
API als Stöberer
Eischub: In diesem Szenario sind die HAVi Java API und das Benachrichtungssystem
Proxy zusammen als Einschub bei Standard Stöberern verfügbar. Wenn der Einschub einmal
geladen ist, können
die Fernapplikationen von dem Heimtor oder einer Website herunter
geladen werden. In diesem Fallkönnen
die Applikationen als Havlets verfügbar gestellt werden.
-
Es
dürfte
einleuchten, dass der HJA Emulator und das Modul 330 nur
einmal entwickelt zu werden braucht. Wenn sie die volle Funktionalität der HAVi
API unterstützen,
können
sie verwendet werden um jedes Havlet in einer Fernanordnung durchzuführen. Als
eine Alternative gegenüber
dem vollen HJA Emulator 310 oder dem Modul 330 können auch
begrenzte Implementierungen verwendet werden, die nur die Funktionalität, erforderlich
für das
spezifische Havlet 238 schaffen. In diesem Szenario wird
vorzugsweise der HJA Emulator 310 zusammen mit dem Havlet 238 in
der Fernanordnung 110 geladen. Die Zwischenanordnung ladet
das Modul 330, das dem Havlet 238 entspricht.
-
GESTARTET WERDEN
-
Zum
Durchführen
von Fern HAVi Applikationen muss die Heimtor HAVi Anordnung (Zwischenanordnung)
im Haus laufen, einschließlich
der "RemoteAccess" Applikation. Wenn
die "RemoteAccess" Applikation gestartet
wird, werden der http Server, die HAViML Schicht und der Applikation
Proxy Verwalter gestartet (Siehe 5). Der
http Serverport und Anwender werden ausgelöst und warten darauf, eintreffende
Anträge
zu erledigen.
-
Der
erste Schritt seitens des Kunden ist unter Verwendung der URL-Adresse
des Heimtors von einem Standard Stöberer aus auf das Heimtor und
auf das HAVi Heimnetzwerk zuzugreifen. Typischerweise wird das Heimtor
ein Menü verfügbarer Applikationen
präsentieren.
Der Kunde selektiert die gewünschte
Applikation. Dies führt
zu einer Hochladung der Kundenapplikation, der HAVi Java API Schicht
und des Benachrichtigungssystems Proxy. Wenn die Hochladung zu Ende
ist, startet die Kundenapplikation die Initialisierung. Die erste Interaktion
mit dem Heimserver ist eine Initialisierungsnachricht, die als "initRemote" bezeichnet wird.
Diese Nachricht sorgt dafür,
dass das Heimtor die IP- Adresse
der Kundenseite extrahiert. In Reaktion auf diese Nachricht wird
die ID des HAVi Benachrichtigungssystems zur künftigen Bezugnahme zu dem Kunden
zurückgeführt.
-
Der
nächste
Initialisierungsschritt an der Kundenseite ist, ein Applikations-Softwareelement zu
schaffen. Ein Softwareelement ist ein "HAVi Object", das imstande ist, Nachrichten zu anderen
Softwareelementen zu senden und von ihnen zu empfangen, und zwar
unter Anwendung des HAVi Benachrichtigungssystems. Das Schaffen
eines Applikations-Softwareelementes führt dazu, dass der Benachrichtigungssystemaufruf "msgOpen" dem Heimserver zugesendet
wird, so dass ihm das Benachrichtigungssystem eine ID (Softwareelement
ID – SEID)
zuordnen kann. Das kundenseitige Benachrichtigungssystem Proxy fügt die Kunden URL-Adresse
als ein zusätzlicher
Parameter diesem Anruf zu. An der Serverseite wird ein Applikation
Proxy (oder ein Proxy Softwareelement) geschaffen und die SEID wird
durch das HAVi Benachrichtigungssystem zurückgeführt. Der Applikation Proxy
Verwalter hält
eine Abbildung dieser SEID und des Proxy Softwareelementes bei und
auch der SEID und der Kunden-URL-Adresse. Dies ermöglicht es,
dass er asynchrone Ereignisse zurücksendet und auf die richtige
Kundenbestimmung antwortet. Die SEID der Applikation Proxy wird
zu dem Kunden zurückgeführt und
dort zur künftigen
Bezugnahme gespeichert. Eine Abbildung der SEID und des Applikations-Softwareelementes
wird auch an der Kundenseite beibehalten, so dass das Benachrichtigungssystem
Proxy Antworten mit den richtigen Applikationssoftwareelementen
assoziieren kann. Ein anderer Aspekt der Softwareerzeugung im Zusammenhang
mit relevanten "Zuhörern" mit den Softwareelementen,
so dass eine Nachricht eines bestimmten Typs, die einem Softwareelement
zugesendet worden ist, von einem geeigneten Zuhörer verarbeitet werden kann.
-
BEHANDLUNG SYNCHRONER
HAVI API ANRUFE
-
Von
dem Gesichtpunkt der Fern HAVi Applikationen ist die Behandlung
von HAVi API Anrufen genau dieselbe wie wenn die Applikationen in
Wirklichkeit mit einem HAVi Netzwerk verbunden wären. Sie senden und empfangen
Nachrichten in einem Benachrichtigungssystem Proxy, das sich genau
so verhält
wie das normale Benachrichtigungssystem.
-
Der
Transport von HAVi API Anrufen über
das Internet erfolgt vorzugsweise mit XML. Die Interaktion zwischen
dem Kunden und dem Server basiert vorzugsweise auf einem Fernprozedur-Anrufmechanismus. Folglich
wird vorzugsweise SOAP, der Notstandard für Fernprozeduranrufe in XML
verwendet. Die XML/SOAP Nachrichten werden unter Anwendung des http
Protokolls auf das Internet gesetzt.
-
Das
Schema zum Tunneln von HAVi API Anrufen über das Internet benutzt die
Tatsache, dass alle Information eines HAVi Java API Anrufs bereits
in binäre
Daten arrangiert sind und in dem Ladungsparameter eines Benachrichtigungssystem
API Anrufs getragen wird. Folglich erfolgt die Übertragung der ganzen HAVi Java
API über
das Internet dadurch, dass es ein Übersetzungsschema gibt für die Benachrichtigungssystem API.
Dies reduziert die Übersetzung
der HAVi Java API (einige Hundert Anrufe) aus die Übersetzung
der Benachrichtigungssystem API (etwa 20 Anrufe). Alle HAVi API
Anrufe können
auf diese Weise verarbeitet werden, ausgenommen den Strom isochroner
Daten.
-
Auf
diese Weise besteht HAViML aus dem Benachrichtigungssystem API,
und dem bereits beschriebenen "initRemote" Verfahren, angewandt
bei der Initialisierung des Fernkunden. HAViML besteht aus etwa 20
API Anrufen. Typische Verfahren sind "MsgSendSimple", "MsgSendReliable", "MsgSendRequest", "MsgOpen", "MsgClose", "MsgWatchOn" und "MsgWatchOff". Die Benachrichtigungssystemanrufe
werden in XML/SOAP übersetzt
zur Übertragung über das
Internet, unter Anwendung von HTTP. Die Übertragung binärer Daten
erfolgt mit Basis-64-Codierung. Ein Beispiel dieser Übersetzung
für den
API Anruf "MsgSendRequestSync" ist unten dargestellt:
-
-
-
Die
Funktion "MsgSendRequestSync" wird angewandt zum
Senden von HAVi API Anrufen.-Der Operationscode des API Anrufs,
der gesendet wird, ist in dem Parameter <opCode> vorgesehen, und die Parameter des Anrufs
sind in <bufferIn> codiert. Die ID des
HAVi Servers, der diesen Anruf verarbeiten wird, ist in <destSeid> gegeben und die ID
des Senders ist in <srcSeid>. Die Reaktion auf
den API Anruf ist auch in XML/SOAP in dem Heimtor codiert und wird
zu der Kundenseite zurückgesendet.
Die Reaktion umfasst alle Rückkehrparameternamen
und Werte und/oder einen Ausnahmecode (Fehler). Ein Fachmann wird
imstande sein, geeignete Übersetzungen
für die
anderen API Anrufe zu entwerfen.
-
BEHANDLUNG ASYNCHRONER
EREIGNISSE UND ANTWORTEN
-
Ereignisse
und asynchrone Antworten sind HAVi Benachrichtigungssystem API Anrufe,
die von dem Heimtor aus statt von dem Fernkunden aus initiiert werden.
Um diese zu empfangen wird vorzugsweise ein HTTP Server an der Kundenseite
verwendet. Diese Anrufe werden vorzugsweise auch in XML/SOAP codiert, wie
in dem vorhergehenden Abschnitt beschrieben. Wenn ein asynchrones
Ereignis oder eine derartige Antwort einem Fern-Applikationskunden
zugeführt
wird, empfängt
die entsprechende Applikation Proxy als erste das Ereignis oder
die Antwort. Dies wird dem Applikation Proxy Verwalter zugeführt. Dieser
Verwalter übersetzt das
Ereignis oder die Antwort in XML/SOAP und sendet dies dem HTTP Server
zu für
die entsprechende Fernapplikation. Der HTTP Server lässt die
Steuerung durch zu einem HAViML Kundenobjekt. Das HAViML Kundenobjekt
extrahiert den API Anruf aus der XML/SOAP Nachricht und ruft das "receiveMsg" Verfahren in dem Benachrichtigungssystem
Proxy auf. Das Benachrichtigungssystem Proxy behält eine Abbildung der Applikation
SEID und des Softwareelementes bei. Es benutzt diese Abbildung zur
Beförderung
des Ereignisses oder der Antwort zu dem richtigen Softwareelement,
und folglich zu der Applikation. Das Heimtor benutzt die Kundenadresseninformation,
die in der Aufstartphase gespeichert wurde zum Zugreifen auf die
eigentliche Fernapplikation.
-
BEHANDLUNG VON EINSTECKEN
UND EINSCHALTEN
-
Einstecken
und Einschalten ist die Fähigkeit
Anordnungen in dem Heimnetzwerk zu entfernen und hinzuzufügen, ohne
dass das ganze Netzwerk abgeschaltet werden muss. In HAVi konfiguriert
eine neue Anordnung sich selbst, wird registriert, beantragt eine
ID und die Anwesenheit kann den übrigen
Anordnungen mitgeteilt werden, die bereits in dem Heimnetzwerk vorhanden
sind. Auf gleiche Weise wird, wenn eine Anordnung entfernt oder
abgeschaltet wird, die Information auch entfernt, und die Entfernung
kann bestehenden Anordnungen gewünschtenfalls
mitgeteilt werden. Diese Aktionen erfordern nicht eine Intervention
des Benutzers in Bezug auf die Tatsache, dass die Anordnungen entfernt
oder hinzugefügt
werden. Mit HAViML werden einige dieser Fähigkeiten für die Fernapplikationen verfügbar, aber
einige erfordern Verbesserungen an dem System. Die üblichsten
Szenarien werden nachstehend beschrieben.
-
Wenn
eine der Anordnungen in dem HAVi Heimnetzwerk hinzugefügt oder
entfernt wird, ist die Abwicklung genau so wie vorher. Die Fernapplikation
kann eine "WatchOn" an der Anordnung
annehmen und darüber informiert
werden, wenn sie wegfällt,
oder sie kann ein Ereignis beantragen, wann eine neue Anordnung
verfügbar
wird. Wenn das Heimtor entfernt wird, dann werden alle zur Zeit
laufenden Fernapplikationen auch entfernt. Wenn auf eine dieser
Applikationen eine Uhr gesetzt ist, wird diese einwandfrei erledigt.
Wenn ein Heimtor hinzugefügt
wird, wird dies auf dieselbe Art und Weise abgewickelt wie für ein normales
HAVi Netzwerk, da keine Fernapplikationen in dieser Phase vorhanden
sein können.
-
Wenn
die Fernkundenanordnung entkoppelt wird, gibt es keine automatische
Art und Weise, dass das HAVi Netzwerk informiert wird. Zwischen
dem Heimtor und dem Fernkunden sind zu regelmäßigen Intervallen zusätzliche
Protokolle erforderlich, wie "Ich
lebe" Nachrichten
erforderlich. Auf gleiche Weise gibt es, wenn eine der Applikationen
an der Seite des Kunden abfällt,
aber das Proxy am Server dennoch verfügbar ist, keine automatische
Art und Weise dies ohne zusätzliche
Protokolle herauszufinden. Die Hinzufügung eines Fernkunden oder
einer Fernapplikation wird durch den HAViML Initialisierungsmechanismus überwacht.
-
BEENDIGUNG EINER FERN
HAVI APPLIKATION
-
Beendigung
einer Fern HAVi Applikation umfasst das Entfernen des Applikationssoftwareelementes an
der Fernkundenseite, und des Proxy Applikationssoftware elementes
an der Heimserverseite. Alle relatierten Beziehung zu diesen Softwareelementen
sollen ebenfalls entfernt werden, wie die SEID und die Fernadresse
(Kunden-URL-Adresse).
Entfernung einer Fernapplikation erfolgt, wenn das Softwareelement
einen "msgClose" Anruft in dem Benachrichtigungssystem
macht. Dies könnte
beispielsweise erfolgen, wenn eine Applikation abschließt.
-
KLASSEN
-
Die
HJA hat verschiedene Typen von Klassen:
- – Klassen,
die auf eine Plattform-unabhängige
Weise implementiert werden können.
- – Klassen,
die nicht auf eine Plattform-unabhängige Art und Weise implementiert
werden können.
-
In
der Praxis werden einige HJA Klassen an der FAV selber (insbesondere
für die
L2 Benutzerschnittstellenfunktionalität) meistens auf eine eigene
Weise implementiert um sie möglichst
effizient zu machen. Wenn von einer Havlet zu einer Nicht Havlet-Anordnung 110 hochgeladen
wird, soll die Nicht-Havlet-Anordnung die HJA liefern, und zwar
dadurch, dass der HJA Emulator 310 verwendet wird. Die
Benutzerschnittstelle wird dann typischerweise örtlich an der Fernseite durchgeführt. Der
HJA Emulator 310 kann auf einfache Weise den UI Teil der
HJA dadurch liefern, dass eine Implementierung benutzt wird, die
auf Sun's Java AWT
("Abstract Windowing
Toolkit") gebaut
ist. Das AWT Paket ist normalerweise an den meisten Internet-Anordnungen (PCs
mit Java) verfügbar.
Für den
Nicht-UI-Teil von HJA, d.h. der Zugriff auf die HAVi Infrastruktur,
können
alle HAVi Java Klassen auf eine Plattform-unabhängige Art und Weise implementiert
werden, ausgenommen die Softwareelementklasse, und Klassen in dem
org.havi.iec61883 Paket. Diese Aufteilung der HJA Funktionalität ist in 6 dargestellt.
Der gesamte Satz der Funktionalität ist durch 400 bezeichnet,
der UI relatierte Teil durch die Nummer 430, der Teil,
der auf eine anordnungsunabhängige
Art und Weis implementiert werden kann, durch die Nummer 420,
und der Teil, der anordnungsabhängig
ist, durch die Nummer 410.
-
Wie
oben beschrieben, hat die Fernanordnung nebst der Herunterladung
des Havlets 238 auch eine Wahl in dem Erhalten des HJA
Emulators 310. So könnte
beispielsweise die Fernanordnung:
- – in den
Stöberer
eingebaut werden
- – von
einer Website heruntergeladen werden
- – von
der HAVi Zwischenanordnung, oder über die HAVi Zwischenanordnung
von den anderen HAVi Anordnungen in dem Heimnetzwerk hochgeladen
werden.
-
Eine
derartige Option kann für
den ganzen HJA Emulator gewählt
werden, aber es kann ebenfalls eine Wahl gemacht werden, und zwar
unabhängig,
für die
in 3 angegebenen Komponenten (den UI Teil, die Plattform-unabhängigen und
-abhängigen
Pakete).