Erweiterung eines CORBA-basierten Event-Management-Dienstes zur Realisierung eines Unified-Messaging-Systems
|
|
- Margarethe Möller
- vor 2 Jahren
- Abrufe
Transkript
1 Fachhochschule Wiesbaden Fachbereich Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplominformatiker (FH) Erweiterung eines CORBA-basierten Event-Management-Dienstes zur Realisierung eines Unified-Messaging-Systems vorgelegt von Frank Köhler am 27. August 2001 Referent: Prof. Dr. R. Kröger Korreferent: Prof. Dr. K.-O. Linn
2
3 Erklärung Hiermit erkläre ich an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel und Literaturquellen verfaßt habe. Taunusstein, Frank Köhler Hiermit erkläre ich mein Einverständnis mit den im folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit: Verbreitungsform ja nein Einstellung der Arbeit in die Bibliothek der FHW Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Taunusstein, Frank Köhler
4
5 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Ereignisbasierte Kommunikation Kommunikationsmodell CORBA Event Service Ereigniskanäle Ereignistypen CORBA Notification Service Strukturierte Ereignisse Ereignisfilterung Quality-of-Service-Unterstützung Persistenz Event Management Service des Labors für verteilte Systeme der FH Wiesbaden Ereigniskommunikation Ereignisfilterung Quality-of-Service-Unterstützung Service Monitoring Vorstellung weiterer Kommunikationsmodelle Java Distributed Event Model Das Cambridge Event Model ECO
6 iv Inhaltsverzeichnis JEDI SIENA Unified Messaging Systeme Einleitung Architektur Eigenschaften Medienanbindung Medienkonvertierung Filterung Profilmanagement Sicherheit Persistenz Skalierbarkeit Fehlertoleranz Anwendungsbeispiel Konzept Analyse Anforderungen an das Unified Messaging System Leistungsumfang des Event Management Service Erweiterung des Event Management Service Zusammenfassung Designentscheidungen Zustellgarantie Anbindung von Unified Messaging Sendern und Empfängern Speicherung empfangener Nachrichten Nachrichtenkonvertierung Repositories Entwurf Systemarchitektur
7 Inhaltsverzeichnis v Extended Event Management Service Gateways Konverter Repositories und Resource Management Verbindungspersistenz Neustart und Wiederherstellung der Konfiguration des EMS Objektreferenzen Datenbanktabellen Ereignispersistenz Ereignisformat Ereignistransport Performance-Betrachtungen Datenbanktabellen Neustart des EMS und Wiederherstellung von Ereignisnachrichten Unified Messaging Komponenten Gateways Konverter Repositories Implementierung Implementierungsumgebung Systemplattformen, Compiler und Werkzeuge CORBA-Plattform und Datenbanksystem Der Extended Event Management Service Einführung einer Datenbank-Klasse zur Realisierung der Persistenzeigenschaften Methoden zum Anlegen, Öffnen und Schließen der Datenbank Methoden zum Hinzufügen neuer Datensätze Methoden zum Aktualisieren von Datensätzen
8 vi Inhaltsverzeichnis Methoden zum Lesen von Datensätzen Methoden zum Löschen von Datensätzen Rückgabewerte Verbindungspersistenz Änderungen zur Gewährleistung persistenter Objektreferenzen Änderungen an der Klasse EventChannelFactory Änderungen an der Klasse EventChannel Änderungen an den Klassen SupplierAdmin und ConsumerAdmin Änderungen an den Klassen vom Typ ProxySupplier und ProxyConsumer Änderungen an den Klasse ForwardingFilter und Mapping- Filter Änderungen an der Klasse FilterSlot Änderungen am Hauptprogramm Ereignispersistenz Änderungen an der Klasse EventRec Änderungen an der Klasse EventChannelFactory Änderungen an den Klassen vom Typ ProxyConsumer und ProxySupplier Änderungen am Hauptprogramm Ereigniswiederherstellung Implementierung der Unified Messaging Schicht Gateways Konverter Repositories und Resource Management Performance-Messungen Meßumgebung Ereignistypen Durchsatzmessung
9 Inhaltsverzeichnis vii Bewertung Implementierungsaufwand Extended Event Management Service Unified Messaging Schicht Zusammenfassung Literaturverzeichnis 105 A Berkeley DB Datenbankbibliothek 107 B Die Klasse EMSDatabase 113 C Vollständige Tabellen der Messergebnisse 123
10 viii Inhaltsverzeichnis
11 Abbildungsverzeichnis 2.1 Vergleich von Client/Server und ereignisbasierter Kommunikation Modelle für die ereignisbasierte Kommunikation CORBA Event Channel Architektur CORBA Notification Channel Architektur Aufbau eines strukturierten Ereignisses Architektur des EMS Architektur eines Unified Messaging System Unified Messaging System mit Store and Forward Queue CANBOX Unified Messaging Systemarchitektur Anbindung der Unified Messaging Konverter an den Event Management Service Event Management Service UMS Architektur Entity Relationship Modell der EMS-Objektabhängigkeiten EMS Ereignistransport Ein- und Ausgabeformate des Unified Messaging Systmes Beispiel einer SMTP Verbindung aus Sicht des SMTP Clients EMS Datenbankarchitektur Objekt- und Verbindungswiederherstellung Unified Messaging Converter Architektur UMS Resource Management A.1 Vereinfachte Architektur der Berkeley DB Datenbankbibliothek A.2 Architektur der Berkeley DB Transactional Data Store Datenbankbibliothek 110
12 x Abbildungsverzeichnis
13 Tabellenverzeichnis 2.1 CORBA Notification Service Dienstgüteparameter EMS Constraint-Sprache Attribute für die Datentabelle Event Channel Attribute für die Datentabelle Admin Objects Attribute für die Datentabelle Proxy Objects Attribute für die Datentabelle Filter Objects Attribute für die Datentabelle Filter Mapping Attribute für die Datentabelle Filter Constraints/Rules Übersicht der Ein- bzw. Ausgabeformate des Unified Messaging Systems Attribute für die Datentabelle User Profiles Attribute für die Datentabelle Abonnement Profiles Verwendete generische Ereignisse Verwendete strukturierte Ereignisse generische Ereignisse Messreihe 1: Ereignispersistenz deaktiviert generische Ereignisse Messreihe 2: Ereignispersistenz aktiviert strukturierte Ereignisse Messreihe 1: Ereignispersistenz deaktiviert strukturierte Ereignisse Messreihe 2: Ereignispersistenz aktiviert Implementierungsaufwand - Extended Event Management Service Implementierungsaufwand - Extended Event Management Service C.1 generische Ereignisse Messreihe 1: Ereignispersistenz deaktiviert C.2 generische Ereignisse Messreihe 2: Ereignispersistenz aktiviert C.3 strukturierte Ereignisse Messreihe 1: Ereignispersistenz deaktiviert C.4 strukturierte Ereignisse Messreihe 2: Ereignispersistenz aktiviert
14 xii Tabellenverzeichnis
15 Listings 4.1 Klasse EMSDatabase: Anlegen, Öffnen und Schließen der Datenbank Klasse EMSDatabase: Hinzufügen neuer Datensätze Klasse EMSDatabase: Aktualisieren von Datensätzen Klasse EMSDatabase: Lesen von Datensätzen Klasse EMSDatabase: Löschen von Datensätzen Ausschnitt aus dem Programm EMSServer.cc Ausschnitt aus der Klasse EventChannel Ausschnitt aus der Klasse EventChannelFactory - Channel-Wiederherstellung Ausschnitt aus der Klasse EventChannelFactory - Filter-Wiederherstellung Ausschnitt aus der Klasse EventChannel - Löschen eines Ereigniskanals Ausschnitt aus der Klasse SupplierAdmin - Einfügen eines Admins Ausschnitt aus der Klasse SupplierAdmin - Löschen eines Admins Ausschnitt aus der Klasse SupplierAdmin - Wiederherstellen von Proxy- Objekten Ausschnitt aus der Klasse ProxyPullSupplier - Verbinden eines Consumers Ausschnitt aus der Klasse ForwardingFilter - Constraint löschen Ausschnitt aus der Klasse FilterSlot - Filter löschen Ausschnitt aus der Klasse FilterSlot - Filter wiederherstellen Ausschnitt aus der Klasse EventRec Ausschnitt aus der Klasse EventChannelFactory - globale Optionen Ausschnitte aus den ProxyConsumer Klassen - Ereignisempfang Ausschnitte aus den ProxySupplier Klassen - Ereigniszustellung Ausschnitt aus der Klasse StructuredProxyPushConsumer - Ereigniswiederherstellung
16 xiv Listings 4.23 Versand einer Ereignisnachricht Empfang einer Ereignisnachricht im Konverter Konvertierung einer Ereignisnachricht IDL-Beschreibung der Resource Management Komponente B.1 EMSDatabase - Datenbank Anlegen, Öffnen oder Schließen B.2 EMSDatabase - Datensätze hinzufügen B.3 EMSDatabase - Datensätze aktualisieren B.4 EMSDatabase - Datensätze lesen B.5 EMSDatabase - Datensätze löschen
17 Kapitel 1 Einleitung Die wachsende Konvergenz zwischen Telefonnetzen, Datennetzen und mobilen Netzen führt zu der zentralen Vision, Informationen zu jeder Zeit, an jedem Ort und in beliebiger Form empfangen zu können. Diese Vision bildet die Grundlage für eines der größten Anwendungsgebiete der Informatik. Seit einigen Jahren beschäftigen sich Forschungs- und Entwicklungseinrichtungen mit dem Problem der nahtlosen Integration einzelner Kommunikationssysteme in eine vom Trägermedium abstrahierten Kommunikationsumgebung für mobile Benutzer. Ein Teilbereich dieser Forschungsaktivitäten wird heute unter dem Begriff Unified Messaging zusammengefaßt. Ein Unified Messaging System (UMS) soll die Produktivität eines Benutzers dadurch steigern, daß die bisherige, in der Regel aus verschiedenen Applikationen bestehende Infrastruktur des Benutzers durch eine Kommunikationsumgebung ersetzt wird, die alle Nachrichtentypen empfängt und diese an einem logisch zentralen Ort zur Verfügung hält. Eine solche, in der Regel auf Internet-Protokollen basierende Umgebung soll es dem Benutzer ermöglichen, unabhängig von seinem Aufenthaltsort und dem gerade zur Verfügung stehenden Kommunikations-Endgerät auf seine Nachrichten zugreifen zu können. Hierbei kann es sich zum Beispiel um eine Web-Applikation, ein Telefon, ein Faxgerät oder einen PDA (Personal Digital Assistant) handeln. Eine notwendige Voraussetzung für die Integration verschiedener Kommunikationssysteme ist die Modularität in Hinblick auf Austauschbarkeit und Erweiterbarkeit von Komponenten, d.h. die Vereinheitlichung von Interfaces auf verschiedenen Ebenen (extern und intern). Hierfür wird eine Integrationsplattform benötigt, die möglichst skalierbar ist und sowohl eine Implementierung des Systems auf einem einzelnen Rechner als auch auf einem verteilten System mit unterschiedlichen Betriebssystemplattformen ermöglicht. Eine solche, auf der Basis verteilter Objekttechnologien basierende Integrationsplattform ist die Common Object Request Broker Architecture (CORBA) der Objekt Management Group (OMG).
18 2 Einleitung Ein wesentlicher Aspekt einer solchen Integrationsplattform sind die zugrundeliegenden Kommunikationsprinzipien, die nach verschiedenen Eigenschaften klassifiziert werden können. Ein Klassifikationsmerkmal ist zum Beispiel die Unterscheidung zwischen Punktzu-Punkt-Kommunikation und Gruppenkommunikation. Neben der im CORBA-Standard definierten synchronen Punkt-zu-Punkt-Kommunikation wird für die Realisierung eines Unified Messaging Systems eine asynchrone Gruppenkommunikation benötigt. Im Rahmen der Common Object Services Specification (COSS) wurde hierfür der standardisierte CORBA Event Service entworfen. Dieser enthält bereits die grundlegenden Konzepte und Schnittstellen zur ereignisbasierten asynchronen Kommunikation zwischen Mengen anonymer Erzeuger und Konsumenten in verteilten Systemen. Auf den Schnittstellen des COR- BA Event Service wurde später der CORBA Notification Service aufgebaut. Dieser stellt eine Erweiterung des CORBA Event Service um Merkmale wie strukturierte Ereignisse, Ereignisfilterung und Quality-of-Service-Unterstützung dar. Im Labor für Verteilte Systeme der FH Wiesbaden wurde im Rahmen der Diplomarbeit [Bro98] von Erik Broßler ein Event Management Service (EMS) entwickelt, der ebenfalls auf den Schnittstellen des CORBA Event Service aufsetzt und als Ereignisform generische Ereignisnachrichten unterstützt. Unter Berücksichtigung der damals existierenden Entwürfe für den CORBA Notification Service wurde die Funktionalität gegenüber dem CORBA Event Service entscheidend erweitert. Neben der Einführung von Prioritäten und Lebenszeiten wurden auch die Konzepte zur Filterung von Ereignissen übernommen. Durch die gemeinsame Nutzung von Filterpunkten an Administrationsobjekten, die eine Gruppierung der Erzeuger und Konsumenten erlauben, wurde die interne Struktur des Dienstes optimiert. Im Rahmen der Diplomarbeit [Mac00] von Holger Machens wurde ein Redesign des Event Management Service zur Anpassung an die Bedürfnisse einer Automatisierungsumgebung durchgeführt. Um eine möglichst schnelle Nachrichtenvermittlung zu gewährleisten, wurde der Dienst zusätzlich um die im CORBA Notification Service spezifizierten strukturierten Ereignisse erweitert. Das primäre Ziel dieser Diplomarbeit ist die Erweiterung des im Labor für Verteilte Systeme der FH Wiesbaden entwickelten Event Management Service zur Realisierung eines Unified Messaging Systems. Die durch die Architektur eines Unified Messaging Systems gestellten Anforderungen an den Event Management Service werden hierbei im Vordergrund stehen. Eine Kernforderung in diesem Zusammenhang ist die Gewährleistung von Zustellgarantien für zu empfangende Ereignisnachrichten, da diese für die Realisierung eines solchen Systems von essentieller Bedeutung sind. Ausgehend von dieser Forderung wurden dazu im CORBA Notification Service die Eigenschaften der Verbindungspersistenz und der Ereignispersistenz spezifiziert. Der grundlegende Ansatz dieser Arbeit besteht darin, eine zweischichtige Systemarchitektur für die Realisierung des Unified Messaging Systems auf der Basis des Event Management Service vorzusehen.
19 3 Das funktionale Ziel der unteren Schicht ist ein erweiterter Event Management Service (Extended Event Management Service, EEMS), der den existierenden EMS um die Eigenschaften der Verbindungs- und Ereignispersistenz ergänzt. Nach einer Analyse des Leistungsumfangs der aktuellen Version des Event Management Service in Hinblick auf die Realisierung eines Unified Messagig Systems werden die Anforderungen für die Gewährleistung von Zustellgarantien betrachtet. In diesem Zusammenhang werden insbesondere die entsprechenden Spezifikationen des CORBA Notification Service untersucht, um die CORBA-Kompatibilität auch bei Erweiterung des Dienstes zu erhalten. Anschließend werden verschiedene Verfahren zur persistenten Datensicherung vorgestellt und diskutiert. Aus den gewonnenen Ergebnissen wird die Architektur des Extended Event Management Service (EEMS) entworfen und implementiert. Dieser bildet die Grundlage für das zu entwickelnde Unified Messaging System. Daran anschließend erfolgt in einem zweiten Schritt die Realisierung des Unified Messaging Systems auf der Basis des Extended Event Management Service. Dazu erfolgt die exemplarische Entwicklung relevanter Komponenten eines Unified Messaging Systems. Hierbei handelt es sich beispielsweise um Gateways für den Nachrichtenempfang bzw. Nachrichtenversand und Module für die Konvertierung der verschiedenen Nachrichtenformate. Alle diese Komponenten werden in Form von Konsumenten bzw. Erzeugern des Extended Event Management Service entwickelt. Zusätzlich werden die Unified Messaging Gateways mit einer Schnittstelle zu einer Resource Management Komponente versehen. Diese Schnittstelle ermöglicht eine Abfrage von benutzerspezifischen Daten (wie zum Beispiel Adressen des Unified Messaging Benutzers). Die Konsumenten bzw. Erzeuger, die innerhalb des Systems als Gateway oder Konverter dienen, werden ebenfalls um die bereits beschriebenen Persistenzeigenschaften erweitert. Nach dieser Einführung beschreibt Kapitel 2 die für das Verständnis der Arbeit notwendigen Grundlagen. Abschnitt gibt zunächst eine Einführung in die klassischen Kommunikationsmodelle verteilter Anwendungen. Dabei werden insbesondere die Unterschiede der klassischen Client/Server-Kommunikation und der ereignisbasierten Kommunikation betrachtet. Abschnitt befaßt sich mit dem CORBA Event Service, der die COR- BA Architektur um Schnittstellen zur ereignisbasierten asynchronen Kommunikation erweitert. Eine Vorstellung des CORBA Notification Service mit seinen Eigenschaften der Verbindunspersistenz und Ereignispersistenz erfolgt in Abschnitt In Abschnitt wird die aktuelle Version des Event Management Service des Labors für Verteilte System der FH-Wiesbaden beschrieben. Abgeschlossen wird das Kapitel 2 mit einer kurzen Betrachtung weiterer Kommunikationsmodelle. In Kapitel 3 werden die im Rahmen dieser Arbeit entwickelten Konzepte für die Erweiterung des Event Management Service und deren Integration in eine Unified Messaging Architektur dargestellt. Abschnitt 3.1 faßt zunächst die Anforderungen an ein Unified Messaging System und die daraus resultierenden Anforderungen für die Modifikation und
20 4 Einleitung Erweiterung des Event Management Service zusammen. In Abschnitt 3.2 werden verschiedene Entwurfsalternativen diskutiert. Die konkrete Architektur des Unified Messaging Systems und die Realisierung der Verbindungspersistenz und Ereignispersistenz wird in Abschnitt 3.3 vorgestellt. Die Umsetzung des Konzepts wird in Kapitel 4 besprochen. Abschnitt 4.1 beschreibt zunächst die Implementierungsumgebung. Die zwei folgenden Abschnitte befassen sich mit den konkreten Implementierungsdetails. In diesen Abschnitten werden die Modifikationen für die Erweiterung des Event Management Service um die Eigenschaften der Verbindungspersistenz bzw. Ereignispersistenz und die Implementation der Unified Messaging Komponenten vorgestellt. Die im Rahmen der Diplomarbeit erreichten Ergebnisse werden in Kapitel 5 zusammengefaßt und bewertet. Darüber hinaus werden Empfehlungen für Verbesserungen und Erweiterungen des Event Management Service aufgezeigt.
21 Kapitel 2 Grundlagen Das Kapitel Grundlagen soll die Konzepte und Techniken vermitteln, die für das Verständnis dieser Arbeit notwendig sind. Im ersten Abschnitt erfolgt eine Einführung in die Grundlagen der ereignisbasierten Kommunikation. In diesem Zusammenhang werden der CORBA Event Service und der CORBA Notification Service näher erläutert. Abschließend erfolgt eine Einführung in die Architektur des Event Management Dienstes des Labors für Verteilte Systeme der FH Wiesbaden. Der zweite Abschnitt gibt einen Einblick in die Architektur eines Unified Messaging Systems und betrachtet die für den Betrieb notwendigen Eigenschaften. 2.1 Ereignisbasierte Kommunikation Kommunikationsmodell Das klassische Kommunikationsmodell in verteilten Anwendungen basiert auf der, in Abbildung 2.1 dargestellten, Client/Server-Architektur. In diesem Modell wird innerhalb eines Servers ein Dienst bereitgestellt, der von einem oder mehreren Clients über ein zuvor definiertes Interface aufgerufen werden kann. Die Kommunikation zwischen Client und Server erfolgt in der Regel über eine synchrone Punkt-zu-Punkt Verbindung. Ein Beispiel für eine Client/Server-Kommunikation ist ein Abbildung 2.1 dargestellt. Eine Client ruft einen Dienst des Servers auf (Request) und blockiert dann so lange, bis er die Rückgabe der aufgerufenen Funktion erhält (Response). In großen verteilten Systemen stößt dieses Modell schnell an seine Grenzen, da durch den Versand der Empfangsbestätigungen eine nicht unerhebliche Netzlast erzeugt wird. Im Gegensatz zum Client/Server-Modell ermöglicht die ereignisbasierte Kommunikation eine Entkopplung von Aufrufer (Caller) und Aufgerufenem (Callee) und stellt damit ein asynchrones Kommunikationsmodell bereit. In diesem Modell wird für den Aufgerufenen
22 6 Grundlagen Server Event Consumer Event Consumer Event Consumer Request Response Client Client/Server Kommunikation Event Supplier ereignisbasierte Kommunikation Abbildung 2.1: Vergleich von Client/Server und ereignisbasierter Kommunikation die Rolle des Erzeugers (Supplier) und für den Aufrufenden die Rolle des Konsumenten (Consumer) eingeführt. Ein Kommunikationsbeispiel ist in Abbildung 2.1 dargestellt. Der Supplier generiert ein Ereignis und stellt dieses einem einzelnen Konsumenten oder einer Gruppe von Konsumenten zu. Hierbei hat der Supplier in der Regel keine Information über die Postion und die Anzahl der Consumer. Die Zustellung von Ereignissen kann nach den, in Abbildung 2.2 dargestellten Ansätzen erfolgen. Push Supplier push Push Consumer Pull Supplier pull Pull Consumer Push-Modell Pull-Modell Abbildung 2.2: Modelle für die ereignisbasierte Kommunikation 1. Nach dem Push-Modell erfolgt bei Vorliegen eines Ereignisses eine Benachrichtigung vom Supplier zum Consumer. Der Supplier verhält sich in diesem Fall aktiv, der Consumer passiv. 2. Das Pull-Modell sieht ein kontinuierliches Ereignis-Polling des Consumers vor. Der Consumer verhält sich in diesem Fall aktiv, der Supplier passiv. Durch die Definition unterschiedlicher Interfaces für jede Kombination von Kommunikationsmodell und Rolle wird eine Verbindung zwischen Supplier und Consumer unterschiedlichen Kommunikationstyps verhindert.
23 2.1 Ereignisbasierte Kommunikation CORBA Event Service Der CORBA Event Service [Obj01] wurde mit dem in Abschnitt beschriebenen Ziel der Entkopplung von Aufrufer und Aufgerufenem entwickelt. Die Kommunikation zwischen dem Supplier und dem Consumer erfolgt über die standardisierten CORBA-Aufrufe Ereigniskanäle Das im Abschnitt vorgestellte Modell erlaubt zwar die Kommunikation zwischen einem Supplier und einem Consumer, es ist aber nicht möglich, ein Ereignis an mehr als einen Consumer zu senden. Zu diesem Zweck wurde das Konzept des Ereigniskanals (Event Channel) eingeführt. Er dient als Bindeglied zwischen einer Anzahl von Erzeugern und Konsumenten und ist somit das zentrale Objekt eines Event Service. Ein Ereigniskanal ermöglicht die anonyme Kommunikation einer beliebigen Anzahl von Erzeugern mit einer beliebegen Anzahl von Konsumenten. Hierzu werden die Meldungen von den Erzeugern in den Ereigniskanal eingespeist und von den Konsumenten auf der entgegengesetzten Seite entnommen. Consumer Side Supplier Side Event Consumer Proxy Supplier Consumer Admin Event Channel Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Abbildung 2.3: CORBA Event Channel Architektur Die Event Channel Architektur ist in Abbildung 2.3 dargestellt. Jeder Ereigniskanal enthält zwei Administrationsobjekte (Consumer Admin und Supplier Admin), die zur Generierung und Installation der Proxy-Objekte für Erzeuger und Konsumenten benötigt werden. Diese Proxy-Objekte werden benötigt, um den Kommunikationspartnern die gewohnte Schnittstelle zum Versand und Empfang von Ereignissen bereitzustellen. Die Kommunikation mit den Proxy-Objekten kann sowohl über das Pull-Modell, als auch über das Push-Modell erfolgen. Auf Empfängerseite übernehmen die Objekte ProxyPushSupplier und ProxyPullSupplier die aktive bzw. passive Zustellung von Ereignissen. Die Aufgabe des aktiven bzw. passiven Konsumenten auf Empfängerseite übernehmen die Objekte ProxyPullConsumer und ProxyPushConsumer.
24 8 Grundlagen Für die Kommunikation über einen Ereigniskanal muß keine Festlegung auf ein bestimmtes Modell erfolgen, da auch Mischformen unterstützt werden. Beispielsweise kann die von einem ProxyPullConsumer empfangene Ereignismeldung auch einem ProxyPushSupplier zugestellt werden, der seinerseits die Meldung an den Push Consumer weitergibt Ereignistypen Mit dem Event Service wurden zwei verschiedene Ereignistypen eingeführt: 1. Generic Events können eine beliebige Datenstruktur vom Datentyp Any enhalten. 2. Typed Events stellen ein zuvor definiertes Interface bereit. Dieses Interface kann mittels der IDL beschrieben werden. Bei der Definition der Schnittstelle gelten die gleichen Einschränkungen wie bei CORBA Oneway-Calls. Zusätzlich müssen die mittels der IDL beschriebenen Interfaces je nach Rolle und Kommmunikationsmodell über eine Methode verfügen, die nach der Push- oder Pull-Semantik arbeitet. Wird ein Ereigniskanal vom Typ Generic angelegt, so können durch diesen nur Ereignisse des gleichen Typs versendet werden. Ein Ereigniskanal vom Typ Typed unterstützt die Ereignisarten Generic und Typed CORBA Notification Service Der CORBA Notification Service [Obj00] wurde auf der Schnittstelle des CORBA Event Service aufgebaut und ergänzt diesen um Merkmale wie strukturierte Ereignisse, Ereignisfilterung und Quality-of-Service-Unterstützung. Die Architektur des Notification Channels ist in Abbildung 2.4 dargestellt. Wie aus Abbildung 2.4 ersichtlich, wurden die im Event Service existierenden Beschränkungen bezüglich der Anzahl der Administrationsobjekte aufgehoben Strukturierte Ereignisse Mit dem CORBA Notification Service wurden die sogenannten strukturierten Ereignisse eingeführt. Gegenüber den vom CORBA Event Service bekannten Typed Events zeichnen sich diese durch eine vereinfachte Handhabung aus. Strukturierte Ereignisse ermöglichen die direkte Abbildung von Ereignissen auf eine zuvor definierte Datenstruktur. Durch neu eingeführte Supplier und Consumer Interfaces ist es nicht mehr notwendig, die Daten in einem Any-Datentyp zu kapseln. Strukturierte Ereignisse können dadurch direkt an den oder die Konsumenten zugestellt werden.
25 2.1 Ereignisbasierte Kommunikation 9 Consumer Side Supplier Side Event Consumer Proxy Supplier Consumer Admin Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Notification Channel Proxy Consumer Event Supplier Event Consumer Proxy Supplier Consumer Admin Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Proxy Consumer Event Supplier Abbildung 2.4: CORBA Notification Channel Architektur domain_name type_name Fixed Header Event Header ohf_name ohf_name ohf_name event_name 1 2 n... ohf_value ohf_value ohf_value 1 2 n Variable Header fd_name 1 fd_value 1 Event Body fd_name 2... fd_value 2 Filterable Body Fields fd_name n fd_value n remainder_of_body Remaining Body Abbildung 2.5: Aufbau eines strukturierten Ereignisses
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
Event und Notification Service in CORBA
Event und Notification Service in CORBA Marcus Denker Zusammenfassung Mittels CORBA können verteilte Applikationen einfach über ein Netzwerk miteinander kommunizieren. Doch das von CORBA zur Verfügung
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
CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten
CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard
inews: XML in der Praxis Konvertierung von Objekten nach XML und zurück Dr. St. Seefeld / INGTES AG
inews: XML in der Praxis Konvertierung von Objekten nach XML und zurück Dr. St. Seefeld / INGTES AG Objekte und XML Bei der Arbeit mit objektorientierten Programmiersprachen und XML kommt schnell der Wunsch
SMTP-Verfahren POP-Verfahren IMAP-Verfahren
IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten
COPPER Best Practices
COPPER Best Practices Version 1.0.1 Wann sollte man überhaupt COPPER verwenden? Allgemein genau dann, wenn man von der COPPER Notation oder den COPPER-Features profitieren kann. Ein wesentliches Feature
Szenario 3: Service mit erweiterter Schnittstelle
2. Hintergrundverarbeitung in Android: Services und Notifications Szenarien für lokale Services Szenario 3: Service mit erweiterter Schnittstelle Ein Service bietet zusätzliche Methoden an, über die sich
CORBA. Systemprogrammierung WS 2006-2007
CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA
Übungen zu Softwaretechnik
Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte
Web Interface für Administratoren (postmaster):
Ing. G. Michel Seite 1/9 Web Interface für Administratoren (postmaster): 1) Grundlagen: - Der Administrator für e-mail wird auch Postmaster genannt. - Sie benötigen die Zugangsdaten zu Ihrem Interface,
CARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH
CARM-Server Version 4.65 Users Guide APIS Informationstechnologien GmbH Einleitung... 1 Zugriff mit APIS IQ-Software... 1 Zugang konfigurieren... 1 Das CARM-Server-Menü... 1 Administration... 1 Remote-Konfiguration...
Java 2, Enterprise Edition Einführung und Überblick
Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte
Der Einsatz von CORBA in verteilten EDA-Tools
Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme
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
10 Nachrichtenorientierte Middleware. vs10 1
10 Nachrichtenorientierte Middleware vs10 1 10.1 Nachrichten- und Ereignisdienste Motivation:? Defizite objektorientierter verteilter Systeme? Anderer Architekturstil sinnvoll für manche Anwendungen, z.b.
3.2 Der CORBA-Standard Common Object Request Broker Architecture
3.2 Der CORBA-Standard Common Object Request Broker Architecture (Bildquelle: OMG) Kapitel 3.2: Vorlesung CORBA 1 CORBA Middleware im Ueberblick G CORBA = Common Object Request Broker Architecture. Standard
Softwarepraktikum - Verteidigung Entwurf LDAP-Interfaces für majordomo und Web
Softwarepraktikum - Verteidigung Entwurf LDAP-Interfaces für majordomo und Web Michael Weiser, Steffen Wolf, 99IN 22. Mai 200 WEB-INTERFACE 2 Web-Interface. Softwareschnittstellen Webserver in Entwicklung
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
ObjectBridge Java Edition
ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente
Erweiterung für Premium Auszeichnung
Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter
Multiuser Client/Server Systeme
Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle
Java und XML 2. Java und XML
Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003
Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen
Java Beans Enterprise Java Beans Eine kurze Einführung in die Welt der Bohnen Java Beans Einführung Stefan Sauer Was ist ein Java Bean? Beans sind Komponenten. Einmal schreiben Überall wiederverwerten
Diese Information ist gültig für Thermoguard ab Version 2.65 (freigegeben 11. April 2010).
Inhalt 1. Kurzanleitung 2. Beispieleinstellungen 2.1 Intranet 2.2 Externer Provider: 1 & 1 2.3 Externer Provider: Google Mail 3. Details 4. Problembehandlung Diese Information ist gültig für ab Version
JMS Java Message Service
JMS Java Message Service TK3 - WS03/04 Dipl.-Ing. Erwin Aitenbichler Abt. Telekooperation TU Darmstadt 1 JMS: Java Message Service Messaging Lose gekoppelte verteilte Kommunikation RMI: Eng gekoppelt Sender
Carl-Engler-Schule Karlsruhe Datenbank 1 (5)
Carl-Engler-Schule Karlsruhe Datenbank 1 (5) Informationen zur Datenbank 1. Definition 1.1 Datenbank-Basis Eine Datenbank-Basis ist eine Sammlung von Informationen über Objekte (z.b Musikstücke, Einwohner,
Objektorientiertes Programmieren für Ingenieure
Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen
i i apitel apitel K K Inhalt Inhalt
Seite iv 0 Einleitung........................................... 1 Kombination der Leistungsbereiche.............. 3 Über dieses Buch.................................. 3 Arbeiten mit den Beispielanwendungen..........
Objektorientierte Analyse und Entwurf
Objektorientierte Analyse und Entwurf Thomas Röfer Funktionale Dekomposition Objektorientierter Ansatz Objekte und Klassen Objektbeziehungen Beispiel Rückblick Datenorganisation und Datenstrukturen Zeichensätze
COM.SPEECH IVR Lösungen von COM.POINT
COM.SPEECH IVR Lösungen von COM.POINT Unsere Sprachportale zeichnen sich durch standardisierte Schnittstellen zu den (internen und externen) Anwendern sowie einen transparenten Zugang in eine Vielzahl
telpho10 Hylafax Server
telpho10 Hylafax Server Version 2.6.1 Stand 02.07.2012 VORWORT... 2 NACHTRÄGLICHE INSTALLATION HYLAFAX SERVER... 3 HYLAFAX ENDGERÄT ANLEGEN... 5 HYLAFAX ENDGERÄT BEARBEITEN... 6 ALLGEMEIN... 6 HYLAFAX
Collax Fax-Server Howto
Collax Fax-Server Howto Dieses Howto beschreibt die Einrichtung eines Fax-Servers für den Faxversand und -empfang. Howto Vorraussetzungen Collax Business Server Collax Groupware Suite Collax Platform Server
Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage
Lösungen zu ---- Informations- und Telekommunikationstechnik Arbeitsheft,. Auflage. HANDLUNGSSCHRITT a) Aufgabe Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP-Adressen), die
Data Mining Standards am Beispiel von PMML. Data Mining Standards am Beispiel von PMML
Data Mining Standards am Beispiel von PMML Allgemeine Definitionen im Data Mining Data Mining (DM) Ein Prozess, um interessante neue Muster, Korrelationen und Trends in großen Datenbeständen zu entdecken,
BS-Anzeigen 3. Handbuch für das Zusatzmodul modazs Import von Anzeigen aus der Anzeigenschleuder
BS-Anzeigen 3 Handbuch für das Zusatzmodul modazs Import von Anzeigen aus der Anzeigenschleuder Inhaltsverzeichnis Anwendungsbereich... 3 Betroffene Softwareversion... 3 Anzeigenschleuder.com... 3 Anmeldung...
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
3 Programmiermodelle für parallele und verteilte Systeme
3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von
7 Der Exchange Server 2010
Der Exchange Server 2010 7 Der Exchange Server 2010 Prüfungsanforderungen von Microsoft: Configuring and Managing Messaging and Collaboration o Configure email. o Manage Microsoft Exchange Server. Managing
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
CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen
Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen
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
Aufgabenstellung und Zielsetzung
Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces
Ersatzteile der Extraklasse Magento-Module der Shopwerft
Ersatzteile der Extraklasse Magento-Module der Shopwerft MicroStudio - Fotolia.com Werden von Kunden oder Suchmaschinen Elemente des Shops aufgerufen, die nicht vorhanden sind, wird statt des gewünschten
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
Enterprise Java Beans Einführung
Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse
Mufid Sulaiman mufidsulaiman@web.de
Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise
Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis
Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Einführung... 2-3 Servereinstellungen für die Einrichtung auf dem E-Mail Client... 4 E-Mail Adresse / Postfach einrichten...
Wiederholung: Beginn
B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben
Dokumentation Authentische Strukturdaten
Dokumentation Version 1.1 Version 1.0 Seite 1/18 31.10.2008 Inhaltsverzeichnis 1. Allgemeines...3 1.1 Phasenmodell...3 1.1.1 Phase I...3 1.1.2 Phase II...3 1.1.3 Phase III...3 1.2 Datenaktualität...3 2.
Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9
Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung
Internet for Guests. Interfaces. 1.0.0 Deutsch. Interfaces Seite 1/14
Internet for Guests Interfaces 1.0.0 Deutsch Interfaces Seite 1/14 Inhalt 1. PMS... 3 1.1 Hinweise... 3 1.2 Konfiguration... 4 1.2.1 VIP/Mitgliedschaft: VIP Gast kostenloser Betrieb... 5 1.2.2 VIP/Mitgliedschaft:
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
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
VPN Tunnel Konfiguration. VPN Tunnel Konfiguration IACBOX.COM. Version 2.0.2 Deutsch 11.02.2015
VPN Tunnel Konfiguration Version 2.0.2 Deutsch 11.02.2015 Dieses HOWTO beschreibt die Konfiguration eines VPN Tunnels zu einem (zentralisierten) OpenVPN Server. VPN Tunnel Konfiguration TITEL Inhaltsverzeichnis
Zeiterfassung-Konnektor Handbuch
Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,
Modul Software Komponenten 10 Komponentenarchitektur
Modul Software Komponenten 10 Komponentenarchitektur Teil 2 Peter Sollberger Die verschiedenen Middleware - Ansätze Inhalt Montag, 3. November Remote Procedure Call (RPC) Fehlersemantiken Remote Message
Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?
Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa
Programmiertechnik Operatoren, Kommentare, Ein-/Ausgabe
Programmiertechnik Operatoren, Kommentare, Ein-/Ausgabe Prof. Dr. Oliver Haase Oliver Haase Hochschule Konstanz 1 Was sind Operatoren? Ein Operator ist eine in die Programmiersprache eingebaute Funktion,
Alternativen für asynchrones Messaging als Teil der "Converging Infrastructure"
Mercedes 2012 1. Anforderungen 2. DR 101 3. Datenreplikation Technologie 4. Leistungsumfang heute 5. Arbeitsweise 6. Zukunft 7. Markt und Kunden 8. Anforderungen revisited 9. Warum Gravic und CS Software?
Administrator-Anleitung
Administrator-Anleitung für die Typ 2 Installation der LEC-Web-Anwendung auf einem Microsoft Windows Server Ansprechpartner für Fragen zur Software: Zentrum für integrierten Umweltschutz e.v. (ZiU) Danziger
SAP NetWeaver Gateway. Connectivity@SNAP 2013
SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten
1 Einführung... 13. 2 Erste Schritte... 19. 3 Programmierkurs... 33. 4 Datentypen... 81. 5 Weiterführende Programmierung... 139
Auf einen Blick 1 Einführung... 13 2 Erste Schritte... 19 3 Programmierkurs... 33 4 Datentypen... 81 5 Weiterführende Programmierung... 139 6 Objektorientierte Programmierung... 191 7 Verschiedene Module...
Howto. Konfiguration eines Adobe Document Services
Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...
Mailrouter Dokumentation
Mailrouter Dokumentation Mailrouter Funktionen Der Mailrouter ist integraler Bestandteil des CT-PEN Systems und dient zur Verteilung und Konvertierung der Formulardaten. Einlesen der Formulardaten in einen
ActivityTools for MS CRM 2013
ActivityTools for MS CRM 2013 Version 6.10 April 2014 Benutzerhandbuch (Wie man ActivityTools für MS CRM 2013 benutzt) Der Inhalt dieses Dokuments kann ohne Vorankündigung geändert werden. "Microsoft"
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.
NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND
NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum
SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis
Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,
Einrichtung Mac OS X Mail IMAP
Einrichtung Mac OS X Mail IMAP Fachhochschule Eberswalde IT-Servicezentrum Erstellt im Mai 2009 www.fh-eberswalde.de/itsz Die folgende Anleitung beschreibt die Einrichtung eines E-Mail-Kontos über IMAP
Komponentenbasierter Taschenrechner mit CORBA
Komponentenbasierter Taschenrechner mit CORBA Silke Kugelstadt Torsten Steinert Inhalt Motivation Demonstration des Taschenrechners Grobarchitektur Implementierung des Clients Implementierung der Komponenten
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
Zwischenbericht. Diplomarbeit Thema: Evaluation des Projekts Quality Objects. Sven Harazim sh17@inf.tu-dresden.de
Zwischenbericht Diplomarbeit Thema: Evaluation des Projekts Quality Objects Sven Harazim sh17@inf.tu-dresden.de Gliederung Aufgabenstellung Übersicht Dienstgüteparameter Framework Quality Objects Beispielanwendung
CNAME-Record Verknüpfung einer Subdomain mit einer anderen Subdomain. Ein Alias für einen Domainnamen.
Seite 1 von 5 Nameserver Fragen zu den Nameservereinstellungen df FAQ Technische FAQ Nameserver Welche Nameserver-Records stehen zur Verfügung? Bei domainfactory können folgende Nameservereinträge erstellt
Referenz-Konfiguration für IP Office Server. IP Office 8.1
Referenz-Konfiguration für IP Office Server Edition IP Office 8.1 15-604135 Dezember 2012 Inhalt Kapitel 1: Einführung... 5 Zweck des Dokuments... 5 Zielgruppe... 5 Zugehörige Dokumente... 5 Kapitel 2:
IBM SPSS Data Access Pack Installationsanweisung für Windows
IBM SPSS Data Access Pack Installationsanweisung für Windows Inhaltsverzeichnis Kapitel 1. Übersicht.......... 1 Einführung............... 1 Bereitstellen einer Datenzugriffstechnologie.... 1 ODBC-Datenquellen...........
Musterlösung Klausur SS 2004
Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:
Glossar. SVG-Grafiken in Bitmap-Grafikformate. Anweisung Eine Anweisung ist eine Folge aus Schlüsselwörtern, Variablen, Objekten,
Glossar Anweisung Eine Anweisung ist eine Folge aus Schlüsselwörtern, Variablen, Objekten, Methoden und/oder Eigenschaften, die eine bestimmte Berechnung ausführt, eine Eigenschaft ändert oder eine Methode
1 Die Active Directory
1 Die Active Directory Infrastruktur Prüfungsanforderungen von Microsoft: Configuring the Active Directory Infrastructure o Configure a forest or a domain o Configure trusts o Configure sites o Configure
Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors
Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht
Dokumentation Managed Exchange Endkunden Anleitung
Dokumentation Managed Exchange Endkunden Anleitung Kurzbeschrieb Das vorliegende Dokument beschreibt die Verwaltung für Endkunden über das Hosting Portal. Auftraggeber/in Autor/in Markus Schütze / Daniel
5. Programmierschnittstellen für XML
5. Programmierschnittstellen für Grundlagen Dr. E. Schön FH Erfurt Sommersemester 2015 Seite 135 Programmierschnittstelle Notwendigkeit: Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen
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
Jürgen Schwab, debis Systemhaus
Jürgen Schwab, debis Systemhaus 1 Komponenten - Markt VAA - Referenzmodell: eine komponentenorientierte Anwendungsarchitektur März 99 99 2 Die Voraussetzungen für einen Komponentenmarkt sind so gut wie
Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste
Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene
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
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
Installation und Benutzung AD.NAV.ZipTools
Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente
Im Kapitel Resourc Manager werden die verschiedenen Möglichkeiten der Überwachung von Messwerten eines Server oder Benutzers erläutert.
4 Resource Manager Erfassung von Messwerten und deren Auswertung. 4.1 Übersicht Themen des Kapitels Resource Manager Themen des Kapitels Einsatz des Resource Managers Installation des Resource Managers
TimeMachine. Time CGI. Version 1.5. Stand 04.12.2013. Dokument: time.odt. Berger EDV Service Tulbeckstr. 33 80339 München
Time CGI Version 1.5 Stand 04.12.2013 TimeMachine Dokument: time.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor Version Datum Kommentar
C++ - Operatoren. Eigene Klassen mit neuen Funktionen
C++ - Operatoren Eigene Klassen mit neuen Funktionen Übersicht Klassen bisher Eigene Operatoren definieren 2 Bisher Durch Kapselung, Vererbung und Polymorphy können nun eigene Klassen definiert werden,
Projekt Message-Logger
M o d u l S o f t w a r e k o m p o n e n t e n T A. S W K. F 1 0 0 1 Projekt Message-Logger S y s t e m s p e z i f i k a t i o n Horw, 06.06.2010 Projekt Dokument Schule Modul Projektteam Dozenten Letzte
Kommunikation und Kooperative Systeme
Kommunikation und Kooperative Systeme Teil II Verteilte Dienste und Anwendungen Nik Klever FB Informatik - FH klever@fh-augsburg.de Einführung Begriffsbestimmung Kommunikation: Austausch, Übermittlung
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?
How-to: VPN mit IPSec und Gateway to Gateway. Securepoint Security System Version 2007nx
Securepoint Security System Version 2007nx Inhaltsverzeichnis VPN mit IPSec und Gateway to Gateway... 3 1 Konfiguration der Appliance... 4 1.1 Erstellen von Netzwerkobjekten im Securepoint Security Manager...
Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695
Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination
Enterprise User Security mit Active Directory
Enterprise User Security mit Active Directory Jürgen Kühn Trivadis GmbH Düsseldorf Schlüsselworte: Enterprise User Security, Active Directory, Directory Integration and Provisioning, Active Directory Passwort
Konfigurationsanleitung Fax over IP (T.38) und CAPI Fax Server (T.30) Graphical User Interface (GUI) Seite - 1 -
Konfigurationsanleitung Fax over IP (T.38) und CAPI Fax Server (T.30) Graphical User Interface (GUI) Copyright Stefan Dahler 22. Oktober 2013 Version 1.0 www.neo-one.de Seite - 1 - 1. Fax over IP (T.38)
SMC Integrationsserver 5.0 Versionsinformationen
SMC Integrationsserver 5.0 Versionsinformationen SMC IT AG Pröllstraße 24 86157 Augsburg Tel. (0821) 720 62-0 Fax. (0821) 720 62-62 smc-it.de info@smc-it.de Geschäftsstelle Ettlingen Pforzheimer Straße
SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit
SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID