DE102012203463B4

DE102012203463B4 - Verfahren zur Bereitstellung von Web Services eines mobilen Web Service Providers

Info

Publication number: DE102012203463B4
Application number: DE102012203463A
Authority: DE
Inventors: Marc Jansen
Original assignee: Hochschule Ruhr West
Current assignee: Hochschule Ruhr West
Priority date: 2012-03-05
Filing date: 2012-03-05
Publication date: 2013-04-18
Anticipated expiration: 2032-03-06
Also published as: DE102012203463A1; US20150026245A1; WO2013131749A3; WO2013131749A2

Abstract

Die Erfindung schlägt die Bereitstellung eines Verfahrens für Web Services eines mobilen Web Service Providers vor. Das Verfahren weist einen Empfangsschritt einer Anfrage zur Registrierung eines Web Services von dem mobilen Web Service Provider und einen Registrierungsschritt des Services auf. Weiterhin weist das Verfahren einen Empfangsschritt einer Web Service Anfrage bezüglich des Web Services von einem Web Service Client und einen Prüfschritt. ob eine Antwort auf die Web Service Anfrage des Web Service Clients seitens des mobilen Web Service Providers vorliegt, auf. Falls eine Antwort vorliegt, wird die Antwort an den Web Service Client in einem weiteren Schritt weitergereicht. Weiterhin kann eine Anfrage des mobilen Web Service Providers, ob eine Web Service Anfrage vorliegt, in einem anderen Schritt erhalten werden. Das Verfahren kann in einem weiteren Schritt prüfen, ob eine Web Service Anfrage eines Web Service Clients vorliegt, die nicht beantwortet werden kann. Falls eine Web Service Anfrage eines Web Service Clients vorliegt, die nicht beantwortet werden kann, wird in einem weiteren Schritt die Web Service Anfrage an den Web Service Provider weitergeleitet.

Description

Hintergrund
Heutzutage werden webbasierte Dienste (sog. Web Services) verwendet, um eine Methodik zur Verfügung zu stellen, die in der Lage ist, plattformunabhängige Dienste bereitzustellen. Webbasierte Dienste bedeutet dabei die Bearbeitung von Anfragen und Rückgabe von Antworten im Sinne einer Machine-to-Machine Interaktion. Diese webbasierten Dienste erfordern jedoch eine direkte Erreichbarkeit, d. h. sie müssen ohne weiteres im Datennetz auffindbar sein. Leider sind jedoch webbasierte Dienste auf mobilen Kommunikationsendgeräten bislang nicht standardisiert. Dies liegt daran, dass diverse Probleme auftreten, wenn ein Dienst auf solch einem mobilen Gerät angeboten werden soll.
Eines der größten Probleme von Web Services auf mobilen Kommunikationsendgeräten ergibt sich aus der Tatsache, dass solche mobilen Geräte recht häufig ihr Netzwerk bzw. ihren Standort wechseln. Daher ist der Web Service, der auf einem solchen Gerät zur Verfügung gestellt wird, gewöhnlich nicht unter einer fixen Adresse verfügbar, was zu einer Vielzahl an Problemen auf der Seite des Dienstenachfragers eines solchen mobilen Web Services führt. Daneben sind solche mobilen Web Services gewöhnlich auch nicht permanent (sog. 24/7-Verfügbarkeit) verfügbar, da die mobilen Kommunikationsendgeräte, die solch einen mobilen Web Service anbieten, zwischenzeitlich ohne Netzempfang sein können oder von ihrem Benutzer auch ausgeschaltet werden können. Folglich können solch mobile Web Services nicht nur unter einer Vielzahl an verschiedenen Netzwerkadressen erreichbar sein, sondern entsprechend auch zeitweise gar nicht verfügbar sein.
US 2010/0211637 A1 , US 2005/0014489 A1 und US 2006/0200541 offenbaren Systeme, die es erlauben sollen, mobil-basierte Webserver bereitzustellen. Dabei werden Systeme beschrieben, die es erlauben bestimmte Dienste von unterschiedlichen mobilen Servern bereitzustellen, um so die Mobilität der Geräte zu nutzen. Jedoch lehren die Dokumente nicht, wie ein bestimmter Dienst auf einem bestimmten Gerät trotz wechselnder Adressen dauerhaft verfügbar gemacht werden kann.
Es wäre daher wünschenswert eine Lösung zu finden, die die Verfügbarkeit von solchen Web-Diensten auch für mobile Geräte ermöglicht und die oben Benannten Probleme berücksichtigt.
Die Anzahl der mobilen Kommunikationsendgeräte nimmt in den letzten Jahren stark zu und umfasst nicht nur leistungsfähige mobile Computer, wie Tablets, Net- und Notebooks. sondern auch Mobiltelefone. Entsprechend den IDC-Angaben aus 2011 existieren derzeit weltweit etwa 300 Millionen Smartphones, wobei die Tendenz rasch steigend ist. Insbesondere bezüglich der verwendeten Betriebssysteme der Smartphones stellt diese gewaltige Anzahl an Smartphones eine große Anzahl an heterogenen Geräten dar. Aktuell sind im Wesentlichen fünf verschiedene Betriebssysteme für Smartphones verbreitet, z. B. Symbian OS, Android, iOS, Blackberry und Windows Mobile, wobei jeweils diese Betriebssysteme in unterschiedlichen Versionen und Funktionsumfang anzutreffen sind. Eine betriebssystemspezifische Bereitstellung von Web-Services für jede Plattform in ihren unterschiedlichen Versionen stellt daher eine nahezu unbezwingbare Herausforderung dar.
Dementsprechend wäre ein plattformübergreifender Mechanismus für Dienste-Kommunikation wünschenswert, um nicht jeden Dienst für jedes der erwähnten Betriebssysteme neu implementieren zu müssen.
Kurzdarstellung der Erfindung
Es ist Ziel der Erfindung zumindest einige der zuvor erwähnten Nachteile zu vermieden und ein Verfahren zur Bereitstellung von Web Services eines mobilen Web Service Providers zur Verfügung zu stellen.
Die Erfindung löst die Aufgabe durch Bereitstellung eines Verfahrens für Web Services eines mobilen Web Service Providers. Das Verfahren weist einen Empfangsschritt einer Anfrage zur Registrierung eines Web Services von dem mobilen Web Service Provider und einen Registrierungsschritt des Services auf. Weiterhin weist das Verfahren einen Empfangsschritt einer Web Service Anfrage bezüglich des Web Services von einem Web Service Client und einen Prüfschritt, ob eine Antwort auf die Web Service Anfrage des Web Service Clients seitens des mobilen Web Service Providers vorliegt, auf. Falls eine Antwort vorliegt, wird die Antwort an den Web Service Client in einem weiteren Schritt weitergereicht. Weiterhin kann eine Anfrage des mobilen Web Service Providers, ob eine Web Service Anfrage vorliegt, in einem anderen Schritt erhalten werden. Das Verfahren kann in einem weiteren Schritt prüfen, ob eine Web Service Anfrage eines Web Service Clients vorliegt, die nicht beantwortet werden kann. Falls eine Web Service Anfrage eines Web Service Clients vorliegt, die nicht beantwortet werden kann, wird in einem weiteren Schritt die Web Service Anfrage an den mobilen Web Service Provider weitergeleitet.
Durch die erfindungsgemäße lehre wird der Vorteil erreicht, dass Web Service Anfragen eines Web Service Clients, die nicht unmittelbar vom mobilen Web Service Provider beantwortet werden können, zwischengespeichert werden, um diese dem mobilen Web Service Provider zu übermitteln, sobald er sich wieder meldet, d. h. der mobile Web Service Provider wieder erreichbar ist.
Damit ist es nicht mehr notwendig, dass ein mobiler Web Service Provider unter einer Netzwerkadresse 24/7 erreichbar ist. Weiterhin kann ein mobiler Web Service auch dann angefordert werden, wenn die Netzwerkadresse häufig wechselt, wie es bei mobilen Kommunikationsendgeräten häufig der Fall ist, oder wenn ein mobiles Kommunikationsendgerät, welches solch einen mobilen Web Service anbietet, nicht in einem Netzwerk eingebucht ist oder sogar ausgeschaltet ist.
Das Verfahren kann dabei beispielsweise in einer sog. Middleware implementiert werden, die entweder eine Komponente des mobilen Netzwerkes oder aber eines anderen mit diesem in Verbindung stehenden auch fixen Netzwerkes sein kann, wobei die Middleware über eine bekannte Adresse erreichbar, z. B. über eine öffentliche IP-Adresse, ist.
Das Speichern der Web Service Anfrage, kann dabei beispielsweise in einem zentralen Proxyserver erfolgen, damit diese nicht verloren geht und dem mobilen Kommunikationsendgerät welches den betreffenden Web Service anbietet übermittelt, nachdem sich das entsprechende mobile Kommunikationsendgerät beim zentralen Proxyserver wieder gemeldet hat und diesen nach Web Service Anfragen nachfragt.
Damit ist ein weiterer Vorteil, dass der mobile Web Service Provider als Web Service Client mit einem dynamisch generierten Web Service Proxy kommunizieren kann und nicht wie bislang üblich, Serverseitige Funktionalitäten in den jeweiligen mobilen Kommunikationsendgeräten implementiert werden müssen. Das bedeutet, dass von der netzwerktechnischen Seite her betrachtet, keine Serverinstanz auf dem mobilen Kommunikationsendgerät installiert sein muss. Das bedeutet, dass ein Web Service Client nicht direkt den Web Service des mobilen Web Service Providers anfragt, sondern stattdessen einen zentral verfügbaren Proxy. Der Web Service, der auf dem mobilen Web Service Provider läuft, fragt dann in regelmäßigen oder auch unregelmäßigen Abständen den Proxy Server nach neuen den Web Service betreffenden Nachrichten ab.
Damit entfällt das Problem einer potentiell wechselnden Netzwerkadresse, da der mobile Web Service Provider lediglich wie ein Client auf Seite des Proxy-Servers auftritt.
Der zentrale Web Service Proxy kann dabei beispielsweise dynamisch für jeden Web Service der auf einem mobilen Web Service Provider zum Einsatz kommt, einen Proxy implementieren. Damit kann der so implementierte Proxy Service Anfragen als Stellvertreter des aktuellen Services entgegennehmen und diese Anfragen zusammen mit notwendigen zugehörigen Daten zwischenspeichern, bis der entsprechende Web Service des mobilen Web Service Providers diese Anfragen am entsprechenden Proxy nachfragt und von diesem diese Anfragen gemeinsam mit den notwendigen zugehörigen Daten entgegennimmt. Sodann kann der mobile Web Service Provider den betreffenden Web Service bereitstellen und die Antwort an den Web Service Proxy zurücksenden, damit dieser wiederum die empfangene Antwort an den ursprünglich anfragenden Web Service Client weiterleitet.
Solch eine Antwort kann das Resultat eines erfolgreich in Anspruch genommenen Web Services sein, als auch der Web Service selbst, bzw. Daten und Anwendungen oder Apps, die der Web Service verwaltet, bzw. anbietet.
Web Services sind dabei Dienste, die üblicherweise als Webdienste zur Verfügung gestellt werden. Dies können sowohl Kommunikationsdienste sein, wie auch beliebige andere Dienste, jedoch auch Dateien, Anwendungen, Apps, Ergebnisse einer Berechnungsanfrage, Ergebnisse von Lokalisierungsanfragen, Rechercheergebnisse, etc.
Die Daten, die der Web Service Proxy Server speichert, können dabei sowohl in einer Datei, relationalen Datenbank oder sonst in eindeutig wiederauffindbarer Weise, z. B. in einer externen Datenbank oder internen Datenbank, gespeichert werden.
Das Speichern der Daten selbst kann dabei sowohl physikalisch auf dem Proxy-Server geschehen, als auch dezentral, z. B. in einem ausgelagerten Datenbankserver, einer Cloud oder ähnlichem.
Ein mobiler Web Service Provider ist bevorzugt ein sog. Smartphone, kann jedoch auch jedes andere mobile Kommunikationsendgerät sein, das in der Lage ist, Web Services anzubieten, wie beispielsweise ein nicht Touch-fähiges Mobilfunk Kommunikationsendgerät oder ein sonstiger Rechner mit wechselnden Adressen. Besonders bevorzugt handelt es sich bei einem mobilen Web Service Provider jedoch neben einem Smartphone auch noch um einen mobilen Computer, z. B. in Form eines Tablets, eines Notebooks, eines Pads, oder ähnlichem. Solch ein mobiler Computer kann jedoch beispielsweise auch ein Embedded System sein, welches in einem Fahrzeug mobil oder auch fest eingebaut ist, z. B. eine sog. On Board Unit (OBU) oder ein sonstiges mobiles Kommunikationsendgerät oder mobiler Computer, das in der Lage ist, ein drahtloses Funk- und/oder Datennetzwerk zu benutzen, bevorzugt jedoch ein WLAN Netzwerk, ein WiMAX-Netzwerk oder ein WiFi-Netzwerk, besonders bevorzugt ein Mobilfunk Netzwerk. Das Mobilfunk Netzwerk kann dabei ein beliebiges Mobilfunknetzwerk, z. B. ein GSM, GSM-R, UMTS, LTE, iDEN-Netzwerk sein. Insbesondere können dies Mobilfunktechnologie Netze der zweiten, dritten, vierten und künftigen Generationen sein, ganz allgemein jedoch Mobilfunktechnologien, wie sie beispielsweise in den Standards von DECT und Bluetooth als auch für WLAN, benutzt werden. Darüber hinaus sind auch Netze umfasst, die für ”short-range-radio” oder ”ZigBee” genutzt werden oder für deren Nutzung geeignet sind.
Wichtiges Kriterium für ein solches Kommunikationsendgerät oder solch einen mobilen Computer ist es, dass es sich in einem Netzwerk ein buchen kann, in welchem es die Netzwerkadresse häufig ändert, bzw. häufig ändern kann, wie dies beispielsweise in einem Mobilfunk-Netz der Fall ist.
Ein Web Service Client kann dabei jeder beliebige netzwerkfähige Computer sein, insbesondere aber auch ein mobiles Kommunikationsendgerät wie im vorherigen Abschnitt beschrieben.
Registrierung eines Web Services bedeutet, dass ein von einem mobilen Web Service Provider zur Verfügung gestellter Web Service dem zentralen Proxyserver bekannt gemacht wird, so dass dieser zentrale Proxyserver bei einer Anfrage eines Web Service Clients erkennen kann, welcher Web Service von dem Client nachgefragt wird und welcher mobile Web Service Provider diesen Web Service zur Verfügung stellt. Dabei können verschiedene mobile Web Service Provider ein und denselben Web Service anbieten, wie auch ein mobiler Web Service Provider mehrere verschiedene Web Services anbieten kann.
In einer besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass die Antwort vor der Weiterleitung auf Gültigkeit geprüft wird.
Dies hat den Vorteil, dass nicht mehr aktuelle oder anderweitig nicht mehr benötigte Web Service Antworten nicht an den Web Service Client weitergereicht werden.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass die Antwort vor der Weiterleitung auf zeitliche und/oder räumliche Gültigkeit geprüft wird.
Dies hat den Vorteil, dass keine ungültigen Web Service Antworten an den Web Service Client weitergereicht werden. Ungültig können dabei räumlich und/oder zeitlich nicht mehr aktuelle Web Service Antworten sein.
Dabei bedeutet räumliche Gültigkeit, dass abhängig von der Position des mobilen Web Service Providers, eine Antwort ungültig geworden sein kann, falls die aktuelle Position des mobilen Web Service Providers zum Zeitpunkt des Versendens der Antwort der Web Service Anfrage eines Clients an die Middleware, räumlich außerhalb eines vorgegeben Bereiches liegt und somit Positionsbezogen irrelevant geworden ist.
Die zeitliche Gültigkeitsprüfung kann bei Benutzung eines Proxy Servers als Middleware beispielsweise auf einem Zeitstempel basieren (sog. lifetime), der auf dem Proxy vorgehalten wird. Es kann sich jedoch beispielsweise auch um ein Timeframe o. ä. handeln, während dessen die Web Service Antwort ihre Gültigkeit behält. Auch kann als Gültigkeit ein Countdown bestimmt werden, z. B. 20 min., bis zu dem die Web Service Antwort als relevant erachtet wird. Es ist auch möglich beispielsweise einen einmaligen Stempel zu vergeben, so dass eine Web Service Antwort beispielsweise nur ein einziges Mal ihre Gültigkeit behält, z. B. in dem die lifetime auf 0 gesetzt wird. Es sind verschiedenste Realisierungen der Gültigkeit und-Gültigkeitsprüfung für solch eine Web Service Antwort möglich, die alle zum Ziel haben, dafür Sorge zu tragen, dass keine ungültigen, d. h. veralteten, Web Service Antworten an den Web Service Client weitergereicht werden.
Auch ist es möglich solch eine Gültigkeit derart zu implementieren, dass nur nicht räumlich und/oder zeitlich veraltete Web Service Anfragen an den mobilen Web Service Provider weitergeleitet werden, oder für den Fall des Gültigkeitsablaufs der Web Service Antwort diese erst gar nicht mehr an die Middleware gesendet wird, oder diese die Antwort gar nicht erst annimmt, oder sofort als ungültig verwirft. Dabei können die Gültigkeitsregeln/-kriterien grundsätzlich sowohl vom Web Service Client als auch vom mobilen Web Service Provider vorgegeben oder vorgeschlagen werden.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass eine Antwort des mobilen Web Service Providers gespeichert wird.
Dies hat den Vorteil, dass die Antwort des mobilen Web Service Providers beispielsweise im Falle eines Systemausfalls oder einer temporären Nichterreichbarkeit des Web Service Clients erneut an den Web Service Client versandt werden kann, und so sichergestellt werden kann, dass der Web Service Client die von ihm angeforderte Web Service Antwort auch erhält. Zudem kann erreicht werden, dass gleiche Anfragen nicht erneut vom mobilen Endgerät beantwortet werden müssen.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass eine Antwort des mobilen Web Service Providers nur für eine gewisse Zeit gültig ist.
Dies hat den Vorteil, dass keine zeitlich veralteten Web Service Antworten an den Web Service Client weitergereicht werden.
Ein weiterer Vorteil ist, dass der Web Service Client durch die Middleware darüber informiert werden kann, dass eine nicht mehr gültige Antwort vorliegt und/oder diesen Client auffordert, seine Anfrage erneut und evtl. auch aktualisiert zu senden.
Die gewisse Zeit bedeutet dabei ein zeitliches Kriterium, nach dem entschieden wird, wie lange eine Antwort des mobilen Web Service Providers gültig ist. Die gewisse Zeit kann jedoch auch ein zeitlicher Rahmen sein, in welcher die Antwort ihre Gültigkeit behält. Stellt die Middleware fest, dass zwischen der Anfrage des Web Service Clients und der Antwort des mobilen Web Service Providers diese gewisse Zeit verstrichen ist, kommt die Gültigkeitsprüfung zu dem Ergebnis, dass die Antwort des mobilen Web Service Providers nicht an den Web Service Client weitergeleitet werden soll.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass eine Antwort des mobilen Web Service Providers nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Antwort enthalten ist.
Dies hat den Vorteil, dass die Kommunikation zwischen dem mobilen Web Service Provider und der Middleware minimiert werden kann, da die gewisse Zeit bereits als Parameter in der Antwort enthalten ist und nicht mehr bei Bedarf von der Middleware vom mobilen Web Service Provider angefordert werden muss.
Ein weiterer Vorteil ist, dass damit die Gültigkeitsprüfung auf der Middleware vereinfacht werden kann, da ein Teil der Gültigkeitskriterien damit bereits vom mobilen Web Service Provider bereitgestellt werden und im Bedarfsfall verwendet werden können.
Ein weiterer Vorteil ist, dass dadurch, dass die gewisse Zeit vom mobilen Web Service Provider vorgegeben wird, die gewisse Zeit dynamisch ist, was bedeutet, dass jeder Web Service eines mobilen Web Service Providers eine eigene gewisse Zeit vorhält, bzw. bestimmt, die möglicherweise von der gewissen Zeit eines anderen Web Services des selben oder auch eines anderen mobilen Web Service Providers abweichen kann.
Die gewisse Zeit kann dabei auch keine Verwendung finden und/oder keine Relevanz haben, falls bereits ohne diese Information die Gültigkeitsprüfung auf der Middleware ergibt, dass die Antwort nicht an den Web Service Client weitergeleitet werden soll, z. B. aufgrund der bereits erfolgten räumlichen Gültigkeitsprüfung, die bereits das Ergebnis liefert, dass die Antwort nicht mehr gültig ist.
Ebenso ist dies andersherum möglich, also dass bereits die zeitliche Gültigkeitsprüfung ergeben hat, dass die Antwort keine Gültigkeit mehr hat.
Auch sind weitere Gültigkeitsprüfungen, bzw. Gültigkeitsprüfungskriterien möglich.
Eine zeitliche Gültigkeitsprüfung kann dabei im Verbund mit einer räumlichen Gültigkeitsprüfung erfolgen, jedoch können auch beide vollständig losgelöst voneinander geprüft werden. Auch ist es insbesondere nicht notwendig, dass beide Kriterien für die Gültigkeitsprüfung der Antwort, also räumliches und zeitliches Kriterium gemeinsam implementiert sind, sondern es kann auch lediglich nur eine der beiden Kriterien implementiert sein, um eine Gültigkeitsprüfung der Antwort vorzunehmen.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass eine Antwort des mobilen Web Service Providers nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Registrierungsanfrage enthalten ist.
Dies hat den Vorteil, dass bereits bei Registrierungsanfrage die gewisse Zeit für den zu registrierenden Web Service und/oder mobilen Web Service Providers der Middleware bekannt gegeben wird, wodurch die Middleware bereits bei Registrierung des Web Services und/oder des mobilen Web Service Providers anhand der Gültigkeitsprüfung bestimmen kann, ob evtl. für diesen Web Service und/oder mobilen Web Service Provider anstehende Anfragen als veraltet verworfen werden und somit erst gar nicht mehr an den mobilen Web Service Provider übertragen werden müssen. Dies kann den Datenverkehr zwischen dem mobilen Web Service Provider und der Middleware weiter minimieren.
Registrierungsanfrage bedeutet dabei, dass der mobile Web Service Provider sich bei der Middleware erstmals oder aktualisierend anmeldet, um seine Web Services oder auch nur einige seiner Web Services der Middleware bekannt zu machen, Änderungen an seinen Web Service bekannt zu geben oder Web Services auch wieder bei der Middleware abzumelden. Dazu kann der mobile Web Service Provider notwendige Rahmendaten hierzu übermitteln, damit die Middleware in die Lage versetzt wird zu bestimmen, wohin eine bestimmte Web Service Anfrage eines Web Service Clients weitergeleitet werden soll und/oder wie mit der betreffenden Web Service Anfrage umgegangen werden soll. In solch einer Registrierungsanfrage können bereits auch Gültigkeitskriterien für die räumliche und/oder zeitliche Prüfung bzw. weitere Gültigkeitskriterien enthalten sein.
In einer weiteren besonders vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass das Verfahren weiterhin die Schritte aufweist: Versenden einer Autorisierungsanfrage an den Web Service Client; erhalten einer Autorisierungsantwort des Web Service Clients: prüfen der Autorisierungsantwort, und falls die Autorisierung erfolgreich war, Empfang von Web Service Anfragen des Webclients zulassen.
Dies hat den Vorteil, dass nur derjenige Web Service Client, der autorisiert ist, Web Service Anfragen an den mobilen Web Service Provider zu stellen, seine Anfragen an die Middleware richten darf. Dadurch werden nichtautorisierte Übertragungen verhindert, was den Datenverkehr sowohl zwischen dem Web Service Client und der Middleware als auch den Datenverkehr zwischen der Middleware und dem mobilen Web Service Provider noch weiter minimieren kann.
Autorisierung bedeutet dabei, dass durch Mitteilung des betreffenden Web Service Clients auf der Middleware bestimmt werden kann, ob dieser Web Service Client berechtigt ist, den von ihm angefragten Web Service in Anspruch zu nehmen. Um die Berechtigung zu überprüfen oder zu bestimmen kann es dabei evtl. auch erforderlich sein, dass der mobile Web Service Provider der Middleware Berechtigungen oder Berechtigungskriterien mitteilt, anhand derer die Middleware entscheiden kann, ob der betreffende Web Service Client den angefragten Web Service in Anspruch nehmen darf oder nicht.
Solche Kriterien können beispielsweise Altersbeschränkungen, ein gültiges Abonnement oder gültige Bezahlung des angefragten Web Services sein, genauso wie geographische wie auch zeitliche Kriterien. Es sind jedoch eine Vielzahl an weiteren Kriterien denkbar, anhand derer eine Autorisierung bestimmt und/oder ermittelt werden kann.
Figurenkurzbeschreibung
Die Erfindung wird nachfolgend eingehender an Hand der Figuren erläutert werden, in diesen zeigt
1 einen schematischen Aufbau einer ”Use Case” Beschreibung einer Middleware gemäß Aspekten der Erfindung,
2 einen schematischen Aufbau eines UML-(Unified Modeling Language-)Sequenz Diagramms der Kommunikation zwischen dem mobilen Web Service Provider und dem Web Service Client gemäßen Aspekten der Erfindung,
3 einen schematischen Aufbau eines Sequenz Diagramms einer Web Service Anfrage und Antwort gemäß Aspekten der Erfindung,
4 eine beispielhafte, simple Implementierung eines möglichen Web Services gemäß Aspekten der Erfindung, und
5 einen schematischen Aufbau eines UML Klassen Diagramms von Teilaspekten einer beispielhaften Implementierung der Funktionsweise eines mobilen Web Service Providers, eines Proxys als Middleware und der Kommunikation zwischen diesen gemäß Aspekten der Erfindung.
Ausführliche Darstellung der Erfindung
Bevor nachfolgend Ausführungsformen der Erfindung eingehender beschrieben werden, ist zunächst festzuhalten, dass die Erfindung nicht auf die beschriebenen Komponenten oder die beschrieben Verfahrensschritte beschränkt ist. Weiterhin stellt auch die verwendete Terminologie keine Einschränkung dar, sondern hat lediglich beispielhaften Charakter. Soweit nachfolgend in der Beschreibung und den Ansprüchen der Singular verwendet wird, ist dabei jeweils der Plural mit umfasst, soweit der Kontext dies nicht explizit ausschließt.
In 1 ist ein schematischer Aufbau einer ”Use Case” Beschreibung einer Middleware gemäß Aspekten der Erfindung dargestellt.
Beispielhaft nehmen vier verschiedene Teilnehmer in dem Szenario teil, bestehend aus einem Web Service Client (ws_client), welcher Dienste nachfragt, einem mobilen Web Service Provider (ws_provider), der Dienste anbietet, einem Web Service Proxy (ws_proxy) der Anfragen vom Client (ws_client) entgegennimmt, an den Provider (ws_provider) weiterleitet und dessen Antwort wiederum an den Client (ws_client) weiterleitet und einer Datenbank (database), in welcher Daten der Clientanfrage (serviceReq) wie auch Daten der Providerantwort serviceReqRes) und evtl. sonstige Daten hinterlegt werden können. Dabei bilden der Web Service Proxy (ws_proxy) und die Datenbank (database) Kernbestandteile der Middleware.
Auf der Anbieterseite, dem Web Service Provider (ws_provider) läuft dabei eine Software, die den eigentlichen Web Service zur Verfügung stellt. Diese Software kann in einem Szenario, in welchem der Web Service von einem gewöhnlichen Server System angeboten wird, am besten verglichen werden mit einem Anwendungsserver, der einen Web Service anbietet.
Auf der Konsumentenseite, dem Web Service Client (ws_client) läuft dabei eine Software, die Web Service Anfragen vornimmt, d. h. es handelt sich beispielsweise um eine Machine to Machine Interaction (MMI).
Gemäß der Erfindung ist zwischen der Konsumentenseite und der Anbieterseite eine Middleware (ws_proxy, database) zwischengeschaltet, wobei der Proxy Server (ws_proxy) bevorzugt mit den gleichen Interfaces implementiert ist, wie der mobile Web Service Provider (ws_provider). Darüber hinaus können auch Interfaces und Methoden, die vom Proxy Server (ws_proxy) zur Verfügung gestellt werden, um beispielsweise den Web Service an- und abzumelden und dergleichen, über Standard Netzwerkprotokolle für Web Services wie beispielsweise SOAP (Simple Object Access Protocol) ansprechbar sein, und die Beschreibung der Interfaces könnte beispielsweise mittels WSDL (Web Services Description Language) erfolgen.
Es ist eine Aufgabe des Proxy Servers (ws_proxy), Clientanfragen (serviceReq) zu erhalten, diese Clientanfragen soweit nötig in einer Datenbank oder anderweitig zu speichern und darauf zu warten, dass der mobile Web Service Provider (ws_provider) die Anfragen (serviceReq) abruft und zugehörige Antworten (serviceReqRes) zurücksendet.
Dadurch dass der Proxy Server (ws_proxy) nicht selbständig aktiv wird und daher nicht versucht die erhaltenen Anfragen (serviceReq) an den mobilen Web Service Provider (ws_provider) zu versenden, sog. ”push-Verfahren”, ist es möglich, auf einfache Weise die Problematik der ständig wechselnden Netzwerkverbindungen und dem damit verbundenen Wechsel der Netzwerkadressen des mobilen Web Service Providers (ws_provider) zu umgehen, da der Web Service Provider (ws_provider) sich selbständig, z. B. in vorbestimmten Zeitintervallen, beim Proxy Server (ws_proxy) meldet und die an ihn gerichteten Anfragen (serviceReq) nachfragt, sog. ”pull-Verfahren”. D. h. der mobile Web Service Provider (ws_provider) pollt den Proxy Server (ws_proxy) nach neuen Anfragen. Denn dadurch müssen weder der Web Service Client (ws_client), noch der Proxy Server (ws_proxy) die aktuelle IP-Adresse des mobilen Web Service Providers (ws_provider) kennen.
Es ist eine Aufgabe der Datenbank (database), die benötigten Informationen einer Clientanfrage (serviceReq) zu sichern, um es dem entsprechenden Web Service zu erlauben, die an ihn gestellte Anfrage (serviceReq) zu bearbeiten und eine entsprechende Antwort (serviceReqRes) zu ermitteln, die dann wiederum von der Datenbank (database) gesichert werden kann, um sie dann über den Proxy Server (ws_proxy) an den Web Service Client (ws_client) weiter zu leiten. Dies ist von Vorteil, da durch diese Vorgehensweise auch der mobile Web Service Provider (ws_provider) die IP-Adresse des Web Service Clients (ws_client) in aller Regel nicht kennt und somit lediglich der Proxy Server (ws_proxy) selbst, die Antwort (serviceReqRes) an den Client (ws_client) versenden kann. Letzteres kann in gewöhnlicher Weise im ”push-Verfahren” geschehen.
Neben diesen exemplarischen vier Teilnehmern (ws_client, ws_provider, ws_proxy, database) sind noch weitere Implementierungen von Anwendungsfällen möglich. Zunächst kann ein mobiler Web Service Provider (ws_provider) in der Lage sein, einen angebotenen Dienst am Proxy Server (ws_proxy) anzumelden (regService). Neben dem mobilen Web Service Provider (ws_provider) interagieren in diesem Anwendungsfall der Proxy Server (ws_proxy) selbst, als auch die Datenbank (database).
Der Proxy Server (ws_proxy) kann das Interface des Web Service dynamisch implementieren, sowie das Speichern von Metadaten der Web Service Anfragen (serviceReq) vornehmen. Solche Metadaten bestehen hauptsächlich aus der aufzurufenden Methode und der von ihr benötigten Parameter.
Die Datenbank (database) kann Speicherplatz vorhalten, um die Parameterwerte einer jeden Methode und zugehöriger Rückgabewerte für jeden mobilen Web Service zu speichern.
Ein weiterer Anwendungsfall ist, dass der mobile Web Service Provider (ws_provider) in der Lage sein soll, Serviceanfragen zu erhalten (rec serviceReq). In diesem Anwendungsfall nimmt auch der Proxy Server (ws_proxy) teil, denn der Proxy Server ist die Instanz, die die Anfragen (serviceReq) von den Web Service Clients (ws_client) entgegennimmt und die benötigten Informationen in der Datenbank (database) speichert. In diesem Anwendungsfall nehmen des Weiteren noch zwei andere Anwendungsfälle teil, nämlich der Anwendungsfall, in dem die Metadaten der Serviceanfragen (serviceReq) gespeichert (str serviceReqMeta) werden und der Anwendungsfall, in dem die Serviceanfragen (serviceReq) ausgeführt (perf serviceReq) werden. Der Anwendungsfall, in dem die Metadaten der Serviceanfragen (serviceReq) gespeichert werden (str serviceReqMeta) interagiert mit dem Teilnehmer mobiler Web Service Provider (ws_provider) und dem Teilnehmer Datenbank (database), während der Anwendungsfall, in dem die Serviceanfragen (serviceReq) ausgeführt werden (perf serviceReq) lediglich mit dem Web Service Client (ws_client) interagiert, was einen großen Vorteil gegenüber dem Stand der Technik darstellt.
Der Anwendungsfall, in dem die Antworten (serviceReqRes) verwaltet werden, (str serviceReqRes) interagiert mit den Teilnehmern mobiler Web Service Provider (ws_provider), Proxy Server (ws_proxy) und Datenbank (database).
Der Letzte in der 1 gezeigte Anwendungsfall ist derjenige, in dem Antworten (serviceReqRes) vom Proxy Server (ws_proxy) erhalten werden (rec serviceReqRes) und (nur) mit den beiden Teilnehmern Proxy Server (ws_proxy) und Web Service Client (ws_client) interagiert wird.
Der Web Service Client (ws_client) ist somit vollständig von den Teilnehmern Datenbank (database) und mobiler Web Service Provider (ws_provider) gekapselt, was sehr vorteilhaft ist, da so gewährleistet ist, dass der Web Service Client (ws_client) nur mit demjenigen Teil der Middleware (ws_proxy) kommuniziert, dem er Anfragen (serviceReq) zusendet und von dem er Antworten (serviceReqRes) erhält. Somit sieht es von der Clientseite (ws_client) so aus, also ob die mobile Web Service Anfrage (serviceReq) nichts weiter ist, als eine gewöhnliche Serviceanfrage. Dadurch ist kein zusätzlicher Aufwand auf der Clientseite (ws_client) notwendig, um Serviceanfrageergebnisse von einem Web Service zu erhalten, der auf einem mobilen Kommunikationsendgerät läuft.
Das Verfahren kann dabei beispielsweise in einer sog. Middleware (ws_proxy, database) implementiert werden, die entweder eine Komponente des mobilen Netzwerkes oder aber eines anderen mit diesem in Verbindung stehenden auch fixen Netzwerkes sein kann.
Das Speichern der Web Service Anfrage (str serviceReqMeta), kann dabei beispielsweise in einem zentralen Proxyserver (ws_proxy) erfolgen, damit diese nicht verloren geht und dem mobilen Kommunikationsendgerät welches den betreffenden Web Service anbietet (ws_provider) übermittelt, nachdem sich das entsprechende mobile Kommunikationsendgerät (ws_provider) beim zentralen Proxyserver (ws_proxy) wieder gemeldet hat und diesen nach Web Service Anfragen (serviceReq) nachfragt.
Damit ist ein weiterer Vorteil, dass der mobile Web Service Provider (ws_provider) als Web Service Client mit einem dynamisch generierten Web Service Proxy (ws_proxy) kommunizieren kann und nicht wie bislang üblich, Serverseitige Funktionalitäten in den jeweiligen mobilen Kommunikationsendgeräten implementiert werden müssen. Das bedeutet, dass von der netzwerktechnischen Seite her betrachtet, keine Serverinstanz auf dem mobilen Kommunikationsendgerät (ws_provider) installiert sein muss. Das bedeutet, dass ein Web Service Client (ws_client) nicht direkt den Web Service des mobilen Web Service Providers (ws_provider) anfragt, sondern stattdessen einen zentral verfügbaren Proxy (ws_proxy). Der Web Service der auf dem mobilen Web Service Provider (ws_provider) läuft, fragt dann in regelmäßigen oder auch unregelmäßigen Abständen den Proxy Server (ws_proxy) nach neuen den Web Service betreffenden Nachrichten (serviceReq) ab.
Damit entfällt das Problem einer potentiell wechselnden Netzwerkadresse, da der mobile Web Service Provider (ws_provider) lediglich wie ein Client auf Seite des Proxy-Servers (ws_proxy) auftritt.
Der zentrale Web Service Proxy (ws_proxy) kann dabei beispielsweise dynamisch für jeden Web Service der auf einem mobilen Web Service Provider (ws_provider) zum Einsatz kommt, einen Proxy (ws_proxy) implementieren. Damit kann der so implementierte Proxy Service (ws_proxy) Anfragen (serviceReq) als Stellvertreter des aktuellen Services entgegennehmen und diese Anfragen (serviceReq) zusammen mit notwendigen zugehörigen Daten zwischenspeichern (str serviceReqMeta), bis der entsprechende Web Service des mobilen Web Service Providers (ws_provider) diese Anfragen (serviceReq) am entsprechenden Proxy (ws_proxy) nachfragt und von diesem diese Anfragen (serviceReq) gemeinsam mit den notwendigen zugehörigen Daten entgegennimmt. Sodann kann der mobile Web Service Provider (ws_provider) den betreffenden Web Service ausführen und die Antwort (serviceReqRes) an den Web Service Provider (ws_provider) zurücksenden, damit dieser wiederum die empfangene Antwort (serviceReqRes) an den ursprünglich anfragenden Web Service Client (ws_client) weiterleitet.
Auch kann eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) gespeichert werden.
Dies hat den Vorteil, dass die Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) beispielsweise im Falle eines Systemausfalls oder einer temporären Nichterreichbarkeit des Web Service Clients (ws_client) erneut an den Web Service Client (ws_client) versandt werden kann, und so Sichergestellt werden kann, dass der Web Service Client (ws_client) die von ihm angeforderte Web Service Antwort (serviceReqRes) auch erhält.
Solch eine Antwort (serviceReqRes) kann das Resultat eines erfolgreich in Anspruch genommenen Web Services sein, als auch der Web Service selbst, bzw. Daten und Anwendungen oder Apps die der Web Service verwaltet, bzw. anbietet.
Web Services sind dabei Dienste, die üblicherweise als Webdienste zur Verfügung gestellt werden. Dies können sowohl Kommunikationsdienste sein, wie auch beliebige andere Dienste, jedoch auch Dateien, Anwendungen, Apps, Ergebnisse einer Berechnungsanfrage, Ergebnisse von Lokalisierungsanfragen, Rechercheergebnisse, etc.
Die Daten, die der Web Service Proxy Server (ws_proxy) speichert (str serviceReqMeta, str serviceReqRes), können dabei sowohl in einer Datei, relationalen Datenbank (database) oder sonst in eindeutig wiederauffindbarer Weise gespeichert werden.
Das Speichern der Daten (str serviceReqMeta, str serviceReqRes) selbst kann dabei sowohl physikalisch auf dem Proxy-Server (ws_proxy) geschehen, als auch dezentral, z. B. in einem ausgelagerten Datenbankserver (database), einer Cloud oder ähnlichem.
Ein mobiler Web Service Provider (ws_provider) ist bevorzugt ein sog. Smartphone, kann jedoch auch jedes andere mobile Kommunikationsendgerät sein, das in der Lage ist, Web Services anzubieten, wie beispielsweise ein nicht Touch-fähiges Mobilfunk Kommunikationsendgerät oder ein sonstiger Rechner mit wechselnden Adressen. Besonders bevorzugt handelt es sich bei einem mobilen Web Service Provider (ws_provider) jedoch neben einem Smartphone auch noch um einen mobilen Computer, z. B. in Form eines Tablets, eines Notebooks, eines Pads, oder ähnlichem. Solch ein mobiler Computer kann jedoch beispielsweise auch ein Embedded System sein, welches in einem Fahrzeug mobil oder auch fest eingebaut ist, z. B. eine sog. On Board Unit (OBU) oder ein sonstiges mobiles Kommunikationsendgerät oder mobiler Computer, das in der Lage ist, ein drahtloses Funk- und/oder Datennetzwerk zu benutzen, bevorzugt jedoch ein WLAN Netzwerk, ein WiMAX-Netzwerk oder ein WiFi-Netzwerk, besonders bevorzugt ein Mobilfunk Netzwerk. Das Mobilfunk Netzwerk kann dabei ein beliebiges Mobilfunknetzwerk, z. B. ein GSM, GSM-R, UMTS, LTE, iDEN-Netzwerk. Insbesondere können dies Mobilfunktechnologie Netze der zweiten, dritten, vierten und künftigen Generationen sein, ganz allgemein jedoch Mobilfunktechnologien, wie sie beispielsweise in den Standards von DECT und Bluetooth als auch für WLAN, benutzt werden. Darüber hinaus sind auch Netze umfasst, die für „short-range-radio” oder „ZigBee” genutzt werden oder für deren Nutzung geeignet sind.
Wichtiges Kriterium für ein solches Kommunikationsendgerät oder solch einen mobilen Computer ist es, dass es sich in einem Netzwerk einbuchen kann, in welchem es die Netzwerkadresse häufig ändert, bzw. häufig ändern kann, wie dies beispielsweise in einem Mobilfunk-Netz der Fall ist.
Ein Web Service Client (ws_client) kann dabei jeder beliebige netzwerkfähige Computer sein, insbesondere aber auch ein mobiles Kommunikationsendgerät wie im vorherigen Abschnitt beschrieben.
Registrierung eines Web Services (regService) bedeutet, dass ein von einem mobilen Web Service Provider (ws_provider) zur Verfügung gestellter Web Service dem zentralen Proxyserver (ws_proxy) bekannt gemacht wird, so dass dieser zentrale Proxyserver (ws_proxy) bei einer Anfrage (serviceReq) eines Web Service Clients (ws_client) erkennen kann, welcher Web Service von dem Client (ws_client) nachgefragt wird und welcher mobile Web Service Provider (ws_provider) diesen Web Service zur Verfügung stellt. Dabei können verschiedene mobile Web Service Provider (ws_provider) ein und denselben Web Service anbieten, wie auch ein mobiler Web Service Provider (ws_provider) mehrere verschiedene Web Services anbieten kann.
In 2 ist ein schematischer Aufbau einer beispielhaften UML-Sequenz Diagramms der Kommunikation zwischen dem mobilen Web Service Provider und dem Web Service Client gemäßen Aspekten der Erfindung dargestellt.
Als erstes meldet der mobile Web Service Provider (ws_provider) seinen Web Service bei dem Proxy Server (ws_proxy) an (regService). Als Teil dieses Registrierungsprozesses erzeugt der Proxy Server (ws_proxy) die benötigte Datenstruktur, um an den Web Service gerichtete Web Service Anfragen (serviceReq) in der Datenbank (database) speichern zu können. Nachdem der mobile Web Service Provider (ws_provider) seinen Service angemeldet hat, fragt er den Proxy Server (ws_proxy) in bestimmten Zeitabständen, z. B. regelmäßig, evtl. auch permanent oder in bestimmten Zeitintervallen, nach neuen für ihn vorliegende Anfragen (serviceReq) ab. Der Proxy Server (ws_proxy) fragt die Datenbank (database) dann ab, ob eine neue Web Service Anfrage (serviceReq) für den anfragenden mobilen Web Service Provider (ws_provider) vorliegt und falls dem so ist, sendet er die Metadaten der vorliegenden Anfrage an den entsprechenden mobilen Web Service Provider (ws_provider). Nach Erhalt dieser Daten führt der mobile Web Service Provider (ws_provider) den Service aus und sendet das Ergebnis als Antwort (serviceReqRes) an den Proxy Server (ws_proxy) zurück, der die Antwort (serviceReqRes) dann in der Datenbank (database) speichert. Danach ist der Proxy Server (ws_proxy) in der Lage die Antwort (serviceReqRes) der entsprechenden Web Service Anfrage (serviceReq) aus der Datenbank (database) abzufragen (chkServiceReqRes) und an den entsprechenden Web Service Client (ws_client) zu senden.
Das Verfahren weist dabei einen Empfangsschritt einer Anfrage zur Registrierung (reqRegService) eines Web Services von dem mobilen Web Service Provider (ws_provider) und einen Registrierungsschritt (regService) des Services auf. Weiterhin weist das Verfahren einen Empfangsschritt einer Web Service Anfrage (serviceReq) bezüglich des Web Services von einem Web Service Client (ws_client) und einen Prüfschritt. ob eine Antwort auf die Web Service Anfrage des Web Service Clients (ws_client) seitens des mobilen Web Service Providers (ws_provider) vorliegt (chkServiceReqRes), auf. Falls eine Antwort (serviceReqRes) vorliegt, wird die Antwort (serviceReqRes) an den Web Service Client (ws_client) in einem weiteren Schritt weitergereicht. Weiterhin kann eine Anfrage des mobilen Web Service Providers (ws_provider) ob eine Web Service Anfrage (serviceReq) vorliegt (chkServiceReq) in einem anderen Schritt erhalten werden. Das Verfahren kann in einem weiteren Schritt prüfen, ob eine Web Service Anfrage (serviceReq) eines Web Service Clients (ws_client) vorliegt, die nicht beantwortet werden kann. Falls eine Web Service Anfrage (serviceReq) eines Web Service Clients (ws_client) vorliegt, die nicht beantwortet werden kann, wird in einem weiteren Schritt die Web Service Anfrage (serviceReq) an den mobilen Web Service Provider (ws_provider) weitergeleitet.
Dadurch wird der Vorteil erreicht, dass Web Service Anfragen (serviceReq) eines Web Service Clients (ws_client), die nicht unmittelbar vom mobilen Web Service Provider (ws_provider) beantwortet werden können, zwischengespeichert werden, um diese dem mobilen Web Service Provider (ws_provider) zu übermitteln, sobald er sich wieder meldet, d. h. der mobile Web Service Provider (ws_provider) wieder erreichbar ist.
Damit ist es nicht mehr notwendig, dass ein mobiler Web Service Provider (ws_provider) unter einer Netzwerkadresse 24/7 erreichbar ist. Weiterhin kann ein mobiler Web Service auch dann angefordert werden, wenn die Netzwerkadresse häufig wechselt, wie es bei mobilen Kommunikationsendgeräten häufig der Fall ist, oder wenn ein mobiles Kommunikationsendgerät, welches solch einen mobilen Web Service anbietet (ws_provider), nicht in einem Netzwerk eingebucht ist oder sogar ausgeschaltet ist.
Registrierungsanfrage (reqRegService) bedeutet dabei, dass der mobilen Web Service Provider (ws_provider) sich bei der Middleware (ws_proxy) erstmals oder aktualisierend anmeldet, um seine Web Services oder auch nur einige seiner Web Services der Middleware (ws_proxy) bekannt zu machen, Änderungen an seinen Web Service bekannt zu geben oder Web Services auch wieder bei der Middleware (ws_proxy) abzumelden. Dazu kann der mobile Web Service Provider (ws_provider) notwendige Rahmendaten hierzu übermitteln, damit die Middleware (ws_proxy) in die Lage versetzt wird zu bestimmen wohin eine bestimmte Web Service Anfrage (serviceReq) eines Web Service Clients (ws_client) weitergeleitet werden soll und/oder wie mit der betreffenden Web Service Anfrage (serviceReq) umgegangen werden soll. In solch einer Registrierungsanfrage (reqRegService) können bereits auch Gültigkeitskriterien für die räumliche und/oder zeitliche Prüfung bzw. weitere Gültigkeitskriterien enthalten sein.
Weiter kann vorgesehen sein, dass das Verfahren weiterhin die Schritte aufweist: Versenden einer Autorisierungsanfrage an den Web Service Client (ws_client); erhalten einer Autorisierungsantwort des Web Service Clients (ws_client); prüfen der Autorisierungsantwort, und falls die Autorisierung erfolgreich war, Empfang von Web Service Anfragen des Webclients (ws_client) zulassen (in 2 nicht gezeigt).
Dies hat den Vorteil, dass nur derjenige Web Service Client (ws_client), der autorisiert ist, Web Service Anfragen (serviceReq) an den mobilen Web Service Provider (ws_provider) zu stellen, seine Anfragen an die Middleware (ws_proxy) richten darf. Dadurch werden nichtautorisierte Übertragungen verhindert, was den Datenverkehr sowohl zwischen dem Web Service Client (ws_client) und der Middleware (ws_proxy) als auch den Datenverkehr zwischen der Middleware (ws_proxy) und dem mobilen Web Service Provider (ws_provider) noch weiter minimieren kann.
Autorisierung bedeutet dabei, dass durch Mitteilung des betreffenden Web Service Clients (ws_client) auf der Middleware (ws_proxy) bestimmt werden kann, ob dieser Web Service Client (ws_client) berechtigt ist, den von ihm angefragten Web Service (serviceReq) in Anspruch zu nehmen. Um die Berechtigung zu überprüfen oder zu bestimmen kann es dabei evtl. auch erforderlich sein, dass der mobile Web Service Provider (ws_provider) der Middleware (ws_proxy) Berechtigungen oder Berechtigungskriterien mitteilt, anhand derer die Middleware (ws_proxy) entscheiden kann, ob der betreffende Web Service Client (ws_client) den angefragten Web Service (serviceReq) in Anspruch nehmen darf oder nicht.
Solche Kriterien können beispielsweise Altersbeschränkungen, ein gültiges Abonnement oder gültige Bezahlung des angefragten Web Services sein, genauso wie geographische wie auch zeitliche Kriterien. Es sind jedoch eine Vielzahl an weiteren Kriterien denkbar, anhand derer eine Autorisierung bestimmt und/oder ermittelt werden kann. In 3 ein schematischer Aufbau eines Sequenz Diagramms einer Web Service Anfrage und Antwort gemäß Aspekten der Erfindung dargestellt, wobei 3 einen Ausschnitt einer beispielhaften UML Sequenz Diagramms ähnlich der aus 2 zeigt, wobei jedoch nur die Kommunikation zwischen dem mobilen Web Service Provider (ws_provider), dem Proxy Server (ws_proxy) und dem Web Service Client (ws_client) dargestellt ist, jedoch die Datenbank in den Proxy Server (ws_proxy) integriert ist und somit keine externe Kommunikation zwischen Proxy Server (ws_proxy) und der Datenbank (database) notwendig ist.
Bevor die Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) vom Proxy Server (ws_proxy) an den Web Service Client (ws_client) weitergeleitet wird, kann beispielsweise vor der Weiterleitung die Antwort (serviceReqRes) auf Gültigkeit geprüft werden.
Dies hat den Vorteil, dass nicht mehr aktuelle oder anderweitig nicht mehr benötigte Web Service Antworten (serviceReqRes) nicht an den Web Service Client weitergereicht werden.
Die Antwort (serviceReqRes) kann vor der Weiterleitung auf zeitliche und/oder räumliche Gültigkeit geprüft werden.
Dies hat den Vorteil, dass keine ungültigen Web Service Antworten (serviceReqRes) an den Web Service Client weitergereicht werden. Ungültig können dabei räumlich und/oder zeitlich nicht mehr aktuelle Web Service Antworten (serviceReqRes) sein.
Dabei bedeutet räumliche Gültigkeit, dass abhängig von der Position des mobilen Web Service Providers (ws_provider), eine Antwort (serviceReqRes) ungültig geworden sein kann, falls die aktuelle Position des mobilen Web Service Providers (ws_provider) zum Zeitpunkt des Versendens der Antwort (serviceReqRes) der Web Service Anfrage (serviceReq) eines Clients (ws_client) an die Middleware (ws_proxy), räumlich außerhalb eines vorgegeben Bereiches liegt und somit Positionsbezogen irrelevant geworden ist.
Die zeitliche Gültigkeitsprüfung kann bei Benutzung eines Proxy Servers als Middleware (ws_proxy) beispielsweise auf einem Zeitstempel basieren, (sog. lifetime) der auf dem Proxy (ws_proxy) vorgehalten wird. Es kann sich jedoch beispielsweise auch um ein Timeframe o. ä. handeln, während dessen die Web Service Antwort (serviceReqRes) ihre Gültigkeit behält. Auch kann als Gültigkeit ein Countdown bestimmt werden, z. B. 20 min., bis zu dem die Web Service Antwort (serviceReqRes) als relevant erachtet wird. Es ist auch möglich beispielsweise einen einmaligen Stempel zu vergeben, so dass eine Web Service Antwort (serviceReqRes) beispielsweise nur ein einziges Mal ihre Gültigkeit behält, z. B. in dem die lifetime auf 0 gesetzt wird. Es sind verschiedenste Realisierungen der Gültigkeit und-Gültigkeitsprüfung für solch eine Web Service Antwort (serviceReqRes) möglich, die alle zum Ziel haben, dafür Sorge zu tragen, dass keine ungültigen, d. h. veralteten, Web Service Antworten (serviceReqRes) an den Web Service Client (ws_client) weitergereicht werden.
Auch ist es möglich solch eine Gültigkeit derart zu implementieren, dass nur nicht räumlich und/oder zeitlich veraltete Web Service Anfragen (serviceReq) an den mobilen Web Service Provider (ws_provider) weitergeleitet werden, oder für den Fall des Gültigkeitsablaufs der Web Service Antwort (serviceReqRes) diese erst gar nicht mehr an die Middleware (ws_proxy) gesendet wird, oder diese die Antwort gar nicht erst annimmt, oder sofort als ungültig verwirft. Dabei können die Gültigkeitsregeln/-kriterien grundsätzlich sowohl vom Web Service Client (ws_client) als auch vom mobilen Web Service Provider (ws_provider) vorgegeben oder vorgeschlagen werden. Bevorzugt bestimmt jedoch die Middleware (ws_proxy) selbst die räumlichen und/oder zeitlichen Gültigkeitsregeln/-kriterien.
Daher kann es vorgesehen sein, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist.
Dies hat den Vorteil, dass keine zeitlich veralteten Web Service Antworten (serviceReqRes) an den Web Service Client (ws_client) weitergereicht werden.
Ein weiterer Vorteil ist, dass der Web Service Client (ws_client) durch die Middleware (ws_proxy) darüber informiert werden kann, dass eine nicht mehr gültige Antwort (serviceReqRes) vorliegt und/oder diesen Client (ws_client) auffordert, seine Anfrage (serviceReq) erneut und evtl. auch aktualisiert zu senden.
Die gewisse Zeit bedeutet dabei ein zeitliches Kriterium, nach dem entschieden wird, wie lange eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) gültig ist. Die gewisse Zeit kann jedoch auch ein zeitlicher Rahmen sein, in welcher die Antwort (serviceReqRes) ihre Gültigkeit behält. Stellt die Middleware (ws_proxy) fest, dass zwischen der Anfrage des Web Service Clients (ws_client) und der Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) diese gewisse Zeit verstrichen ist, kommt die Gültigkeitsprüfung zu dem Ergebnis, dass die Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nicht an den Web Service Client (ws_client) weitergeleitet werden soll.
Weiter kann vorgesehen sein, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Antwort (serviceReqRes) enthalten ist.
Dies hat den Vorteil, dass die Kommunikation zwischen dem mobilen Web Service Provider (ws_provider) und der Middleware (ws_proxy) minimiert werden kann, da die gewisse Zeit bereits als Parameter in der Antwort (serviceReqRes) enthalten ist und nicht mehr bei Bedarf von der Middleware (ws_proxy) vom mobilen Web Service Provider (ws_provider) angefordert werden muss.
Ein weiterer Vorteil ist, dass damit die Gültigkeitsprüfung auf der Middleware (ws_proxy) vereinfacht werden kann, da ein Teil der Gültigkeitskriterien damit bereits vom mobilen Web Service Provider (ws_provider) bereitgestellt werden und im Bedarfsfall verwendet werden können.
Ein weiterer Vorteil ist, dass dadurch, dass die gewisse Zeit vom mobilen Web Service Provider (ws_provider) vorgegeben wird, die gewisse Zeit dynamisch ist, was bedeutet, dass jeder Web Service eines mobilen Web Service Providers (ws_provider) eine eigene gewisse Zeit vorhält, bzw. bestimmt, die möglicherweise von der gewissen Zeit eines anderen Web Services des selben oder auch eines anderen mobilen Web Service Providers (ws_provider) abweichen kann.
Die gewisse Zeit kann dabei auch keine Verwendung finden und/oder keine Relevanz haben, falls bereits ohne diese Information die Gültigkeitsprüfung auf der Middleware (ws_proxy) ergibt, dass die Antwort (serviceReqRes) nicht an den Web Service Client (ws_client) weitergeleitet werden soll, z. B. aufgrund der bereits erfolgten räumlichen Gültigkeitsprüfung, die bereits das Ergebnis liefert, dass die Antwort (serviceReqRes) nicht mehr gültig ist.
Ebenso ist dies andersherum möglich, also dass bereits die zeitliche Gültigkeitsprüfung ergeben hat, dass die Antwort (serviceReqRes) keine Gültigkeit mehr hat.
Auch sind weitere Gültigkeitsprüfungen, bzw. Gültigkeitsprüfungskriterien möglich.
Eine zeitliche Gültigkeitsprüfung kann dabei im Verbund mit einer räumlichen Gültigkeitsprüfung erfolgen, jedoch können auch beide vollständig losgelöst voneinander geprüft werden. Auch ist es insbesondere nicht notwendig, dass beide Kriterien für die Gültigkeitsprüfung der Antwort (serviceReqRes), also räumliches und zeitliches Kriterium gemeinsam implementiert sind, sondern es kann auch lediglich nur eine der beiden Kriterien implementiert sein, um eine Gültigkeitsprüfung der Antwort (serviceReqRes) vorzunehmen.
Es kann auch vorgesehen sein, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Registrierungsanfrage (reqRegService) enthalten ist.
Dies hat den Vorteil, dass bereits bei Registrierungsanfrage (reqRegService) die gewisse Zeit für den zu registrierenden Web Service und/oder mobilen Web Service Providers der Middleware (ws_proxy) bekannt gegeben wird, wodurch die Middleware (ws_proxy) bereits bei Registrierung des Web Services und/oder des mobilen Web Service Providers (ws_provider) anhand der Gültigkeitsprüfung bestimmen kann, ob evtl. für diesen Web Service und/oder mobilen Web Service Provider (ws_provider) anstehende Anfragen (serviceReq) als veraltet verworfen werden und somit erst gar nicht mehr an den mobilen Web Service Provider (ws_provider) übertragen werden müssen. Dies kann den Datenverkehr zwischen dem mobilen Web Service Provider (ws_provider) und der Middleware (ws_proxy) weiter minimieren.
In 4 ist eine beispielhafte Implementierung eines möglichen Web Services gemäß Aspekten der Erfindung dargestellt.
In 4 ist eine beispielhafte Implementierung gezeigt, die sich an JAX-WS (Java API for XML-Based Web Services) anlehnt. Der Web Service ist dabei mittels zweier Notierungen implementiert worden: @MobileWebService und @MobileWebMethod.
@MobileWebService kennzeichnet eine Klasse als einen Web Service und Methoden innerhalb dieser Klasse können als Methoden gekennzeichnet werden, die Mithilfe von @MobileWebMethod durch den mobilen Web Service verfügbar sind.
4 zeigt beispielhaft einen einfachen mobilen Web Service. Dieser liefert das Ergebnis der Addition zweier übergebener Variablen.
In 5 ist ein schematischer Aufbau eines UML Klassen Diagramms von Teilaspekten einer beispielhaften Implementierung der Funktionsweise eines mobilen Web Service Providers, eines Proxys als Middleware und der Kommunikation zwischen diesen gemäß Aspekten der Erfindung dargestellt.
5 zeigt Beziehungen zwischen unterschiedlichen Klassen gemäß einem Implementierungsvorschlag gemäß dem Beispiel in 4. Hauptsächlich besteht die Implementierung aus zwei Paketen.
Zum einen wird ein Paket, das gewöhnlich auf einem Server läuft, der durch das Internet über eine Adresse erreichbar ist, z. B. eine öffentliche IP-Adresse, bereitgestellt. Dies ist das Proxy Server Paket, welches in der unteren Hälfte der Figur dargestellt ist. Dabei implementiert eine Klasse in diesem Paket die notwendigen Methoden für die Registrierung (regService) des neuen Web Services, für das Polling des Web Services an den Proxy Server (ws_proxy) nach den Serviceanfragen Metadaten (serviceReqMeta) und für das Speichern der Serviceanfrage (serviceReq) in der Datenbank (database). Alle diese Methoden können selbst als Web Service erreichbar sein, so dass die Kommunikation zwischen den Instanzen des mobilen Web Services und dem Proxy Server (ws_proxy) vollständig als Web Service basiert sein kann.
Zum anderen wird ein Provider Paket bereitgestellt, in welchem eine der Klassen die MobileWebServiceRunner Klasse ist, auf dem der Web Service aufgebracht ist. Zusätzlich kann dieses Paket die beiden zuvor genannten Notationen @MobileWebMethod, @MobileWebService bereitstellen, die es erlauben, eine Klasse als einen mobilen Web Service zu kennzeichnen. Weiter implementiert dieses Paket die ServiceRequestFetcher Klasse. Sie ist verantwortlich für das andauernde Abfragen des Web Service Providers (ws_provider) nach neuen Serviceanfragen (serviceReq). Durch die Erfindung wird es ermöglicht, Web Services auch für Kommunikationsgeräte bereitzustellen, die mobil und/oder nicht ständig verfügbar sind.

Claims

Verfahren für die Bereitstellung von Web Services eines mobilen Web Service Providers (ws_provider) aufweisend die Schritte: • Empfangen einer Anfrage zur Registrierung (reqRegService) eines Web Services von dem mobilen Web Service Provider (ws_provider), • Registrieren des Services (regService), • Empfang einer Web Service Anfrage (serviceReq) bezüglich des Web Services von einem Web Service Client (ws_client), • Prüfen, ob eine Antwort (chkServiceReqRes) auf die Web Service Anfrage des Web Service Clients (ws_client) seitens des mobilen Web Service Providers (ws_provider) vorliegt, und falls eine Antwort (serviceReqRes) vorliegt, weiterreichen der Antwort (serviceReqRes) an den Web Service Client (ws_client), • Erhalten einer Anfrage (reqServiceReq) des mobilen Web Service Providers (ws_provider), ob eine Web Service Anfrage (serviceReq) vorliegt, • Prüfen (chkServiceReq), ob eine Web Service Anfrage (serviceReq) eines Web Service Clients (ws_client) vorliegt, die nicht beantwortet werden kann; falls eine Web Service Anfrage (serviceReq) eines Web Service Clients (ws_client) vorliegt, die nicht beantwortet werden kann, Weiterleiten der Web Service Anfrage (serviceReq) an den mobilen Web Service Provider (ws_provider).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Antwort (serviceReqRes) vor der Weiterleitung auf Gültigkeit geprüft wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Antwort (serviceReqRes) vor der Weiterleitung auf zeitliche und/oder räumliche Gültigkeit geprüft wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider), z. B. in einer externen Datenbank (database) oder internen Datenbank, gespeichert wird.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) in einer Datenbank (database) gespeichert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Antwort (serviceReqRes) enthalten ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Antwort (serviceReqRes) des mobilen Web Service Providers (ws_provider) nur für eine gewisse Zeit gültig ist, wobei die gewisse Zeit als Parameter in der Registrierungsanfrage (reqRegService) enthalten ist.
Verfahren nach einem der vorhergehenden Ansprüche, weiterhin aufweisend die Schritte • Versenden einer Autorisierungsanfrage an den Web Service Client (ws_client) • Erhalten einer Autorisierungsantwort des Web Service Clients (ws_client) • Prüfen der Autorisierungsantwort, und falls die Autorisierung erfolgreich war, Empfang von Web Service Anfragen (serviceReq) des Web Service Clients (ws_client) zulassen.