Die Industrie hat in der jüngsten Vergangenheit erkannt, dass der Entwurf von Mobile Web Services (MWS) offene Standards benötigt. Viele Großakteure arbeiten eng mit OMA sowie anderen Standardisierungsorganisationen zusammen an der Definition von MWS Spezifikationen. Das Ziel ist die Integration der WS-Technologien in die OMA-Architektur sowie die Gewährleistung der Interoperabilität über die offenen und standardisierten Protokolle. Die MWS-Arbeitsgemeinschaft beabsichtigt hierbei nicht, neue Spezifikationen herauszubringen, sondern strebt an, die verfügbaren Standards, welche die MWS-Anforderungen erfüllen, miteinander zu verbinden und zu erweitern.
In der vorliegenden Seminararbeit wird überwiegend die erste Version vom OMA Web Services Enabler (OWSER) behandelt.
Inhalt
1 EINLEITUNG
1.1 Motivation
1.2 Historische Entwicklung
1.3 Begriffe
2 GRUNDLAGEN
2.1 Service Oriented Architecture
2.2 Web Services
2.3 OMA Web Services Enabler (OWSER)
3 OWSER MOBILE WEB SERVICES REQUIREMENTS
3.1 Use Cases
3.2 Anforderungen
4 OWSER CORE SPECIFICATIONS
4.1 Architektur des OMA MWS Protokolls
4.2 Spezifikation von allgemeinen Funktionen
5 OWSER BEST PRACTICES: WSDL STYLE GUIDE
6 OWSER NETWORK IDENTITY SPECIFICATIONS
ANHANG
A Organisationen und Industriekonsortien
B Abkürzungen und Akronyme
C Abbildungsverzeichnis
LITERATURVERZEICHNIS
Zusammenfassung
Die Industrie hat in der jüngsten Vergangenheit erkannt, dass der Entwurf von Mobile Web Services (MWS) offene Standards benötigt. Viele Großakteure arbeiten eng mit OMA sowie anderen Standardisierungsorganisationen zusammen an der Definition von MWS Spezifikationen. Das Ziel ist die Integration der WS-Technologien in die OMA-Architektur sowie die Gewährleistung der Interoperabilität über die offenen und standardisierten Protokolle. Die MWS-Arbeitsgemeinschaft beabsichtigt hierbei nicht, neue Spezifikationen herauszubringen, sondern strebt an, die verfügbaren Standards, welche die MWS-Anforderungen erfüllen, miteinander zu verbinden und zu erweitern.
In der vorliegenden Seminararbeit wird überwiegend die erste Version vom OMA Web Services Enabler (OWSER) behandelt.
Stichworte
OMA Mobile Web Services, OWSER Anforderungen, OWSER Überblick, OWSER Kernspezifikation, OWSER beste Praxis: Anleitung zu WDSL Style
Abstract
Recently the industry has recognized that the draft of Mobile Web Services (MWS) needs open standards. With the goal to integrate WS technologies into the Open Mobile Alliance (OMA) architecture as well as to ensure the interoperability over standardized protocols, many main players cooperate with OMA for a common definition of the MWS specifications. The MWS Working Group does not propose to bring out new specifications, but to pull the existing standards together which have been shown to fulfill the MWS requirements.
The following seminar work introduces details about the first release of OMA Web services Enabler (OWSER).
Keywords
OMA Mobile Web Services, OWSER Requirements, OWSER Overview, OWSER Core Specifications, OWSER Best Practices WSDL Style Guide
1 EINLEITUNG
1.1 Motivation
Das Angebot von nützlichen und preiswerten Datendiensten ist ein wichtiger Faktor für das Wachstum am mobilen Markt. Jedoch war es lange Zeit für die Akteure der Industrie eine große Herausforderung, im Dschungel von proprietären Schnittstellen, Plattformen und Standards flexible und sichere Services anzubieten. Die Entwicklungskosten für mobile Anwendungen und Services wurden durch die komplexe Infrastruktur in die unendliche Höhe getrieben. Manche Akteure haben zwar mit eigener Kraft versucht, MWS Standards zu entwickeln. Doch kein Anbieter war stark genug sein spezielles System am Markt durchzusetzen.
Im Juli 2004 wurde die erste Version der OMA Mobile Web Services (MWS) Spezifikationen unter der Unterstützung vieler großen Unternehmen und Organisationen von der Open Mobile Alliance (OMA) veröffentlicht. Durch die Definition von offenen, plattformunabhängigen Schnittstellen ermöglichen sie verschiedenartige und flexibel einsetzbare Services. Dadurch wurde eine standardisierte Kommunikation zwischen Anwendungen und Services sowie unter den Services sichergestellt. Komplizierte Anwendungen wie mobile Bezahlungs- oder B2B-Transaktionsysteme sind möglich und erschwinglich geworden. Die Schlüsseleigenschaften bei der mobilen Interaktion „Mobilität“ und „Roaming“ wurden dabei maximiert.
Durch die Kompatibilität mit allen gängigen, etablierten Standards auf dem mobilen Markt und durch den Einsatz von plattform-, programmiersprachen- und protokollunabhängigen Spezifikationen haben Konsumenten von überall Zugang zu Mobile Web Services. Diese ortunabhängige Verfügbarkeit wiederum verspricht eine erhöhte Produktivität und eine bessere Lebensqualität für die Beteiligten. Die Unternehmen ihrerseits können höhere Gewinne realisieren.
1.2 Historische Entwicklung
Vor der Bekanntgabe der MWS von OMA haben manche Großanbieter erfolgreich Vorläufer von MWS-Spezifikationen entwickelt, einschließlich denjenigen, die z.B. auf Mobile Internet Browsing und Mobile Commerce basieren. Die darauf implementierten Services haben jedoch unter einigen Beeinträchtigungen gelitten:
- Sie sind während der engen Kooperation zwischen verschiedenen „Value-Added Service Providern” entstanden und waren fest gekoppelt und teuer.
- Solche durch Geschäftslogik entstandenen Abhängigkeiten müssen entkoppelt werden. Ferner muss die Entwicklung von Services preiswerter und anwendergerichtet sein.
- Sie wurden entwickelt aus einer Mischung von proprietären Modellen oder manchmal sogar aus unvereinbaren und sich überlappenden Standards (z.B. WAP, Location, MMS, Presence, Identity usw.).
- Diese Mischung aus nicht-offenen und nicht-freien Standards müssen vereinheitlicht werden. Die Entwicklung ist im vollen Gange.
- Spezielle Use Cases, die mehrere dieser Standards mit einbeziehen, müssen entworfen werden.
- Einige Standards sind speziell für die mobile Umgebung neu entwickelt worden. (z.B. WAP 1.0)
- Vorhandene Internet- und Web Services Spezifikationen sollen für den Entwurf benutzt werden, um damit „das Wiedererfinden des Rades“ zu vermeiden.
- Die Entwicklung, die Integration und die Benutzung der Services sind viel zu komplex und erfordern besonders geschulte Fachkräfte, die kaum zu finden sind.
- Vom Entwurf bis zum Gebrauch der Services soll der Prozess möglichst einfach und effizient gehalten werden und die verwendeten Techniken sollen möglichst spracheunspezifisch und plattformunabhängig sein.
1.3 Begriffe
Abbildung in dieser Leseprobe nicht enthalten
2 GRUNDLAGEN
2.1 Service Oriented Architecture
Die zugrunde liegende Software-Infrastruktur des OMA-Web-Services- Enablers basiert auf die Service Oriented Architecture (SOA). Eine SOA ist ein Systemarchitektur-Konzept, das die Bereitstellung von Services vorsieht und die dazu benötigten Schnittstellen festlegt, über die die Services via Netzwerk in Anspruch genommen werden können.
Beim Vergleich mit anderen Verteilten Systemen wird es deutlich, warum SOA als Konzept für Web Services besonders geeignet ist:
- Die von den traditionellen Verteilten-Systemen verwendeten Techniken wie CORBA, DCOM und Java RMI benutzen die objekt- und methodenorientierten APIs (Application Programming Interface) für die Kommunikation zwischen den Services und Servicekonsumenten. Bei der SOA ist die Interaktion nachrichtenbasiert und ihre Schnittstelle ähnelt eher einem Vertrag als einer beschreibenden Programmierschnittstelle. Die Konversation erfolgt mittels Austausch von Nachrichten durch Verwendung von einem festen Schema.
- Bei den früheren Verteilten Systemen wird meistens die synchrone Kommunikation implementiert. Dagegen wird in SOA der asynchrone Nachrichtenaustausch angewandt, der auch Antworten bearbeiten kann, selbst wenn sie erst mit Verspätung oder über andere Transportwege ankommen.
- SOA unterstützt eine Anwendungsintegration, in der zwei unabhängige Anwendungen wohl definierte Daten austauschen können. (Peer-to-Peer) Zwingende Abhängigkeiten der monolithischen und bestimmten Client-/Server-Architekturen sind damit aufgelöst.
- Instanzen in SOA agieren auf wohl definierte und erweiterbare Nachrichten. Es muss nur sichergestellt werden, dass die Anwendungen an beiden Verbindungsenden die Semantik und Syntax dieser Nachricht verstehen können. Für SOA ist es irrelevant, ob die Portabilität der Programme über unterschiedliche Programmiersprachen und Plattformen hinweg garantiert ist.
- Gewöhnlich erlaubt SOA die dynamische Suche nach nützlichen und kompatiblen Services. Die Geschäftsbeziehungen zwischen SOA- Instanzen müssen nicht vorher deklariert werden.
- SOA beschränkt sich nicht nur auf Anwendungen, die im Intranet laufen. Dank der Anpassbarkeit kann sie ohne Schwierigkeiten (z.B. Firewall) Geschäftsprozesse über das Internet anbieten.
2.2 Web Services
Web Services (WS) sind eine Initiative der Industrie zur Realisierung der SOA. Sie implementieren die bereits bestehenden und weit verbreiteten Internet- Standards und bieten eine offene und flexible Architektur an, die unabhängig von den verwendeten Plattformen, Programmiersprachen und Protokollen ist. Zusätzlich zur Unterstützung der programmatischen Interaktionen wie RPC, lassen WS einen asynchronen Dokumentaustausch zu, der mehr Flexibilität und Anpassungsfähigkeit liefert.
Die Wahl der offenen Standards, z.B. XML als die universelle Datenbeschreibungssprache und HTTP für die Datenübertragung, erleichtert den kleineren Mitstreitern die Integration und den Einstieg in den Markt.
Die WS-Architektur beinhaltet drei Funktionen (dargestellt in Abb. 2.1): Web Service, Web Service Requester (WSR) und Web Service Registry.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.1: Web Service Architektur [WSI1.0]
Ein WS-Anbieter ist zuständig für die Erstellung und die Veröffentlichung der Beschreibung seiner Services in einem Verzeichnis (Discovery) oder mehreren Verzeichnissen. Anschließend wartet das WS auf ankommende Nachrichten von WSR. Ein WSR durchsucht im Web Service Registry und wählt das gewünschte Service aus. Nachdem eventuell weitere Protokolldetails ausgetauscht worden sind, kann der WSR mit der empfangenen Service-Beschreibung dynamisch an das gewünschte WS anbinden.
2.3 OMA Web Services Enabler
Entwickler haben es nicht leicht, eine robuste, dezentralisierte und interoperatible Implementation der Web Services zu schaffen und gleichzeitig das Produkt in kurzer Zeit auf den Markt zu bringen. Der OMA-Webservice-Enabler (OWSER) definiert dazu allgemeine Funktionen, die aus wiederverwendbaren und in der Industrie weit verbreiteten Lösungsansätzen gewonnen wurden. Sie können anschließend von den Web Services (innerhalb von OMA) auf verschiedene Weise benutzt werden (z.B. in WSR oder in WSP). Der OWSER ist darüber hinaus erweiterbar, d.h. neue Funktionen können definiert und in OWSER eingeschlossen werden.
Es herrscht zurzeit eine starke Divergenz in den Gebieten Sicherheit, Richtlinien und Messaging. z.B. Wie man die Verfügbarkeit realisieren könnte. Bevor die Lösungsansätze in der Industrie als de-facto Standards anerkannt worden sind, werden sie vorerst nicht in der jetzigen Version des OWSER erfasst.
Die Funktionsweise des OWSER wird in drei Phasen geteilt (vgl. Abb. 1.2):
Service Publikation ist der erste Schritt, um einen SE verfügbar zu machen. Dabei werden die benötigten Informationen publiziert, wie der Ort, die Schnittstellebeschreibung, das Nachrichtentransportprotokoll sowie zusätzliche Informationen des Enablers. Zur Unterscheidung befinden sich die allgemeinen Informationen in einem externen und die anderen, die zum Auffinden und Verwenden von OWSER Funktionen notwendig sind, in einem internen und geschützten Serviceverzeichnis. Nachdem die Beschreibung des SE veröffentlicht wurde, kann er von einer Applikation entdeckt und benutzt werden.
Service Entdecken (Discovery): Welche Möglichkeiten zur Entdeckung der SE den Servicekonsumenten angeboten werden, hängen davon ab, wie der Serviceanbieter die Informationen zur Verfügung stellt. In vielen Fällen besteht schon eine Beziehung zwischen Serviceanbieter und Servicekonsumenten. Hier muss der Serviceanbieter die Informationen per Serviceverzeichnis, Email, Webseite oder in Form von Werbe- CDs bereitstellen. Der Servicekonsument bekommt die notwendigen Angaben zur Nachrichtenschnittstelle sowie zusätzlichen Richtlinien, einschließlich Auskunft über die Sicherheitsbedingungen, die für die Verbindung zwischen WSR und WS erforderlich sind.
Service Aufruf (Invocation): Die technischen Informationen, die relevant für die SE Schnittstelle sind, werden bei der Implementation des WSR verwendet. In Abb. 2.2 liegt nur ein Pfad zwischen WSR und WS. Aber in Wirklichkeit gibt es dafür mehrere Entwicklungsarchitekturen. Oft befindet sich ein Vermittlungselement (standardmäßig SOAP) zwischen WSR und WS, das die Aufgabe der Ver-/Entschlüsslung, der Autorisierung, des Lastausgleichs usw. vornimmt und transparent für den WSR ist (außer bei Value-Added Services)
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.2: Funktionsweise des OWSER [OWSEROvw]
Es existiert zwei Hauptmodi bei der Interaktion zwischen WSR und WS im OWSER: Direktes Modell: WSR und WS unterstützen beide ein vollständiges WS-Stack. Ein WS kann zur gleichen Zeit ein WSR des anderen WS sein.
Indirektes Modell: Falls WSR das Web Services Stack nicht komplett unterstützt,
kann er trotzdem die verfügbaren Services indirekt konsumieren. Meistens findet die Interaktion über einen Vermittler (Proxy) statt. Der Proxy übernimmt die Rolle des WSR und kommuniziert mit WS unter Benutzung der WS Standardschnittstelle.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2.3: Indirekt = Schnittstelle A + Schnittstelle B ; Direkt = Schnittstelle B [OWSEROvw]
[...]
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.