Mobile Web Services der OMA

OMA Mobile Web Services

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

- ii -

OMA Mobile Web Services

Inhalt

1 EINLEITUNG 1

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 21

A Organisationen und Industriekonsortien B Abkürzungen und Akronyme C Abbildungsverzeichnis LITERATURVERZEICHNIS 24

- iii -

OMA Mobile Web Services

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 -

OMA Mobile Web Services

EINLEITUNG 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.

- 2 -

OMA Mobile Web Services

EINLEITUNG 1.3

Begriffe

Enabler

Enabler ist eine Technik, die bei der Entwicklung, Implementierung und beim Einsatz von Services verwendet wird. [OMADICT]

OMA Web Services

Das OMA Web Services Enabler ist eine Sammlung allgemeiner Protokolle, Schemata und Prozessrichtlinien, deren Elemente Enabler (OWSER) basierend auf WS-Technologien unterschiedliche Services erzeugen bzw. mit ihnen interagieren können. SOA

Service Oriented Architecture (SOA) ist ein Systemarchitsektur-Konzept, das die Bereitstellung von Services vorsieht, die über eine standardisierte und auf Nachrichten basierende Schnittstelle in Anspruch genommen werden können. Die SOA sieht eine Menge voneinander unabhängige, asynchrone und lose gekoppelte Services vor. SOAP

Simple Object Access Protocol (SOAP) ist ein auf XMLbasierendes Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können.

Web Service

Ein Web Service ist eine Software-Anwendung, die entworfen wurde, um interoperatible Kommunikation zwischen verschiedenen Systemen über ein Netzwerk zu ermöglichen. Sie ist mit einem Uniform Ressource Identifier (URI) eindeutig identifizierbar. Und deren Schnittstellen können als automatisch verarbeitbare XML- Artefakte (siehe WSDL) definiert, beschrieben und gefunden werden. Der Datenaustausch zwischen Serviceanbieter und -Konsument findet unter Verwendung von SOAP oder XML-RPC Nachrichten statt, die meistens über HTTP übermittelt werden. [WSGloss] WSDL

Die Web Services Description Language (WSDL) definiert einen plattform-, programmiersprachen- und protokollunabhängigen XML- Standard und wird verwendet, um spezielle Methoden zu definieren, die zum Aufrufen von Services benötigt werden. Sie beschreibt im Wesentlichen Details zu den von außen zugänglichen Funktionen, Parametertypen, übermittelten Nachrichten, Netzwerkadressen und dem Transportprotokoll.

- 3 -

OMA Mobile Web Services

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.

- 4 -

OMA Mobile Web Services

GRUNDLAGEN 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.

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.

- 5 -