-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung betrifft eine Vorrichtung, ein Verfahren und
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte über mehrere
Plattformen hinweg, einschließlich
unter Aufrechterhaltung eines einheitlichen synchronisierten Zustands.
-
ALLGEMEINER
STAND DER TECHNIK
-
Mit
fortschreitender Datenverarbeitungstechnologie kann die Anzahl persönlicher
Geräte,
Kommunikationsprotokolle und die Diversität der Verbindungswahlmöglichkeiten
zunehmen. Insbesondere können
zu diesen Geräten
zum Beispiel ein Desktop-PC (Personal Computer), ein Laptop-Computer, ein
persönlicher
Datenassistent (PDA), ein Mobiltelefon, ein GPS-Navigationssystem
in einem Auto, eine digitale Kamera, ein MP3-Player und andere Geräte gehören. Als
Protokoll können
zum Beispiel HTTP (Hypertext Transfer Protocol), FTP (File Transfer
Protocol), SNMP (Simple Network Management Protocol), IIOP (Internet
Inter-Orb Protocol) in der CORBA (Common Object Request Broken Architecture), SOAP
(Simple Object Access Protocol mit XML (Extension Markup Language)
oder ein beliebiges anderes geeignetes Protokoll ausgewählt werden.
Für Konnektivität können zum
Beispiel Ethernet, Bluetooth, IEEE 802.11 a/b/g (WiFi), ZigBee,
IrDA (Infrared Detection and Acquisition), GPRS (General Packet
Radio Service), CDMA (Code Division Multiplexed Access) und GSM
(Global System for Mobile Communication) ausgewählt werden.
-
Diese
Geräte
kommunizieren jedoch möglicherweise
nicht direkt miteinander, weil sie zum Beispiel möglicher weise
kein gemeinsames Kommunikationsprotokoll unterstützen oder sie in verschiedenen
Programmiersprachen implementiert sein können. Wenn Geräte kleiner,
kostengünstiger,
produktiver und mehr auf eine einzige Anwendung konzentriert werden,
kann die Interoperabilität
zwischen Geräten
ein größeres Problem
darstellen. Auch wenn ein Gerät über mehrere
Protokolle kommunizieren kann, kann die Möglichkeit, zu neuen Standards überzugehen,
eine problematische und schwierige Aufgabe bleiben.
-
Jedes
der Geräte
kann verschiedene Datenverarbeitungsleistung, Schirmgrößen, Datenverarbeitungsleistungs- und Verbindungsfähigkeiten
aufweisen und die Verbindung dieser Geräte miteinander und mit anderen
Netzwerken, wie zum Beispiel dem Internet oder einem anderen Netzwerk,
kann daher signifikante Programmierungs- und manuelle Synchronisationsbemühungen erfordern,
um einheitliche Zustände
zu erzielen. Die Bereitstellung von Diensten für diese Geräte kann schwierig sein und kann
signifikante Programmierbemühungen
und Infrastruktur erfordern.
-
Zur
schnellen Anwendungsentwicklung kann eine Standardplattform erwünscht sein,
so daß sich Programmierer
auf die Anwendungsentwicklung konzentrieren können, anstatt sich mit mehreren
Sprachen und/oder mehreren Konnektivitätsproblemen beschäftigen zu
müssen.
In dieser Hinsicht können das
zugrundeliegende System und Systembibliotheken der Standardplattform
eine Abstraktion oder vereinfachte Schnittstelle bereitstellen,
um die mehreren Verbindungsprotokolle und hardwarespezifischen Details
abzuschirmen. Es kann jedoch eine geeignete Standardplattform für Geräte insofern
fehlen, als für
jede neue geschriebene Softwareanwendung signifikante Programmierbemühungen erforderlich
sein können,
um gerätespezifische
Details zu behandeln, wodurch sich die Anwendungsentwicklung verlängern und
der Einsatz der Anwendung in anderen Geräten begrenzt werden kann.
-
Zur
Bereitstellung von Diensten für
Geräte kann
es auch andere Herausforderungen geben. Insbesondere kann die Bereitstellung
von Diensten für mobile
Geräte über ein
drahtloses Netzwerk ein Problem darstellen, zum Beispiel aufgrund
der Verzögerungs-
und Verfügbarkeitseinschränkungen.
Insbesondere können
Verzögerungseinschränkungen
aufgrund von begrenzter Bandbreite, Paketverlusten und Backbone-Verzögerung entstehen,
wodurch für Techniker
mit begrenzter oder gar keiner Kontrolle über diese Einschränkungen
schwierige Herausforderungen entstehen können. Öffentliche Backbones, wie zum
Beispiel das Internet oder zellulare Netzwerke, können sehr
latent sein und können
nur eine begrenzte Abdeckung bereitstellen. Mobile Anwendungen müssen daher
in einer nicht immer betriebsbereiten Umgebung arbeiten können und
ein Netzwerk nur dann benutzen, wenn es verfügbar ist.
-
KURZE DARSTELLUNG
DER ERFINDUNG
-
Eine
beispielhafte Ausführungsform und/oder
ein beispielhaftes Verfahren der vorliegenden Erfindung können automatisierte
Dienste für
heterogene Geräte über mehrere
Plattformen hinweg (ASAP – Across
multiple Platforms) bereitstellen, während ein einheitlicher synchronisierter
Zustand aufrechterhalten wird. Zu den heterogenen Geräten können zum
Beispiel eine persönliche
Datenassistenz (PDA), ein drahtloses Gerät, ein Mobiltelefon, eine in
der Hand gehaltene GPS-Einheit (Global Positioning System), ein
Navigationssystem in einem Auto, eine digitale Kamera, ein MP3-Player,
ein Desktop-Computer, ein Laptop-Computer, ein Drucker, ein digitales
Videoaufzeichnungsgerät,
ein Haushaltsgerät
oder ein beliebiges anderes heterogenes Gerät gehören. In dieser Hinsicht kann
ein beispielhaftes ASAP-System Software (Anwendungen), Dienste (Transaktionen)
und Daten (persönliche
Profile und Anwendungsdaten) über
großflächige und
lokale Netzwerke abliefern und kann transparente Verbindungen von
Gerät zu
Gerät und
Gerät zu
Diensten bereitstellen, ohne aktiv Verbindungen zu Dienstanbietern
einzuleiten. Außerdem
kann das beispielhafte ASAP-System die Probleme der Verzögerung und Latenz
besser behandeln und kann eine asynchrone Nachrichtengebung bereitstellen,
um den Server zu aktualisieren, wenn das Netzwerk verfügbar ist.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können eine automatische Registration
von Geräten
bereitstellen.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können eine automatische Synchronisation zwischen
Geräten
bereitstellen, so daß Daten
so aktuell oder frisch wie möglich
gehalten werden können.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können eine automatische Entdeckung
von Gerätefähigkeiten
bereitstellen.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können eine vereinfachte Anwendungsprogrammierschnittstelle
(API) bereitstellen, um einen großen Teil der Protokoll- und
Konnektivitätsdetails zu
verbergen, die zum Zugriff auf Dienste erforderlich sind, so daß die Last
der Programmierung verringert werden kann. In dieser Hinsicht kann
das ASAP-System eine Markup-Sprache verwenden (wie zum Beispiel
XML (Extension Markup Language)) oder eine reduzierte/komprimierte
Version davon.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können eine Plattform zum Einsetzen
und Verwalten von Anwendungen auf koordinierte Weise verwenden,
wie zum Beispiel die OSGi (Open Systems Gateway interface). In dieser
Hinsicht kann die Verwendung von OSGi erweiterte Austauschdienste, wie
zum Beispiel Bündel,
bereitstellen. Insbesondere kann man mit OSGi zum Beispiel eine wohldefinierte und
geschützte
Ausführungsumgebung
für Bündel, zusätzliche
Lebenszyklusverwaltung, dauerhafte Datenspeicherung, Versionsverwaltung
usw. bereitstellen.
-
Ein
beispielhaftes ASAP-Verfahren und/oder -System können außerdem relevanten Geräten durch
ein Web-Portal (das als Proxy für
den Benutzer zum Aufbrauchen anderer Web-Dienste dienen kann) anonyme
Dienste bereitstellen, wobei zum Beispiel eine nachrichtenorientierte
Architektur verwendet wird.
-
Ein
beispielhaftes ASAP-Verfahren und/oder -System können außerdem einen Mechanismus zum Verbinden
verteilter Dienste in einem peer-to-peer-Netzwerk bereitstellen.
In dieser Hinsicht kann ein beispielhaftes ASAP-System eine Markup-Sprache
(wie zum Beispiel XML (Extension Markup Language)) als zugrundeliegendes
Nachrichtenschnittstellenformat verwenden und kann eine Menge von
Protokollen für
den Datenaustausch und Dienstanforderungen/-antworten definieren.
ASAP soll jedoch in jeder beliebigen Sprache implementierbar sein.
-
Ein
beispielhaftes ASAP-Verfahren und/oder System können zum Beispiel Jini-Netzwerktechnologie
verwenden, um verteilte Dienste innerhalb eines Java-Netzwerks zu
verbinden. Insbesondere kann das beispielhafte ASAP-System einen zentralisierten Dienstortmakler
verwenden.
-
Eine
beispielhafte Ausführungsform
betrifft ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei das System folgendes enthält: einen
Geräteagenten,
der auf jedem der heterogenen Geräte verankert ist, einen Gerätekommunikator
zum Registrieren und Synchronisieren der Geräte über jeden der Geräteagenten
und einen Portal-Server
zur Anschaltung mehrerer Inhaltsquellen im Namen der Geräte, wobei
die Geräte über jeden
der Geräteagen ten
und den Gerätekommunikator
mit dem Portal-Server kommunizieren.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei mindestens zwei der Geräte verschiedene
Protokolle und Konnektivitäten
unterstützen.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die Geräte mindestens eines der Folgenden
umfassen: einen Desktop-Computer, einen Laptop-Computer, ein drahtloses
Gerät,
einen persönlichen
Datenassistenten, eine in der Hand gehaltene GPS-Einheit, ein Navigationssystem
in einem Auto, ein Mobiltelefon, eine Digitalkamera, einen MP3-Player,
ein digitales Videoaufzeichnungsgerät, einen Drucker und ein Haushaltsgerät mit einem
Prozessor.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die Dienste das Herunterladen von Daten
und/oder das Bereitstellen von Datensynchronisation umfassen.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die Dienste mindestens einen der
Folgenden umfassen: Finden eines Dienstanbieters, Bestellen eines
Produkts und/oder eines Dienstes, Erwerben des Produkts und/oder
des Dienstes, Finden eines nahegelegenen Dienstunternehmens, Herunterladen
von Informationen und Aktualisieren von Informationen.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die Netzwerkumgebung eine verdrahtete
Verbindung und/oder eine drahtlose Verbindung enthält.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die Netzwerkumgebung ein persönliches
Netzwerk, ein lokales Netzwerk und/oder ein großflächiges Netzwerk enthält.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Geräteagent eine einzige vereinigte
Nachrichtenschnittstelle bereitstellt.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die einzige Nachrichtenschnittstelle eine
XML-Schnittstelle und/oder eine komprimierte XML-Schnittstelle ist.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die einzige vereinigte Nachrichtenschnittstelle
zukünftige
Erweiterungsfähigkeiten ohne
eine feste Bindung eines Funktionsaufrufs für eine Anwendungsprogrammierschnittstelle
ermöglicht.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Gerätekommunikator so konfiguriert
ist, daß er
während
einer Registration der Geräte Gerätefähigkeiten
speichert.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei zu den Gerätefähigkeiten eine Konnektivitätsfähigkeit
gehört.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei zu der Konnektivitätsfähigkeit
mindestens eine der Folgenden gehört: ZigBee, Bluetooth, IrDA,
GPRS, GSM, CDMA und Ethernet.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei zu den Gerätefähigkeiten mindestens ein unterstütztes Protokoll
gehört.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei das mindestens eine unterstützte Protokoll
mindestens eines der Folgenden enthält: HTTP, FTP, SNMP, SOAP,
XML, RMl und IIOP/CORBA.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei zu den Gerätefähigkeiten mindestens eine der
Folgenden gehört:
Speichergröße, Schirmgröße, Datenverarbeitungsleistung,
Speicherungsfähigkeit,
Audiofähigkeit
und Videofähigkeit.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Gerätekommunikator so konfiguriert
ist, daß er über den
Geräteagenten
Softwareaktualisierungen an die Geräte abliefert.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Gerätekommunikator so konfiguriert
ist, daß er
die Softwareaktualisierungen abliefert, wenn das Gerät verfügbar ist.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Portal-Server so konfiguriert
ist, daß er
Daten von den mehreren Inhaltsquellen zusammenstellt und/oder Cachespeichert.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei der Portal-Server so konfiguriert
ist, daß er
Datenpersistenz aufrechterhält,
so daß Geräte, die
nicht immer eingeschaltet sind, Zugang zu einem neusten Schnappschuß haben.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei mindestens eine der mehreren Inhaltsquellen
auf einem großflächigen Netzwerk
verankert ist.
-
Eine
weitere beispielhafte Ausführungsform betrifft
ein System zur Bereitstellung automatisierter Dienste für heterogene
Geräte
in einer Netzwerkumgebung, wobei die mindestens eine der mehreren
Inhaltsquellen auf dem Internet verankert ist.
-
Ein
beispielhaftes Verfahren betrifft die Bereitstellung automatisierter
Dienste für
heterogene Geräte
in einer Netzwerkumgebung über
mehrere Plattformen hinweg, mit den folgenden Schritten: Bereitstellen
einer einzigen Nachrichtenschnittstelle auf jedem Gerät über einen
Geräteagenten,
der über
ein gerätespezifisches
Konnektivitäts-
und Kommunikationsprotokoll mit einem Gerätekommunikator kommuniziert,
Registrieren jedes der Geräte über den
Gerätekommunikator,
um Gerätefähigkeiten
jedes der Geräte
aufzuzeichnen, Zusammenstellen von Daten von mehreren Inhaltsquellen über einen
Portal-Server, Cache-Speichern der Daten und Herunterladen und Synchronisieren
der Daten über
den Gerätekommunikator.
-
Ein
beispielhaftes Verfahren betrifft die Bereitstellung automatisierter
Dienste für
heterogene Geräte
in einer Netzwerkumgebung über
mehrere Plattformen hinweg, mit den folgenden Schritten: Ausgeben
einer Dienstanforderung über
die einzige Nachrichtenschnittstelle, Senden der Anforderung von
dem Geräteagenten
zu dem Gerätekommunikator,
Modifizieren der Anforderung, so daß sie der Netzwerkumgebung
entspricht, Weiterleiten der Anforderung an einen Dienstanbieter über den
Portal-Server und Empfangen einer Antwort von dem Dienstanbieter über den
Portal-Server.
-
Eine
weitere beispielhafte Ausführungsform betrifft
die Bereitstellung automatisierter Dienste für heterogene Geräte in einer
Netzwerkumgebung über mehrere
Plattformen hinweg, wobei das System folgendes enthält: eine
einzige Nachrichtenschnittstelle auf jedem Gerät über einen Geräteagenten,
der über ein
gerätespezifisches
Konnektivitäts-
und Kommunikationsprotokoll mit einem Gerätekommunikator kommuniziert,
eine Anordnung zum Registrieren jedes der Geräte über den Gerätekommunikator zum Aufzeichnen
von Gerätefähigkeiten
jedes der Geräte, eine
Anordnung zum Zusammenstellen von Daten von mehreren Inhaltsquellen über einen
Portal-Server, eine Anordnung zum Cache-Speichern der Daten und
eine Anordnung zum Herunterladen und Synchronisieren der Daten über den
Gerätekommunikator.
-
Eine
weitere beispielhafte Ausführungsform betrifft
die Bereitstellung automatisierter Dienste für heterogene Geräte in einer
Netzwerkumgebung über mehrere
Plattformen hinweg, wobei das System folgendes enthält: eine
Anordnung zum Ausgeben einer Dienstanforderung über die einzige Nachrichtenschnittstelle,
eine Anordnung zum Senden der Anforderung von dem Geräteagenten
zu dem Gerätekommunikator,
eine Anordnung zum Modifizieren der Anforderung, so daß sie der
Netzwerkumgebung entspricht, eine Anordnung zum Weiterleiten der
Anforderung zu einem Dienstanbieter über den Portal-Server und eine
Anordnung zum Empfangen einer Antwort von dem Dienstanbieter über den
Portal-Server.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
1A zeigt
eine beispielhafte Systemarchitektur zur Bereitstellung automatisierter
Dienste für heterogene
Geräte über mehrere
Plattformen hinweg (ASAP).
-
1B zeigt
eine beispielhafte, durch den Portal-Server durchgeführte Zusammenstellung.
-
2A zeigt
ein beispielhaftes Verfahren gemäß der vorliegenden
Erfindung.
-
2B zeigt
ein weiteres beispielhaftes Verfahren gemäß der vorliegenden Erfindung.
-
3 zeigt
eine beispielhafte Konfiguration zur Bereitstellung einer effizienten
Bandbreitenbenutzung und verbesserten Netzwerklatenz.
-
4 zeigt
eine beispielhafte Netzwerktopologie für automatisierte Dienste für heterogene
Geräte über mehrere
Plattformen hinweg (ASAP).
-
5 zeigt
eine beispielhafte Architektur für automatisierte
Dienste für
heterogene Geräte über mehrere
Plattformen hinweg (ASAP).
-
6 zeigt
Pseudocode zur Implementierung eines beispielhaften Teilnehmer-/Veröffentlicher-Steuerflusses.
-
7 zeigt
ein Flußdiagramm
für eine
beispielhafte Geräteentdeckung.
-
8 zeigt
ein beispielhaftes Verfahren zum Bestellen eines Kinotickets von
einem nahegelegenen Kino und zum Erhalten einer Wegbeschreibung zu
dem Kino unter Verwendung der automatisierten Dienste für heterogene
Geräte über mehrere
Plattformen hinweg (ASAP).
-
9 zeigt
ein beispielhaftes Verfahren zum Erhalten einer Wegbeschreibung
durch Verwendung einer Sprechschnittstelle eines Mobiltelefongeräts im Rahmen
der automatisierten Dienste für
heterogene Geräte über mehrere
Plattformen hinweg (ASAP).
-
10A zeigt die Schritte 1-3 eines beispielhaften
Verfahrens für
eine sprachinteraktive Fahrzeugassistenzanwendung.
-
10B zeigt die Schritte 4 und 5 eines beispielhaften
Verfahrens für
eine sprachinteraktive Fahrzeugassistenzanwendung.
-
11 zeigt
ein beispielhaftes Verschlüsselungsschema
zur Erhöhung
der Sicherheit.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
1A zeigt
eine beispielhafte Systemarchitektur 100 für automatisierte
Dienste über
mehrere Plattformen hinweg (ASAP) einschließlich dreier Geräte 101, 102 und 103,
eines Gerätekommunikators 104,
eines Portal-Servers 105,
eines Dienstagenten 106 und einer Datenbank 107.
-
Die
Geräte 101, 102 und 103 enthalten
eine Schicht gerätespezifischer
Software, den sogenannten Geräteagenten,
die eine übliche
Sprache (wie zum Beispiel XML (Extension Markup Language)) als Schnittstelle
mit dem Gerätekommunikator 104 unterstützt. Der
Gerätekommunikator 104 wirkt
als Gateway oder Moderator zum Koordinieren der Geräte 101, 102 und 103 in
einer lokalen Netzwerkumgebung. Der Gerätekommunikator 104 unterstützt mehrere
Kommunikationsprotokolle und Konnektivitätsstandards, so daß er in
einer Sprache (z.B. XML) mit anderen Geräten sprechen kann, aber unter
Verwendung verschiedener Protokolle und/oder Konnektivitätsstandards
(wie zum Beispiel HTTP (Hypertext Transfer Protocol), FTP (File
Transfer Protocol, SNMP (Simple Network Management Protocol), IIOP (Internet
Inter-Orb Protocol) in der CORBA (Common Object Request Broken Architecture),
SOAP (Simple Object Access Protocol) mit XML (Extension Markup Language),
Ethernet, Bluetooth, IEEE 802.11 a/b/g (WiFi), ZigBee, IrDA (Infrared
Detection and Acquisition), GPRS (General Packet Radio Service),
CDMA (Code Division Multiplexed Access) und GSM (Global System for
Mobile Communication) oder beliebige andere entsprechende Kommunikationsprotokolle oder
Konnektivitätsstandards).
Der Gerätekommunikator 104 führt außerdem Geräteregistration,
Synchronisation und Benutzerauthentisierung und Autorisierung durch.
Der Geräteagent
gibt dem Anwendungsprogrammierer eine „vereinfachte" Möglichkeit zur
Kommunikation mit dem Gerätekommunikator 104.
Der Gerätekommunikator 104 gewährt eine nahtlose
Integration und Synchronisation zwischen den Geräten 101, 102 und 103 in
dem lokalen Netzwerk. Anstatt einzelne Geräte direkt (Punkt zu Punkt) mit
einem Netzwerk wie zum Beispiel dem Internet, zu verbinden, um Dienste
zu erhalten, stellt der Gerätekommunikator 104 daher
eine „Middleware"-Lösung
bereit, die Protokoll- und Konnektivitätsdetails vor dem Gerät verbirgt.
Dienste zum Beispiel aus dem Internet können folglich bereitgestellt
werden, ohne daß man
sich über
die zukünftige
Entwicklung neuer Protokolle, Dienste und Konnektivität sorgen muß.
-
Um
Dienste von externen Quellen zu erhalten, stellt der Gerätekommunikator 104 auf
der Basis der von den mehreren Geräten 101, 102 und 103 gesammelten
Informationen über
den Geräteagenten eine
Anforderung und gibt die Anforderung an den Portal-Server 105 aus.
In dieser Hinsicht kann angenommen werden, daß der Gerätekommunikator 104 bei
der Anforderung zur Erhaltung von Web-Diensten eine bessere Fähigkeit
aufweist. Der Portal-Server 105 wirkt als Proxy/Gateway,
um Web-Dienste von vielfältigen Inhaltsquellen
anzufordern, aufzubrauchen und/oder zu verteilen. In dieser Hinsicht
kann die Identität
der Person geschützt
werden, weil der Portal-Server 105 die Dienstanforderung über den Dienstagenten 106 im
Namen des Benutzers ausgibt. Außerdem
können
vielfältige
Dienste zusammengestellt und Cache-gespeichert werden, wodurch eine
schnellere Ansprechzeit und eine bessere Benutzung von Netzwerkbandbreite
gewährleistet werden.
Wenn zum Beispiel Benutzer A das heutige Wetter an einer bestimmten
Postleitzahl anfordert und Benutzer B in derselben Leitzahl zufällig dieselbe Anforderung
tätigt,
kann das Ergebnis unmittelbar zurückgegeben werden.
-
Der
Portal-Server 105 kann Informationen bezüglich der
Geräte
und/oder Dienstanbieter speichern. In dieser Hinsicht kann der Portal-Server 105 eine
Benutzerprofildatenbank 107 enthalten, die eine aktualisierte
Kopie des Benutzerprofils und von Anwendungsdaten führt, so
daß intelligente
Inhaltsdienste und Synchronisation zwischen verschiedenen Geräten bereitgestellt
werden können.
In einer drahtlosen Netzwerkumgebung ist die Verfügbarkeit möglicherweise
nicht immer garantiert, so daß ein anderer
Mechanismus, wie zum Beispiel eine Warteschlangenstruktur, erforderlich
sein kann, um die Daten, Profile und Ergebnisse zum späteren Abrufen
zu sichern.
-
Gemäß einer
beispielhaften Ausführungsform
des ASAP-Systems
kann ein PDA-Gerät,
das zum Beispiel mit einer Schnittstelle gemäß IEEE 802. 11b ausgestattet
ist, SMS-Nachrichten
(Short Message Service) über
den Gerätekommunikator 104 prüfen und
senden, ohne es mit einem Mobiltelefon verbinden oder Infrarot-Ports
ausrichten zu müssen. In
dieser Hinsicht kann der Gerätekommunikator 104 im
Namen des PDA-Geräts
mit dem mobilen Telefon kommunizieren.
-
Gemäß einer
anderen beispielhaften Ausführungsform
unterstützt
der Gerätekommunikator 104 beide
Standards IEEE 802.11b und Bluetooth.
-
Gemäß einer
weiteren beispielhaften Ausführungsform
können
die Kommunikationsnachrichten zwischen den Geräten 101, 102 und 103,
dem Gerätekommunikator 104 und/oder
dem Portal-Server 105 komprimiert werden, um die Datentransferrate
zu erhöhen.
Insbesondere kann die Datenkomprimierung erforderlich sein, um Bandbreiteneinschränkungen
zu genügen.
-
Gemäß einer
weiteren beispielhaften Ausführungsform
kann die Kommunikation zwischen den Geräten 101, 102 und 103,
dem Gerätekommunikator 104 und/oder
dem Portal-Server 105 verschlüsselt werden, so daß die Sicherheit
der ausgetauschten Daten erhöht
werden kann.
-
1B zeigt
eine beispielhafte, durch den Portal-Server 105 durchgeführte Zusammenstellung 150 von
Inhaltsdaten von Dienstanbietern 151 bis 152,
darunter zum Beispiel ein Web-gestütztes Verzeichnis (z.B. die über yahoo.com
verfügbaren
Auflistungen der „gelben" oder „weißen" Seiten), ein geographischer
Karten-/Ortsfindungsdienst,
ein Flugreisenreservierungssystem, ein Hotelreservierungssystem,
ein Ticket-Kaufsystem, ein Web-gestützter Server, eine kommerzielle
Website, ein Spieldienst usw. Im Gegensatz zu einem Client/Server-Ansatz, der
möglicherweise
Inhaltsdaten nur in einem unflexiblen und/oder komplizierten Format
für alle
Geräte bereitstellen
kann, stellt der Portal-Server 105 Inhaltsdaten
auf eine Weise zusammen, die bezüglich der
registrierten Fähigkeiten
des Geräts „personalisiert" oder konfiguriert
ist, so daß eine
diverse Menge von Geräten über mehrere
Plattformen hinweg unterstützt
werden kann.
-
2A zeigt
ein beispielhaftes Verfahren 200 gemäß der vorliegenden Erfindung.
Im Schritt S11 registrieren sich die Geräte 101, 102 and 103 bei dem
Gerätekommunikator 104,
wobei Informationen bezüglich
der Fähigkeiten
des Geräts
bereitgestellt werden, darunter zum Beispiel die Speichergröße, Verarbeitungskapazität und unterstützte Protokolle und
Konnektivitäten.
Im Schritt S12 verarbeitet der Gerätekommunikator 104 Dienstanforderungen
von den Geräten 101, 102 und 103.
In dieser Hinsicht kann der Gerätekommunikator 104 die
Dienstanforderungen erweitern und/oder diese kollektiv kombinieren,
bevor die Anforderung an einen Dienstagenten 106 ausgegeben
wird, der eine Schnittstelle mit einem oder mehreren Dienstanbietern 151 bis 154 aufweist.
Nach dem Empfang einer oder mehrerer Antworten von den Dienstanbietern 151 bis 154 über den
Dienstagenten 106 wird sie von dem Gerätekommunikator 104 „zurechtgeschnitten", um den entsprechenden
Dienstfähigkeiten
zu entsprechen, bevor sie an das entsprechende Gerät weitergeleitet
wird. Die Geräte 101, 102 und 103 geben
daher Anforderungen in ihrem eigenen Namen aus und empfangen Antworten
individuell gemäß ihren
bestimmten Fähigkeiten,
während
der Gerätekommunikator 104 Anforderungen/Antworten
anpaßt
und kombiniert, um die Kommunikationseffizienz zu vereinfachen und/oder
zu verbessern.
-
Darüber hinaus
werden im Schritt S13 Daten automatisch synchronisiert, um einen
einheitlichen Zustand der Geräte
aufrechtzuerhalten, unabhängig zum
Beispiel von Netzwerkverfügbarkeit
und/oder unzuverlässigen
Netzwerken.
-
2B zeigt
ein beispielhaftes Verfahren 201 gemäß der vorliegenden Erfindung.
Im Schritt S21 fordern ein oder mehrere Geräte, wie zum Beispiel ein PDA
und ein Mobiltelefon eine Registration bei dem Gerätekommunikator 104 an.
Im Schritt S22 registriert der Gerätekommunikator 104 die
Geräte, einschließlich ihrer
Konnektivitäts-
und Protokollsfähigkeiten.
Während
der Registration bestimmt der Gerätekommunikator 104 zum
Beispiel, daß der
PDA den Konnektivitätsstandard
IEEE 802.11b unterstützt und
das Mobiltelefon Bluetooth- und SMS-Nachrichtenverarbeitung unterstützt. Im
Schritt S23 kann ein Gerät
(wie zum Beispiel der PDA) eine von einem anderen Gerät unterstützte Anwendung
auslösen
und der zugeordnete Geräteagent
kommuniziert mit dem Gerätekommunikator 104.
Zum Beispiel kann der PDA auslösen,
daß eine
Anwendung SMS-Nachrichten sendet und empfängt und der dem PDA zugeordnete
Geräteagent
kann (hinter der Szene) eine Nachricht zu dem Gerätekommunikator 104 senden.
Im Schritt S24 empfängt
der Gerätekommunikator 104 die
Anforderung und sucht nach einem registrierten Gerät, das diese
Anwendung unterstützt.
Zum Beispiel durchsucht der Gerätekommunikator 104 eine Gerätetabelle
und findet, daß das
Mobiltelefon in dem lokalen Netzwerk in der Lage ist, SMS-Nachrichten zu verarbeiten.
Im Schritt S25 leitet der Gerätekommunikator 104 die
Anwendungsanforderung weiter. Zum Beispiel kann der Gerätekommunikator 104 auslösen, daß das Mobiltelefon
die SMS-Nachricht sendet. Im Schritt S26 leitet der Gerätekommunikator 104 die
Anwendungsantwort zu dem anfordernden Gerät weiter. Zum Beispiel kann
der Gerätekommunikator 104 die
SMS-Antwortnachricht von dem Mobiltelefon zu dem PDA weiterleiten.
In dieser Hinsicht kann das beispielhafte System dem PDA einen transparenten
SMS-Dienst bereitstellen.
Vom Standpunkt des Benutzers aus gesehen sendet und empfängt der
Benutzer SMS- Nachrichten
von einem PDA, aber der PDA kann die SMS-Nachrichtenverarbeitung nicht alleine
durchführen.
Die Technologie ist transparent und ermutigt den Benutzer, den Dienst öfter zu benutzen,
wodurch ein größeres Umsatzpotential
erzeugt werden kann, wodurch wiederum der Nutzen entsteht, neue
Produkte und Dienste bereitzustellen, sowie weitere Nutzen.
-
Das
beispielhafte Verfahren 200 kann auf das Drucken von Dokumenten
angewandt werden. Man nehme zum Beispiel an, daß ein Dokument von einem PDA
auf einem Netzwerkdrucker ausgedruckt werden soll. Anstatt das Dokument
in einen PC (Personal Computer) herunterzuladen und die Druckoperation
von dem PC aus auszulösen,
kann als Alternative eine Druckanforderung (zum Beispiel unter Verwendung
des Standards IEEE 802.11b) zu dem Gerätekommunikator 104 gesendet
werden, der in einem lokalen Zugangspunkt installiert sein kann
(einem sogenannten Hot Spot). Der Gerätekommunikator 104 kann
dann die Eingangsanforderung analysieren und das Dokument direkt
(z.B. über
ein verdrahtetes Netzwerk) zu dem Netzwerkdrucker weiterleiten,
ohne über
den PC zu gehen, wodurch anonyme Dienste auf benutzertransparente
Weise bereitgestellt werden.
-
3 zeigt
eine beispielhafte Konfiguration 300 zur Bereitstellung
einer effizienten Bandbreitenbenutzung und verbesserten Netzwerklatenz.
Die beispielhafte Konfiguration 300 enthält ein Gerät 301, das über eine
GPRS-Strecke, die eine Datentransferrate von 14,4 kbps unterstützt, mit
dem Internet 302 und über
ein lokales Netzwerk, das den Bluetooth-Standard verwendet und eine
Datentransferrate von ungefähr
1 MBps unterstützt,
mit einem Gerätekommunikator
an einem Zugangspunkt 303 verbunden ist. Der Zugangspunkt 303 ist über eine
Strecke, die eine Datentransferrate von 1,5 MBps unterstützt, mit
dem Internet verbunden. Die beispielhafte Konfiguration 300 gestattet
es dem Gerät 300,
durch den Zugangspunkt 303 eine Dienstanforderung zu dem
Internet 302 weiterzuleiten, um so eine potentielle Zunahme
des Datendurchsatzes und eine niedrigere Netzwerklatenz bereitzustellen.
-
Das
beispielhafte ASAP-System kann anstatt auf einem Client-Server-Ansatz
auf einer peer-to-peer-Architektur (P2P) basieren. Bei dieser beispielhaften
Architektur gehört
jedes teilnehmende Gerät,
d.h. jeder Peer, zu einer Peer-Gruppe, wie zum Beispiel einer lokalen
Impromptu-Netzwerkumgebung, die durch nahegelegene Geräte durch
Authentisierung und Autorisierung gebildet wird. Jedes Gerät besitzt
einen Geräteagenten,
der mit einem Gerätekommunikator
kommunizieren kann, der zum Beispiel auf einem anderen Gerät verankert
ist. Der Gerätekommunikator
kann außerdem
als ein Geräteagent
fungieren, mit der Ausnahme, daß er
zusätzlich
für die
Gerätesynchronisation,
Geräteregistration,
Authentisierung, Autorisierung und das Erhalten von Diensten von
Dienstanbietern verantwortlich sein kann. Der Gerätekommunikator
kann die Dienstanforderungen von jedem Gerät zusammenstellen, um eine
einzige Anfrage zu bilden, und es kann gefordert werden, daß er eine
geeignete Konnektivität/Bandbreite
zu dem Dienstanbieter besitzt, um Antworten zu erhalten. Um unzuverlässige Netzwerke
zu berücksichtigen,
kann der Gerätekommunikator
außerdem
die Anforderungen und Ergebnisse Cache-speichern, so daß, wenn
die Geräte
getrennt werden, ein Neuverbinden und Neusenden der Anforderung durchgeführt werden
kann. Gemäß einer
beispielhaften Ausführungsform
sollte mindestens ein Gerätekommunikator
in der Peer-Gruppe existieren. Während
sich Geräte
dem Netzwerk anschließen
und dieses verlassen, können
sich ihre Rollen ändern.
Zum Beispiel kann ein fähigeres
Gerät (z.B.
mit schnellerer Konnektivität
oder höherer
Datenverarbeitungsleistung) zu dem Gerätekommunikator werden und den
existierenden ersetzen (siehe zum Beispiel 4). Das
Hands-off-Protokoll
sollte anderen Peers (Geräten)
transparent sein. Daher kann eine flexible und dynamische Netzwerktopologie
bereitgestellt werden.
-
4 zeigt
eine beispielhafte ASAP-Netzwerktopologie, bei der Netzwerkgeräte sich
dynamisch mit dem Netzwerk assoziieren und disassoziieren können. Die
beispielhafte Netzwerktopologie enthält einen ersten Zustand 401 und
einen zweiten Zustand 402. Im ersten Zustand 401 des
beispielhaften Netzwerks wirkt das Gerät C als Gerätekommunikator, um den Geräten A und
B, die als Geräteagenten
wirken, automatisierte Dienste bereitzustellen. Im zweiten Zustand 402 des
beispielhaften Netzwerks schließt
sieh ein fähigeres
Gerät D
an und ersetzt das Gerät
C als Gerätekommunikator,
so daß das
Gerät D
Berechnungs- und Konnektivitätsbestimmungen für die anderen
Geräte
A, B und C durchführt.
-
5 zeigt
eine beispielhafte ASAP-Architektur 500 mit vier Schichten:
einer Konnektivitätsschicht 501,
einer Protokollschicht 502, einer Kernschicht 503 und
einer Dienstschicht 504. Die Konnektivitätsschicht 501 liefert
Konnektivitätsunterstützung zwischen
Geräten
und enthält
zum Beispiel Konnektivitätsstandards
wie etwa Bluetooth, IrDA, 802.11 (WiFi), ZigBee, GPRS/GSM/CDMA und
Ethernet. In dieser Hinsicht kann der Geräteagent zum Beispiel einen
Konnektivitätsstandard
unterstützen,
während ein
Gerätekommunikator
mehrere Konnektivitätsstandards
unterstützen
sollte, um mehr als ein Gerät zu
versorgen. Die Protokollschicht 502 liefert Protokollunterstützung für standardisierte
und/oder proprietäre
Protokolle, darunter zum Beispiel HTTP, FTP, SNMP, SOAP und IIOP/CORBA.
Die Kernschicht 503 liefert Verwaltung, Synchronisation
und Sicherheit, darunter zum Beispiel Geräteverwaltung, Verbindungsverwaltung,
Gerätesynchronisation,
Authentisierung und Autorisierung. Die Dienstschicht 504 liefert
Anwendungsdienste, wie zum Beispiel Entdeckung, Publikation/Abonnement
und/oder Geräteinformationsdienste.
-
Ein
Teil der Dienste/Standards/Protokolle, die den Schichten zugeordnet
sind, kann wegen Bandbreiten- und rechnerischen Einschränkungen möglicherweise
nur in dem Gerätekommunikator
unterstützt
sein. Der Gerätekommunikator 104 ist
für die Verbindung
mit dem Dienstanbieter verantwortlich. Somit kann zum Beispiel von
dem Gerätekommunikator 104 gefordert
werden, das HTTP- oder das SOAP-Protokoll zu unterstützen, während der
Geräteagent
XML oder CORBA unterstützen
kann. Die Kernschichtdienste sind hauptsächlich Komponenten des Gerätekommunikators,
da er die lokale Geräteumgebung
verwaltet, eine Liste von Verbindungen führt und Synchronisation zwischen
den Geräten durchführt. Sicherheit
ist eine Kernkomponente in der Kernschicht 503, da von
jedem Gerät
gefordert werden kann, sich durch Authentisierung und Autorisierung
bei dem Gerätekommunikator
zu registrieren.
-
Die
Kommunikation zwischen Prozessen in einer heterogenen verteilten
Umgebung kann die Unterstützung
verschiedener Sprachenbindungen (z.B. C, C++, Java usw.), verschiedener
Protokolle (z.B. HTTP, IIOP, RMl, HTTPS, SOAP, XML, XML-RPC usw.)
und verschiedener Rahmen (z.B. CORBA, OS-Sockets, JMS, Java-Objektserialisierung
usw.) erfordern. Um die Last von Anwendungsprogrammierern, die Komponenten
für das
System schreiben, zu erleichtern, wird eine leichtgewichtige Schicht
bereitgestellt, die die Vernetzung- und Systemprobleme zur effizienten
Kommunikation abstrahiert oder vereinfacht. Anstatt für jedes
Modul Wrapper/Adapter herzustellen, damit jedes Protokoll mit anderen
Modulen kommunizieren kann, was umständlich und fehleranfällig sein
kann, kann eine vereinfachte Anwendungsprogrammierschnittstelle
(API) bereitgestellt werden, damit diese gesamte Kommunikation transparent
wird. Um die oben erwähnten
Anforderungen zu unterstützen,
kann in der Protokollschicht 502 eine nachrichtenorientierte
Middleware (MoM) bereitgestellt werden.
-
Die
nachrichtenorientierte Middleware (MoM) kann als eine Software implementiert
werden, die kontinuierlich abläuft
(z.B. als Server-Middleware wirkt), um den Austausch von Nachrichten
zwischen Veröffentlichern
(diejenigen, die „ansagen") und Teilnehmern
(diejenigen, die „zuhören") zu regulieren und
zu ermöglichen.
Die Nachricht kann mit XML-codierten Metainformationen beschrieben
werden. Nachrichtendaten können
einfachen ASCII-Text, GIF-Bilder, XML-Daten, Java-Objekte oder beliebige andere
binär codierte
Daten umfassen. Andere Protokolle, wie zum Beispiel Email oder SOAP,
können später eingesteckt
werden, ohne irgendwelche Änderungen
an dem Client-Code vorzunehmen. Die MoM kann einen großen Teil
der Vernetzungsprotokoll- und Betriebssystemprobleme verbergen,
wodurch die Last des Aufrechterhaltens der Sockets-Kommunikation
und der Sitzungsverwaltung von Programmierern erleichtert wird.
-
Die
Dienstschicht 504 kann ein schnelles Schreiben von Anwendungen
ermöglichen,
indem die ASAP-Plattform gestärkt
wird. Das Entdeckungsdienstmodul ermöglicht es einem Geräteagenten,
einen Gerätekommunikator
zu entdecken und eine Verbindung für Dienstanforderungen und -antworten und
Synchronisation einzurichten. Ein Geräteinformationsdienst liefert
Informationen bezüglich
Gerätefähigkeiten,
so daß eine
Dienstanforderung von mehreren Geräten zusammengestellt werden
kann. In dieser Hinsicht können
sich Anwendungsentwickler auf dienstorientierte Geschäftslogik
konzentrieren, anstatt Netzwerkverbindungen einzurichten und zu warten
und Geräte
zu synchronisieren.
-
6 zeigt
Pseudocode zur Implementierung eines beispielhaften Teilnehmer-/Veröffentlicher-Steuerflusses.
-
7 zeigt
ein Flußdiagramm
für ein
beispielhaftes Verfahren zum Entdecken eines Geräts mit einer Umgebung, die
automatisierte Dienste über mehrere
Platt formen hinweg (ASAP) bereitstellt. Im Schritt S71 erscheint
ein Geräteagent
zunächst
in einem Netzwerk. Im Schritt S72 durchsucht der Geräteagent
den lokalen Cache-Speicher nach Informationen über den Gerätekommunikator. Wenn die Informationen
gefunden werden, versucht das Gerät im Schritt 573,
den Gerätekommunikator
zu kontaktieren und eine Verbindung einzurichten. Wenn dagegen die
Informationen nicht gefunden werden, wird im Schritt S74 eine Entdeckungsanforderung
gesendet. Zum Beispiel kann in einer TCP/IP-Umgebung die Entdeckungsanforderung über eine
Rundsendung oder ein Multicast gesendet werden. In dieser Hinsicht
sendet der Geräteagent
eine Entdeckungsanforderung aus und alle Geräte in der Netzwerkumgebung
sollten die Nachricht empfangen und entsprechend antworten. Im Schritt
S75 untersucht der Geräteagent
die Antworten, um den Gerätekommunikator
zu bestimmen und/oder zu bestätigen.
Wenn der Geräteagent
die Gerätekommunikation
nicht entdeckt, nimmt das System in Schritt S76 an, daß sich zur
Zeit kein Gerätekommunikator
in der Netzwerkumgebung befindet, und das Aussenden einer Entdeckungsanforderung
wird wiederholt. Wenn dagegen der Geräteagent den Gerätekommunikator
entdeckt, wird im Schritt S77 das Verbindungs-Token (eine XML-Nachricht,
die angibt, wo sich der Gerätekommunikator
befindet und wie er kontaktiert werden kann) zur späteren Benutzung
in dem Cache-Speicher gesichert. Der Cache-Speicher kann ein schnelleres
Entdecken ermöglichen,
aber er kann auch aufgrund des Merkmals, daß sich Geräte dem Netzwerk anschließen und
dieses verlassen können,
ablaufen. Deshalb kann eine Lebensdauer (TTL – time-to-live) angebunden werden, so daß nach einem
bestimmten Zeitraum die Cache-gespeicherten Daten als abgelaufen
betrachtet werden können.
Außerdem
kann eine Prüfung
durchgeführt
werden, um sicherzustellen, daß das
Gerät existiert,
bevor eine Netzwerkverbindung eingeleitet wird.
-
Das
beispielhafte ASAP-System kann Veröffentlichungsdienste bereitstellen.
Wenn zum Beispiel ein Geräteagent
einen Dienst anfordert, kann er eine Dienstanforderung an den Gerätekommunikator
veröffentlichen,
die danach als ein Token bezeichnet wird. Das Token ist ein Behälter, der
von einem Geräteagenten
zu dem Gerätekommunikator
weitergeleitet werden kann, und umgekehrt. Zur Bereitstellung eines
verallgemeinerten Formats kann XML verwendet werden, um eine leicht
erweiterbare und hierarchische Darstellung zu gewährleisten.
Mit XML kann man außerdem
Informationen von anderen Agenten zusammenstellen und Ergebnisse über den
Gerätekommunikator
von Dienstanbietern zu Geräteagenten
zurücksenden.
-
Ein
beispielhaftes ASAP-System kann die Anforderungen der mehreren Geräte zusammenstellen.
Um zum Beispiel eine Dienstanforderung zu versorgen, kann gefordert
werden, daß die
Geräte
zusammengestellte Informationen bereitstellen. Da jedes Gerät verschiedene
Fähigkeiten
aufweisen kann, kann gefordert werden, daß im Namen des Gerätes, das
den Dienst eingeleitet hat, eine neue Anforderung konstruiert wird.
Wie in dem PDA-Beispiel erläutert
wurde, können
die Mobiltelefonfähigkeiten
und PDA-Funktionen kombiniert werden, um die Anforderung abzuschließen. Im
Gegensatz zu einem Client-Server-Modell,
das erfordern kann, daß Benutzer alle
obigen Schritte durchführen,
um verschiedene Informationen von jedem Gerät zu erhalten, diese in dem
Web-Browser einzutippen und die Ergebnisse zurückzulesen, verwendet ein beispielhaftes ASAP-System
einen peer-to-peer-Ansatz,
bei dem jedes Gerät
durch den Gerätekommunikator
koordiniert wird, und ermöglicht
somit die dienstorientierte Architektur.
-
Ein
beispielhaftes ASAP-System kann außerdem Abonnementdienste bereitstellen.
Zum Beispiel können
in einem Veröffentlichungs-/Abonnement-Modell
mehrere Geräte
ein interessiertes Ereignis (z.B. Kalenderereignis) auch dann abonnieren, wenn
nur ein Gerät
die Anforderung stellt. In dieser Hinsicht können die Geräte, die
ihr Interesse an bestimmten Ereignissen zeigen, aktualisiert werden, ohne
das Netzwerk mit redundanten Paketen zu überschütten. Während des Abonnements kann
das Gerät
außerdem
die Priorität
erwähnen,
die einen effizienteren Zugriff bereitstellt (z.B. kann der Gerätekommunikator
die Ergebnisse in einer einzigen Sendeoperation aufstapeln, anstatt
jedes Gerät
zu jeder Anforderung zu aktualisieren). Dadurch kann der Nutzen
des Optimierens der Netzwerkbenutzung sowie des Verringerns der
Latenz bereitgestellt werden.
-
Wie
in der Beschreibung des Abonnierens von Ereignissen erwähnt, kann,
wenn die Ergebnisse zurückkommen,
der Gerätekommunikator
außerdem die
Geräte
in der Netzwerkumgebung synchronisieren, um sie auf dem neuesten
Stand zu halten. In dieser Hinsicht müssen Benutzer Geräte nicht
unbedingt explizit synchronisieren.
-
8 zeigt
ein beispielhaftes Verfahren 800 zum Bestellen eines Filmtickets
von einem nahegelegenen Kino und zum Erhalten einer Wegbeschreibung
zu dem Kino. Im Schritt S80 erfolgt eine Geräteregistration. Das registrierte
Gerät kann
zum Beispiel ein PDA, ein Mobiltelefon oder eine Kombination davon
sein. Im Schritt S81 wird eine Anforderungsnachricht von dem PDA-Gerät unter
Verwendung eines lokal unterstützten
Formats, wie zum Beispiel XML, über
WiFi zu dem Gerätekommunikator gesendet.
Im Schritt S82 sendet der Gerätekommunikator
eine Anforderungsnachricht in einem von dem Mobiltelefon unterstützten Format,
wie zum Beispiel XML, über
Bluetooth zu dem Mobiltelefongerät, um
seine geographische Position zu identifizieren. In Schritt S83 antwortet
das Mobiltelefongerät,
das mit einem GPS ausgestattet ist, auf die Anforderung. Im Schritt 584 konstruiert
der Gerätekommunikator
eine Anforderung unter Verwendung der von dem PDA- und dem Mobiltelefongerät gelieferten
Informationen. Im Schritt S85 wird über einen Zugangspunkt eine Anforderung
zu einem entsprechenden Server gesendet. Im Schritt S86 empfängt der
Zugangspunkt eine Antwort von dem entsprechenden Server und leitet
sie zu dem Gerätekommunikator
weiter. Im Schritt S87 sendet der Gerätekommunikator ein Ergebnis
zu dem PDA-Gerät.
-
9 zeigt
ein beispielhaftes Verfahren 900 zum Erhalten einer Wegbeschreibung
unter Verwendung einer Sprachschnittstelle eines Mobiltelefongeräts. Im Schritt
S90 erfolgt Geräteregistration.
Das registrierte Gerät
kann zum Beispiel einen PDA, ein Mobiltelefon oder eine Kombination
davon umfassen. Im Schritt S91 sendet das Mobiltelefongerät eine Dienstanforderungsnachricht
in einem lokal unterstützten
Format (wie zum Beispiel XML) zu dem Gerätekommunikator. Im Schritt
S92 sendet der Gerätekommunikator
in einem geeigneten Format (wie zum Beispiel XML) über GPRS
eine Anforderung zu einem entsprechenden Anbieter. Im Schritt S93
empfängt
der Gerätekommunikator
eine Antwort. Im Schritt S84 werden das Mobiltelefongerät und das PDA-Gerät mit Adresseninformationen
bezüglich
der Anforderung synchronisiert.
-
10a und 10b zeigen
ein beispielhaftes Verfahren für
eine sprachinteraktive Fahrzeugassistenzanwendung. Im Schritt 1 zeigt
ein Signal auf der Instrumententafel ein Problem an und es werden Behelfsvorschläge auf einem
Display gezeigt. In Schritt 2 leitet der Fahrer über Sprachsteuerung
eine Funktionssequenz ein. In Schritt 3 wird die aktuelle Position
des Autos bestimmt und über
ein zellulares Funkgerät
zu einem Dienstanbieter gesendet. Im Schritt 4 verarbeitet
der Anbieter die Anfrage und gibt eine Liste möglicher Dienstoptionen zurück. Im Schritt 5 aktiviert
ein Sprachbefehl die Navigation.
-
11 zeigt
ein beispielhaftes Verschlüsselungsschema 1100 zum
Erhöhen
der Sicherheit, wobei ein Gerätekommu nikator 104 über ein
Netzwerk eine verschlüsselte
Anforderung zu einem Dienstagenten 106 des Portal-Servers 105 sendet.