Motivation

1. Discovery von LBSSeminararbeitvon Florian Peppingim Rahmen der Projektgruppe„Location Based Services for Wireless Devices“

2. Motivation • 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

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

4. 1: Registrierung 2: Dienstanfrage 3: Antwort 4: Dienstnutzung Dienstvermittler 2 1 3 Dienstnutzer Dienstanbieter 4 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 nach ([MCFS])

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

6. Service Location Protokoll (SLP 2) • Zwei unterschiedliche Ausführungsmodi • 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) Directory Agent User Agent Service Registration Service Request Service Agent Service Ack Service Reply Service

7. Zwei unterschiedliche Ausführungsmodi 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 Location Protokoll (SLP 3) Service Agent User Agent Service Request Service Agent Service Reply SLP nach: [MC], [SDuJ], [SLP], [SDP], [SLPTW], [TS]

8. Server Handy Laptop Desktop Server SM-API Salutation Application Interface SM-API Salutation Manager Salutation Manager Salutation Manager Transport Man. Transport Man. Transport Manager Transport Manager Salutation Protocol Salutation Protocol Transport Layer Transport Layer 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

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

10. 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]

11. UDDI White Pages - Namensregister, sortiert nach Namen - Auflistung der Anbieter mit Detailangaben - Kontaktinformationen (Telefon, Telefax, Mail,…) - textuelle Beschreibung 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 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 UDDI nach: [CBL], [UDDI], [WebS] Web-Service Architektur

12. 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, dassGerä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)

13. Service Registrierung [3] SSDP-Proxy Server Multicast- Anfrage [1] [2] Service Antwort [4] Service Antwort [4] Client Universal Plug and Play (UPnP 2) • Service Discovery und Vernetzung in 5 Schritten: • 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) • Control Point sendet Dienst-Anfrage über Multicast ins Netz • passender Service antwortet über UDP • Dienst registiert sich bei der zentralen Kommponente SSDP-Proxy • Dienstanfragen durch Proxy beantwortet

14. Universal Plug and Play (UPnP 3) • Service Discovery und Vernetzung in 5 Schritten: • Description • Dienstbeschreibung in Form von XML-Dokumenten • Download via HTTP von der mitgeteilten URL • Inhalt: u. a. Hersteller, Statusvariablen, Dienstangebot, Steuerungs-URL‘s • 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 • 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) • 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]

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

16. JINI Services Druckdienste Kartendienste ÖPNV JINI Services Druckdienste Kartendienste ÖPNV JINI Infrastruktur: Discovery, Join, Lookup Prog.-Modell: Events, Transaktionen, Leasing JINI Infrastruktur: Discovery, Join, Lookup Prog.-Modell: Events, Transaktionen, Leasing Java 2 Plattform JVM, RMI, Netzwerk, Sicherheit, Serialisierung Java 2 Plattform JVM, RMI, Netzwerk, Sicherheit, Serialisierung Betriebssystem Betriebssystem Prozessor Prozessor Service-Protokoll Discovery, Join, Lookup Java-RMI Netzwerk 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 • Infrastruktur (Verwaltung / Verteilung) • Programmiermodell (Diensterstellung) • Services

17. 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 Discovery (Client und Server)Join (Server)Lookup (Client) als Dienst implementiert Corba/JINI

18. Web-Server Druck-Service Lookup-Service Discovery 1 2 Registrierung 3 LS-Service-Proxy 5 Use-Service 8 7 LS-Service-Proxy Lookup 6 Discovery Druck-Service-Proxy 4 Java Intelligent Network Infrastructure Ablauf JINI nach:[JAOS], [JINI], [JINI 01], [JINISun], [SDuJ], [SDP]

19. 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 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 niedrigerNetzwerkebene (effizient) mit XML gute Dienstbeschreibung möglich JINI großer Funktionsumfang plattformunabhängig/objektorientiert Sicherheitskonzept (Policy/Sandbox) Mobile-Code Feature Service Discovery ProtokolleVor- und Nachteile

20. Interaktion Dienst / Client Zentrale Komponente Client registrieren Dienst registrieren Software installieren Client Dienst best. Dienst anfordern Dienstadresse mitteilen regelm. Dienststatus abfragen 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

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

22. Fragen & Diskussion Vielen Dank für Ihre Aufmerksamkeit. Bitte jetzt um Fragen und Diskussion

23. Quellenangaben [CBL]: Computer-Base Lexikon [SDuJ]: C. Hanin & B. Penz ComputerBase Medien Gbr, 2004 Service Discovery und Jini http://www.computerbase.de Seminar ang. Informatik, SS 2002 [JAOS]: Jini Architectural Overview [SLP]: Homepage der OpenSLP-Gruppe Sun Microsystems, 1999 http://www.openslp.org [JINI]: Homepage der JINI-Gruppe [SLPTW]: Charles Perkins http://www.jini.org SLP Technical Whitepaper, Sun 1997 http://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 Forums http://wwws.sun.com/software/jinihttp://www.upnp.org [MC]: Developing Ad-Hoc Component [TS]: Tine Schneider: Systems for Mobile Computing Basistechnologien für spontane Hauptseminar Prof. Dr. Broy Vernetzung, Seminar SS 2001 TU 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. Informationen Diplomarbeit Humboldt Universität Berlin

24. Background Backgroundfolien mit zusätzlichen Informationen

25. BackgroundÜbersicht über die Protokolle

26. 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 Teilnehmeroder 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]

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

28. 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/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))

29. Universal Description, Discoveryand Integration (UDDI) • Grundlegende Architektur von UDDI Universal Description,Discovery and Integration als öffentliches Verzeichnis UDDI Service Verzeichnis Finden Publizieren WSDL WSDL Kommunikation über SOAP Service Nutzer Service Anbieter Binden (Kommunikation über SOAP-Nachrichten)

30. 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)