Ein adaptives Brokernetz für Publish/Subscribe Systeme

Größe: px
Ab Seite anzeigen:

Download "Ein adaptives Brokernetz für Publish/Subscribe Systeme"

Transkript

1 Diplomarbeit Ein adaptives Brokernetz für Publish/Subscribe Systeme vorgelegt von Helge Parzyjegla Berlin, den 26. Oktober 2005 Gutachter Prof. Dr. Hans-Ulrich Heiß Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin Dr.-Ing. Gero Mühl Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin Betreuer Dipl. Inf. Michael A. Jaeger Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin

2 ii

3 Inhaltsverzeichnis 1 Einleitung Motivation Ziele Wissenschaftlicher Beitrag Aufbau der Arbeit Publish/Subscribe Konzepte Ereignisse, Notifikationen und Nachrichten Publisher, Subscriber und Broker Filter, Subskriptionen und Ankündigungen Filtermodelle Entkopplung Architekturen Routing-Algorithmen Multicast und Peer-to-Peer Systeme Siena Gryphon Jedi Rebeca Hermes Verwandte Arbeiten Selbstorganisation Selbststabilisierung Adaptivität und Selbstoptimierung Rekonfiguration Design eines adaptiven Brokernetzes Kostenmodell Modell eines Publish/Subscribe Systems Kostenfaktoren Minimale und maximale Spannbäume Optimale Publish/Subscribe Bäume NP-Vollständigkeit Konsequenzen Bestimmung gemeinsamer Brokerinteressen Assoziativität Caches Bloom-Filter iii

4 iv INHALTSVERZEICHNIS Integration der Caches Strategie des Algorithmus Grundlagen der Heuristik Bewertungsphase Abstimmungsphase Integration der Heuristik Rekonfiguration Strawman Approach Grundlagen der Rekonfiguration Invarianten Integration des Rekonfigurationsalgorithmus Algorithmusdetails Implementierung Übersicht Broker Warteschlangen Routing-Tabelle Cache Lokale Umgebung Simulationsumgebung Ereignisse Brokertopologien Applikationen Szenarien Simulation und Auswertung Simulationsaufbau Netzwerktopologie Parameter Beispiel Adaptionsgüte Lastverteilung Lokalität Kostenverhältnis Aufwand Heuristik Rekonfiguration Nachrichtenordnungen Zusammenfassung Bewertung Ausblick Literaturverzeichnis 99 A CD-ROM 111

5 Abbildungsverzeichnis 2.1 Ereignisbasierte Interaktion Illustration der Schnittstelle eines Publish/Subscribe Systems Overlay-Netzwerk basierend auf einem physischen Netz Verschiedene Brokertopologien Modell eines Brokers Brokernetz basierend auf einem minimalen Spannbaum Brokernetz basierend auf einem maximalen Spannbaum Assoziativität und Ereignisverteilung Caches und Notifikationen Bloom-Filter mit drei Hashfunktionen Modell eines Brokers mit Cache Kosten verschiedener Verbindungsvarianten Abstimmung über einen Rekonfigurationswunsch Routing einer Broadcast-Nachricht Routing einer Request-Nachricht Illustration des Strawman Approachs Grundlagen des Rekonfigurationsalgorithmus Vermeiden von Notifikationsduplikaten Verzögern von Subskriptionen und Kündigungen Garantie einer FIFO- und einer kausalen Ordnung der Notifikationen Modell eines Brokers mit Cache und zusätzlichen Warteschlangen Sperren des Rekonfigurationspfades Beginn des eigentlichen Rekonfigurationsprozesses Routing der Separator-Nachrichten Durch Separator-Nachricht initiierte Aktionen Freigabe des gesperrten Rekonfigurationspfades Garantie der Nachrichtenvollständigkeit und -ordnung UML-Klassendiagramm eines Brokers UML-Klassendiagramm der Simulationsumgebung Beispiel einer Topologiedatei Beispiel einer Konfigurationsdatei Parameter der Simulationsexperimente Beispiel eines Simulationslaufs Relative Verbesserung bei ungleichmäßiger Lastverteilung Relative Verbesserung bei steigender Lokalität Relative Verbesserung bei variierten Kostenverhältnissen Relative Performanz und Kostenanteile Rekonfigurationskosten bei steigender Pfadlänge Mittlere Verzögerungszeit bei steigender Pfadlänge v

6 vi ABBILDUNGSVERZEICHNIS

7 Kapitel 1 Einleitung In den letzten Jahrzehnten haben sich Computer deutlich verändert aus riesigen Maschinen wurden kleine, tragbare Geräte, die trotzdem ein Vielfaches der Rechenleistung ihrer einstigen Vorfahren besitzen. Gleichzeitig nahm ihre Komplexität beständig zu, wobei auch heutzutage ein Ende dieser Entwicklung nicht abzusehen ist. Die Komplexität entsteht durch Abhängigkeiten einzelner Komponenten voneinander, die es erschweren das Verhalten des Gesamtsystems zu erfassen. In der Folge ist es schwierig zu bedienen und aufwändig zu warten. Daher ist die Beherrschung der Komplexität eine aktuelle Herausforderung und zugleich auch Voraussetzung für die weitere Entwicklung. In diesem Zusammenhang ist es eine faszinierende und vielversprechende Idee, Computersystemen die Fähigkeit zu geben, sich und ihre Komponenten selbständig verwalten zu können. Hierbei betrachtet IBMs Autonomic Computing Initiative [IBM01a] sogar den menschlichen Körper als inspirierendes Vorbild. Dessen autonomes Nervensystem reguliert automatisch Körperfunktionen wie Atmung und Herzschlag, ohne dass dem Menschen die inhärente Komplexität dieser Vorgänge bewusst ist. Analog sollen zukünftige Computersysteme sich autonom kontrollieren, so dass manuelle Eingriffe nur in Ausnahmefällen erforderlich sind. Natürlich besteht noch ein weiter Weg bis zum angestrebten Ziel des Autonomic Computings [GC03]. Mit der vorliegenden Arbeit unternehmen wir einen Schritt in diese Richtung. Im Bereich der Publish/Subscribe Systeme beschreiben wir die Entwicklung eines adaptiven Brokernetzes, dass sich selbständig rekonfiguriert und an die Topologie des Kommunikationsnetzes anpasst, jedoch gleichzeitig auch die Interessen der Anwendungen beachtet. 1.1 Motivation Mit abnehmender physischer Größe gelingt es Computern immer mehr Bereiche des täglichen Lebens zu durchdringen. Bereits heutzutage ist der Mensch von unzähligen Mikroprozessoren umgeben. Sie befinden sich beispielsweise in Fahrzeugen, Haushaltsgeräten oder Spielwaren. Einige Geräte, wie Persönliche Digitale Assistenten (PDAs) oder Mobiltelefone, vereinen Beweglichkeit, Rechenleistung und die Möglichkeit zur Kommunikation. Damit entstehen hochgradig vernetzte, mobile und intelligente Systeme, die zunehmend Mark Weisers Vision des Ubiquitous Computing[Wei91] entsprechen, in der eine mit computerisierten Artefakten angereicherte Umgebung den Menschen bei seinen Tätigkeiten in 1

8 2 1. EINLEITUNG unaufdringlicher Weise assistiert. Ein ähnliches Bild zeichnet auch der von IBM geprägte Begriff des Pervasive Computings[HMNS03] allerdings mit der Intention der breiten Anwendung bereits verfügbarer Technologien in Mobile- und Electronic-Commerce Szenarien. Ubiquitous und Pervasive Computing implizieren beide eine dynamische Welt mit einer gewaltigen Anzahl an kommunizierenden Geräten und Anwendungen, die Kommunikationsnetze und -infrastrukturen vor neue Herausforderungen stellt. Dabei ist absehbar, dass klassische Kommunikationsformen, insbesondere Client/Server Modelle, an ihre Grenzen stoßen. Sie sind zu unflexibel und scheitern bereits an der klassischen Rollenaufteilung in Client oder Server. Publish/Subscribe Systeme können hier ihr volles Potential ausschöpfen. Als ereignisbasierte Systeme ermöglichen sie eine Konzentration auf Kommunikationsinhalte, ohne Nachrichten direkt adressieren zu müssen. Inhaltsbasierte Filter erlauben den Anwendungen zudem die exakte Beschreibung und Auswahl der Ereignisse, für die sie sich interessieren. Beides zusammen gestattet eine lose und flexible Kopplung einzelner Komponenten, wie sie zukünftige dynamische Umgebungen benötigen. Doch auch schon heute helfen Publish/Subscribe Systeme die stetig wachsende Informations- und Datenflut einzudämmen, da eine Kommmunikation nur erfolgt, wenn einerseits eine neue Nachricht vorliegt und andererseits an ihr tatsächlich ein Interesse besteht. Derzeit gibt es eine Vielzahl von Implementierungen verteilter Publish/Subscribe Systeme, die auf einem Brokernetz basieren und einen Notifikationsdienst bilden. Allerdings besitzt ihr Brokernetz meist statische Strukturen, wodurch es sich als starr und unflexibel erweist. Sowohl die wachsende Größe des Netzes, beispielsweise in einem globalen Internet- Szenario, als auch die hohe Dynamik ubiquitärer Umgebungen werden jedoch letztlich eine Anpassung erfordern. Hierzu bieten gegenwärtige Systeme keine oder nur begrenzte manuelle Rekonfigurationsmöglichkeiten, die in beiden Fällen vom Aufwand nicht mehr zu vertreten sind. Folglich benötigen wir autonome, eigenständige Publish/Subscribe Systeme, die in der Lage sind sich selbst und insbesondere ihr Brokernetz, an die Topologie des Kommunikationsnetzes sowie den Anwendungsinteressen in dynamischen Umgebungen anzupassen. 1.2 Ziele Die Autonomic Computing Initiative definiert vier fundamentale Eigenschaften autonomer Computersysteme [GC03]. Zunächst besitzen sie die Fähigkeit sich selbst zu konfigurieren (engl. self-configuring). Für Einsatzzweck und -umgebung finden sie jeweils passende und sinnvolle Einstellungen. Dann sind sie in der Lage sich selbst zu heilen (engl. self-healing), indem sie auftretende Fehler eigenständig erkennen, diagnostizieren und schließlich beheben. Ferner sind autonome Systeme ständig bestrebt sich selbst zu optimieren (engl. self-optimising). Sie passen die Aufteilung ihrer Ressourcen kontinuierlich an, um stets eine optimale Funktionalität zu gewährleisten. Zuletzt wissen sie auch ihre Daten und Dienste zu schützen (engl. self-protecting). Unberechtigte Zugriffe oder Angriffe werden automatisch erkannt und verhindert. Die Betrachtung aller vier Eigenschaften würde im Kontext von Publish/Subscribe Systemen den Rahmen dieser Arbeit sprengen. Wir beschränken uns daher auf den Aspekt der Selbstoptimierung mit dem Ziel, die Performance eines Publish/Subscribe Systems durch Adaption seines Brokernetzes zu steigern. Dies umfasst folgende Punkte:

9 1.3. WISSENSCHAFTLICHER BEITRAG 3 Primäres Vorhaben ist die Entwicklung eines adaptiven, verteilten Algorithmus, der sich an die Topologie des Kommunikationsnetzes anpasst, dabei jedoch auch die Nachrichteninteressen der Anwendungen berücksichtigt. Im Ergebnis soll sowohl die Leistung des Routing-Verfahrens erhöht, als auch die Netzlast reduziert werden. Der Algorithmus soll möglichst universell einsetzbar sein. Hierfür müssen weitreichende und einschränkende Annahmen, beispielsweise über Nachrichtenhäufigkeiten und -verteilungen, vermieden werden. Die Rekonfiguration des Brokernetzes soll für Anwendungen kaum wahrzunehmen sein. Daher darf sie nur minimale Auswirkungen auf die Dienstgüte des Publish/ Subscribe Systems haben. 1.3 Wissenschaftlicher Beitrag Schwerpunkt dieser Arbeit ist die Entwicklung eines adaptiven Brokernetzes für Publish/ Subscribe Systeme. Die folgenden Punkte markieren wichtige Schritte im Entwicklungsprozess und bilden essentielle Bestandteile der Arbeit: Das Kostenmodell ist die Grundlage, auf der Rekonfigurationsentscheidungen getroffen werden. Mit seiner Hilfe führen wir den Nachweis, dass die Optimierung des Brokernetzes NP vollständig ist. Wir stellen ein Verfahren zur Bestimmung des gemeinsamen Nachrichteninteresses verschiedener Broker vor. Da das Verfahren auf Caches und Bloom-Filtern beruht, werden keine Annahmen über Nachrichten- bzw. Ereignisverteilungen benötigt. Kernstück des entwickelten Algorithmus ist eine Heuristik, die Broker mit gleichen Interessen möglichst direkt miteinander verbindet, sofern der Aufwand für das genutzte Kommunikationsnetz ein akzeptables Maß nicht übersteigt. Für die notwendige Rekonfiguration des Brokernetzes präsentieren wir eine Möglichkeit, die ohne Nachrichtenverlust auskommt und zudem Aufwand und Auswirkungen lokal begrenzt. Durch Queueing kann zusätzlich eine FIFO- bzw. kausale Ordung der Nachrichten gewährleistet werden. Durch Implementierung des Algorithmus und Simulation verschiedener Szenarien analysieren wir seine Charakteristika. Ebenfalls erfolgt ein Vergleich mit anderen Ansätzen und Verfahren. 1.4 Aufbau der Arbeit Im folgenden Kapitel 2 erläutern wir die Grundlagen des Publish/Subscribe Modells, wobei sowohl dessen Konzepte erörtert, als auch aktuelle Systeme vorgestellt werden. Ferner geben wir einen Überblick über verwandte Arbeiten, die vor allem Aspekte autonomer Systeme beinhalten. Kapitel 3 beschreibt den Entwurf eines adaptiven Brokernetzes für Publish/Subscribe Systeme. Zunächst stellen wir ein Kostenmodell und ein Verfahren zum Bestimmen gemeinsamer Brokerinteressen vor. Darauf aufbauend entwickeln wir eine Adaptionsheuristik sowie einen Rekonfigurationsalgorithmus.

10 4 1. EINLEITUNG Anschließend diskutiert Kapitel 4 sowohl die Implementierung der entwickelten Algorithmen und Verfahren, als auch den Aufbau einer flexiblen Simulationsumgebung zu ihrer Auswertung. Wir besprechen die Details der wichtigsten Klassen und erläutern die unter ihnen bestehenden Beziehungen und Abhängigkeiten. Kapitel 5 beschäftigt sich mit der Simulation und Evaluierung der Heuristik und des Rekonfigurationsalgorithmus. In verschiedenen Szenarien untersuchen wir sowohl die erreichte Adaptionsgüte, als auch den verursachten Aufwand und vergleichen die Ergebnisse mit denen anderer Verfahren und Ansätze. Abschließend fasst Kapitel 6 die geleistete Arbeit zusammen und bewertet die gewonnenen Ergebnisse. Ferner wird ein Ausblick auf weiterführende Thematiken und Aspekte gegeben.

11 Kapitel 2 Publish/Subscribe Dieses Kapitel widmen wir dem Publish/Subscribe Paradigma. Wir erläutern seine Grundlagen, die das Fundament dieser Arbeit bilden und auf denen nachfolgende Kapitel aufbauen. Zunächst werden maßgebliche Konzepte vorgestellt und dann deren Umsetzung in aktuellen Publish/Subscribe Systemen betrachtet. Abschließend geben wir eine kurze Zusammenfassung aktueller Forschung auf diesem Gebiet. Insbesondere interessieren uns Veröffentlichungen, die bewusst Aspekte autonomer Systeme thematisieren. 2.1 Konzepte Publish/Subscribe Systeme ermöglichen eine flexible ereignisbasierte Kommunikation. Ihre Flexibilität liegt in den genutzten Konzepten begründet, die wir im Folgenden erläutern. Wir beginnen unsere Betrachtung aus Sicht der Anwendungen und untersuchen, warum das Publish/Subscribe Modell insbesondere für zukünftige, dynamische Szenarien wie das Ubiquitous- oder Pervasive Computing geeignet ist. Anschließend interessieren wir uns mehr für technische Details der Systeme und diskutieren Varianten der Implementierung Ereignisse, Notifikationen und Nachrichten In ereignisbasierten Systemen interagieren Komponenten, indem sie Notifikationen austauschen und sich gegenseitig über aufgetretene Ereignisse informieren [CNRW98]. Ein Ereignis ist eine beobachtbare Zustandsänderung, die sowohl in der realen, physischen Welt, als auch im Inneren des Computers liegen kann. Beispielsweise kann ein physisches Ereignis durch einen Sensor registriert werden, was zu einer Änderung seines Messwertes führt. Aber auch das Ergebnis interner Rechenoperationen ist ein Ereignis, das den Abschluß der Berechnung markiert. Ereignisse können ebenfalls in Größe und Umfang variieren. Sowohl ein einfacher Hardwareinterrupt, als auch die komplexe Auftragsannahme in einer Electronic-Commerce Anwendung stellen in diesem Sinne Ereignisse dar. Möchte eine Komponente eine andere über ein Ereignis informieren, so erstellt sie hierzu eine Notifikation. Eine Notifikation enthält die notwendigen Daten, um das Ereignis und eventuell die Umstände seines Auftretens zu beschreiben [Zei04]. Gleichzeitig repräsentiert sie das Ereignis in der Form, in der es von anderen Komponenten verarbeitet werden kann. Gebräuchliche Datenmodelle sind Name/Wert Paare [CRW01], Objekte [EGD01] oder semi-strukturierte Daten im XML-Format [MF01]. 5

12 6 2. PUBLISH/SUBSCRIBE Ereignis Publisher Ereignisbasierte Interaktion Subscriber Notifikation Notifikation Broker Broker Nachricht Kommunikationsnetz Abbildung 2.1: Ereignisbasierte Interaktion. Die Zustellung der Notifikationen an interessierte Empfänger übernimmt ein Notifikationsdienst. Ist hierfür der Transport über ein Netzwerk erforderlich, so sprechen wir auf Netzebene von Nachrichten. Eine Nachricht ist schlicht der Transportcontainer einer Notifikation und praktisch meist die serialisierte Notifikation selbst Publisher, Subscriber und Broker In der Publish/Subscribe Welt wird ein Produzent von Notifikationen als Publisher 1 bezeichnet. Wir sagen, ein Publisher veröffentlicht oder publiziert Notifikationen, wann immer ein Ereignis auftritt. Ein Subscriber ist hingegen der Konsument von Notifikationen. Wir sagen, ein Subscriber abonniert oder subskribiert Notifikationen, für die er sich interessiert. Für eine Komponente gibt es keine feste Aufteilung der Rollen. Sie kann Publisher und zugleich Subscriber sein. Die Aufgabe des Notifikationsdienstes übernimmt das Publish/Subscribe System. Ein verteiltes Publish/Subscribe System besteht aus einer Menge untereinander vernetzter Broker. Für Publisher wie Subscriber bilden die Broker Schnittstelle und Zugangspunkte zum System. Abbildung 2.1 illustriert die ereignisbasierte Kommunikation in einem verteilten Publish/Subscribe System. Ein Publisher registriert ein Ereignis, worauf er eine Notifikation veröffentlicht und sie seinem lokalen Broker übergibt. Dieser sendet sie, verpackt in einer Nachricht, an den Broker des Subscribers, der die Notifikation dann ausliefert Filter, Subskriptionen und Ankündigungen Nicht jedes Ereignis ist bedeutend und daher nur ein Teil der Notifikationen relevant. Broker nutzen Filter, um die wichtigen Notifikationen von den uninteressanten zu trennen. 1 Sofern keine treffenden deutschen Übersetzungen existieren, werden englische Bezeichnungen verwendet.

13 2.1. KONZEPTE 7 advertise() unadvertise() publish() Broker subscribe() unsubscribe() notify() Publisher Subscriber Abbildung 2.2: Illustration der Schnittstelle eines Publish/Subscribe Systems. Ein Filter ist eine boolsche Funktion, mit der ein Broker eine erhaltene Notifikation auf ihre Relevanz testet. Entweder besteht an ihr Interesse oder nicht. Durch eine Subskription können Konsumenten ihr Interesse an bestimmten Notifikationen äußern. Eine Subskription enthält einen Filter, der genau die Notifikationen beschreibt, an denen der Subscriber interessiert ist. Er übergibt die Subskription dann seinem lokalen Broker, der das Filtern übernimmt. Während Filter sich nur auf den Inhalt einer Notifikation beziehen, können Subskriptionen noch Metadaten mit einschließen [Zei04]. Beispiele sind Sichtbarkeitsbereiche [FMG02a], Sicherheits- [BEP + 03] und Zeitinformationen [CFH + 03] sowie maximale Auslieferungsraten [MUHW04]. Auf der anderen Seite können Produzenten ihrem lokalen Broker durch eine Ankündigung mitteilen, welche Notifikationen sie veröffentlichen werden. Analog zu Subskriptionen enthalten Ankündigungen einen Filter, der den Inhalt zukünftiger Notifikationen festlegt. Diese Information kann vom Publish/Subscribe System zu Optimierungszwecken ausgenutzt werden. Allerdings kann auf Ankündigungen auch vollständig verzichtet werden, wenn implizit angenommen wird, dass jeder Publisher fähig ist, beliebige Notifikationen zu erzeugen. Abbildung 2.2 veranschaulicht Schnittstellen und zugehörige Operationen eines Publish/- Subscribe Systems. Durch subscribe()- und unsubscribe()- Aufrufe äußert ein Subscriber sein Interesse an Notifikationen bzw. widerruft es. Ein Publisher kann mit advertise() und unadvertise() die Erzeugung von Notifikationen an- bzw. aufkündigen. publish() und notify() dienen dem Veröffentlichen von Notifikationen bzw. deren Zustellung Filtermodelle Broker vertreten die Interessen ihrer Klienten. Sie filtern gewünschte Notifikationen heraus und benachrichtigen ihre Subscriber. Dem Wunsch der Subscriber nach einer möglichst präzisen Beschreibung der Interessen steht ein erhöhter Filteraufwand seitens der Broker gegenüber. Zwischen Ausdrucksstärke und Skalierbarkeit muss abgewogen werden [CRW99]. Nach ihrer Ausdrucksstärke unterscheiden wir im Wesentlichen fünf Filtermodelle [Zei04]: Kanalbasierte Filterung. Notifikationen werden in benannten Nachrichten-Kanälen veröffentlicht. Ein Subscriber kann einen oder mehrere Kanäle abonnieren und erhält dann alle dort publizierten Notifikationen. Eine differenziertere Auswahl findet nicht statt. Ein Beispiel ist der Corba Event Service [OMG04].

14 8 2. PUBLISH/SUBSCRIBE Themenbasierte Filterung. Jede Notifikation gehört zu einem Thema. Beispielsweise könnte IBMs aktueller Aktienkurs unter market.nyse.stock.stockquote.ibm veröffentlicht werden. Themen sind hierarchisch geordnet, wobei untergeordnete Kategorien den Notifikationsinhalt weiter eingrenzen. Jede Subskription bezieht sich auf ein bestimmtes Thema und kann auch untergeordnete Themen mit einschließen. Typbasierte Filterung. Notifikationen werden als Objekte betrachtet. Die Auswahl erfolgt anhand der Typhierarchie ihrer zugehörigen Klassen [EGD01]. Typbasierte Filterung ähnelt stark der themenbasierten, erweitert deren Ausdruckskraft jedoch um die Möglichkeit der Mehrfachvererbung (falls implementiert). Durch Kombination mit inhaltsbasierten Filtern kann die Selektion weiter verfeinert werden. Inhaltsbasierte Filterung. Inhaltsbasierte Filter erlauben die Selektion anhand beliebiger inhaltlicher Aspekte, was die Auswertung der gesamten Notifikation zulässt [Müh02]. Die Subscriber sind somit unabhängig von jeglicher Klassifizierung durch die Publisher. Die Ausdruckskraft wird nur durch die genutzten Filterprädikate und das Datenmodell der Notifikationen begrenzt [Zei04]. Vorgeschlagen werden u.a. Templates [CNF01], Filter für Name/Wert Paare [Müh01], XPath für XML [AF00] sowie der Einsatz von mobilem Programmcode [DMDP03]. Konzeptbasierte Filterung. Ereignisse lassen sich unterschiedlich beschreiben abhängig vom jeweiligen Kontext. Beispielsweise könnte ein New Yorker Aktienkurs das Attribut price=50$ tragen, wohingegen ein Frankfurter Kurs mit preis=50e gekennzeichnet wird. Konzeptbasierte Filterung [Cil02] berücksichtigt inhaltliche Transformationen und erlaubt die Auswahl von Notifikationen auf einem semantischen Niveau. Konzeptbasierte Filterung erweitert so die inhaltsbasierte, setzt jedoch wohl definierte Ontologien voraus [Zei04] Entkopplung Gegenüber dem weit verbreiteten Request/Reply Paradigma bietet Publish/Subscribe ein flexibleres Kommunikationsmodell. Die Flexibilität liegt vor allem in der Entkopplung der Kommunikationspartner begründet. Das Publish/Subscribe System agiert als neutraler Mediator zwischen Ereignisproduzenten und -konsumenten. Publisher und Subscriber werden in drei Dimensionen entkoppelt [EFGK03]: Entkopplung im Raum. Publisher und Subscriber müssen sich nicht gegenseitig kennen. Publisher veröffentlichen ihre Notifikationen und die Broker übernehmen deren Auslieferung an alle interessierten Subscriber. Dabei werden die Empfänger einzig aus dem Inhalt der Notifikation und den Filtern der abgegebenen Subskriptionen bestimmt. Die resultierende Gruppenkommunikation ist daten- bzw. inhaltszentriert und damit anonym sowie indirekt. Entkopplung in der Zeit. Durch den Einsatz von Caches [CFH + 03] können Broker Notifikationen temporär zwischenspeichern. Subscriber brauchen dann zum Veröffentlichungszeitpunkt einer Notifikation nicht mehr mit dem System verbunden zu sein. Die Notifikation kann auch später noch zugestellt werden, selbst wenn der Publisher nun seinerseits nicht mehr erreichbar ist.

15 2.1. KONZEPTE 9 Entkopplung in der Synchronisation. Publisher werden beim Veröffentlichen einer Notifikation nicht blockiert und deren Auslieferung an die Subscriber erfolgt asynchron durch Callbacks. Die Kontrollflüsse von Publishern und Subscribern sind daher nicht so stark miteinander verwoben und voneinander abhängig, wie dies bei entfernten Prozeduraufrufen im Request/Reply Modell üblich ist. Eine lose Kopplung einzelner Komponenten ist Voraussetzung für dynamische Szenarien wie das Ubiquitous- oder Pervasive Computing, in denen eine Vielzahl von Sensoren, Aktuatoren und mobilen Geräten miteinander kommunizieren. Publish/Subscribe erlaubt die asynchrone Benachrichtigung der Subscriber, wenn sich beispielsweise ein Sensormesswert ändert. Mit Request/Reply bliebe hingegen nur das ineffiziente periodische Abfragen des Sensors, um eine Änderung zu detektieren [FZ98]. Durch die indirekte, inhaltsbasierte Kommunikation brauchen Komponenten sich nicht mehr gegenseitig zu kennen. Der Sensor muss nicht wissen, welche und wieviele Anwendungen sich für seine Daten interessieren. Ein mobiles Gerät ist hauptsächlich daran interessiert, dass ein Dienst erbracht wird und weniger von wem. Publisher wie Subscriber müssen sich nicht um die Verwaltung von Adressinformationen kümmern, die sich in mobilen Welten zudem ständig ändern können. Das temporäre Zwischenspeichern von Notifikationen trägt hier ebenfalls den fragilen Verbindungen drahtloser Netze Rechnung [Zei04]. Das abrupte Abbrechen einer Verbindung muss in mobilen Szenarien Berücksichtigung finden. Publish/Subscribe Systeme können dies durch Caches auf Middleware-Ebene unterstützen und so einen Notifikations- und Datenverlust für die Anwendungen vermeiden Architekturen Einfache Publish/Subscribe Systeme bestehen nur aus einem Server, der für das Filtern und Ausliefern veröffentlichter Notifikationen verantwortlich ist. Erste Implementierungen folgten diesem zentralistischen, jedoch nicht skalierbaren Ansatz. Hingegen bestehen aktuelle Publish/Subscribe Systeme aus einer Anzahl untereinander vernetzter und kooperierender Broker. Die Broker bilden dabei ein logisches Overlay-Netzwerk [PB03a]. Zwei Broker müssen hierzu nicht notwendiger Weise direkt miteinander verbunden sein. Nachrichten können erst über mehrere physische Knoten des genutzten Kommunikationsnetzes laufen, ehe sie den jeweils anderen Broker erreichen. Abbildung 2.3 zeigt ein Overlay-Netzwerk basierend auf einem bespielhaften physischen Netz. Viele verteilte Publish/Subscribe Systeme unterscheiden sich in den Topologien ihrer Overlay-Netze. Im Folgenden differenzieren wir vier verschiedene Formen [Car98]: Hierarchische Topologie. Eine hierarchische Topologie entsteht durch Erweiterung des zentralistischen Ansatzes (mit einem Server). Jeder Broker hat eine Anzahl von Klienten, was Publisher und Subscriber, aber auch andere Broker sein können [Car98]. Ein Broker vertritt seine Klienten, indem er erhaltene Subskriptionen und Notifikationen an den jeweils übergeordneten Broker weiterleitet. Aus Sicht des übergeordneten Brokers erscheint dieser dann wie ein einfacher Publisher oder Subscriber und muss daher nicht gesondert behandelt werden. Abbildung 2.4(a) zeigt eine hierarchische Topologie. Broker sind als Kreise, Publisher und Subscriber als Rechtecke dargestellt.

16 10 2. PUBLISH/SUBSCRIBE Overlay- Netzwerk Physisches Netzwerk Abbildung 2.3: Overlay-Netzwerk basierend auf einem physischen Netz. Azyklische Topologie. Azyklische Topologien basieren wie hierarchische auf Baumstrukturen, benötigen jedoch keinen ausgezeichneten Wurzelknoten. Die Broker sind einander gleichgestellt und tauschen bidirektional Subskriptionen, Ankündigungen und Notifikationen aus. Abbildung 2.4(b) gibt ein Beispiel. Generische Topologie. In generischen Topologien, wie in Abbildung 2.4(c) dargestellt, werden zusätzliche Zyklen zugelassen, wodurch sich die Fehlertoleranz erhöht. Sind zwei Broker über mehr als einen Weg miteinander verbunden, kann eine Verbindung unterbrochen werden. Ebenfalls ist es möglich, die Last auf mehrere Wege zu verteilen. Allerdings konstruieren viele Routing-Algorithmen zunächst wieder azyklische Baumstrukturen, beispielsweise minimale Spannbäume für Publisher, auf denen sie dann effizient arbeiten [CW03, CRW04]. Die tatsächlich genutzten Verbindungen ergeben sich aus einer Überlagerung der konstruierten Bäume. Hybride Topologie. Hybride Topologien entstehen durch Kombination der obigen. Abbildung 2.4(d) illustriert eine generische Topologie mit zwei hierarchischen Subnetzen (Cluster) Routing-Algorithmen Die Art und Weise, wie Broker untereinander Subskriptionen, Ankündigungen und Notifikationen austauschen, wird durch die genutzten Routing-Algorithmen bestimmt. Prinzipiell beeinflussen Subskriptionen, wohin passende Notifikationen geschickt werden. Wir unterscheiden folgende Routing-Algorithmen [Müh02]: Flooding. Flooding bezeichnet das kontrollierte Fluten des Brokernetzes. Die Notifikationen werden grundsätzlich an alle Broker gesendet. Deshalb brauchen Subskriptionen nicht weitergeleitet zu werden. Dieser triviale Ansatz ist nicht skalierbar [MFB02]. Da Broker grundsätzlich alle veröffentlichten Notifikationen erhalten, muss jeder von ihnen auch solche verarbeiten, für die sich kein Subscriber interessiert. Somit werden wertvolle Ressourcen verschwendet. Simple Routing. Simple Routing ist der einfachste inhaltsbasierte Routing-Algorithmus. Das Brokernetz wird mit Subskriptionen geflutet, so dass jeder Broker globales Wissen über alle Interessen besitzt. Ein Broker muss Notifikationen dann nur noch in die Richtungen weiterleiten, in denen sich weitere interessierte Broker befinden.

17 2.1. KONZEPTE 11 (a) (b) (c) (d) Abbildung 2.4: Verschiedene Brokertopologien: (a) hierarchische Topologie; (b) azyklische Topologie; (c) generische Topologie; (d) hybride Topologie (generisch/hierarchisch). Hierzu speichert er in einer Routing-Tabelle jeweils den Filter einer Subskription zusammen mit dem Nachbarbroker, von dem er sie erhalten hat. Empfangene Notifikationen werden gegen die Filter der Tabelle getestet und nur an die Nachbarn weitergeleitet, die einen passenden Routing-Eintrag haben. Identity-based Routing. Identity-based Routing nutzt Gemeinsamkeiten zwischen den Filtern zweier Subskriptionen aus, um die Größe der Routing-Tabellen und somit den Aufwand in jedem Routing-Schritt zu reduzieren [MFB02]. Das Weiterleiten einer Subskription an einen Nachbarn wird unterbunden, wenn an diesen bereits eine identische Subskription 2 gesendet wurde. Dies verringert die Anzahl seiner Routing- Einträge. Covering-based Routing. Covering-based Routing [CRW01] ist eine Erweiterung des Identity-based Routings. Subskriptionen, die nur eine Teilmenge an Notifikationen einer bereits übermittelten Subskription erfassen, werden ebenfalls nicht mehr weitergeleitet. Erst beim Kündigen der überdeckenden Subskription müssen sie übermittelt werden. Merging-based Routing. Merging-based Routing erlaubt Brokern ihre Routing-Einträge zu neuen, überdeckenden Subskriptionen zu verschmelzen, die sie anstatt der 2 Eine Subskription, die eine identische Menge an Notifikationen beschreibt.

18 12 2. PUBLISH/SUBSCRIBE Originale weiterleiten [MFB02]. So kann die Größe der Routing-Tabellen nochmals reduziert werden. Ankündigungen schränken ebenfalls die Weiterleitung von Subskriptionen ein. Subskriptionen müssen nur noch in die Teile des Overlay-Netzes propagiert werden, aus denen Ankündigungen stammen, die sich mit ihnen überschneiden. Für das Routing der Ankündigungen können alle oben vorgestellten Algorithmen, bis auf das Flooding, genutzt werden. Ebenfalls können unterschiedliche Algorithmen für das Weiterleiten von Subskriptionen und von Ankündigungen miteinander kombiniert werden Multicast und Peer-to-Peer Die im vorigen Abschnitt vorgestellten Algorithmen beschreiben das Routing im Overlay- Netz der Broker, wobei Gemeinsamkeiten der Filter von Subskriptionen sowie von Ankündigungen zur Optimierung genutzt werden. Doch können auch Mechanismen des zu Grunde liegenden Kommunikationsnetzes zur Leistungssteigerung eingesetzt werden. Beispielsweise bietet sich IP-Multicast [Dee89] für eine effiziente Gruppenkommunikation der Broker an. Aktuelle Arbeiten [PB02, Pie04] nutzen allerdings auch Peer-to-Peer Routing- Verfahren und daraus entstehende Overlay-Netze, um auf deren Grundlage Publish/Subscribe Systeme zu realisieren. Multicast. Multicast bezeichnet das Senden von Informationen an eine Gruppe von Empfängern. IP-Multicast-Nachrichten laufen hierbei nur einmal über jede Kante des Netzes und werden erst an den Knoten kopiert, an denen sich die Wege zu unterschiedlichen Empfängern trennen. Alle Beteiligten gehören einer gemeinsamen Multicast-Gruppe an. In themenbasierten Publish/Subscribe Systemen kann für jedes Thema eine Multicast- Gruppe eingerichtet werden, der die Broker bei Interesse ihrer Subscriber beitreten. Bei einer nur begrenzten Anzahl verfügbarer Multicast-Adressen und -Gruppen gegenüber einer großen Menge an Themen führt dieser Ansatz zum sogenannten Channelization Problem [AGK + 01]. Das Finden einer optimalen Zuordnung bezogen auf genutzte Ressourcen von Themen zu einzelnen Gruppen ist NP-vollständig [AGK + 01]. In inhaltsbasierten Systemen bestimmt erst der Inhalt einer Notifikation, an welche Broker sie gesendet wird. Die Menge der Empfänger kann sich so von Notifikation zu Notifikation ändern, wobei insgesamt 2 N mögliche Kombinationen bei N beteiligten Brokern existieren [OAA + 00]. Prinzipiell müsste daher eine exponentielle Anzahl von Multicast-Gruppen bereitgehalten werden, was nicht skalierbar ist und ebenfalls zu einem Channelization Problem führt 3. Die Anzahl genutzter Multicast-Gruppen wird nicht nur durch die Verfügbarkeit freier Adressen begrenzt, sondern vor allem durch den Aufwand die Gruppen zu verwalten. Broker treten den Gruppen bei und verlassen sie wieder. Routing-Informationen für das Kommunikationsnetz müssen berechnet, gespeichert und stets aktuell gehalten werden. Opyrchal et al. erörtern daher in [OAA + 00] mehrere Heuristiken, um die Anzahl der benötigten Gruppen zu reduzieren. Dabei geben sie einen Überblick über generelle Ansätze und Möglichkeiten: 3 Die Analogie ist ersichtlich, wenn wir uns für jede der 2 N Kombinationen ein eigenes Thema vorstellen.

19 2.1. KONZEPTE 13 Reduzieren der Gruppenpräzision. In einer Gruppe werden auch Notifikationen veröffentlicht, für die sich nur ein Teil der beigetretenen Broker interessiert. Mehrfaches Senden von Multicasts. Eine Notifikation wird in mehreren Multicast- Gruppen veröffentlicht. Senden über mehrere Knoten. Ein Broker sendet die Notifikation in einer Multicast- Nachricht an einen Teil seiner Nachbarn, die sie dann mittels Multicast analog weiterleiten. Peer-to-Peer. In Peer-to-Peer Netzen [Ora01] interagieren Knoten als Gleichgestellte und bieten sich gegenseitig Dienste an bzw. nehmen diese in Anspruch. Der Begriff Peerto-Peer wurde im Zusammenhang mit Internettauschbörsen bekannt, in denen Nutzer sich gegenseitig Zugriff auf Dateien gewähren. Peer-to-Peer Systeme der ersten Generation waren unstrukturiert und fluteten Anfragen direkt in ihr Netz, was zu Performance- und Skalierbarkeitsproblemen führte [CP02]. Aktuelle Systeme wie Pastry [RD01] oder Tapestry [ZKJ01], die auf verteilten Hashtabellen basieren, sind in der Lage Nachrichten in durchschnittlich O(log N) Schritten zu einem der N Netzknoten zu leiten. Ihr Routing-Algorithmus konstruiert ein sogenanntes Small-World Overlay-Netz [Ora01], das stark geclustert ist und einen geringen Durchmesser aufweist. Derartige Peer-to-Peer Systeme sind in hohem Maße fehlertolerant sowie skalierbar. Eine verteilte Hashtabelle [Dev93] ist eine dezentrale Datenstruktur, die einen Schlüssel auf einen Netzknoten abbildet, der ein zugehöriges Datum speichert. Der Aufwand zum Speichern wird gleichmäßig auf alle Knoten verteilt. Anfragen leitet das Peer-to-Peer System effizient an den durch den Hashwert des Schlüssels bestimmten Knoten, der diese dann bedient. Auf dieser Basis lässt sich ein Multicast auf Applikationsebene [CRZ00] entwerfen, der äquivalent zu themenbasierten Publish/Subscribe ist. Subskriptionen sowie Notifikationen werden durch das Peer-to-Peer Netz geroutet, wobei ihr Thema als Schlüssel dient. Ihr Zielknoten, der sich durch den Hashwert des Schlüssels bzw. Themas ergibt, ist der Rendezvous-Punkt [CDKR02], an dem sie sich treffen. Auf ihrer Reise zum Rendezvous-Punkt hinterlassen Subskriptionen in jedem Knoten Routing-Informationen, die den letzten Vorgänger auf ihrem bisherigen Weg beinhalten. Damit initialisieren sie die Pfade, die in umgekehrter Richtung der Auslieferung der Notifikationen dienen. Es entsteht ein kernbasierter Multicast-Baum [BFC93] für ein bestimmtes Thema mit dem zugehörigen Rendezvous-Knoten als Wurzel. Ist die Adresse bekannt, so können Notifikationen auch direkt an den Wurzelknoten geschickt werden, von dem ausgehend die eigentliche Verteilung an die Subscriber beginnt. Scribe [CDKR02] implementiert einen derartigen Multicast basierend auf Pastry. Eine weitere, ähnliche Implementierung ist Bayeux [ZZJ + 01], die hingegen Tapestry als Peerto-Peer Routing-Schicht nutzt. In Bayeux verwalten die Rendezvous-Knoten zusätzlich die Mitgliedschaft in ihren Gruppen. Ferner wird der Multicast-Baum erst von Nachrichten des Rendezvous-Knotens an die Subscriber erzeugt, die ihre Subskriptionen bestätigen. Hermes [PB02] (siehe auch Kapitel 2.2.5) erweitert den vorgestellten Multicast-Mechanismus um inhaltsbasierte Filterung zu einem flexiblen und vollwertigen Publish/Subscribe System.

20 14 2. PUBLISH/SUBSCRIBE 2.2 Systeme Es gibt eine Vielzahl verschiedener Publish/Subscribe Systeme. Wang et al. verweisen allein in [WQA + 02] auf elf Projekte. Dies sind bei weitem nicht alle und aufgrund der Attraktivität des Publish/Subscribe Modells werden es kontinuierlich mehr. Wir haben fünf Repräsentanten Siena [Car98], Gryphon [IBM01b], Jedi [CNF98], Rebeca [FMB01] und Hermes [PB02] ausgewählt, die wir im Folgenden vorstellen. Vor allem interessiert uns, welche der im vorigen Abschnitt betrachteten Konzepte jeweils umgesetzt wurden SIENA Das Siena Projekt [Car98, CRW01] ist am Software Engineering Research Laboratory der Universität von Colorado in Boulder beheimatet [SER04]. Die Scalable Internet Event Notification Architecture (Siena) ist eine der ersten Implementierungen eines verteilten inhaltsbasierten Publish/Subscribe Systems. Siena Server bilden die Zugangspunkte zum System und bieten ihren Klienten eine Schnittstelle zum Publizieren, Subskribieren und Ankündigen von Notifikationen. Notifikationen bestehen aus typisierten Attributen, die in Form von (Name, T yp, W ert) Tripeln angegeben werden. Die Auswahl möglicher Typen ist jedoch auf eine feste, vordefinierte Menge beschränkt. Subskriptionen bzw. Filter erlauben die Angabe einfacher Prädikate über den Attributwerten. Siena nutzt Covering-Based Routing als inhaltsbasierten Routing-Algorithmus [CRW00], wobei statische, azyklische Netzwerktopologien unterstützt werden. Eine Rekonfiguration des Brokernetzes, bestehend aus den Siena Servern, ist nicht vorgesehen. Allerdings werden in [CIP02] und [CCW03] Erweiterungen für mobile Klienten vorgestellt, die auf dem Zwischenspeichern der Notifikationen basieren, solange Subscriber nicht mit Brokern verbunden sind. Die vorgeschlagenen Lösungen können den Verlust von Notifikationen drastisch reduzieren, aber aufgrund auftretender Race-Conditions nicht vollständig ausschließen [Zei04] GRYPHON Ziel des seit Frühjar 1997 am IBM Watson Research Center bestehenden Gryphon Projekts [IBM01b] ist die Entwicklung eines hoch skalierbaren, zuverlässigen sowie sicheren inhaltsbasierten Publish/Subscribe Systems. Gryphon ist heute als IBM WebSphere MQ Event Broker Bestandteil von IBMs kommerzieller WebSphere Produktreihe [IBM05] und wurde bereits erfolgreich bei globalen Sportveranstaltungen wie den australischen Olympischen Spielen 2000 oder Wimbledon 2001 eingesetzt. Gryphons Zuverlässigkeit und Skalierbarkeit beruhen auf Redundanz. Virtuelle Broker werden eingeführt, die aus Zellen (Clustern) untereinander vernetzter physischer Broker bestehen. Eine Kante im Netz der virtuellen Broker wird auf ein Bündel von Verbindungen zwischen physischen Brokern der verschiedenen Zellen abgebildet. So kann einerseits die Last aufgeteilt und andererseits der Ausfall einzelner physischer Broker oder Verbindungen toleriert werden. Gryphon unterscheidet zwischen Brokern, die entweder nur für Publisher oder nur für Subscriber zuständig sind, sowie zwischen intermediären Brokern, die keine Klienten besitzen. Das Routing der Notifikationen wird von einem Informationsfluss-Graphen (IFG)

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten

Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten Prof. Dr. P. Tran-Gia Methoden zur adaptiven Steuerung von Overlay-Topologien in Peer-to-Peer-Diensten 4. Würzburger Workshop IP Netzmanagement, IP Netzplanung und Optimierung Robert Henjes, Dr. Kurt Tutschku

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung

Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung Algorithmen für Peer-to-Peer-Netzwerke Sommersemester 2004 04.06.2004 7. Vorlesung 1 Kapitel III Skalierbare Peer to Peer-Netzwerke Tapestry von Zhao, Kubiatowicz und Joseph (2001) Netzw erke 2 Tapestry

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91 Inhaltsverzeichnis Vorwort 13 Kapitel 1 Einleitung 17 1.1 Definition eines verteilten Systems................................ 19 1.2 Ziele........................................................ 20 1.2.1

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS

Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Verfahren zur Berechnung von Routen zur Gewährleistung von Ende-zu-Ende QoS Dezember 007 Dipl.-Ing. Stefan Abu Salah Dipl.-Ing. Achim Marikar QoS (Quality of Service): Sicherstellung der Qualität Zeitkritische

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Autonome Koordination verteilter. seine Bedeutung für E-Government

Autonome Koordination verteilter. seine Bedeutung für E-Government Autonome Koordination verteilter Services Ein neues Paradigma und seine Bedeutung für E-Government A.o. Univ. Prof. Dr. DI eva Kühn TU Wien, Institut für Computersprachen Space Based Computing Group 1040

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung

Peer-to-Peer-basierte kollaborative Spam-Erkennung und Filterung Der folgende Seminarbericht dient als Grundlage für die Studien-/Diplomarbeit über ein P2P basiertes Spambekämpfungssystem. Für die Studien/Diplomarbeit besonders relevante Stellen sind fett markiert.

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater

Rechnernetze Übung 8 15/06/2011. Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1. Switch. Repeater Rechnernetze Übung 8 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2011 Schicht 7 Schicht 6 Schicht 5 Schicht 4 Schicht 3 Schicht 2 Schicht 1 Repeater Switch 1 Keine Adressen 6Byte

Mehr

3 Das verbindungslose Vermittlungsprotokoll IP

3 Das verbindungslose Vermittlungsprotokoll IP Das verbindungslose Vermittlungsprotokoll IP 27 3 Das verbindungslose Vermittlungsprotokoll IP In diesem Kapitel lernen Sie das verbindungslose Vermittlungsprotokoll IP näher kennen. Nach dem Durcharbeiten

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

ServiceGlobe: Flexible and Reliable Web Service Execution

ServiceGlobe: Flexible and Reliable Web Service Execution ServiceGlobe: Flexible and Reliable Web Service Execution Markus Keidl, Stefan Seltzsam und Alfons Kemper Universität Passau Fakultät für Mathematik und Informatik 94030 Passau @db.fmi.uni-passau.de

Mehr

Schnittstelle zu Inxmail. Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld

Schnittstelle zu Inxmail. Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld Schnittstelle zu Inxmail Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

WS 2009/10. Diskrete Strukturen

WS 2009/10. Diskrete Strukturen WS 2009/10 Diskrete Strukturen Prof. Dr. J. Esparza Lehrstuhl für Grundlagen der Softwarezuverlässigkeit und theoretische Informatik Fakultät für Informatik Technische Universität München http://www7.in.tum.de/um/courses/ds/ws0910

Mehr

Dezentralisiertes Quality-of-Service Monitoring

Dezentralisiertes Quality-of-Service Monitoring Dezentralisiertes Quality-of-Service Monitoring Mai 2013 netidee Zwischenbericht Dieses Dokument informiert über den aktuellen Stand des Netidee 2012 Projektes Dezentralisiertes Quality-of-Service Monitoring.

Mehr

Hauptdiplomklausur Informatik März 2002: Internet Protokolle

Hauptdiplomklausur Informatik März 2002: Internet Protokolle Universität Mannheim Fakultät für Mathematik und Informatik Lehrstuhl für Praktische Informatik IV Professor Dr. W. Effelsberg Hauptdiplomklausur Informatik März 2002: Internet Protokolle Name:... Vorname:...

Mehr

Studienprojekt HP-MOM

Studienprojekt HP-MOM Institute of Parallel and Distributed Systems () Universitätsstraße 38 D-70569 Stuttgart Studienprojekt HP-MOM High Performance Message Oriented Middleware 23. Januar 2013 Kurt Rothermel, Frank Dürr, Patrick

Mehr

Erfassung von Umgebungskontext und Kontextmanagement

Erfassung von Umgebungskontext und Kontextmanagement Erfassung von Umgebungskontext und Kontextmanagement Jörg Schneider, Christian Mannweiler, Andreas Klein, Hans D. Schotten 13.05.2009 Inhalt 1. Einleitung 2. Anforderungen 3. Kontext Erfassung und Verteilung

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Netzwerke 3 Praktikum

Netzwerke 3 Praktikum Netzwerke 3 Praktikum Aufgaben: Routing unter Linux Dozent: E-Mail: Prof. Dr. Ch. Reich rch@fh-furtwangen.de Semester: CN 4 Fach: Netzwerke 3 Datum: 24. September 2003 Einführung Routing wird als Prozess

Mehr

DATENBLATT IDEE ZIELE LÖSUNG VORTEILE VORAUSSETZUNGEN. www.nospamproxy.de

DATENBLATT IDEE ZIELE LÖSUNG VORTEILE VORAUSSETZUNGEN. www.nospamproxy.de www.nospamproxy.de Net at Work Netzwerksysteme GmbH Am Hoppenhof 32, D-33104 Paderborn Tel. +49 5251 304-600, Fax -650 info@netatwork.de www.netatwork.de DIE IDEE Der Anlass zu entwickeln, ist der gestiegene

Mehr

Verteilte Systeme CS5001

Verteilte Systeme CS5001 CS5001 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Einführung Administratives Unterlagen Verwendbar: Master of Science (Informatik) Wahlpflichtfach (Theorie-Pool) Unterlagen Folien:

Mehr

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen Rodrigo Nebel Institut für Informatik Lehrstuhl für Rechnernetze und Kommunikationssysteme (Informatik 7) Friedrich-Alexander-Universität

Mehr

IP routing und traceroute

IP routing und traceroute IP routing und traceroute Seminar Internet-Protokolle Dezember 2002 Falko Klaaßen fklaasse@techfak.uni-bielefeld.de 1 Übersicht zum Vortrag Was ist ein internet? Was sind Router? IP routing Subnet Routing

Mehr

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung

Use-Cases. Bruno Blumenthal und Roger Meyer. 17. Juli 2003. Zusammenfassung Use-Cases Bruno Blumenthal und Roger Meyer 17. Juli 2003 Zusammenfassung Dieses Dokument beschreibt Netzwerk-Szenarios für den Einsatz von NetWACS. Es soll als Grundlage bei der Definition des NetWACS

Mehr

Peer-to-Peer- Netzwerke

Peer-to-Peer- Netzwerke Peer-to-Peer- Netzwerke Christian Schindelhauer Sommersemester 2006 12. Vorlesung 14.06.2006 schindel@informatik.uni-freiburg.de 1 Inhalte Kurze Geschichte der Peer-to-Peer- Netzwerke Das Internet: Unter

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Steinerbäume. Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering

Steinerbäume. Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering Steinerbäume Seminarausarbeitung Hochschule Aalen Fakultät für Elektronik und Informatik Studiengang Informatik Schwerpunkt Software Engineering Verfasser Flamur Kastrati Betreuer Prof. Dr. habil. Thomas

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik

Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Fachgebiet Didaktik der Informatik Konzeption und prototypische Implementierung eines Knowledge-Servers mit Adaptern zur Integration

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Datenstrukturen & Algorithmen

Datenstrukturen & Algorithmen Datenstrukturen & Algorithmen Matthias Zwicker Universität Bern Frühling 2010 Übersicht Binäre Suchbäume Einführung und Begriffe Binäre Suchbäume 2 Binäre Suchbäume Datenstruktur für dynamische Mengen

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

Public-Key-Infrastrukturen

Public-Key-Infrastrukturen TECHNISCHE UNIVERSITÄT DARMSTADT FACHGEBIET THEORETISCHE INFORMATIK PROF. DR. J. BUCHMANN DR. A. WIESMAIER 9. Übung zur Vorlesung Public-Key-Infrastrukturen Sommersemester 2011 Aufgabe 1: Indirekte CRL

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

Band M, Kapitel 5: Server

Band M, Kapitel 5: Server Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-0 E-Mail: Hochverfuegbarkeit@bsi.bund.de Internet: https://www.bsi.bund.de Bundesamt für Sicherheit

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Chapter 7 Distanzvektorprotokolle. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von

Chapter 7 Distanzvektorprotokolle. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Chapter 7 Distanzvektorprotokolle CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

costream Collaborative Media Streaming

costream Collaborative Media Streaming Institut für Betriebssysteme und Rechnerverbund Technische Universität Braunschweig 21. September 2004 1 Inhalt Einleitung Szenarien Proxy-Architektur zur Signalisierung Auffinden von Diensten Gruppenkommunikation

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Name: Vorname: Matrikelnummer: Studiengang: E-Mail: Schreiben Sie zunächst sofort Ihren Namen und Matrikelnummer auf

Mehr

Zuverlässige Kommunikationsverbindungen

Zuverlässige Kommunikationsverbindungen Peter Dorfinger Zuverlässige Kommunikationsverbindungen 7. IT-Businesstalk Die 90er Getrennte Netze für Telefonie und Internet Oft eigene Verkabelung für Internet / Telefonie / Fernsehen Eigene Komponenten

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1

Hochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1 Modul 7: SNMPv3 18.06.2014 14:42:33 M. Leischner Netzmanagement Folie 1 SNMP-Versionen Party-Based SNMP Version 2 (SNMPv2p) User-Based SNMP Version 2 (SNMPv2u) SNMP Version 3 1988 1989 1990 1991 1992 1993

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag)

Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag) Lehrstuhl für Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag) Markus Sieber Betreuer: Ali Fessi,

Mehr

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle ein Versandsystem das immer passt Dokumentation SAP-IDoc Schnittstelle Inhalt 1 HVS32 Anbindung an SAP mit IDocs...2 1.1 Integration...2 1.1.1 HVS32...2 1.1.2 HVS32-Gateway...2 1.2 Ablauf...3 2 IDoc Typen...4

Mehr

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Peter Hillmann Institut für Technische Informatik Fakultät für Informatik Peter.Hillmann@unibw.de Peter Hillmann 1 Gliederung 1. Motivation

Mehr

Kürzeste Wege in Graphen. Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik

Kürzeste Wege in Graphen. Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik Kürzeste Wege in Graphen Maurice Duvigneau Otto-von-Guericke Universität Fakultät für Informatik Gliederung Einleitung Definitionen Algorithmus von Dijkstra Bellmann-Ford Algorithmus Floyd-Warshall Algorithmus

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Informationsintegration

Informationsintegration Informationsintegration Grundlegende Architekturen Ulf Leser Inhalt diese Vorlesung Klassifikation verteilter, autonomer, heterogener Systeme Weitere Klassifikationskriterien Schichtenaufbau integrierter

Mehr

14. Fachtagung Mobilkommunikation Osnabrück

14. Fachtagung Mobilkommunikation Osnabrück SOA-basierte Peer-to-Peer-Mehrwertdienstebereitstellung 14. Fachtagung Mobilkommunikation Osnabrück 13. - 14. Mai 2009 Dipl.-Ing. Armin Lehmann, Prof. Dr.-Ing. Ulrich Trick Fachhochschule Frankfurt am

Mehr

paluno Software & CPS Matthias Book Innovationsworkshop Horizon 2020 ICT 23.01.2014

paluno Software & CPS Matthias Book Innovationsworkshop Horizon 2020 ICT 23.01.2014 Impulse aus dem CPS-Netzwerk NRW Software & CPS Matthias Book Innovationsworkshop Horizon 2020 ICT 23.01.2014 Cyber Physical NRW Überblick: Software-technische Herausforderungen Cyber Physical Systems

Mehr

Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and Ren-Hung Hwang

Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and Ren-Hung Hwang Albert-Ludwigs-Universität Freiburg SS 2009 Institut für Informatik Lehrstuhl für Rechnernetze und Telematik Seminararbeit Laptop a location aware peer-to-peer overlay network Chi-Jen Wu, De-Kai Liu and

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr

DriveLock in Terminalserver Umgebungen

DriveLock in Terminalserver Umgebungen DriveLock in Terminalserver Umgebungen Technischer Artikel CenterTools Software GmbH 2011 Copyright Die in diesen Unterlagen enthaltenen Angaben und Daten, einschließlich URLs und anderen Verweisen auf

Mehr

ProCall 5 Enterprise

ProCall 5 Enterprise ProCall 5 Enterprise Installationsanleitung Upgradeverfahren von ProCall 4+ Enterprise auf ProCall 5 Enterprise ProCall 5 Enterprise Upgrade Seite 1 von 10 Rechtliche Hinweise / Impressum Die Angaben in

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

Mehr

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf Vorlesung Modelle für Geschäftsprozesse und Services Prof. Dr. Karsten Wolf Was ist ein Geschäftsprozess? Beispiele: Bearbeitung eines Schadensfalls in einer Versicherung Kreditüberprüfung in einer Bank

Mehr

Synchronisations -Assistent 2.6

Synchronisations -Assistent 2.6 TimePunch Synchronisations -Assistent 2.6 Benutzerhandbuch 22.10.2014 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, Synchronisations-Assistent

Mehr

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr