PUBSCRIBE MIKRO- UND MAKROARCHITEKTUR

Größe: px
Ab Seite anzeigen:

Download "PUBSCRIBE MIKRO- UND MAKROARCHITEKTUR"

Transkript

1 PUBCRIBE MIKRO- UND MAKROARCHITEKTUR M. Redert, C. Reinhard, W. Lehner, W. Hümmer Universität Erlangen-Nürnberg - Lehrstuhl für Datenbanksysteme Martensstr. 3, D Erlangen {mlredert, cnreinha, lehner, Kurzfassung In dem folgenden Beitrag wird die Architektur des Pubcribe-ystems aus zwei unterschiedlichen Perspektiven beleuchtet. Auf der einen eite wird die Makroarchitektur vorgestellt, die sich aus einem Verbund von Vermittlungskomponenten mit unterschiedlichen trategien der verteilten Abarbeitung einzelner ubskriptionsanforderungen ergibt. Auf der anderen eite wird die Architektur mikroskopisch untersucht; Es wird gezeigt, aus welchen Modulen sich jeweils eine einzelne Vermittlungskomponente zusammensetzt. Aus operationeller icht wird dabei insbesondere die Tatsache des Rollenmodells herausgearbeitet.

2 Einleitung 1 Einleitung Die grundlegende Idee eines ubskriptionssystems, wie es ausführlich in [LeHü01] und [LeHR01] geschildert und demgemäß an dieser telle nur skizzenhaft wiedergegeben wird, besteht darin, dass ein Benutzer eine ubskription in inne einer permanenten Anfrage (standing query) absetzt und beim Eintreffen relevanter Informationen über die entsprechenden Vorgänge informiert wird, in dem Daten proaktiv unter Rückgriff auf diverse Auslierungsmechanismen zurückgeliefert werden. Ziel ist ein skalierbares und effizientes datenbankgestütztes ubskriptionssystem zu entwerfen. Der vorliegende Artikel beschreibt die architekturorientierten Merkmale des Pubcribe-ystems aus zwei unterschiedlichen Perspektiven: o wird aus makroskopischer ichtweise ein verteilter Architekturansatz in Abschnitt 4 erläutert. Darin wird das Pubcribe-ystem als ein Netz verteilter erver mit unterschiedlichen trategien zur kooperativen Auswertung von ubskriptionen beschrieben. Darüberhinaus wird eine mikroskopische ichtweise verfolgt, indem die einzelnen Module einer Pubcribe- Vermittlungskomponente erläutert werden. Im Kontext dieser Aufarbeitung, wie sie in den nachfolgenden Abschnitten erfolgt, wird weiterhin die Metadatenverwaltung und die Persistenzsicherung erläutert. 2 Architekturentwurf Dem Pubcribe-ystem liegt eine drei-schichtige Architektur aus mehreren ubskribenten als Clients, einem zentralen Broker auf der erver-chicht und durch gekapselten Datenquellen zugrunde (Abbildung 2.1). Der Informationsfluss erfolgt dabei von den Quellen durch das ystem, wo sie verarbeitet werden, hindurch zu den jeweiligen ubskribenten. Client- chicht Mail M Web... Port erver- chicht ubscription Handler Publisher Hander Informationsfluss - chicht Web-eite Warehouse ystemzeit Abb. 2.1: Mikroarchitektur des Pubcribe-ystems

3 2.1 Client-chicht Client-chicht Die Client-chicht beinhaltet verschiedene Benutzerschnittstellen zum Erstellen, Editieren und manuellen Löschen von ubskriptionen. Im einfachsten Fall handelt es sich dabei um eine Web-eite, über die der Benutzer eine vorgegebene ubskription parametrieren kann. Diese wird dann durch ein CGI-Programm ( Common Gateway Interface ) erzeugt und zum erver übertragen. Weit komplexer ist ein graphisches Werkzeug, das ein interaktives Erstellen eines beliebigen Operatorenbaumes erlaubt (z.b. mit Drag&Drop). Denkbar ist auch eine Integration der chnittstelle in bestehende oftware (z.b. eine Data-Warehouse-Anwendung oder ein Überwachungssystem für Börseninformationen). Unabhängig davon, wie die Benutzerschnittstelle realisiert wird, erfolgt die Kommunikation mit dem erver immer über XML, indem der Client die ubskriptionsdefinition in Form eines XML-Dokuments erzeugt und es an den erver übermittelt chicht Jede Datenquelle, die in das Pubcribe-ystem integriert werden soll, ist durch einen zu kapseln, der Änderungen der Daten erkennt und diese in einem einheitlichen, für die Datenquelle spezifischen chema, ihrem Exportschema, publiziert. Die Erkennung von Änderungen erfolgt abhängig von der Datenquelle entweder synchron (z.b. durch einen Trigger in einem Datenbanksystem) oder asynchron durch regelmäßiges Abfragen der Quelle und den Vergleich mit ihrem letzten Zustand (z.b. bei Web-eiten). Um die Anzahl der Publikationen zu reduzieren, kann der Änderungen akkumulieren und gesammelt an den Broker schicken. Dabei muss er jedoch sicherstellen, dass keine Änderung älter als die bei der Registrierung angegebene Mindestaktualität ist. Bei asynchroner Änderungserkennung lässt sich der genaue Zeitpunkt der Modifikation von Daten häufig nicht exakt ermitteln; per Konvention muss daher ein anderer angenommen werden. Naheliegende Möglichkeiten sind der frühestmögliche Zeitpunkt der Änderungen, ihr Erkennungszeitpunkt oder der Mittelwert dieser beiden Extreme. Entdeckte Änderungen werden in Form einer Queue, die als XML-Dokument repräsentiert ist, an den Broker übertragen. Während die Daten in Datenbanksystemen in strukturierter Form vorliegen, ist dies z.b. bei Web-eiten nicht der Fall. Ein generischer könnte das gesamte HTML-Dokument in einem einzigen Datenfeld publizieren. Ein Zugriff auf Inhalte (z.b. den Titel oder die einzelnen, enthaltenen Informationen) ist einer ubskription dann jedoch nahezu unmöglich. Zwar ist jede beliebige Extraktion durch geeignet mächtige kalarfunktionen prinzipiell machbar, jedoch sehr aufwendig und benutzerunfreundlich. Daher publizieren individuell angepasste die relevanten Informationen der Quelle in einem geeigneten chema. Im Kontext eines bestimmten Informationskanals als unnötig erachtete Daten wie z.b. Werbebanner, Verweise auf andere eiten o.ä. bleiben unberücksichtigt. Zur automatischen Erzeugung solcher sei beispielsweise auf die in [LiPH00] beschriebene XWRAP-Technologie verwiesen.

4 Architekturentwurf 2.3 erver-chicht: Vermittlung/Broker Im erver laufen ubskriptionen und Publikationen zusammen. Hier erfolgt die Auswertung der ubskriptionen auf den durch Publikationen gelieferten Daten. Um eine kalierbarkeit innerhalb dieser chicht zu gewährleisten, ist der erver in kleinere Funktionseinheiten aufgeteilt, die bei Bedarf in beliebiger Kombination auf mehrere Rechner verteilt werden können. Im einzelnen sind dies der, der ubscription Handler, der und der. ie sind schematisch in Abbildung 2.1 dargestellt und werden in den folgenden Abschnitten beschrieben. ubscription Handler Der ubscription Handler nimmt neue ubskriptionen sowie Modifikations- und Löschaufforderungen des Benutzers entgegen. ubskriptionen werden zuerst in Kooperation mit den anderen Broker-Komponenten auf Validität und Ausführbarkeit überprüft. o kontrolliert beispielsweise der, ob alle Datenquellen existieren, ob die Aktualitätsbedingung erfüllt werden kann und ob die Operatoren und Operanden typkompatibel sind. Der prüft, ob er in der Lage ist, Nachrichten über das geforderte Medium auszuliefern. Ist die ubskription ausführbar, so bekommt sie eine eindeutige Identifikation (sid) zugewiesen und wird an den weitergeleitet, der sie zur Bearbeitung vorbereitet. Der ist für die Kommunikation mit den n der Datenquellen verantwortlich. Er nimmt Registrierungen und Publikationen entgegen und validiert diese. Zur Verarbeitung werden sie an den weitergeleitet. Bei der Registrierung neuer Produzenten wird eine eindeutige Kennung (pid) generiert, die an den zurückgegeben wird. Dieser benutzt sie als Identifikation, um die Zugehörigkeit einer Publikation zu dem entsprechenden Informationskanal kenntlich zu machen. Die Übermittlung von Anfrageergebnissen an den Anwender wird vom initiiert und vom durchgeführt. Dabei ist prinzipiell zwischen der Auslieferung der Ergebnisse und der Notifikation zu unterscheiden. Bei der Auslieferung erhält der Anwender das gesamte Ergebnis, bei der Notifikation wird ihm lediglich eine Referenz darauf zugestellt und er kann es bei Bedarf abrufen. Der enthält Teilkomponenten, die die Übermittlung über verschiedene Medien realisieren. Naheliegend ist die Zustellung von Anfrageergebnissen über , Fax oder M. Zur Notifikation ist es denkbar, die Resultate auf einem Web-erver zu hinterlegen und den entsprechenden Link als Nachricht über eines der genannten Medien zu versenden. ollen die Daten auf Anwenderseite nachbearbeitet werden (z.b. im Fall einer Web-eite mit generischem ), so erscheint es hilfreich, diese dem entsprechenden Programm direkt über eine Netzverbindung zu übermitteln. Dieser Mechanismus wird auch zur internen Kommunikation im erver benötigt (Abschnitt 3.3).

5 2.4 Rollenmodell des Pubcribe-ystems 177 Der bildet die Kontroll- und Verarbeitungskomponente des Pubcribe-ervers. Hier treffen Publikationen und ubskriptionen aufeinander und die eigentliche Verarbeitung der Daten erfolgt. Bei der Ankunft einer neuen Publikation koordiniert der die Auswertung der Bedingungen. Abhängig von dem Resultat wird eine ubskription je nach ihrem Zustand aktiviert, aus dem ystem entfernt oder die Auswertung und Auslieferung ihres Rumpfs angestoßen. Um die initiale Auswertung einer ubskription vornehmen zu können, kommuniziert der mit den n der Datenquellen. Damit ein Broker möglichst viele ubskriptionen und Publikationen ohne Überlastung verarbeiten kann, werden Bedingungen und Rümpfe von ubskriptionen vor ihrer Ausführung in einem mehrstufigen Prozess optimiert. 2.4 Rollenmodell des Pubcribe-ystems Die Begriffe Produzent und ubskribent sind im Pubcribe-ystem Namen für verschiedene Rollen. Eine Komponente spielt die Rolle eines Produzenten, wenn sie aktiv Daten zur Verfügung stellt. Die Rolle eines ubskribenten ist dadurch gekennzeichnet, dass er über bestimmte Dinge informiert werden will und dies durch eine ubskription mitteilt. Die ystemkomponenten Publisher und ubscriber sind nach den Rollen, die sie im Gesamtsystem spielen, benannt. Der Broker hat als Vermittler zwischen beiden Teilen eine Doppelrolle. Gegenüber den ubskribenten verhält er sich wie ein Produzent, für einen Produzenten wie ein ubskribent. Der Unterschied ist lediglich der, dass die Aktivität bei der Registrierung einer ubskription vom ubskribent ausgeht, bei der Anmeldung eines Informationskanal dagegen vom Produzent. Der Registrierungsvorgang kann jedoch auch so gedeutet werden, dass der Produzent den Broker von der Existenz eines neuen Kanals informiert, worauf sich dieser (implizit) für den gesamten Kanalinhalt subskribiert. 3 Informationskanäle des Brokers Jeder Broker besitzt neben den Informationskanälen, die für die registrierten Produzenten erzeugt werden, mehrere Kanäle, die die aktuelle ystemzeit sowie Metadaten von Produzenten und ubskriptionen beinhalten. Ebenso wird die Wiederherstellbarkeit des ystemzustands nach einem Neustart durch die peicherung des Zustands aller Komponenten in Informationskanälen sichergestellt. Die einheitliche Integration von ystemzeit, Metadaten und Persistenzsicherung durch Informationskanäle gestaltet den Entwurf des Gesamtsystems einfacher und klarer. Die peicherung von Daten erfolgt durch die icherung der Kanalzustände, der Zugriff durch ubskriptionen. Diese gleichartige Repräsentation von ystemdaten hat allerdings den Preis des erhöhten Aufwands. o erzeugt z.b. jede Publikation eine weitere, die die Metadaten

6 Informationskanäle des Brokers aktualisiert. Das Einfügen einer ubskription erzeugt zusätzlich zur Publikation ihrer Metadaten mehrere weitere Publikationen, die den aktualisierten Zustand der veränderten ystemkomponenten bekannt machen. In den nachstehenden Abschnitten werden die genannten Informationskanäle näher beschrieben, ihr chema dargestellt und ihre Funktionsweise verdeutlicht. 3.1 ystemzeit Die Bereitstellung der ystemzeit zur Verwendung in ubskriptionen erfolgt über einen Informationskanal Zeit. Da dieser zu jedem Zeitpunkt nur einen gültigen Wert enthält, ist keine Identifikation erforderlich; er besitzt das folgende chema: ([], [(zeit, datetime)]) Beim tart des Brokers wird ein Produzent erzeugt, der sich registriert und dann in regelmäßigen Abständen die aktuelle ystemzeit publiziert. Die Häufigkeit der Publikationen und damit die zeitliche Auflösung hängt von den an das ystem gestellten Ansprüchen ab. Diese ichtweise vereinfacht die Ereignisbehandlung z.b. im Vergleich mit dem OpenCQ- Projekt ([LiPT99]) erheblich, da die Unterscheidung zwischen zeitabhängigen und datenabhängigen Bedingungen entfällt. Das Konzept des Gesamtsystems gestaltet sich dadurch einheitlicher. 3.2 Metadaten Informationen über die registrierten Produzenten sowie die im ystem vorhandenen ubskriptionen werden als Metadaten in eigenen Informationskanälen verwaltet. ie werden somit genau wie die Daten normaler Informationskanäle behandelt und sind auch wie diese durch ubskriptionen zugreifbar. Metadaten der Produzenten Die Metadaten eines Produzenten enthalten neben den Registrierungsdaten Informationen über seine bisherigen Publikationen. Das chema des Kanals ist zusammen mit der Bedeutung der Attribute im Folgenden aufgeführt: ([(pid, integer) // ID des Produzenten ], [(channel, string), // Name des Informationskanals (registration, string), // XML-Dokument der Registrierung (regtime, datetime), // Zeitpunkt der Registrierung (publcount, integer), // Anzahl der Publikationen (publtuplecount, integer), // Anzahl der publizierten Tupel (lastpubltime, datetime), // Zeitpunkt der letzten Publikation (lastpubl, string) // XML-Dokument der letzten

7 3.2 Metadaten 179 ] ) Publikation Die meisten der Attribute sind selbsterklärend. Der Unterschied zwischen publcount und publtuplecount ergibt sich aus der Möglichkeit, mehrere Tupel in einer Publikation zusammenzufassen. Das erstgenannte Attribut bezeichnet die Anzahl der Publikationen, das letztgenannte die Anzahl der publizierten Tupel. Die Verwendung der Metadaten wird in dem am Ende dieses Abschnitts folgenden Beispiel illustriert. Metadaten der ubskriptionen Analog zu den Produzenten verwaltet das ystem auch für jede ubskription einen Metadatensatz. ein chema gliedert sich einerseits in Daten, die in der ubskriptionsdefinition enthalten sind, und andererseits in Informationen zum bisherigen Verlauf der ubskription. Nachfolgend ist das chema des Metainformationskanals sowie die Bedeutung der Attribute dargestellt: ([(sid, integer) // ID der ubskription ], [(recipient, string), // Typ und Adresse des Empfängers (subscription, string), // XML-Dokument der ubskription (state, string), // Zustand der ubskription (nicht aktiviert, aktiviert) (regtime, datetime), // Zeitpunkt der Registrierung (acttime, datetime), // Zeitpunkt der Aktivierung (delivcount, integer), // Anzahl der Auslieferungen (lastdelivtime, datetime), // Zeitpunkt der letzten Auslieferung (lastdeliv, string) // XML-Dokument der letzten Auslieferung ] ) Die Publikation von Metadaten in eigene Informationskanäle fügt sich nahtlos ins Gesamtkonzept ein. ubskriptionen haben Zugriff auf Metadaten wie auf jede andere Datenquelle auch. Eine onderbehandlung ist jedoch bei den ubskriptionsmetadaten notwendig: aus Gründen des Datenschutzes sollen ubskriptionen nur auf ihre eigenen Metadaten zugreifen können. Um dies zu gewährleisten, fügt der beim Aufbau des Operatorenbaums implizit vor jedem Ressourcen-Knoten, der die Metadaten bezeichnet, eine elektion ein, die fremde Metadaten herausfiltert. Die Verwendung von Metadaten in ubskriptionen wird durch das folgende Beispiel illustriert. Dazu zeigt Abbildung 3.1 den Rumpf einer ubskription, die die Namen aller seit ihrer letzten Auslieferung registrierten Informationskanäle sowie deren Registrierungszeitpunkt liefert. Dazu werden die Metadaten der Produzenten (P-Meta) mit denen der ubskription (-Meta) verbunden. Dieses kartesische Produkt enthält jedoch nur so viele Tupel wie der P-Meta-Kanal, da der rechte Ast des Verbundes nur einen Datensatz liefert. Der folgende kalaroperator belegt das neue Attribut reglater mit dem Ergebnis des Vergleichs vom Zeit-

8 Informationskanäle des Brokers ([pid, sid, reglater], [channel, regtime]) elektion reglater=true ([pid, sid, reglater], [channel, regtime]) hift reglater ([pid, sid], [channel, regtime, reglater]) kalar channel=id(channel) regtime=id(regtime) reglater=greater(regtime, lastdelivtime) Verbund ([pid, sid], [channel, regtime,..., lastdelivtime,...]) ([pid], [channel, regtime,...]) P-Meta ([pid], [channel, regtime,...]) ([sid], [lastdelivtime,...]) elektion sid=id ([sid], [lastdelivtime...]) -Meta ([sid], [lastdelivtime,...]) Abb. 3.1: Rumpf einer ubskription mit Metadaten punkt der Registrierung und dem der letzten Auslieferung. Das Attribut wird anschließend in den Identifikationsteil verschoben, um dann diejenigen Tupel, für die es wahr ist, auszuwählen. Die oben erwähnte implizite elektion zum Herausfiltern der Metadaten fremder ubskriptionen ist in der Abbildung grau schattiert dargestellt. ID ist die vom ubscription Handler vergebene, eindeutige Kennung der ubskription. 3.3 Persistenz des Pubcribe-ystems Damit ein Broker bei einem Neustart an der telle wiederaufsetzen kann, an der er heruntergefahren wurde (bzw. abgestürzt ist), muss die Persistenz seines Verarbeitungszustands sichergestellt werden. Zu diesem Zweck publiziert jede ystemkomponente ihre Zustandsänderungen in einen oder mehrere dafür vorgesehene Informationskanäle. Bei einem Wiederanlauf verschafft sie sich ihre Zustandsinformationen durch eine ubskription auf den gesamten Kanalinhalt und rekonstruiert daraus ihren letzten Zustand. Damit eine solche ubskription realisierbar ist, muss der Informationskanal abfragbar sein, d.h. es muss eine Komponente existieren, die seinen Zustand sichert. Um den Mehraufwand gering zu halten, wird diese Aufgabe vom Broker selbst übernommen. Dabei muss sichergestellt werden, dass die Zustandsänderung, ihre Publikation und die icherung transaktional geschützt erfolgen. Hierzu stehen verschiedene Mechanismen verteilter und geschachtelter Transaktionen zur Verfügung, auf die jedoch an dieser telle nicht näher eingegangen werden soll. Die ubskription zur Wiederherstellung des Zustands muss die asynchrone Auslieferung der Ergebnisse in eine synchrone Weiterverarbeitung einbinden. Dazu macht sie Gebrauch von der direkten Auslieferung der Ergebnisse über eine Netzverbindung. ie öffnet einen Kommunikationsendpunkt ( Port ), schickt die ubskription ab und wartet auf die Ergebnisse. Da es sich um eine synchrone ubskription handelt, werden diese sofort nach der Auswertung verschickt.

9 3.3 Persistenz des Pubcribe-ystems 181 Es sei noch angemerkt, dass die Zustandsinformationen der Komponenten auch zur Administration des ystems und zur Fehlersuche verwendet werden können. ollen beispielsweise die in der Data Processing Unit enthaltenen Operatorenbäume überwacht werden, so kann ein Werkzeug eine ubskription auf den entsprechenden Informationskanal einrichten. Es wird somit bei jeder Änderung sofort informiert und kann darauf z.b. mit der Aktualisierung seiner Darstellung reagieren. In einem realen ystem sollte jedoch ein Zugriffsschutz für derartige Informationen vorgesehen werden, damit nicht jeder Anwender Einsicht in interne trukturen des Brokers erlangen kann. Die icherung des Zustands einer Komponente wird am Beispiel des Publisher Handlers und einer eintreffenden Publikation erläutert. Erreicht eine neue Publikation den, so ist er für deren Verifikation, die Aktualisierung der Metadaten und die Weiterleitung an den verantwortlich (Abschnitt 2.3). ein Zustand beinhaltet die noch nicht weitergeleiteten Publikationen und den tatus ihrer Verarbeitung und wird in drei Informationskanälen gespeichert. Die zur Zustandssicherung notwendigen Publikationen sind in Abbildung 3.2 schematisch in zeitlicher Abfolge dargestellt und werden im Folgenden erläutert. Produzent Publikation Publikation sichern ID-Vergabe Bestätigung Verifikation Zustandsaktualisierung BI der Metadaten sichern Metadatenaktualisierung Zustandsaktualisierung BI der Metadaten löschen Weiterleitung Persistenzsicherung Bestätigung Publikation löschen Trifft eine neue Publikation ein, so bekommt diese zuerst eine eindeutige Abb. 3.2: Ablauf der Zustandssicherung Identifikation zugewiesen und wird in dem Kanal, der unvollständig bearbeitete Publikationen enthält, gesichert. Damit ist ihre Persistenz gewährleistet und dem Produzent kann der Erhalt der Nachricht bestätigt werden. Nachdem die Publikation verifiziert ist, wird ihr Bearbeitungszustand durch eine Publikation in einen weiteren Kanal auf unbearbeitet gesetzt. Da die Verifikation jederzeit ohne eiteneffekte wiederholt werden kann, muss ihr Abschluss nicht protokolliert werden. Dann werden die Metadaten des Produzenten ausgelesen und als Kopie ( Before-Image, BI) in einem dritten Kanal gesichert. Jetzt können die aktualisierten Metadaten publiziert und die icherungskopie gelöscht werden. Damit keine Inkonsistenzen entstehen, darf der Prozess der Metadatenaktualisierung nicht für mehrere Publikationen eines Kanals gleichzeitig erfolgen. Der Zustand der Bearbeitung wird nun durch eine entsprechende Publikation auf Metadaten aktualisiert gesetzt.

10 Verteilter Architekturentwurf Im letzten chritt wird die Publikation an den weitergegeben. Dieser publiziert sie zur Persistenzsicherung in einen seiner Zustandskanäle und schickt eine Bestätigung an den. Er kann die Publikation nun aus seinem Kanal der zu bearbeitenden Publikationen löschen und die zugehörigen Zustandsinformationen entfernen. Damit dieser Mechanismus funktioniert, darf der Zustand des s bei der Verarbeitung von Zustands-Publikationen nicht gesichert werden, weil sonst eine endlose Kette derartiger Publikationen entstehen würde. Es wird dadurch in Kauf genommen, dass die Korrektheit der Metadaten der Zustandskanäle im Fall eines ystemabsturzes nicht mehr garantiert werden kann. Da sie jedoch nicht zum Betrieb benötigt werden, ist dies unproblematisch. 4 Verteilter Architekturentwurf Um eine bessere kalierbarkeit zu erzielen, werden mehrere lokale Instanzen des Pubcribe- ystems über ein Netzwerk verteilt. Wie in Abbildung 4.1 dargestellt, sind ubskriptionen und Publisher dabei wie im unverteilten Fall einer der Instanzen zugeordnet. owohl zum Benutzer als auch zu den Produzenten hin soll sich dieser Verbund wie ein unverteiltes ystem verhalten (Verteilungstransparenz). Dies bedeutet insbesondere, dass eine ubskription unabhängig von dem Broker, bei dem sie registriert wird, und unabhängig von dem Broker, bei dem die referenzierten Datenquellen angemeldet sind, immer dasselbe Ergebnis liefern muss. Um dies zu ermöglichen, ist die Kommunikation zwischen den Verbundpartnern erforderlich. Es wird davon ausgegangen, dass das Verbindungsnetz den Nachrichtenaustausch zwischen beliebigen Komponenten erlaubt. Die Kommunikation zwischen Brokern erfolgt über bereits von der lokalen Architektur her bekannte Mechanismen, nämlich Informationskanäle und ubskriptionen, und fügt sich somit nahtlos in das Gesamtkonzept des ystems ein. Benötigt ein Broker z.b. zur Beantwortung einer Anfrage Informationen, über die er nicht selbst verfügt, so subskribiert er sich bei einem anderen für diese. Er nimmt damit die Rolle eines ubskribenten ein, der andere Broker die Rolle eines Produzenten. Wie in Abbildung 4.1 durch die Verbindungspfeile dargestellt, können zwischen den Broker-Instanzen eines Gesamtsystems eine Vielzahl solcher Abhängigkeiten existieren, sodass ein Broker auch beide Rollen gleichzeitig innehaben kann. Der linke untere Broker der Abbildung ist z.b. Publisher für die beiden oberen und ubskribent des rechten unteren. Das entstehende Netz von Abhängigkeiten zwischen Brokern kann beliebig komplex werden, es dürfen jedoch keine Zyklen auftreten. Das in Abschnitt 2.4 für ein unverteiltes ystem dargestellte Rollenkonzept wird durch dieses Konzept auch in einer verteilten Architektur eingehalten. Eine Liste der dem Gesamtsystem angehörenden Broker wird ebenso über einen globalen Metadatenkanal zur Verfügung gestellt, wie Informationen darüber, welcher Broker über welche Informationskanäle verfügt. Das chema der beiden Kanäle wird in Abschnitt 4.1 beschrieben. Ein ausgezeichneter Broker (in Abbildung 4.1 links oben schattiert dargestellt)

11 4.1 Der globale Metadatenkanal 183 übernimmt die Verwaltung der Kanäle, was jedoch eine Replikation nicht ausschließt. Um die Daten aktuell halten zu können, müssen sich Broker bei ihm registrieren und er muss über neue und entfernte Informationskanäle oder Replikate informiert werden. 4.1 Der globale Metadatenkanal In einer verteilten Umgebung dienen die globalen Metadaten einerseits dazu, die am Gesamtsystem beteiligten Broker zu verwalten, andererseits enthalten sie Informationen darüber, welche Datenquellen bei welchem Broker mit welcher Aktualität verfügbar sind. ie werden durch zwei Informationskanäle realisiert. Der erste Kanal enthält alle registrierten Broker und hat das folgende chema: ([(bid, integer) ], [(hostname, string), // ID des Brokers // Rechnername ubscription Handler ubscription Handler Warehouse Metadaten Web-eite ubscription Handler ubscription Handler Warehouse Warehouse ystemzeit Web-eite Web-eite Abb. 4.1: Makroarchitektur des Pubcribe-ystems

12 Verteilter Architekturentwurf (port, integer) ] ) // Port-Nummer Das Attribut bid identifiziert einen Broker eindeutig und wird bei seiner Registrierung von dem ausgezeichneten Broker vergeben. Die beiden Informationsattribute hostname und port geben an, über welche Adresse eine ubskription bei diesem Broker in des ystem eingebracht werden kann. Der zweite Metadatenkanal enthält Informationen darüber, welcher Kanal (name) bei welchem Broker (bid) mit welcher Aktualität (qos) geführt wird. Das Attribut master gibt an, ob es sich bei dem Informationskanal um den primären Kanal oder ein Replikat (Abschnitt 4.2) handelt. Die Metadaten besitzen das folgende chema: ([(name, string), (bid, integer) ], [(qos, integer), (master, boolean) ] ) // Name des Informationskanals // ID des Brokers // Aktualität der Daten // primärer Kanal oder Replikat Globale Metadaten müssen abfragbar sein, um einerseits den Zugriff auf in der Vergangenheit publizierte Daten zu erhalten, aber auch, um einen Neustart des ausgezeichneten Brokers zu überdauern. Da die Metadaten bei ihm anfallen, ist er auch für die Realisierung der Abfragbarkeit zuständig. 4.2 Zusammenführung von Publikationen und ubskription Referenziert eine ubskription einen Informationskanal, der nicht beim lokalen Broker vorhanden ist, so existieren prinzipiell zwei Möglichkeiten: entweder verschafft sich der Broker, bei dem die ubskription eingegangen ist, die Daten ( data shipping ) oder sie wird bei einem Broker ausgeführt, der über die entsprechenden Daten verfügt ( query shipping ). Die erste Variante wird im Kontext des Pubcribe-ystems als Kanalreplikation ( channel replication ) bezeichnet, die letztere je nach Ausprägung als entfernte Auswertung ( remote evaluation ) bzw. ubskriptionsweiterleitung ( subscription forwarding ). Die drei Verfahrensweisen werden nachfolgend beschrieben. Kanalreplikation Bei der Kanalreplikation wird die ubskription von dem Broker, bei dem sie eingegangen ist, ausgeführt. Da die benötigten Daten nicht vorhanden sind, müssen sie beschafft werden. Dieser Vorgang ist in Abbildung 4.2 schematisch dargestellt. Durch eine synchrone ubskription ermittelt der Broker aus den globalen Metadaten zuerst diejenigen Broker, die über die geforderten Daten in genügend hoher Aktualität verfügen (chritt 1 und 2). Einer der möglichen Kanäle wird als Quelle des neu anzulegenden Replikats ausgewählt. Bei diesem (in der Abbildung links unten) subskribiert sich der Broker dann für die gesamten Publikationen des

13 4.2 Zusammenführung von Publikationen und ubskription 185 ([name, bid, qos, bid2], [master, hostname, port]) Verbund bid = bid elektion name = Aktien qos 10 ([name, bid, qos], [master]) Broker ([bid], [hostname, port]) hift qos Kanäle ([name, bid], [qos, master]) ([name, bid, qos], [master]) Abb. 4.3: ubskription zur Abfrage der globalen Metadaten Kanals und erzeugt somit eine lokale Kopie der Informationen (chritt 3). Über die Auslieferungsbedingung kann er die gewünschte Aktualität des Replikats steuern. Nun verfügt der Broker über die notwendigen Daten und kann die Auswertung der ubskription lokal vornehmen. Durch eine Publikation in den Metadatenkanal macht er bekannt, dass er nun auch über eine lokale Kopie des Informationskanals verfügt (chritt 4). Regelmäßige Auslieferungen der ubskriptionsergebnisse halten das Replikat auf den aktuellen tand (chritt 5). Das folgende Beispiel illustriert den Vorgang der Kanalreplikation. Als Beispiel zum Ablauf einer Kanalreplikation sei folgendes zenario gegeben: Zur Auswertung einer ubskription muss ein Broker ein Replikat des Informationskanals Aktien erzeugen, welches die von der ubskription geforderte Aktualität von 10 besitzen soll. Der Rumpf der synchronen ubskription, die die als Quelle in Frage kommenden Broker ermittelt, ist in Abbildung 4.3 dargestellt. Zunächst werden darin alle Aktien-Kanäle mit einer aus- 2 ubscription Handler 1 ubscription Handler tub Metadaten 5 3 ubscription Handler 4 Web-eite Abb. 4.2: Ablauf der Kanalreplikation

14 Verteilter Architekturentwurf chalter ([wp, hp, zeit], [kurs, vol]) ([wp, hp, zeit], [kurs, vol]) Aktien ([wp, hp, zeit], [kurs, vol]) ([sid], [bedingungok]) kalar bedingungok = greater(differenz, 10) ([sid], [differnz]) kalar differenz = minus(uhrzeit, last) Verbund ([sid], [uhrzeit, lastdelivtime,...]) ([], [uhrzeit]) Zeit ([], [uhrzeit]) ([sid], [lastdelivtime,...]) elektion id = ID ([sid], [lastdelivtime,...]) Abb. 4.4: ubskription zur Replikation des Aktien-Kanals reichend hohen Aktualität selektiert. Um die Adressen der zugehörigen Broker zu erhalten, werden diese anschließend mit den entsprechenden Metadaten verbunden und ein Broker als Quelle für die Kopie ausgewählt. Die Etablierung des Replikats erfolgt durch die in Abbildung 4.4 dargestellte ubskription (Rumpf und Auslieferungsbedingung). Mit Hilfe der Metadaten der ubskriptionen initiiert die Bedingung eine Auslieferung alle 10 Minuten. Für die Einhaltung des Zeitintervalls sorgt der kalaroperator mit der Bedingung differenz 10. Da der Broker lediglich an Änderungen interessiert ist, erfolgt die Auswertung des Rumpfes partiell, d.h. zwischen zwei Benachrichtigungen gleich gebliebene Daten werden nicht erneut ausgeliefert. Die tartbedingung der ubskription ist konstant wahr, sodass die Kopie mit sofortiger Wirkung erstellt wird. Wie lange das Replikat tatsächlich benötigt wird, ist zum Zeitpunkt seiner Etablierung noch unklar, da es möglicherweise auch von noch nicht existierenden ubskriptionen genutzt wird. Die topbedingung wird daher so gewählt, dass sie niemals wahr wird. Zur Entfernung des Replikats wird die Löschfunktion der Administrationsschnittstelle benutzt. Als letzter chritt des Vorgangs muss die Existenz des neuen Replikats allen Brokern durch eine Publikation in den globalen Metadatenkanal bekannt gemacht werden, die wie folgt aussieht: ([ Aktien, 3], [10, false]) Metadaten ([sid], [lastdelivtime,...]) Zur initialen Auswertung einer ubskription muss der betreffende Informationskanal abfragbar sein. Verfügt der das Replikat haltende Broker bereits über des Gesamtzustand des Kanals, so kann die initiale Auswertung direkt bei diesem erfolgen. Andernfalls wird der entsprechende Operatorenbaum in Form einer ubskription zum Broker, der das Replikat speist, weitergeleitet. Realisiert dieser die Abfragbarkeit des Zustands, so erfolgt die Initialauswertung bei ihm. Ist auch das nicht der Fall, wird der Operatorenbaum zum Publisher selbst weitergeleitet. Ist der Informationskanal abfragbar, so ist spätestens hier eine initiale Auswertung möglich.

15 4.2 Zusammenführung von Publikationen und ubskription 187 Prinzipiell lässt sich der Mechanismus der Kanalreplikation auf alle Informationskanäle anwenden. Aus Gründen des Datenschutzes sollte jedoch eine Replikation der ubskriptions- Metadaten untersagt werden, sodass der Zugriff auf sie immer beim die ubskription koordinierenden Broker erfolgen muss. Da sehr viele ubskriptionen die ystemzeit benötigen, empfielt es sich, diese nicht durch Replikation verfügbar zu machen, sondern bei jedem Broker lokal zu generieren. Der Mehraufwand wird so reduziert und die Netzbelastung minimiert. Entfernte Auswertung Die entfernte Auswertung ist eine Verallgemeinerung der Kanalreplikation. Während bei der Letztgenannten immer komplette Quellen repliziert werden, kann die entfernte Auswertung als ubskription auf einen bereits vorverarbeiteten Kanal angesehen werden. Nachdem der Operatorenbaum durch die DPU analysiert wurde, wird ein Teil, der nur von einer nicht lokal vorhandenen Datenquelle abhängt, abgetrennt. Er wird dann in Form einer ubskription an einen Broker gesendet. Es entsteht ein neuer virtueller Informationskanal, der bereits vorverarbeitete Daten zur Verfügung stellt. Dieser wird statt des Teilbaums in der ubskription referenziert. Jedesmal, wenn die weitergeleitete ubskription ausgewertet wird, gelangen die Ergebnisse durch Publikationen in den virtuellen Kanal und werden so in die Auswertung des Operatorenbaums integriert. Der Ablauf ist also exakt der gleiche wie der in Abbildung 4.2 dargestellte. Der einzige Unterschied zur Kanalreplikation besteht darin, dass in chritt 3 eine andere ubskription registriert wird. Das nachfolgende Beispiel verdeutlicht die Vorgehensweise. Zur Beantwortung einer ubskription muss besipielsweise der in Abbildung 4.5 dargestellte Ausschnitt eines Operatorenbaums ausgewertet werden. Die Daten der mit den Knoten Ressource 2 und Ressource 3 korrespondierenden Informationskanäle liegen lokal vor, die von Ressource 1 nicht. Um möglichst wenige Daten transferieren zu müssen, wird der größte Teilbaum, der nur von diesem Kanal abhängt (in der Abbildung grau hinterlegt), auf den zuvor ermittelten Broker übertragen. Die dazu benutzte ubskription entspricht der in Abbildung 4.4, jedoch ist ihr Rumpf durch den grau hinterlegten Teilbaum ersetzt. Die Häufigkeit der Auslieferung im rechten Teil wird durch die geforderte Aktualitätsbedingung der ubskription ausgetauscht. Im lokalen Broker wird der Teilbaum durch den Ressourcenknoten des durch die ubskription entstandenen virtuellen Informationskanals ersetzt. Gehört der entfernt auszuwertende Operatorenbaum dem aktiven Teil eines chalters, also der Bedingung an, so wird die ubskription zur entfernten Auswertung beim Einbringen des Baums aktiviert und bei dessen Löschung entfernt. Liefert sie Ergebnisse erfolgen also Publikationen in den virtuellen Kanal so löst dies im Operatorenbaum der Benutzer-ubskription Trigger aus. Ist der entfernt auszuwertende Baum hingegen Teil des passiven Zweigs, muss sein Ergebnis bei jeder Auswertungsaufforderung durch eine synchrone ubskription abgefragt werden.

16 Zusammenfassung und Ausblick kalar Gruppierung Verbund elektion Vereinigung hift elektion Gruppierung kalar Ressource 2 kalar Ressource 1 Ressource 3 ubskriptionsweiterleitung Abb. 4.5: Entfernte Auswertung eines Operatorenbaums Im Gegensatz zur entfernten Auswertung, bei der lediglich Teile des Operatorenbaums bei einem anderen Broker ausgewertet werden, die Kontrolle aber beim Empfänger der ubskription bleibt, wird bei der ubskriptionsweiterleitung die gesamte Verarbeitung an einen anderen Broker übertragen. Damit die ubskription mit einem geringeren Aufwand an Ressourcen ausgewertet werden kann, sollte dieser über möglichst viele der benötigten Datenquellen in ausreichender Aktualität verfügen. Ein geeigneter Broker wird aufgrund der Metadaten ausgewählt (chritt 1 und 2 in Abbildung 4.6). Die ubskription wird dann an diesen weitergeleitet (chritt 3) und dort wie gewohnt integriert. Ergebnisse werden direkt von diesem an den ubskribent ausgeliefert (chritt 4). Bei dem Verfahren zur Auswahl des ausführenden Brokers muss sichergestellt werden, dass dieser die ubskription nicht erneut weiterleitet und die Folge der Weiterleitungen zyklisch wird. 5 Zusammenfassung und Ausblick Um das Pubcribe-ystem auch im großen Maßstab skalierbar zu machen, wird in diesem Beitrag eine verteilte Architektur miteinander kooperierender Broker entworfen. Dazu wird zunächst im ersten Abschnitt dieses Beitrags die drei-schichtige Architektur eines unverteilten Pubcribe-ystems dargestellt. Für die Client-chicht werden verschiedene Realisierungsalternativen aufgezeigt, die über XML-Dokumente mit dem auf der zentralen Mittelschicht angesiedelten Broker kommunizieren. Die in das ystem integrierten Datenquellen werden jeweils durch individuelle gekapselt und treten ebenfalls über XML-Doku-

17 5 Zusammenfassung und Ausblick ubscription Handler 1 ubscription Handler tub Metadaten 3 ubscription Handler Web-eite Abb. 4.6: Ablauf der ubskriptionsweiterleitung mente mit dem Broker in Kontakt. Um eine bedingte kalierbarkeit zu erreichen, ist der Broker selbst in mehrere Module untergliedert, die auf verschiedene Rechner verteilt werden können. Zur Verwaltung von ystem- und Metadaten werden Informationskanäle verwendet, sodass für ubskriptionen kein Unterschied zwischen den Daten eines externen Produzenten und diesen internen Informationen besteht. Ebenfalls über Informationskanäle wird der Zustand des Brokers gesichert, sodass er einen Neustart überdauert. Aus makroskopischer ichtweise wird Verteilungstransparenz dadurch erzielt, dass Produzenten und ubskribenten sich wie im zentralen Fall bei einem Broker registrieren. Um Daten und Abfragen zur Auswertung zusammenzubringen, werden drei Mechanismen dargestellt: Kanalreplikation, entfernte Auswertung und ubskriptionsweiterleitung. Literatur BCM+99 Banavar, G.; Chandra, T.; Mukherjee, B.; Nagarajarao, J.; trom, R.E.; turman, D.C.: An Efficient Multicast Protocol for Content-Based Publish-ubscribe ystems. In: Proceedings of the 19th International Conference on Distributed Computing ystems (ICDC 99, Austin (TX), UA, 31. Mai - 4. Juni), 1999, BEK+00 Box, D.; Ehnebuske, D.; Kakivaya, G.; Layman, A.; Mendelsohn, N.; Nielsen, H.F.; Thatte,.; Winer, D.: OAP: imple Object Access Protocol, 2000 CaRW00 Carzaniga, A.; Rosenblum, D..; Wolf, A.L.: Achieving calability and Expressiveness in an Internet-cale Event Notification ervice. In: Proceedings of the 19th ACM ymposium on Principles of Distributed Computing (PODC 2000, Portland (OR), UA, Juli), 2000, Hack97 Hackathron, R.: Publish or Perish. In: Byte Magazin, eptember 1997 (Elektronisch verfügbar unter:

18 Zusammenfassung und Ausblick LeHR01 Lehner, W.; Hümmer, W.; Redert, M.: Building An Information Marketplace using a Content and Memory based Publish/ubscribe ystem. In: Lehner, W. (Ed.): Advanced Techniques in Personalized Information Delivery. Arbeitsbericht des Instituts für Informatik, Friedrich-Alexander Universität Erlangen-Nürnberg, 2001 LeHü01 Lehner, W.; Hümmer, W.: The Revolution Ahead: Publish/ubscribe meets Database ystems. In: Lehner, W. (Ed.): Advanced Techniques in Personalized Information Delivery. Arbeitsbericht des Instituts für Informatik, Friedrich-Alexander Universität Erlangen-Nürnberg, 2001 LiPH00 Liu, L.; Pu, C.; Han, W.: XWRAP: An XML-enabled Construction ystem for Web Information ources. In: Proceedings of the 16th International Conference on Data Engineering (ICDE 2000, an Diego (CA), UA, 28. Februar - 3. März), 2000, (Elektronisch verfügbar unter: LiPT99 Liu, L.; Pu, C.; Tang, W.: Continual Queries for Internet cale Event-Driven Information Delivery. In: IEEE Transactions on Knowledge and Data Engineering (Jahrgang 11, Nummer 1), 1999, AB+00 egall, B.; Arnold, D.; Boot, J.; Henderson, M.; Phelps, T.: Content Based Routing with Elvin4. In: Proceedings of the AUUG 2000 Technical Conference (AUUG 2000, Canberra, Australien, Juni), 2000 W3C99 N.N.: Extensible Markup Language (XML) 1.0. World Wide Web Consortium, 1999 (Elektronisch verfügbar unter: YaGa99 Yan, T.W.; Garcia-Molina, H.: The IFT Information Dissemination ystem. In: ACM Transactions on Database ystems (TOD, Jahrgang 24, Nu

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

T H E P O W E R O F B U I L D I N G A N D M A N A G I N G N E T W O R K S. Operations

T H E P O W E R O F B U I L D I N G A N D M A N A G I N G N E T W O R K S. Operations T H E P O W E R O F B U I L D I N G A N D M A N A G I N G N E T W O R K S by ERAMON GmbH Welserstraße 11 86368 Gersthofen Germany Tel. +49-821-2498-200 Fax +49-821-2498-299 info@eramon.de Inhaltsverzeichnis

Mehr

Unterabfragen (Subqueries)

Unterabfragen (Subqueries) Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

dpa-infocom - Datenlieferung

dpa-infocom - Datenlieferung dpa-infocom - Datenlieferung Copyright 2006 von dpa-infocom GmbH Status des Dokuments: FINAL Inhaltsverzeichnis Inhaltsverzeichnis...1 1. Verzeichnisstrukturen...2 2. Nachrichtenmanagement...2 3. Datenübertragung...3

Mehr

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System)

Kurs 70-291 Notizen Rene Dreher www.renedreher.de -DNS (Domain Name System) -DNS (Domain Name System) Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

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

Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots

Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots Einleitung Analyse alt- und mittelpaläolithischer Steinartefaktinventare mittels Parallelkoordinatenplots von Irmela Herzog Im Rahmen der Herbsttagung der AG DANK (Datenanalyse und Numerische Klassifikation)

Mehr

Online Bedienungsanleitung elektronisches Postfach

Online Bedienungsanleitung elektronisches Postfach Online Bedienungsanleitung elektronisches Postfach 1. elektronisches Postfach 1.1. Prüfung ob das Postfach bereits für Sie bereit steht. 1.2. Postfach aktivieren 1.3. Neue Mitteilungen/Nachrichten von

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

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes

Kapitel. Sicherheit. Seite. Kapitel. Sicherheit. Workplace & WebSphere Domino & Notes Sicherheit 99 9 Sicherheit 7. Ergänzungslieferung 02/2007 Ein ITP-Handbuch 9 Sicherheit 9 Moderne Anwendungen müssen einer Vielzahl von Anforderungen gerecht werden. Mit dem Siegeszug der IT in die Geschäftswelt

Mehr

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

Registrierung Ihres Unternehmens auf der B2B Lieferantenplattform VWGroupSupply.com

Registrierung Ihres Unternehmens auf der B2B Lieferantenplattform VWGroupSupply.com egistrierung Ihres Unternehmens auf der B2B Lieferantenplattform VWGroupupply.com tand: 15. Februar 2009 upplier elf egistration : Teil 1 (Partner werden) von 3 Zur egistrierung auf der VWGroupupply.com

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Bedienungsanleitung ComfortTouch App für Busch-ComfortPanel. Busch-ComfortPanel 9 8136/09-811 8136/09-825

Bedienungsanleitung ComfortTouch App für Busch-ComfortPanel. Busch-ComfortPanel 9 8136/09-811 8136/09-825 1373-1-8367 01.08.2013 Bedienungsanleitung Busch- 9 8136/09-811 8136/09-825 Busch- 12.1 8136/12-811 8136/12-825 1 Einleitung... 3 1.1 Bestimmungsgemäßer Gebrauch... 3 2 Systemvoraussetzung der mobilen

Mehr

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12

Folge 19 - Bäume. 19.1 Binärbäume - Allgemeines. Grundlagen: Ulrich Helmich: Informatik 2 mit BlueJ - Ein Kurs für die Stufe 12 Grundlagen: Folge 19 - Bäume 19.1 Binärbäume - Allgemeines Unter Bäumen versteht man in der Informatik Datenstrukturen, bei denen jedes Element mindestens zwei Nachfolger hat. Bereits in der Folge 17 haben

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

SingleSignOn Schnittstelle

SingleSignOn Schnittstelle SingleSignOn Schnittstelle Integration vom Seminar-Shop mit der Partnerseite unter Verwendung der Seminar-Shop Formulare 1 Grundidee: Eine Website übernimmt den Seminar-Shop Content und wünscht, dass ein

Mehr

Installation des edu- sharing Plug- Ins für Moodle

Installation des edu- sharing Plug- Ins für Moodle Installation des edu- sharing Plug- Ins für Moodle [edu-sharing Team] [Dieses Dokument beschreibt die Installation und Konfiguration des edu-sharing Plug-Ins für das LMS Moodle.] edu- sharing / metaventis

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

Bedienungsanleitung V2.5. Secyourit GmbH, Rupert-Mayer-Str. 44, 81379 München, Deutschland Tel +49-89-12294700 Fax +49-89-72430099

Bedienungsanleitung V2.5. Secyourit GmbH, Rupert-Mayer-Str. 44, 81379 München, Deutschland Tel +49-89-12294700 Fax +49-89-72430099 ecyourit GmbH IENNA Home Connect Bedienungsanleitung V2.5 ecyourit GmbH, Rupert-Mayer-tr. 44, 81379 München, Deutschland Tel +49-89-12294700 Fax +49-89-72430099 Copyright 2014 ecyourit GmbH. Inhaltsverzeichnis

Mehr

Beschreibung E-Mail Regeln z.b. Abwesenheitsmeldung und Weiterleitung

Beschreibung E-Mail Regeln z.b. Abwesenheitsmeldung und Weiterleitung Outlook Weiterleitungen & Abwesenheitsmeldungen Seite 1 von 6 Beschreibung E-Mail Regeln z.b. Abwesenheitsmeldung und Weiterleitung Erstellt: Quelle: 3.12.09/MM \\rsiag-s3aad\install\vnc\email Weiterleitung

Mehr

Handbuch. zur Registrierung / Aktivierung der Lizenzdatei. 4. Auflage. (Stand: 24.09.2014)

Handbuch. zur Registrierung / Aktivierung der Lizenzdatei. 4. Auflage. (Stand: 24.09.2014) Handbuch zur Registrierung / Aktivierung der Lizenzdatei 4. Auflage (Stand: 24.09.2014) Copyright 2015 by NAFI GmbH Unerlaubte Vervielfältigungen sind untersagt! Einführung Um mit dem NAFI Kfz-Kalkulator

Mehr

Anleitung. E-Mail Kontenverwaltung auf mail.tbits.net

Anleitung. E-Mail Kontenverwaltung auf mail.tbits.net Anleitung E-Mail Kontenverwaltung auf mail.tbits.net E-Mail Kontenverwaltung auf mail.tbits.net 2 E-Mail Kontenverwaltung auf mail.tbits.net Leitfaden für Kunden Inhaltsverzeichnis Kapitel Seite 1. Überblick

Mehr

Datenkollektor für SAP Customer Relationship Management (CRM) Status: 09.12.08

Datenkollektor für SAP Customer Relationship Management (CRM) Status: 09.12.08 Datenkollektor für SAP Customer Relationship Management (CRM) Status: 09.12.08 Inhaltsverzeichnis SAP CRM DATENKOLLEKTOR 3 DIE LEISTUNGSMERKMALE DES DATENKOLLEKTORS FÜR SAP CRM...3 Ziele des Monitorings:...3

Mehr

Methoden zur Benutzerüberprüfung im ELMS 1.1

Methoden zur Benutzerüberprüfung im ELMS 1.1 Methoden zur Benutzerüberprüfung im ELMS 1.1 2012-12-21 Kivuto Solutions Inc [VERTRAULICH] INHALTSVERZEICHNIS ÜBERSICHT...1 ÜBERPRÜFUNGSMETHODEN...2 Integrierte Benutzerüberprüfung (IUV)...2 Shibboleth

Mehr

Access und OpenOffice.org

Access und OpenOffice.org Access-Datenbanken in OpenOffice.org 1.1 einbinden Herausgegeben durch das OpenOffice.org Germanophone-Projekt Autoren Autoren vorhergehender Versionen Timo Kozlowski Alle in diesem Dokument erwähnten

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

Dokumentation Softwareprojekt AlumniDatenbank

Dokumentation Softwareprojekt AlumniDatenbank Dokumentation Softwareprojekt AlumniDatenbank an der Hochschule Anhalt (FH) Hochschule für angewandte Wissenschaften Fachbereich Informatik 13. Februar 2007 Betreuer (HS Anhalt): Prof. Dr. Detlef Klöditz

Mehr

Benutzerhandbuch. bintec elmeg GmbH. Benutzerhandbuch. Workshops (Auszug) WLAN-Workshops. Copyright Version 07/2015 bintec elmeg GmbH

Benutzerhandbuch. bintec elmeg GmbH. Benutzerhandbuch. Workshops (Auszug) WLAN-Workshops. Copyright Version 07/2015 bintec elmeg GmbH Benutzerhandbuch Benutzerhandbuch WLAN-Workshops Copyright Version 07/2015 1 Benutzerhandbuch Rechtlicher Hinweis Gewährleistung Änderungen in dieser Veröffentlichung sind vorbehalten. gibt keinerlei Gewährleistung

Mehr

Visualisierung. Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen

Visualisierung. Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen Visualisierung Basierend auf den Artikeln: GridMapper: A Tool for Visualizing the Behavior of Large-Scale Distributed Systems, von

Mehr

Das neue Suite Content Management System

Das neue Suite Content Management System Das neue Suite Content Management System Eine Beschreibung des neuen 'Visual CMS', veröffentlicht mit emarketing Suite Version 8.0 im Mai, 2014 Mai 2014 1 Einführung in das Visual CMS Bitte beachten Sie:

Mehr

Babelprojekt.com Datenschutzhinweise

Babelprojekt.com Datenschutzhinweise Babelprojekt.com Datenschutzhinweise Datenschutzrichtlinie runterladen Letzte Aktualisierung: 24. Apr. 2015 Willkommen zur Webseite des Babelprojekt Kft. Babelprojekt bittet Sie darum, vor der Nutzung

Mehr

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen)

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen) Datenschutzerklärung der Etacs GmbH Die Etacs GmbH wird den Anforderungen des Bundesdatenschutzgesetzes (BDSG) gerecht.personenbezogene Daten, d.h Angaben, mittels derer eine natürliche Person unmittelbar

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Serverumzug mit Win-CASA

Serverumzug mit Win-CASA Serverumzug mit Win-CASA Wenn Sie in Ihrem Netzwerk einen Umzug der Server-Version durchführen müssen, sollten Sie ein paar Punkte beachten, damit dies ohne Probleme abläuft. 1. Nachweis-Ordner In der

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

Mehr

Übertragung von Terminen und Baustellen

Übertragung von Terminen und Baustellen In dieser Dokumentation wird die Anwendung und die Konfiguration der Programme beschrieben, die für die Übertragung der Baustellen und Termine aus der KWP SQL-Datenbank an das virtic-system verwendet werden

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

"getiban.exe" wird als selbstentpackende Archivdatei "getiban.exe" ausgeliefert.

getiban.exe wird als selbstentpackende Archivdatei getiban.exe ausgeliefert. Allgemeine Beschreibung von GETIBAN.EXE "getiban.exe" ist ein Windows Kommandozeilen Programm zur Berechnung von IBANs aus vorhandenen Kontonummern und Bankleitzahlen für die derzeit in SEPA teilnehmenden

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

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

McAfee Security-as-a-Service -

McAfee Security-as-a-Service - Handbuch mit Lösungen zur Fehlerbehebung McAfee Security-as-a-Service - Zur Verwendung mit der epolicy Orchestrator 4.6.0-Software Dieses Handbuch bietet zusätzliche Informationen zur Installation und

Mehr

SiteAudit Knowledge Base. Verwendung von Regeln, Formatvorlagen und Benachrichtigungen. Grundlagen: Benachrichtigungen. In diesem Artikel:

SiteAudit Knowledge Base. Verwendung von Regeln, Formatvorlagen und Benachrichtigungen. Grundlagen: Benachrichtigungen. In diesem Artikel: SiteAudit Knowledge Base Verwendung von Regeln, Formatvorlagen und Benachrichtigungen März 2008 In diesem Artikel: Grundlagen: Benachrichtigungen Beschleunigung, Zeitspannen & Verzögerungen Zusammengefasst:

Mehr

Die wichtigsten Vorteile von SEPPmail auf einen Blick

Die wichtigsten Vorteile von SEPPmail auf einen Blick Die wichtigsten Vorteile von SEPPmail auf einen Blick August 2008 Inhalt Die wichtigsten Vorteile von SEPPmail auf einen Blick... 3 Enhanced WebMail Technologie... 3 Domain Encryption... 5 Queue-less Betrieb...

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis 1. Allgemeines... 2 1.1 Einschalten... 2 1.2 Polter Programm starten... 2 1.3 Info Anzeige... 2 1.4 Haupt Fenster...

Mehr

Information über die Secure E-Mail

Information über die Secure E-Mail Information über die Secure E-Mail Ihre Möglichkeiten Der Austausch von verschlüsselten E-Mails kann auf 3 Arten erfolgen 1. über das Webmail-Portal: Direkt empfangen und senden Sie vertrauliche Informationen

Mehr

Verteilungsmechanismen in verschiedenen RDBMS

Verteilungsmechanismen in verschiedenen RDBMS Verteilungsmechanismen in verschiedenen RDBMS Vorlesung im Wintersemester 2013 (Analyse verschiedener RDBMS-Produkte hinsichtlich angebotener Verteilmechanismen) Prof. Dr. Andreas Schmietendorf 1 Zielstellung

Mehr

Delegierte Benutzerverwaltung (DeBeV) Nutzungshinweise

Delegierte Benutzerverwaltung (DeBeV) Nutzungshinweise Delegierte Benutzerverwaltung (DeBeV) Nutzungshinweise Stand: 17. Februar 2014 Inhalt 1 Einleitung... 3 2 Registrierung neuer Administratoren... 4 2.1 Validierung des Registrierungscodes... 4 2.2 Aktivierung

Mehr

PHOENIX CONTACT Connector Technology zum Thema Datenschutz

PHOENIX CONTACT Connector Technology zum Thema Datenschutz PHOENIX CONTACT Connector Technology zum Thema Datenschutz Wir freuen uns über Ihr Interesse an unserem Unternehmen und unseren Produkten bzw. Dienstleistungen und möchten, dass Sie sich hinsichtlich des

Mehr

VIDA ADMIN KURZANLEITUNG

VIDA ADMIN KURZANLEITUNG INHALT 1 VIDA ADMIN... 3 1.1 Checkliste... 3 1.2 Benutzer hinzufügen... 3 1.3 VIDA All-in-one registrieren... 4 1.4 Abonnement aktivieren und Benutzer und Computer an ein Abonnement knüpfen... 5 1.5 Benutzername

Mehr

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen

Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Von Netop ProtectOn 2 auf Netop ProtectOn Pro umstellen Wenn Sie Benutzer von ProtectOn 2 sind und überlegen, auf ProtectOn Pro upzugraden, sollten Sie dieses Dokument lesen. Wir gehen davon aus, dass

Mehr

Richtlinie zur Nutzung des Remote Access Services

Richtlinie zur Nutzung des Remote Access Services Richtlinie zur Nutzung des Remote Access Services vom 19.9.2011 Als Bestandteil zum Antrag für den Remote Access, werden die Einsatzmöglichkeiten, die Richtlinien und Verantwortlichkeiten für die Zugriffe

Mehr

Checkliste. Integration Saferpay Business. Version 2.3. 110.0083 SIX Payment Services

Checkliste. Integration Saferpay Business. Version 2.3. 110.0083 SIX Payment Services Checkliste Integration Saferpay Business Version 2.3 110.0083 SIX Payment Services Einleitung Vielen Dank, dass Sie sich für Saferpay als E-Payment-Plattform entschieden haben. Dieses Dokument soll Ihnen

Mehr

Leitfaden Registrierung

Leitfaden Registrierung Leitfaden Registrierung zur Nutzung der Ausschreibungsplattform der dualen Systeme www.ausschreibung-erfassung.de Die Anforderung von Ausschreibungsunterlagen Ausschreibungsunterlagen der Ausschreibungsführer

Mehr

Checkliste für die Registrierung für Quantum View Inbound

Checkliste für die Registrierung für Quantum View Inbound Checkliste für die Registrierung für Quantum View Inbound Wenn Sie sich für das Abonnement registrieren lassen, werden Sie zur Eingabe von detaillierten Informationen aufgefordert, die Ihnen möglicherweise

Mehr

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg

Scaling IP Addresses. CCNA 4 version 3.0 Wolfgang Riggert,, FH Flensburg Scaling IP Addresses CCNA 4 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

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland

eadmin Manual Universitätsstraße 3 56070 Koblenz Deutschland DOKUMENT: TYP: ERSTELLT VON: Manual nova ratio AG Universitätsstraße 3 56070 Koblenz Deutschland VERSION: STAND: 9.x 23. September 2015 Inhaltsverzeichnis 1 2 2.1 2.2 2.3 3 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4

Mehr

VHDL Verhaltensmodellierung

VHDL Verhaltensmodellierung VHDL Verhaltensmodellierung Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2008/2009 VHDL Verhaltensmodellierung 1/26 2008-10-20

Mehr

Rail Mall 4.0 Kundendokumentation Siemens AG 2014 Alle Rechte vorbehalten. Answers for infrastructure and cities.

Rail Mall 4.0 Kundendokumentation Siemens AG 2014 Alle Rechte vorbehalten. Answers for infrastructure and cities. Ersatzteilbestellung und Preisauskunft Rail Mall 4.0 Kundendokumentation Answers for infrastructure and cities. Rail Mall 4.0 - Überblick Per Mausklick zum Ersatzteil rund um die Uhr seit über zehn Jahren!

Mehr

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2 Jörg Kapelle 15:19:08 Filterregeln Inhaltsverzeichnis Filterregeln... 1 Einführung... 1 Migration der bestehenden Filterregeln...1 Alle eingehenden Nachrichten weiterleiten...2 Abwesenheitsbenachrichtigung...2

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0

Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014. Gültig für Release 1.0.0.0 Version 1.0 Erstellt am 12.12.2014 Zuletzt geändert am 17.12.2014 Gültig für Release 1.0.0.0 Inhalt 1 WebPart Site Informationen 3 1.1 Funktionalität 3 1.2 Bereitstellung und Konfiguration 4 2 WebPart

Mehr

Benutzeranleitung Superadmin Tool

Benutzeranleitung Superadmin Tool Benutzeranleitung Inhalt 1 Einleitung & Voraussetzungen... 2 2 Aufruf des... 3 3 Konto für neuen Benutzer erstellen... 3 4 Services einem Konto hinzufügen... 5 5 Benutzer über neues Konto informieren...

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

17.2 MS-Access Projekte

17.2 MS-Access Projekte 964 Von MS-Access 2000 zum SQL-Server 17.2 MS-Access Projekte MS-Access-Projekte, die die Dateiendung adp besitzen, werden als Front-End-Anwendung verwendet. Für die Back-End-Seite gibt es mehrere Möglichkeiten.

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

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Stubbe-CS. Kurssystem. Günter Stubbe. Datum: 19. August 2013

Stubbe-CS. Kurssystem. Günter Stubbe. Datum: 19. August 2013 Kurssystem Günter Stubbe Datum: 19. August 2013 Aktualisiert: 6. September 2013 Inhaltsverzeichnis 1 Einleitung 5 2 Benutzer 7 2.1 Registrierung............................. 7 2.2 Login..................................

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

9 Verteilte Verklemmungserkennung

9 Verteilte Verklemmungserkennung 9 Verteilte Verklemmungserkennung 9.1 Grundlagen Für die Existenz einer Verklemmung notwendige Bedingungen Exklusive Betriebsmittelbelegung Betriebsmittel können nachgefordert werden Betriebsmittel können

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

KOGIS Checkservice Benutzerhandbuch

KOGIS Checkservice Benutzerhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 KOGIS Checkservice Benutzerhandbuch Zusammenfassung Diese Dokumentation beschreibt die Bedienung des KOGIS Checkservice. 4.2.2015

Mehr

Scalera Mailplattform Dokumentation für den Domänenadministrator

Scalera Mailplattform Dokumentation für den Domänenadministrator Scalera Mailplattform Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht werden. Kontakt Everyware

Mehr

Einleitung: Frontend Backend

Einleitung: Frontend Backend Die Internetseite des LSW Deutschland e.v. hat ein neues Gesicht bekommen. Ab dem 01.01.2012 ist sie in Form eines Content Management Systems (CMS) im Netz. Einleitung: Die Grundlage für die Neuprogrammierung

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Kundenleitfaden zur Sicheren E-Mail per WebMail

Kundenleitfaden zur Sicheren E-Mail per WebMail Allgemeines Die E-Mail gehört heute für nahezu jeden von uns zu einem häufig verwendeten digitalen Kommunikationsmittel. Trotz des täglichen Gebrauchs tritt das Thema Sicherheit bei der Übermittlung von

Mehr

Das Studiengangsinformationssystem (SGIS)

Das Studiengangsinformationssystem (SGIS) Das Studiengangsinformationssystem (SGIS) Manual für Typo3-Redakteure Version 1.a Mai 2015 Kontakt: Referat 1.4 - Allgemeine Studienberatung und Career Service Christian Birringer, christian.birringer@uni-rostock.de

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

DirectSmile CrossMedia und Salesforce

DirectSmile CrossMedia und Salesforce DirectSmile DirectSmile CrossMedia und Salesforce Anleitung 2014 Salesforce und DirectSmile Cross Media Salesforce und DirectSmile Cross Media... 2 1.1 Einführung... 3 1.2 Ein Benutzerkonto einrichten...

Mehr

Benutzerhandbuch für ZKB WebMail. Für Kunden, Partner und Lieferanten Oktober 2013, V1.1

Benutzerhandbuch für ZKB WebMail. Für Kunden, Partner und Lieferanten Oktober 2013, V1.1 Benutzerhandbuch für ZKB WebMail Für Kunden, Partner und Lieferanten Oktober 2013, V1.1 Inhaltsverzeichnis 1 Beschreibung 3 1.1 Definition 3 1.2 Sicherheit 3 2 Funktionen 3 2.1 Registrierung (erstes Login)

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

KEEPASS PLUGIN - BENUTZERHANDBUCH

KEEPASS PLUGIN - BENUTZERHANDBUCH Zentrum für sichere Informationstechnologie Austria Secure Information Technology Center Austria A-1030 Wien, Seidlgasse 22 / 9 Tel.: (+43 1) 503 19 63 0 Fax: (+43 1) 503 19 63 66 A-8010 Graz, Inffeldgasse

Mehr

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01

OPC-Server VM OPC. Anleitung. Installation, Konfiguration, Verwendung. Version 1.01 Installation, Konfiguration, Verwendung Version 1.01 Seite 2 von 20 OPC-Server VM OPC Revision Version Erstellt am Versionsnummer Bemerkung 1.00 26.07.2013 Erstellung 1.01 05.11.2013 2.14 - Reiter der

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken

Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken Einleitungsvortrag zur Diplomarbeit: Entwurf und simulative Bewertung eines Verfahrens zur Behandlung von Engpässen in Bandwidth-Broker-gesteuerten DiffServ- Netzwerken --- Bernd Wollersheim --- --- wollersh@informatik.uni-bonn.de

Mehr

Nutzerbeirat 2012 Bonn 20.11.2012

Nutzerbeirat 2012 Bonn 20.11.2012 Der neue Personalausweis Einsatzmöglichkeiten in der Lucom Interaction Platform Nutzerbeirat 2012 Bonn 20.11.2012 Henning Meinhardt Leiter Software Entwicklung Ab Version 3.2.2 unterstützt die LIP den

Mehr

Häufig gestellte Fragen Erfahren Sie mehr über Verified by Visa

Häufig gestellte Fragen Erfahren Sie mehr über Verified by Visa Informationen zu Verified by Visa 2 1. Was ist Verified by Visa? 2 2. Wie funktioniert Verified by Visa? 2 3. Wie schützt mich Verified by Visa? 2 4. Ist der Umgang mit Verified by Visa benutzerfreundlich?

Mehr

Websense Secure Messaging Benutzerhilfe

Websense Secure Messaging Benutzerhilfe Websense Secure Messaging Benutzerhilfe Willkommen bei Websense Secure Messaging, einem Tool, das ein sicheres Portal für die Übertragung und Anzeige vertraulicher, persönlicher Daten in E-Mails bietet.

Mehr

GRAFIK WEB PREPRESS www.studio1.ch

GRAFIK WEB PREPRESS www.studio1.ch Datum 11.07.2012 Version (Dokumentation) 1.0 Version (Extedit) 1.0 Dokumentation Kontakt Externe Verwaltung Firmen- & Vereinsverwaltung Studio ONE AG - 6017 Ruswil E-Mail agentur@studio1.ch Telefon 041

Mehr

368 4 Algorithmen und Datenstrukturen

368 4 Algorithmen und Datenstrukturen Kap04.fm Seite 368 Dienstag, 7. September 2010 1:51 13 368 4 Algorithmen und Datenstrukturen Java-Klassen Die ist die Klasse Object, ein Pfeil von Klasse A nach Klasse B bedeutet Bextends A, d.h. B ist

Mehr

Technische Produktinformation: Active Directory- Management in bi-cube

Technische Produktinformation: Active Directory- Management in bi-cube Inhalt: 1 bi-cube -FEATURES ACTIVE DIRECTORY... 2 2 DAS SYSTEMKONZEPT... 3 3 WAS SIND ADOC UND ECDOC?... 3 4 DIE WICHTIGSTEN FUNKTIONEN IM ÜBERBLICK... 5 4.1 Verwaltung der Strukturdaten... 5 4.2 Verwaltung

Mehr