DE602005005435T2 - System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen - Google Patents

System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen Download PDF

Info

Publication number
DE602005005435T2
DE602005005435T2 DE602005005435T DE602005005435T DE602005005435T2 DE 602005005435 T2 DE602005005435 T2 DE 602005005435T2 DE 602005005435 T DE602005005435 T DE 602005005435T DE 602005005435 T DE602005005435 T DE 602005005435T DE 602005005435 T2 DE602005005435 T2 DE 602005005435T2
Authority
DE
Germany
Prior art keywords
message
application
subsystem
server
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602005005435T
Other languages
English (en)
Other versions
DE602005005435D1 (de
Inventor
Michael Richmond Hill Shenfield
Brindusa Toronto Fritsch
Viera Kilbride Bibr
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Publication of DE602005005435D1 publication Critical patent/DE602005005435D1/de
Application granted granted Critical
Publication of DE602005005435T2 publication Critical patent/DE602005005435T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Circuits Of Receivers In General (AREA)

Description

  • Die vorliegende Erfindung bezieht sich allgemein auf ein Kommunikationssystem zur Bereitstellung der Kommunikation zu einer Vielzahl von Geräten und insbesondere auf ein System und ein Verfahren zur Verwaltung der Kommunikation mit Komponentenanwendungen auf solchen Geräten.
  • Aufgrund der wachsenden Verbreitung von Drahtlosnetzen sind heutzutage eine immer größer werdende Anzahl von Drahtlosgeräten in Benutzung. Zu diesen Geräten zählen Mobiltelefone, PDAs (Personal Digital Assistants) mit Fähigkeit zur Drahtloskommunikation, Zweiwege-Pager und dergleichen. Parallel zur wachsenden Verfügbarkeit von Drahtlosgeräten hat sich die Nützlichkeit von Software-Anwendungen erhöht, die auf solchen Geräten ausgeführt werden. Beispielsweise kann das Drahtlosgerät eine Anwendung enthalten, die einen Wetterbericht für eine Liste von bevorzugten Städten abruft, oder eine Anwendung, die es einem Benutzer ermöglicht, Lebensmittel einzukaufen. Diese Software-Anwendungen nutzen die Fähigkeit des Drahtlosnetzes zur Datenübertragung, um den Benutzern zeitnahe und nützliche Dienste verfügbar zu machen, oft zusätzlich zur Sprachkommunikation. Allerdings bleibt die Entwicklung von Software-Anwendungen angesichts einer Überfülle von unterschiedlichen Gerätetypen, angesichts der beschränkten Ressourcen von einigen Geräten und angesichts der Komplexität der Zustellung großer Datenmengen zu den Geräten eine schwierige und zeitaufwändige Aufgabe.
  • Gegenwärtig sind die Geräte so konfiguriert, dass sie über Internet-basierte Browser und/oder native Anwendungen mit Webdiensten kommunizieren. Die Browser haben den Vorteil, dass sie für den Betrieb auf einer plattformübergreifenden Basis für eine Vielzahl von unterschiedlichen Geräten eingerichtet werden können, haben jedoch den Nachteil, dass sie Seiten (Bildschirmdefinitionen in HTML) von dem Webdienst benötigen, was die Persistenz der in den Bildschirmen enthaltenen Daten behindert. Ein weiterer Nachteil von Browsern besteht darin, dass die Bildschirme zur Laufzeit wiedergegeben werden, was ressourcenintensiv sein kann. Anwendungen für Browser sind effiziente Werkzeuge zum Gestalten plattformunabhängiger Anwendungen. Dementsprechend führen unterschiedliche Laufzeitumgebungen – unabhängig von der jeweiligen Plattform – dieselbe Anwendung aus. Da verschiedene Drahtlosgeräte jedoch über unterschiedliche Fähigkeiten und Formfaktoren verfügen, kann die Anwendung möglicherweise nicht wie gewünscht angezeigt werden. Außerdem benötigen browserbasierte Anwendungen oft eine erhebliche Übertragungsbandbreite, um effizient arbeiten zu können, was für einige Mobilgeräte teuer oder sogar unmöglich sein kann.
  • Auf der anderen Seite werden native Anwendungen für eine spezielle Plattform von Drahtlosgeräten entwickelt, wodurch für eine Laufzeitumgebung, die auf dieser Plattform ausgeführt wird, ein relativ optimiertes Anwendungsprogramm ermöglicht wird. Eine plattformabhängige Anwendung führt jedoch zu mehreren Hindernissen, wozu gehört, dass mehrere Versionen derselben Anwendung entwickelt werden müssen und dass diese eine relativ große Größe haben, wodurch Speicherressourcen des Drahtlosgeräts beansprucht werden. Außerdem benötigen Anwendungsentwickler Erfahrungen auf dem Gebiet von Programmiersprachen wie Java und C++, um derartige native Anwendungen erstellen zu können.
  • US2002/032783 offenbart eine Anwendungsarchitektur, die sich auf das Anwenden einer Schnittstelle für Geräte bezieht, die mithilfe einer Vielzahl von unterschiedlichen Kommunikationsprotokollen kommunizieren können. Diese Entgegenhaltung lehrt das Bereitstellen einer Anwendung, die auf einem Server ausgeführt wird, um Anforderungen von den Geräten zu bedienen. Wenn eine bediente Anforderung die Kommunikation mit einem gemeinsam verwendeten Dienst erforderlich macht, wird eine Messaging-Komponente instantiiert, um die Kommunikation zu ermöglichen. Die Messaging-Komponente ruft den Namen des gewünschten gemeinsam verwendeten Dienstes sowie den Funktionsamen aus der Nachricht ab und richtet eine entsprechende Kommunikation mit dem gemeinsam verwendeten Dienst ein. Diese Entgegenhaltung lehrt jedoch nicht die Verwendung einer Kommunikationszuordnung und eines Ursprungs der Nachricht zur Ermittlung des Nachrichtenziels.
  • WO03/017055 offenbart ein System zur Erleichterung der Abwicklung von Kreditkartentransaktionen. Das System besteht aus einer Anzahl von Komponenten, die unterschiedliche Funktionsbereiche repräsentieren, zu denen ein Präsentations-Framework, Anwendungskomponenten, Anwendungsserver, Asset-Verwaltung, Datenverwaltung, Enterprise-Anwendungsintegration, Hilfsdienstverwaltung und Leistungsverwaltung gehören. In einer Anwendung wird das System durch eine Kreditkartenfirma eingesetzt, um die Verarbeitung von Kreditkartentransaktionen zu erleichtern. Das System bietet eine Plattform und die zugehörige Funktionalität, auf der verschiedene Typen von Anwendungen im Zusammenhang mit der Verarbeitung von Kreditkartentransaktionen implementiert und ausgeführt werden.
  • ALLGEMEINES
  • Die hier offenbarten Systeme und Verfahren stellen ein Kommunikationssystem zur Verwaltung der Kommunikation mit komponentenbasierten Anwendungen auf Geräten bereit, um zumindest einige der oben angeführten Nachteile zu mildern oder zu beseitigen.
  • Gemäß einem Aspekt der vorliegenden Erfindung wird ein Anwendungs-Gateway-Server zur Verwaltung der Kommunikation zwischen einer Anwendung, die in einer Laufzeitumgebung auf einem Gerät ausgeführt wird, und mindestens einem Backend-Server bereitgestellt, wobei der Anwendungs-Gateway-Server umfasst: einen Message-Listener zum Empfangen von Nachrichten von der Anwendung; ein Connector-Subsystem, umfassend eine Vielzahl von Connectoren, wobei jeder aus der Vielzahl von Connectoren der Kommunikation mit einem oder mehreren assoziierten Backend-Servern dient; ein Messaging-Subsystem, umfassend einen Message-Broker für die Bearbeitung der vom Message-Listener empfangenen Nachrichten und für deren Übertragung zu einem assoziierten aus der Vielzahl der Connectoren; wobei der Anwendungs-Gateway-Server dadurch gekennzeichnet ist, dass das Messaging-Subsystem des Weiteren eine Kommunikationszuordnung umfasst, um eine Identifizierung zu ermöglichen, welcher aus der Vielzahl von Connectoren entsprechend einem Ursprung einer Nachricht für eine Nachricht verwendet werden soll.
  • Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren zur Verwaltung der Kommunikation auf einem Anwendungs-Gateway- Server zwischen einer Anwendung, die in der Laufzeitumgebung auf einem Gerät ausgeführt wird, und mindestens einem Backend-Server bereitgestellt, wobei das Verfahren die folgenden Schritte umfasst: das Empfangen von Nachrichten von der Anwendung an einem Message-Listener; das Zuordnen der Nachrichten zu einem Ziel-Backend-Server; das Zustellen der Nachrichten zu einem Connector entsprechend dem Ziel-Backend-Server; und das Zustellen der Nachricht zu diesem Backend-Server; wobei das Verfahren dadurch gekennzeichnet ist, dass die Nachrichtenzuordnung entsprechend einer vordefinierten Kommunikationszuordnung und einem Ursprung der Nachricht durchgeführt wird.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Es erfolgt nun die Beschreibung einer Ausführungsform der Erfindung, und zwar lediglich anhand eines Beispiels und unter Bezug auf die beigefügten Zeichnungen, die folgende Bedeutung haben:
  • 1 ist ein Blockdiagramm eines Netzes, das drahtlose Komponentenanwendungen ermöglicht;
  • 2 ist ein detailliertes Blockdiagramm des Anwendungs-Gateways aus 1;
  • 3 ist ein Blockdiagramm einer Message-Listening-Anwendung;
  • 4 ist ein Blockdiagramm eines Lifecycle-Subsystems;
  • 5 ist ein Blockdiagramm eines Administrations-Subsystems;
  • 6 ist ein Blockdiagramm eines Messaging-Subsystems;
  • 7 ist ein Blockdiagramm eines Transformations-Subsystems;
  • 8 ist ein Blockdiagramm eines Connector-Subsystems;
  • 9 ist ein Blockdiagramm eines Sicherheits-Subsystems;
  • 10 ist ein Blockdiagramm eines Protokollierungs-Subsystems;
  • 11 ist ein Blockdiagramm eines Konfigurations-Subsystems;
  • 12 ist ein Blockdiagramm eines Dienstprogramm-Subsystems;
  • 13 ist ein Blockdiagramm eines Discovery-Servers;
  • 14 ist ein Blockdiagramm eines Bereitstellungs-Servers;
  • 15 ist ein Flussdiagramm und veranschaulicht die Laufzeitinitialisierung;
  • 16 ist ein Flussdiagramm und veranschaulicht den Discovery als Antwort auf eine Benutzeranforderung;
  • 17 ist ein Flussdiagramm und veranschaulicht den Discovery als Antwort auf einen Push von einem Administrator;
  • 18 ist ein Flussdiagramm und veranschaulicht den Discovery als Antwort auf einen Push von einem Dienstanbieter;
  • 19 ist ein Flussdiagramm und veranschaulicht die Bereitstellung einer Komponentenanwendung;
  • 20 ist ein Flussdiagramm und veranschaulicht die Quittung der Komponentenanwendungsinstallation;
  • 21 ist ein Flussdiagramm und veranschaulicht die Verarbeitung einer Nachricht von einer Komponentenanwendung;
  • 22 ist ein Flussdiagramm und veranschaulicht das Benachrichtigungsabonnement;
  • 23 ist ein Flussdiagramm und veranschaulicht die Zustellung einer Benachrichtigung;
  • 24 ist ein Flussdiagramm und veranschaulicht die Zustellung einer Komponentenanwendungs-Upgrade-Benachrichtigung;
  • 25 ist ein Flussdiagramm und veranschaulicht die Zustellung einer Laufzeitumgebungs-Upgrade-Benachrichtigung;
  • 26 ist ein Flussdiagramm und veranschaulicht die geplante Aufgabenzustellung; und
  • 27 ist ein Blockdiagramm und veranschaulicht eine Komponentenanwendung.
  • BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • Aus Gründen der Vereinfachung beziehen sich gleiche Bezugsziffern in der Beschreibung auf gleichartige Strukturen in den Zeichnungen. Unter Bezug auf 1 ist eine Kommunikationsinfrastruktur dargestellt, die allgemein mit der Bezugsziffer 100 bezeichnet ist. Die Kommunikationsinfrastruktur 100 umfasst eine Vielzahl von Drahtlosgeräten 102, ein Kommunikationsnetz 104, ein Anwendungs-Gateway 106 sowie eine Vielzahl von Backend-Diensten 108.
  • Die Drahtlosgeräte 102 sind typischerweise PDAs (Personal Digital Assistants), wie beispielsweise ein BlackberryTM von Research in Motion, es können jedoch auch andere Geräte sein. Jedes der Drahtlosgeräte 102 enthält eine Laufzeitumgebung, die in der Lage ist, eine Vielzahl von Komponentenanwendungen zu hosten.
  • Komponentenanwendungen umfassen eine oder mehrere Datenkomponenten, Präsentationskomponenten und/oder Nachrichtenkomponenten, die in einer strukturierten Definitionssprache wie dem XML-Code (Extensible Markup Language) geschrieben sind. Die Komponentenanwendungen können des Weiteren Workflow-Komponenten umfassen, welche eine Serie von Anweisungen enthalten, die beispielsweise in einer Untermenge von ECMAScript geschrieben sind, und die in einigen Implementierungen in den XML-Code eingebettet sein können. Daher kann aufgrund der Aufteilung der Anwendungen eine gemeinsame Anwendung für mehrere Geräte geschrieben werden, indem die entsprechenden Präsentationskomponenten bereitgestellt werden, ohne dabei die anderen Komponenten neu schreiben zu müssen. Außerdem werden große Abschnitte der Verantwortlichkeit von typischen Anwendungen auf die Anwendungsumgebung für die Komponentenanwendung übertragen. Die Details der Komponentenanwendungen werden am Ende dieser Beschreibung erläutert.
  • Die Drahtlosgeräte 102 stehen über das Kommunikationsnetz 104 in Kommunikation mit dem Anwendungs-Gateway 106. Folglich kann das Kommunikationsnetz 104 mehrere Komponenten einschließen, wie z. B. ein Drahtlosnetz 110, ein Relay 112, einen Corporate-Server 114 und/oder einen Mobildatenserver 116 zur Weiterschaltung von Daten zwischen den Drahtlosgeräten 102 und dem Anwendungs-Gateway 106.
  • Das Anwendungs-Gateway 106 umfasst einen Gateway-Server 118, einen Bereitstellungs-Server 120 und einen Discovery-Server 122. Der Gateway-Server 118 agiert als Message-Broker zwischen der Laufzeitumgebung der Drahtlosgeräte 102 und den Backend-Servern 108. Der Gateway-Server 118 kommuniziert sowohl mit dem Bereitstellungs-Server 120 als auch mit dem Discovery-Server 122. Der Gateway-Server 110 kommuniziert außerdem über eine geeignete Verbindung mit einer Vielzahl von Backend-Servern 108, wie beispielsweise Webdiensten 108a, Datenbankdiensten 108b sowie mit anderen Enterprise-Diensten 108c. Beispielsweise ist der Gateway-Server 110 über SOAP (Simple Object Access Protocol) und JDBC (Java Database Connectivity) mit den Webdiensten 108a bzw. mit den Datenbankdiensten 108b verbunden. Für den durchschnittlichen Fachmann auf dem Gebiet der Technik sind weitere Typen von Backend-Servern 108 und ihre entsprechenden Verbindungen nahe liegend.
  • Jedes Drahtlosgerät 102 ist anfänglich mit einem Dienstbuch ausgestattet, das verschiedene Protokolle und Einstellungen einrichtet, was Konnektivitätsinformationen für den Corporate-Server 114 und/oder und den Mobildatenserver 116 einschließt. Diese Parameter können eine URL (Uniform Resource Locator) für den Anwendungs-Gateway-Server 118 sowie dessen Verschlüsselungsschlüssel einschließen. Alternativ – wenn das Drahtlosgerät 102 anfänglich nicht mit der URL und dem Verschlüsselungsschlüssel ausgestattet ist – können diese über den Mobildatenserver 116 zum Drahtlosgerät 102 gepusht werden. Das Mobilgerät 102 kann dann über die URL des Anwendungs-Gateway-Servers 118 Verbindung mit dem Anwendungs-Gateway 106 aufnehmen.
  • Unter Bezug auf 2 wird eine detaillierte Ansicht von Anwendungs-Gateway 106 gezeigt. Der Anwendungs-Gateway-Server 118 enthält drei Diensteschichten; eine Basisdiensteschicht 202, eine Anwendungs-Gateway-Diensteschicht 204 und eine Anwendungsdiensteschicht 206. Der Anwendungs-Gateway-Server 118 enthält des Weiteren einen Administrationsdienst 208.
  • Durch den Bereitstellungs-Server 120 und den Discovery-Server 122 werden ein Bereitstellungsdienst 210 bzw. ein Discovery-Dienst bereitgestellt.
  • Auf der untersten Ebene bietet die Basisdiensteschicht 202 den anderen Komponenten auf den höheren Ebenen grundlegende, domänenunabhängige Systemdienste an. Damit können beispielsweise alle Subsysteme in der Anwendungs-Gateway-Diensteschicht 204 und in der Anwendungsdiensteschicht 206 die Subsysteme in der Basisdiensteschicht 202 nutzen und mit diesen zusammenarbeiten. In der vorliegenden Ausführungsform enthält die Basisdiensteschicht 202 ein Dienstprogramm-Subsystem 210, ein Sicherheits-Subsystem 212, ein Konfigurations-Subsystem 214 und ein Protokollierungs-Subsystem 216.
  • Die Anwendungs-Gateway-Diensteschicht 204 stellt domänenspezifische Drahtloskomponentenanwendungsdienste bereit. Diese Dienste ermöglichen eine effiziente Nachrichtentransformation und -zustellung zu Backend-Systemen 108 und stellen das Management von Drahtlosgerät 102 und des Komponentenanwendungs-Lifecycle bereit. In der vorliegenden Ausführungsform enthält die Anwendungs-Gateway-Diensteschicht 204 ein Lifecycle-Subsystem 220, ein Connector-Subsystem 222, ein Messaging-Subsystem 224 und ein Transformations-Subsystem 226.
  • Die Anwendungsdiensteschicht 206 steht an oberster Stelle der Architektur und stellt externe Programmschnittstellen und Benutzerschnittstellen bereit, wozu Subsysteme verwendet werden, die durch die unteren Schichten bereitgestellt werden. Beispielsweise stellen verschiedene Anwendungen wie eine Dienstanbieter-Lifecycle-Anwendung, eine Packaging-Anwendung und eine Message-Listening-Anwendung externe Programmschnittstellen bereit, weil sie in erster Linie mit Anwendungen auf externen Systeme kommunizieren. In gleicher Weise stellt eine Administrationsanwendung eine Benutzerschnittstelle bereit, indem einem Benutzer die Möglichkeit gegeben wird, auf Daten und/oder Parameter des Anwendungs-Gateways zuzugreifen und möglicherweise zu modifizieren.
  • Der Administrationsdienst 208 ist für administrative Systemnachrichten, für die Administration der Drahtlosgeräte 102, die Laufzeitadministration des Anwendungs-Gateway-Subsystems, für die Support- und Displaysystemdiagnose und für die Administration von Standardimplementierungen der Bereitstellungs- und Discovery-Dienste verantwortlich.
  • Die Komponenten des Anwendungs-Gateways 106 werden im Folgenden detailliert beschrieben.
  • Messaging-Listening-Anwendung
  • Die Messaging-Listening-Anwendung stellt eine Schnittstelle zum Empfang von Nachrichten sowohl von den Drahtlosgeräten 102 als auch von externen Quellen und für deren Weiterleitung zum Messaging-Subsystem bereit. Außerdem übernimmt die Message-Listening-Anwendung typischerweise die Authentifizierung der Gültigkeit der Nachrichtenquelle.
  • Unter Bezug auf 3 wird die Message-Listening-Anwendung detailliert dargestellt. Die Message-Listening-Anwendung umfasst drei Listener; einen Benachrichtigungs-Listener 302, einen Kompakt-Message-Listener 304 und einen Mobildatendienst-Quittungs-Listener 306. Der Benachrichtigungs-Listener 302 empfängt über eine Benachrichtigungsschnittstelle 303 Benachrichtigungs- und Antwortnachrichten von Ereignisquellen 108c.
  • Die Benachrichtigungsschnittstelle 303 kann beispielsweise mithilfe von WS Eventing (Web Service) implementiert werden. Webdienste wollen oft Nachrichten empfangen, wenn Ereignisse in anderen Diensten wie den Ereignisquellen und Anwendungen auftreten. Ein Mechanismus zur Registrierung des Interesses ist durch WS Subscription beim Stand der Technik bereits bekannt. WS Subscription definiert ein Protokoll für einen Webdienst, der als ein Abonnent bezeichnet wird, um bei einem anderen Webdienst, der als eine Ereignisquelle bezeichnet wird, das Interesse am Empfang von Nachrichten zu Ereignissen, die als Benachrichtigungen bezeichnet werden, zu registrieren. Wenn die Ereignisquelle den Abonnenten über ein Ereignis benachrichtigt, wird dies als WS Eventing bezeichnet.
  • Der Kompakt-Message-Listener 304 empfängt über eine Kompakt-Message-Schnittstelle 305 Nachrichten von den Mobilgeräten 102. Der Mobildatendienst-Quittungs-Listener 306 empfängt und quittiert über eine Mobildatendienst-Schnittstelle 307 Benachrichtigungen vom Mobildatendienst 116. Jeder der drei Listener 302, 304 und 306 empfängt über eine Listener-Administrationsschnittstelle 309 Administrationsnachrichten vom Administrationsdienst 208.
  • In der vorliegenden Ausführungsform sind die Listener-Schnittstellen 303, 305, 307 und 309 mithilfe von HTTP/HTTPS (Hypertext Transfer Protocol/Hypertext Transfer Protocol over Secure Socket Layer) konfiguriert. Dem Fachmann auf dem Gebiet der Technik wird jedoch einleuchten, dass diese Protokolle als eine Gestaltungsoption gewählt wurden und dass auch andere Protokolle verwendet werden können, wenn das erwünscht ist. Demgemäß übertragen externe Systeme eine HTTP/HTTPS-Anforderung, die durch den entsprechenden Listener empfangen wird. Der Listener nimmt die Nachricht, führt minimale Transformationen durch und leitet sie zum Messaging-Subsystem 224 weiter. Zu den Transformationen zählt das Kopieren von HTTP-Headerinformationen in Nachrichtenobjektfelder. Beispielsweise können die HTTP-Headerinformationen den Mobildatendienst 116 und das Drahtlosgerät 102 identifizieren, die der Ursprung der Nachricht sind.
  • Wie bereits zuvor beschrieben wurde, authentifiziert die Message-Listening-Anwendung, dass die Quelle der Nachricht – sei es der Mobildatendienst 116, das Drahtlosgerät 102 oder die Ereignisquelle 108 – gültig ist. Weiterhin wird – wenn ein zuverlässiges Messaging erforderlich ist – die Dienstverfügbarkeit gewährleistet, und die Listener behandeln Verfügbarkeitsangriffslösungen. Um dies zu erleichtern, definiert das Messaging-Subsystem einen Schwellwert für eine maximale Anzahl von Nachrichten und Verbindungen für einen gegebenen Zeitabschnitt von jedem Backend-Server 108, jeder Komponentenanwendung oder jedem Drahtlosgerät. Der Administrator kann über den Administrationsdienst 208 bei Bedarf diesen Schwellwert modifizieren sowie spezielle Ausnahmen zulassen.
  • Weil Nachrichtenabhör- und -wiedergabeangriffe möglich sind, erkennen und verbieten die Listener außerdem diesen Angriff mithilfe von Mechanismen, die die wiedergegebenen Nachrichten identifizieren. Diese Mechanismen schließen typischerweise die Verwendung von einem Nonce ein. Ein Nonce ist als Parameter definiert, der im Lauf der Zeit variiert. Ein Nonce kann einen Zeitstempel oder eine andere spezielle Markierung sein, die dazu vorgesehen ist, die unberechtigte Wiedergabe oder Reproduktion einer Nachricht einzuschränken oder zu verhindern. Da ein Nonce sich im Lauf der Zeit ändert, kann er verwendet werden, um zu ermitteln, ob eine Nachricht ein Original oder eine Wiedergabe oder eine Reproduktion der Originalnachricht ist oder nicht. Die Verwendung eines Nonce zur Verhinderung von Abhör- und Wiedergabeangriffen ist nach dem Stand der Technik bekannt und muss nicht detailliert beschrieben werden, weil Standardimplementierungen eingesetzt werden.
  • Zusätzlich zu der Zeitstempeltechnik oder anstelle dieser Technik können außerdem auch andere Technologien wie Sequenzierung verwendet werden, um die Wiedergabe von Anwendungsnachrichten zu verhindern. Und wiederum sind solche Techniken nach dem Stand der Technik bekannt und müssen nicht detailliert beschrieben werden, weil Standardimplementierungen eingesetzt werden.
  • Lifecycle-Subsystem
  • Unter Bezug auf 4 wird das Lifecycle-Subsystem 220 detailliert dargestellt. Das Lifecycle-Subsystem schließt einen Lifecycle-Dienst 402 und ein Gerätedepot 404 ein.
  • Der Lifecycle-Dienst 402 verarbeitet geräteinitiierte Nachrichten, die sich auf das Drahtlosgerät 104, auf den Laufzeitumgebungs-Lifecycle und auf den Komponentenanwendungs-Lifecycle beziehen. Solche Nachrichten können sich beispielsweise auf die Registrierung oder Suspendierung eines Drahtlosgeräts, auf den Wechsel eines Mobilgeräts, auf die Verfügbarkeit eines Mobilgeräts, auf die Installation, Aufrüstung (Upgrade) oder Löschung einer Komponentenanwendung und auf Laufzeitumgebungs-Upgrades beziehen. Diese Nachrichten werden über eine Gerätesystemnachrichtenverarbeitungsschnittstelle 403 zu dem und von dem Connector-Subsystem 222 kommuniziert.
  • Der Lifecycle-Dienst 402 stellt des Weiteren die Möglichkeit zur Abfrage nach Drahtlosgeräten und Komponentenanwendungen mithilfe von verschiedenen Filtern bereit. Um diese Funktion zu erleichtern, kommuniziert der Lifecycle-Dienst 402 mit dem Messaging-Subsystem 224 und dem Administrations-Subsystem 208 über eine Schnittstelle zur Abfrage/Aktualisierung von Geräteinformationen 405. In der vorliegenden Ausführungsform ist die Schnittstelle zur Abfrage/Aktualisierung von Geräteinformationen 405 mit einer Reihe von Java-APIs (Application Program Interfaces) zum Abfragen und Aktualisieren von Geräteinformationen implementiert. Zu den typischen Schnittstellen zählen solche zum Verwalten der Sicherheit des Drahtlosgeräts und der Client-Administrationsrichtlinie.
  • Das Lifecycle-Subsystem 220 verwaltet ein Sicherheitsprofil für jedes beim Anwendungs-Gateway 106 registrierte Drahtlosgerät 104 im Gerätedepot 404. Jedes Sicherheitsprofil enthält einen sicheren symmetrischen Schlüssel für jedes Gerät. Dieser Schlüssel wird für die sichere Kommunikation zwischen dem Drahtlosgerät 104 und dem Anwendungs-Gateway 106 verwendet.
  • Die Client-Administrationsrichtlinie schließt das Abrufen des Drahtlosgerätestatus, das Suchen nach Komponentenanwendungen mit bestimmten programmierbaren Kriterien und die Suche nach Geräten mit bestimmten programmierbaren Kriterien ein. Beispielsweise kann es erwünscht sein zu ermitteln, welche Komponentenanwendungen auf allen Drahtlosgeräten installiert sind oder auf welchen Drahtlosgeräten spezielle Komponentenanwendungen installiert sind.
  • Darüber hinaus wird eine Lifecycle-Administrations-Schnittstelle 407 bereitgestellt, um die Verwaltung des Lifecycle-Subsystems 402 und des Gerätedepots 404 durch das Administrations-Subsystem 208 zu erleichtern. Beispielsweise kann das Administrations-Subsystem die Verfügbarkeit einer neuen Version einer Komponentenanwendung oder der Laufzeitumgebung anzeigen.
  • Demgemäß verwaltet der Lifecycle-Dienst 402 den Status von jedem aus einer Vielzahl von assoziierten Drahtlosgeräten 102, wozu auch die Laufzeitumgebung und die Komponentenanwendungen gehören, die darin gespeichert sind. Informationen wie die Laufzeitumgebung, der Komponentenanwendungsstatus und die Drahtlosgerät-Sicherheitseinstellungen sind im Lifecycle-Depot gespeichert. Zu den Sicherheitseinstellungen können beispielsweise die Client-Administrationsrichtlinie und der Verschlüsselungsschlüssel des Drahtlosgeräts zählen.
  • Der Anwendungs-Gateway-Server 118 ermöglicht auch die Verwendung von Lifecycle-Komponenten von Dritten, die auch als Lifecycle-Dienstanbieter bezeichnet werden, die sich typischerweise außerhalb des Anwendungs-Gateways 106 befinden. Um Lifecycle-Dienstanbieter zu ermöglichen, werden in der Anwendungsdiensteschicht Lifecycle-Dienstanbieter-Listener bereitgestellt. Die Lifecycle-Dienstanbieter-Listener sind für das Empfangen der Benachrichtigung zu allen Lifecycle-Systemnachrichten von den Lifecycle-Dienstanbietern und für deren Übertragung zur Verarbeitung zum Administrations-Subsystem 208 verantwortlich. Außerdem können die Lifecycle-Dienstanbieter auf den Administrationsdienst zugreifen, um den Anwendungs-Gateway-Server 188 zu konfigurieren oder Systemnachrichten zu senden.
  • Administrations-Subsystem
  • Das Administrations-Subsystem 208 ist für die Administration von Systemnachrichten, Systemgeräten, Anwendungs-Gateway-Subsystemen, Systemdiagnosen und Standardimplementierungen der Bereitstellungs- und Discovery-Dienste verantwortlich. Unter Bezug auf 5 wird eine detaillierte Ansicht des Administrations-Subsystems 208 gezeigt. Das Administrations-Subsystem 208 schließt ein Administrationsdienst 502, eine Administrationskonsole 504 und Administrationsanwendungen 506 ein. Die Administrationsanwendungen 506 schließen eine JMX-Anwendung (Java Management Extension) 508 und eine Webdienst-Anwendung 510 ein.
  • Eine Browser-Schnittstelle 505 stellt die Verbindung zwischen einem Administrator und der Administratorkonsole 502 her, um die Administration des Anwendungs-Gateways 106 zu ermöglichen. Eine Administratorschnittstelle 503 verbindet den Administratordienst 502 mit dem Messaging-Subsystem 224 zur Zustellung von Administrativsystemnachrichten. Die Administrationsanwendungen 506 sind über eine geeignete Schnittstelle mit ihren jeweiligen Administrativanwendungen von Dritten verbunden. Beispielsweise ist die JMX-Anwendung 508 über eine JMX-Schnittstelle 509 verbunden, und die Webdienst-Anwendung 510 ist über eine Webdienst-Schnittstelle 511 verbunden.
  • Der Administrationsdienst 502 verarbeitet Komponentenanwendungs- und Laufzeitumgebungs-Lifecycle-Ereignisse, die durch den Administrator oder die Lifecycle-Dienstanbieter über die Lifecycle-Administrationsschnittstelle initiiert werden. Beispiele für solche Ereignisse sind das Installieren einer Komponentenanwendung mithilfe von Push-Bereitstellung, das Auffrischen des Verschlüsselungsschlüssels, das Upgraden der Komponentenanwendung oder von Laufzeitkomponenten, das Entfernen von Komponentenanwendungen, das Unter-Quarantäne-Stellen von Komponentenanwendungen und das Entfernen von Komponentenanwendungen aus der Quarantäne, das Anwenden eines Komponentenanwendungs-Cleanup-Scripts, das Abfragen der Laufzeitumgebung nach einer Statusaktualisierung und das Aktualisieren der Client-Administrationsrichtlinie.
  • Der Administrationsdienst 502 ist auch für die Administration der Drahtlosgeräte 104 verantwortlich. Demgemäß ist der Administrationsdienst 502 in der Lage, auf Drahtlosgerät-Registrierungssystemnachrichten zu reagieren und Drahtlosgeräteinstellungen wie den Sicherheitsschlüssel, die Mobildatendienst-URL, die Laufzeitversion und den Laufzeitstatus zu verwalten. Der Administrationsdienst 502 unterstützt außerdem die Fähigkeit zum Auflisten von Geräten entsprechend vordefinierten Filtercharakteristika, beispielsweise zur Abfrage eines Geräts im Hinblick auf seine Komponentenanwendungs- und Laufzeitumgebungseinstellungen und zur Abfrage im Hinblick auf Komponentenanwendungen auf speziellen Geräten.
  • Der Administrationsdienst 502 bietet dem Administrator auch die Möglichkeit zum Zugriff auf Laufzeitinformationen und Einstellungen des Anwendungs-Gateway-Subsystems, wenn zutreffend für jeden einzelnen Cluster-Knoten, und zur Durchführung von systembezogenen Aufgaben. Zu solchen Aufgaben gehören das Anzeigen der Laufzeitinformationen des Message-Subsystems 224, einschließlich Nachrichteninformationen für jedes einzelne Drahtlosgerät 102 und für jede einzelne Komponentenanwendung sowie der Anzahl von Nachrichten in der Warteschlange und eines Snapshots der Anzahl der gepoolten Objekte eines speziellen Typs. Der Administrator kann spezielle Einstellungen zur Laufzeit modifizieren sowie abgelaufene Nachrichten löschen oder neu planen.
  • Zu den weiteren Informationen und Einstellungen, die durch den Administrationsdienst 502 bereitgestellt werden, zählen die folgenden. Die Parameter des Anwendungs-Gateway-Subsystems stehen zur Modifikation zur Verfügung. Deshalb kann der Administrator beispielsweise verschiedene Funktionen zur Laufzeit aktivieren oder deaktivieren. Die Datenbankeinstellungen können für eine zentralisierte Anwendungs-Gateway-Datenbank konfiguriert werden. Diese Datenbank kann sämtliche Subsystemdepots enthalten. Die Anwendungs-Gateway-URLs können so konfiguriert werden, dass sie für externe Systeme zugänglich sind. Beispielsweise kann der Administrationsanwendung 506 eine URL zugewiesen werden, um den Zugriff durch Dritte zu ermöglichen. Außerdem kann der Packaging-Anwendung eine URL zugewiesen werden, um den Zugriff durch den Bereitstellungsdienst zu ermöglichen.
  • Der Administrationsdienst 502 kann auch Discovery-Dienst-Credentials, Dienstanbieter-Credentials, Mobildatendienstparameter und Sicherheitsparameter speichern. Die Discovery-Dienst-Credentials können zur Authentifizierung des Discovery-Diensts beim Empfang einer Benachrichtigungsmeldung, dass eine Komponentenanwendung verfügbar ist, verwendet werden. Desgleichen können die Dienstanbieter-Credentials, einschließlich dessen URL, zur Authentifizierung eines Dienstanbieters beim Empfangen von Komponentenanwendungs- oder Laufzeitumgebungs-Lifecycle-Nachrichten verwendet werden. Die Mobildatendienstparameter können verwendet werden, um den Administrator mit dem Mobildatendienst zu verbinden und dessen IP-Adresse, Benutzerkennung und Passwort einzubeziehen. Die Anwendungs-Gateway-Sicherheitsparameter und – einstellungen, wie z. B. der öffentliche und private Schlüssel und die Schlüsselauffrischungsrichtlinie des Anwendungs-Gateways, werden zur Verschlüsselung der Kommunikation zwischen dem Anwendungs-Gateway und externen Anwendungen verwendet.
  • Der Administrationsdienst 502 wird auch zur Registrierung zusätzlicher Subsysteme verwendet, wozu zum Beispiel angepasste Connectoren und Lifecycle-Listener gehören.
  • Die Webdienst-Anwendung 510 verwendet Webdienste, um falls erforderlich die durch den Dienstanbieter initiierten Systemnachrichten zur Verarbeitung und zur Zustellung zum Gerät an den Administrationsdienst 502 weiterzuleiten.
  • In gleicher Weise leitet die JMX-Anwendung 508 falls erforderlich die durch den Dienstanbieter initiierten Systemnachrichten zur Verarbeitung und zur Zustellung zum Gerät an den Administrationsdienst 502 weiter. Allerdings ist die JMX-Schnittstelle 509 eine offene Schnittstelle, die jeder Anbieter von Managementsystemen einsetzen kann. Die Administrationsinfrastruktur basiert auf der JMX-Technologie, die eine offene Technologie zum Systemmanagement und -monitoring ist. Jedes Managementsystem implementiert ein Set von Mbeans-Objekten, um konfigurierbar zu sein. Diese Objekte müssen entsprechend der JMX-Spezifikation bei einem MbeanServer registriert sein, der im Prozessraum des Objekts läuft.
  • Da das Anwendungs-Gateway 106 potentiell in einer verteilten Umgebung laufen kann, was bedeutet, dass einige Subsysteme auf unterschiedlichen Anwendungsservern laufen können, muss jeder Anwendungsserver seine eigene Implementierung des MbeanServers haben. Außerdem muss jedes Subsystem mithilfe einer separaten Administrationskonsole konfiguriert sein, die durch den entsprechenden Anwendungsserver bereitgestellt wird, oder mithilfe einer Konsole von Dritten, die weiß, wie der Zugriff auf die Funktionalität des MbeanServers erfolgt.
  • Messaging-Subsystem
  • Das Messaging-Subsystem 224 behandelt Nachrichten, die entweder systemspezifisch oder komponentenanwendungsspezifisch sind. Das Messaging-Subsystem 224 ist auch für die Integrität und Pflege aller Nachrichten verantwortlich, die durch das Anwendungs-Gateway 106 zugestellt werden sollen. Beim Empfang einer Nachricht stellt das Messaging-Subsystem 224 diese in eine Warteschlange, speichert sie optional (aus Gründen der Zuverlässigkeit sowohl zum als auch vom Anwendungs-Gateway 106) und bereitet sie für die weitere Zustellung zu ihrem Ziel vor.
  • Unter Bezug auf 6 wird das Messaging-Subsystem 224 detailliert gezeigt. Das Messaging-Subsystem 224 enthält einen Message-Broker 602 und ein Message-Depot 604. Eine Message-Prozessorschnittstelle 606 verbindet den Message-Broker 602 mit den Message-Listenern 232, dem Connector-Subsystem 222, dem Transformations-Subsystem 226 und den anderen Anwendungs-Gateway-Subsystemen. Eine Message-Prozessor-Administrationsschnittstelle 608 verbindet das Message-Depot 604 mit dem Administrations-Subsystem 208 und bietet eine Schnittstelle zur Administration und Konfiguration des Messaging-Subsystems 224.
  • Der Message-Broker 602 ist für die Validierung, Verarbeitung und Weiterleitung von Nachrichten im geeigneten Format an den richtigen Connector im Connector-Subsystem verantwortlich. Der Message-Broker 602 kommuniziert mit dem Lifecycle-Subsystem 220, um Informationen über Drahtlosgeräte 102 und Komponentenanwendungen abzurufen. Wenn eine Nachrichtenzuordnung auf mehrere Drahtlosgeräte abzielt, erstellt der Message-Broker 602 eine Nachricht für jedes einzelne Drahtlosgerät. Der Message-Broker 602 führt außerdem planmäßige Aufträge zur Nachrichtenpflege durch. In erster Linie führt das zur Entfernung abgelaufener Nachrichten. Ein Administrator kann über das Administrations-Subsystem die Zeit und die Häufigkeit dieser Pflegeaufträge planen.
  • Der Message-Broker 602 verwaltet außerdem Abonnementinformationen und sendet bei entsprechender Benachrichtigung Nachrichten per Broadcasting an alle Abonnenten.
  • Das Message-Depot 604 wird zum Speichern von Informationen über Nachrichten, von allen Informationen im Zusammenhang mit der zuverlässigen Zuordnung, dem Messaging und den Abonnements sowie von Korrelationsinformationen verwendet.
  • Transformations-Subsystem
  • Das Transformations-Subsystem 226 transformiert Nachrichten, die zwischen den Drahtlosgeräten 102 und dem Anwendungs-Gateway 106 fließen, entweder in ein internes Message-Format oder in ein Kompakt-Message-Format.
  • Das interne Message-Format ist praktisch für interne Subsysteme. Das Kompakt-Message-Format wird für die Übertragung über die Luft zum Drahtlosgerät 102 verwendet, um die Bandbreitenbeanspruchung zu minimieren.
  • Unter Bezug auf 7 wird das Transformations-Subsystem 226 detailliert gezeigt. Das Transformations-Subsystem 226 umfasst einen Kompakt-Transformator 702 und einen Dekompakt-Transformator 704, die jeweils über eine Kompakt-Schnittstelle 706 bzw. über eine Dekompakt-Schnittstelle 708 mit dem Message-Subsystem 224 kommunizieren. Wenn das Message-Subsystem 224 eine Nachricht von einem internen Subsystem empfängt, die für ein Drahtlosgerät 102 bestimmt ist, ist es wahrscheinlich, dass die Nachricht im internen Message-Format vorliegt. Daher transformiert das Message-Subsystem 224 die Nachricht mit dem Kompakt-Transformator 702 in das Kompakt-Message-Format. Wenn das Message-Subsystem 224 eine Nachricht von einem Drahtlosgerät 102 empfängt, die für ein internes Subsystem bestimmt ist, ist es wahrscheinlich, dass diese Nachricht im Kompakt-Message-Format vorliegt. Daher transformiert das Message-Subsystem 224 die Nachricht mit dem Dekompakt-Transformator 704 in das interne Message-Format. Dem durchschnittlichen Fachmann auf dem Gebiet der Technik wird klar sein, dass dem Transformations-Subsystem 226 auch noch angepasste Transformatoren hinzugefügt werden können, um angepasste Message-Formate zu ermöglichen.
  • Um die Transformation zu ermöglichen, werden Transformatorzuordnungen bereitgestellt, um identifizieren zu können, welche Transformation für ein gegebenes Nachrichtenziel erfolgen muss. Es muss darauf hingewiesen werden, dass eine böswillige Transformatorzugordnung zur Durchführung einer willkürlichen Transformation führen könnte, was negative Auswirkungen auf die Sicherheit haben kann, indem z. B. eine Endlosschleife ausgeführt wird und Systemressourcen überbeansprucht werden. Dementsprechend erfolgt eine Validierung der Transformatorzuordnungen, wenn diese eingesetzt werden.
  • Connector-Subsystem
  • Das Connector-Subsystem 222 stellt Transportdienste zwischen dem Anwendungs-Gateway 106 und externen Zielsystemen bereit, wozu es die erforderlichen Transportprotokolle verwendet. Außerdem empfängt das Connector- Subsystem 222 synchrone Antworten von den Zielsystemen und gibt diese zur Bearbeitung an das Message-Subsystem 224 weiter.
  • Unter Bezug auf 8 wird das Connector-Subsystem 222 detailliert gezeigt. Das Connector-Subsystem 222 enthält einen MDS-Connector 802, einen System-Connector 804 und eine Gruppe von Backend-Connectoren 806. Der MDS-Connector 802 ist über eine MDS-Connector-Schnittstelle 803 mit dem Message-Subsystem 224 verbunden. Der System-Connector 804 und die Backend-Connectoren 806 sind über eine Connector-Schnittstelle 805 mit dem Message-Subsystem 224 verbunden.
  • Die MDS-Connector-Schnittstelle 803 ist eine Java-API für die Nachrichtenzustellung zu den Drahtlosgeräten 102 im Kompakt-Message-Format. Die Connector-Schnittstelle 805 ist eine Java-API für die Nachrichtenzustellung zu den internen Subsystemen oder Backend-Systemen. Die Nachrichten haben das interne Message-Format.
  • Der MDS-Connector 802 ist für die Zustellung von Kompakt-Messages über den MDS 116 an das Drahtlosgerät verantwortlich. Der MDS-Connector 802 arbeitet als Push-Initiiator zum Pushen von Nachrichten zu den Drahtlosgeräten 102. In der vorliegenden Ausführungsform unterstützt der MDS-Connector 802 sowohl das grundlegende Pushen als auch das zuverlässige Pushen zum MDS über das Standardprotokoll WAP (Wireless Application Protocol) to Push (PAP), obwohl auch andere Standards unterstützt werden können, wenn diese entwickelt werden.
  • Der System-Connector 804 ist für die Zustellung von Systemnachrichten an das Lifecycle-Subsystem 220, an das Administrations-Subsystem 208 oder an das Message-Subsystem 224 verantwortlich. Die Zustellung von Systemnachrichten zu jedem der angegebenen Subsysteme erfolgt durch direkte API-Aufrufe. Der System-Connector empfängt die Nachrichten im internen Message-Format und führt Java-API-Aufrufe zum entsprechenden Subsystem durch.
  • Die Backend-Connectoren 806 schließen verschiedene Standard-Connectoren ein, wozu ein Datenbank-Connector 808, ein SOAP-Connector 810 und ein WS-Eventig-Connector 812 zählen. Außerdem werden sowohl die Connector-Schnittstelle 805 als auch das interne Message-Format veröffentlicht, und damit können Integratoren von dritter Seite bei Bedarf angepasste Backend-Connectoren implementieren.
  • Der Datenbank-Connector 808 empfängt Nachrichten im internen Message-Format und transformiert diese in SQL-Anweisungen (Structured Query Language). Der Datenbank-Connector 808 führt dann die SQL-Anweisungen über JDBC an einem Zieldatenbankserver aus. Mithilfe der für jede Nachricht definierten Zuordnungsinformationen erstellt der Datenbank-Connector 808 eine JDBC-Verbindung und bereitet die SQL-Anweisungen vor und/oder führt diese aus. Der Datenbank-Connector 808 empfängt das Abfrageergebnis vom Zieldatenbankserver 108b und leitet es im internen Message-Format an das Message-Subsystem zurück.
  • Der SOAP-Connector 810 empfängt Nachrichten im internen Message-Format, transformiert diese in das SOAP-Format und liefert die SOAP-Anforderungsnachrichten an die Backend-Webdienste 108, wozu er die Webdienst-SOAP-Bindung über das HTTP-Protokoll verwendet. Sowohl Webdienste im RPC-Stil (Remote Procedure Call) als auch solche im Dokumentstil werden unterstützt. Der SOAP-Connector 810 empfängt auch synchrone SOAP-Antwortnachrichten für jede Anforderung von den Backend-Webdiensten, transformiert die Nachrichten in das interne Message-Format und leitet sie zum Messaging-Subsystem 224 weiter.
  • Der SOAP-Connector 810 unterstützt außerdem die Verschlüsselung von SOAP-Nachrichten an Webdienst-Backend-Ziele über das Standard-HTTP-Protokoll. Es muss darauf hingewiesen werden, dass eine End-to-End-Sicherheit erreicht werden kann, wenn sowohl das Anwendungs-Gateway als auch der sichere Webdienst hinter derselben Firewall eingesetzt werden oder wenn das WS-Sicherheitsprotokoll unterstützt wird.
  • Der WS-Eventing-Connector 812 ist ein spezialisierter SOAP-Connector, der das WS-Eventing-Protokoll für die Behandlung von WS-Eventing-Abonnementanforderungen unterstützt.
  • Sicherheits-Subsystem
  • Das Sicherheits-Subsystem 212 stellt Dienste bereit, die von anderen Subsystemen verwendet werden, um die Kommunikation mit dem Drahtlosgerät 102 abzusichern. Um eine sichere Kommunikation zu ermöglichen, verschlüsselt und entschlüsselt das Sicherheits-Subsystem 212 Nachrichten, übernimmt die Validierung von Signaturen und signiert Nachrichten.
  • Unter Bezug auf 9 wird das Sicherheits-Subsystem 212 detailliert dargestellt. Das Sicherheits-Subsystem 212 enthält eine Crypto-Schnittstelle 902, eine Keystore-Schnittstelle 904 und eine Signaturschnittstelle 906 für die Interaktion mit den Subsystemen des Anwendungs-Gateways 106. Die Crypto-Schnittstelle 902 bietet die Funktionalität, die das Verschlüsseln oder Entschlüsseln von Nachrichten ermöglicht, welche vom Gerät empfangen oder zu diesem gesendet werden. Die Verschlüsselungs-/Entschlüsselungsalgorithmen sind so implementiert, dass die Standardalgorithmen durch neue Algorithmen ausgetauscht werden können, um die Verschlüsselungsstandards für das gesamte Anwendungs-Gateway 106 zu ändern.
  • Die Keystore-Schnittstelle 904 ermöglicht die Generierung von Verschlüsselungsschlüsseln und das Speichern und Abrufen der Schlüssel je nach Bedarf.
  • Die Signaturschnittstelle 906 ermöglicht die Validierung der empfangenen Nachrichtensignaturen und auch die Signierung der zu übertragenden Nachrichten. Wie beim Verschlüsselungsalgorithmus können auch die Validierungs- und Signaturalgorithmen auf Wunsch durch andere Algorithmen ersetzt werden.
  • Protokollierungs-Subsystem
  • Unter Bezug auf 10 wird das Protokollierungs-Subsystem detailliert gezeigt. Das Protokollierungs-Subsystem 216 delegiert Systemprotokollmeldungen zu einer Vielzahl von Protokollierungsanbietern 1002, wozu ein Konsolenprotokollanbieter, ein Dateiprotokollanbieter, ein Datenbankprotokollanbieter und ein E-Mail-Protokollanbieter gehören. Die Protokollanbieter können im Verhältnis zum Gateway-Server entweder intern oder extern sein. Das Protokollierungs-Subsystem 216 ermöglicht außerdem die systemweite Protokollierung über eine log4J-Schnittstelle 1004. Außerdem können je nach Bedarf weitere angepasste Protokollierungsanbieter hinzugefügt werden, was dem durchschnittlichen Fachmann auf dem Gebiet der. Technik verständlich sein dürfte.
  • Konfigurations-Subsystem
  • Das Konfigurations-Subsystem 214 bietet den Anwendungs-Gateway-Subsystemen Zugang zu schreibgeschützten Konfigurationsparametern, die zum Bootstrapping und zur Initialisierung des Anwendungs-Gateway-Systems verwendet werden. Unter Bezug auf 11 enthält das Konfigurations-Subsystem 214 eine Konfigurationsschnittstelle 1102 zur Bereitstellung der Konfiguration für die Anwendungs-Gateway-Subsysteme über einen "Single Point of Access".
  • Dienstprogramm-Subsystem
  • Das Dienstprogramm-Subsystem 210 bietet eine Reihe von auf Standards basierenden Bibliotheken und Schnittstellen zur Durchführung von Basisschichtdiensten in einer einheitlichen Weise. Sie ist verantwortlich für die Bereitstellung statusfreier und wiederverwendbarer Code-Sets, die in sämtlichen Subsystemen durchgängig verwendet werden können. Unter Bezug auf 12 umfasst das Dienstprogramm-Subsystem 210 eine JDBC-Schnittstelle 1202, eine Base64-Schnittstelle 1204, eine UUID-Schnittstelle (Universal Unique Identifier) 1206, eine Locale-Schnittstelle 1208 und eine gemeinsame Schnittstelle 1210 zur Verbindung des Dienstprogramm-Subsystems 210 mit anderen Anwendungs-Gateway-Subsystemen. Die JDBC-Schnittstelle 1202 bietet ein Dienstprogramm zur Herstellung der Verbindung von einer gemeinsam konfigurierten Datenquelle. Die Base64-Schnittstelle 1204 bietet ein Dienstprogramm zum Codieren von binär codierten Daten. Die UUID-Schnittstelle 1206 bietet ein Dienstprogramm für die Erstellung von systemeindeutigen Kennungen. Die gemeinsame Schnittstelle 1210 bietet alle anderen gemeinsamen funktionalen Bibliotheken, die erforderlich sind. Wie dem durchschnittlichen Fachmann auf dem Gebiet der Technik einleuchten wird, können je nach Bedarf auch andere Schnittstellen oder Bibliotheken hinzugefügt werden.
  • Packaging-Anwendung
  • Die Packaging-Anwendung wird als Bestandteil der Anwendung 230 zur Ermöglichung der Bereitstellung von Komponentenanwendungen auf den Drahtlosgeräten 102 bereitgestellt. Während einer ersten Anforderung für ein Komponentenanwendungspaket verarbeitet die Packaging-Anwendung eine Rohkomponentenanwendung, die auch als ein Komponentenanwendungsbündel bezeichnet wird, und bereitet diese für die Drahtlosübertragung vor. Die Packaging-Anwendung lädt das Komponentenanwendungsbündel von einem angegebenen Standort, was typischerweise eine vordefinierte URL ist, ermittelt die Sicherheitsaktionen und die Verarbeitungsschritte, die sie durchführen muss, und gibt eine gepackte Komponentenanwendung zur Speicherung an den Bereitstellungsdienst zurück.
  • Zu den Sicherheitsaktionen, die eventuell durchgeführt werden müssen, zählt beispielsweise die Authentifizierung des Publishers des Komponentenanwendungsbündels. Die Authentifizierung kann erreicht werden, indem die Gültigkeit des Zertifikats des Publishers verifiziert wird und indem die Anwendungs-Gateway-Signatur verwendet wird, um die gepackte Komponentenanwendung zu signieren. Außerdem werden die mit Studio-Tools erstellten IDE-Tag-Zertifikate verifiziert.
  • Das Komponentenanwendungsbündel enthält typischerweise Module wie XML-Definitionen, Zuordnungen, Anwendungsressourcen und Ressourcenbündel zur Lokalisierungsunterstützung. Die XML-Definitionen enthalten XML-Codes von Anwendungsdaten, Nachrichten, Bildschirmkomponenten und Workflow. XML wird hier als Beispiel für jede strukturierte Definitionssprache verwendet, die zur Codierung der Komponentenanwendungen eingesetzt werden kann.
  • Die Zuordnungen definieren die Beziehung zwischen der Komponentenanwendung und einem oder mehreren Backend-Servern 108. In der vorliegenden Ausführungsform wird die Zuordnung mithilfe von WSDL (Web Services Description Language) definiert. WSDL ist im Standard als ein XML-Format zur Beschreibung von Netzdiensten als ein Set aus Endpunkten definiert, die auf der Basis von Nachrichten arbeiten, welche entweder dokumentorientierte oder prozedurorientierte Informationen enthalten. Die Operationen und Nachrichten werden abstrakt beschrieben und dann an ein konkretes Netzprotokoll und Nachrichtenformat gebunden, um einen Endpunkt zu definieren. Miteinander im Zusammenhang stehende konkrete Endpunkte werden zu abstrakten Endpunkten (Diensten) kombiniert. WSDL ist erweiterbar, um die Beschreibung von Endpunkten und deren Nachrichten unabhängig davon zu ermöglichen, welche Nachrichtenformate oder Netzprotokolle zur Kommunikation verwendet werden, allerdings beschreiben die einzigen in diesem Dokument beschriebenen Bindungen, wie WSDL in Verbindung mit SOAP, HTTP und MIME (Multi-Purpose Internet Mail Extensions) zu verwenden ist.
  • Wenn demnach eine Nachricht vom Drahtlosgerät 102 empfangen wird, enthält sie eine Kennung, welche die Komponentenanwendung verdeutlicht, von der sie stammt. Diese Information wird zur Identifizierung einer entsprechenden Zuordnung verwendet, mit der bestimmt wird, wie die Nachricht zu interpretieren ist und wohin sie gesendet werden soll. In der vorliegenden Ausführungsform kann jedes Drahtlosgerät 102 eindeutig adressiert werden. Dementsprechend werden Rückmeldungen über den Mobildatenserver 116 zu dem Gerät gepusht. In alternativen Ausführungsformen kann das Pushen über andere bekannte träger- oder gerätespezifische Push-Protokolle erreicht werden, was dem Fachmann auf dem Gebiet der Technik einleuchten dürfte. Beispielsweise über einen WAP-Push (Wireless Area Protocol), der über SMS (Short Message System) erfolgt.
  • Die Anwendungsressourcen schließen eine oder mehrere Ressourcen wie Bilder, Sound, Video und dergleichen ein, die zusammen mit der Anwendung als statische Abhängigkeiten gepackt sind. Die Ressourcenbündel enthalten typischerweise Lokalisierungsinformationen für die Komponentenanwendung. Ein Beispiel für Lokalisierungsinformationen sind Sprachenunterstützung, Textrichtung, Scrolling-Richtungen, Wörterbuch- und Thesaurus-Dienste und dergleichen.
  • Demgemäß schließt die Verarbeitung des Komponentenanwendungsbündels die Lokalisierung mithilfe des bereitgestellten Ressourcenbündels, die Binärcodierung, die Markierung der Komponentenanwendung mit einem Sicher-Flag und das Hochladen der gepackten Komponentenanwendung in ein bereitgestelltes Ziel-Repository ein, das typischerweise durch eine URL definiert wird. In der vorliegenden Ausführungsform erfolgt die Binärcodierung zur Reduzierung der Bandbreite, die für die Übertragung der Komponentenanwendung zum Drahtlosgerät 102 benötigt wird. Die Binärcodierung wird durch Verwendung des WBXML-Standards (Wireless Area Protocol Binary XML) erzielt, obwohl auch andere Codierungsschemas verwendet werden können. Und darüber hinaus ist es eventuell nicht erforderlich, die Binärcodierung überhaupt durchzuführen. Des Weiteren wird die Zuordnung zum Message-Broker 602 übertragen, um die Kommunikation zwischen der Laufzeitumgebung, welche die Komponentenanwendung ausführt, und dem zugehörigen Backend-Server bzw. den Backend-Servern 108 zu ermöglichen.
  • Die Packaging-Anwendung ist für externe Subsysteme als Webdienst verfügbar. In der vorliegenden Ausführungsform erfolgt der Zugriff auf ihn durch den Bereitstellungsdienst 120, der Zugriff kann jedoch auch durch angepasste Bereitstellungsdienste Dritter erfolgen.
  • Discovery-Server
  • Unter Bezug auf 13 ist der Discovery-Server 122 detailliert dargestellt. Der Discovery-Server 122 umfasst einen Discovery-Dienst 1302 und eine UDDI-Registratur (Universal Description, Discovery and Integration) 1304. Der Discovery-Dienst 1302 kommuniziert über eine UDDI-Suchschnittstelle 1312 und eine UDDI-Abonnementbenachrichtigungsschnittstelle 1314 mit der UDDI-Registratur 1304. Der Discovery-Dienst 1302 kommuniziert außerdem über eine Abonnementbenachrichtigungsschnittstelle 1306 mit dem Administrations-Subsystem-Server 108 und über eine Suchschnittstelle 1308 sowohl mit dem Anwendungs-Gateway-Server 118 als auch mit dem Bereitstellungs-Server 120. Die UDDI-Registratur 1304 kommuniziert über eine UDDI-Publish-Schnittstelle 1310 mit einem IDE (Integrated Development Enterprise) 1316.
  • Die UDDI-Publish-Schnittstelle 1310 ist eine SOAP-basierte UDDI-Schnittstelle zur Bereitstellung von Publishing-Fähigkeiten. Diese Schnittstelle wird von jedem Dienstprogramm verwendet, welches das Komponentenanwendungs-Publishing ermöglicht. Nachdem ein Entwickler eine Komponentenanwendung erstellt hat, kann er diese demnach zur UDDI-Registratur 1304 übergeben, indem eine Reihe von Komponentenanwendungs-Publikationsregeln befolgt werden.
  • Der Discovery-Dienst 1302 kann eine Benachrichtigung über neue oder aktualisierte Komponentenanwendungen anfordern, die in der UDDI-Registratur 1304 registriert sind. Die UDDI-Abonnementbenachrichtigungsschnittstelle 1314 ist eine SOAP-basierte UDDI-Schnittstelle, die durch die UDDI-Registratur bereitgestellt wird, um Registraturbenachrichtigungen zu abonnieren. Die Unterstützung für die Benachrichtigung basiert auf der UDDI v3.0-Spezifikation.
  • Die UDDI-Suchschnittstelle 1312 stellt eine SOAP-basierte UDDI-Schnittstelle für das Durchsuchen der UDDI-Registratur bereit.
  • Die Standardimplementierung des Discovery-Diensts 1302 ist ein eigenständiger Webdienst, der als Bestandteil des Anwendungs-Gateways 106 über den Discovery-Server 122 eingesetzt wird. Der Discovery-Dienst 1302 bietet einer Discovery-Komponentenanwendung in der Laufzeitumgebung auf den Drahtlosgeräten 102 lokale Komponentenanwendungs-Discovery-Dienste. Aus der Perspektive des Anwendungs-Gateway-Servers 118 ist der Discovery-Dienst 1302 eine typische Komponentenanwendung und wird auch als solche eingesetzt und verwaltet. Dementsprechend ist die Verarbeitung von Discovery-Nachrichten generisch und transparent für den Anwendungs-Gateway-Server. Damit dient der Anwendungs-Gateway-Server 118 als ein Message-Broker zwischen der Laufzeitumgebung und dem Discovery-Dienst 1302.
  • Typischerweise kommuniziert die Laufzeitumgebung über die Suchschnittstelle 1308 mit dem Discovery-Dienst 1302. Die aktuelle Suchschnittstelle 1308 kann durch eine andere ersetzt werden, solange diese sowohl von der Discovery-Komponentenanwendung auf dem Drahtlosgerät als auch vom Discovery-Dienst 1302 unterstützt wird.
  • Und außerdem kann die Standardimplementierung des Discovery-Diensts 1302 verwendet werden, um die sichere Drahtloskomponentenbereitstellungsrichtlinie durchzusetzen. Die Sicherheit wird erreicht, weil der Discovery-Dienst 1302 lediglich auf vordefinierte lokale oder vertrauenswürdige UDDI-Registraturen zugreift.
  • Wie die UDDI-Abonnementbenachrichtigungsschnittstelle 1314 ist auch die Abonnementbenachrichtigungsschnittstelle 1306 eine SOAP-basierte Schnittstelle, die durch den Discovery-Dienstanbieter 122 implementiert wird. Sie ermöglicht es dem Administrations-Subsystem 208, Discovery-Benachrichtigungen zu abonnieren. Zu solchen Benachrichtigungen gehören beispielsweise 'Neue Komponentenanwendungsversion verfügbar' und 'Neue Komponentenanwendung verfügbar'.
  • Bereitstellungs-Server
  • Unter Bezug auf 14 wird der Bereitstellungs-Server 120 detailliert dargestellt. Der Bereitstellungs-Server 120 umfasst einen Bereitstellungsdienst 1402, ein Komponentenanwendungsdepot 1404, eine Bereitstellungsschnittstelle 1406 und eine Packaging-Schnittstelle 1408.
  • Der Bereitstellungsdienst 1402 kann Komponentenanwendungspakete erstellen, abrufen, aktualisieren und löschen. Der Bereitstellungsdienst 1402 bedient die Komponentenanwendungs-Bereitstellungsanforderungen, die auf dem Mobilgerät 102 initiiert werden, über die Bereitstellungsschnittstelle 1406. Wenn die Komponentenanwendung gepackt wurde, gibt der Bereitstellungsdienst den Standort der gepackten Komponentenanwendung zurück.
  • Wenn die Komponentenanwendung nicht gepackt wurde, kommuniziert der Bereitstellungsdienst 1402 mit dem Discovery-Dienst 1302 zur Lokalisierung der angeforderten Komponentenanwendung. Der Standort der Komponentenanwendung wird an den Bereitstellungsdienst 1402 zurückgegeben, der eine Packaging-Anforderung über die Packaging-Schnittstelle 1408 zur Packaging-Anwendung kommuniziert. Eine gepackte Komponentenanwendung wird zum Bereitstellungsdienst 1402 zurückgegeben, um im Komponentenanwendungsdepot 1404 gespeichert zu werden. Der Bereitstellungsdienst 1402 gibt dann den Standort der gepackten Komponentenanwendung zurück.
  • Systemoperation
  • Es folgt eine Beschreibung der Operation des Anwendungs-Gateways 106. Zunächst wird die allgemeine Operation zur Nachrichtenverarbeitung beschrieben, danach die Komponentenanwendungsbereitstellung und andere spezifische Funktionen des Anwendungs-Gateways 106.
  • Unter Bezug auf 15 ist ein Beispiel der Laufzeitinitialisierung allgemein mit der Bezugsziffer x00 bezeichnet. In Schritt 1502 wird das Dienstbuch auf das Drahtlosgerät geladen. Wie zuvor beschrieben wurde, kann das Dienstbuch durch den MDS 116 oder durch den Enterprise-Server 114 zum Drahtlosgerät gepusht werden, oder es kann durch einen Administrator mithilfe eines lokalen, drahtgebundenen Connectors geladen werden. In Schritt 1504 benachrichtigt das Drahtlosgerät 102 die Laufzeitumgebung, dass es das Dienstbuch empfangen hat. Die Laufzeitumgebung quittiert die Benachrichtigung zum Drahtlosgerät 102, das seinerseits die Antwort zu dem Dienst quittiert, der ursprünglich das Dienstbuch gepusht hatte.
  • In Schritt 1506 sendet die Laufzeitumgebung eine Registrierungsnachricht an die im Dienstbuch angegebene URL, um sich beim Anwendungs-Gateway 106 zu registrieren. Die Registrierungsnachricht enthält Informationen zur Identifizierung des Drahtlosgeräts und Systeminformationen, wie z. B. die Laufzeitumgebungsversion und dergleichen. Das Anwendungs-Gateway 106 registriert das Gerät durch Aufzeichnung der relevanten Informationen im Lifecycle-Subsystem 220 und im Administrationsdienst 208 und quittiert die Registrierungsnachricht.
  • In Schritt 1508 überträgt das Anwendungs-Gateway 106 ein Benutzeradministrationsprofil und das standardmäßige Komponentenanwendungs-Administrationsprofil an die Laufzeitumgebung, und in Schritt 1510 werden die Profile durch die Laufzeitumgebung gespeichert. Das Benutzeradministrationsprofil definiert Endbenutzerprivilegien sowie domänenbezogene Einstellungen für das Drahtlosgerät 102. Es enthält Informationen wie z. B. ob nicht vertrauenswürdige Komponentenanwendungen auf dem Drahtlosgerät 102 zulässig sein sollen oder nicht, ob eine 'stille' Push-Bereitstellung zulässig ist oder nicht oder ob eine durch Benutzer initiierte Bereitstellung zulässig sein soll oder nicht. Als stille Push-Bereitstellung wird der Vorgang bezeichnet, wenn eine Komponente durch den Administrator auf das Drahtlosgerät gepusht wird, ohne dass der Benutzer davon Kenntnis hat.
  • Das Komponentenanwendungs-Administrationsprofil beschreibt Komponentenanwendungs-Laufzeitparameter wie z. B. die Rechte der Komponentenanwendung in Bezug auf den Zugriff auf andere Anwendungen auf dem Drahtlosgerät 102, ein zugewiesenes Speicherlimit und einen Warteschlangenschwellwert. Das Komponentenanwendungs-Administrationsprofil wird typischerweise durch die Administratoren definiert und durch die Laufzeitumgebung verwendet und durchgesetzt. Typischerweise gibt es unterschiedliche Standardprofile für vertrauenswürdige und nicht vertrauenswürdige Komponentenanwendungen.
  • Sobald das Drahtlosgerät 102 beim Anwendungs-Gateway 106 registriert ist, kann es beginnen, die Bereitstellung von Komponentenanwendungen anzufordern. Das heißt, das Drahtlosgerät 102 fordert an, dass spezielle Komponentenanwendungen installiert werden sollen. Im Allgemeinen gibt es drei Verfahren, um zu ermitteln, welche Komponentenanwendungen bereitgestellt werden sollen: Anforderung vom Benutzer, Push vom Administrator und Push von einem Dritten oder einem Dienstanbieter.
  • In der vorliegenden Ausführungsform besteht der Hauptunterschied zwischen diesen Verfahren darin, wie ein Einsatzdeskriptor gewonnen wird. Der Einsatzdeskriptor enthält Informationen wie z. B. den Namen, die Version, die Beschreibung und den Standort der Komponentenanwendung. Die Beschreibung kann optional Angaben dazu enthalten, welche Sprachen durch die Anwendung unterstützt werden. Sobald der Einsatzdeskriptor gewonnen wurde, sind die eigentlichen Bereitstellungsprozesse für die drei Verfahren im Wesentlichen gleich.
  • Unter Bezug auf 16 ist ein Beispiel dafür dargestellt, dass ein Benutzer die Bereitstellung einer Komponentenanwendung anfordert. In Schritt 1602 überträgt die Gerätelaufzeitumgebung (Geräte-LU) eine Kompakt-Message zum Anwendungs-Gateway-Server 118. Die Details des Nachrichtenflusses werden unter Bezug auf 21 beschreiben. Für das vorliegende Beispiel ist es ausreichend zu verstehen, dass das Message-Subsystem 224 die Kompakt-Message empfängt und in Schritt 1604 eine interne Message an das Connector-Subsystem 222 zustellt. In Schritt 1606 stellt der SOAP-Connector 810 eine Suchanforderung an den Discovery-Dienst 1302 zu. In Schritt 1608 durchsucht der Discovery-Dienst 1302 die UDDI-Registratur 1304 nach der angeforderten Komponentenanwendung und gibt ein Ergebnis zurück.
  • In der vorliegenden Ausführungsform ist das Ergebnis der Einsatzdeskriptor, das Ergebnis kann jedoch auch eine URL zu dem Einsatzdeskriptor sein oder eine andere Methode zu dessen Adressierung. In Schritt 1610 wird das Ergebnis vom SOAP-Connector 810 zum Message-Subsystem 224 im internen Message-Format zurückgegeben. In Schritt 1612 gibt das Message-Subsystem 224 das Ergebnis an die Gerätelaufzeit zurück.
  • Unter Bezug auf 17 ist ein Beispiel der Push-Bereitstellung einer Komponentenanwendung vom Administrationsdienst 208 zum Drahtlosgerät 102 dargestellt. In Schritt 1702 bereitet der Administrator eine Drahtlosgerätparameterliste für die Push-Bereitstellung vor und gibt diese mithilfe der Administrationskonsole 504 ein. In Schritt 1704 kommuniziert die Administrationskonsole 504 die Liste zum Administrationsdienst 502. In Schritt 1706 sendet der Administrationsdienst 502 eine Anfrage an das Lifecycle-Subsystem 220, um eine Liste der Drahtlosgeräte zu erhalten, die den Parametern des Administrators entsprechen. Die Ergebnisse werden die Kette wieder aufwärts zum Administrator zurückgegeben.
  • In Schritt 1708 verwendet der Administrator die Liste der Drahtlosgeräte zum Pushen eines Einsatzdeskriptors. Die Liste der Geräte und der Einsatzdeskriptor werden in die Administrationskonsole 504 eingegeben. In Schritt 1710 kommuniziert die Administrationskonsole 504 die Liste und den Einsatzdeskriptor zum Administrationsdienst 502. In Schritt 1712 wird die Laufzeitumgebung für jedes Gerät in der Liste aus dem Lifecycle-Subsystem 220 abgerufen. In Schritt 1714 wird die Version der Laufzeitumgebung im Hinblick auf die Version der Laufzeitumgebung überprüft, die für die bereitzustellende Komponentenanwendung benötigt wird. Die für die Komponentenanwendung benötigte Version der Laufzeitumgebung kann auf verschiedene Weise kommuniziert werden. In der vorliegenden Ausführungsform ist sie im Einsatzdeskriptor enthalten. In einer alternativen Ausführungsform kann sie bei Bedarf aus dem Komponentenanwendungsbündel abgerufen werden. Wenn ermittelt wird, dass die Laufzeitumgebung und die Komponentenanwendung inkompatibel zueinander sind, wird eine Fehlermeldung generiert. In Schritt 1716 wird die Fehlermeldung zur Administrationskonsole 504 übertragen.
  • In Schritt 1718 wird für alle Geräte, für die ermittelt wurde, dass sie kompatible Laufzeitumgebungen haben, eine Nachricht des Typs "Upgrade erforderlich" oder "Neue Anwendung verfügbar" einschließlich des Einsatzdeskriptors erstellt und in Schritt 1720 zu den zugehörigen Drahtlosgeräten 102 zugestellt. Die Details einer Aufgabenzustellung sind in 26 dargestellt.
  • Unter Bezug auf 18 ist ein Beispiel der Push-Bereitstellung einer Komponentenanwendung vom Dienstanbieter für das Drahtlosgerät 102 dargestellt. In Schritt 1802 initiiert ein Administrator des Dienstanbieters eine Anforderung an den Lifecycle-Dienstanbieter (Lifecycle-DA) für einen Komponentenanwendungs-Push. Die Anforderung enthält Parameter für eine Vielzahl von Drahtlosgeräten sowie die Einsatzbeschreibung der Komponentenanwendung. In Schritt 1804 ruft der Lifecycle-Dienstanbieter die Drahtlosgerätinformationen ab, beispielsweise die Drahtlosgerätekennung und die Laufzeitversion, und überträgt diese zusammen mit dem Einsatzdeskriptor zur Administrationsanwendung.
  • In Schritt 1806 erfolgt die Authentifizierung des Lifecycle-Dienstanbieters durch die Administrationsanwendung. Wenn die Authentifizierung fehlschlägt, dann meldet der Administrationsdienst 502 in Schritt 1808 das Fehlschlagen an den Lifecycle-Dienstanbieter. Ansonsten sendet die Administrationsanwendung in Schritt 1810 die empfangenen Informationen an den Administrationsdienst 502. In Schritt 1812 verifiziert der Administrationsdienst 502, dass die Version der Laufzeitumgebung des Geräts kompatibel mit der Komponentenanwendung ist. In Schritt 1814 wird für alle Geräte, deren Laufzeitumgebung kompatibel zur Komponentenanwendung ist, eine Systemnachricht des Typs "Upgrade erforderlich" oder "Neue Anwendung verfügbar" erstellt. Die Systemnachricht wird in Schritt 1816 zu den Drahtlosgeräten 102 zugestellt.
  • Sobald das Drahtlosgerät 102 den Einsatzdeskriptor für die bereitzustellende Komponentenanwendung empfangen hat, kann das Drahtlosgerät 102 damit fortfahren, die Komponentenanwendung abzurufen. Unter Bezug auf 19 ist ein Beispiel für die Bereitstellung einer Komponentenanwendung für ein Drahtlosgerät dargestellt. Wenn das Benutzeradministrationsprofil des Drahtlosgeräts 102 die stille Bereitstellung zulässt, dann fährt die Laufzeitumgebung automatisch mit Schritt 1902 fort. Wenn dagegen das Benutzeradministrationsprofil auf dem Drahtlosgerät 102 die stille Bereitstellung nicht zulässt, fährt die Laufzeitumgebung erst dann mit Schritt 1902 fort, wenn sie eine entsprechende Anweisung vom Benutzer erhält.
  • In Schritt 1902 überträgt die Laufzeitumgebung eine Nachricht an das Anwendungs-Gateway 106. Die Nachricht enthält einen Einsatzdeskriptor und eine Anzeige des Wunschs zum Abrufen einer Komponentenanwendung. Die Nachricht wird am Anwendungs-Gateway 106 durch den Anwendungs-Gateway-Server 118 abgerufen und zum Message-Subsystem 224 gesendet.
  • In Schritt 1904 sendet das Messaging-Subsystem 224 die Nachricht an den SOAP-Connector 810. In Schritt 1906 überträgt der SOAP-Connector die Anforderung zum Bereitstellungs-Server 120. In Schritt 1908 führt der Bereitstellungs-Server 120 eine Überprüfung durch, um festzustellen, ob die Komponentenanwendung bereits im gewünschten Format gepackt wurde. In Schritt 1910 überprüft der Bereitstellungs-Server 120 das Komponentenanwendungszertifikat auf Gültigkeit. In Schritt 1912 fragt der Bereitstellungs-Server 120 den Discovery-Server 122 ab, um zu ermitteln, ob dieser über die gepackte Komponentenanwendung verfügt.
  • Wenn die Komponentenanwendung bereits gepackt wurde, springt der Prozess zu Schritt 1928. In Schritt 1914 wird festgestellt, dass die Komponentenanwendung noch nicht gepackt wurde, und es wird eine Anforderung an die Packaging-Anwendung gesendet. In Schritt 1916 ruft die Packaging-Anwendung die Rohkomponentenanwendung von der URL ab, die durch den Einsatzdeskriptor bereitgestellt wurde. In Schritt 1918 wird die Rohkomponentenanwendung mithilfe des bereitgestellten Ressourcenbündels lokalisiert. In Schritt 1920 wird die lokalisierte Komponentenanwendung gemäß einer in dem Bündel enthaltenen DTD (Document Type Definition) binär codiert. In Schritt 1921 versucht die Packaging-Anwendung, eine eindeutige Kennung für die Anwendung bereitzustellen, indem ihre Kennung, die durch einen Entwickler zugewiesen wurde, mit einem Zeitstempel gehasht wird. Die Ergebnisse des Hashs werden mit einer Liste bekannter Anwendungskennungen verglichen, um zu verifizieren, dass sie eindeutig sind. Wenn das nicht der Fall ist, wird die Kombination erneut gehasht, entweder mit einem anderen Hashing-Algorithmus oder mit einem anderen Zeitstempel. Der Prozess wird solange wiederholt, bis eine eindeutige Kennung gewonnen wird oder eine maximale Anzahl von Versuchen verbraucht wurde. In Schritt 1922 ermittelt die Packaging-Anwendung, ob die Komponentenanwendung einen dedizierten Server benötigt oder nicht. Wenn sie keinen dedizierten Server benötigt oder wenn der dedizierte Server der Anwendungs-Gateway-Server 106 ist, lädt die Packaging-Anwendung die Zuordnung auf den Message-Broker 602. Wenn der dedizierte Server ein externer Server ist, wird entweder die Zuordnung zum externen Server exportiert oder es wird angenommen, dass der externe Server über die erforderliche Zuordnung verfügt. Alternativ kann die Zuordnung eingesetzt werden, wenn die Laufzeitumgebung die Installation der Anwendung quittiert, wie das unter Bezug auf 20 beschrieben wird. In Schritt 1923 wird die codierte Komponentenanwendung mit dem Verschlüsselungsschlüssel des Anwendungs-Gateways signiert, und in Schritt 1924 wird die signierte Komponentenanwendung zu einer Ziel-URL hochgeladen, die durch den Bereitstellungs-Server 120 bereitgestellt wird. In Schritt 1926 setzt die Packaging-Anwendung ein Vertrauenswürdig-Flag in ihrer Antwort zum Bereitstellungssystem 120, womit angezeigt wird, dass die Komponentenanwendung gepackt und signiert wurde.
  • In Schritt 1928 wird der Standort der gepackten Komponentenanwendung durch den Bereitstellungsdienst 120 abgerufen. In Schritt 1930 werden der Standort der Komponentenanwendung und das Vertrauenswürdig-Flag über den SOAP-Connector 224 an den Message-Prozessor 224 zurückgegeben. In Schritt 1932 überträgt der Message-Prozessor die Nachricht zum Drahtlosgerät und zeigt damit an, dass die Komponentenanwendung bereitgestellt wurde.
  • In den oben beschriebenen Beispielen wird die Anforderung zur Bereitstellung der Komponentenanwendung vom Drahtlosgerät 102 gesendet. Das muss jedoch nicht in jedem Fall so sein. Für die Push-Bereitstellung ist es beispielsweise möglich, den Einsatzdeskriptor zu erhalten und die Bereitstellung anzufordern, ohne dass dabei eine Kommunikation mit dem Drahtlosgerät 102 erfolgt. Für eine solche Ausführungsform müsste das Anwendungs-Gateway 106 wissen, ob für das Drahtlosgerät 102 die stille Push-Bereitstellung zulässig ist. Wenn die stille Push-Bereitstellung zulässig ist, kann das Anwendungs-Gateway mit der Bereitstellung der Komponentenanwendung fortfahren. Wenn die stille Push-Bereitstellung nicht zulässig ist, muss das Drahtlosgerät 102 vor der Bereitstellung der Komponentenanwendung benachrichtigt werden, um die entsprechende Anweisung vom Benutzer zu erhalten.
  • Sobald das Drahtlosgerät die Nachricht empfängt, kann die Komponentenanwendung durch die Laufzeitumgebung abgerufen und kompiliert werden. Außerdem quittiert die Laufzeitumgebung die Installation der Komponentenanwendung zum Anwendungs-Gateway 106. Unter Bezug auf 20 wird anhand eines Beispiels gezeigt, was als Antwort auf eine Quittungsmeldung geschieht. In Schritt 2002 sendet das Drahtlosgerät 102 eine Quittungsmeldung zum Anwendungs-Gateway 106. Die Quittungsmeldung enthält die URL der Komponentenanwendung, die URL der gepackten Komponentenanwendung und ein Flag, das anzeigt, dass die Komponentenanwendung erfolgreich installiert wurde.
  • In Schritt 2004 wird die Quittungsmeldung durch den Kompakt-Listener abgerufen, der die Informationen an das Messaging-Subsystem 224 weiterleitet. In Schritt 2006 wird ermittelt, ob eine Zuordnung eingesetzt wurde oder nicht. Wenn die Zuordnung eingesetzt wurde, wird der Prozess mit Schritt 2022 fortgesetzt. In Schritt 2008 wurde die Zuordnung noch nicht eingesetzt, so dass das Messaging-Subsystem 224 die Bereitstellung der Komponentenanwendung wie folgt vervollständigt. In Schritt 2010 ruft das Messaging-Subsystem 224 die gepackte Komponentenanwendung ab. In Schritt 2012 wird der WSDL-Abschnitt abgerufen, und in Schritt 2014 ermittelt das Messaging-Subsystem 224, ob der WSDL-Abschnitt der gepackten Komponentenanwendung noch gültig ist.
  • Wenn der WSDL-Abschnitt ungültig ist, wird der Prozess mit Schritt 2020 fortgesetzt, wo eine Nachricht zum Lifecycle-Subsystem 220 gesendet wird, um die Komponentenanwendung unter Quarantäne zu stellen.
  • Wenn der WSDL-Abschnitt gültig ist, wird der Prozess mit Schritt 2016 fortgesetzt, wo die Komponentenanwendungszuordnung aus dem WSDL-Abschnitt abgerufen und eingesetzt wird. In Schritt 2018 werden Java-Class-Dateien eingesetzt, um die für die Zuordnung benötigten SOAP-Verbindungen zu ermöglichen. Ein Beispiel für eine solche Datei ist die Java-Class-Datei AXIS. AXIS (Apache eXtensible Interaction System) bietet Java-Programmierern einen transparenten Zugriff auf Webdienste. AXIS ist nach dem Stand der Technik bekannt und muss hier nicht im Detail beschrieben werden.
  • In Schritt 2022 wird aus den Komponentenanwendungsinformationen in der Quittungsmeldung eine Lifecycle-Nachricht erstellt. Die Lifecycle-Nachricht wird durch das Transformations-Subsystem 226 in das interne Message-Format transformiert. In Schritt 2024 wird die Lifecycle-Nachricht in ihrem internen Format zum System-Connector 804 zugestellt. In Schritt 2026 stellt die Systemverbindung 804 die Bereitstellungsstatusinformationen an das Lifecycle-Subsystem 220 zu. In Schritt 2028 aktualisiert das Lifecycle-Subsystem 220 die darin gespeicherten Geräteinformationen, und in Schritt 2030 erstellt es eine Bereitstellungsstatusnachricht. Die Bereitstellungsstatusnachricht kann verwendet werden, um externe Listener zu aktualisieren, die beim Lifecycle-Subsystem 220 für Benachrichtigungen registriert sind. Beispielsweise kann ein Betreiberabrechnungssystem sich beim Anwendungs-Gateway-Server 116 registrieren, um benachrichtigt zu werden, wenn Kunden Anwendungen herunterladen. Das Betreiberabrechnungssystem kann dann das Konto eines Kunden entsprechend der heruntergeladenen Anwendung belasten.
  • In Schritt 2032 kontaktiert das Message-Subsystem 224 den Administrations-Server 208, um eine Liste der registrierten Dienstanbieter-Lifecycle-Listener abzurufen. In Schritt 2034 wird für jeden der registrierten Dienstanbieter-Lifecycle-Listener die Lifecycle-Nachricht über den WS-Eventing-Connector 810 übertragen.
  • Deshalb werden das Lifecycle-Subsystem 220 und geeignete Dienstanbieter-Lifecycle-Systeme über die Komponentenanwendungen informiert, die auf jedem der Drahtlosgeräte installiert sind. Auf diese Weise kann das Lifecycle-Subsystem 220 sicherstellen, dass bei Bedarf ein Upgrade der entsprechenden Geräte erfolgt.
  • Unter Bezug auf 21 ist ein Beispiel der Nachrichtenverarbeitung zwischen dem Drahtlosgerät 102 und dem Anwendungs-Gateway 106 gezeigt. In Schritt 2102 überträgt die Gerätelaufzeit eine Kompakt-Message zum Anwendungs-Gateway 106. In Schritt 2104 empfängt der Kompakt-Message-Listener 304 die Meldung und stellt sie in die Warteschlange. In Schritt 2106 wird die Nachricht durch den Kompakt-Message-Listener vorverarbeitet und zum Message-Broker 602 zugestellt.
  • In Schritt 2108 entschlüsselt und validiert der Message-Broker 602 die Nachrichtensignatur, wenn dies erforderlich ist. In Schritt 2110 führt der Message-Broker 602 eine Überprüfung beim Lifecycle-Dienst 402 durch, um zu verifizieren, dass die mit der Nachricht assoziierte Komponentenanwendung auf dem Drahtlosgerät 102 installiert ist. Wenn die Komponentenanwendung nicht auf dem Drahtlosgerät 102 installiert ist, wird eine Fehlermeldung zurückgegeben.
  • In Schritt 2112 wird das Message-Depot 604 überprüft, um zu ermitteln, ob eine Zuordnung für die Komponentenanwendungen vorhanden ist. Wenn die Zuordnung nicht vorhanden ist, wird die Komponentenanwendung in Schritt 2114 unter Quarantäne gestellt und eine Fehlermeldung zum Drahtlosgerät 102 zurückgegeben. Wenn die Zuordnung vorhanden ist, wird in Schritt 2116 der Ziel-Backend-Server 108 entsprechend dem Ursprung der Nachricht und der Zuordnung ermittelt. Die Nachricht wird im Message-Depot 404 gespeichert. In Schritt 2118 sendet der Message-Broker 602 die Nachricht an das Transformations-Subsystem 226, wo sie durch den Dekompakt-Transformator 704 in das interne Message-Format transformiert wird, und sie wird dann zum Message-Broker 602 zurückgegeben. In Schritt 2120 stellt der Message-Prozessor die Nachricht dem entsprechenden Backend-Connector 806 im Connector-Subsystem 222 zu. In diesem Beispiel wird der SOAP-Connector 810 verwendet. In Schritt 2122 versucht der Backend-Connector 806, die Nachricht mithilfe der erforderlichen Protokolle zum Backend-System 108 zu übertragen. In der vorliegenden Ausführungsform ist die Kommunikation zwischen dem Anwendungs-Gateway-Server 118 und dem Backend-System 108 synchron. Wenn demzufolge der Backend-Server eine Antwort zurückgibt, kennt das Anwendungs-Gateway die Zielanwendung und das Drahtlosgerät 102. Das Backend-System 108 antwortet dem Backend-Connector 806, der die Antwort zum Message-Broker 602 überträgt.
  • Wenn die Antwort anzeigt, dass die versuchte Kommunikation fehlgeschlagen ist und die Antwort bestimmte Kriterien für die Quarantäne erfüllt, wird die Komponentenanwendung in Schritt 2124 im Lifecycle-Dienst 402 für die Quarantäne markiert. Ein Beispiel der Kriterien für die Quarantäne ist eine Änderung im Webdienst, durch die die im Anwendungs-Gateway 118 eingesetzte Zuordnung ungültig wird. Die assoziierte Anwendung sollte unter Quarantäne gestellt werden, weil die Anwendung erst verwendet werden kann, wenn der Webdienst die Änderung rückgängig macht oder abwärtskompatibel wird.
  • Ansonsten sendet der Message-Prozessor in Schritt 2126 die Antwort zum Transformations-Subsystem 226, wo sie durch den Kompakt-Transformator 702 in das Kompakt-Message-Format konvertiert wird, und sie wird dann zum Message-Broker 602 zurückgegeben. In Schritt 2128 wird die Antwort in eine Warteschlange für die Übertragung zum Drahtlosgerät 102 gestellt. In Schritt 2126 wird die Nachricht in eine Nachrichtenantwortwarteschlange gestellt. In Schritt 2130 wird die Nachricht der Reihe nach aus der Warteschlange abgerufen und vorverarbeitet, indem sie mit anderen Nachrichten gebündelt wird, für die die Zustellung zum selben Drahtlosgerät 102 noch anstehen. In Schritt 2132 wird die Nachricht zum Kompakt-Transformator 702 übertragen, um in das Kompakt-Message-Format transformiert zu werden, und in Schritt 2134 wird die Nachricht bei Bedarf verschlüsselt.
  • In Schritt 2136 überträgt der Message-Prozessor die Antwort zum MDS 116, der in Schritt 2138 die Antwort zum Drahtlosgerät 102 überträgt. In Schritt 2140 überträgt der MDS 116 eine Nachricht zum Message-Broker 602, mit der er quittiert, dass die Antwort gesendet wurde.
  • Unter Bezug auf 22 ist ein Beispiel eines Abonnements für die Benachrichtigung dargestellt. Dieses Beispiel zeigt, wie das Anwendungs-Gateway 106 beim Empfang einer Nachricht von der Komponentenanwendung Benachrichtigungen von einer Ereignisquelle abonnieren kann, indem das WS-Eventing-Protokoll implementiert wird. In diesem Beispiel wird von zwei Annahmen ausgegangen. Die erste Annahme ist, dass das Anwendungs-Gateway 106 weiß, und zwar aus der Komponentenanwendungszuordnung, dass die Nachricht eine Abonnementnachricht ist. Die zweite Annahme ist, dass das Anwendungs-Gateway 106 weiß, und zwar wiederum aus der Zuordnung, wie aus dem Nachrichteninhalt, der von der Komponentenanwendung empfangen wird, ein Abonnementfilter erstellt wird.
  • In Schritt 2202 überträgt die Laufzeitumgebung eine Abonnementnachricht zum Message-Broker 602, die eine Drahtlosgerätekennung, eine Komponentenanwendungskennung und eine Abonnementkennung enthält.
  • In Schritt 2204 verwendet der Message-Broker 602 die Zuordnungsinformationen der Komponentenanwendung zum Erstellen von internen Abonnementinformationen. In Schritt 2206 überträgt der Message-Prozessor die Abonnementinformationen zum Transformations-Subsystem 226. In Schritt 2208 transformiert das Transformations-Subsystem sowohl den Abonnementfilter als auch die Nachricht in das interne Message-Format und gibt diese an den Message-Broker 602 zurück.
  • In Schritt 2210 überträgt der Message-Broker 602 das Abonnement zum Backend-Connector 806, der in diesem Beispiel der SOAP-Connector 810 ist. In Schritt 2212 überträgt der SOAP-Connector 810 die Abonnementanforderung zum Backend 108, der darauf mit einer externen Korrelatorkennung oder mit einer Fehlermeldung antwortet. Der SOAP-Connector 810 gibt die Antwort zum Message-Broker 602 zurück.
  • In Schritt 2214 überträgt der Message-Broker 602 die Antwort zum Transformations-Subsystem 226, wo sie in das Kompakt-Message-Format transformiert wird. In Schritt 2216 wird die externe Korrelatorkennung im Message-Depot gespeichert, und in Schritt 2218 wird eine Nachricht zur Laufzeitumgebung zurückgegeben, die anzeigt, ob die Abonnementanforderung erfolgreich war oder nicht.
  • Unter Bezug auf 23 wird ein Beispiel für die Zustellung einer Benachrichtigung gezeigt. Dieses Beispiel zeigt den Empfang, die Verarbeitung und die Zustellung zum richtigen Gerät (bzw. zu den richtigen Geräten) einer Benachrichtigungsmeldung durch den Anwendungs-Gateway-Benachrichtigungs-Listener 302. In diesem Beispiel wird von zwei Annahmen ausgegangen. Die erste Annahme ist, dass die Ereignisquelle eine WS-Eventing-Ereignisquelle ist. Die zweite Annahme ist, dass das Anwendungs-Gateway 106 weiß, und zwar aus gespeicherten Abonnementinformationen und aus der Komponentenanwendungszuordnung, wie eine Benachrichtigungsmeldung mit einem Abonnement assoziiert und zum richtigen Ziel zugestellt wird.
  • In Schritt 2302 überträgt die Ereignisquelle eine Benachrichtigung zum Benachrichtigungs-Listener des Message-Listeners 232. In Schritt 2304 überträgt der Benachrichtigungs-Listener die Nachricht zum Message-Broker 602. In Schritt 2306 überträgt der Message-Prozessor die Nachricht zum Transformations-Subsystem 226, das die Nachricht in das interne Message-Format konvertiert und zum Message-Broker 602 zurückgibt.
  • In Schritt 2308 lokalisiert der Message-Broker 602 die Korrelationsinformationen im Message-Depot mithilfe der externen Korrelatorkennung, die mit der Benachrichtigung übertragen wird. In Schritt 2310 validiert der Message-Broker 602 die assoziierte Komponentenanwendung im Lifecycle-Subsystem 220. Wenn die Komponentenanwendung nicht verfügbar ist, sendet der Message-Broker 602 in Schritt 2312 über den MDS 116 eine Nachricht an die Laufzeitumgebung, um das Abonnement für diese Benachrichtigungen aufzuheben. Wenn die Komponentenanwendung verfügbar ist, leitet der Message-Broker 602 in Schritt 2314 die Nachricht von der Benachrichtigung über den MDS 116 zum Abonnementen weiter.
  • Unter Bezug auf 24 wird ein Beispiel gezeigt, wie der Gerätelaufzeit signalisiert wird, dass ein Upgrade einer Komponentenanwendung verfügbar ist. In diesem Beispiel initiiert ein Administrator des Discovery-Dienstes oder ein anderes externes Signal eine Nachricht des Typs 'Upgrade verfügbar'. Die Nachricht 'Upgrade verfügbar' informiert das Drahtlosgerät 102 über die Verfügbarkeit eines Upgrades der Komponentenanwendung in der lokalen oder vertrauenswürdigen UDDI-Registratur 1304.
  • Im vorliegenden Beispiel wird von drei Annahmen ausgegangen. Die erste Annahme ist, dass das externe System vertrauenswürdig ist und durch das Lifecycle-Subsystem 220 erfolgreich authentifiziert wurde. Die zweite Annahme ist, dass das externe System weiß, wie die Kommunikation mit der Anwendung über die veröffentlichte Dienstanbieter-Lifecycle-Anwendung erfolgt. Die dritte Annahme ist, dass das externe System über die Fähigkeit verfügt, einen gültigen Komponentenanwendungs-Einsatzdeskriptor bereitzustellen.
  • In Schritt 2402 überträgt der Administrator eine Benachrichtigung über ein Komponentenanwendungs-Upgrade zum Discovery-Service 1302. In Schritt 2404 überträgt der Discovery-Service 1302 die Benachrichtigung zum Lifecycle-Subsystem 220. In Schritt 2406 sendet das Lifecycle-Subsystem 220 die Benachrichtigung an das Administrations-Subsystem 208.
  • In Schritt 2408 aktualisiert das Administrations-Subsystem 208 die Versionsinformationen für die Komponentenanwendung. In Schritt 2410 wird ermittelt, ob die automatische Benachrichtigung aktiviert wurde. Wenn die automatische Aktivierung deaktiviert ist, erfolgen keine weiteren Schritte in Bezug auf die Benachrichtigung des Drahtlosgeräts 102. Wenn die automatische Benachrichtigung aktiviert ist, wird der Prozess mit Schritt 2412 fortgesetzt, wo eine Liste der zu benachrichtigenden Geräte abgerufen wird. In Schritt 2414 wird eine Kompakt-Message der Benachrichtigung für mehrere Drahtlosgeräte 102 erstellt, und in Schritt 2416 wird diese Nachricht übertragen. Sobald die Drahtlosgeräte 102 die Upgrade-Benachrichtigung empfangen, können sie ein Upgrade der Komponentenanwendung in gleicher Weise durchführen wie auch eine neue Komponentenanwendung erhalten wird. Da jedoch die Upgrade-Benachrichtigung Informationen enthält, die denen im Einsatzdeskriptor gleichen, muss der Einsatzdeskriptor nicht verwendet werden.
  • Unter Bezug auf 25 wird ein Beispiel gezeigt, wie der Gerätelaufzeit signalisiert wird, dass ein Upgrade der Laufzeitumgebung verfügbar ist. Dieses Beispiel veranschaulicht, wie ein Administrator ein Ereignis zum Upgraden der Laufzeitumgebung initiiert, was eine oder mehrere Laufzeitumgebungskomponenten einschließt.
  • In Schritt 2502 bereitet der Administrator eine Liste von Drahtlosgeräteparametern vor und übergibt diese an das Administrations-Subsystem 208. In Schritt 2504 fragt das Administrations-Subsystem 208 das Lifecycle-Subsystem 220 ab, und in Schritt 2504, wird an den Administrator eine Liste der Geräte zurückgegeben, die den Parametern entsprechen. Im vorliegenden Beispiel handelt es sich beim Parameter wahrscheinlich um eine Laufzeitumgebungsversion, und deshalb enthält die Liste alle Geräte, welche die angegebene Laufzeitumgebungsversion haben.
  • In Schritt 2506 überträgt der Administrator die Liste zusammen mit einer Anforderung zum Upgrade der Laufzeitumgebung zur Administrationskonsole 504. In Schritt 2508 überträgt die Administrationskonsole 504 die Anforderung zum Administrationsdienst 502. In Schritt 2510 erstellt der Administrationsdienst 502 eine Kompakt-Message des Upgrades für mehrere Drahtlosgeräte 102, und in Schritt 2512 wird die Nachricht übertragen. Sobald die Drahtlosgeräte 102 die Upgrade-Benachrichtigung empfangen, können sie das Upgrade der Laufzeitumgebung in gleicher Weise durchführen wie auch eine neue Laufzeitumgebung erhalten wird. Allerdings werden vor dem Upgrade der Laufzeitumgebung alle Anwendungen und Anwendungsdaten in der Laufzeitumgebung in ein XML/Script-Formular konvertiert. Das Upgrade der Laufzeitumgebung wird durchgeführt, und die Anwendungen und Anwendungsdaten werden aus der XML/Script-Formular für die neue Laufzeitumgebung wiederhergestellt.
  • In vielen der oben beschriebenen Situationen war es erforderlich, eine gemeinsame Kompakt-Message an mehrere Drahtlosgeräte zu übertragen. Dieser Prozess wird als eine geplante Aufgabenzustellung bezeichnet und wird im Folgenden beschrieben. Unter Bezug auf 26 wird ein Beispiel einer geplanten Aufgabenzustellung gezeigt. In Schritt 2602 bereitet der Administrationsdienst 502 eine Nachricht vor, die an eine Vielzahl von Drahtlosgeräten 102 übertragen werden soll. In Schritt 2604 wird die Nachricht an den Message-Broker 602 gesendet.
  • In Schritt 2606 plant der Message-Broker 602 eine Aufgabe zum Pushen der Nachricht in einer zeitlich geplanten oder gruppierten Weise. In Schritt 2608 führt der Message-Broker 602 die geplante Aufgabe aus. In Schritt 2610 erstellt der Message-Broker 602 für jedes Gerät in der Gruppe eine Systemnachricht, und in Schritt 2612 stellt er die Nachricht über den MDS 116 an das Drahtlosgerät 102 zu.
  • Demzufolge wird deutlich, dass der Anwendungs-Gateway-Server 118 generischen Drahtlosanwendungen die Kommunikation mit generischen, schemenbasierten Backend-Servern 108 erlaubt, ohne anwendungsspezifischen Code im Anwendungs-Gateway-Server 118 selbst einzusetzen. Stattdessen lädt das Gateway eine Anwendungszuordnung und konvertiert eingehende und ausgehende Anwendungsnachrichten in Formate und Protokolle, die für die ausgewählte Datenquelle spezifisch sind.
  • In der gesamten Beschreibung wurden verschiedene Begriffe durchgängig verwendet, um die Erklärung zu vereinfachen. Jedoch wird einem Fachmann auf dem Gebiet der Technik einleuchten, dass diese Begriffe in keiner Weise die Anmeldung einschränken sollen. So wurde zwar ein Drahtlosgerät genannt, aber es können auch andere, drahtgebundene Geräte wie z. B. ein Desktopcomputer verwendet werden. Entsprechend wird der Begriff 'Gerät' allgemein verwendet, um jedes drahtgebundene oder drahtlose Gerät wie einen Desktopcomputer, einen Laptop- oder Mobilcomputer, ein Smart-Phone, einen PDA (Personal Digital Assistant) und dergleichen zu bezeichnen.
  • Und um ein weiteres Beispiel zu nennen: Obwohl laut Beschreibung das Kompakt-Message-Format zur Kommunikation zwischen dem Anwendungs-Gateway 106 und dem Gerät 102 verwendet wird, muss das nicht so sein. Ein Grund für die Verwendung des Kompakt-Message-Formats ist die Einsparung von Bandbreite. Entsprechend muss für Systeme, bei denen die Bandbreite kein Problem darstellt, auch nicht das Kompakt-Message-Format verwendet werden.
  • In allen hier beschriebenen Beispielen ist die Gerätelaufzeit für das Abrufen der gepackten Anwendung verantwortlich, sobald diese bereitgestellt wurde. Dies wird typischerweise bevorzugt, weil – indem die Laufzeitumgebung die Kontrolle darüber erhält, was heruntergeladen wird – verhindert wird, dass Junk-Anwendungen zum Gerät 102 gepusht werden. Das muss allerdings nicht unbedingt so sein, und die gepackte Anwendung kann auch zum Gerät gepusht werden, wenn das gewünscht ist.
  • Obwohl bisher nicht explizit beschrieben, sieht das für das System verwendete Verschlüsselungsschema folgendermaßen aus. Die zwischen dem Gerät 102 und dem Anwendungs-Gateway 106 gesendeten Nachrichten werden mithilfe der Kryptographie mit symmetrischem Schlüssel verschlüsselt. Die Kryptographie mit symmetrischem Schlüssel wird verwendet, weil sie relativ praktisch ist, um einen symmetrischen Schlüssel sicher zum Gerät zu übertragen. Die Kryptographie mit einem Paar aus öffentlichem und privatem Schlüssel wird verwendet, um Nachrichten zwischen dem Gateway-Server und externen Systemen sicher zu übertragen, wodurch praktischerweise jedes System eine Nachricht sicher zum Gateway-Server übertragen kann. Wie dem Fachmann auf dem Gebiet der Technik einleuchten wird, ist die Auswahl eines Verschlüsselungsschemas eine Gestaltungsoption, und es können auch abweichende Verschlüsselungsschemas sowie Kombinationen aus diesen verwendet werden.
  • Komponentenanwendung
  • Unter Bezug auf 27 wird ein Blockdiagramm der Komponentenanwendung gezeigt, welche die Datenkomponenten 2700, die Präsentationskomponenten 2702 und die Nachrichtenkomponenten 2704 umfasst, die durch Workflow-Komponenten 2706 über die Kommunikation mit dem Anwendungscontainer 300 koordiniert werden. Mithilfe der strukturierten Definitionssprache können die Komponenten 2700, 2702, 2704 als eine Serie von Metadaten-Datensätzen erstellt werden, die aus einer Anzahl vordefinierter Elemente bestehen, die spezielle Attribute einer Ressource repräsentieren, so dass jedes Element einen oder mehrere Werte haben kann. Jedes Metadatenschema verfügt typischerweise über definierte Merkmale wie z. B. unter anderem: eine begrenzte Anzahl von Elementen, einen Namen von jedem Element und eine Bedeutung für jedes Element. Beispiele für Metadatenschemas sind beispielsweise unter anderem DC (Dublin Core), AACR2 (Anglo-American Cataloging Rules), GILS (Government Information Locator Service), EAD (Encoded Archives Description), IMS (IMS Global Learning Consortium) und AGLS (Australian Government Locator Service). Die Codierungssyntax ermöglicht die Verarbeitung der Metadaten der Komponenten 2700, 2702, 2704 durch die Geräteinfrastruktur 204 (siehe 2), und zu den Codierungsschemen zählen unter anderem beispielsweise XML, HTML, XHTML, XSML, RDF, MARC (Machine Readable Cataloging) und MIME (Multipurpose Internet Mail Extension).
  • Die Datenkomponenten 2700 definieren Dateninstanzen, die durch das Komponentenanwendungsprogramm verwendet werden. Beispiele für Dateninstanzen, die durch die Datenkomponenten 2700 beschrieben werden können, sind Aufträge, Benutzer und Finanztransaktionen. Die Datenkomponenten 2700 definieren, welche Informationen erforderlich sind, um die Dateninstanzen zu beschreiben, und in welchem Format die Informationen ausgedrückt werden. Beispielsweise kann die Datenkomponente 2700 unter anderem einen Auftrag definieren, der aus einer eindeutigen Kennung für den Auftrag besteht, die als eine Zahl definiert ist, aus einer Liste von Objekten, die als Zeichenfolgen formatiert sind, aus der Zeit, zu der der Auftrag erstellt wurde, die ein Datum-Uhrzeit-Format hat, aus dem Status des Auftrags, der als eine Zeichenfolge formatiert ist, und aus einem Benutzer, der den Auftrag erteilt hat und der gemäß der Definition einer anderen der Datenkomponenten 2700 formatiert ist. Da die Datenteile (Elemente) üblicherweise entsprechend den Webdienst-Choreographieregeln von Nachricht zu Nachricht übertragen werden, gibt es vorzugsweise eine Persistenz der Datenkomponenten 2700. Die Datenkomponenten 2700 können gemäß den Webdienst(e)-Choreographiedefinitionen (sofern verfügbar) dynamisch generiert werden, oder sie können durch den Anwendungsentwickler auf der Grundlage komplexer Typendefinitionen und/oder Nachrichtenkorrelationsinformationen definiert werden.
  • Die Nachrichtenkomponenten 2704 definieren das Format der vom Komponentenanwendungsprogramm 302 zur Kommunikation mit externen Systemen wie dem Webdienst verwendeten Nachrichten. Beispielsweise kann eine der Nachrichtenkomponenten 2704 unter anderem eine Nachricht zur Erteilung eines Auftrags beschreiben, die die eindeutige Kennung für den Auftrag, den Status des Auftrags sowie Notizen im Zusammenhang mit dem Auftrag einschließt. Die in der strukturierten Definitionssprache geschriebenen Definitionen der Nachrichtenkomponenten 2704 können WSDL-Nachrichten eindeutig repräsentieren (und Zuordnungen zu diesen ermöglichen) und können dynamisch zur Laufzeit generiert werden. Entsprechend kann die dynamische Generierung für die Komponentendefinitionen für Client-Anwendungsnachrichten – und für den assoziierten Dateninhalt – aus standardmäßigen Webdienst-Metadaten in der Definitionssprache erfolgen, die auch zum Ausdrücken der Webdienst-Schnittstelle verwendet wird, beispielsweise unter anderem WSDL und BPEL. Webdienst-Nachrichten werden im Kontext der Operation definiert, und es gibt definierte Korrelationen zwischen den Nachrichtenkomponenten 2704 in der Komponentenanwendungsprogrammdefinition. Diese Korrelation könnte mithilfe vordefinierter Nachrichtenparameter erzielt werden und/oder durch separate Workflow-Komponenten 2706, wie das weiter unten definiert wird.
  • Die Präsentationskomponenten 2702 definieren das Erscheinungsbild und das Verhalten des Komponentenanwendungsprogramms, wie es durch eine Benutzerschnittstelle angezeigt wird. Die Präsentationskomponenten 2702 können GUI-Bildschirme (Graphic User Interface) und Steuereinrichtungen spezifizieren sowie Aktionen, die ausgeführt werden müssen, wenn der Benutzer unter Verwendung der Benutzerschnittstelle mit der Komponentenanwendung interagiert. Beispielsweise können die Präsentationskomponenten 2702 Bildschirme, Beschriftungen, Bearbeitungsfelder, Schaltflächen und Menüs definieren sowie Aktionen, die durchgeführt werden sollen, wenn der Benutzer eine Eingabe in ein Textfeld vornimmt oder auf eine Schaltfläche drückt. Die Mehrzahl der Webdienst-Kunden verwenden eine visuelle Präsentation der Webdienst-Operationsergebnisse und stellen deshalb die Laufzeitumgebung auf ihren Geräten so zur Verfügung, dass diese Bildschirme der Benutzerschnittstelle anzeigen kann.
  • Es sollte erkennbar sein, dass im oben beschriebenen Hosting-Modell für Client-Komponentenanwendungsprogrammdefinitionen die Präsentationskomponenten 2702 in Abhängigkeit von der Client-Plattform und der Umgebung des Geräts abweichen können. Beispielsweise benötigen in einigen Fällen die Webdienst-Kunden keine visuelle Präsentation. Die Anwendungsdefinition der Komponenten 2700, 2702, 2704, 2706 des Komponentenanwendungsprogramms 302 kann in einer Webdienst-Registratur in einem Metadaten-Repository 700 gehostet werden, und zwar als ein Bündel von plattformneutralen Deskriptoren für Datenkomponenten 2700, Nachrichtenkomponenten 2704, Workflow-Komponenten 2706 mit einem Set von plattformspezifischen Deskriptoren für Präsentationskomponenten 2702 für verschiedene vordefinierte Client-Laufzeiten. Wenn die Discovery- oder Einsatzanforderungsnachricht ausgegeben wird, sollte der Client-Typ als Teil dieser Anforderungsnachricht spezifiziert sein. Um eine Duplizierung von Daten-, Nachrichten- und Workflow-Metadaten beim Packen von Komponentenanwendungsprogrammen für unterschiedliche Client-Plattformen auf den Geräten zu vermeiden, können Anwendungsdefinitionen beispielsweise auf dem Anwendungsserver gehostet werden, als ein Bündel von plattformneutralen Komponentendefinitionen, die mit unterschiedlichen Sets von Präsentationskomponenten 2703a, 2703b, 2703c verknüpft sind und die unterschiedlichen unterstützten Benutzerschnittstellen auf den Geräten repräsentieren. Es sollte außerdem erkennbar sein, dass eine standardmäßige Präsentationskomponente 2702 für den Fall verwendet werden kann, wenn das spezielle Gerät nicht explizit unterstützt wird, wodurch zumindest ein beschränktes Set der Präsentationsmerkmale bereitgestellt wird. Wenn ein Benutzer eine Discovery- oder Download-Anforderungsnachricht auslöst, wird der Client-Laufzeittyp der Geräte validiert, und das richtige Bündel wird zur Zustellung durch den Webserver 106 zum Gerät 100 über das Netz 104 erstellt. Für solche Webdienst-Kunden könnten die Client-Anwendungsprogramme 302 ausgewählte Präsentationskomponenten 2703 enthalten, die über die Workflow-Komponenten 2706 mit den Datenkomponenten 2700 und den Nachrichtenkomponenten 2704 verknüpft sind, wodurch eine angepasste Komponentenanwendung 302 bereitgestellt wird.
  • Die Workflow-Komponenten 2706 des Komponentenanwendungsprogramms definieren die Verarbeitung, die erfolgt, wenn eine Aktion durchgeführt werden soll, beispielsweise eine Aktion, die wie oben beschrieben durch eine Präsentationskomponente 2702 spezifiziert wird, oder eine Aktion, die durchgeführt werden soll, wenn Nachrichten für das System eintreffen. Die Präsentations-, Workflow- und Nachrichtenverarbeitung wird durch die Workflow-Komponenten 2706 definiert. Die Workflow-Komponenten 2706 sind als eine Serie von Anweisungen in einer Programmiersprache oder in einer Scripting-Sprache geschrieben, wie beispielsweise unter anderem ECMASript, und können zu nativem Code kompiliert und durch den Anwendungscontainer ausgeführt werden, wie das oben beschrieben wurde. Ein Beispiel der Workflow-Komponenten 2706 kann das Zuweisen von Werten zu Daten, das Manipulieren von Bildschirmen oder das Senden der Nachricht sein. Die Workflow-Komponente 2706 unterstützt eine Korrelation zwischen den Nachrichten und definiert den Anwendungsfluss als ein Set von Regeln für Operationen an den anderen Komponenten 2700, 2702, 2704.
  • Gerätelaufzeitumgebung
  • Die Gerätelaufzeitumgebung lädt die in den Definitionen der Komponenten 2700, 2702, 2704, 2706 enthaltenen Metadaten und erstellt dann über einen Anwendungscontainer 300 eine ausführbare Version des Anwendungsprogramms 302 auf dem Gerät 100. Beispielsweise gibt es zwei Operationsmodelle für die Client-Laufzeit: die vorlagenbasierte native Ausführung und die metadatenbasierte Ausführung. Beim vorlagenbasierten nativen Ausführungsmodell hostet die Laufzeit mithilfe des nativen Codes zuvor erstellte Daten-, Nachrichten- und Bildschirmvorlagen auf dem Gerät. Wenn die Anwendungsprogrammdefinition geladen wird, füllt die durch das Komponentengerüst bereitgestellte Client-Umgebung die Vorlagen mit metadatendefinierten Parametern von den Komponenten 2700, 2702, 2704 aus und erstellt das ausführbare Client-Anwendungsprogramm im nativen Format. Das Workflow-Script (zum Beispiel ECMAScript) der Workflow-Komponente 2706 könnte entweder in nativen Code konvertiert oder mithilfe eines ECMAScript-Interpreters zu einem nativen Code-Umleiter ausgeführt werden, wobei der Umleiter Aufrufe an die Scripting-Sprache über eine native Laufzeit-Engine als Operationen auf nativen Komponenten interpretiert. Bei der metadatenbasierten Ausführung behält die Laufzeitumgebung des Komponentengerüsts entweder die Definitionen der Komponenten 2700, 2702, 2704, 2706 in XMS (zum Beispiel), die dann während der Ausführungszeit syntaktisch analysiert werden, oder sie verwendet eine native Repräsentation von XML-Knoten. Während der Ausführung beruht die Operation der nativen Laufzeit-Engine 506 auf den Definitionen der Komponenten 2700, 2702, 2704, 2706 anstatt auf nativen Komponenteninstanzen. Es sollte erkennbar sein, dass der vorlagenbasierte Ansatz unter Performance-Gesichtspunkten zwar effizienter sein kann als der metadatenbasierte Ansatz, jedoch eine kompliziertere Ausführungsumgebung erfordern und mehr Speicherressourcen beanspruchen kann.
  • Obwohl hier bevorzugte Ausführungsformen der Erfindung beschrieben wurden, dürfte dem Fachmann auf dem Gebiet der Technik einleuchten, dass an der Erfindung im Rahmen der beigefügten Ansprüche Variationen vorgenommen werden können.

Claims (15)

  1. Ein Anwendungs-Gateway-Server (118) zur Verwaltung der Kommunikation zwischen einer Anwendung, die in einer Laufzeitumgebung auf einem Gerät (102) ausgeführt wird, und mindestens einem Backend-Server (106), wobei der Anwendungs-Gateway-Server (118) umfasst: einen Message-Listener (232) zum Empfangen von Nachrichten von der Anwendung; ein Connector-Subsystem (222), umfassend eine Vielzahl von Connectoren (806), wobei jeder aus der Vielzahl von Connectoren (806) der Kommunikation mit einem oder mehreren assoziierten Backend-Servern (106) dient; ein Messaging-Subsystem (224), umfassend einen Message-Broker (602) für die Bearbeitung der vom Message-Listener (232) empfangenen Nachrichten und für deren Übertragung zu einem assoziierten aus der Vielzahl der Connectoren (806); wobei der Anwendungs-Gateway-Server (118) dadurch gekennzeichnet ist, dass das Messaging-Subsystem (224) des Weiteren eine Kommunikationszuordnung umfasst, um eine Identifizierung zu ermöglichen, welcher aus der Vielzahl von Connectoren (806) entsprechend einem Ursprung einer Nachricht für eine Nachricht verwendet werden soll.
  2. Der Anwendungs-Gateway-Server (118) gemäß Anspruch 1, des Weiteren umfassend ein Lifecycle-Subsystem zum Führen einer Liste von Geräten (102) und der darauf installierten Anwendung, um sicherzustellen, dass gültige Nachrichten übertragen werden.
  3. Der Anwendungs-Gateway-Server (118) gemäß Anspruch 2, wobei das Lifecycle-Subsystem so ausgelegt ist, dass es die Anwendung verifiziert, die eine Nachricht überträgt, um die Installation von bösartigen Anwendungen zu verhindern.
  4. Der Anwendungs-Gateway-Server (118) gemäß Anspruch 2 oder Anspruch 3, wobei das Lifecycle-Subsystem so ausgelegt ist, dass es die Anwendung verifiziert, die eine Nachricht vom Backend-Server (106) empfängt, um die für fehlerhafte Nachrichten genutzte Bandbreite zu reduzieren.
  5. Der Anwendungs-Gateway-Server (118) gemäß einem der Ansprüche 1 bis 3, wobei die Kommunikationszuordnung Details dazu umfasst, wie der Inhalt der Nachricht interpretiert wird, bevor sie zum Backend-Server (106) gesendet wird.
  6. Der Anwendungs-Gateway-Server (118) gemäß einem der Ansprüche 1 bis 5, des Weiteren umfassend ein Transformations-Subsystem zum Transformieren der Nachricht zwischen einem kompakten Nachrichtenformat, das zur Kommunikation zwischen dem Gerät (102) und dem Anwendungs-Gateway-Server (118) verwendet wird, und einem internen Nachrichtenformat, das für die Kommunikation anderswo verwendet wird.
  7. Ein Verfahren zur Verwaltung der Kommunikation auf einem Anwendungs-Gateway-Server (118) zwischen einer Anwendung, die in der Laufzeitumgebung auf einem Gerät (102) ausgeführt wird, und mindestens einem Backend-Server (106), wobei das Verfahren die folgenden Schritte umfasst: das Empfangen von Nachrichten von der Anwendung an einem Message-Listener (232); das Zuordnen der Nachrichten zu einem Ziel-Backend-Server (106); das Zustellen der Nachrichten zu einem Connector (806) entsprechend dem Ziel-Backend-Server (106); und das Zustellen der Nachricht zu diesem Backend-Server (106); wobei das Verfahren dadurch gekennzeichnet ist, dass die Nachrichten zuordnung entsprechend einer vordefinierten Kommunikationszuordnung und einem Ursprung der Nachricht durchgeführt wird.
  8. Das Verfahren gemäß Anspruch 7, des Weiteren umfassend die Schritte des Entschlüsselns der von der Anwendung empfangenen Nachricht.
  9. Das Verfahren gemäß Anspruch 7 oder Anspruch 8, des Weiteren umfassend die Schritte des Validierens der von der Anwendung empfangenen Nachricht.
  10. Das Verfahren gemäß einem der Ansprüche 7 bis 9, des Weiteren umfassend den Schritt des Transformierens der Nachricht zwischen einem kompakten Nachrichtenformat, das zur Kommunikation zwischen dem Gerät (102) und dem Anwendungs-Gateway-Server (118) verwendet wird, und einem internen Nachrichtenformat, das für die Kommunikation anderswo verwendet wird.
  11. Das Verfahren gemäß einem der Ansprüche 7 bis 10, wobei die Zustellung der Nachricht zum Backend-Server (106) synchron erfolgt.
  12. Das Verfahren gemäß einem der Ansprüche 7 bis 11, wobei die Nachricht eine Registrierung zur Benachrichtigung von der Anwendung zu einem Backend-Server (106) ist, und das Verfahren des Weiteren die folgenden Schritte umfasst: das Empfangen einer Antwort vom Backend-Server (106), wobei die Antwort eine externe Korrelatorkennung umfasst; das Speichern der externen Korrelatorkennung zur Identifizierung der Anwendung beim Empfang einer Benachrichtigungsnachricht vom Backend-Server.
  13. Das Verfahren gemäß einem der Ansprüche 1 bis 12, wobei die Anwendung eine Komponentenanwendung ist.
  14. Eine Kommunikationsinfrastruktur (100), umfassend eine Vielzahl von Drahtlosgeräten (102), ein Kommunikationsnetz (104), das die Drahtlosgeräte in die Lage versetzt, mit mindestens einem Backend-Server (106) zu kommunizieren, und umfassend den Anwendungs-Gateway-Server (118) gemäß einem der Ansprüche 1 bis 6 und Anspruch 13 bei Anfügung an einen der Ansprüche 1 bis 6, zum Verwalten der Kommunikation zwischen einer Anwendung, die in der Laufzeitumgebung auf einem der erwähnten Geräte (102) ausgeführt wird, und dem mindestens einen Backend-Server (106).
  15. Ein maschinenlesbares Medium, umfassend Computercodemittel, die bei ihrer Ausführung dem Anwendungs-Gateway-Server (118) gemäß einem der Ansprüche 1 bis 6 ermöglichen, das Verfahren gemäß einem der Ansprüche 7 bis 13 zu implementieren.
DE602005005435T 2005-01-24 2005-01-24 System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen Active DE602005005435T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP05100435A EP1684482B1 (de) 2005-01-24 2005-01-24 System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen

Publications (2)

Publication Number Publication Date
DE602005005435D1 DE602005005435D1 (de) 2008-04-30
DE602005005435T2 true DE602005005435T2 (de) 2008-07-03

Family

ID=34938563

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005005435T Active DE602005005435T2 (de) 2005-01-24 2005-01-24 System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen

Country Status (7)

Country Link
EP (1) EP1684482B1 (de)
CN (1) CN100505711C (de)
AT (1) ATE390011T1 (de)
CA (1) CA2533543C (de)
DE (1) DE602005005435T2 (de)
HK (1) HK1091067A1 (de)
SG (1) SG124389A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060282516A1 (en) * 2005-04-18 2006-12-14 Taylor Sean P System and method for discovering component applications
CN100365583C (zh) * 2006-08-03 2008-01-30 华为技术有限公司 组件的实现方法以及系统
US8028072B2 (en) * 2008-03-03 2011-09-27 International Business Machines Corporation Method, apparatus and computer program product implementing session-specific URLs and resources
US20100306321A1 (en) * 2009-05-29 2010-12-02 Microsoft Corporation Delivering messages using user-defined agents
CN102395123B (zh) * 2011-10-31 2014-12-10 中兴通讯股份有限公司 管理服务器，以及移动终端的应用程序管理方法
JP2014170491A (ja) * 2013-03-05 2014-09-18 Fuji Xerox Co Ltd 中継装置、システム及びプログラム
CN111857799A (zh) * 2020-06-30 2020-10-30 海尔优家智能科技（北京）有限公司 组件信息的传输方法及装置、存储介质、电子装置
CN114501186B (zh) * 2022-01-28 2023-10-03 瀚云科技有限公司 一种数据采集系统、方法、电子设备及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020032783A1 (en) * 1999-12-30 2002-03-14 Tuatini Jeffrey T. Shared service funtionality invocation
US20030120593A1 (en) * 2001-08-15 2003-06-26 Visa U.S.A. Method and system for delivering multiple services electronically to customers via a centralized portal architecture

Also Published As

Publication number Publication date
SG124389A1 (en) 2006-08-30
CA2533543C (en) 2011-11-08
DE602005005435D1 (de) 2008-04-30
HK1091067A1 (en) 2007-01-05
CA2533543A1 (en) 2006-07-24
CN1812382A (zh) 2006-08-02
CN100505711C (zh) 2009-06-24
EP1684482A1 (de) 2006-07-26
ATE390011T1 (de) 2008-04-15
EP1684482B1 (de) 2008-03-19

Similar Documents

Publication Publication Date Title
US7853674B2 (en) System and method for provisioning component applications
DE60102305T2 (de) Migration von prozessen unter benutzung einer darstellung dieser prozesse in einer daten-darstellungssprache in einer verteilten rechnerumgebung
DE60101911T2 (de) Verfahren und vorrichtung zum zugriff und zur adressierung von diensten in einer verteilten rechnerumgebung
US8446911B2 (en) System and method for managing communication for component applications
DE60104678T2 (de) Mechanismus und vorrichtung um dienst-ergebnissen einer verteilten rechnerumgebung zurückzuliefern
DE602005005435T2 (de) System und Verfahren zur Kommunikationsverwaltung von Komponentenanwendungen
US7370075B2 (en) Method and apparatus for managing web services within a computer network system
DE60102234T2 (de) Verfahren und vorrichtung zur ermittlung von benachbarten diensten
DE60123289T2 (de) Ereignisnachricht-endstelle in einer verteilten rechnerumgebung
DE602005006391T2 (de) System und verfahren zum asynchronen kommunizieren mit web-diensten unter verwendung von nachrichtensatzdefinitionen
DE60315558T2 (de) Verteiltes Rechnersystem für Vorrichtungsresourcen basierend auf Identität
DE60218069T2 (de) Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung
EP1872523B1 (de) System und Verfahren zur Registration von Einrichtung zu Server
CA2533608C (en) System and method for provisioning component applications
US20060248181A1 (en) Formatted and/or tunable QOS data publication, subscription, and/or distribution servers and clients
EP1370951A2 (de) Nachrichteninfrastruktur für den identitätszentrischen datenzugriff
EP1872256B1 (de) System und verfahren zur abfallbehandlung
DE60101740T2 (de) Transformation von objekten zwischen einer rechnerprogrammiersprache und einer daten-darstellungssprache
US8391845B2 (en) System and method of presenting entities of standard applications in wireless devices
DE60121605T2 (de) Aufruf einer entfernten funktion mit nachrichten in einer verteilten rechnerumgebung
US7849157B2 (en) System and method for consumer entitlements in portal services
EP1875372B1 (de) System und verfahren der anwendungspersistenz
Kyriazis et al. Achieving real-time in distributed computing: From grids to clouds
Lund et al. SOA pilot 2011-service infrastructure
Familiar et al. Azure, A Microservice Platform

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: MERH-IP, 80336 MUENCHEN