Discovery von Location Based Services

Discovery von LBS
Seminararbeit
von Florian Pepping
im Rahmen der Projektgruppe
„Location Based Services for Wireless Devices“
AG Kao
Betriebssysteme und Verteilte Systeme
Institut für Informatik
Universität Paderborn
Motivation
• Wieso:
 Service Discovery zusammen mit LBS unserer PG?
 Service Discovery, was steckt denn dahinter?
• Weshalb:
• Darum:
 Service Discovery als leistungsfähiges Konzept für diese Aufgaben
 Service Discovery als Verbindung Dienst  Dienstbenutzer
 Service Discovery als zentrale Dienstverwaltung / Middleware
16.05.2016
PG LBS: Discovery von LBS
Folie 2
Florian Pepping, November 2004
 Anzahl netzfähiger mobiler Endgeräte steigt rasant
 Netzwerke stellen immer mehr Dienste zur Verfügung
 User erwartet einfache Nutzung der Dienste - sofort und überall
Agenda
• Dienst und Service Discovery Protokoll
• Protokolle
Service Location Protocol (SLP)
Salutation
Universal Description, Discovery and Integration (UDDI)
Universal Plug and Play (UPnP)
Java Intelligent Network Infrastructure (JINI)
• Fazit & Bewertung
16.05.2016
PG LBS: Discovery von LBS
Folie 3
Florian Pepping, November 2004





Dienst und Service Discovery Protokoll
• Was ist ein Dienst?
abgeschlossene (Programm-) Einheit mit spezieller Aufgabe
kann Menge von Funktionen besitzen
wird von Dienstanbieter erbracht und von Dienstnutzer verwendet
Infrastruktur-, Mobilitäts-, Informations- und Ortungsdienste
• Wozu Service Discovery Protokolle?
(nach [CBL])
 Stellen einen Mechanismus für das dynamische Entdecken der
verfügbaren Dienste in einem Netz und für das Sammeln der
notwendigen Informationen zur Verfügung:
 Suchen und Browsen des Dienstes
 Auswahl des richtigen Dienstes
 Benutzen des Dienstes
2
1:
2:
3:
4:
Dienstvermittler
Registrierung
Dienstanfrage
Antwort
Dienstnutzung
1
3
Dienstnutzer
Dienstanbieter
4
nach ([MCFS])
16.05.2016
PG LBS: Discovery von LBS
Folie 4
Florian Pepping, November 2004




(nach [CBL])
Service Location Protokoll (SLP 1)
• Service Location Protokoll
 Standard der Internet Engineering Task Force
 Definition durch eine Reihe von RFC‘s
 Protokoll zum Auffinden von Diensten in einem TCP/IP-Netzwerk
• Dreistufiges Konzept der SLP Architektur:
 Benutzeragenten (User Agents):
 Ausführung des Service Discovery
 Client bezogen
 Anmeldung der Dienste mit ihren Positionen und Eigenschaften beim
Verzeichnisagenten
 Verzeichnisagenten (Directory Agents):
 Service-Adressen und -Informationen der Service Agents sammeln
 Beantworten der Service-Anfragen der User Agents
Multicast
16.05.2016
PG LBS: Discovery von LBS
Folie 5
Florian Pepping, November 2004
 Dienstagenten (Service Agents):
Service Location Protokoll (SLP 2)
• Zwei unterschiedliche Ausführungsmodi
1) Directory Agent verfügbar
 Sammeln aller Serviceinformationen der Service Agents und
User Agents durch Unicast
 Service Agent gibt Dienst-Infos an Directory Agent (Service Advertisement)
 User Agents suchen nach Services (Service Requests)
Directory Agent
16.05.2016
Service Request
Service Registration
Service Reply
Service Ack
PG LBS: Discovery von LBS
Service Agent
Service
Folie 6
Florian Pepping, November 2004
User Agent
Service Location Protokoll (SLP 3)
• Zwei unterschiedliche Ausführungsmodi
2) Directory Agent nicht verfügbar
 User Agents melden sich per Multicast bei allen SLP Multicast-Adressen
 wird der Dienst eines Service Agent nachgefragt
 Sendung einer Antwort zum User Agent
 Service Agents melden sich periodisch bei allen SLP Multicast-Adressen
 User Agents finden neue Dienste
Service Request
Service Agent
Service Reply
SLP nach: [MC], [SDuJ], [SLP], [SDP], [SLPTW], [TS]
16.05.2016
PG LBS: Discovery von LBS
Folie 7
Florian Pepping, November 2004
Service Agent
User Agent
Salutation (1)
• Salutation (Anrede, Begrüßung)
 Von Salutation Consortium entwickelt
 mehr als 20 Unternehmen beteiligt (z. B. IBM, HP, Xerox, Toshiba,…)
• Ziel:
 Kommunikation zwischen den Komponenten
 Kommunikationstechnologie protokollunabhängig
 Endgeräteunabhängigkeit
Server
Laptop
Handy
Server
SM-API
Salutation Application Interface
SM-API
Salutation Manager
Salutation Manager
Salutation Manager
Transport Manager
Salutation Protocol
Transport Layer
16.05.2016
Desktop
Transport Man.
Transport Man.
Transport Manager
Salutation Protocol
Transport Layer
PG LBS: Discovery von LBS
Folie 8
Florian Pepping, November 2004
• Architektur von Salutation
Salutation (2)
• Hauptkomponente: Salutation Manager (SLM)
 Funktionalität eines Service Brokers und Dienstregistrierung
 Dienste anfragen durch Clients
 anschließend Anforderung der Dienste beim SLM
• Aufgaben des Salutation Managers:
 Salutation Manager verwaltet Registry; Clients können Dienste an- und abmelden
 Minimalanforderung: Speicherung von Infos über Dienste, die an den SLM
angeschlossen sind
 Optional: Speicherung von Infos über Dienste anderer SLM‘s
 Zentrales Verzeichnis für alle Dienste im Netzwerk möglich
 Service Discovery:
 SLM findet Dienste, die bei anderen SLM‘s registriert sind
 Vergleich von Attributen über Salutation Manager Protocol
16.05.2016
PG LBS: Discovery von LBS
Folie 9
Florian Pepping, November 2004
 Service Registry:
Salutation (3)
• Aufgaben des Salutation Managers:
 Service Availability:
 Client Applikation fordert SLM auf, periodisch Verfügbarkeit der Dienste abzufragen
 Status-Check zwischen SLM der Client Applikation und SLM des Dienstes
 Service Session Management
 Object Locate & Load
 Salutation kann Doc Storage Service beschreiben
 Doc Storage kann „Page Images“, Gerätetreiber, Anwendungsdaten,... enthalten
 Find-and-Bind
Salutation nach: [SDuJ], [Salutation], [SDP], [TS]
16.05.2016
PG LBS: Discovery von LBS
Folie 10
Florian Pepping, November 2004
 Aufbau der Datenleitung zwischen Client und gefundenem Dienst
 3 Modi: Native Mode (Native Data in Native Packtes)
Emulated Mode (Native Data in Salutation Packets)
Salutation Mode
Universal Description, Discovery
and Integration (UDDI)
• Universal Description, Discovery and Integration
Verzeichnisdienst für dynamische Webservices
Entwicklung von IBM, Ariba, Sun und Microsoft (Konsortium von 300 Firmen)
standardisiert das Publizieren und Finden von Infos über Webservices
verwaltet und speichert Metadaten über Webservices und ist selbst Webservice
 öffentliches Register (wie DNS für Business Anwendungen)
 Eintragen/Abfragen von Daten über SOAP-basierte API‘s (nur 40 Operationen)
 konzipiert für das WWW mit stark heterogenen Strukturen
UDDI nach: [CBL], [UDDI], [WebS]
 baut auf TCP/IP, XML, SOAP und WSDL
UDDI
White Pages
- Namensregister,
sortiert nach Namen
- Auflistung der Anbieter
mit Detailangaben
- Kontaktinformationen
(Telefon, Telefax, Mail,…)
- textuelle Beschreibung
16.05.2016
Yellow Pages
- Branchenverzeichnis
- Spezifische Suche nach
Taxonomien (Ort, Dienstart)
- Kategorisierung
(Gelbe Seiten)
- Verweist auf White Pages
PG LBS: Discovery von LBS
Green Pages
- Technische Details zu den
angebotenen Web Services
und zu ihrem Zugang
- WSDL-Beschreibungen
- Binding Informationen
Web-Service
Architektur
Folie 11
Florian Pepping, November 2004




Universal Plug and Play (UPnP 1)
• Universal Plug and Play
 Entwicklung durch UPnP-Forum; gegründet 1999
 Über 450 Mitglieder, Microsoft an der Spitze
 Ziel: Erweiterung der Plug & Play-Idee für den Fall, dass
Geräte über TCP/IP miteinander verbunden sind
 Steuerung über Webbrowser oder UPnP-Applikation
 UPnP nutzt TCP, IP, UDP, HTTP und XML




16.05.2016
den UPnP fähigen Geräten
den Diensten
den (Benutzer-) Kontrollpunkten (Control Point)
einer optionalen zentralen Komponente (SSDP-Proxy)
PG LBS: Discovery von LBS
Folie 12
Florian Pepping, November 2004
• UPnP-System besteht aus drei Grundkomponenten:
Universal Plug and Play (UPnP 2)
• Service Discovery und Vernetzung in 5 Schritten:
1) Discovery and Advertisement
Voraussetzung: gültige IP-Adresse  Addressing
melden der Existenz des Dienstes im Netz via UDP-Multicast
Control Points fragen bei Beitritt verfügbare Dienste ab
Basis ist das Secure Service Discovery Protocol (SSDP)
Datenaustausch über Discovery-Messages
Messages enthalten nur sehr wenig Information (effizient)
Service
Registrierung [3]
SSDP-Proxy
Service
Antwort [4]
Server
[1]
MulticastAnfrage
Client
16.05.2016
1) Control Point sendet Dienst-Anfrage
über Multicast ins Netz
2) passender Service antwortet über UDP
[2]
Service
Antwort [4]
3) Dienst registiert sich bei der zentralen
Kommponente SSDP-Proxy
4) Dienstanfragen durch Proxy beantwortet
PG LBS: Discovery von LBS
Folie 13
Florian Pepping, November 2004






Universal Plug and Play (UPnP 3)
• Service Discovery und Vernetzung in 5 Schritten:
2) Description
 Dienstbeschreibung in Form von XML-Dokumenten
 Download via HTTP von der mitgeteilten URL
 Inhalt: u. a. Hersteller, Statusvariablen, Dienstangebot, Steuerungs-URL‘s
3) Control
 Control Point sendet Controle Messages an Control URL des Dienstes
 Steuerung der Dienstes über SOAP-Mitteilungen in XML-Format
 Dienst sendet Ergebniswerte als Antwort




Verhinderung ständiger Statusabfragen von Diensten
Dienst gibt Updates der Statusvariablen bekannt
Control Point kann Event-Messages bei jeder Statusänderung abonnieren
Basis: General Event Notification Architecture von XML (GENA)
5) Presentation
 Alternative zu Steuerungs- und Statusmeldungen
 Presentation-URL aus Beschreibung erlaubt Zugriff auf Dienst via Webbrowser
 ermöglicht erweiterte Steuerung und Beschreibung
Florian Pepping, November 2004
4) Eventing
UPnP nach: [MC], [SDuJ], [SDP], [UPnP]
16.05.2016
PG LBS: Discovery von LBS
Folie 14
Java Intelligent Network Infrastructure
• Java Intelligent Network Infrastructure (JINI)
 von SUN definierter Standard (Satz von API‘s) für die Kommunikation von
Geräten und Diensten untereinander
 Veröffentlicht im Januar 1999 (aktuell Version 2.0_002)
 Paradigma: Network Plug & Play, vereinfachte Netzwerknutzung






16.05.2016
Spontane Netzwerkbildung und –auflösung
Verwaltung von Diensten und Clients im Netzwerk
selbstständige Discovery brauchbarer Dienste
Vereinfachung der Netzwerkadministration
Mobile Computing (Positionswechsel ohne Anbindungsverlust)
Selbstheilung
PG LBS: Discovery von LBS
Folie 15
Florian Pepping, November 2004
• Ziele von JINI
Java Intelligent Network Infrastructure
Architektur
• Logische Schicht (Middleware) über die einzelnen JVM‘s
 Kommunikation über Netzwerk (RMI oder proprietäres Protokoll)
 Applikationen setzen auf JINI auf
• Architektur bestehend aus drei Teilen
Service-Protokoll
JINI Services
JINI Services
Druckdienste Kartendienste ÖPNV
Druckdienste Kartendienste ÖPNV
JINI
JINI
Discovery,
Join,
Lookup
Infrastruktur: Discovery, Join, Lookup
Infrastruktur: Discovery, Join, Lookup
Prog.-Modell: Events, Transaktionen, Leasing
Prog.-Modell: Events, Transaktionen, Leasing
Java-RMI
Java 2 Plattform
Java 2 Plattform
JVM, RMI, Netzwerk, Sicherheit, Serialisierung
JVM, RMI, Netzwerk, Sicherheit, Serialisierung
Betriebssystem
Betriebssystem
Prozessor
Prozessor
Netzwerk
16.05.2016
PG LBS: Discovery von LBS
Folie 16
Florian Pepping, November 2004
1) Infrastruktur (Verwaltung / Verteilung)
2) Programmiermodell (Diensterstellung)
3) Services
Java Intelligent Network Infrastructure
Zentrale Konzepte
• Lookup und Discovery
 besteht aus drei Protokollteilen: Discovery (Client und Server)
• Lookup-Service
Join (Server)
Lookup (Client)
als Dienst implementiert
 findet und löst Dienste auf, registriert sie
 identifiziert Dienste über Typ-Match-Regeln oder Attribute
 Kontaktvermittlung zwischen Dienstanbieter und -nutzer
 erzielen Dynamik und automatische Konfiguration des Netzwerkes
 Zugriff auf Dienst nur gültig für bestimmte Zeitperiode (Lease erneuern)
• Remote-Events
 verteilte Events, basierend auf Java-Bean Events
 Abonnement von Events wird unterstützt
16.05.2016
PG LBS: Discovery von LBS
Corba/JINI
Folie 17
Florian Pepping, November 2004
• Leasing
Java Intelligent Network Infrastructure
Ablauf
Web-Server
Druck-Service
Lookup-Service
1 Discovery
2
3 Registrierung
LS-Service-Proxy
5
Use-Service
JINI nach: [JAOS], [JINI], [JINI 01], [JINISun], [SDuJ], [SDP]
16.05.2016
PG LBS: Discovery von LBS
Folie 18
Florian Pepping, November 2004
6
Service Discovery Protokolle
Vor- und Nachteile



einfache Implementierung
geeignet auch für beschränkte HW
flexibel und skalierbar
 schwaches Sicherheitskonzept
 keine bzw. schlechte Interoperatibilität
 beschränkte Funktionalität, nur für TCP/IP



netzwerkunabhängig
Kollaboration von SM untereinander
unabhängig von Programmiersprache
 Spezifikation enthält keine Sicherheitsaspekte
 vor allem auf Vermittlung von Hardware
ausgerichtet


XML für Protokollstandardisierung
aufbauend auf Protokollen niedriger
Netzwerkebene (effizient)
mit XML gute Dienstbeschreibung möglich




nur für TCP/IP-Netzwerke
Spezifikation enthält keine Sicherheitsaspekte
keine attributbasierte Suche von Diensten
keine Interoperabilität
großer Funktionsumfang
plattformunabhängig/objektorientiert
Sicherheitskonzept (Policy/Sandbox)
Mobile-Code Feature




setzt JVM auf jedem Endgerät voraus
nur für TCP/IP-Netzwerke (im Standard)
ressourcenhungrig (CPU, Speicher)
unübersichtliche, komplizierte API von JINI
• Salutation
• Universal Plug & Play

• JINI




16.05.2016
PG LBS: Discovery von LBS
Folie 19
Florian Pepping, November 2004
• Service Location Protokoll
Fazit & Bewertung
Anforderungen/Möglichkeiten unserer PG
• Service Discovery im Rahmen der PG






zentrale Komponente problemlos verfügbar, eher Routingprobleme
keine Bandbreitenprobleme, da über WLAN
Endgeräte genügend leistungsfähig (Laptop, PDA)
genaue Dienstspezifikation und Dienstsuche über Attribute wichtig
Plattformunabhängigkeit und Mobile-Code erforderlich
Ist Sicherheitskonzept notwendig?  Klärung erforderlich
• Mögliche Systemarchitektur
Zentrale Komponente
Client registrieren
Client
Software installieren
Dienst registrieren
Dienst
best. Dienst anfordern
Dienstadresse mitteilen
regelm. Dienststatus abfragen
- Client wählt im Browser www.upb.de
- Splash-Screen mit Dienstangebot und Softwareinstallationsaufforderung
16.05.2016
PG LBS: Discovery von LBS
Folie 20
Florian Pepping, November 2004
Interaktion Dienst / Client
Fazit & Bewertung
• Möglichkeiten für unsere Projektgruppe:
 Vorschlag 1: Java Intelligent Network Infrastructure
Plattformunabhängigkeit ist gegeben
gute Kompatibilität mit anderen Anforderungen (z. B. Java-Applets)
zahlreiche erweiterte Funktionalitäten (z. B. Transaktionen)
Restriktionen wie leistungsschwache Endgeräte, geringe Bandbreite und die
benötigten JVM‘s kommen im Projekt nicht zum Tragen
 javabasiertes Sicherheitskonzept









16.05.2016
setzt auf vorhandene, etablierte Technologien auf (HTTP, XML, TCP, IP)
gute Dienstbeschreibung mit Hilfe von XML möglich
bietet erweiterten Funktionsumfang (Eventing, Presentation)
Konzept ohne zentrale Komponente
kein Sicherheitskonzept vorhanden
PG LBS: Discovery von LBS
Übersicht
Folie 21
Florian Pepping, November 2004
 Vorschlag 2: Universal Plug & Play
Fragen & Diskussion
Bitte jetzt um Fragen und Diskussion
16.05.2016
PG LBS: Discovery von LBS
Folie 22
Florian Pepping, November 2004
Vielen Dank für Ihre Aufmerksamkeit.
Quellenangaben
[JAOS]:
[JINI]:
[JINI 01]:
[JINISun]:
[MC]:
[MCFS]:
[Salutation]:
16.05.2016
Computer-Base Lexikon
ComputerBase Medien Gbr, 2004
http://www.computerbase.de
Jini Architectural Overview
Sun Microsystems, 1999
Homepage der JINI-Gruppe
http://www.jini.org
Scott Oaks & Henry Wong:
JINI in a Nutshell, Deutsche Ausgabe
O’Reilly Verlag Köln, 1. Auflage 2001
Homepage von Jini bei SUN
http://wwws.sun.com/software/jini
Developing Ad-Hoc Component
Systems for Mobile Computing
Hauptseminar Prof. Dr. Broy
TU München, WS 2000 / 2001
Antonino Leanza:
Fachseminar Mobile Computing
Juni 2000
Homepage Salutation Consortium
http://www.salutation.org
[SDuJ]:
C. Hanin & B. Penz
Service Discovery und Jini
Seminar ang. Informatik, SS 2002
[SLP]:
Homepage der OpenSLP-Gruppe
http://www.openslp.org
[SLPTW]: Charles Perkins
SLP Technical Whitepaper, Sun 1997
http://www.playground.sun.com/srvloc
[UDDI]: Homepage der UDDI-Gruppe
http://www.uddi.org
[UPnP]:
Homepage des UPnP Forums
http://www.upnp.org
[TS]:
Tine Schneider:
Basistechnologien für spontane
Vernetzung, Seminar SS 2001
Eberhard-Karls-Uni-Tübingen
[SDP]:
Mirco Tegler:
Service Discovery Protokolle
Seminar technische Informatik, Januar 03
[WebS]: Ralf Heese:
GIS-Datenbank für webservicebasierten
Zugriff auf standortbez. Informationen
Diplomarbeit Humboldt Universität Berlin
PG LBS: Discovery von LBS
Folie 23
Florian Pepping, November 2004
[CBL]:
Background
16.05.2016
PG LBS: Discovery von LBS
Folie 24
Florian Pepping, November 2004
Backgroundfolien mit
zusätzlichen Informationen
16.05.2016
Protokoll
SLP
Salutation
UPnP
Jini
Entwickler /
Organisation
IETF
Salutation
Consortium
Microsoft
Sun
Entstehungsjahr
1997
1995
1999
1998
Status
In Entwicklung
Im Gebrauch
Übergang
Marktreife
Übergang
Marktreife
Lizenz /
Spezifikation
Open Source
Open Source
Open Source /
kontrolliert
Open Source /
kontrolliert
Programmiersprache
Unabhängig
Unabhängig
Unabhängig
Java
Netzwerktransport
TCP/IP
Unabhängig
TCP/IP
Unabhängig
Dienst-Beschreibung
String
String
String
Java Interface
Server-Registrierung
Authenticated
Multicast
nur lokal
Multicast /
Unicast
Multicast mit
TCP-Callback
Code-Mobilität
nein
nein
nein
Java-RMI
Sicherheitsmodell
nein
Ja
Ja
Java-basiert
HW / SW Anforderungen
TCP / IP
keine
TCP / IP,
HTTP, XML
Java, JVM
JRE 1.2 >
Interoperation
mit anderen SDPs
nein
ja
nein
ja
PG LBS: Discovery von LBS
Folie 25
Florian Pepping, November 2004
Background
Übersicht über die Protokolle
Background
Broadcast, Multicast, Unicast
• Broadcast




Rundruf ins Netz mit Versand von Paketen an alle Teilnehmer
Verwendung, wenn Empfängeradresse unbekannt
jeder Empfänger muss über Verarbeitung entscheiden
ein Broadcast wird von Routern nicht weitergeleitet
 Punkt-zu-Gruppe Übertragung (Mehrpunktverbindung)
 gleichzeitiger Versand von Nachrichten an mehrere Teilnehmer
oder geschlossene Teilnehmergruppe
 Pakete werden an Router/Switch kopiert und dann weitergeleitet
• Unicast
 Punkt-zu-Punkt Verbindung ohne Zwischenvermittlung
 Pakete werden von Routern/Switches weitergeleitet
nach [CBL]
16.05.2016
PG LBS: Discovery von LBS
Folie 26
Florian Pepping, November 2004
• Multicast
Background
Unterschiede JINI – Corba
• Corba
 beruht auf dem Client-Server-Paradigma. Fokus liegt mehr auf verteilten
Objekten als auf verteilten Diensten
 vermittelt Methodenaufruf, wenn Server aktuell erreichbar
 setzt eng gekoppeltes, homogenes System voraus; arbeit in heterogenem
System nur mit hohem Aufwand möglich
 sprachunabhängig
 beruht auf dem Dienst-Paradigma. Clients beschreiben den Dienst, den sie
benötigen
 bietet Ausweichmöglichkeiten, wenn Dienst nicht erreichbar
 informiert, wenn Dienst wieder bzw. neu verfügbar (Eventing)
 unterstützt proaktive Fehlererkennung (Leasing)
 bietet weitere Dienste wie Transaktionsmechanismen usw.
16.05.2016
PG LBS: Discovery von LBS
Folie 27
Florian Pepping, November 2004
• JINI
Background
Service Desription in SLP
• Service Description
 Setzt sich zusammen aus
 Service URL
 Service Scheme (Menge von Schlüssel-Wert-Paaren)
 Service Requests wird Query hinzugefügt
(formuliert als boolsches Prädikat)
• Beispiel
service:printer://lj4050.tum.de:1020/queue1
scopes = profs, pg-lbs, administrator
printer-name = lj4050
printer-model= HP LJ4050 N
printer-location = Room 409
color-supported = false
pages-per-minute = 9
sides-supported = one-sided, two-sided
Beispielprädikat: (&(q<=3) (pages-per-minute>6))
16.05.2016
PG LBS: Discovery von LBS
Folie 28
Florian Pepping, November 2004
 Service Schema eines Netzwerkdruckers:
Universal Description, Discovery
and Integration (UDDI)
• Grundlegende Architektur von UDDI
UDDI
Service
Verzeichnis
Universal Description,
Discovery and Integration als
öffentliches Verzeichnis
Finden
Publizieren
WSDL
WSDL
Service
Nutzer
16.05.2016
Binden
(Kommunikation über
SOAP-Nachrichten)
PG LBS: Discovery von LBS
Service
Anbieter
Folie 29
Florian Pepping, November 2004
Kommunikation
über SOAP
Background
Definition Web-Service
• Definition Web-Service
 Ein Web-Service (Web Dienst) ist eine Software, die




auf einem Server bereitgestellt wird,
eine bestimmte Funktionalität als Blackbox zur Verfügung stellt,
über gängige Internet-Protokolle unter Benutzung von SOAP zugreifbar ist und
über eine mit WSDL beschriebene Schnittstelle verfügt.






16.05.2016
implementieren keine neuen Systeme
Fassade für bestehende Systeme, um auf diese einfach zuzugreifen
nutzen gängige Internet-Protokolle wie HTTP(S), SMTP und FTP
verwenden XML-Standards SOAP und WSDL
unabhängig von Programmiersprachen und Betriebssystemen
zwei Erscheinungsformen: entfernte Prozeduraufrufe (synchron) oder
Messaging (asynchron)
PG LBS: Discovery von LBS
Folie 30
Florian Pepping, November 2004
 Eigenschaften von Web-Services