Discovery von LBS Seminararbeit von Florian Pepping im Rahmen der Projektgruppe „Location Based Services for Wireless Devices“ Kommentare zur Startfolie:

Präsentation zum Thema: "Discovery von LBS Seminararbeit von Florian Pepping im Rahmen der Projektgruppe „Location Based Services for Wireless Devices“ Kommentare zur Startfolie:"—  Präsentation transkript:

1 Discovery von LBS Seminararbeit von Florian Pepping im Rahmen der Projektgruppe „Location Based Services for Wireless Devices“ Kommentare zur Startfolie: Begrüßung: Herr Kao, Herr Rerrer, Mitglieder der Projektgruppe, evtl. Mitarbeiter von Siemens Vorstellung von Florian Pepping Vorstellung des Themas

2 Motivation Wieso: Weshalb: Darum:
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 Kommentare zur Folie Motivation: Wieso: folgende zentrale Fragen sollen innerhalb dieses Vortrages beantwortet werden: Service Discovery zusammen mit Location Based Services unserer Projektgruppe? Service Discovery, was steckt konzeptionell und aufgabenmäßig dahinter? zur ersten Frage: Service Discovery spielt bei unserer Projektgruppe eine zentrale Rolle, da sie die Verbindung zwischen den zur Verfügung stehenden Diensten und den Benutzern herstellt. Sie ermöglicht gleichzeitig eine Auswahl vorhandener Dienste und erlaubt die Spezifikation der Dienste. Ohne Service Discovery müssten unsere angebotenen Dienste, deren Funktionen und Adressen statisch bekannt sein, was einer dynamischen Einbindung von Endgeräten in ein Netz widerspricht. zur zweiten Frage: Service Dicovery basiert auf unterschiedlichen Protokollen und Mechanismen, die ein dynamisches Auffinden von Diensten ermöglichen. Hierzu wird in der Regel auf Konzepte wir Broadcast und Unicast zurückgegriffen und/oder eine zentrale Komponente zur Verfügung gestellt. Wie diese Konzepte im Detail aussehen und welche Protokolle zur Verfügung stehen, soll im Laufe des Vortrages verdeutlicht werden. Weshalb: Frage: Warum ist sind Location Based Services überhaupt interessant? - Anzahl netzfähiger mobiler Endgeräte steigt rasant (Handy‘s, PDA‘s, Laptop‘s, evtl. Digitalkamera‘s, usw.) - Netzwerke stellen immer mehr Dienste zur Verfügung (Prinzip Angebot und Nachfrage / je mehr Endgeräte, desto mehr Dienste und andersherum) - User erwarten mehr und mehr eine einfache und sofortige Nutzung von Diensten ohne manuellen administrativen Aufwand Ziel: jedes Gerät soll Dienste anderer Geräte nutzen können (sofern berechtigt) z. B. Drucker, Rechendienste, Kartendienste, ... dynamische Anpassung an das jeweilige Umfeld und die zur Verfügung stehenden Dienste (bei z. B. Bewegung durch ein Gebäude) zur Verfügung stehende Dienste müssen benutzt, verwaltet und gefunden werden können Ziel: idealerweise kein oder nur sehr geringer Administrationsaufwand Darum: Service Discovery als leistungsfähige Konzepte, die diese Aufgaben übernehmen und erfüllen Service Discovery als Verbindungsglied zwischen den vorhandenen Diensten und den Clients, die die vorhandenen Dienste benutzen möchten Service Discovery als zentrale Dienstverwaltung und Pool, bei dem die Informationen zusammenlaufen

3 Dienst und Service Discovery Protokoll Protokolle
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 Kommentare zur Folie Agenda: kurze Vorstellung, was Inhalt dieses Vortrags sein soll - kurze Erläuterung was ein Dienst ist und die grundsätzliche Funktionsweise und Aufgabe von Service Discovery Protokollen - anschließend Präsentation der unterschiedlichen Protokolle (UDDI nur angeschnitten, da für unsere PG nicht wirklich relevant) abschließend Zusammenfassung der Vor- und Nachteile der unterschiedlichen Protokolle und eine Bewertung ihrer FunktionalitätS

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 Kommentare zur Folie Dienst und Service Discovery Protokoll: Dienst: ein Dienst ist eine abgeschlossene Programmeinheit, die eine Menge von unterschiedlichen Funktionen besitzen kann. Dies können spezielle Angebote wie z. B. Verschlüsselung, Bildberechnungen o. ä. sein. Außerdem können Gerätetreiber zur Verfügung gestellt werden oder spezielle Geräte verfügbar gemacht werden, ein Dienst wird immer von einem Dienstanbieter erbracht und von einem Dienstnutzer angefragt bzw. verwendet die Fülle von möglichen Diensten wird in der Regel in vier Kategorien aufgeteilt: - Infrastrukturdienste: Nutzung von Geräten in der lokalen Umgebung wie Drucker, Fax, Telefon, Server, etc. - Mobilitätsdienste: automatische Anrufweiterleitung, Übertragung der gewohnten Arbeitsoberfläche auf fremde Geräte - Informationsdienste: push: Information wird unaufgefordert zur Verfügung gestellt pull: Anfordern einer speziellen Information Ortungsdienste: Möglichkeit, den eigenen Standort oder einer anderen Person zu bestimmen Service Discovery Protokoll: stellen einen Mechanismus für das dynamische Entdecken der verfügbaren Dienste in einem Netz zur Verfügung übernehmen idealerweise die Integration von neuen Diensten in die bestehende Umgebung und sind selbstkonfigurierend Hauptziele: keinerlei manuelle Konfiguration keinerlei manuelle Administration sammeln alle notwendigen Informationen, um eine Vermittlung zwischen Server/Dienstanbieter und Client/Dienstnutzer durchführen zu können - erlauben durchsuchen und Browsen des Dienstes - erlauben Auswahl des richtigen Dienstes - ermöglichen Benutzung des Dienstes, indem zwischen Client und Server vermittelt wird alle hier vorgestellten Protokolle arbeiten unter dem Paradigma der „Closed World Assumption“ - Struktur der Dienste ist im Voraus bekannt - Dienste sind mittels spezifischer Schnittstellen beschrieben - für die Zusammenarbeit von Dienstanbieter und Dienstnutzer werden vorher Schnittstellen definiert, die von beiden Seiten eingehalten werden müssen - die für die „Open World Assumption“ notwendige semantische Beschreibung und künstliche Intelligenz wird somit umgangen Vorstellung des schematischen Ablauf‘s anhand der Grafik Dienstvermittler Dienstnutzer Dienstanbieter 1 2 3 4 1: Registrierung 2: Dienstanfrage 3: Antwort 4: Dienstnutzung nach ([MCFS])

5 Service Location Protokoll (SLP 1)
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 Kommentare zur Folie Service Location Protokoll (SLP 1): das Service Location Protokoll ist ein Standard der Internet Engeineering Task Force wurde 1997 spezifiziert und im Laufe der Jahre mehrfach überarbeitet. Aktuell ist SLPv3 (darin wurden Anpassungen an IPv6 vorgenommen) definiert wird SLP durch eine Reihe von Request for Comments, die die genaue Spezifikation des Protokolls enthalten (u. a. 2608, 2609, 2614, 2165, 3059 und 3082) Ziel von SLP ist das Auffinden von Diensten in Netzwerken definiert nach Diensttypen und Attributen wird auf eine Anfrage ein passender Dienst gefunden, liefert SLP die URL mit der Adresse des Dienstes zurück SLP beinhaltet aber keine weiteren über die Discovery hinausgehende Funktionen; hat der Client einmal die URL des Dienstes erhalten, ist er für die weitere Kommunikation selbst verantwortlich (die Client-Anwendung muss den Dienst mit einem ihr bekannten Protokoll selbst ansprechen) SLP ist primär für unternehmensweite Netze konzipiert, die gemeinsame Dienste haben auch wenn es Mechanismen beinhaltet um für größere Netze zu skalieren (z. B. Internet). Hierfür ist es aber ursprünglich nicht gedacht. Unterstützer von SLP sind sowohl Novell und Apple, die SLP in ihren Produkten verwenden und integriert haben die Firma Sun, bei der die Entwicklung von SLP durchgeführt wurde, verhält sich wegen JINI neutral gegenüber SLP zentrale Komponenten von SLP und ihre Funktion: Benutzeragent / User Agent (UA): Ein Prozeß, der im Auftrag des Benutzers arbeitet, um Attribute und Konfigurationen von Diensten aufzufinden. Der User-Agent holt Informationen über Dienste von Service Agents oder Directory Agents ein. Dienstagent / Service Agent (SA): Ein Prozeß, der im Auftrag eines oder mehrerer Dienste arbeitet, um Attribute und Konfigurationen der Dienste anzubieten. Verzeichnisagent / Directory Agent (DA): Ein Prozeß, der Informationen von Service Agents sammelt, um eine zentrale Datenbasis für Dienstinformationen zu bilden, auf die von User Agents effizient zugegriffen werden kann. Ein Directory Agent ist nicht zwangsweise notwendig, er verbessert aber die Skalierbarkeit. das initiale Finden der Komponenten wird über Multicast realisiert, indem ein definiertes Paket ins Netz gesendet wird. Wurde eine passende Komponente gefunden wird im Folgenden dann Unicast zur Kommunikation verwendet. User Agents bzw. Service Agents sind von der Client-Anwendung bzw. dem eigentlichen Dienst getrennt. Die eigentliche Funktion des Dienstes spielt für sie keine Rolle. Sie übernehmen nur die Vermittelung zwischen den Komponenten, der Rest spielt für die keine Rolle Multicast

6 Service Location Protokoll (SLP 2)
Zwei unterschiedliche Ausführungsmodi 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 User Agent Service Request Service Registration Service Agent Kommentare zur Folie Service Location Protokoll (SLP 2): grundsätzlich bietet das SLP-Protokoll zwei unterschiedliche Ausführungsmodi an. Einmal mit Directory Agent und einmal ohne Directory Agent. ist ein Directory Agent vorhanden, verringert dies vor allem die Netzwerklast und führt zu einer besseren Skalierbarkeit. Gleichzeitig muss der Directory Agent aber auch immer zur Verfügung stehen, d.h. online sein (In größeren Netzwerken können Broadcast- und Multicast-Nachrichten zuviel Netzwerkverkehr erzeugen. Um dieses Problem in den Griff zu bekommen, erlaubt SLP den Einsatz von Directory Agents, die das n-zu-m-Verhältnis der User- und Service Agents zu zwei n-zu-1 und m-zu-1-Verhältnissen reduzieren. ein Directory Agent verhält sich wie ein Proxy mit Cache-Funktion. User Agents und Service Agents kommunizieren direkt mit dem Directory Agent. Der Directory Agent sammelt die Informationen der Dienste und leitet sie auf Anfrage an die Clients weiter. ist in einem Netzwerk Multicast und Broadcast ausgeschaltet, können die Adressen der Directory Agents statisch definiert werden, so dass auch Dienste in anderen Netzsegmenten gefunden und genutzt werden können ein Service wird definiert durch einen Typnamen, eine URL sowie einige Typ-Wert-Paare zur Beschreibung des Dienstes (Attribute) Service Agent: will ein Host einen Dienst anbieten, muss er über einen Dienstagenten verfügen Dienstagent registriert Dienst beim Verzeichnisagenten über Multicast bzw. Unicast, wenn Adresse schon bekannt beide Agenten kommunizieren anschließend in freien, aber fest definierten Zeitintervallen miteinander (Dienst noch verfügbar?, Adress- oder Statusänderung?) User Agent: benötigt ein Client einen Netzwerkdienst, so muss zum Auffinden des Dienstes ein Benutzeragent vorhanden sein Benutzeragent fragt beim Verzeichnisagenten nach, ob es einen gewünschten Dienst gibt wenn ja, teilt Verzeichnisagent die entsprechende Netzwerkadresse mit Antworten auf Request sind grundsätzlich Strings, die nach einem festgelegten Schema aufgebaut sind: service:abstracttype:concretetype://address z. B. service:printer:lpr: Service Ack Service Reply Service

7 Service Location Protokoll (SLP 3)
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 User Agent Service Agent Kommentare zur Folie Service Location Protokoll (SLP 3): ist kein Directory Agent vorhanden, kommunizieren die User Agents direkt mit den Service Agents, indem sie einen Multicast über das Netzwerk durchführen. im Multicast ist die Diensttypisierung sowie Senderadresse enthalten, so dass Service Agents, die den gewünschten Dienst anbieten, direkt dem User Agent antworten können in der Antwort ist die Dienstspezifikation enthalten und die Adresse des Services, so dass der Client dann direkt per Unicast auf den Dienst zugreifen kann Anschließend findet die normale Servicenutzung statt, wie sie eben schon skizziert worden ist die Wahl der geeigneten Betriebsart hängt von mehreren Faktoren ab: Administrationsaufwand zur Einrichtung des Systems und Anpassungen Geschwindigkeit/ Bandbreite des Netzwerkes Skalierbarkeit des Systems Service Request Service Agent Service Reply SLP nach: [MC], [SDuJ], [SLP], [SDP], [SLPTW], [TS]

8 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 Kommentare zur Folie Salutation (1): der Name Salutation wurde in Anspielung auf Anrede/Begrüßung gewählt, was als Aufgabe mit diesem Protokoll umgesetzt werden sollte die Entwicklung von Salutation wird durch das Salutation Consortium vorangetrieben, welches 1995 gegründet wurde (es ist eine nicht gewinnorientierte Vereinigung, die die Entwicklung koordiniert und als Zentrale die Sourcen verwaltet und verteilt) Salutation ist ein offener Standard, der unabhängig von Betriebssystemen, Kommunikationsprotokollen und Hardware ist. die Entwicklung wird vor allem von der Forschung im Bereich intelligenter Agenten vorangetrieben und weniger von Unternehmen Ziel: das Ziel von Salutation ist, vor allem Bürogeräte, wie Faxe, Computer und Drucker zu vernetzen oder globaler gesagt, die Kommunikation heterogener Komponenten zu ermöglichen Salutation ist so konzipiert, dass heterogene Kommunikationstechnologien problemlos unterstützt werden können. Durch eine Middleware werden die unteren Schichten des ISO-OSI Modells vor den oberen Schichten verdeckt und die Kommunikation durch den Salutation Manager verwaltet. durch die Kapselung der eigentlichen Dienstfunktionalität durch den Salutation Manager, können unterschiedlichste Endgeräte einfach unterstützt werden, indem lediglich ihre Kommunikationsprotokolle implementiert werden Architektur von Salutation: in der Abbildung links ist ein beliebiger Server, der neben einem Dienst mit einem Salutation Manager und einem Transport Manager ausgestattet ist er benutzt das Salutation Discovery Protokoll, um mit Hilfe des Salutation Managers andere Dienste zu finden oder zu nutzen der Salutation Manager leitet die Anfrage weiter an den Transport Manager, der die Netzwerkkommunikation mit anderen Geräte- oder Dienst-Servern übernimmt der angesprochene Dienst-Server kann dabei gleichzeitig Client und Server sein, also sowohl Dienste zur Verfügung stellen, als auch Dienste nutzen die Unterstützung heterogener Protokolle und Endgeräte wird durch den Transportmanager realisiert, der für jedes Protokoll spezifisch implementiert werden muss der Salutation Manager und somit auch die Dienstimplementierung ist aber immer dieselbe, so dass eine Unterstützung unterschiedlicher Protokolle leicht realisiert werden kann das Salutation Application Interface stellt die programmiertechnische Verbindung zwischen der Dienst-Funktionalität und dem Salutation Manager zur Verfügung Server SM-API Salutation Manager Transport Manager Handy Transport Layer Salutation Protocol Desktop Transport Man. Laptop Salutation Application Interface

9 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 Kommentare zur Folie Salutation (2): The Salutation protocol aims to integrate different devices into a network by supplying them with a standard communications and API specification for discovering the capabilities of other entities in a network. As shown in Figure 1, this architecture is based on a model called the Salutation Manager (SLM), which is similar to the lookup service in Jini and functions as a service broker for services in the network. The Salutation architecture enables transaction between function units representing essential features of a service (e.g. fax, print, scan etc). Each functional unit is composed of descriptive attribute record. Another important entity called transport manager that isolate SLM from particular transport protocol and provide SLM reliable communication channels independent transport layer. SLM may sit one more than one Transport Manager attaching to different network, and provide a transport-independent interface to Server and Client applications.

10 Salutation nach: [SDuJ], [Salutation], [SDP], [TS]
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 Kommentare zur Folie Salutation (3): xsmx Salutation nach: [SDuJ], [Salutation], [SDP], [TS]

11 Universal Description, Discovery and Integration (UDDI)
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] Kommentar zur Folie Universal Description, Discovery and Integration (UDDI): Verzeichnisdienst für Webservices, sprich eine Art gelbe Seiten für die Webservices, die im WWW angeboten werden UDDI wurde im Rahmen einer Kooperation von mehreren hundert Firmen, darunter SAP, IBM, Sun, Oracle, Compaq, HP, Intel und Microsoft, definiert gesamter Standard basiert auf offenen Standards und Technologien ohne Eigentümer Grundidee von UDDI ist, ein öffentliches Register bereitzustellen, durch welches Informationen über Unternehmen und ihre Webservices in einer strukturierten Weise verwaltet werden sollen. UDDI bietet einen Mechanismus für einen Dienstnehmer, um einen Webservice dynamisch finden zu können. Man kann sich UDDI als DNS-Service für Business-Anwendungen vorstellen. UDDI Register hat zwei Nutzertypen: Unternehmen, die ihre Webservices veröffentlichen möchten und Anwendungen, die eine bestimmte Art von Webservice benutzen möchten. generell standardisiert UDDI das Publizieren und Finden von Informationen über Webservices, indem es das Format für Beschreibungen und Anfragen über XML definiert und festlegt die Verwaltung, sprich das Eintragen, Ändern und Abfragen von Einträgen aus dem Verzeichnis wird durch SOAP-basierte API‘s ermöglicht, die zusammen in etwa 40 Operationen definieren. Die API‘s unterscheiden sich dabei nach Inquiry-API und Publishing-API, je nachdem, welche Operationen gerade benötigt werden.  Inquiry-API: Definiert 25 Operationen, um die Registry nach Services, Unternehmen oder Branchen zu durchsuchen  Publishing-API: Definiert 15 Operationen, um Informationen in der Registry zu verwalten, zu ändern und einzutragen UDDI wurde für das Internet mit stark heterogenen Strukturen konzipiert. Es soll plattformübergreifend und protokollunabhängig verwendet werden können. Darum auch als Basis die etablierten Protokolle TCP/IP, XML, SOAP und WSDL die Informationen im UDDI-Verzeichnis werden in drei unterschiedliche Kategorien aufgeteilt: white-pages: Die äußere Hülle beinhaltet die Geschäftsinformationen, wozu der Firmennamen, die Kontaktadresse, eine Beschreibung sowie die Kategorisierung des Unternehmens gehören. Diese Daten dienen dem Auffinden eines bestimmten Serviceanbieters, falls bereits Teilinformationen, z. B. der Firmenname, bekannt sind Textbeschreibungen über den Serviceanbieter Kontaktinformation (URL, , Postadresse, Telefonnummer...) yellow-pages: Branchenverzeichnis nach z. B.Geschäftskategorien (Industrie, Produkte, Dienst-leistungen, geographischer Ort) Spezifische Suche gemäß verschiedener Taxonomien (Ort, Dienstart,...) Verweist auf White Pages green-pages: Beinhalten die technischen und geschäftlichen Informationen über die Webservices, wie z. B. Service Beschreibungen, Binding Information, Zeiger auf WSDL Definitionen usw. Allgemein: alle Details, die bekannt sein müssen um Web Services zu finden und darauf zuzugreifen. SOAP (Simple Object Access Protocol): SOAP ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf die Dienste anderer Standards, XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP. 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 Architektur

12 Universal Plug and Play (UPnP 1)
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) Kommentare zur Folie Universal Plug and Play (UPnP 1): xsmx Universal Plug and Play (UPnP): Offener Standard, der von Microsoft seit Windows 98 für alle Plattformen zur Verfügung steht Microsoft hat sowohl die Spezifikation, einen Programmier-Guide als auch Beispielimplementierungen veröffentlicht die Entwicklung von UPnP wird durch das UPnP-Forum vorangetrieben Gegründet wurde dieses Forum 1999 es besteht heute aus etwa 450 Mitgliedern, angeführt von Microsoft und Hewlett-Packard Ziel von UPnP ist die Erweiterung der von Windows bekannten Plug & Play-Technologire auch über die physikalischen Rechnergrenzen hinweg - der angestrebte Einsatzort von UPnP ist die Vernetzung von kleinen Geräten im Heim-/Büro-Bereich und deren Fernsteuerung. UPnP basiert auf keiner spezifischen Programmiersprache sondern ist protokollbasiert hier bei kommen vor allem HTTP und XML zum Einsatz, sowie TCP/IP als Trägerprotokoll UPnP beinhaltet einen Webbrowser, um seine Komponenten zu steuern und nutzt HTTP-Messages um Anweisungen zu geben

13 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) SSDP-Proxy Service Registrierung [3] Antwort [4] Client Server Multicast- Anfrage [1] [2] Kommentare zur Folie Universal Plug and Play (UPnP 2): xsmx 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 Kommentare zur Folie Universal Plug and Play (UPnP 3): xsmx 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 Kommentare zur Folie Java Intelligent Network Infrastructure: JINI ist ein von der Firma Sun Microsystems definierter Standard, der die Kommunikation von Geräten und Diensten untereinander unterstützen soll. Der Standard besteht aus einem Satz von API‘s, die die notwendigen Funktionen eines Service Discovery Protokolls realisieren und die Anbindung der unterschiedlichen Komponenten ermöglichen. Die API ist momentan nicht standardmäßig im Java SDK enthalten, da sie aufgrund von Weiterentwicklungen und Änderungen noch starken Anpassungen unterliegt. Teilweise sind unter anderem die Versionen 1 und 2 von JINI inkompatibel, da Klassen umbenannt oder verschoben wurden JINI wurde erstmal im Jahre 1999 veröffentlicht und seitdem ständig verändert und weiterentwickelt. Momentan aktuell ist Version 2.0_002. Die Vision bzw. das Paradigma von Sun bei der Erstellung von JINI ist ein „Network Plug & Play“ so wie es für viele Geräte heute die Betriebssysteme bieten. Es soll eine Dienst und Gerätenutzung ad-hoc und ohne Einstellung ermöglicht werden Ziele von JINI: Vorlesen und jeweils eine kleine Erklärung beifügen.

16 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 Prozessor Betriebssystem Java 2 Plattform JVM, RMI, Netzwerk, Sicherheit, Serialisierung JINI Infrastruktur: Discovery, Join, Lookup Prog.-Modell: Events, Transaktionen, Leasing JINI Services Druckdienste Kartendienste ÖPNV Netzwerk Service-Protokoll Discovery, Join, Lookup Java-RMI Kommentare zur Folie Java Intelligent Network Infrastructure – Architektur:

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 Kommentare zur Folie Java Intelligent Network Infrastructure – Zentrale Konzepte: Corba/JINI

18 Java Intelligent Network Infrastructure Ablauf
Web-Server Lookup-Service Druck-Service 1 Discovery 3 Registrierung 4 6 5 LS-Service-Proxy 2 8 Use-Service Lookup Druck-Service-Proxy 7 Kommentare zur Folie Java Intelligent Network Infrastructure – Ablauf: zu 1) ein neuer Druckservice wird in das Netzwerk eingebunden und will seine Dienst zur Verfügung stellen. Er führt zunächst über den Discovery-Dienst (Join) ein Multicast auf das Netzwerk aus und der Lookup-Service wird aufgefunden. zu 2) Download des Lookup-Service-Proxies (serialisiertes Objekt) entweder direkt über eine TCP-Callback-Verbindung zum Lookup-Service oder von einem beliebigen Webserver, der diesen Code enthält. Das Interface des Proxies, genannt Service-Registrar, hält Methoden zur Interaktion mit dem Lookup-Service bereit, auf die der Service nun zurückgreifen kann. Zu den drei wichtigsten Methoden gehören dabei register, mit der sich ein Dienst-Proxy-Objekt beim Lookup-Service anmelden kann lookup, mit deren Hilfe besonders der Klient seine Anfrage beim Lookup-Service macht notify, das an die Remote Events errinnert und mit dem ein Callback beim Lookup-Service bestellt werden kann, falls bestimmte Ereignisse eintreffen. zu 3) anschließend wird über den Proxy die Registrierung des Dienstes beim Lookup-Service durchgeführt, indem der Dienst-Proxy zum Lookup-Service hochgeladen wird. Der Dienst-Proxy enthält dabei neben der Schnittstellenbeschreibung auch noch eine nähere Beschreibung der Funktionalität des neuen Dienstes. zu 4) wird ein neuer Client in das Netzwerk eingebunden, so führt auch er zunächst ein Discovery durch, um den Lookup-Service aufzufinden. Hierbei wird wiederum der Discovery-Dienst verwendet (Lookup) zu 5) wiederum erfolgt der Download des Lookup-Service-Proxies direkt über TCP-Callback zum Lookup-Service oder von einem beliebigen Webserver. Hierdurch wird die Kommunikation zwischen Client und Lookup-Service ermöglicht. zu 6) will ein Client nun einen Dienst benutzen, wird anschließend ein Lookup durchgeführt, indem ein Service-Template-Objekt an den Lookup-Server geschickt wird. Dieses Service-Template-Objekt beschreibt die Anforderungen des Clients an den Dienst und ermöglicht dem Lookup-Service die korrekte Auswahl eines Dienstes. zu 7) wird ein passender Dienst gefunden wird anschließend das zugehörige Proxy-Objekt zum Client übertragen (TCP-Callback oder Webserver) zu 8) der Client kommuniziert über das Proxy-Objekt direkt mit dem Service und teilt ihm seine Aufträge mit JINI nach: [JAOS], [JINI], [JINI 01], [JINISun], [SDuJ], [SDP]

19 Service Discovery Protokolle Vor- 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 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 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 Kommentare zur Folie Service Discovery Protokolle Vor- und Nachteile: Service Location Protokoll: positive Punkte: - geeignet auch für beschränkte Hardware, da sehr effizient und genau auf Aufgabe angepasst - wegen der geringen Komplexität einfache Implementierung negative Punkte: - keine über die Discovery und Vermittlung hinausgehende Funktionalität - kein Sicherheitskonzept und keine Interoperabilität Salutation: positive Punkte: - es kann mehrere Salutation Manager über das Netzwerk verteilt geben, die sich untereinander verständigen und austauschen - sowohl Netzwerk als auch Programmiersprachenunabhängig negative Punkte: - kein Sicherheitskonzept vorhanden - vor allem zur Vermittlung von Hardware-Diensten ausgelegt und deswegen auch nah an der Hardware Universal Plug & Play: positive Punkte: - XML zur Protokollstandardisierung und zur Dienstbeschreibung effizient und gut - aufbauend auf bekannten, etablierten Technologien, die ein effizientes stabiles System ermöglichen negative Punkte: - keine Sicherheitsaspekte in der Spezifikation des Protokolls - keine Interoperabilität mit anderen Service Discovery Protokollen - keine attributbasierte Suche von Diensten, wie z. B. in JINI JINI: positive Punkte: - großer Funktionsumfang über die reine Dienstdiscovery und Dienstvermittlung hinaus - plattformunabhängig - Sicherheitskonzept über Java vorhanden - Mobile-Code-Feature über Java RMI ermöglicht Transfer von Code während der Laufzeit negative Punkte: - setzt JVM auf jedem Endgerät voraus - ressourcenhungrig bzgl. CPU und Speicher

20 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 Dienst Client regelm. Dienststatus abfragen Dienst registrieren Client registrieren Software installieren best. Dienst anfordern Dienstadresse mitteilen Interaktion Dienst / Client Kommentare zur Folie Fazitt & Bewertung - Anforderungen: Anforderungen: zentrale Komponente innerhalb der Universität problemlos verfügbar, da genügend Rechner als Server ständig aktiv. Probleme könnten eher beim Routing von Mutlicasts und Unicasts auftreten, die zur Discovery der Komponenten untereinander benötigt werden. Hier kommt es auf die Konfiguration der Router und Firewalls an keine Bandbreitenbeschränkung vorhanden, da alle Komponenten WLAN unterstützen müssen. Der WLAN Standard b reicht mit einer Übertragungsrate von 11Mbit pro Sekunde für unsere Anforderungen aber völlig aus unsere Zielendgeräte Laptop‘s und PDA‘s verfügen zudem über genügend Rechenleistung und Speicher, damit sie eine JVM und die entsprechende Programmierlogik ohne Probleme aufnehmen können ein Sicherheitskonzept mit Zugangsbeschränkung und Authentifizierung ist wünschenswert. Im ersten Entwicklungszyklus wird dieses zwar aller Voraussicht bei uns nicht benötigt werden, für Weiterentwicklungen sollte es aber zumindest im verwendeten Protokoll verfügbar sein. So können auch Dienste angeboten werden, auf die nur bestimmte Personen, z. B. die Professoren Zugriff haben gute Dienstspezifikationen und eine Dienstsuche über Attribute kann den Erfolg bei der Suche nach Diensten deutlich erhöhen und gleichzeitig Möglichkeiten für weitere Anwendungen öffnen. Die Dienstanfragen werden von einem speziellen Dienst verarbeitet, der z. B. außerhalb der Universität im Internet nach matchenden Diensten auf die Anfrage sucht Plattformunabhängigkeit ist unbedingt erforderlich, da das System unkompliziert sowohl auf Windows, Linux als auch auf Betriebssystemen für PDA‘s lauffähig sein muss. In diesem Zusammenhang ist auch Mobile-Code zu erwähnen, um evtl. Anwendungslogik auf den Client transferieren zu können. Mögliche Systemarchitektur: eine mögliche Systemarchitektur könnte bei uns aus den drei Teilen Dienst, zentrale Komponente und Client bestehen. Folgender Ablauf würde in Bezug auf die Service Discovery Protokolle Sinn machen zentrale Komponenten ist im Netzwerk verfügbar und aktiv ein Dienst wird in das Netzwerk eingebunden und registriert sich über einen Lookup oder direkt bei der zentralen Komponente. Die Adresse der zentralen Komponente kann bei unserer Architektur auch über Konfigurationsdateien mit angegeben werden, da hier eine regelmäßige Änderung nicht zu erwarten ist zur Überprüfung, ob der Dienst noch aktiv ist, werden regelmäßig Statusabfragen durchgeführt Client wird in das Netz eingebunden: ein Client wird in das Netzwerk eingebunden und möchte bestimmte Dienste nutzen. Er wählt im Browser „ und bekommt je nach Aufbau einen Splash-Screen angezeigt oder in die Seite wird ein entsprechender Link eingebunden, der auf eine Seite mit dem Dienstangebot referenziert. sollen Dienste genutzt werden, muss über z. B. Java-Applets soviel Applikationslogik auf der Clientseite vorhanden sein, dass dieser die zentrale Komponente finden kann. anschließend wird mit der zentralen Komponenten kommuniziert und die erweiterte Applikationslogik heruntergeladen und auf dem Client installiert. ab dann kann über das Service Discovery Protokoll ganz normal eine Dienst gesucht werden und mit Hilfe der zentralen Komponente eine Verbindung mit dem entsprechenden Dienst hergestellt werden. Client wählt im Browser Splash-Screen mit Dienstangebot und Softwareinstallationsaufforderung

21 Möglichkeiten für unsere Projektgruppe:
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 Kommentare zur Folie Fazit & Bewertung: Vorschlag 1: Jini - unter Betrachtung aller Vor- und Nachteile der unterschiedlichen Service Discovery Protokolle und in Bezug auf die Anforderungen der Projektgruppe an ein Service Discovery Protokoll erweist sich JINI als bester Kompromiss - Plattformunabhängigkeit erspart viel Arbeit bei der Distribution und Anpassung an unterschiedliche Betriebssysteme - auch wenn es nicht direkt benötigt wird ist ein Sicherheitskonzept vorhanden, was bei zukünftigen Entwicklungen verwendet werden kann - es sind Dokumentationen und Beispielimplementierungen in der von Java bekannten Form vorhanden - Wermutstropfen von JINI sind sicherlich die hohen Anforderungen an CPU und Speicher, auch wenn die für unsere Endgeräte kein Problem darstellen sollten. - Konzept mit der zentralen Komponente „Lookup-Service“ Vorschlag 2: - als Konzept ohne zentrale Komponente bietet sich UPnP für die Verwendung in unserer Projektgruppe an - es setzt auf vorhandene etablierte Technologien auf und ist dadurch stabil und effizient - auch UPnP bietet erweiterte Funktionen wie ein Event-Management und detaillierte Präsentation der Dienste an und ermöglicht eine gute Beschreibung vorhandener Dienste durch XML - Nachteil von UPnP ist das im Augenblick in der Spezifikation nicht vorgesehene Sicherheitskonzept Warum nicht SLP oder Salutation: SLP: - SLP beschränkt sich in der Funktionalität nur auf die Discovery und die Vermittlung zwischen Diensten und Dienstbenutzern und ist daher in seiner weiteren Funktionalität sehr eingeschränkt - SLP bietet nur ein schwaches Sicherheitskonzept auf Basis digitaler Signaturen. Es wird davon ausgegangen, dass alle weitern sicherheitsrelevanten Abfragen durch den Dienst selber durchgeführt werden - auch Eventing und Interoperabilität wird durch SLP nicht unterstützt  eignet sich vor allem dann, wenn Endgeräte mit sehr geringer Leistung zum Einsatz kommen, da SLP einen sehr geringen Ressourcenbedarf hat Salutation: - ist vor allem auf die Vermittlung von Hardware ausgelegt, sprich z. B. von Druckern mit den entsprechenden Treibern usw. - bietet ebenso wie SLP kein Sicherheitskonzept - Dokumentation ist nachdem was ich gefunden habe eher schlecht Übersicht

22 Vielen Dank für Ihre Aufmerksamkeit.
Fragen & Diskussion Vielen Dank für Ihre Aufmerksamkeit. Bitte jetzt um Fragen und Diskussion Kommentare zur Folie Fragen & Diskussion: für die Aufmerksamkeit der Zuhörer bedanken und um Fragen und Diskussion bitten

23 Quellenangaben [CBL]: Computer-Base Lexikon [SDuJ]: C. Hanin & B. Penz
ComputerBase Medien Gbr, Service Discovery und Jini Seminar ang. Informatik, SS 2002 [JAOS]: Jini Architectural Overview [SLP]: Homepage der OpenSLP-Gruppe Sun Microsystems, [JINI]: Homepage der JINI-Gruppe [SLPTW]: Charles Perkins SLP Technical Whitepaper, Sun 1997 [JINI 01]: Scott Oaks & Henry Wong: [UDDI]: Homepage der UDDI-Gruppe JINI in a Nutshell, Deutsche Ausgabe O’Reilly Verlag Köln, 1. Auflage 2001 [JINISun]: Homepage von Jini bei SUN [UPnP]: Homepage des UPnP Forums [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 / Eberhard-Karls-Uni-Tübingen [MCFS]: Antonino Leanza: [SDP]: Mirco Tegler: Fachseminar Mobile Computing Service Discovery Protokolle Juni Seminar technische Informatik, Januar 03 [Salutation]: Homepage Salutation Consortium [WebS]: Ralf Heese: GIS-Datenbank für webservicebasierten Zugriff auf standortbez. Informationen Diplomarbeit Humboldt Universität Berlin Kommentare zur Folie Quellenangaben: hier erfolgen keine Kommentare

24 zusätzlichen Informationen
Background Backgroundfolien mit zusätzlichen Informationen Kommentar zur Folie Background: ab hier beginnt der Teil des Foliensatzes, der nicht mehr zur eigentlichen Präsentation gehört, sondern als Backgroundinformation für evtl. Nachfragen dient.

25 Background Übersicht über die Protokolle
SLP Salutation UPnP Jini Entwickler / Organisation IETF Consortium Microsoft Sun Entstehungsjahr 1997 1995 1999 1998 Status In Entwicklung Im Gebrauch Übergang Marktreife Übergang Marktreife Lizenz / Spezifikation Open Source Open Source / kontrolliert Programmiersprache Unabhängig Java Netzwerktransport TCP/IP Dienst-Beschreibung String Java Interface Server-Registrierung Authenticated Multicast nur lokal Multicast / Unicast Multicast mit TCP-Callback Code-Mobilität nein Java-RMI Sicherheitsmodell Ja Java-basiert HW / SW - Anforderungen TCP / IP keine TCP / IP, HTTP, XML Java, JVM JRE 1.2 > Interoperation mit anderen SDPs ja Kommentar zur Folie Background – Übersicht über die Protokolle: diese Folie ist dazu gedacht nochmals einen Überblick über die Protokolle zu geben und ihre Funktionalitäten auf einem Blick erfassen zu können diese Folie ist von der Folie Fazit & Bewertung aus zu erreichen, um evtl. meine Entscheidung für ein Protokoll nochmals untermauern zu können

26 Background Broadcast, Multicast, Unicast
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 Kommentar zur Folie Background – Broadcast, Multicast, Unicast: Broadcast - Rundruf ins Netzwerk, bei dem an alle Teilnehmer des Subnetzes ein Datenpaket versendet wird - wird vor allem verwendet, wenn die Adresse des Teilnehmers vollkommen unbekannt ist und auch keine Multicast-Adresse spezifiziert wurde. - ein Broadcast erzeugt allerdings eine hohe Netzlast, da das Datenpaket an alle Teilnehmer versandt wird - außerdem muss jeder Teilnehmer das Datenpakt aufnehmen und entscheiden, ob er es verarbeiten muss oder nicht  ineffizient - ein Broadcast wird aufgrund der durch ihn entstehenden hohen Netzwerklast in der Regel von Routern nicht weitergeleitet, um so die Netzwerklast einzudämmen Multicast - Multicast ist eine Punkt-zu-Gruppe Übertragung, bei der ein Paket an eine definierte Zielgruppe gesendet wird - Basis ist hierfür eine festgelegte Multicast-Adresse (ein spezieller IP-Adressenbereich, der für Multicast reserviert ist) - der Vorteil von Multicast gegenüber Broadcast ist neben der deutlich geringeren Netzwerklast auch die Weiterleitung von Multicastpaketen durch Router und Switches - innerhalb des Multicast-Paketes kann eine Time-to-Live angegeben werden, wie viele Stationen das Paket weitergeleitet wird Unicast - Paket wird an genau einen Teilnehmener gesendet, der diese Daten verarbeiten soll - das Paket wird von Routern und Switches weitergeleitet - Punkt-zu-Punkt-Verbindungen sind Verbindungen ohne vermittelnde Zwischenstation. Darunter fällt die Kommunikation in den unteren Netzwerkschichten (1-3 im OSI-Modell). Damit grenzen sich solche Verbindungen von den so genannten "Ende-zu-Ende-Verbindungen" auf den höheren Netzwerkschichten (4-7 im OSI-Modell) ab. Bei der Ende-zu-Ende-Kommunikation wird die Weitervermittlung durch Zwischenstation genutzt. Man spricht dabei auch von Multihop-Kommmunikation. - an einer Punkt-zu-Punkt Kommunikation sind genau 2 Kommunikationspartner beteiligt nach [CBL]

27 Background Unterschiede JINI – 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. Kommentare zur Folie Background – Unterschiede JINI – Corba: CORBA: - Corba hat als primäres Ziel die Unterstützung der verteilten Programmierung und in diesem Zusammenhang das Client-Server-Paradigma als Grundlage - Corba vermittelt nur Methodenaufrufe, wenn der Server aktuell verfügbar ist, bietet aber keine Ausweichmöglichkeiten für den Fall des Ausfalls eine Dienstes an - Corba bietet zudem keine ursprünglich zur Dienstbeschreibung vorgesehenen Mechanismen an - großer Vorteil von Corba ist aber sicherlich, dass es sprachunabhängig ist und von sehr vielen Programmiersprachen Bibliotheken zur Nutzung von Corba vorhanden sind JINI: - Jini wurde zur Vermittlung von Diensten in einem Netzwerk konzipiert und bringt deshalb alle dafür notwendigen Konzepte mit - insbesondere gute Möglichkeiten zur Dienstbeschreibung und zum Auffinden von Diensten - stellt Ausweichmöglichkeiten bzw. bei mehreren Suchmatchings Auswahlmöglichkeiten für einen Dienst zur Verfügung - unterstützt aktive Fehlererkennung, indem Dienste immer nur für einen bestimmten Zeitraum als aktiv gelten und dieser Zeitraum regelmäßig wieder verlängert werden muss, wenn der Dienst weiterhin aktiv ist - bietet neben der reinen Vermittlung auch noch weitere Features, die im Zusammenhang mit der Discovery von Services nützlich sind

28 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 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)) Kommentar zur Folie Background – Service Description in SLP: in SLP gibt es genaue Regeln dafür, wie eine Dienstbeschreibung auszusehen hat, damit die Beschreibung entsprechend verarbeitet werden kann allgemein wird in SLP ein Dienst durch einen Typnamen, eine URL und eine beliebige Anzahl an Schlüssel-Wert-Paaren definiert - der Typname wird durch eine String beschrieben - die URL gibt an, wie und wo der Service zu finden ist - die Schlüssel-Wert-Paare stellen die Attribute des Service, sprich seine Eigenschaften dar Service-Requests wird eine Query hinzugefügt, welche in Form eines boolschen Prädikats die Anfoderungen an den Dienst beschreibt Beispiel kurz erläutern, indem die Schlüssel-Wert-Paare durchgegangen werden wichtig: das Attribut „scopes“ ermöglicht eine Zuordnung bestimmter Dienste zu bestimmten Gruppen Beispielprädikat: das Beispielprädikat in einem Druckertemplate könnte z. B. bedeuten, dass die Druckerwarteschlange maximal 3 lang sein soll und der Drucker mindestens 6 Seiten pro Minute drucken können soll

29 Universal Description, Discovery and Integration (UDDI)
Grundlegende Architektur von UDDI Universal Description, Discovery and Integration als öffentliches Verzeichnis Service Verzeichnis UDDI Finden Publizieren WSDL WSDL Kommunikation über SOAP Kommentare zur Folie Universal Description, Discovery and Integration (UDDI): das Service Verzeichnis stellt für das UDDI-Protokoll die zentrale Komponente dar, die zur Verwaltung der Web-Services verantwortlich ist und Einträge und Anfragen bearbeitet. sowohl die Suche als auch die Publikation von Web-Services im UDDI-Verzeichnis erfolgt mittels WSDL, der Web-Service-Description-Language. Diese definiert genau, wie die Beschreibung eines Dienste auszusehen hat und wie Eigenschaften für einen benötigten Dienst beschrieben werden müssen die Kommunikation erfolgt bei UDDI immer mittels SOAP, dass die WSDL-Nachrichten verpackt und aufnimmt und eine protokollunabhängige Übertragung ermöglicht Veränderte Randbedingungen können dazu führen, dass andere Spezifikationen verwendet werden; zum Beispiel ist die Service-Beschreibung mit WSDL nicht zwingend notwendig. Service Nutzer Service Anbieter Binden (Kommunikation über SOAP-Nachrichten)

30 Background 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) Kommentar zur Folie Background – Definition Web-Service: Diese Folie ist selbsterklärend