DE602005004382T2 - System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen - Google Patents

System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen Download PDF

Info

Publication number
DE602005004382T2
DE602005004382T2 DE602005004382T DE602005004382T DE602005004382T2 DE 602005004382 T2 DE602005004382 T2 DE 602005004382T2 DE 602005004382 T DE602005004382 T DE 602005004382T DE 602005004382 T DE602005004382 T DE 602005004382T DE 602005004382 T2 DE602005004382 T2 DE 602005004382T2
Authority
DE
Germany
Prior art keywords
data
message
model
data structure
application
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
DE602005004382T
Other languages
English (en)
Other versions
DE602005004382D1 (de
Inventor
Daniel Toronto Mateescu
Michael V. Brampton Cacenco
Bryan R. Milton Goring
Viera Kilbride Bibr
Michael L4C 3S9 Richmond Hill Shenfield
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 DE602005004382D1 publication Critical patent/DE602005004382D1/de
Application granted granted Critical
Publication of DE602005004382T2 publication Critical patent/DE602005004382T2/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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)
  • Communication Control (AREA)
  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Description

  • Die vorliegende Anmeldung bezieht sich allgemein auf die Kommunikation zwischen einer Kundenanwendung und einer über ein Netzwerk verbundenen Datenquelle.
  • Es werden heutzutage in ständig wachsender Anzahl Endgeräte und Mobilgeräte verwendet, wozu z. B. Smart Phones, PDAs (Personal Digital Assistants) mit Fähigkeit zur Drahtloskommunikation, PCs (Personal Computers), Selbstbedienungskioske und Zweiwege-Pager/Kommunikationsgeräte gehören. Software-Anwendungen, die auf diesen Geräten ausgeführt werden, steigern deren Nutzen. Beispielsweise kann ein Smart Phone eine Anwendung enthalten, die das Wetter für eine Reihe von Städten abruft, oder ein PDA kann eine Anwendung enthalten, die es einem Benutzer ermöglicht, Lebensmittel einzukaufen. Diese Software-Anwendungen nutzen die Konnektivität zu einem Netzwerk, um den Benutzern zeitnahe und nützliche Dienste bereitzustellen. Allerdings bleibt aufgrund der beschränkten Ressourcen von einigen Geräten und wegen der Komplexität der Zustellung großer Datenmengen zu den Geräten die Entwicklung und Pflege von Software-Anwendungen, die auf eine große Vielfalt von Geräten zugeschnitten sind, eine schwierige und zeitaufwändige Aufgabe.
  • Eine große Herausforderung, die es bei der Exponierung komplexer Datenquellen (wie z. B. Webdienste) für das Drahtlosgerät zu meistern gilt, besteht in der Größe und Komplexität der Datenstrukturen, die beim Messaging zwischen dem Gerät und dem Webdienst kommuniziert werden. In der drahtgebundenen Welt, wo Ressourcen und Effizienz keine solche Bedeutung haben, ist es zulässig, große und komplexe Strukturen von Daten hin und zurück zu übertragen. Um eine Drahtlosanwendung effizient arbeiten zu lassen, ist es effektiv, den Entwickler festlegen zu lassen, wie Nachrichten aus der Perspektive der benötigten wesentlichen Informationen dem Gerät präsentiert werden sollen.
  • Die hier offenbarten Systeme und Methoden stellen ein Entwicklungstool bereit, mit dem sich zumindest einige der oben erwähnten Nachteile vermeiden oder verringern lassen.
  • Verwandte Probleme bestehen bei der Entwicklung von semantischen Webdiensten, die darauf ausgerichtet sind, durch andere Software-Agenten leicht zugänglich zu sein. Diese werden in einem Artikel von Mark H. Burnstein mit dem Titel "The Many Faces of Mapping and Translation for Semantic Web Services" (Web Information Systems Engineering, 2003.Wise 2003. Proceedings of the Fourth International Conference an 10–12 Dec. 2003 Piscataway, NJ, USA, IEEE, (2003-12-10) Seiten 261–268, XP010674533 ISBN: 0-765-1999-7 diskutiert. Dort wird ein spezielles Beispiel der Kommunikation zwischen Agenten mit unterschiedlichen Ontologien angeführt, bei der eine gemeinsame Ontologie entwickelt wird, der beide Agenten zugeordnet werden.
  • ALLGEMEINES
  • Im Gegensatz zu aktuellen Umgebungen zur Anwendungsentwicklung werden ein System und eine Methode zur Erzeugung eines Erfassungsmodells bereitgestellt, um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen und zu überwachen. Das erste Nachrichtenformat ist für den Gebrauch eines Kunden konfiguriert und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle. Die Datenquelle ist konfiguriert für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells. Das System und die Methode umfasst: ein Anwendungsmodul zur Bereitstellung einer Beschreibung des ersten Nachrichtenformats, das erste Nachrichtenformat umfasst mindestens ein Nachrichtenelement des Kunden zur Zusammenstellung in einer ersten Datenstruktur; ein Datenquellenmodul zur Bereitstellung einer Beschreibung des zweiten Nachrichtenformats, das zweite Nachrichtenformat umfasst eine Vielzahl an Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer Datenstruktur mit mehreren Abschnitten, die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle; ein Erfassungsmodul zur Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur mit der zweiten Daten struktur, die Erfassungsdeskriptoren zur Verlinkung des mindestens einen Nachrichtenelements des Kunden der ersten Datenstruktur mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur, wenn die Anzahl der Abschnitte in der zweiten Datenstruktur größer ist als die Anzahl der Abschnitte in der ersten Datenstruktur; wobei das Erfassungsmodell, das die Erfassungsdeskriptoren einschließt, anschließend verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  • Dementsprechend wird vorzugsweise ein System zur Erstellung eines Erfassungsmodells bereitgestellt, um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen und zu überwachen, wobei das erste Nachrichtenformat für den Gebrauch eines Kunden und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle konfiguriert ist, die Datenquelle für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells konfiguriert ist, und das System umfasst: ein Anwendungsmodul zur Bereitstellung einer Beschreibung des ersten Nachrichtenformats, wobei das erste Nachrichtenformat mindestens ein Nachrichtenelement des Kunden zur Zusammenstellung in einer ersten Datenstruktur umfasst; ein Datenquellenmodul zur Bereitstellung einer Beschreibung des zweiten Nachrichtenformats, wobei das zweite Nachrichtenformat eine Vielzahl an Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer Datenstruktur mit mehreren Abschnitten umfasst, wobei die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle umfassen; ein Erfassungsmodul zur Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur mit der zweiten Datenstruktur, wobei die Erfassungsdeskriptoren das mindestens eine Nachrichtenelement des Kunden der ersten Datenstruktur mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur verlinken, wenn die Anzahl der Abschnitte in der zweiten Datenstruktur größer ist als die Anzahl der Abschnitte in der ersten Datenstruktur; wobei das Erfassungsmodell, das die Erfassungsdeskriptoren einschließt, anschließend verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  • Ebenfalls offenbart wird eine Methode zur Erzeugung eines Erfassungsmodells, um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen und zu überwachen, wobei das erste Nachrichtenformat für den Gebrauch eines Kunden und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle konfiguriert ist, die Datenquelle konfiguriert für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells, und die Methode die folgenden Schritte umfasst: Erhalt einer Beschreibung des ersten Datenformats, wobei das erste Datenformat mindestens ein Kundennachrichtenelement zur Zusammenstellung in einer ersten Datenstruktur umfasst; Erhalt einer Beschreibung des zweiten Datenformats, wobei das zweite Datenformat eine Vielzahl von Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer zweiten Datenstruktur mit mehreren Abschnitten umfasst, wobei die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle dienen; Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur mit der zweiten Datenstruktur, wobei die Erfassungsdeskriptoren zur Verlinkung des mindestens einem Nachrichtenelement des Kunden der ersten Datenstruktur mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur dienen, wenn die Anzahl der Abschnitte in der zweiten Datenstruktur größer ist als die Anzahl der Abschnitte in der ersten Datenstruktur; wobei das Erfassungsmodell, das die Erfassungsdeskriptoren einschließt, anschließend verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  • Ebenfalls offenbart wird ein Computerprogrammprodukt zur Erzeugung eines Erfassungsmodells, um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen, wobei das erste Nachrichtenformat für den Gebrauch eines Kunden und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle konfiguriert ist, die Datenquelle für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells konfiguriert ist, und das Computerprogrammprodukt umfasst: ein computerlesbares Medium; ein Anwendungsmodul zum Erhalt einer Beschreibung des ersten Datenformats, wobei das erste Datenformat mindestens ein Kundennachrichtenelement zur Zusammenstellung in einer ersten Datenstruktur umfasst; ein Datenquellenmodul zum Erhalt einer Beschreibung des zweiten Datenformats, wobei das zweite Datenformat eine Vielzahl von Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer zweiten Datenstruktur mit mehreren Abschnitten umfasst, wobei die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle dienen; ein Erfassungsmodul zur Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur mit der zweiten Datenstruktur, die Erfassungsdeskriptoren zur Verlinkung des mindestens einem Nachrichtenelement des Kunden der ersten Datenstruktur mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur dienen, so dass eine Anzahl der Abschnitte in der ersten Datenstruktur nicht größer ist als die Anzahl der Abschnitte in der zweiten Datenstruktur; wobei das Erfassungsmodell, das die Erfassungsdeskriptoren einschließt, verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  • Beim bevorzugten System und der bevorzugten Methode entsprechend der Erfindung ist der Kunde drahtlos mit dem Netzwerk verbunden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Diese und weitere Merkmale werden aus der nachfolgenden detaillierten Beschreibung noch deutlicher, in der Bezug auf die beigefügten Zeichnungen genommen wird, welche folgende Bedeutung haben:
  • 1 ist ein Blockdiagramm eines Kommunikationsnetzwerksystems;
  • 2 ist ein Blockdiagramm eines Tools zum Entwickeln und Erzeugen der Anwendungen aus 1;
  • 3 ist ein Blockdiagramm des Netzwerk-Messaging aus 1;
  • 4 ist ein Beispiel eines Nachrichtenzuordnungs- bzw. -erfassungsmodells beim Messaging aus 3;
  • 5 zeigt eine exemplarische Operation des Tools aus 1;
  • 6 ist ein Blockdiagramm der Toolarchitektur aus 2;
  • 7 zeigt eine exemplarische Konfiguration der Anwendung aus 1;
  • 8 zeigt eine exemplarische Baumrepräsentation des Inhalts einer drahtlosen Nachricht und deren Felder der Anwendung aus 1;
  • 9 ist ein Blockdiagramm des gesamten Zuordnungs- bzw. Erfassungsprozesses aus 5; und
  • 10 ist ein Blockdiagramm der Zuordnungs- bzw. Erfassungserzeugung aus 9.
  • BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
  • Netzwerksystem
  • Bezug nehmend auf 1, umfasst ein Netzwerksystem 10 die mobilen Kommunikationsgeräte 100 zum Interagieren mit einer oder mehreren Backend-Datenquellen 106 (z. B. einem schemabasierten Dienst wie ein Webdienst oder eine Datenbank, die durch eine Anwendung 105 verwendete Enterprise-Dienste bereitstellt) über ein Drahtlosnetzwerk 102, das mit einem Anwendungs-Gateway AG verbunden ist. Bei den Geräten 100 handelt es sich unter anderem um Geräte wie Mobiltelefone, PDAs, Zweiwege-Pager, Dualmodus-Kommunikationsgeräte. Es wird anerkannt, dass das Anwendungs-Gateway AG und die Datenquellen 106 über nach dem Stand der Technik bekannte Extranets (z. B. das Internet) und/oder Intranets verlinkt sein können. Das Anwendungs-Gateway AG handhabt durch die Anwendung 105 initiierte Anforderungs-/Antwortnachrichten sowie von den Datenquellen 106 zum Gerät 100 gepushte Abonnementbenachrichtigungen. Das Anwendungs-Gateway AG funktioniert als ein Datenzuordnungsserver (Data Mapping Server) zum Vermitteln des Messaging zwischen einer Client-Laufzeitumgebung RE auf dem Gerät 100 (auf dem die Anwendung(en) 105 ausgeführt werden) und einem Backend-Server der Datenquellen 106. Das Gateway AG kann für das asynchrone Messaging für die Anwendungen 105 sorgen und kann Legacy-Backend-Datenquellen 106 integrieren und mit diesen kommunizieren. Die Geräte 100 übertragen und empfangen die Drahtlosanwendungen 105, wie das weiter unten beschrieben wird, wenn sie mit den Datenquellen 106 kommunizieren, und sie übertragen/empfangen das Messaging, das mit der Operation der Anwendungen 105 assoziiert ist. Die Geräte 100 operieren als Web-Clients der Datenquellen 106 durch die Ausführung der Anwendungen 105, wenn diese in den jeweiligen Laufzeitumgebungen RE (Runtime Environment) der Geräte 100 bereitgestellt werden.
  • Zur Erledigung des entsprechenden Messaging, das mit den Anwendungen 105 verbunden ist, kommuniziert das Anwendungs-Gateway AG mit den Datenquellen 106 über verschiedene Protokolle (unter anderem über HTTP, SQL und Component API) zum Exponieren relevanter Business-Logik (Methoden) für die Anwendungen 105, sobald sie auf den Geräten 100 bereitgestellt sind. Die Anwendungen 105 können die Business-Logik der Datenquellen 106 ähnlich dem Aufrufen einer Methode für ein Objekt (oder eine Funktion) verwenden. Es wird anerkannt, dass die Anwendungen 105 in Bezug auf die Datenquellen 106 über das Netzwerk 102 und das Anwendungs-Gateway AG direkt auf die Geräte 100 heruntergeladen/hochgeladen werden können. Beispielsweise ist das Anwendungs-Gateway AG mit einem Bereitstellungsserver 108 und einem Discovery-Server 110 verbunden, um einen Mechanismus zur optimierten OTA-Bereitstellung (Over the Air) der Anwendungen 105 bereitzustellen, einschließlich Fähigkeiten für die Ermittlung (Discovery) der Anwendung 105 vom Gerät 100 aus entsprechend der Auflistung in z. B. einer UDDI-Registrierung (Universal Description, Discovery and Integration) 112. Die Registrierung 112 ist ein Verzeichnisdienst, wo Unternehmen Webdienste registrieren und nach ihnen suchen können, und sie kann Bestandteil des durch den Server 110 implementierten Discovery-Dienstes sein. Die Registrierung 112 wird zur Veröffentlichung der Anwendungen 105 verwendet. Die Information zur Anwendung 105 in der Registrierung 112 können unter anderem eine Bereitstellungsdeskriptor (Deployment Descriptor – DD) (enthält Informationen wie z. B. den Namen, die Version und die Beschreibung der Anwendung 105) sowie die Position dieser Anwendung 105 in einem Anwendungs-Repository 114 enthalten. Die Registrierung kann ein Verzeichnis zum Speichern von Informationen über Webdienste (bereitgestellt durch die Datenquellen 106) bereitstellen, einschließlich eines Verzeichnisses von Webdienstschnittstellen, die z. B. durch WSDL beschrieben sind.
  • Außerdem basiert UDDI als eine Registrierung 112 auf Internet-Standards wie unter anderem XML-, HTTP- und DNS-Protokollen.
  • Wiederum unter Bezug auf 1 kann zur Initialisierung der Laufzeitumgebung RE die RE die URL des Gateways AG und den öffentlichen Schlüssel des Gateways AG in einem Dienstbuch des MDS 115 empfangen. Die Laufzeitumgebung RE verwendet diese Informationen, um die Verbindung zum Gateway AG für das anfängliche Handshaking herzustellen. Durch die Bereitstellung des Geräts 100 oder von BES 116 wird in Abhängigkeit von der Domäne das Dienstbuch des MDS 115 zum Gerät 100 gepusht. Es wird anerkannt, dass es je nach Wunsch auch mehr als ein Gateway AG geben kann. Nach der Initialisierung kann der Zugriff auf die Anwendungen 105 durch die Geräte 100 nach dem Herunterladen/Hochladen über das Gateway AG direkt von dem Anwendungs-Repository 114 kommuniziert werden und/oder in Verbindung mit dem Direktzugriff (nicht dargestellt) der Datenquelle (106) auf das Repository 114.
  • Exemplarische Datenquelle 106
  • Die Datenquellen 106 können beispielsweise mithilfe von WSDL (Web Services Description Language) beschrieben werden und deshalb dem Netzwerk als ein Dienst präsentiert werden, der üblicherweise als ein Webdienst bezeichnet wird. Beispielsweise wird WSDL in XML als ein XML-Dokument geschrieben, das zur Beschreibung von Webdiensten und zur Lokalisierung von Webdiensten verwendet wird, d. h. das XML-Dokument kann die Position des Webdienstes und der Operationen (oder Methoden) spezifizieren, die der Dienst für das Netzwerk (z. B. das Internet) exponiert. Das WSDL-Dokument definiert den Webdienst mithilfe von Hauptelementen, zu denen unter anderem gehören: <portType> – die durch den Webdienst ausgeführten Operationen (jede Operation kann mit einer Funktion in einer traditionellen Programmiersprache verglichen werden, so dass die Funktion auf dem Webdienst selbst resident ist); <message> – die durch den Webdienst verwendeten Nachrichtenformate; <types> – die durch den Webdienst verwendeten Datentypen, die typischerweise Bestandteil der Nachrichten selbst sind; und <binding> – die durch den Webdienst verwendeten Kommunikationsprotokolle zur Kommunikation der Nachrichten zwischen dem Webdienst und dem Anwendungs-Gateway AG. Außerdem könnte ein Dienstelement in das WSDL-Dokument eingeschlossen werden, um die Position (z. B. URL) des Webdienstes selbst zu identifizieren und um die logische Netzwerkverbindung zwischen dem Anwendungs-Gateway (zum Beispiel) und dem Webdienst gemäß den durch das binding-Element bereitgestellten Kommunikationsprotokollen zu verwalten.
  • Das WSDL-Dokument kann beispielsweise durch das Anwendungs-Gateway AG zum Makeln des Messaging zwischen dem Webdienst und dem Gerät bzw. den Geräten verwendet werden. Das WSDL-Dokument kann auch andere Elemente enthalten, beispielsweise Erweiterungselemente und ein Dienstelement, was es ermöglicht, die Definitionen mehrer Webdienste zu einem einzigen WSDL-Dokument zusammenzufassen. Das Element <portType> definiert den Webdienst, die Operationen, die durch den Webdienst ausgeführt werden können, sowie die Nachrichten, die im Hinblick auf die Webdienstoperationen involviert sind. Ein WSDL-Port beschreibt die Schnittstellen (zulässige Operationen), die durch den Webdienst exponiert werden. Das Element <portType> kann mit einer Funktionsbibliothek (oder einem Modul oder einer Klasse) in einer traditionellen Programmiersprache verglichen werden. Das Element <message> definiert die Datenelemente der Operation sowie den Namen, der mit jeder der Nachrichten assoziiert ist, für die Interaktion mit der Operation. Jede Nachricht kann aus einem oder mehreren Bestandteilen bestehen. Die Teile können mit den Parametern einer Funktion in einer traditionellen Programmiersprache verglichen werden, so dass die Funktion Teil des Webdienstes selbst ist. Das Element <types> definiert die Datentypen, durch den Webdienst verwendet werden. Um eine möglichst maximale Plattformneutralität zu erreichen, verwendet WSDL die XML-Schemasyntax zum Definieren von Datentypen. Das Element <binding> definiert das Nachrichtenformat sowie Kommunikationsprotokolldetails für jede Operation, so dass das Nachrichtenformat und das Kommunikationsprotokoll dem vom Webdienst erwarteten Format und Protokoll entsprechen.
  • Der Operationstyp Anforderung-Antwort ist der üblichste Operationstyp, aber WSDL definiert vier Operationstypen, wie z. B. unter anderem: One-way (Einweg), wobei die Operation eine Nachricht empfangen kann aber keine Antwort zurückgeben wird; Request-response (Anforderung-Antwort), wobei die Operation eine Anforderung empfangen kann und eine Antwort zurückgeben wird; Solicit-response (Abruf-Antwort), wobei die Operation eine Anforderung senden kann und auf eine Antwort warten wird; und Notification (Benachrichtigung), wobei die Operation eine Nachricht senden kann aber nicht auf eine Antwort warten wird.
  • WSDL-bindings definiert das Nachrichtenformat und die Protokolldetails für den Webdienst. Das binding-Element verfügt über zwei Attribute – das name-Attribut und das type-Attribut. Das name-Attribut (bei dem jeder beliebige Name verwendet werden kann) definiert den Namen der Bindung (binding), und das type-Attribut verweist auf den Port für die Bindung, in diesem Fall den Port "glossaryTerms". Das soap:binding-Element verfügt über zwei Attribute – das style-Attribut und das transport-Attribut. Das style-Attribut kann "rpc" oder "document" sein. In diesem Fall verwenden wir "document". Das transport-Attribut definiert das zu verwendende SOAP-Protokoll. In diesem Fall verwenden wir " HTTP". Das operation-Element definiert jede Operation, die der Port exponiert. Für jede Operation muss die entsprechende SOAP-Aktion definiert werden. Sie müssen auch spezifizieren, wie die Eingabe und Ausgabe codiert werden. In diesem Fall verwenden wir "literal". Es wird verständlich sein, dass auf Wunsch auch andere Protokolle als SOAP verwendet werden können.
  • WSDL-Beispiel
  • Das Folgende ist ein vereinfachter Ausschnitt eines exemplarischen WSDL-Dokuments.
  • Figure 00100001
  • Figure 00110001
  • Im obigen Beispiel definiert das portType-Element "glossaryTerms" als den Namen des Ports und "getTerm" als den Namen der entsprechenden Operation. Die "getTerm"-Operation hat eine Eingangsmeldung mit der Bezeichnung "getTermRequest" und eine Ausgangsmeldung mit der Bezeichnung "getTermResponse". Die message-Elemente definieren die Teile von jeder Nachricht und die zugehörigen Datentypen. Im Vergleich zur traditionellen Programmierung kann glossaryTerms eine Funktionsbibliothek sein und kann "getTerm" eine Funktion mit "getTermRequest" als Eingangsparameter und getTermResponse als Rückgabeparameter sein.
  • Benutzeroberfläche oder Tool 116 zur Anwendungsentwicklung
  • Unter Bezug auf 1 können die Anwendungen 105 im Repository 114 als eine Reihe von Paketen gespeichert werden, die durch ein Studio-Entwicklertool 116 erstellt werden können, welches durch die Entwickler der Anwendungen 105 eingesetzt wird. Das Entwicklerentwurfstool 116 kann ein RAD-Tool sein, das sowohl zur Entwicklung der Pakete der Drahtlosanwendung 105 als auch zur Entwicklung eines Zuordnungs- bzw. Erfassungsmodells 300 (siehe 3) verwendet wird, welches Erfassungsinformationen zwischen den Nachrichtenelementen der Anwendung(en) 105 und verschiedener Nachrichten- und Datenstrukturen der Datenquellen 106 definiert, wie das weiter unten beschrieben wird. Das Tool 116 kann einen grafischen Drag-and-Drop-Ansatz für das visuelle Entwerfen der Anwendung 105 einschließlich des Erfassungsmodells unterstützen. Beispielsweise können in einem komponentenbasierten XML-Skript-Anwendungsmodell die Pakete der Anwendung 105 als Metadaten (XML) repräsentiert werden, die vom Tool 116 über einen automatischen Code-Generierungsprozess automatisch erzeugt werden können. Das Tool 116 kann dafür sorgen, dass der automatisch erzeugte Code eine branchenüblichen Standardskriptsprache (z. B. JavaScript) oder andere nach dem Stand der Technik bekannte Skript/Programmiersprachen einschließt oder durch diese anderweitig erweitert wird. Die Verfügbarkeit der Pakete der Anwendung 105 im Repository 114 wird über einen Discovery-Dienst des Servers 110 in der Registrierung 112 veröffentlicht. Es wird anerkannt, dass es mehr als ein Repository 114 und zugehörige Registrierungen 112 geben kann, die durch die Konfiguration des konkreten Netzwerks 10 des Anwendungs-Gateways AG und der zugehörigen Datenquellen 106 verwendet werden.
  • Unter Bezug auf 2 wird das Tool 116 auf einem Computer 201 ausgeführt, der mit einem Netzwerk 10 verbunden sein kann, und zwar über eine Netzwerkverbindungsschnittstelle wie z. B. eine Sende-Empfangseinrichtung 200, die über die Verbindung 218 mit einer Geräteinfrastruktur 204 gekoppelt ist. Die Sende-Empfangseinrichtung 200 kann verwendet werden, um sowohl die fertigen Anwendungsprogramme 105 in das Repository 114 hochzuladen (siehe 1) als auch auf die Registrierung 112 und auf ausgewählte Datenquellen 106 zuzugreifen. Wiederum unter Bezug auf 2 hat das Entwicklerentwurfstool 116 außerdem eine Benutzeroberfläche 202, die über die Verbindung 222 mit der Geräteinfrastruktur 204 gekoppelt ist, um mit einem Benutzer (nicht dargestellt) zu interagieren. Die Benutzeroberfläche 202 enthält ein oder mehrere Benutzereingabegeräte, wie unter anderem eine Tastatur, ein Tastenfeld, ein Einstellrad (ein so genanntes Trackwheel), einen Stift, eine Maus, ein Mikrofon, und ist mit einem Benutzerausgabegerät wie z. B. einem Lautsprecher (nicht dargestellt) und einem Bildschirm-Display 206 gekoppelt. Wenn das Display 206 berührungsempfindlich ist, dann kann das Display 206 auch als das durch die Geräteinfrastruktur 204 gesteuerte Benutzereingabegerät verwendet werden. Die Benutzeroberfläche 202 wird durch den Benutzer des Tools 116 eingesetzt, um das Entwerfen der Anwendungen 105 und/oder des Erfassungsmodells 300 (siehe 300) mithilfe einer Reihe Editoren 600 und Viewern 602 (siehe 6) und mithilfe einer Mehrzahl von Assistenten 604 zur Unterstützung/Steuerung des Workflows des Entwicklungsprozesses zu koordinieren. Das Erfassungsmodell 300 kann als eine Beschreibung definiert sein, welche die Datenstrukturen 308 der Nachrichten 302 des Webdienstes 106 den vereinfachten Nachrichten 304 der Datenstrukturen 306 zuzuordnen, die auf dem Gerät 100 verwendet werden. Das Gateway AG würde dieses Erfassungsmodell 300 verwenden, um Nachrichtendaten an das und vom Gerät 100 entsprechend über die Nachrichten 302, 304 umzusetzen, d. h. mithilfe der Erfassungsinformationen 300, um die vereinfachte Gerätenachricht 304 in das und aus dem Format der komplexen Nachricht 302 der Webdienste 106 umzuformatieren.
  • Wiederum unter Bezug auf 2 wird die Operation des Toolcomputers 201 durch die Geräteinfrastruktur 204 ermöglicht. Die Geräteinfrastruktur 204 schließt einen Computerprozessor 208 und das zugehörige Speichermodul 210 ein. Der Computerprozessor 208 manipuliert die Operation der Netzwerkschnittstelle 200, der Benutzeroberfläche 202 und des Displays 206 des Tools 116 durch Ausführung verwandter Anweisungen, die durch ein Betriebssystem und die Anwendung 105 und/oder durch im Speichermodul 210 residente Entwurfseditoren 600 für das Erfassungsmodell 300, Assistenten 604, Dialoge 605 und Viewer 602 bereitgestellt werden. Außerdem wird anerkannt, dass die Geräteinfrastruktur 204 ein computerlesbares Speichermedium 212 einschließen kann, das mit dem Prozessor 208 gekoppelt ist, um dem Prozessor 208 Anweisungen bereitzustellen und/oder um die Anwendungen 105 zu laden/entwerfen, die ebenfalls (beispielsweise) im Speichermodul 210 resident sind. Das computerlesbare Medium 212 kann Hardware und/oder Software einschließen, wie unter anderem Magnetplatten, Magnetbänder, optisch lesbare Medien wie CD/DVD-ROMs und Speicherkarten. In jedem Fall kann das computerlesbare Medium 212 die Form einer kleinen Platte, einer Floppy-Diskette, einer Kassette, eines Festplattenlaufwerks, einer Festkörperspeicherkarte, oder die Form von im Speichermodul 210 bereitgestelltem RAM annehmen. Es sollte erwähnt werden, dass die oben aufgeführten exemplarischen computerlesbaren Medien 212 entweder allein oder in Kombination verwendet werden können.
  • Wiederum unter Bezug auf 2 wird das Entwurfstool 116 auf dem Computer 201 als eine Entwicklungsumgebung zur Entwicklung der Anwendungen 105 und/oder des Erfassungsmodells 300 eingesetzt. Die Entwicklungsmethodik des Tools 116 kann auf einem visuellen "Drag-and-Drop"-System zum visuellen Aufbauen der Anwendung, der Daten, des Messaging-Verhaltens und des Laufzeitnavigationsmodells basieren. Das Tool 116 kann als ein Set von Plugins für ein generisches IDE-Framework (Integrated Design Environment) strukturiert sein, beispielsweise unter anderem für das Eclipse-Framework, oder das Tool 116 kann als ein komplettes Design-Framework ohne Verwendung einer Plugin-Architektur konfiguriert sein. Lediglich für exemplarische Zwecke wird nun das Tool 116 als eine Plugin-Design-Umgebung unter Verwendung des Eclipse-Frameworks beschrieben.
  • Unter Bezug auf die 2 und 6 stellt Eclipse eine generische Basisumgebung für das Tool 116 zur Verfügung, die erweitert werden kann, um angepasste Editoren, Assistenten, Projektmanagement und eine Vielzahl anderer Funktionen bereitzustellen. Die Eclipse-Plattform wurde zur Aufbau von IDEs (Integrated Development Environments) gestaltet, die zur Erstellung solcher verschiedenen Anwendungen verwendet werden können wie Websites, eingebettete JavaTM-Programme, C++-Programme und Enterprise JavaBeansTM. Die Navigatoransicht 230 zeigt die Dateien im Arbeitsbereich eines Benutzers (z. B. eines Entwicklers); ein Texteditorbereich 232 zeigt den Inhalt einer Datei an, die durch den Benutzer des Tools 116 bearbeitet wird, um die jeweilige Anwendung 105 und/oder das jeweilige Modell 300 zu entwickeln; der Aufgabenansichtsbereich 234 zeigt eine Liste von durch den Benutzer des Tools 116 zu erledigenden Aufgaben; und der Übersichtsanzeigebereich 236 zeigt beispielsweise eine inhaltliche Übersicht der gerade entworfenen/editierten Anwendung 105 und/oder des Modells 300 an und/oder kann weitere Ansichten erweitern, indem in einer anderen Ansicht Informationen über das aktuell ausgewählte Objekt bereitgestellt werden wie z. B. die Eigenschaften des ausgewählten Objekts. Es wird anerkannt, dass das Tool 116 den Entwickler beim Erstellen und Modifizieren des codierten Definitionsinhalts der Anwendung 105 und/oder des Modells 300 unterstützt, beispielsweise in einer strukturierten Definitionssprache (z. B. XML). Außerdem unterstützt das Tool 116 den Entwickler beim Erstellen, Modifizieren und Prüfen der wechselseitigen Abhängigkeiten des Definitionsinhalts zwischen den Anwendungsnachrichten/Daten- und/oder Bildschirm/Daten-Beziehungen, die in der Definition der Anwendung 105 und im Erfassungsmodell 300 enthalten sind. Es wird auch anerkannt, dass die Präsentation des Inhalts von Assistenten 604 und Dialogen 605 zur Verwendung durch den Entwickler (während der Verwendung der Editoren 600 und Viewer 602) auf Wunsch in einem der Bereiche 230, 232, 234, 236 und/oder in einem eigenen Assistentenbereich (nicht dargestellt) positioniert sein kann.
  • Die Eclipse-Plattform basiert auf einem Mechanismus zur Aufspürung, Integrierung und Ausführung von Modulen, die als Plugins bezeichnet werden (d. h. Editoren 600 und Viewer 602). Wenn die Eclipse-Plattform über die Benutzeroberfläche 202 des Computers 201 gestartet wird, dann wird dem Benutzer auf dem Display 206 eine IDE (Integrated Development Environment) präsentiert, die aus dem Set der verfügbaren Plugins besteht, z. B. aus den Editoren 600 und den Viewern 602. Die verschiedenen Plugins für die Eclipse-Plattform arbeiten an regulären Dateien im Arbeitsbereich des Benutzers, der auf dem Display 206 angezeigt wird. Der Arbeitsbereich besteht aus einem oder mehreren Projekten auf oberster Ebene, wobei jedes Projekt einem entsprechenden, vom Benutzer festgelegten Verzeichnis in dem Dateisystem zugeordnet ist, das im Speicher 210 gespeichert ist (und/oder über das Netzwerk 10 verfügbar ist), und in dem die Navigation mithilfe des Navigators 230 erfolgt. Das Benutzeroberflächenparadigma der Eclipse-Plattform basiert auf Editoren, Ansichten und Perspektiven. Aus Sicht des Benutzers besteht ein Arbeitsplatz-Display 206 visuell aus Ansichten 602 und Editoren 600. Perspektiven manifestieren sich selbst in der Auswahl und in den Anordnungen der auf dem Display 206 sichtbaren Editoren 600 und Ansichten 602. Die Editoren 600 ermöglichen dem Benutzer das Öffnen, Bearbeiten und Speichern von Objekten. Die Editoren 600 folgen einem Öffnen-Speichern-Schließen-Lebenszykius, ähnlich den auf einem Dateisystem basierenden Tools. Wenn ein ausgewählter Editor 600 aktiv ist, kann er Aktionen für ein Arbeitsplatzmenü und eine Werkzeugleiste beisteuern. Die Ansichten 602 bieten Informationen über ein Objekt, an dem der Benutzer am Arbeitsplatz gerade arbeitet. Ein Viewer 602 kann den Editor 600 unterstützen, indem er Informationen über das gerade bearbeitete Dokument bereitstellt. Die Viewer 602 können beispielsweise einen einfacheren Lebenszyklus als die Editoren 600 haben, wodurch unter Verwendung eines Viewers 602 vorgenommene Modifikationen (wie z. B. die Änderung eines Eigenschaftswerts) im Allgemeinen sofort gespeichert werden und die Änderungen sofort in anderen verwandten Teilen des Displays 206 widerspiegelt werden. Es wird auch anerkannt, dass ein Arbeitsplatzfenster des Displays 206 verschiedene separate Perspektiven haben kann, von denen immer nur jeweils eine sichtbar ist. Jede Perspektive hat ihre eigenen Viewer 602 und Editoren 600, die für die Präsentation auf dem Display 206 angeordnet sind (gekachelt, gestapelt oder getrennt).
  • Anwendungen 105
  • Beispielsweise können die Anwendungen 105 kompilierte Anwendungen für die Übertragung zum und zur anschließenden Ausführung auf dem Gerät 100 sein, oder sie können Pakete sein, die über Anwendungselemente oder -artefakte verfügen, wie unter anderem XML-Definitionen, Zuordnungen (Bestandteil des Erfassungsmodells 300), Anwendungsressourcen und optional ein oder mehrere Ressourcenbündel für die Lokalisierungsunterstützung. XML-Dateidefinitionen können XML-Codierung von Anwendungsdaten, Nachrichten, Bildschirmkomponenten (optional Workflow-Komponenten) sein, die Bestandteil einer unkompilierten Anwendung 105 in Rohform sind. Es wird anerkannt, dass die XML-Syntax nur als ein Beispiel für jede strukturierte Definitionssprache verwendet wird, die auf die Codierung der Anwendungen 105 anwendbar ist. Die XML-Definitionen können je nach Wunsch entweder durch die Generierungsphase des Tools 116 produziert worden sein, wie das unten beschrieben wird, oder sie können von Hand durch den Entwickler codiert worden sein. Die Anwendungs-XML-Definitionen können generisch benannt und zur obersten Ebene (beispielsweise) einer JAR-Datei hinzugefügt werden.
  • Bei den Ressourcen handelt es sich um eine oder mehrere Ressourcen (Bilder, Soundbytes, Mediadaten usw.), die mit der Anwendung 105 als statische Abhängigkeiten gepackt sind. Beispielsweise können Ressourcen relativ zu einem resources-Ordner (nicht dargestellt) lokalisiert sein, so dass eine bestimmte Ressource ihren eigenen relativen Pfad zu dem Hauptordner enthalten kann (z. B. resources/icon.gif, resources/screens/clipart_1.0/happyface.gif und resources/soundbytes/midi/inthemood.midi). Die Ressourcenbündel können Lokalisierungsinformationen für jede Sprache enthalten, die durch die Anwendung 105 unterstützt wird. Diese Bündel können sich beispielsweise in einem locale-Ordner befinden, und sie können entsprechend der unterstützten Sprache benannt sein (z. B. locale/lang_en.properties und locale/lang_fr.properties).
  • Beispielsweise kann die Laufzeitumgebung RE des Geräts 100 der beim Client residente Container sein, in dem die Anwendungen 105 im Gerät 100 ausgeführt werden. Der Container kann den Lebenszyklus der Anwendung 105 auf dem Gerät 100 (Bereitstellung, Ausführung, Löschung usw.) verwalten und ist dafür verantwortlich, die Metadaten (XML), welche die Anwendung 105 repräsentieren (im Fall von XML-Rohdefinitionen), in eine effiziente ausführbare Form auf dem Gerät 100 zu übersetzen. Die Metadaten der Anwendung 105 sind die ausführbare Form der XML-Definitionen, wie das oben beschrieben wurde, und können durch die Laufzeitumgebung RE erzeugt und gepflegt werden. Die RE kann der Anwendung 105 auch ein Set gemeinsam verwendeter Dienste zur Verfügung stellen und Unter stützung für optionales JavaScript oder andere Skriptsprachen bieten. Zu diesen Diensten zählen die Unterstützung für unter anderem die Steuerung der Benutzeroberfläche, Datenpersistenz und asynchrones Client-Server-Messaging. Es wird anerkannt, dass diese Dienste auf Wunsch auch als Bestandteil in die Anwendung 105 einbezogen werden können.
  • Unter Bezug auf 7 und lediglich als ein exemplarisches Beispiel zu verstehen, kann es sich bei den Anwendungen 105 um auf einer Komponentenarchitektur basierende Software-Anwendungen handeln, die Artefakte haben können, welche beispielsweise in eXtensible Markup Language (XML) und einer Teilmenge von ECMAScript geschrieben sind. XML und ECMAScript sind standardbasierte Sprachen, die es Software-Entwicklern ermöglichen, die Komponentenanwendungen 105 in einer portablen und plattformunabhängigen Weise zu entwickeln. Ein Blockdiagramm der Komponentenanwendung 105 umfasst die Datenkomponenten 400, die Präsentationskomponenten 402 und die Nachrichtenkomponenten 404, welche durch die Workflow-Komponenten 406 durch Interaktion mit der Client-Laufzeitumgebung RE des Geräts 100 koordiniert werden (siehe 1), sobald sie auf diesem bereitgestellt wurden. Die strukturierte Definitionssprache (z. B. XML) kann zum Aufbau der Komponenten 400, 402, 404 als eine Serie von Metadatendatensätzen verwendet werden, die aus einer Anzahl vordefinierter Elemente bestehen, welche spezifische Attribute einer Ressource repräsentieren, so dass jedes Element einen oder mehre Werte haben kann. Jedes Metadatenschema hat typischerweise definierte charakteristische Merkmale, wie unter anderem: eine begrenzte Anzahl von Elementen, einen Namen für jedes Element und eine Bedeutung für jedes Element. Zu exemplarischen Metadatenschemas gehören unter anderem Dublin Core (DC), Anglo-American Cataloging Rules (AACR2), Government Information Locator Service (GILS), Encoded Archives Description (BAD), IMS Global Learning Consortium (IMS) und Australian Government Locator Service (AGLS). Die Codierungssyntax ermöglicht es, die Metadaten der Komponenten 400, 402, 404 durch die Laufzeitumgebung RE zu verarbeiten (siehe 1), und die Codierungsschemas enthalten Schemas wie unter anderem XML, HTML, XHTML, XSML, RDF, Machine Readable Cataloging (MARC) und Multipurpose Internet Mail Extensions (MIME). Die Client-Laufzeitumgebung RE des Geräts 100 operiert an den Metadatendeskriptoren der Komponenten 400, 402, 404, um eine ausführbare Version der Anwendung 105 bereitzustellen.
  • Wiederum unter Bezug auf 4 definieren die Datenkomponenten 400 Datenentitäten, die durch die Anwendung 105 verwendet werden. Die Datenkomponenten 400 definieren, welche Informationen erforderlich sind, um die Datenentitäten zu beschreiben, und in welchem Format die Informationen ausgedrückt werden. Beispielsweise kann die Datenkomponente 400 unter anderem solche Informationen definieren wie einen Auftrag, der aus einem eindeutigen Identifikator für den Auftrag besteht, welcher als eine Zahl formatiert ist, eine Liste von Elementen, welche als Zeichenfolgen formatiert sind, den Zeitpunkt, zu dem der Auftrag erstellt wurde, welcher ein Datum-Uhrzeit-Format hat, den Status des Auftrags, welcher als eine Zeichenfolge formatiert ist, und einen Benutzer, der den Auftrag erteilt hat, welcher gemäß der Definition einer anderen der Datenkomponenten 400 formatiert ist.
  • Wiederum unter Bezug auf 4 definieren die Nachrichtenkomponenten 404 das Format der Nachrichten, die durch die Komponentenanwendung 105 verwendet werden, um mit externen Systemen wie dem Webdienst zu kommunizieren. Beispielsweise kann eine der Nachrichtenkomponenten 404 Informationen beschreiben wie unter anderem eine Nachricht zur Erteilung eines Auftrags, welche den eindeutigen Identifikator für den Auftrag, den Status des Auftrags und dem Auftrag zugeordnete Notizen enthält. Es wird anerkannt, dass Datendefinitionsinhalt der Komponenten gemeinsam für Daten- 400 und Nachrichtenkomponenten 404 verwendet werden kann, die miteinander verlinkt sind oder in anderer Weise gleiche Datendefinitionen enthalten. Die Nachrichtenkomponente 404 ermöglicht es, den Nachrichteninhalt auszuwerten, um zu ermitteln, ob die erforderlichen Felder in der Nachricht 304 geliefert wurden (siehe 3), und ihn über das AG zur Datenquelle 106 zu senden.
  • Wiederum unter Bezug auf 4 definieren die Präsentationskomponenten 402 das Erscheinungsbild und das Verhalten der Komponentenanwendung 105, wie dieses durch eine Benutzeroberfläche der Geräte 100 angezeigt wird. Die Präsentationskomponenten 402 können GUI-Bildschirme und -steuereinrichtungen festlegen sowie Aktionen, die ausgeführt werden müssen, wenn der Benutzer unter Verwendung der Benutzeroberfläche mit der Komponentenanwendung 105 interagiert. Beispielsweise können die Präsentationskomponenten 402 Bildschirme, Beschriftungen, Bearbeitungsfelder, Schaltflächen und Menüs definieren sowie Aktionen, die durchgeführt werden müssen, wenn der Benutzer eine Eingabe in ein Bearbeitungsfeld vornimmt oder eine Schaltfläche drückt. Es wird anerkannt, dass Datendefinitionsinhalt der Komponenten gemeinsam für Daten- 400 und Präsentationskomponenten 402 verwendet werden kann, die miteinander verlinkt sind oder in anderer Weise gleiche Datendefinitionen enthalten.
  • Unter Bezug auf die 1 and 4 wird anerkannt, dass beim oben beschriebenen Definitions-Hosting-Modell für die Client-Komponentenanwendung 105 die Präsentationskomponenten 402 in Abhängigkeit von der Client-Plattform und der Umgebung des Geräts 100 abweichend sein können. Beispielsweise benötigen Kunden von Webdiensten in einigen Fällen keine visuelle Präsentation. Die Anwendungsdefinition der Komponenten 400, 402, 404, 406 der Komponentenanwendung 105 kann in dem Webdienst-Repository 114 als ein Paketbündel plattformneutraler Deskriptoren der Daten- 400, Nachrichten- 404 und Workflow-Komponenten 406 gehostet sein, mit einem Set von plattformspezifischen Deskriptoren der Präsentationskomponente 402 für verschiedene vordefinierte Client-Laufzeitumgebungen RE. Wenn die Discovery- oder Deployment-Anforderungsnachricht für die Anwendung 105 ausgegeben wird, würde als ein Bestandteil dieser Anforderungsnachricht der Client-Typ spezifiziert werden. Um eine Duplizierung von Daten-, Nachrichten- und Workflow-Metadaten beim Packen der Komponentenanwendung 105 für unterschiedliche Client-Plattformen der Kommunikationsgeräte 100 zu vermeiden, können Anwendungsdefinitionen als ein Bündel plattformneutraler Komponentendefinitionen gehostet werden, die mit unterschiedlichen Sets von Präsentationskomponenten 402 verlinkt sind. Für solche Webdienst-Kunden würde die Client-Anwendung 105 ausgewählte Präsentationskomponenten 402 enthalten, die über die Workflow-Komponenten 406 mit den Daten- 400 und Nachrichtenkomponenten 404 verlinkt sind.
  • Wiederum unter Bezug auf 4 definieren die Workflow-Komponenten 406 der Komponentenanwendung 105 die Verarbeitung, welche erfolgt, wenn eine Aktion ausgeführt werden muss, beispielsweise eine durch eine Präsentationskomponente 402 spezifizierte Aktion wie oben beschrieben oder eine Aktion, die ausgeführt werden muss, wenn Nachrichten vom Anwendungs-Gateway AG ankommen (siehe 1). Die Präsentations-, Workflow- und Nachrichtenverarbeitung wird durch die Workflow-Komponenten 406 definiert. Die Workflow- Komponenten 406 sind als eine Serie von Anweisungen in einer Programmiersprache geschrieben (z. B. in einer objektorientierten Programmiersprache) und/oder in einer Skriptsprache, wie unter anderem ECMAScript, und kann (beispielsweise) in nativen Code kompiliert und durch die Laufzeitumgebung 206 ausgeführt werden, wie das oben beschrieben wurde. Ein Beispiel der Workflow-Komponenten 406 kann die Zuweisung von Werten zu Daten, die Manipulation von Bildschirmen oder das Senden der Nachricht 105 sein. Wie bei Präsentationskomponenten können mehrere Workflow-Definitionen erstellt werden, um die Fähigkeiten und Features zu unterstützen, die bei verschiedenen Geräten 100 unterschiedlich sind. ECMA (European Computer Manufacturers Association) Script ist eine Standardskriptsprache, wobei Skripts als eine Sequenz von Anweisungen bezeichnet werden können, die nicht durch den Computerprozessor, sondern durch ein anderes Programm interpretiert oder ausgeführt wird. Einige andere Beispiele für Skriptsprachen sind Perl, Rexx, VBScript, JavaScript und Tcl/Tk. Die Scriptsprachen sind ganz allgemein Anweisungssprachen, die zum Manipulieren, Anpassen und Automatisieren der Einrichtungen eines existierenden Systems verwendet werden, beispielsweise der Geräte 100.
  • Unter Bezug auf 4 ist die Anwendung 105 beispielsweise mithilfe der Komponentenarchitektur strukturiert, so dass beim Empfang einer Nachrichtendaten enthaltenden Antwortnachricht vom Anwendungs-Gateway AG durch das Gerät 100 (siehe 1) die jeweilige Workflow-Komponente 406 den Dateninhalt der Nachricht entsprechend den jeweiligen Komponentendefinitionen 404 interpretiert. Die Workflow-Komponente 406 verarbeitet dann den Dateninhalt und fügt die Daten in die jeweilige Datenkomponente 400 zur nachfolgenden Speicherung in dem Gerät 100 ein. Außerdem fügt die Workflow-Komponente 406 falls erforderlich auch die Daten in die jeweilige Präsentationskomponente 402 zur nachfolgenden Anzeige auf dem Display des Geräts 100 ein. Ein weiteres Beispiel für die Komponentenarchitektur der Anwendungen 105 ist die Dateneingabe durch einen Benutzer des Geräts 100, beispielsweise durch Drücken einer Schaltfläche oder Auswählen eines Menüelements. Die relevanten Workflow-Komponente 406 interpretiert die Eingabedaten entsprechend der jeweiligen Präsentationskomponente 404 und erstellt Datenentitäten, die durch die jeweiligen Datenkomponenten 400 definiert sind. Die Workflow-Komponente 406 bestückt dann die Datenkomponenten 400 mit den durch den Benutzer bereitgestellten Eingabedaten zur nachfolgenden Speicherung in dem Gerät 100. Ferner fügt die Workflow-Komponente 406 die Eingabedaten auch in die jeweilige Nachrichtenkomponente 404 ein, um die Eingabedaten anschließend als Datenentitäten zur Datenquelle 106 zu senden, beispielsweise zu einem Webdienst, wie das durch die Nachrichtenkomponente 404 definiert ist.
  • Es wird anerkannt, dass der obige exemplarische Inhalt einer komponentenbasierten Anwendung 105 auch auf eine traditionellere integrierte Anwendung angewendet werden könnte, bei der die verschiedenen Daten-, Nachrichten-, Workflow- und Bildschirmcodierungen (welche die Funktionalität der Anwendung 105 repräsentieren) nicht als diskrete interaktive Komponenten strukturiert sind, sondern als ein integriertes Programm. Jedoch wäre unabhängig von der Form der Anwendung 105 die Verwendung des Erfassungsmodells 300 durch das Anwendungs-Gateway AG gleich, sobald das Modell 300 durch das Tool 116 erstellt und für das Anwendungs-Gateway AG verfügbar gemacht wird.
  • Eine exemplarische Komponentenanwendung 105, repräsentiert in XML und mEScript, könnte folgendermaßen aussehen und die Datenkomponenten 400 als "wcData" und die Nachrichtenkomponenten 404 als "wcMsg" enthalten:
    Figure 00210001
    Figure 00220001
  • Wie oben gezeigt, definiert das XML-Element wcData den exemplarischen Inhalt der Datenkomponente 400, der aus einer Gruppe von benannten und typisierten Feldern gebildet wird. Der Inhalt des wcMsg-Elements definiert die exemplarische Nachrichtenkomponente 404, die in gleicher Weise eine Gruppe benannter, typisierter Felder definiert.
  • Architektur des Entwicklertools 116
  • 6 zeigt die Gesamtstruktur des Entwurfstools 116 zum Entwerfen von Anwendungen 105 und/oder des zugehörigen Erfassungsmodells 300. Die Benutzerschnittstelle (Benutzeroberfläche UI 202 und Display 206 – siehe 2) des Entwurfstools 116 ist in erster Linie eine zum Benutzer gerichtete Sammlung von Modulen 601 aus grafischen und Texteditoren 600, Viewern 602, Dialogen 605 und Assistenten 604. Die große Mehrzahl der externen Interaktionen werden durch einen oder mehrere dieser Editoren 600 bewerkstelligt, wobei der Entwickler/Benutzer ein System zum Bearbeiten per "Drag-and-Drop" und zur assistentengestützten Ausarbeitung verwendet. Die zweite und nicht zum Benutzer gerichtete System schnittstelle ist die des "Backends", mit der sich das Tool 116 mit Diensten der Datenquelle 106 wie Webdiensten und SQL-Datenbanken verbindet und diese verarbeitet. Wie oben beschrieben wurde, kann das Tool 116 auf der Eclipse-Plattform aufgebaut sein, wodurch die Benutzerschnittstellensystemkomponenten unter anderem den Komponenten Editoren 600, Viewern 602, Dialogen (nicht dargestellt) und Assistenten 604 entsprechen können, welches Plugin-Module 601 sind, die beispielsweise Eclipse-Klassen erweitern und das Eclipse-Framework nutzen. Wie gezeigt wird, kommuniziert das Tool 116 mit den Backend-Datenquellen 106 und den UDDI-Repositories 114 und Registrierungen 112. Diese externen Systeme 106, 112, 114 sind zwar möglicherweise nicht Bestandteil des Werkzeugs 116, werden aber der Vollständigkeit halber gezeigt.
  • UI-Schicht 606
  • Das Tool 116 verfügt über eine UI-Schicht 606, die hauptsächlich aus den Editoren 600 und Viewern 602 besteht, welche durch die Workflow-Assistenten 605 unterstützt werden. Die Schicht 606 hat Zugriff auf eine umfangreiche Widget-Set- und Grafikbibliothek, die bei Eclipse als das Standard Widget Toolkit (SWT) bekannt ist. Die Module 601 der UI-Schicht 606 können auch ein als JFace bezeichnetes, auf höherer Ebene angesiedeltes Toolkit nutzen, das Standard-Viewer-Klassen wie Listen, Bäume und Tabellen enthält, sowie ein Aktions-Framework, das zum Hinzufügen von Befehlen zu Menüs und Werkzeugleisten verwendet wird. Das Tool kann auch ein Graphical Editing Framework (GEF) verwenden, um Diagrammeditoren zu implementieren. Die Module 601 der UI-Schicht 606 können dem Model-View-Controller-Entwurfsmuster folgen, wobei jedes Modul 601 sowohl eine Ansicht (View) als auch ein Controller ist. Die Datenmodelle 608, 610 repräsentieren den Dauerstatus der Anwendung 105 und sind in der Datenmodellschicht 612 der Architektur des Tools 116 implementiert. Die Trennung der Schichten 606, 612 hält präsentationsspezifische Informationen in den verschiedenen Ansichten und ermöglicht es, dass mehrere UI-Module 601 (z. B. Editoren 600 und Viewer 602) auf Änderungen im Datenmodell 608, 610 reagieren können. Die Bedienung der Editoren 600 und Viewer 602 durch den Entwickler auf dem Display 202 (siehe 2) kann durch die Assistenten 604 unterstützt werden, welche die Entwicklung der Anwendung 105 und/oder des Erfassungsmodells 300 begleiten.
  • Unter Bezug auf 6 wird die UI-Schicht 606 durch ein Set von Editoren 600, Viewern 602, Assistenten 604 und Dialogen 605 gebildet. Die UI-Schicht 606 verwendet ein MVC-Muster (Model-View-Controller), wobei jedes UI-Modul 601 sowohl eine Ansicht (View) als auch ein Controller ist. Die UI-Schicht-Module 601 interagieren mit den Datenmodellen 608, 610 und dem Erfassungsmodell mit einer verwandten Steuerlogik, wie sie durch das MVC-Muster definiert ist. Die Editoren 600 sind Module 601, die Änderungen am Modell 608, 610, 300 erst dann übernehmen, wenn der Benutzer des Tools die Entscheidung trifft, diese zu "speichern". Die Viewer 602 sind Module 601, die ihre Änderungen an dem Modell 608, 612, 300 sofort übernehmen, wenn sie vom Benutzer durchgeführt werden. Die Assistenten 604 sind Module 601, die schrittweise durch eine Reihe von einem oder mehreren Dialogen 605 vorangebracht werden, wobei jeder Dialog 605 bestimmte Informationen vom Benutzer des Tools 116 über die Benutzeroberfläche 202 erfasst (siehe 2). Bei Verwendung der Assistenten 604 werden keine Änderungen auf das Entwurfszeitmodell 608 angewendet, bis der Benutzer des Tools 116 eine Bestätigungsschaltfläche wie z. B. "Beenden" wählt. Es wird in der exemplarischen Umgebung für das Plugin-Entwurfstool 116 anerkannt, dass die Module 601 zwei Typen von Schnittstellen erweitern können: Eclipse-Erweiterungspunkte (Extension Points) und Erweiterungspunktschnittstellen (Extension Point Interfaces). Erweiterungspunkte deklarieren ein bereits im System definiertes eindeutiges Paket oder Plugin als den Eingangspunkt für die Funktionserweiterung, z. b. einen Editor 600, einen Assistenten 604 oder ein Projekt. Erweiterungspunktschnittstellen ermöglichen dem Tool 116 das Definieren eigener Plugin-Schnittstellen, z. B. für Skin- 618 und Backend- 616 -Konnektoren, wie das weiter unten beschrieben wird.
  • Datenmodelle 608, 610 und Erfassungsmodell 300
  • Die Datenmodelle 608, 610 des Tools 116 und das Erfassungsmodell 300 basieren beispielsweise auf dem Eclipse Modeling Framework (EMF). Es wird anerkannt, dass je nach Wunsch auch andere Modellierungs-Frameworks verwendet werden können. Das Framework bietet Benachrichtigung bei Änderungen am Modell 608, 610, 300, Persistenzunterstützung und eine effiziente Reflektiv-API zum generischen Manipulieren von EMF-Objekten. Die Codeerzeugungseinrichtung wird zum Erzeugen der Implementierung des Modells 608, 610, 300 und zum Erstellen von Adaptern zur Verbindung einer Modellschicht 612 mit den Benutzeroberflächenmodulen 601 der UI-Schicht 606 verwendet.
  • Wiederum unter Bezug auf 6 sind die Module 601 (in erster Linie die Editoren 600 und Viewer 602) in dem Tool 116 Beobachter der Datenmodelle 608, 610 und des Erfassungsmodells 300 und werden verwendet, um mit den Datenmodellen 608, 610 und dem Erfassungsmodell 300 der Anwendung (z. B. mit den Komponenten 400, 402, 404, 406 – siehe 4) zu interagieren oder diese anderweitig zu testen und zu modifizieren. Wenn sich das Datenmodell 608, 610 und das Erfassungsmodell 300 ändern, werden die Modelle 608, 610 und das Erfassungsmodell benachrichtigt und antworten durch die Aktualisierung der Präsentation der Anwendung 105. Das Tool 116 verwendet beispielsweise das Eclipse Modeling Framework (EMF), um das Eclipse-UI-Framework mit dem Datenmodell 608, 610 des Tools 116 und dem Erfassungsmodell 300 zu verbinden, wodurch die Module die Standard-Eclipse-Schnittstellen verwenden können, um die anzuzeigenden Informationen bereitzustellen und ein Objekt auf dem Display 206 zu bearbeiten (siehe 2). Im Allgemeinen implementiert das EMF-Framework diese Standardschnittstellen und passt die Aufrufe an diese Schnittstellen an, indem generierte Adapter aufgerufen werden, die wissen, wie auf das Datenmodell 608, 610 und das Erfassungsmodell 300 zugegriffen wird, die im Speicher 210 resident sind. Das Entwurfszeit-Datenmodell 608 wird verwendet, um die aktuelle Version der in Entwicklung befindlichen Anwendung 105 (z. B. ein Anwendungsmodul) zu repräsentieren, und darauf wird durch die Benutzer zugegriffen, die die Module 601 einsetzen, um mit den assoziierten Daten des Modells 608 zu interagieren. Die Module 601 können auch Validierungsaktionen an dem Entwurfszeit-Datenmodell 608 triggern. Die Module 601 können auch bewirken, dass ein Teil oder die gesamte Anwendung 105 aus dem im Speicher 210 residenten Entwurfszeit-Datenmodell 608 generiert wird. Allgemein akzeptiert das Entwurfszeit-Datenmodell 608 ein Set aus Befehlen über die UI 202 (siehe 2), die sich auf den Status des Modells 608 auswirken, und kann als Antwort ein Set von Ereignissen generieren. Jedes beschriebene Modul 601 (Editor 600 und Viewer 602) schließt ein Set aus Befehlen und die Ereignisse ein, die sich auf die Paarung aus Modul 601 und Datenmodell 608 auswirken.
  • Unter Bezug auf die 6 und 8 repräsentiert das Laufzeit-Datenmodell 610 den Status einer emulierten Anwendung 105, die gerade durch das Tool 116 entwickelt wird, wobei als eine Basis der Inhalt des Entwurfszeit-Datenmodells 608 verwendet wird. Das Laufzeit-Datenmodell 610 speichert Werte für die folgenden wichtigen Elemente, wozu unter anderem gehören: Datenkomponenten 400 (siehe 4); Globalvariablen; Nachrichtenkomponenten 404; Ressourcen; Bildschirmkomponenten 402 und Stile. Das Laufzeit-Datenmodell 610 arbeitet beispielsweise während der Emulation der Anwendung 105 mit dem Entwurfszeit-Datenmodell 608 und einem Test/Vorschau-Viewer (nicht dargestellt) für Test- und Vorschauzwecke zusammen. Der Viewer arbeitet auch mit dem Skin-Manager 616 zusammen, um das Laufzeit-Datenmodell 610 für einen spezifizierten Typ des Geräts 100 zu emulieren. Das Laufzeit-Datenmodell 610 benachrichtigt über eine Brücke 613 auch den Viewer sowie alle anderen Module 601 der UI-Schicht 606, die mit den am Modell 610 vorgenommenen Änderungen assoziiert sind. Beispielsweise kann ein API-Aufruf als ein Benachrichtiger für die assoziierten Modelle 601 verwendet werden, wenn sich der Status des Modells 610 geändert hat. Das Entwurfszeit-Datenmodul 608 repräsentiert den Status eines Entwicklungsprojekts der Anwendung 105 und interagiert mit den Modulen 601 der UI-Schicht 606, indem die Module 601 benachrichtigt werden, wenn sich der Status des Modells 608 geändert hat, und durch Speichern und Laden der Objekte aus dem Speicher 210. Die primäre Verantwortung des Modells 608 besteht darin, die Anwendungen 105 zu definieren, einschließlich unter anderem der folgenden Elemente: Definitionen der Datenkomponenten 400; Definitionen der Globalvariablen; Definitionen der Nachrichtenkomponenten 404; Definitionen der Ressourcen 304, 306; Definitionen der Bildschirmkomponenten 402; Skripts 406; Definitionen der Stile und Deskriptoren der Erfassung 302 der Backend-Datenquelle 106. Das Entwurfszeit-Datenmodell 608 reagiert auf Befehle von jedem Editor 600 und Viewer 602. Das Entwurfszeit-Datenmodell 608 triggert auch Ereignisse an die Module 601 als Reaktion auf Änderungen in dem Modell 608 und übernimmt die Zusammenarbeit/Kommunikation mit den anderen Modulen 601 (Interaktion zwischen Modul 601 und Modul 601) durch Benachrichtigung der jeweiligen Module 601, wenn sich das Datenmodell 608 geändert hat. Das Datenmodell 608 hängt von einer Schnittstelle ab, um das Abrufen und das Speichern aus dem und in den Speicher 210 des Inhalts von Modell 608 zu serialisieren.
  • Das Obige beschreibt den Mechanismus, der durch die Editoren 600 und Viewer 602 des Tools 116 verwendet wird, um mit den Modellen 608, 610, 300 zu interagieren. Das EMF.Edit-Framework ist ein optionales Framework, das durch das Eclipse-Framework bereitgestellt wird. Das Tool 116 kann das EMF.Edit-Framework und den generierten Code (beispielsweise) als eine Brücke oder Kopplung 613 zwischen dem Eclipse-UI-Framework und den Toolmodellen 608, 610, 300 verwenden. Entsprechend dem Model-View-Controller-Muster haben die Editoren 600 und Viewer 602 keine direkte Kenntnis von den Modellen 608, 610, 300, sondern verlassen sich auf die Schnittstellen bei der Bereitstellung der Informationen, die zum Anzeigen und Bearbeiten benötigt werden.
  • Erfassungsmodell 300
  • Unter Bezug auf 3 definiert die Quellnachrichtenstruktur 302 die Beziehung des Inhalts im Anwendungs-Messaging zwischen dem Anwendungs-Gateway AG und dem Backend-Betrieb der Datenquellen 106. Die Gerätenachrichtenstruktur 304 definiert die Beziehung des Inhalts im Anwendungs-Messaging zwischen dem Gerät 100 und dem Anwendungs-Gateway AG. Das Erfassungsmodell 300 wird durch das Erfassungsmodul 629 aufgebaut, unter Verwendung der Kenntnis der Datenstrukturen des Backends 308 und der durch das Gerät 100 verwendeten Datenstrukturen 306 (wie z. B. im Entwurfsdatenmodell 608 repräsentiert), um eine Reihe von Zuordnungen oder "Cross-Mappings" 310 zwischen den zwei ungleichen Datenstrukturen 306, 308 zu implementieren, wie das im Folgenden detailliert beschrieben wird. Das Erfassungsmodul 629 hilft bei der Generierung der Erfassungsinformationen 310 auf der Basis einer definierten Anwendungs-/Gerätenachrichtenstruktur 304 (und der verwandten Datenstruktur 308) durch Abgleich mit der entsprechenden Datenquellennachrichtenstruktur 302 (und der verwandten Datenstruktur 306). Die Strukturen 304, 308 werden durch das Entwurfsmodell 608 bereitgestellt, d. h. durch das Modell der Anwendung 105. Der Anwendungsentwickler erstellt das Erfassungsmodell 300 unter Verwendung des Moduls 629 vom Tool 116, wodurch das Gateway AG die Informationen dieses Erfassungsmodells 300 verwendet, während die Anwendung 105 Anforderungs-/Antwortnachrichten zwischen der Laufzeitumgebung RE der Geräte 100 und den Datenquellen 106 kommuniziert. Das Erfassungsmodell 300 kann als eine Annotation für das Schema der Datenquelle 106 erzeugt werden, oder das Erfassungsmodell 300 kann stattdessen beispielsweise als eine separate Datei festgehalten werden. Beispielsweise ist die Beschreibung der Datenquelle 106 ein WSDL-Schema des Webdienstes 106. Außerdem kann es mehrere Erfassungsmodelle 300 in dem Fall geben, dass durch die Anwendung 105 mehrere Backend-Datenquellen 106 genutzt werden. Alle solchen Erfassungsmodelle 300 können zusammen in einem mappings-Ordner (nicht dargestellt) gruppiert werden und können entsprechend dem Dienstnamen der Datenquelle 106 benannt werden, z. B. mappings/WeatherService.wsdl und mappings/AirlineBookingSystem.wsdl.
  • Unter Bezug auf 4 ist ein Beispiel für eine Webdienststruktur 308 (z. B. Produkt 309) gegeben, das zwei zusätzliche Strukturen enthält, nämlich Abrechnungsoptionen 312 und Kategorie 314. Die Struktur 309 des Geräts Produkt, die über mehrere Datenabschnitte bzw. Datenschichten verfügt, ist verflacht, so dass nur einfache Felder (z. B. eine Datenschicht oder zumindest weniger als die Anzahl der Schichten in der Struktur 309) vorhanden sind, die zusätzlichen Abschnitte bzw. Schichten sind entfernt. Felder aus der Abrechnungsoptionen-Struktur 312 und der Kategorie-Struktur 314 sind als einfache Felder in der verflachten Produkt-Struktur 316 der vereinfachten Datenstruktur 306 präsent. Durch das Modell 300 werden Zuordnungen 310 verwendet, um die wechselseitigen Beziehungen zwischen den Datenstrukturen 306, 308 zu repräsentieren, wie sie in den jeweiligen Nachrichtenstrukturen 304, 302 implementiert sind.
  • Wie weiter unten detailliert beschrieben wird, können die Datenstrukturen 306, 308, welche den Dateninhalt der Nachrichtenstrukturen 302, 304 repräsentieren, beispielsweise unter anderem in einer Baumdarstellung repräsentiert werden. Die Datenstrukturen 306, 308 können als ein Spezialformat für das Organisieren und Speichern von Daten definiert sein. Zu den allgemeinen Datenstrukturtypen können ein Feld, eine Datei, ein Datensatz, eine Tabelle, der Baum usw. zählen. Jede Datenstruktur ist dafür ausgelegt, Daten für einen bestimmten Zweck zu organisieren, so dass sie in geeigneter Weise zugänglich sind und mit ihnen gearbeitet werden kann. Bei der Computerprogrammierung kann die Datenstruktur dafür ausgewählt oder gestaltet werden, Daten für den Zweck zu speichern, dass mit ihnen mit verschiedenen Algorithmen gearbeitet werden kann. Die Baumdatenstruktur 306, 308 wird verwendet, um Datensätze/Schlüssel im Modell 300 zu platzieren und zu lokalisieren. Die Baumdatenstruktur 306, 308 wird zum Suchen nach Daten der Struktur 306, 308 verwendet, indem wiederholt an Entscheidungspunkten, die als Knoten bezeichnet werden, Auswahlentscheidungen getroffen werden. Ein Knoten kann minimal zwei Zweige haben (die auch als Kinder bezeichnet werden) oder bis zu mehreren Dutzend. Die Struktur ist zwar geradlinig, aber im Hinblick auf die Anzahl der Knoten und Kinder kann ein Baum gigantische Ausmaße haben. In der Baumdatenstruktur 306, 308 werden die Datensätze an Orten gespeichert, die als Blätter bezeichnet werden. Diese Bezeichnung rührt daher, dass Datensätze immer an den Entstellen existieren; nach ihnen kommt nichts mehr. Der Startpunkt wird als die Wurzel bezeichnet. Die minimale Anzahl der Kinder pro Knoten wird als die Ordnung der Baumdatenstruktur 306, 308 bezeichnet. Die maximale Anzahl von Zugriffsoperationen, die zum Erreichen des gewünschten Datensatzes erforderlich sind, wird als die Tiefe bezeichnet. Die Ordnung kann bei jedem Knoten gleich sein, und die Tiefe kann für jeden Datensatz gleich sein. Andere Bäume haben variierende Anzahlen von Kindern pro Knoten, und verschiedene Datensätze können auf unterschiedlichen Tiefen liegen. Die Zuordnungen 310 sind die Umsetzungen der Struktur 306, 308, welche es dem Anwendungs-Gateway ermöglichen, die Backend-Nachrichtenstruktur 302 auf eine Gerätenachrichtenstruktur 304 umzusetzen und umgekehrt. Es wird anerkannt, dass die oben beschriebenen Baumstrukturen je nach Wunsch zum Beispiel unter anderem durch andere ähnliche Konstrukte aus Feld, Datei und Tabelle ersetzt werden können.
  • Für das Tool 116 kann der Baum-Viewer 602 eine TreeContentProvider- und LabelProvider-Schnittstelle nutzen, um die Struktur der Baumdarstellung abzufragen und Text bzw. Symbole für jeden einzelnen Knoten in dem Baum zu erhalten. Die Tabellen-Viewer 602 und Listen-Viewer 602 arbeiten in einer ähnlichen Weise, verwenden jedoch die strukturierten ContentProvider- und LabelProvider-Schnittstellen. Jede Klasse in dem Datenmodell 300 kann ein Änderungsbenachrichtiger sein, das heißt, dass bei jeder Änderung eines Attributs oder eines Verweises ein Ereignis getriggert wird. In EMF wird ein Benachrichtigungsbeobachter beispielsweise als Adapter bezeichnet, weil er nicht nur Statusänderungen überwacht, sondern auch das Verhalten der Klasse erweitern kann, mit der er verbunden ist (ohne Unterklassierung), indem zusätzliche Schnittstellen unterstützt werden. Ein Adapter wird durch eine Adapter-Factory mit einem Modellobjekt verbunden. Eine Adapter-Factory wird aufgefordert, ein Objekt mit einer Erweiterung eines bestimmten Typs zu adaptieren. Die Adapter-Factory ist verantwortlich für das Erstellen des Adapters oder das Zurückgeben eines existierenden Adapters, das Modellobjekt hat selbst keine Kenntnis von der Adaptierung. Das Tool 116 verwendet EMF zum Generieren eines Sets von Adaptern für das Datenmodell 300, die als Item-Provider bezeichnet werden. Jeder Item-Provider ist ein Adapter, der Provider-Schnittstellen implementiert, um das Verhalten des Objekts aus dem Modell 300 so zu erweitern, dass es betrachtet und bearbeitet werden kann, und ist gleichzeitig ein Benachrichtigungsbeobachter, der Statusänderungen an die abhörenden Ansichten weitergeben kann. Das Tool 116 verbindet die Editoren 600 und Viewer 602 mit dem Modell 300, indem die Editoren 600 und Viewer 602 beispielsweise mit einer oder mehreren EMF.Edit-Klassen konfiguriert werden. Jede EMF.Edit-Klasse unterstützt eine Eclipse UI-Provider-Schnittstelle. Die EMF.Edit-Klasse implementiert einen Schnittstellenaufruf durch Delegierung zu einer Adapter-Factory. Die Adapter-Factory gibt dann einen generierten Adapter (einen Item-Provider) zurück, der weiß, wie auf das Modell 300 zugegriffen wird. Wenn sich der Status des Modells 300 ändert, werden dieselben Adapter verwendet, um die Viewer 602 und Editoren 600 zu aktualisieren.
  • Dienstschicht 614
  • Wiederum unter Bezug auf 6 stellt eine Dienstschicht 614 Einrichtungen für die UI-Schicht 606 bereit, z. B. Validierung 620, Lokalisierung 624, Generierung 622, Build 626, Erfassungsmodul 629 und Bereitstellung 628, wie das weiter unten beschrieben wird. Das Tool 116 kann den Eclipse-Erweiterungspunktmechanismus nutzen, um zusätzliche Plugins für zwei Typen von Diensten zu laden: Backend-Konnektoren 616 und Geräte-Skin-Manager 618 mit den zugehörigen Präsentationsumgebungen 630.
  • Der Backend-Konnektor 616 definiert einen Eclipse-Erweiterungspunkt, um dem Tool 116 die Kommunikation mit verschiedenen Backend-Datenquellen 106 zu ermöglichen oder anderweitig Informationen über diese zu erlangen, um das Nachrichtenformat (z. B. durch WSDL-Definitionen bereitgestellt) der ausgewählten Datenquelle 106 zu erhalten. Der Backend-Konnektor 616 kann als eine Schnittstelle zur Verbindung zu Diensten der Backend-Datenquelle 106 wie z. B. Webdienste und SQL-Datenbanken verwendet werden und um diese zu untersuchen. Der Backend- Konnektor 616 ermöglicht das Aufbauen eines geeigneten Anwendungsnachrichten- und -datensets, um die Kommunikation mit diesen Diensten von der Anwendung 105 aus zu erlauben, wenn diese auf dem Gerät 100 ausgeführt wird. Der Backend-Konnektor 616 kann den Zugriff auf mehrere verschiedene Typen von Datenquellen 106 unterstützen, wozu unter anderem das Exponieren der jeweiligen direkten Kommunikationsschnittstellen über eine auf Kommunikationskonnektoren basierende Architektur gehört. Zur Laufzeit liest das Tool 116 die Plugin-Registrierung, um die bereitgestellten Backend-Erweiterungen zum Set der Backend-Konnektoren 616 hinzuzufügen, wozu unter anderem Konnektoren für Webdienste gehören.
  • Der Backend-Konnektor 616 kann unter anderem verantwortlich sein für: Verbindung zu einem (oder mehreren) ausgewählten Backend-Datenquellen 106 (z. B. Webdienst, Datenbank); Bereitstellung einer Schnittstelle zum Zugriff auf die Beschreibung der Backend-Datenquelle 106 (z. B. Nachrichten, Operationen und Datentypen); und/oder Bereitstellung der Identifikation von Benachrichtigungsdiensten (welche Benachrichtigungen über das Netzwerk 10 zum Gerät 100 pushen – siehe 1). Der Backend-Konnektor 616 kann eine Schnittstelle zur Backend-Datenquelle 106 (z. B. einem Webdienst, einer SQL-Datenbank oder einer anderen) für den Zugriff auf die Beschreibung der Datenquelle 106 bereitstellen und kann eine Abstraktionsebene zwischen implementierungsspezifischen Details des Backend-Messaging und generischen Messaging-Beschreibungen im Erfassungsmodell 300 bereitstellen. Beispielsweise kann der Backend-Konnektor 616 verwendet werden, um die jeweiligen Sets an Messaging- 404 und Datenkomponenten 400 (z. B. Datenelemente) für die Anwendung 105 zu erzeugen, und wird durch den Modellprüfer 620 im Rahmen der Validierungsaufgaben verwendet, um die Integrität der existierenden Nachrichtenerfassungsbeziehungen in dem Erfassungsmodell 300 und/oder in anderen in Entwicklung befindlichen Modellen 608, 610 zu verifizieren. Beispielsweise kann der Backend-Konnektor 616 als eine Schnittstelle implementiert sein, wobei ein API-Aufruf als das Protokoll zum Zugriff auf die zugrunde liegende Backend-Datenquelle 106 (z. B. unter Verwendung einer WSDL-Schnittstelle für Webdienste) verwendet wird. Es wird anerkannt, dass die Informationen der Datenquelle 106, auf die über den Konnektor 616 zugegriffen wird, verwendet werden, um die Konstruktion des Erfassungsmodells 300 zu unterstützen, wie das weiter unten beschrieben wird.
  • Der Geräte-Skin-Manager 618 definiert einen Eclipse-Erweiterungspunkt, um beispielsweise dem Tool 116 zu ermöglichen, unterschiedliche Geräte 100 zu emulieren (siehe 1), so dass das Erscheinungsbild der verschiedenen Zielgeräte 100 (der Anwendung 105) spezifiziert werden kann. Zur Laufzeit liest das Tool 116 die Plugin-Registrierung, um die bereitgestellten Skin-Erweiterungen oder Präsentationsumgebungen 630 zum Set der Geräteumgebungen 630 hinzuzufügen, die durch den Manager 618 koordiniert werden, beispielsweise unter anderem Umgebungen 630 für ein generisches BlackBerryTM oder ein anderes Gerät 100. Der Skin-Manager 618 wird durch den Test/Vorschau-Viewer 806 verwendet, um visuelle Elemente des Datenmodells 608, 610 zu laden, die für das emulierte Gerät 100 passend aussehen, d. h. Elemente, die mit der spezifizierten Umgebung 630 kompatibel sind. Unterschiedliche Skins oder Präsentationsumgebungen/formate 630 sind "plugin-fähig" in den Manager 618 des Tools 116, was bedeutet, dass Dritte ihre eigenen Präsentationsumgebungen 630 implementieren können, indem sie beispielsweise neue eindeutige SkinIds (ein Eclipse-Erweiterungspunkt) erstellen und eine geeignete Schnittstelle zum Erstellen von Instanzen der Bildschirmelemente implementieren, die durch die Laufzeitumgebung RE des emulierten Geräts 100 unterstützt werden. Um eine neue Präsentationsumgebung 630 zu landen, fragt der Test/Vorschau-Viewer 806 zuerst den Manager 618 nach einer Instanz der spezifizierten Umgebung. Der Manager 618 instantiiert dann die Umgebung 630, und der Test/Vorschau-Viewer 806 verwendet die spezifizierte Umgebung 630 zum Konstruieren der Bildschirmelemente entsprechend den Bildschirmkomponenten des Modells 608, 610. Beispielsweise werden die Präsentationsumgebungen 630 (z. B. Skin-Plugins) für den Skin-Manager 618 über einen angepassten Eclipse-Erweiterungspunkt unter Verwendung des Eclipse-Frameworks identifiziert.
  • Die Modellprüfung 620 der Serviceschicht 614 stellt Einrichtungen für die UI-Schicht 606 bereit, z. B. die Prüfung (Validierung) des Entwurfszeit-Datenmodells 608 und/oder des Erfassungsmodells 300. Der Modellprüfer 620 wird verwendet, um zu überprüfen, dass die Repräsentation der Nachrichten in Anwendung 105 gemäß der Präsentation der Messaging-Operationen in der Backend-Datenquelle 106 erfolgt. Der Modellprüfer 620 kann dafür verantwortlich sein, die Repräsentation des Modells 608 der zu generierenden Anwendung 105 zu überprüfen, was beispielsweise unter anderem die folgenden Elemente einschließt: Workflow-Integrität der Workflow-Komponente 406; Konsistenz von Parametern und Feldschichtzuordnungen der Komponenten 400, 402, 404, 406; Bildschirmsteuerungszuordnungen und Bildschirmaktualisierungsnachrichten der Bildschirmkomponenten 402; Nachrichten- und/oder Datendopplungen innerhalb und außerhalb der Komponente 400, 402, 404, 406. Eine weitere Funktion der Validierung 620 kann die Überprüfung der vom Modell 300 repräsentierten Messaging-Beziehungen der Backend-Datenquelle 106 sein. Um seiner Verantwortung gerecht zu werden, arbeitet der Prüfer mit dem Entwurfszeit-Datenmodell 608, dem Erfassungsmodell 300, den Nachrichtenstrukturen 302, 304, einem Anwendungsgenerator 622 und dem Backend-Konnektor 616 zusammen. Der Modellprüfer 620 nutzt im Rahmen der Prüfungsaufgabe das Entwurfszeit-Datenmodell 608 (zur Validierung der Anwendung 105) und die Nachrichtenstrukturen 302, 304 (zur Validierung des Modells 300) sowie den Backend-Konnektor 616, der die Schnittstelle zu den Backend-Datenquellen 106 unterstützt.
  • Wiederum unter Bezug auf 6 ist der Lokalisierungsdienst 624 unter anderem für Folgendes verantwortlich: Unterstützung einer Buildzeitlokalisierung für dem Benutzer sichtbare Zeichenfolgen; Unterstützung zusätzlicher Lokalisierungseinstellungen (z. B. Standardanzeigeformat für Datum und Uhrzeit, Standardanzeigeformat für Zahlen, Anzeigewährungsformat usw.); und Erstellung der Ressourcenbündeldateien (und Ressourcen), die während der Vorbereitung der bereitstellungsfähigen Anwendung 105 (z. B: eine Anwendungs-JAR-Datei) durch einen Build-Dienst 626 verwendet werden können. Beispielsweise kann der Lokalisierungsdienst 624 als ein Ressourcenmodul zum Erfassen von Ressourcen implementiert sein, die im Entwurfszeit-Datenmodell 608 resident sind, um diese in die bereitstellungsfähige Anwendung 105 einzuschließen. Die JAR-Datei kann eine Datei sein, welche die Klassen-, Bild- und Sound-Dateien für die Anwendung enthält, die zu einer einzigen Datei zusammengefasst und komprimiert sind, um ein effizientes Herunterladen auf das Gerät 100 zu ermöglichen. Der Lokalisierungsdienst 624 wird durch den Anwendungsgenerator 622 verwendet, um beispielsweise die sprachspezifischen Ressourcenbündel zu produzieren. Der Build-Dienst 626 implementiert die Vorbereitung der Ressourcenbündel und das Packen der Ressourcenbündel mit der bereitstellungsfähigen Anwendung 105. Der Lokalisierungsdienst 624 interagiert (stellt eine Schnittstelle bereit) mit den Tooleditoren 600 und -viewern 602, um Sprachzeichenfolgen und Regionseinstellungen der Anwendung 105 festzulegen oder anderweitig zu manipulieren.
  • Unter Bezug auf 6 kann der Generator 622 beispielsweise unter anderem für Folgendes verantwortlich sein: Erzeugung der Anwendungs-XML aus den Komponenten 400, 402, 404; Erzeugung der Deskriptoren des Erfassungsmodells 300 (einschließlich der Zuordnungen 310); optimierte Feldsortierung der Deskriptoren der Komponente 400, 402, 404; und Erzeugung der Abhängigkeiten und Skriptumsetzung, wie sie für die Speicherung im Speicher 210 gewünscht sind. Der Generator 622 arbeitet mit dem Entwurfszeit-Datenmodell 608 zusammen, um den Inhalt der entwickelten Komponenten 400, 402, 404 zu erhalten, welche die Anwendung 105 bilden, und kooperiert mit dem Erfassungsmodell 300, um die Zuordnungen 310 im Modell 300 zur Verwendung durch das Anwendungs-Gateway AG zu generieren. Der Generator 622 nutzt den Modellprüfer 620, um zu überprüfen, dass sowohl die Definitionen (der Komponenten 400, 402, 404, 406) der Anwendung 105 als auch die Beschreibungsinformationen des Erfassungsmodells 300 korrekt sind. Der Generator 620 produziert dann den XML-Code der Anwendung 105, mit Einbeziehungen und/oder Erweiterungen des Skripts der Workflow-Komponenten 406, und/oder die Dateideskriptoren des Erfassungsmodells 300 (durch das Anwendungs-Gateway AG verwendet). Der Generator 622 verwendet den Lokalisierungsdienst 624, um das Sprachressourcenbündel zu produzieren, beispielsweise über eine Ressourcenbündel-Schnittstelle (nicht dargestellt). Der Erzeugungsprozess des Generators 622 kann über eine Erzeugungsschnittstelle gestartet werden, auf die der Benutzer über die UI 202 des Tools 116 zugreift (z. B. durch Benutzereingabeereignisse wie Mausklicks und/oder Drücken von Tasten). Es wird anerkannt, dass der Generator 622 als eine Sammlung von Modulen konfiguriert sein kann, zu denen beispielsweise unter anderem ein Code-Modul zum Erzeugen des XML (der das zugehörige Skript enthalten kann) und ein Erfassungsmodul zum Erzeugen der Deskriptoren des Erfassungsmodells 300 gehören. Es wird anerkannt, dass das Erfassungsmodell 300 entwickelt werden kann, während sich die Anwendung 105 in Entwicklung befindet, oder entwickelt werden kann, sobald die Entwicklung der Anwendung 105 abgeschlossen ist.
  • Der Bereitstellungsdienst 628 wird zur Bereitstellung der geeigneten Deskriptordatei der Anwendung 105 im Hinblick auf das Repository 114 und die Registrierung 112 verwendet, um das Erfassungsmodul 300 zur Verwendung durch das Anwendungs-Gateway AG bereitzustellen. Der Build-Dienst 626 stellt einen Mechanismus zum Aufbau der bereitstellungsfähigen Form der Anwendung 105 und/oder des Erfassungsmoduls 300 bereit. Der Build-Dienst 626 produziert über eine Build-Engine die bereitstellungsfähige Datei der Anwendung 105 und/oder die Datei des Erfassungsmoduls 300. Diese Dateien werden über eine Ausgangsschnittstelle des Tools 116 dem Bereitstellungsdienst 628 verfügbar gemacht. Der Sicherheitsdienst 632 verfügt über die Möglichkeit zur Signierung der Datei der Anwendung 105 und/oder der Datei des Erfassungsmodells 300, um ein Eingreifen in ihren Inhalt zu verhindern und um die Identität des Erzeugers bereitzustellen. Es kann zwei Beispieloptionen für die Signierung geben, entweder die Verwendung von DAS mit SHA1-Digest oder RSA mit MD5, was nach dem Stand der Technik bekannt ist. Beispielsweise kann der Sicherheitsdienst 632 Zertifikate handhaben, die zur Signierung der Datei der Anwendung 105 und/oder des Erfassungsmodells verwendet werden. Der Sicherheitsdienst 632 kann über die Möglichkeit verfügen, ein Paar aus öffentlichem und privatem Schlüssel anzufordern, zu speichern und zu verwenden, um dazu beizutragen, dass die Gültigkeit des Erzeugers und des Inhalts der Dateien der Anwendung 105 und/oder des Erfassungsmodells 300 bei deren Bereitstellung gewährleistet ist. Das Modell kann als ein Framework zum Organisieren und Repräsentieren von Messaging-Informationen definiert sein, die durch das Anwendungs-Gateway AG verwendet werden, um die Kommunikation zwischen dem Gerät 100 und der Datenquelle 106 zu erleichtern.
  • Operation des Erfassungsmoduls 629
  • Die Nachrichtenstruktur 302 und die zugehörige Datenstruktur 308 kann komplexe Datenstrukturen enthalten, die viele Verschachtelungsebenen aufweisen (z. B. mehrdimensionale Datenstrukturen mit verschachtelten Datenfeldern), was für Drahtlosgeräte 100 mit eine erheblichen Arbeitsspeicherbelastung verbunden sein kann. Diese komplexe Datenrepräsentation kann sich auch auf die Leistung auswirken, wenn auf solche Daten im Dauerspeicher 210 des Geräts 100 zugegriffen wird (siehe 2). Das Erfassungsmodul 629 hat die Aufgabe, die Nachrichtenstruktur 302 zu entfernen oder anderweitig zu vereinfachen und damit die Nachricht und die zugehörigen Daten zur Verwendung in der Gerätenachrichtenstruktur 304 zu verflachen (siehe 4). Diese Verflachung kann dazu beitragen, die Verarbeitungseffizienz im Gerät 100 und auch die Leistung des Dauerspeichers 210 zu verbessern. Dementsprechend wird das Erfassungsmodul 629 durch das visuelle Entwicklungstool 116 eingesetzt, um den Entwickler dabei zu unterstützen, detaillierte Querzuordnungen (Cross Mappings) 310 zwischen den in der Datenquelle beschriebenen Nachrichtenstrukturen 302 und dem optimierten Erscheinungsbild der zum Gerät 100 gelieferten Nachrichtenstrukturen 304 bereitzustellen, und zwar über einen Erfassungsprozess, der durch die Messaging-Strukturen 304 der Drahtlosanwendung 105 und verwandte Datenstrukturen 306 gesteuert wird.
  • Typische komplexe Datenstrukturen können das Feld (bzw. Array), den Stapel, die verlinkte Liste, den Baum und auch Klassen einschließen, die beispielsweise verwendet werden, um die physischen und/oder logischen Beziehungen zwischen den Datenelementen der Struktur zur Unterstützung unterstützungsspezifischer Datenmanipulationsfunktionen zu repräsentieren. Die verlinkte Liste ist eine sequenzielle Sammlung von Strukturen, die durch Zeiger miteinander verbunden oder "verlinkt" sind. Verlinkte Listen können flexibler als Felder zur Führung von Elementlisten verwendet werden. Die verlinkte Liste kann bei Bedarf wachsen, während das Feld auf die anfänglich deklarierte feststehende Anzahl von Elementen beschränkt sein kann. Der Zeiger enthält eine Speicheradresse einer Variablen; die Variable enthält einen spezifischen Wert. Es wird anerkannt, dass die Array-Datenstruktur sich von der verlinkten Listendatenstruktur unterscheiden kann, weil der Programmierer lediglich mit den Array-Positionen zu tun hat und der Computer sämtliche Speicheraspekte verbirgt. Bei verlinkten Listen hat der Programmierer dagegen mit einigen Speicheraspekten zu tun – den Zeigern. Damit kann die verlinkte Listendatenstruktur aufgrund ihres Wesens jenseits des logischen Aspekts noch einen physischen Aspekt haben: die Manipulation von Speicheradressen, durch Zeiger. Es wird anerkannt, dass die obigen Beispiele als exemplarische Beschreibungen der Datenstrukturen 306, 308 betrachtet werden können.
  • Unter Bezug auf 5 ermöglicht der Top-Down-Erfassungsprozess 500 dem Entwickler das Verlinken von Feldern in jeder beliebigen Konfiguration (bei akzeptablen Typkonvertierungen), das Verlinken ganzer komplexer Strukturen auf der Basis der Analyse gemeinsamer Definitionen zwischen den Datenstrukturen 306, 308, und er hilft beim Durchsetzen minimaler Datenanforderungen zur Befriedigung grundlegender Anforderungs- oder Antwortanfragen der verwandten Messaging-Strukturen 302, 304. Der Erfassungsprozess 500 wird durch die Struktur der Drahtlosnachrichtenelemente der Anwendung 105 mit jeder beliebigen Komplexität bestimmt, und der Prozess 500 produziert das Erfassungsmodell 300, welches flexible und optimierte Querzuordnungen 310 einschließt, so dass aus komplexen Typen selektive Daten extrahiert und zu und von einem optimierten Schema der Nachrichtenstruktur 306 übergeben werden können, wie sie von der drahtlosen Anwendung 105 erwartet werden. Das Erfassungsmodul 629 kann in das Tool 116 integriert werden und kann verschiedene Artefakte nutzen, um Effizienz, Flexibilität und Konsistenz mit jedem vorherigen Erfassungsprozess durchsetzen, der durch die entwickelte Anwendung 105 genutzt wird. Das Erfassungsmodul 629 verwendet eine XML-Schema-Erfassungsspezifikation 504 (d. h. Erfassungsformat – siehe Anhang A) zur Anleitung der Erzeugung des Erfassungsmodells 300, der Beschreibung der Anwendung 105 (einschließlich der Struktur 304) und der Beschreibung der Datenquelle 106 (z. B. WSDL-Spezifikation der Struktur 302). Das Erfassungsmodul 629 wählt 506 die Anwendung 105 aus und wählt 508 die Datenquelle 106 aus.
  • Grundsätzlich besteht der Erfassungsprozess 500 aus zwei iterativen Hauptschritten. Der erste Schritt ist eine anfängliche Umsetzung 510a der Drahtlosanwendungsnachrichtenstruktur 304 und die Umsetzung 510b der Datenquellennachrichtenstruktur 302 in die entsprechenden Datenstrukturen 306, 308, z. B. Baumrepräsentationen (siehe 8, wo eine exemplarische Baumrepräsentation des Anwendungsnachrichteninhalts und der entsprechenden Felder gezeigt wird). Der Drahtlosanwendungsnachrichteninhalt kann Datenfelder komplexer Typen umfassen, welche Felder des Typs Aufzählung oder Einfach/Komplex-Typ usw. haben, die in der Datenstruktur 306 repräsentiert würden. In gleicher Weise umfasst der Datenquellennachrichteninhalt Teile, die sich nach der XML-Schemaspezifikation 504 zu einem Element oder einem Einfach/Komplex-Typ rekursiv auflösen können, die in der Datenstruktur 308 repräsentiert würden. Nach dieser anfänglichen Umsetzung der Zielstrukturen versucht das Erfassungsmodul 629, sich in den Datenstrukturen 306, 308 aufzulösen, basierend auf einem Set aus Validierungsregeln.
  • Der zweite Schritt 512 ist ein iterativer Unterprozess des Produzierens von Zuordnungen 310 für ein Element in der Drahtlosbaumstruktur 306 zu einem passenden Element der Datenquellenbaumstruktur 308. Die durch das Modul 629 verwendeten Artefakte und Validierungsregeln können beispielsweise unter anderem sein:
    • 1. ein bereits zugeordnetes Drahtloselement kann nicht erneut zugeordnet werden;
    • 2. das Modul 629 erlaubt nur dann die Verknüpfung (Zuordnung 310) zwischen 2 komplexen Strukturen, wenn diese komplexen Strukturen in Bezug auf Kardinalität und Typkompatibilität übereinstimmen;
    • 3. die Benutzeroberfläche 202 ermöglicht dem Entwickler die Produktion der Zuordnungen 310 von zwei kompatiblen Strukturen und erzeugt automatisch alle Zuordnungen 310 für die Felder (Kindknoten in dem Baum) zu den drahtlosen elementaren Feldern;
    • 4. der Erfassungsprozess 500 kann erst abgeschlossen werden, wenn alle drahtlosen elementaren Felder (Blattknoten im drahtlosen Nachrichtenbaum) zugeordnet sind. Dies kann eine leistungsstarke Möglichkeit zur Durchsetzung der Effizienz in drahtlosen Anwendungen 105 durch Optimierung des Verkehrs des Geräts 100 sein, da die wechselseitige Übergabe nicht notwendiger drahtloser Elemente/Felder zwischen dem Gerät 100 und der Datenquelle 106 minimiert wird; und
    • 5. eine mögliche vorherige Zuordnung 310 zwischen der Drahtlosnachrichtenstruktur 304 und der Datenquellennachrichtenstruktur 302 wird auf der Oberfläche 202 des Tools 116 angezeigt. Der Drahtlosentwickler hat die Möglichkeit, die existierenden Zuordnungen 310 zu ändern oder querzuverlinken oder die existierende Zuordnung 310 insgesamt zu löschen. In dieser Situation können die erzeugten Zuordnungen 310 Vorrang erhalten, und die alten Zuordnungen 310 können überschrieben werden, wie das im Erfassungsmodell 300 repräsentiert ist, dass durch den Generator 622 erzeugt wird.
  • Es wird anerkannt, dass in der obigen exemplarischen Operation 500 die Beschreibung der Anwendung 105 (einschließlich der Struktur 304) und die Beschreibung der Datenquelle 106 (z. B. WSDL-Spezifikation der Struktur 302) verglichen oder anderweitig validiert werden, um die im Erfassungsmodell 300 enthaltenden Zuordnungen 310 zu produzieren, die vom Anwendungs-Gateway AG während des Nachrichtenmakelns bei der Kommunikation 302, 304 zwischen der Datenquelle 106 und dem Gerät 100 verwendet werden.
  • Unter Bezug auf 9 beschreibt der Prozess 900 ferner die Operation des Moduls 629: die Auswahl 902 der Datenquelle 106 und der Anwendung 105; das Ermitteln 904 vergleichbarer Elemente zwischen den Strukturen 306, 308; das Erstellen 906 der Zuordnungen 310; das Überprüfen 908, ob alle Elemente der Strukturen 306, 308 zugeordnet bzw. erfasst wurden; und das Erzeugen/Aktualisieren des Erfassungsmodells 300.
  • Unter Bezug auf 10 beschreibt der Prozess 800: das Lesen der Benutzerauswahl der Datenquelle 106 und der Anwendung 105; das Ermitteln 804, ob einfache Typen in den Strukturen 306, 308 verfügbar sind; wenn nicht, dann das Fortsetzen des Lesens 806 von Kindern der Knoten; wenn ja, dann das Ermitteln 808, ob die Typen in den Strukturen 306, 308 kompatibel sind; wenn ja, dann wird die Zuordnung 310 akzeptiert und in das Modell 300 geschrieben 810; wenn nein, dann wird die Zuordnung 310 zurückgewiesen 812. Alle Knoten der Strukturen 306, 308 können in gleicher Weise wie oben beschrieben gelesen werden, um das vollständige Set der Zuordnungen 310 zu erzeugen, die in dem Modell 300 verwendet werden.
  • Beispiel für die Zuordnung 310
  • Das Folgende ist ein Beispiel des durch das Modul 629 erzeugten Modells 300. Für eine gegebene Drahtlosanwendungsnachrichtenstruktur 304 werden die Zuordnungen 310 zur Datenquellennachrichtenstruktur 302 entsprechend dem exemplarischen Zuordnungsformat erzeugt, das in Anhang A gezeigt wird.
  • Figure 00390001
  • Figure 00400001
  • Figure 00410001
  • Deshalb sind das oben beschriebene Tool 116 und die zugehörige Operationsmethode zum Erzeugen des Erfassungsmodells 300 fähig, die Nachrichtenkommunikationen zwischen der ersten Nachrichtenstruktur 304 und der zweiten Nachrichtenstruktur 302 umzusetzen. Die erste Nachrichtenstruktur 304 ist zur Verwendung durch das Client-Gerät 100 konfiguriert und die zweite Nachrichtenstruktur 302 zur Verwendung durch die Datenquelle 106, so dass die Datenquelle 106 durch die Implementierung des Erfassungsmodells 300 für die Netzwerkverbindung mit dem Client-Gerät 100 konfiguriert wird. Eine exemplarische Implementierung besteht darin, dass das Erfassungsmodell 300 durch das Anwendungs-Gateway AG gehostet wird. Eine weitere exemplarische Implementierung besteht darin, dass das Erfassungsmodell 300 entweder durch das Client-Gerät 100, die Datenquelle 106 oder durch eine Kombination daraus gehostet wird. Das Tool 116 und die zugehörige Operation schließen ein: ein Anwendungsmodul (d. h. das Entwurfszeitmodell 608) zur Bereitstellung einer Beschreibung der ersten Nachrichtenstruktur 304, wobei die erste Nachrichtenstruktur 304 mindestens ein Client-Nachrichtenelement zur Zusammenstellung in der ersten Datenstruktur 306 umfasst; ein Datenquellenmodul (d. h. der Backend-Konnektor 616) zur Bereitstellung einer Beschreibung der zweiten Nachrichtenstruktur 302, wobei die zweite Nachrichtenstruktur 302 eine Vielzahl an Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer Datenstruktur mit mehreren Schichten 308 umfasst, wobei die mehreren Schichten der zweiten Datenstruktur 308 der Repräsentation der Beziehungen zwischen den Nachrichtenelementen der Datenquelle dienen; und das Erfassungsmodul 629 der Erstellung von mindestens einem Erfassungsdeskriptor 310 des Erfassungsmodels 300 durch Vergleich der ersten Datenstruktur 306 mit der zweiten Datenstruktur 308 dient, wobei die Erfassungsdeskriptoren 310 der Verlinkung des mindestens einen Client-Nachrichtendatenelements der ersten Datenstruktur 306 mit mindestens einem der Datenquellennachrichtenelemente der zweiten Datenstruktur 308 dienen, so dass eine Anzahl von Schichten in der ersten Datenstruktur 306 nicht größer (d. h. gleich oder kleiner) ist als die Anzahl der Schichten in der zweiten Datenstruktur 308. Das Erfassungsmodell 300 einschließlich der Erfassungsdeskriptoren 310 wird anschließend zur Überwachung der Nachrichtenkommunikation zwischen dem Client-Gerät 100 und der Datenquelle 106 verwendet. Anhang A – Exemplarisches XML-Erfassungsschema
    Figure 00430001
    Figure 00440001
    Figure 00450001
    Figure 00460001

Claims (24)

  1. Ein System zur Erstellung eines Erfassungsmodells (300), um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen und zu überwachen, das erste Nachrichtenformat für den Gebrauch eines Kunden konfiguriert und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle (106), die Datenquelle konfiguriert für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells, umfasst das System: ein Anwendungsmodul (608) zur Bereitstellung einer Beschreibung des ersten Nachrichtenformats, das erste Nachrichtenformat umfasst mindestens ein Nachrichtenelement des Kunden zur Zusammenstellung in einer ersten Datenstruktur; ein Datenquellenmodul (616) zur Bereitstellung einer Beschreibung des zweiten Nachrichtenformats, das zweite Nachrichtenformat umfasst eine Vielzahl an Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer Datenstruktur mit mehreren Abschnitten, die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle; ein Erfassungsmodul (629) zur Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur (306) mit der zweiten Datenstruktur (308), die Erfassungsdeskriptoren zur Verlinkung des mindestens einem Nachrichtenelement des Kunden der ersten Datenstruktur mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur, wenn die Anzahl der Abschnitte in der zweiten Datenstruktur größer ist als die Anzahl der Abschnitte in der ersten Datenstruktur; wobei das Erfassungsmodell (300), das die Erfassungsdeskriptoren einschließt, anschließend verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  2. Das System aus Anspruch 1, bei welchem das Kundengerät kabellos mit dem Netzwerk verbunden ist.
  3. Das System aus Anspruch 1, 2 oder 3, wobei die zweite Datenstruktur eine beliebige Feldstruktur, Stapelspeicherstruktur, verlinkte Listenstruktur, Baumstruktur oder Klassenstruktur umfasst.
  4. Das System aus Anspruch 1, 2 oder 3, wobei die Erfassungsmodelldeskriptoren (300) die Nachrichtenelemente der Webdienstnachrichten auf den Nachrichtenelementen der Nachrichten des Kundengeräts abbilden, das Kundengerät (100) in Kommunikation mit dem Webdienst, der Webdienst ist die Datenquelle, die das zweite Nachrichtenformat benutzt und das Kundengerät (100) benutzt das erste Nachrichtenformat.
  5. Das System aus jeglichem der Ansprüche 1 bis 4, wobei das Anwendungsmodul die Beschreibung des ersten Nachrichtenformats von den Nachrichtenkomponenten einer Anwendung, ausgedrückt in einer strukturierten Definitionssprache erhält, die Anwendung konfigurierbar zur Ausführung auf dem Kundengerät (100).
  6. Das System aus jeglichem der Ansprüche 1 bis 5, wobei das Datenquellenmodul (616) die Beschreibung des zweiten Nachrichtenformats von den Nachrichtenkomponenten einer Webdienstschnittstelle, ausgedrückt in einer strukturierten Definitionssprache erhält.
  7. Das System aus Anspruch 6, ferner ein Verbindungsmodul für den Zugang zur Beschreibung der Webdienstschnittstelle über das Netzwerk umfassend.
  8. Das System aus Anspruch 7, ferner eine Vielzahl an Erfassungsmodellen (300), konfiguriert für die Nachrichtenkommunikation des Kundengeräts (100) mit mehreren entsprechenden Webdiensten umfassend.
  9. Das System aus jeglichem der Ansprüche 1 bis 8, wobei das Erfassungsmodell konfiguriert ist, um Nachrichtenelemente der ersten und zweiten Nachrichtenformate abzubilden, einschließlich jeglicher: verbundener Datenfelder, die an akzeptierbare Typenkonvertierungen gebunden sind; Verlinkung ganzer komplexer Datenstrukturen basierend auf üblichen Definitionen zwischen den ersten und zweiten Datenstrukturen; oder Durchsetzung von vordefinierten Datenanforderungen zur Zufriedenstellung der Nachrichtenanforderungen von zugehörigen Nachrichtenstrukturen.
  10. Das System aus jeglichem der Ansprüche 1 bis 9, ferner ein Erfassungsschema, ausgedrückt in einer strukturierten Definitionssprache, zur Leitung der Erzeugung eines Erfassungsmodells durch das Erfassungsmodul (629) umfassend.
  11. Das System aus jeglichem der Ansprüche 1 bis 10, ferner eine Reihe von Prüfvorschriften, die vom Erfassungsmodul (629) verwendet werden, umfassend, einschließlich jeglichem: bereits erfassten Nachrichtenelement, das nicht nochmals erfasst werden kann; Erfassungsdeskriptoren, die die Erfassung zwischen 2 komplexen Datenstrukturen darstellen, können nur erzeugt werden, wenn diese komplexen Datenstrukturen hinsichtlich der Kardinalität und Typenkompatibilität zusammenpassen; die Erfassungsdeskriptoren werden für zwei kompatible Datenstrukturen für Datenfelder bis zu den entsprechenden elementaren Feldern erzeugt; die Erfassungsdeskriptoren sind nicht vollständig, bis alle der elementaren Felder der Datenstrukturen erfasst sind; oder ein letztendlich vorheriger Erfassungsdeskriptor zwischen der ersten Datenstruktur und der zweiten Datenstruktur wird auf einer grafischen Schnittstelle dargestellt.
  12. Eine Methode zur Erzeugung eines Erfassungsmodells (300), um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen und zu überwachen, das erste Nachrichtenformat für den Gebrauch eines Kunden konfiguriert und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle (106), die Datenquelle konfiguriert für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells, die Methode umfasst die Schritte: Erhalt einer Beschreibung des ersten Datenformats, das erste Datenformat umfasst mindestens ein Kundennachrichtenelement zur Zusammenstellung in einer ersten Datenstruktur (306); Erhalt einer Beschreibung des zweiten Datenformats, das zweite Datenformat umfasst eine Vielzahl von Nachrichtenelementen der Datenquelle zur Zusammenstellung in einer zweiten Datenstruktur mit mehreren Abschnitten (308), die mehreren Abschnitte der zweiten Datenstruktur zur Darstellung der Beziehungen zwischen den Nachrichtenelementen der Datenquelle; Erstellung von mindestens einem Erfassungsdeskriptor des Erfassungsmodels durch Vergleich der ersten Datenstruktur (306) mit der zweiten Datenstruktur (308), die Erfassungsdeskriptoren zur Verlinkung des mindestens einem Nachrichtenelement des Kunden der ersten Datenstruktur (306) mit einer Vielzahl der Nachrichtenelemente der Datenquelle der zweiten Datenstruktur (308), wenn die Anzahl der Abschnitte in der zweiten Datenstruktur größer ist als die Anzahl der Abschnitte in der ersten Datenstruktur; wobei das Erfassungsmodell, das die Erfassungsdeskriptoren einschließt, anschließend verwendet wird, um die Nachrichtenkommunikation zwischen dem Kunden und der Datenquelle zu überwachen.
  13. Die Methode aus Anspruch 12, bei welchem das Kundengerät kabellos mit dem Netzwerk verbunden ist.
  14. Die Methode aus Anspruch 12 oder 13, wobei die zweite Datenstruktur (308) eine beliebige Feldstruktur, Stapelspeicherstruktur, verlinkte Listenstruktur, Baumstruktur oder Klassenstruktur umfasst.
  15. Die Methode aus Anspruch 12, 13 oder 14, wobei die Erfassungsmodelldeskriptoren die Nachrichtenelemente der Webdienstnachrichten auf den Nachrichtenelementen der Nachrichten des Kundengeräts abbilden, das Kundengerät (100) in Kommunikation mit dem Webdienst, der Webdienst ist die Datenquelle, die das zweite Nachrichtenformat benutzt und das Kundengerät (100) benutzt das erste Nachrichtenformat.
  16. Die Methode aus jeglichem der Ansprüche 12 bis 15, wobei die Beschreibung des ersten Nachrichtenformats von den Nachrichtenkomponenten einer Anwendung, ausgedrückt in einer strukturierten Definitionssprache, erhalten wird, die Anwendung konfigurierbar zur Ausführung auf dem Kundengerät (100).
  17. Die Methode aus jeglichem der Ansprüche 12 bis 15, wobei die Beschreibung des zweiten Nachrichtenformats von den Nachrichtenkomponenten einer Webdienstschnittstelle, ausgedrückt in einer strukturierten Definitionssprache, erhalten wird.
  18. Die Methode aus Anspruch 17, ferner den Schritt zum Zugang zur Beschreibung der Webdienstschnittstelle über das Netzwerk umfassend.
  19. Die Methode aus Anspruch 18, ferner den Schritt zur Erzeugung einer Vielzahl an Erfassungsmodellen, konfiguriert für die Nachrichtenkommunikation des Kundengeräts mit mehreren entsprechenden Webdiensten umfassend.
  20. Die Methode aus jeglichem der Ansprüche 12 bis 19, wobei das Erfassungsmodell konfiguriert ist, um Nachrichtenelemente der ersten und zweiten Nachrichtenformate abzubilden, einschließlich jeglicher: verbundener Datenfelder, die an akzeptierbare Typenkonvertierungen gebunden sind; Verlinkung ganzer komplexer Datenstrukturen basierend auf üblichen Definitionen zwischen den ersten und zweiten Datenstrukturen; oder Durchsetzung von vordefinierten Datenanforderungen zur Zufriedenstellung der Nachrichtenanforderungen von zugehörigen Nachrichtenstrukturen.
  21. Die Methode aus jeglichem der Ansprüche 12 bis 20, ferner den Schritt der Anwendung eines Erfassungsschemas, ausgedrückt in einer strukturierten Definitionssprache zur Leitung der Erzeugung des Erfassungsmodells.
  22. Die Methode aus jeglichem der Ansprüche 12 bis 21, ferner den Schritt der Anwendung einer Reihe von Prüfvorschriften, die zur Erzeugung der Modelldeskriptoren verwendet werden, umfassend, die Prüfvorschriften einschließlich jeglichem: bereits erfassten Nachrichtenelement, das nicht nochmals erfasst werden kann; Erfassungsdeskriptoren, die die Erfassung zwischen 2 komplexen Datenstrukturen darstellen, können nur erzeugt werden, wenn diese komplexen Datenstrukturen hinsichtlich der Kardinalität und Typenkompatibilität zusammenpassen; die Erfassungsdeskriptoren werden für zwei kompatible Datenstrukturen für Datenfelder bis zu den entsprechenden elementaren Feldern erzeugt; die Erfassungsdeskriptoren sind nicht vollständig, bis alle der elementaren Felder der Datenstrukturen erfasst sind; oder ein letztendlich vorheriger Erfassungsdeskriptor zwischen der ersten Datenstruktur und der zweiten Datenstruktur wird auf einer grafischen Schnittstelle dargestellt.
  23. Ein Computerprogrammprodukt zur Erzeugung eines Erfassungsmodells, um Nachrichtenkommunikationen zwischen einem ersten Nachrichtenformat und einem zweiten Nachrichtenformat umzusetzen, das erste Nachrichtenformat für den Gebrauch eines Kunden konfiguriert und das zweite Nachrichtenformat für den Gebrauch einer Datenquelle, die Datenquelle konfiguriert für die Netzwerkkommunikation mit dem Kunden durch die Anwendung eines Erfassungsmodells, umfasst das Computerprogrammprodukt: ein computerlesbares Medium, einschließlich Hilfsmitteln für den Programmcode, ausführbar von einem Prozessor eines Computergeräts, -einheit oder -systems zur Umsetzung der Methode aus jeglichem der Ansprüche 12 bis 22.
  24. Bin Kommunikationsnetzwerksystem, einschließlich des Systems aus jeglichem der Ansprüche 1 bis 11.
DE602005004382T 2005-04-18 2005-04-18 System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen Active DE602005004382T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP05103047A EP1715431B1 (de) 2005-04-18 2005-04-18 System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen

Publications (2)

Publication Number Publication Date
DE602005004382D1 DE602005004382D1 (de) 2008-03-06
DE602005004382T2 true DE602005004382T2 (de) 2009-01-08

Family

ID=34939333

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005004382T Active DE602005004382T2 (de) 2005-04-18 2005-04-18 System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen

Country Status (4)

Country Link
EP (1) EP1715431B1 (de)
AT (1) ATE384300T1 (de)
CA (1) CA2543959C (de)
DE (1) DE602005004382T2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935093B (zh) * 2020-07-14 2023-04-07 湖南哈工楚帆智能科技有限公司 设备的集成方法和装置
US11502911B2 (en) * 2021-04-07 2022-11-15 Cisco Technology, Inc. Dynamic augmentation for functionally similar data models on network devices
CN115022403B (zh) * 2022-07-07 2022-12-13 中航信移动科技有限公司 一种用于多渠道服务代理的信息处理系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004507839A (ja) * 2000-08-29 2004-03-11 コンティヴォ　インコーポレイテッド 仮想グループ

Also Published As

Publication number Publication date
DE602005004382D1 (de) 2008-03-06
EP1715431A1 (de) 2006-10-25
CA2543959C (en) 2012-07-10
ATE384300T1 (de) 2008-02-15
CA2543959A1 (en) 2006-10-18
EP1715431B1 (de) 2008-01-16

Similar Documents

Publication Publication Date Title
US8407666B2 (en) System and method for generating component based applications
US20060235882A1 (en) System and method for developing arbitrary and efficient mappings between complex message structures
US8132149B2 (en) System and method for applying development patterns for component based applications
US7120896B2 (en) Integrated business process modeling environment and models created thereby
US7747983B2 (en) System and method for generating a web service definition and database schema from wireless application definition
US20060236307A1 (en) System and method for transformation of wireless application definition to simplified form
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
US8683433B2 (en) Adaptive change management in computer system landscapes
DE60108158T2 (de) Onlineentwicklung von applikationen
US7716665B2 (en) System and method for developing portal applications and for automatically deploying portal applications into a portal server application
US7895566B2 (en) System and method for building a deployable component based application
US20060236254A1 (en) System and method for automated building of component based applications for visualizing complex data structures
EP1703379A1 (de) System und Verfahren zum Anbringen von Entwicklungsmustern für komponentbasierte Anwendungen
EP1715414A1 (de) System und Methode zur automatisierten Erstellung komponentenbasierter Anwendungen zur Visualisierung komplexer Datenstrukturen
WO2005069942A2 (en) System and method for generating and deploying a software application
US20080229274A1 (en) Automating Construction of a Data-Source Interface For Component Applications
DE602005004382T2 (de) System und Verfahren zur Entwicklung von Zuordnungen zwischen verschiedenen Nachrichtenstrukturen
CA2538861C (en) System and method for building a deployable component based application
EP1712995A1 (de) System und Verfahren zur Unterstützung der Verpackung, des Veröffentlichen und des Wiederveröffentlichen von drahtlosen Komponent-anwendungen
EP1703387A1 (de) System und Verfahren zum Erzeugen einer entfaltbaren komponentbasierten Anwendung
Srinivasmurthy et al. Web2exchange: A model-based service transformation and integration environment
Smythe Initial Investigations into Interoperability Testing of Web Services from their Specification Using the Unified Modelling
CA2543501C (en) System and method for generating a web service definition and database schema from wireless application definition
EP1712994A1 (de) System und Verfahren zur Transformation einer Anwendungsdefinition
EP1978441A1 (de) System und Verfahren zur Aktualisierung des Bezugs auf eine Datenquelle in einer komponentenbasierten Anwendung

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