ag kao betriebssysteme und verteilte systeme institut für informatik universität paderborn...

AG Kao

Betriebssysteme und Verteilte SystemeInstitut für InformatikUniversität Paderborn

Discovery von LBS

Seminararbeitvon Florian Pepping

im Rahmen der Projektgruppe„Location Based Services for Wireless Devices“

PG LBS: Discovery von LBS Folie 2 Flori

an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

• Wieso: Service Discovery zusammen mit LBS unserer PG? Service Discovery, was steckt denn dahinter?

• Weshalb: 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

• Darum: Service Discovery als leistungsfähiges Konzept für diese

Aufgaben Service Discovery als Verbindung Dienst Dienstbenutzer Service Discovery als zentrale Dienstverwaltung / Middleware

Motivation


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Dienst und Service Discovery Protokoll

• Was ist ein Dienst? (nach [CBL])

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

Dienstvermittler

Dienstnutzer Dienstanbieter

12

3

4

1: Registrierung2: Dienstanfrage3: Antwort4: Dienstnutzung

nach ([MCFS])


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

Dienstagenten (Service Agents): 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


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

• Zwei unterschiedliche Ausführungsmodi1) Directory Agent verfügbar

Sammeln aller Serviceinformationen der Service Agents undUser Agents durch Unicast

Service Agent gibt Dienst-Infos an Directory Agent (Service Advertisement)

User Agents suchen nach Services (Service Requests)


User Agent

Directory Agent

Service AgentService Registration

Service Ack

Service Request

Service ReplyService


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23


• Zwei unterschiedliche Ausführungsmodi2) 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

User Agent Service Agent

Service Agent

Service Request

Service Reply

SLP nach: [MC], [SDuJ], [SLP], [SDP], [SLPTW], [TS]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

• Architektur von Salutation

Server

SM-API

Salutation Manager

Transport Manager

Handy

SM-API

Salutation Manager

Transport Manager

Transport Layer

Salutation ProtocolTransport Layer

Salutation Protocol

Desktop

Salutation Manager

Transport Man.

Laptop

Salutation Application Interface

Transport Man.

Server


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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: Service Registry:

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


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

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]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Universal Description, Discoveryand 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 baut auf TCP/IP, XML, SOAP und WSDL

Architektur

White Pages- Namensregister, sortiert nach Namen- Auflistung der Anbieter mit Detailangaben- Kontaktinformationen (Telefon, Telefax, Mail,…)- textuelle Beschreibung

UDDI

Yellow Pages- Branchenverzeichnis - Spezifische Suche nach Taxonomien (Ort, Dienstart) - Kategorisierung (Gelbe Seiten)- Verweist auf White Pages

Green Pages- Technische Details zu den angebotenen Web Services und zu ihrem Zugang- WSDL-Beschreibungen- Binding Informationen

Web-Service

UDDI nach: [CBL], [UDDI], [WebS]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

• UPnP-System besteht aus drei Grundkomponenten: den UPnP fähigen Geräten den Diensten den (Benutzer-) Kontrollpunkten (Control Point) einer optionalen zentralen Komponente (SSDP-Proxy)


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23


• 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)

SSDP-Proxy

ServiceRegistrierung [3]

ServiceAntwort [4]

ServiceAntwort [4]

Client

Server

Multicast-Anfrage[1] [2]

1) Control Point sendet Dienst-Anfrage über Multicast ins Netz

2) passender Service antwortet über UDP

3) Dienst registiert sich bei der zentralen Kommponente SSDP-Proxy

4) Dienstanfragen durch Proxy beantwortet


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23


• 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

4) Eventing 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

UPnP nach: [MC], [SDuJ], [SDP], [UPnP]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

• Ziele von JINI 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


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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 Teilen1) Infrastruktur (Verwaltung / Verteilung)2) Programmiermodell (Diensterstellung)3) Services

Prozessor

Betriebssystem

Java 2 PlattformJVM, RMI, Netzwerk, Sicherheit, Serialisierung

JINIInfrastruktur: Discovery, Join, Lookup

Prog.-Modell: Events, Transaktionen, Leasing

JINI ServicesDruckdienste Kartendienste ÖPNV

Prozessor

Betriebssystem

Java 2 PlattformJVM, RMI, Netzwerk, Sicherheit, Serialisierung

JINIInfrastruktur: Discovery, Join, Lookup

Prog.-Modell: Events, Transaktionen, Leasing

JINI ServicesDruckdienste Kartendienste ÖPNV

Netzwerk

Service-Protokoll

Discovery, Join, Lookup

Java-RMI


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Java Intelligent Network Infrastructure Zentrale Konzepte

• Lookup und Discovery besteht aus drei Protokollteilen:

• Lookup-Service findet und löst Dienste auf, registriert sie identifiziert Dienste über Typ-Match-Regeln oder Attribute Kontaktvermittlung zwischen Dienstanbieter und -nutzer

• Leasing 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

als Dienst implementiert

Discovery (Client und Server)Join (Server)Lookup (Client)

Corba/JINI


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Java Intelligent Network Infrastructure Ablauf

Web-Server Lookup-ServiceDruck-Service

1 Discovery

3 Registrierung

4

6

5LS-Service-Proxy

2

8

LS-Service-Proxy

Use-Service

Look

upDisc

over

y

Druck-Service-Proxy

7

JINI nach: [JAOS], [JINI], [JINI 01], [JINISun], [SDuJ], [SDP]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

schwaches Sicherheitskonzept keine bzw. schlechte Interoperatibilität beschränkte Funktionalität, nur für TCP/IP

Spezifikation enthält keine Sicherheitsaspekte vor allem auf Vermittlung von Hardware

ausgerichtet

nur für TCP/IP-Netzwerke Spezifikation enthält keine Sicherheitsaspekte keine attributbasierte Suche von Diensten keine Interoperabilität

setzt JVM auf jedem Endgerät voraus nur für TCP/IP-Netzwerke (im Standard) ressourcenhungrig (CPU, Speicher) unübersichtliche, komplizierte API von JINI

Service Discovery ProtokolleVor- und Nachteile

• Service Location Protokoll einfache Implementierung geeignet auch für beschränkte HW flexibel und skalierbar

• Salutation netzwerkunabhängig Kollaboration von SM untereinander unabhängig von Programmiersprache

• Universal Plug & Play XML für Protokollstandardisierung aufbauend auf Protokollen niedriger

Netzwerkebene (effizient) mit XML gute Dienstbeschreibung möglich

• JINI großer Funktionsumfang plattformunabhängig/objektorientiert Sicherheitskonzept (Policy/Sandbox) Mobile-Code Feature


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Fazit & BewertungAnforderungen/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

- Client wählt im Browser www.upb.de- Splash-Screen mit Dienstangebot und Softwareinstallationsaufforderung

Zentrale Komponente

DienstClient

regelm. Dienststatus abfragen

Dienst registrieren

Client registrieren

Software installieren

best. Dienst anfordern

Dienstadresse mitteilen

Interaktion Dienst / Client


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

Vorschlag 2: Universal Plug & Play 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

Übersicht


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Fragen & Diskussion

Vielen Dank für Ihre Aufmerksamkeit.

Bitte jetzt um Fragen und Diskussion


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Quellenangaben

[CBL]: Computer-Base Lexikon [SDuJ]: C. Hanin & B. PenzComputerBase Medien Gbr, 2004 Service Discovery und Jinihttp://www.computerbase.de Seminar ang. Informatik, SS 2002

[JAOS]: Jini Architectural Overview [SLP]: Homepage der OpenSLP-GruppeSun Microsystems, 1999 http://www.openslp.org

[JINI]: Homepage der JINI-Gruppe [SLPTW]:Charles Perkinshttp://www.jini.org SLP Technical Whitepaper, Sun 1997http://www.playground.sun.com/srvloc

[JINI 01]: Scott Oaks & Henry Wong: [UDDI]: Homepage der UDDI-Gruppe JINI in a Nutshell, Deutsche Ausgabe http://www.uddi.org O’Reilly Verlag Köln, 1. Auflage 2001

[JINISun]: Homepage von Jini bei SUN [UPnP]: Homepage des UPnP Forumshttp://wwws.sun.com/software/jini http://www.upnp.org

[MC]: Developing Ad-Hoc Component [TS]: Tine Schneider:Systems for Mobile Computing Basistechnologien für spontaneHauptseminar Prof. Dr. Broy Vernetzung, Seminar SS 2001TU München, WS 2000 / 2001 Eberhard-Karls-Uni-Tübingen

[MCFS]: Antonino Leanza: [SDP]: Mirco Tegler: Fachseminar Mobile Computing Service Discovery Protokolle Juni 2000 Seminar technische Informatik, Januar

03[Salutation]: Homepage Salutation Consortium [WebS]: Ralf Heese:

http://www.salutation.org GIS-Datenbank für webservicebasierten

Zugriff auf standortbez. InformationenDiplomarbeit Humboldt Universität Berlin


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Background

Backgroundfolien mitzusätzlichen Informationen


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

BackgroundÜbersicht über die Protokolle

Protokoll SLP Salutation UPnP JiniEntwickler / Organisation

IETFSalutation

ConsortiumMicrosoft Sun

Entstehungsjahr 1997 1995 1999 1998

Status In Entwicklung Im GebrauchÜbergang Marktreife

ÜbergangMarktreife

Lizenz /Spezifikation

Open Source Open SourceOpen

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 StringJava

Interface

Server-Registrierung

Authenticated Multicast

nur lokalMulticast /

Unicast

Multicast mit TCP-Callback

Code-Mobilität nein nein nein Java-RMI

Sicherheitsmodell nein Ja Ja Java-basiert

HW / SW - Anforderungen

TCP / IP keineTCP / IP,

HTTP, XMLJava, JVMJRE 1.2 >

Interoperationmit anderen SDPs

nein ja nein ja


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

BackgroundBroadcast, 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

• Multicast 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]


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

BackgroundUnterschiede 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

• JINI 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.


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

BackgroundService 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 Schema eines Netzwerkdruckers:

service:printer://lj4050.tum.de:1020/queue1scopes = profs, pg-lbs, administratorprinter-name = lj4050printer-model= HP LJ4050 Nprinter-location = Room 409color-supported = falsepages-per-minute = 9sides-supported = one-sided, two-sided

Beispielprädikat: (&(q<=3) (pages-per-minute>6))


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

Universal Description, Discoveryand Integration (UDDI)

• Grundlegende Architektur von UDDI

ServiceAnbieter

ServiceNutzer

ServiceVerzeichnis

Binden(Kommunikation

über SOAP-Nachrichten)

PublizierenFinden

WSDLWSDL

UDDI

Kommunikationüber SOAP

Universal Description,Discovery and Integration alsöffentliches Verzeichnis


an

Pep

pin

g, N

ovem

ber

20

04

11.04.23

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

Eigenschaften von Web-Services 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)

ag kao betriebssysteme und verteilte systeme institut für informatik universität paderborn...

Documents

service registry

lbs folie

service availab

pg lbs

user agents multicast

server folie

lbs seminararbeit

salutation managers