Hauptseminar. Nachrichtenbasierte Middleware - ein Vergleich: Protokolle, Fähigkeiten, Implementierungen und Anwendungsgebiete
|
|
- Jakob Abel
- vor 5 Jahren
- Abrufe
Transkript
1 Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Hauptseminar Nachrichtenbasierte Middleware - ein Vergleich: Protokolle, Fähigkeiten, Implementierungen und Anwendungsgebiete vorgelegt von: Mihaela Todorova Tomova eingereicht am: geboren am: Studiengang: Studienrichtung: Ingenieurinformatik Multimediale Informations- und Kommunikationssysteme Anfertigung im Fachgebiet: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Verantwortlicher Professor: Wissenschaftlicher Betreuer: Prof. Dr. rer. nat. Jochen Seitz Dipl.-Ing. Karsten Renhak
2 Kurzfassung In dieser Arbeit geht es um die Beschreibung der Fähigkeiten einer nachrichtenbasierten Middleware (MOM : Message Oriented Middleware), die mit einer MOM verwendeten Protokolle und einige der den MOM nutzende open-source Projekte (wie RabbitMQ, ActiveMQ, Qpid, OpenMQ). In dem ersten Kapitel werden die Problemstellung dieser Arbeit und die Anwendungsgebiete einer nachrichtenbasierten Middleware vorgestellt. Das zweite Kapitel beschreibt die Eigenschaften von MOM und gibt eine Antwort auf die Frage, warum MOM benötigt wird. Im nächsten Kapitel werden typische Protokolle und Standards von MOM vorgestellt. Das letzte Kapitel gibt einen Überblick über eine Auswahl der bekanntesten Implementierungen nachrichtenbasierter Middlewares.
3 Abstract This work concentrates on the capabilities and characteristics of a message oriented middleware (MOM), the protocols used with MOM-based middleware and typical MOM implementations such as RabbitMQ, ActiveMQ, Apache Qpid. The first chapter tells us more about where MOM can be found. The second chapter explains the need of a message oriented middleware and gives a description of its capabilities. Typical protocols and standards are discussed in the next chapter. The last chapter compares some of the most used open-source MOM projects.
4 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung 1 2 Fähigkeiten und Funktionen einer MOM 2 3 Protokolle und Standards XMPP Was ist XMPP? Aufbau von XMPP-Streams Vor- und Nachteile JMS Was ist JMS? Eigenschaften JMS Message Model Aufbau von JMS-Nachrichten AMQP Was ist AMQP? Message Model AMQP Wie ist AMQP aufgebaut? Aufbau von AMQP-Nachrichten Vor- und Nachteile Was ist STOMP? Was ist HTTP/HTTPS? Vergleich zwischen AMQP und JMS Implementierungen Beschreibung und Vergleich von typischen open-source Projekten RabbitMQ Apache ActiveMQ Apache Qpid
5 Inhaltsverzeichnis ii OpenMQ Zusammenfassung Literaturverzeichnis 26 Abbildungsverzeichnis 29 Tabellenverzeichnis 30 Abkürzungsverzeichnis 31 Erklärung 33
6 1 Einleitung 1 1 Einleitung Die Entwicklung des Internets und seine sich ausweitende Nutzung hat zu vielen und vielfältigen Möglichkeiten geführt. So sind wir es beispielsweise heutzutage gewohnt online Sachen zu kaufen oder zu verkaufen, uns einfach, schnell und zu jederzeit über die Wettervorhersage oder den Verkehrszustand zu informieren oder die Route eines Briefes zu verfolgen. Für alle diese Möglichkeiten stehen Anwendungen zur Verfügung. Um die Kommunikation zwischen den verschiedenen Anwendungen innerhalb einer Organisation oder zwischen mehreren zu schaffen ist, muss eine Zwischenschnittstelle hinzugefügt werden. Diese Schnittstelle wird durch eine Message Oriented Middleware, kurz MOM genannt, repräsentiert. Durch MOM kann die Kommunikation zwischen verschiedene Anwendungen erleichtert werden. Middleware dieser Art findet man unter anderem auch bei Onlinespiele oder beispielsweise im Finanzsektor. Immer mehr wird MOM auch im Alltag der Menschen eingesetzt, z.b. in technischen Assistenzsystemen, die älteren, allein wohnenden Menschen helfen. Weitere Vorteile der Middleware werden in den folgenden Kapiteln dargestellt. Ziel dieser Arbeit ist die Fähigkeiten und Funktionen einer nachrichtenbasierten Middleware zu recherchieren und die dazugehörenden Protokolle und Standards zu beschreiben und zu vergleichen.
7 2 Fähigkeiten und Funktionen einer MOM 2 2 Fähigkeiten und Funktionen einer MOM Vor der Entwicklung einer nachrichtenbasierten Middleware wurde RPC (Remote Procedure Call) verwendet, um die Kommunikation zwischen Prozessen (Systemen) zu ermöglichen. RPC ist mit einem Telefongespräch vergleichbar. Bei dem Remote Procedure Call sprechen die beiden Systeme miteinander. Mit fortschreitender technischer Entwicklung und steigender Komplexität entstand auch der Wunsch nach besserer Quality of Service ( QoS), besserer Performanz und höherer Geschwindigkeit. RPC konnte diese Anforderungen nicht mehr erfüllen, weshalb nach einer Alternative geforscht wurde. Das Ziel von MOM war es daher, die Nachteile von RPC zu beseitigen und wachsende Ansprüche zu bedienen. Einen Vergleich zwischen RPC und MOM zeigt Tabelle 2.1. MOM arbeitet nach dem Store and Forward Prinzip. Man ermöglicht es eine Nachricht zu erhalten, auch wenn Sender und Empfänger nicht gleichzeitig aktiv sind. Dies wird durch die Verwendung von Message Queues realisiert. Daher kann MOM auch mit Post-Diensten verglichen werden. Im Vergleich zu RPC, MOM ist zuverlässiger, flexibler und besser skalierbar. MOM bietet eine asynchrone, verbindungslose und anwendungsunabhängige Technologie. Die Verwendung von MOM ermöglicht die Zustellung von Nachrichten, die nicht sofort gesendet werden können. z.b. in Fällen, in denen es keinen Internetzugang oder nur schlechte Verbindung gibt. Grundsätzlich kann MOM drei wichtige Komponenten unterscheiden: Konsumenten, Produzenten und message Brokers (message Provider).
8 2 Fähigkeiten und Funktionen einer MOM 3 Vorteile Nachteile RPC einfacher Mechanismus; direkte Nachrichtenübertragung durch synchrones Modell; garantierte sequenzielle Verarbeitung; langsam, aber widerspruchsfrei unflexible; enge Kopplung; alle Komponenten des Systems müssen funktionieren, ansonsten arbeitet das System nicht mehr; Skalierungsprobleme; mehr Bandbreite; unterstützt nur einen Client MOM weniger Bandbreite; keine großen Änderungen von Anwendungen; integrierte Infrastruktur, die Änderungen stören die Funktionalität des Systems nicht; unterstützt mehrere Clients keine Garantie für sequenzielle Verarbeitung, daraus folgen kurzfristige Ungenauigkeiten der Daten in der Datenbank Tabelle 2.1: Vergleich RPC und MOM,[Mah04]
9 2 Fähigkeiten und Funktionen einer MOM 4 Die Produzenten (Sender) haben die Aufgabe Nachrichten zu erzeugen und sie zu einer Zwischeninstanz (message broker) zu senden. Die Konsumenten (Receiver) können Nachrichten aus einem message Broker entnehmen. Die dritte wichtige Kompetente ist der message Broker (message Provider). Die Hauptaufgabe eines message Brokers ist es, Nachrichten von einem Produzenten zu einem Konsumenten weiterzuleiten. Durch diese vermittelnde Instanz gibt es keine direkte Verbindung zwischen Sender und Empfänger. Aus der Verwendung von Warteschlangen folgt asynchrones Verhalten. Typische MOM- Kommunikationsmodelle, die Warteschlangen benutzen, werden in Kapiteln und ausführlich beschrieben. Weitere Aufgaben sind in [ASR + 05] aufgelistet: Verbindung heterogener Systemen Übersetzung des Nachrichtenformates des Senders in ein oder in meherere Nachrichtenformaten des oder der Empfänger MOM sorgt für effiziente Nachrichtenvermittlung (priorisierbare Nachrichtenvermittlung) [Ric11] Nach [Mah04] bietet MOM lose Kopplung, welche durch das Hinzufügen von einer Schicht zwischen Sender und Empfänger realisiert wird. Dieser Kopplungsart erleichtert die Durchführung von Änderungen einzelner Komponenten in einem System. So können Anwendungen von verschiedenen Systemen leichter miteinander kommunizieren, ohne Anpassungen der Ziel- und Quellsysteme. Diese Funktion bietet RPC nicht. Wie in der Einleitung kurz erwähnt, kann MOM in Assistenzsystemen oder in verteilen Systemen benutzt werden. Das MOM basierte Protokoll AMQP wird auch von vielen Finanzorganisationen eingesetzt. Beispiele für MOM -Implementierungen sind u.a. WebsphereMQ, Apache ActiveMQ, RabbitMQ.
10 3 Protokolle und Standards 5 3 Protokolle und Standards 3.1 XMPP Was ist XMPP? XMPP steht für Extensible Messaging and Presence Protocol und ist ein Kommunikationsprotokoll von MOM. XMPP wurde zunächst unter dem Namen Jabber bekannt wurde dieses auf XML basierendes Protokoll von der Jabber open-source Gruppe entwickelt. Im Jahr 2008 wurde Jabber ein Teil der Cisco Firmengruppe. Die Idee für die Entwicklung dieses Protokolls war es, den echtzeitfähigen Nachrichtenaustausch zu ermöglichen. Mit den Jahren hat sich das Protokoll verbreitet und wurde von Firmen wie Google, AOL und Facebook benutzt.[wik14c] Aufbau von XMPP-Streams Das XMPP-Protokoll verwendet zur Kommunikation Streams. Abbildung 3.1 zeigt den grundlegenden Aufbau eines Streams. Man kann sehen, dass der XMPP-Stream in einen Initial Stream und in einen Response Stream aufgeteilt ist. Man kann auch drei wichtige Teile erkennen:[hal12] presence message iq Vor- und Nachteile XMPP gibt den Benutzern die Möglichkeit einen eigenen Server zu betreiben. Somit kann ein zentraler Server durch einzelne Server ersetzt werden. So können eine eventuelle Überlastung und der daraus folgende single point of failure vermieden werden. Noch ein
11 3 Protokolle und Standards 6 Abbildung 3.1: Vereinfachte Sicht auf zwei Streams, [Hal12] Vorteil von XMPP ist die Sicherheit, die durch das Benutzen von isolierten Intranetservern und durch die Verschlüsselung via SASL und TLS realisiert werden kann. Als Nachteil kann man die Verwendung vom XML-Format erwähnen. XMPP ist als ein einzelner XML-Dokument kodiert und es ist nicht möglich unmodifizierte binäre Daten zu übertragen. Anstatt XML kann man AMQP benutzen.[hal12] 3.2 JMS Was ist JMS? JMS steht für Java Message Service und ist in [Wik13a] erläutert. JMS ist ein Teil aus dem Java Platform, Enterprise Edition und wurde durch den Java Community Process
12 3 Protokolle und Standards 7 im Rahmen des JMR 914 genormt. JMS repräsentiert eine Programmierschnittstelle (API ). Diese Schnittstelle steurt den Nachrichtenaustausch zwischen ein oder mehreren Clients. Wie das Akronym zeigt, wird Java als Programmiersprache verwendet wurde die erste Version (JMS 1.0.2b) entwickelt, gefolgt von Version 1.1 im Jahr Die aktuellste Version (2.0) wurde 2013 etabliert Eigenschaften Einer der Hauptgründe für die Entwicklung von nachrichtenbasierter Middleware war der Ersatz von enger Kopplung (RPC ) durch lose Kopplung. Allerdings stellte sich mit der Einführung loser Kopplung auch die Frage nach der Portabilität. [Mah04] JMS hat das Ziel, eine lose gekoppelte, verlässliche und asynchrone Kommunikation zwischen den Komponenten einer verteilten Anwendung zu ermöglichen. Bild 3.2 zeigt die Kommunikation zwischen einem Client und einem Server. Um die Kommunikation wie in dieser Abbildung zu ermöglichen, müssen Client und Server die API des Middleware-Herstellers verwenden. Obwohl effektiv, ist diese Variante nicht portierbar. Um Portabilität zu erreichen, braucht man eine standardisierte Schnittstelle. Mittels dieser Schnittstelle kann man auf die nachrichtenbasierte Middleware zugegriffen werden. Bild 3.3 zeigt, dass JMS die herstellerspezifische API ergänzt.[sh05] Abbildung 3.2: MOM ohne JMS, [SH05] JMS Message Model JMS unterstützt zwei Arten von Nachrichtenübertragung: Punkt-zu-Punkt (Point-to-Point) Publish/Subscribe (Pub/Sub) Beide Modelle basieren sich auf dem Nachrichtenaustausch über einen Kanal (auch als Warteschlange bezeichnet) und werden in Abbildungen 3.4 und 3.5 dargestellt.
13 3 Protokolle und Standards 8 Abbildung 3.3: MOM mitjms, [SH05] Point-to-Point Dieses Modell ermöglicht einen asynchronen Austausch von Nachrichten. Bild 3.4 zeigt wie Produzenten Nachrichten an Konsumenten über eine Warteschlange schicken. Die Anzahl von den Produzenten kann variieren, wobei die Anzahl von Konsumenten bis auf einen begrenzt ist. Bei diesem Modell werden die Nachrichten nur einmal weitergeleitet. Sie werden in einer Warteschlange gespeichert bis sie von dem entsprechenden Konsumenten empfangt werden. Die Nachrichten werden über das FIFO-Prinzip in der Warteschlange gespeichert und aus der Warteschlange entnommen. [Mah04] Publish/Subscribe Bild 3.5 zeigt das zweite Modell. Im Gegensatz zu dem P2P-Modell können Nachrichten an mehreren Konsumenten weiterleitet werden. Konsumenten und Produzenten brauchen nichts voneinander zu wissen. Der Produzent sendet die Nachrichten themenspezifisch an den message Broker. Der Empfänger bekommt nur die Nachrichten, deren Themen er abonniert hat. Im Fall, dass einzelne Konsumenten nicht aktiv sind, gibt es zwei Möglichkeiten. Bei einem normalen Abonnement erreichen die Nachrichten die inaktiven Ziele nicht. Wenn ein dauerhaftes Abonnement gewählt ist, werden die Nachrichten in einer Warteschlange zwischengespeichert und später von den jeweiligen Abonnenten gelesen.[mah04] Aufbau von JMS-Nachrichten JMS Anwendungen kommunizieren mittels Nachrichten. Nachrichten sind einfach strukturiert, flexibel und können durch verschiedene Anwendungen verwendet werden. JMS
14 3 Protokolle und Standards 9 Abbildung 3.4: P2P-Kommunikation, [SH05] Abbildung 3.5: Sub/Pub-Kommunikation, [SH05] definiert das Superinterface Message. Davon werden die folgenden Subinterfaces abgeleitet (Bild 3.6):[SH05] BytesMessage MapMessage ObjectMessage StreamMessage
15 3 Protokolle und Standards 10 TextMessage Abbildung 3.6: Message Interfaces, [SH05] Mit deren Hilfe können Daten verschiedener Art versendet werden. Eine JMS Nachricht besteht aus drei Teilen. In der folgenden Tabelle (3.1) werden die drei Teile dargestellt und kurz beschrieben. 3.3 AMQP Was ist AMQP? AMQP steht für Advanced Message Queuing Protocol. AMQP Version 1.0 ist ein OASIS Standard, der den Nachrichtenaustausch zwischen Anwendungen oder Organisationen ermöglicht wurden die ersten beiden AMQP-Versionen (0-8, 0-9) veröffentlicht, gefolgt von den Versionen 0-10 und im Jahr wurde die neuste Version (1.0) auf dem Markt gebracht Message Model AMQP Nachrichtenaustausch im AMQP erfolgt mittels exchanges und Warteschlangen. Die exchange-komponente dient nur als Verteiler und speichert keine Nachrichten.
16 3 Protokolle und Standards 11 Elements Description Required Nachrichtenkopf (Header) Enthält Information über Identifikation und Pfad von Nachrichten. Abb. 3.6 zeigt eine Auflistung von Header-Feldern und deren Werte. Ja Nachrichtenrumpf (Body) speichert Nutzdaten, die zum Nachrichtenaustausch benutzt werden. Mit Hilfe der Messaghe Typen (Subinterfaces) aus Abb. 3.8 kann man eine Übertragung verschiedener Nutzdaten ermöglicht werden. Nein Nachrichteneigenschaften (Properties) Verschiedene Datentypen (boolean, byte, int, short, u.a) stehen dem Entwickler zur Verfügung. Drei Eigenschaftskategorien können hier unterscheiden werden (anwendungsspezifische, JMS-definierte und providerspezifische) Nein Tabelle 3.1: Teile einer JMS-Nachricht und deren Beschreibung,[SH05] Diese Aufgabe übernehmen die Warteschlangen, sie speichern Nachrichten. Das message Model AMQP bietet fünf exchange-typen (Direct Exchange, Fanout Exchange, Header Exchange, Topic Exchange, System Exchange). Die ersten beiden müssen von den message Brokers verwendet werden. Die anderen drei sind optional. Direct Exchange ähnelt dem JMS-P2P Modell. Der Unterschied ist, dass es bei Direct Exchange keine Beschränkung für die Anzahl von Konsumenten gibt. Fanout Exchange, Topic
17 3 Protokolle und Standards 12 Abbildung 3.7: How JMS Message Header Field Values are set, [JMS13] Exchange und Header Exchange ähneln dem Pub/Sub-Modell. System Exchange kann Nachrichten zu einem Anwendungs- oder einem Systemdienst weiterleiten. Typischerweise werden die Nachrichten an eine Warteschlange weitergeleitet.[ric11] Wie ist AMQP aufgebaut? AMQP kann in zwei Bereiche unterteilt werden: Nezwerkprotokoll-Teil und das Protokollmodell-Teil. Im ersten Teil wird entschieden, welche Informationen die Clientund Serveranwendungen austauschen sollen,um miteinander zu kommunizieren. AMQP überträgt Daten mittels Rahmen (Frames). Der zweite Teil setzt die Standards an AMQP Anwendungen. Eine Anwendung kann die Form und Kodierungsart der Daten beliebig wählen. AMQP definiert neun verschiedene Frame-Bodies:[Hal12] open: neue Verbindung herstellen begin: neue Session erstellen attach: neuen Link erstellen transfer: Nachricht verschicken
18 3 Protokolle und Standards 13 Abbildung 3.8: JMS Message Types,[JMS13] flow: Nachrichtenaustauschkontrollschema disposition: Zuverlässigkeitseinstellung(at-most-once, at-least-once, exactly-once) detach: Link trennen end: Session beenden close: Verbindung schließen Aufbau von AMQP-Nachrichten Der Aufbau von AMQP Nachrichten ähnelt den Aufbau von JMS-Nachrichten. Wie in Punkt erwähnt, bestehen JMS-Nachrichten aus drei Teilen (header, properties section, message body). AMQP dagegen besteht aus mehreren Teilen (header, proporties, body and optional footer). Der header-teil im Vergleich zu JMS-header enthält unveränderliche anwendungsspezifische Eigenschaften. Der Property-Teil stellt die unveränderlichen Routing- und Metadaten Eigenschaften dar. Im AMQP existiert nur
19 3 Protokolle und Standards 14 Abbildung 3.9: Aufbau des AMQP Frames, [Hal12] ein Nachrichten Body-Typ (eine binäre Nachricht). Bei JMS gibt es fünf Nachrichten Body-Typen. [Wik14a] Vor- und Nachteile Das Protokoll wurde für den Finanz- und Börsensektor entwickelt. Aus diesem Grund waren hohe Geschwindigkeit, Durchsatz, Skalierbarkeit, Verlässlichkeit, Sicherheit und Interoperabilität gewünscht. Da AMQP ein binäres Netzwerkprotokoll ist, entsteht der Vorteil mehrere Daten in einem Rahmen zu übertragen. Daraus folgt die Erhöhung der Geschwindigkeit. Eine weitere Besonderheit ist die Verschiebung der Routinglogik in den Broker, was wieder zur Erhöhung der Geschwindigkeit führt. Die Verschiebung der Routinglogik kann nicht nur als Vorteil, sondern auch als Nachteil gesehen werden. Die Folge ist, dass man bei der Implementierung von AMQP im Vergleich zu anderen Protokollen (z.b. XMPP) mehr Programmierungsarbeit geleistet werden muss. [Hal12] 3.4 Was ist STOMP? STOMP steht für Streaming Text Oriented Messaging Protocol und ist ein textbasiertes Protokoll. STOMP ähnelt HTTP und wird von nachrichtenbasierten Middlewares verwendet. Das Protokoll benutzt ein wire-format. 1 [Con13] Mittels STOMP können STOMP-Clients mit STOMP unterstützenden Message 1 wird benutzt zur Übertragung von Daten von einem Punkt zu einem anderen. Ein wire-protokoll ist bei der Interoperabilität von einer oder mehreren Anwendungen verwendet.
20 3 Protokolle und Standards 15 Brokers unproblematisch kommunizieren. Wie in [Jü11] erwähnt ist, ermöglicht STOMP eine Kommunikation zwischen Anwendungen verschiedener Herkunft, in Bezug auf die zugrundeliegende Programmiersprachen und Plattform. 3.5 Was ist HTTP/HTTPS? HTTP steht für HyperText Transfer Protocol und ist ein Anwendungsschichtprotokoll. HTTP dient zur Übertragung von Daten über ein Netzwerk und wird am meisten zum Laden von Webseiten in einem Webbrowser verwendet. HTTPS steht für HyperText Transfer Protocol Secure und hat die selben Eigenschaften wie HTTP. Der Unterschied liegt in der abhörsicheren Übertragung von Daten. Diese wird durch eine SSL/TLS Verschlüsselung erreicht. HTTP bzw. HTTPS wird verwendet, um die Barriere eines clientseitigen Firewalls umgegangen zu werden. So wird eine Nachrichtenvermittlung mittels XML-Messages ermöglicht, was die Kommunikation zwischen Client und Message Broker erleichtert.[wik14b] 3.6 Vergleich zwischen AMQP und JMS Im Vergleich zu AMQP spezifiziert JMS eine API. D.h., JMS entscheidet, wie Senderund Empfängerseite implementiert sind. AMQP dagegen ist eine Lösung für Interoperabilität zwischen unterschiedlichen Implementierungen. So können beispielsweise Sender und Empfänger in verschiedenen Programmiersprachen geschrieben sein. Ein weiterer Unterschied liegt im Message Routing: Message Routing AMQP Im Vergleich zu JMS-message Routing (Bild 3.10 ) hat das AMQP-Message Routing (Bild 3.11 ) zusätzlich zu den Komponenten: Produzent, Konsument und Warteschlange auch eine binding- und exchange-komponente. Die exchange-komponente hat einen Routing-Schlüssel (routing key). Die binding-komponente verbindet die exchange- Komponente mit der Warteschlange.[Ric11] Message Routing JMS Bild 3.10 zeigt wie message Routing bei JMS realisiert wird. Aus dem Bild lassen sich die drei wichtigen Teile von JMS erkennen. (Produzent, Konsument, Warteschlange).
21 3 Protokolle und Standards 16 Damit Produzent (Sender) und Konsument (Receiver) Nachrichten austauschen können, müssen sie zunächst mit einer Warteschlange verbunden sein. Entweder sind beide mit einer Warteschlange des gleichen Namens verbunden oder der Produzent sendet themenspezifische Nachrichten, während der Konsument Themen abonniert. [Ric11] Weitere Unterschiede sind die Nachrichtenstruktur und Nachrichtenmodelle. Sie werden in Kapiteln 3.2.4, und in Kapiteln 3.2.3, beschrieben. In [Wik14a] wird erwähnt, wofür JMS nicht geeignet ist. JMS definiert einen Standard für Interoperabilität innerhalb einer Java-Platform, aber nicht außerhalb dieser Platformen. In Fällen, in denen es sich um unterschiedliche Platformen handelt und JMS verwendet wird, können verschiedenen Nachteilen auftreten. Einige dieser Nachteile sind die folgenden: Die Protokolle (z.b. STOMP, OpenWire 2 ), die der Message Broker für die verschiedenen Klienten benötigt, können unterschiedliche Nachrichten Body-Typen (message body types) unterstützen. Die Protokolle können unterschiedliche Datentypen und unterschiedliche header- Eigenschaften unterstützen. Viele Lösungen für cross-platform Interoperabilität sind oft kommerziell und nicht Fokus dieser Arbeit. AMQP ist deshalb häufig eine bessere Alternative. AMQP bietet eine Spezifikation für ein standardisiertes wire-level Protokoll. Die Aufgabe dieser Spezifikation ist es, die Struktur von Nachrichten und die Art und Weise von Nachrichtenvermittlung zu beschreiben. Man kann jede beliebige AMQP Client-Bibliothek und jeden beliebigen AMQP Broker benutzen. Daher liegt die Schlussfolgerung nahe, dass AMQP flexibler, besser austauschbar ist. 2 Openwire ist ein wire-protokoll und wird von ActiveMQ benutzt.
22 3 Protokolle und Standards 17 Abbildung 3.10: JMS-Message Routing, [Ric11] Abbildung 3.11: AMQP-Message Routing, [Ric11]
23 4 Implementierungen 18 4 Implementierungen 4.1 Beschreibung und Vergleich von typischen open-source Projekten Heutzutage gibt es viele kommerzielle und offene Implementierungen, die auf JMS oder AMQP basiert sind. Dieses Kapitel beschreibt und vergleicht eine Auswahl der bekanntesten open-source (ActiveMQ, RabbitMQ, Apache Qpid, OpenMQ) Message Brokers. Abb. 4.3 stellt ein Google Trends Diagramm ein. Die Abbildung zeigt, wie häufig nach den vier in dieser Arbeit gewählten Message Brokers gesucht wurde. Da kommerzielle Software wie WebsphereMQ (auch als MQSeries) zu teuer ist und es viele kostenfreie Projekte gibt, wird diese nicht betrachtet. Tabelle [4.1] zeigt vier open-source Projekte und die Kriterien, nach denen die Brokers miteinander verglichen sind. Einige der wichtigsten Kriterien für Message Brokers sind Clustering, Zuverlässigkeit, Robustheit, Sicherheit, Persistenz. Unter Clustering versteht man eine Gruppe von miteinander arbeitender Geräte (z.b. Rechner, Message Brokers). Broker cluster sind für diese Arbeit besonders relevant, da mit ihrer Hilfe eine zuverlässige Nachrichtenübertragung sicher gestellt werden kann. So kann beispielsweise ein aus irgendwelchen Gründen ausgefallener Broker mit einem anderen Broker aus demselben Cluster ersetzt werden. Der Broker übernimmt die Arbeit des ausgefallenen Brokers, um so die weitere Nachrichtenvermittlung zu garantieren. In [Clu13] werden grundsätzlich zwei Arten von Broker clusters unterschieden: conventional broker clusters enhanced broker clustering Conventional broker clusters (Bild 4.1 ) bieten service availability. Wenn ein Broker ausfällt, wird die Kommunikation mittels eines anderen Brokers wiederhergestellt.
24 4 Implementierungen 19 Diese Art von Broker cluster haben den Nachteil, dass Nachrichten und Zustandsinformationen des ausgefallenen Brokers nicht in dem Neuen erhalten sind. Abbildung 4.1: Conventional broker clusters, [Clu13] Enhanced broker clusters (Bild 4.2 ) bieten data availability und service availability. Der Unterschied hier ist, dass der neue Cluster einen Zugang zu allen Informationen und Nachrichten des ausgefallenen Brokers erlaubt. Das wird durch das Benutzen gemeinsamer Datenspeicher realisiert. Dieser Speicher ist durch eine highly-available JDBC Datenbank repräsentiert. Im Gegensatz dazu hat in den conventional broker clusters jeder Cluster einen separaten Datenspeicher. Die enhanced Broker clusters bieten auch recovery at failover, was auch für eine zuverlässige Nachrichtenvermittlung spricht. Ein weiteres Kriterium ist Persistenz. In [Wik13c] ist Persistenz definiert als die Fähigkeit, Daten (oder Objekte) oder logische Verbindungen über lange Zeit (insbesondere über einen Programmabbruch hinaus) bereitzuhalten. Dies wird durch die Verwendung von Datenbanken ermöglicht. Zwei Typen von Persistenz werden unterschieden: persistenter Typ und nicht persistenter Typ. Der Unterschied zwischen beiden ist, dass bei dem persistenten Typ die Nachrichten nach der Vermittlung immer noch zur Verfügung stehen. Die nicht-persistenten Nachrichten werden nach der Übertragung aus dem Speicher gelöscht.
25 4 Implementierungen 20 Abbildung 4.2: Enhanced broker clustering, [Clu13] Persitenz wird auch durch JDBC (Java Database Connectivity) repräsentiert. JDBC ist eine Datenbankschnittstelle. In [Jü11] ist erwähnt, dass Nachrichten über eine standardisierte Schnittstelle auf Datenbanken gespeichert werden können. So können verschiedene Datenbanksystemen unterstützt werden, da der brokerseitige Zugriff datenbankneutral ist. Man unterscheidet auch dateibasierte Persistenz. Durch das Anlegen von individuellen Dateien können Nachrichten persistent gespeichert werden. Bespiele für dateibasierte Persistenz ist AMQ Message Store, KahaDB MessageStore. Unter dem Kriterium Robustheit versteht man die Fähigkeit eines Systems auch unter ungünstigen Bedingungen (z.b. Serverausfall) weiter zu funktionieren. Für Robustheit bei den Message Brokers sprechen Kriterien wie Clustering und redelivery policy. In [Mes13] wird erwähnt, dass ActiveMQ im Vergleich zu anderen Brokern weniger robust ist. Bei extrem hohen Last oder bei tausenden von Queues stößt ActiveMQ an seine Grenze. Daraus kann ein temporärer Ausfall folgen. Eine Möglichkeit für sichere Übertragung wird durch das hybride Verschlüsselungsprotokoll SSL/TLS vorgestellt. SSL/TLS steht für Secure Socket Layer/Transport Layer
26 4 Implementierungen 21 Security. Heutzutage wird nur TLS benutzt. TLS befindet sich in der Transportschicht in der TCP/IP-Schichtenmodell und ist ein hybrides Verschlüsselungsprotokoll zur sicheren Datenübertragung. Bekannte Implementierungen des Protokolls sind OpenSSL und GnuTLS. TLS wird in HTTPS, POP3, SMTP, XMPP und andere Protokolle eingesetzt. Eine weitere Möglichkeit ist JAAS (Java Authentication and Authorization Service). JAAS ist eine Java-API und dient zur Authentifizierung von Diensten und Bereitstellung von Zugriffsrechte RabbitMQ RabbitMQ ist eine häufig verwendete Implementierunge des AMQP Protokolls. RabbitMQ ist ein Open Source Message Broker Software, die von der Firma Rabbit Technologies entwickelt wurde. Wie auch in [Hal12] erwähnt, besteht RabbitMQ aus den folgenden vier Teilen: RabbitMQ Server, der in der Sprache Erlang geschrieben ist Gateways für diversen Protokolle (HTTP, STOMP, u.a.) Bibliotheken für AMQP Clients (Java,.NET, Erlang) Plug-in Plattform, deren Arbeit sich durch drei Plug-ins weiter charakterisiert: Shovel Plug-in (kopiert oder tauscht Nachrichten von einem Broker zu einem anderen), Federation Plug-in (kümmert sich um eine effiziente Mitteilung von Nachrichten zwischen zwei Brokern), Management Plug-in (zur Steuerung und Überwachung von Brokern). RabbitMQ ist zuverlässig, robust, schnell und bietet viele Client- Bibliotheken, die Programmiersprachen wie Java, C++, Python und andere unterstützen. Dieser Broker kann mit Hilfe von Plug-ins auch Protokolle wie STOMP benutzen. Weitere Protokolle, die von RabbitMQ verwendet werden können, sind AMQP (Version 0-8, 0-9, 0-9-1) und XMPP (über Gateway). Als Nachteil kann man hier erwähnen, dass kein AMQ Protokoll in der Version 1.0 unterstützt wird, aber gerade daran gearbeitet wird. In [Wik10] sind ein paar Testergebnisse für RabbitMQ zu finden. Die durchgeführten Tests zeigen, dass Clustering angeboten wird. Bei high-availability Clustern entstehen Probleme in den Fällen, wenn
27 4 Implementierungen 22 Knoten vorübergehend nicht online sind. Was sich noch von den Ergebnissen erkennen lässt ist, dass keine Skalierung für die Anzahl von Clients/queues existiert, was zu einer ineffizienten Nutzung von Speicherplatz führt. Abbildung 4.3: Verbreitung von message Brokers,[Int14] Apache ActiveMQ Apache ActiveMQ ist noch ein sehr verbreiteter und bekannter message broker. In [Mes13] wird dieser Broker als zuverlässig, hoch performant und ressourcenschonend beschrieben. Ein Unterschied zu RabbitMQ ist, dass ActiveMQ die Java Message Service(JMS) Spezifikation unterstützt. Es gibt eine große Wahl an Möglichkeiten für Clustering. So z.b. kann ein high-availability Cluster durch eine Master/Slave Konfiguration geschaffen werden. Wie im Punkt 4.1 erwähnt ist, bietet high-availability Clustering einen schnellen Ersetzen von einem ausgefallenen Cluster. Bei der Master/Slave Konfiguration kann ein Slavebroker den ausgefallenen Master ersetzen. Der Slavebroker enthält eine Kopie aller Daten des Masters. So wird eine eventuelle single point of failure vermieden, da der Master schnell von einem Slavebroker ersetzt wurde. In [Nig09] kann man einen Skalierungstest finden, der zeigt, dass man mehrere Nachrichten zwischen zwei Broker senden kann, wenn man ActiveMQ im Vergleich zu RabbitMQ verwendet Apache Qpid Apache Qpid ist ein open-source message Broker, der auf dem AMQ Protokoll basiert. In [Mes13] wird erwähnt, dass der Qpid Broker in zwei Versionen geboten wird. Die erste Version ist für Java Clients entwickelt und ist unter den Namen Java API für
28 4 Implementierungen 23 Qpid bekannt. Die zweite Version (Qpid Messaging API ) wird von C++, Python und Microsoft.Net-Clients benutzt. Als Vorteil für Apache Qpid kann man die JMS-Client API erwähnen. Mit dieser API können sich Clients über AMQP auch mit anderen Brokern wie z.b. RabbitMQ verbinden.[mes13] OpenMQ OpenMQ ist ein open-source Projekt, das von der Firma Oracle entwickelt wurde. OpenMQ implementiert die JMS-API Version 2.0. Dieser Message Broker bietet auch high availability performance, was für eine zuverlässige Kommunikation zwischen Clients und message Broker spricht. Die Sicherheit in OpenMQ wird durch SSL/TSL und JAAS erreicht.[wik13b] 4.2 Zusammenfassung In diesem Kapitel wurden einige Implementierungen durch selbstgewählte Kriterien miteinander verglichen. Diese Vergleiche geben einen Überblick über verschiedene MOM - basierte Softwares, die auf dem Markt existieren. Dennoch kann man nicht mit Sicherheit sagen, dass eine Software einer anderen überlegen ist. Der Grund dafür ist, dass die zum Vergleich verwendeten Kriterien von weiteren Faktoren wie Programmiersprache und Anwendungsgebiet abhängig sind. So ist beispielsweise ein AMQP Message Broker eine bessere Lösung für Finanzsoftware im Vergleich zu einem JMS-basierten Message Broker.
29 4 Implementierungen 24 Kriterien/Message RabbitMQ Apache ActiveMQ Apache Qpid OpenMQ Brokers JMS/AMQP- AMQP JMS AMQP JMS Unterstützung Zuverlässigkeit Ja Ja Ja Ja Robustheit Ja Ja Ja Ja Clients Schnittstellen C, C++, Erlang,.NET, Python, Ruby, u.a Java, C, C++, Erlang, Phython,.NET, Perl, u.a. C, C++, Java JMS,.NET, Python, Ruby, u.a. Java und C Client API Unterstützung für Messaging Protokolle AMQP(0-8, 0-9, ),MQTT, STOMP, XMPP, HTTP AMQP1.0, MQTT, OpenWire, STOMP, XMPP, UDP, HTTP, TCP AMQP1.0 TCP, UDP, HTTPS, RMI Sicherheit OpenSSL JAAS, LDAP repository pluggable security using SASL JAAS Plugin, SSl/TLS STOMP- ja ja nein ja Unterstützung Persistenz k.a. Memory Message Memory Mes- dateibasierte Store, sage Store, Persistenz, AMQ Message Derby Mes- JDBC Store, sage Store, KahaDB JDBC API Message Store, JDB- SC Clustering/HA ja ja ja ja redelivery policy k.a. dead message queue k.a. automatic acknowledgement Dokumentaion sehr gut sehr gut gut gut Verbreitung hoch hoch niedrig niedrig Tabelle 4.1: Open-source Projekte
30 25 Anhang
31 Literaturverzeichnis 26 Literaturverzeichnis [ASR + 05] Arion, Alexandru ; Schöllhorn, Benjamin ; Reese, Ingo ; Gebhard, Jürgen ; Patsch, Stefan ; Frank, Stephan: MessageBroker(MB). lehre/archiv/ws_05_06/verteiltesysteme_uebung/downloads/ MessageBroker.pdf. Version: Message Broker [Online; zuletzt abgerufen am ] [Clu13] Oracle: 4 Broker Clusters /e24949/broker-clusters.htm. Version: Oracle Homepage [Online; zuletzt abgerufen am ] [Con13] Contributors, Wikipedia: Streaming Text Oriented Messaging Protocol. Oriented_Messaging_Protocol&oldid= Version: 4 September [Online; zuletzt abgerufen am ] [Hal12] Haller, Andreas: Message Queuing System. uni-luebeck.de/teaching/ws2012/sem-sse/andreas-haller-mqs.pdf. Version: Message Queing System [Online; zuletzt abgerufen am ] [Int14] Interest over Time. en-us#q=activemq%2c%20rabbitmq%2c%20qpid%2c%20openmq&cmpt=q. Version: [Online; zuletzt abgerufen am ] [JMS13] [Jü11] Oracle: JMS Messages. doc/bncdr.html#bncds. Version: The Java EE 6 Tutorial [Online; zuletzt abgerufen am ] Jürgens, Frank: Open Message Queue, Technische Universität Ilmenau, Fachgebiet AVT, Hauptseminar, 2011
32 Literaturverzeichnis 27 [Mah04] Mahmoud, Qusay H.: Middleware for Communications. 1. WILEY, Seiten [Mes13] predic8 GmbH: ActiveMQ, Qpid, HornetQ und RabbitMQ im Vergleich. activemq-hornetq-rabbitmq-apollo-qpid-vergleich.htm. Version: ActiveMQ, Qpid, HornetQ und RabbitMQ im Vergleich, Thomas Bayer [Online; zuletzt abgerufen am 2013] [Nig09] [Ric11] Nighttale, Dejan: Python messaging: ActiveMQ and RabbitMQ. sensatic.net/activemq/python-messaging-activemq-and-rabbitmq. html. Version: [Online; zuletzt abgerufen am ] Richards, Mark: Understanding the Differences between AMQP and JMS. Version: Understanding the Differencs between AMQP and JMS [Online; zuletzt abgerufen am ] [SH05] Steffen Heinzl, Markus M.: Middleware in Java. 1. VIEWEG, Seiten [Wik10] Wiki, Second L.: Message Queue Evaluation Notes. http: //wiki.secondlife.com/w/index.php?title=message_queue_ Evaluation_Notes&oldid= Version: [Online; zuletzt abgerufen am ] [Wik13a] Wikipedia: Java Message Service. php?title=java_message_service&oldid= Version: [Online; zuletzt abgerufen am ] [Wik13b] Wikipedia: Open Message Queue Wikipedia, The Free Encyclopedia. Queue&oldid= Version: [Online; zuletzt abgerufen am ] [Wik13c] Wikipedia: Persistenz (Informatik). w/index.php?title=persistenz_(informatik)&oldid= Version: [Online; zuletzt abgerufen am ] [Wik14a] Wikipedia: Advance Message Queuing Protocol. org/w/index.php?title=advanced_message_queuing_protocol&oldid=
33 Literaturverzeichnis Version: Advance Message Queuing Protocol [Online; zuletzt abgerufen am ] [Wik14b] Wikipedia: Hypertext Transfer Protocol Wikipedia, Die freie Enzyklopädie. Transfer_Protocol&oldid= Version: [Online; zuletzt abgerufen am ] [Wik14c] Wikipedia: Message-oriented middleware. w/index.php?title=message-oriented_middleware&oldid= Version: [Online; zuletzt abgerufen am ]
34 Abbildungsverzeichnis 29 Abbildungsverzeichnis 3.1 Vereinfachte Sicht auf zwei Streams, [Hal12] MOM ohne JMS, [SH05] MOM mitjms, [SH05] P2P-Kommunikation, [SH05] Sub/Pub-Kommunikation, [SH05] Message Interfaces, [SH05] How JMS Message Header Field Values are set, [JMS13] JMS Message Types,[JMS13] Aufbau des AMQP Frames, [Hal12] JMS-Message Routing, [Ric11] AMQP-Message Routing, [Ric11] Conventional broker clusters, [Clu13] Enhanced broker clustering, [Clu13] Verbreitung von message Brokers,[Int14]
35 Tabellenverzeichnis 30 Tabellenverzeichnis 2.1 Vergleich RPC und MOM,[Mah04] Teile einer JMS-Nachricht und deren Beschreibung,[SH05] Open-source Projekte
36 Abkürzungsverzeichnis 31 Abkürzungsverzeichnis MOM RPC QoS XML API PDF AMQP XMPP JMS FIFO MQ STOMP P2P Pub/Sub SASL TLS SSL/TLS HTTP HTTPS Message Oriented Middleware Remote Procedure Call Quality of Service extensible Markup Language Application Programming Interface Portable Document Format Advanced Message Queuing Protocol extensible Messaging and Presence Protocol Java Message Service First In First Out Message Queue Streaming Text Oriented Messaging Protocol Point-to-Point Publish/Subscribe Simple Authetication and Security Layer Transport Layer Security Secure Sockets Layer/Transport Layer Security HyperText Transfer Protocol HyperText Transfer Protocol Secure
37 Abkürzungsverzeichnis 32 JDBC JAAS TCP/IP Java DataBase Connectivity Java Authentication and Authorization Service Transmission Control Protocol/ Internet Protocol POP Post Office Protocol version 3
38 Erklärung 33 Erklärung Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen noch nicht vorgelegt worden. Ilmenau, den Mihaela Tomova
Hauptseminar. Nachrichtenbasierte Middleware - ein Vergleich: Protokolle, Fähigkeiten, Implementierungen und Anwendungsgebiete
Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Hauptseminar Nachrichtenbasierte Middleware - ein Vergleich: Protokolle, Fähigkeiten, Implementierungen und Anwendungsgebiete
MehrKapitel 8: Nachrichtenbasierte Kommunikation mit JMS. Middleware in Java vieweg 2005 Steffen Heinzl, Markus Mathes
Kapitel 8: Nachrichtenbasierte Kommunikation mit JMS Middleware und nachrichtenorientierte Middleware Eine Software heißt Middleware genau dann, wenn sie die Entwicklung und den Betrieb eines verteilten
MehrSCHICHTENMODELLE IM NETZWERK
SCHICHTENMODELLE IM NETZWERK INHALT Einführung Schichtenmodelle Das DoD-Schichtenmodell Das OSI-Schichtenmodell OSI / DOD Gegenüberstellung Protokolle auf den Osi-schichten EINFÜHRUNG SCHICHTENMODELLE
MehrWeb Services Die Definition von Web Services in der Theorie und FNT-Command als Web Service in der Praxis
Web Services Die Definition von Web Services in der Theorie und FNT-Command als Web Service in der Praxis Philipp Tendyra Web Service in kurzen Worten dient der Kommunikation zwischen verschiedenen Systemen
MehrIUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only
IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES 2016 Software AG. All rights reserved. For internal use only DIGITAL BUSINESS APPLICATIONS DRIVE THE DIGITAL BUSINESS Partner Lieferanten Kunden SaaS
MehrGrundlagen der Web-Entwicklung INF3172
Grundlagen der Web-Entwicklung INF3172 Web-Services Thomas Walter 16.01.2014 Version 1.0 aktuelles 2 Webservice weitere grundlegende Architektur im Web: Webservice (Web-Dienst) Zusammenarbeit verschiedener
MehrJava 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
MehrMessage 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
MehrGRUDIS RB3 (Schnittstelle MapViewer)
GRUDIS RB3 (Schnittstelle MapViewer) Datum: 7.09.2005 Version: 1.0 Status: Genehmigt Bearbeiter: Markus Lauber Verteiler: Entwickler Fremd-GIS-System Inhaltsverzeichnis 1 Einleitung... 3 1.1 MapViewer...3
MehrEvaluation 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
MehrQBus Enterprise Service Bus. intersales Creating the Digital Enterprise
QBus Enterprise Service Bus intersales Creating the Digital Enterprise Wenn Ihre Anwendungslandschaft so aussieht, Photo: flickr / Michael Coghlan / CC BY-SA 2.0 2 bringt ein ESB Ordnung in Schnittstellen
Mehr<Insert Picture Here> Einführung in SOA
Einführung in SOA Markus Lohn Senior Principal Consultant SOA? - Ideen Selling Oracle To All SAP On ABAP Increasing Sales Of Applications 3 Agenda Motivation SOA-Definition SOA-Konzepte
MehrFWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen. Sommersemester Michael Theis, Lehrbeauftragter 1
FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Sommersemester 2017 2017 Michael Theis, Lehrbeauftragter 1 2 Servlet API Websockets JSF JAX-WS JAX-RS JMS JAXB JSON-P JEE Enterprise
MehrEine Untersuchung der Funktionen des Apache Wicket Webframeworks
Eine Untersuchung der Funktionen des Apache Wicket Webframeworks Seminararbeit von Olaf Matticzk 1 15.01.2016 (c) by synaix 2016 synaix...your business as a service. Agenda 1. Einleitung 2. Webanwendungen
MehrWebservices. 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
MehrSOAP Simple Object Access Protocol. Dr. Reinhard Riedl Universität Zürich/Universität Rostock
SOAP Simple Object Access Protocol Dr. Reinhard Riedl Universität Zürich/Universität Rostock Vision Implementierung von verteilten Systemen über Systemgrenzen hinweg Integration von heterogenen verteilten
MehrGliederung Einleitung Die Interprozess Kommunikation Zusammenfassung Fragen. .NET Remoting. André Frimberger
.NET Remoting André Frimberger 30.11.2004 André Frimberger.NET Remoting 1 Gliederung 1 Einleitung Was ist.net Remoting? 2 Die Interprozess Kommunikation Grundkonzept der Datenkanal Parameterübergabe Instanziierung
MehrOracle Advanced Queuing AQ
Oracle Advanced Queuing AQ 13.09.2012 Referenten: Claus Cullmann Andreas Steinel Inhalt Motivation Message Systeme Eigenschaften, Beispiele Oracle AQ Terminologie AQ Beispiel pure SQL Beispiel Java-Anwendung
MehrProgrammierung von verteilten Systemen und Webanwendungen mit Java EE
Programmierung von verteilten Systemen und Webanwendungen mit Java EE Frank Müller-Hofmann Martin Hiller Gerhard Wanner Programmierung von verteilten Systemen und Webanwendungen mit Java EE Erste Schritte
MehrIndustrie 4.0 zum Anfassen: Web-IO 4.0 Digital mit MQTT
Pressemitteilung Oktober 2016 Industrie 4.0 zum Anfassen: Web-IO 4.0 Digital mit MQTT Die neue Generation der netzwerkbasierten Fernschalter von Wiesemann & Theis unterstützt mit MQTT und REST aktuelle
MehrWeb Services. Standards und Realisierung in Java
Standards und Realisierung in Java http://werner.gaulke.net 4.6.2007 Idee Aufbau und Standards und Java Outline 1 Idee Idee hinter? 2 Aufbau und Standards Schichtenmodell WSDL Fazit WSDL SOAP Fazit SOAP
MehrStudienprojekt HP-MOM
Institute of Parallel and Distributed Systems () Universitätsstraße 38 D-70569 Stuttgart Studienprojekt HP-MOM High Performance Message Oriented Middleware 23. Januar 2013 Kurt Rothermel, Frank Dürr, Patrick
MehrMQTT Dokumentation VERBINDEN VON ENDGERÄTEN ÜBER DAS MQTT-PROTOKOLL VERSION 1.1.0
MQTT Dokumentation VERBINDEN VON ENDGERÄTEN ÜBER DAS MQTT-PROTOKOLL VERSION 1.1.0 INHALT Über das MQTT-Protokoll... 2 Verbindungsaufbau... 2 Verbindungsparameter... 2 Verbindungsbestätigung... 3 Topic-Übertragung...
MehrEnterprise JavaBeans Überblick
Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.
MehrVerteilte Systeme - Java Networking (Sockets) -
Verteilte Systeme - Java Networking (Sockets) - Prof. Dr. Michael Cebulla 30. Oktober 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 36 M. Cebulla Verteilte Systeme Gliederung Grundlagen TCP/IP
MehrLösen Sie (fast) alle ihre Probleme mit Oracle Advanced Queuing. Performance Lastverteilung
Lösen Sie (fast) alle ihre Probleme mit Oracle Advanced Queuing Matthias Schulz Schulz IT Services GmbH Nürnberg Schlüsselworte Oracle Datenbank; Oracle Advanced Queuing; AQ; Messaging; IT-Probleme; Lösungen;
MehrAlexandru 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
MehrVermittlungsschicht ( network layer )
Vermittlungsschicht ( network layer ) ggf. Auswahl eines Subnetzes für die folgende Übertragungsstrecke Auswahl eines guten Transportweges (Routing) im gewählten Subnetz statisch: fest für alle Pakete
MehrSoftwareentwicklung mit Enterprise JAVA Beans
Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung
MehrInteroperabilität von OPC UA und DDS. Mahyar Azarmipour Lehrstuhl für Prozessleittechnik RWTH Aachen Winterkolloquium
Interoperabilität von OPC UA und DDS Mahyar Azarmipour Lehrstuhl für Prozessleittechnik RWTH Aachen Winterkolloquium 02.12.2016 Agenda OPC UA DDS Ein Vergleich Die Interoperabilität von DDS und OPC UA
MehrXMPP: Extensible Messaging and Presence Protocol
XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung
MehrInformations- und Kommunikationssysteme
Informations- und Kommunikationssysteme TCP/IP: Transport und Vermittlung im Karl Meier karl.meier@kasec.ch Agenda 1 2 3 4 5 6 7 und Protokolle, IP Adressierung Die Transportprotokolle UDP und TCP ISO/OSI
MehrJMS Java Message Service
JMS Java Message Service TK3 WS02/03 Dipl.-Ing. Erwin Aitenbichler Abt. Telekooperation TU Darmstadt 1 JMS: Java Message Service Messaging Lose gekoppelte verteilte Kommunikation RMI: Eng gekoppelt Sender
MehrRechnernetze Übung 11
Rechnernetze Übung 11 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Herr Müller (Test GmbH) Sekretärin (Super AG) T-NR. 111 T-NR. 885 Sekretärin (Test GmbH) Herr Meier (Super
MehrWeb Services. Web Services in the News. Vision: Web of Services. Learning for Results. DECUS Symposium 2002, Vortrag 1K07,
Web Services Vision: Web of Services Applikationen und Services Ralf Günther Compaq Computer GmbH, Köln Ralf.Guenther@compaq.com DECUS Symposium 2002, Vortrag 1K07, 16.04.2002 Web Services in the News
Mehr= Smart Enterprise Application Integration
+ = Smart Enterprise Application Integration Ziel dieses Vortrags Bullet Point Boot Camp Nur wenige Folien... 14.06.2011 Seite 2 Ziel dieses Vortrags... dafür jede Menge Live-Demos!!! 14.06.2011 Seite
MehrVerteilte Systeme - 1. Übung
Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)
MehrSoftwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert
Softwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert Partly based on material by Victor García Barrios and Paul Krzyzanowski
MehrBusiness Process Management und Enterprise Service Bus
Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?
MehrUNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Remote Method Invocation Teil 3 RMI over IIOP
UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Remote Method Invocation Teil 3 RMI over IIOP el0100 copyright Abt. Technische Informatik,
Mehr.NET Networking 1. Proseminar Objektorientiertes Programmieren mit.net und C# Matthias Jaros. Institut für Informatik Software & Systems Engineering
.NET Networking 1 Proseminar Objektorientiertes Programmieren mit.net und C# Matthias Jaros Institut für Informatik Software & Systems Engineering Agenda Motivation Protokolle Sockets Anwendung in.net
MehrEinführung: Verteilte Systeme - Remote Method Invocation -
Einführung: Verteilte Systeme - - Prof. Dr. Michael Cebulla 11. Dezember 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 43 M. Cebulla Verteilte Systeme Gliederung 1 2 Architektur RMI Kommunikation
MehrEinführung in parallele Dateisysteme am Beispiel von GPFS. Proseminar von Jakob Schmid im SS 2014
Einführung in parallele Dateisysteme am Beispiel von GPFS Proseminar von Jakob Schmid im SS 2014 Gliederung Definition Anwendungsgebiete Anforderungen Beispiel: General Parallel File System (GPFS) Zusammenfassung
MehrThesis Outline. Erstellung eines universellen Konzepts zur Kommunikation auf mobilen Geräten mit Hilfe von Positionsbestimmung.
Thesis Outline Erstellung eines universellen Konzepts zur Kommunikation auf mobilen Geräten mit Hilfe von Positionsbestimmung. von Thomas Steinberg am 09.12.2005 Übersicht Einleitung Motivation Mehrwert
MehrRechnernetze Übung 11. Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2012
Rechnernetze Übung 11 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2012 IP: 192.168.43.9 MAC: 02-55-4A-89-4F-47 IP: 216.187.69.51 MAC: 08-48-5B-77-56-21 1 2 IP: 192.168.43.15 MAC:
MehrEntwicklung von Web-Anwendungen auf JAVA EE Basis
Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages
MehrJabber-Comets-Integration
FU Berlin - Institut für Informatik SoSe 2003 Internet Learning Dozenten: Klaus-Dieter Graf Marco Rademacher Referent: Stefan Gerber 1. Jabber-Protokoll 2. Comets-Protokoll 3. Jabber und Comets - Ein gutes
MehrWissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider
Wissenschaftliche Vertiefung Web Services Esslingen, 22. Januar 2016 Agenda 1. Einführung 2. Serviceorientierte Architektur 3. SOAP Web Service 4. Standards und Protokolle von SOAP Web Services 5. Bewertung
MehrWeb Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1
Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web
MehrAlternative Architekturkonzepte
Alternative Architekturkonzepte Motivation: Suche nach einer Gesamtstruktur meistens: dominante nichtfunktionale Eigenschaften legen Architektur fest Antrieb: Architekturziel Ziel: globale Betrachtung
MehrMobilkommunikationsnetze - TCP/IP (und andere)-
- TCP/IP (und andere)- Vorlesung Inhalt Überblick ISO/OSI vs. TCP/IP Schichten in TCP/IP Link Layer (Netzzugang) Network Layer (Vermittlung) Transport Layer (Transport) Application Layer (Anwendung) Page
MehrMicrosoft.NET XML-Webdienste Schritt für Schritt
Adam Freeman Allen Jones Microsoft.NET XML-Webdienste Schritt für Schritt Microsoft Press Teil A Kapitel 1 Einführung Warum haben wir dieses Buch geschrieben? Wer sollte dieses Buch lesen? Der Aufbau dieses
MehrEnterprise Middleware mit ActiveMQ
ITMAGAZINE Enterprise Middleware mit ActiveMQ 17. August 2007 - Nachrichtenorientierte Middleware ist die Basistechnologie moderner Enterprise-Architekturen, die die Implementierung von Enterprise Integration
MehrARP, ICMP, ping. Jörn Stuphorn Bielefeld, den 4. Mai Mai Universität Bielefeld Technische Fakultät
ARP, ICMP, ping Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät TCP/IP Data Link Layer Aufgabe: Zuverlässige Übertragung von Rahmen über Verbindung Funktionen: Synchronisation,
MehrWorkflow, 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
MehrUnternehmensdokumente mit dem XML Publisher erzeugen
Unternehmensdokumente mit dem XML Publisher erzeugen Jürgen Menge TSBU Middleware ORACLE Deutschland GmbH XML-Publisher Moderne Lösung zur Entwicklung und Verteilung von Geschäftsdokumenten (Output Management)
MehrDevice Management Schnittstellen. Referat von Peter Voser Embedded Development GmbH
Device Management Schnittstellen Referat von Peter Voser Embedded Development GmbH Device Management ist Gerätesteuerung Parametrisierung Zugang zu internen Messgrössen und Zuständen Software Upgrade www.embedded-development.ch
MehrInstallationsführer für den SIP Video Client X-Lite
Installationsführer für den SIP Video Client X-Lite Stand: 12.04.2010 1. Einleitung Dieses Dokument beschreibt die Vorgehensweise für den Download, die Installation und Inbetriebnahme eines SIP Videoclients
MehrEnterprise JavaBeans (mit JBoss)
Enterprise JavaBeans (mit JBoss) Christian Hülsmeier 30.10.2004 Überblick Rekapitulation des vorhandenen Wissen Entity-Beans Session-Beans Deployment-Deskriptor Sichten / Client-Anwendungen Applikationsserver
MehrTechnische Informatik II FS 2008
Institut für Technische Informatik und Kommunikationsnetze Prof. Bernhard Plattner, Fachgruppe Kommunikationssysteme Technische Informatik II FS 2008 Übung 5: Kommunikationsprotokolle Hinweis: Weitere
MehrOracle SOA Suite: Total Quality T-Systems
Oracle SOA Suite: Total Quality Monitoring @ T-Systems Arnd Scharpegge, Lynx-Consulting GmbH Andreas Makiola, T-Systems International GmbH Agenda Ziele des Total Quality Monitorings Vorgaben für das Total
Mehr5. Programmierschnittstellen für XML
5. Programmierschnittstellen für für Medientechnologen Dr. E. Schön Wintersemester 2015/16 Seite 146 Notwendigkeit: Programmierschnittstelle Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen
MehrWeb Services and Semantic Web
Web Services and Semantic Web XML, Web Services and the Data Revolution von Suat Sayar Inhalt Motivation: neues Paradigma XML,Microsoft und Sun Verteilte Systeme Erweiterungen des Unternehmensnetzes XML
MehrWiederholung: 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
MehrBetriebssysteme Kap. 5: Netzwerkmanagement
Betriebssysteme Kap. 5: Netzwerkmanagement Winfried E. Kühnhauser Wintersemester 2016/17 Winfried E. Kühnhauser CSI Technische Universität Ilmenau www.tu-ilmenau.de Betriebssysteme, WS 2016/17 wk - 1 -
MehrSitepark Information Enterprise Server - die Technologie-Plattform von Sitepark
Sitepark Information Enterprise Server - die Technologie-Plattform von Sitepark Der IES ermöglicht die Entwicklung von Produkten auf einer einheitlichen Basis und stellt unter anderem ein produktübergreifendes
MehrÜbungsblatt 4. (Router, Layer-3-Switch, Gateway) Aufgabe 2 (Kollisionsdomäne, Broadcast- Domäne)
Übungsblatt 4 Aufgabe 1 (Router, Layer-3-Switch, Gateway) 1. Welchen Zweck haben Router in Computernetzen? (Erklären Sie auch den Unterschied zu Layer-3-Switches.) 2. Welchen Zweck haben Layer-3-Switches
Mehr<Insert Picture Here> Web-2.0-Anwendungen mit MySQL
Web-2.0-Anwendungen mit MySQL Ralf Gebhardt Principal Sales Consultant MySQL Agenda Die Definition von Web-2.0 Web-2.0-Architektur MySQL als Datenbankschicht Teil 1 MySQL Replikation
MehrProtokolle und Schichten. Grundlagen der Rechnernetze Einführung 41
Protokolle und Schichten Grundlagen der Rechnernetze Einführung 41 Protokoll und Interface Host 1 Host 2 High Level Objekt High Level Objekt Service Interface Service Interface Protokoll Peer to peer Interface
MehrÜbungsblatt 4. (Router, Layer-3-Switch, Gateway) Aufgabe 2 (Kollisionsdomäne, Broadcast- Domäne)
Übungsblatt 4 Aufgabe 1 (Router, Layer-3-Switch, Gateway) 1. Welchen Zweck haben Router in Computernetzen? (Erklären Sie auch den Unterschied zu Layer-3-Switches.) 2. Welchen Zweck haben Layer-3-Switches
MehrInternetanwendungstechnik. TCP/IP- und OSI-Referenzmodell. Gero Mühl
Internetanwendungstechnik TCP/IP- und OSI-Referenzmodell Gero Mühl Technische Universität Berlin Fakultät IV Elektrotechnik und Informatik Kommunikations- und Betriebssysteme (KBS) Einsteinufer 17, Sekr.
MehrNetzwerk-Programmierung. Netzwerke. Alexander Sczyrba Michael Beckstette.
Netzwerk-Programmierung Netzwerke Alexander Sczyrba Michael Beckstette {asczyrba,mbeckste}@techfak.uni-bielefeld.de 1 Übersicht Netzwerk-Protokolle Protkollfamilie TCP/IP Transmission Control Protocol
MehrOffice 365 Dynamics 365 Azure Cortana Intelligence. Enterprise Mobility + Security Operations Mgmt. + Security
Office 365 Dynamics 365 Azure Cortana Intelligence Enterprise Mobility + Security Operations Mgmt. + Security API Application Availability Bottomless Storage Identity Management Full hybrid
MehrSOA Blueprint. Ordnung im SOA Werkzeugkasten. Tobias Krämer OPITZ CONSULTING München GmbH
SOA Blueprint Ordnung im SOA Werkzeugkasten Tobias Krämer OPITZ CONSULTING München GmbH München, 25.02.2010 OPITZ CONSULTING GmbH 2010 Seite 1 Agenda 1. Was beinhaltet das Thema SOA? 2. Eigenschaften einer
MehrSeminar Internet Dienste. Webservices
Universität Ulm Seminar Internet Dienste Webservices Matthias Kirchmayr, SS 2003 Inhaltsverzeichnis 1 Motivation 1 2 Definition 1 3 XML & Co. 3 3.1 XML - extensible Markup Language.................. 3
MehrMessage Queuing Systems
1 Message Queuing Systems Andreas Haller Institut für Telematik, Universität zu Lübeck Ratzeburger Allee 160, 23538 Lübeck, Germany Email: andreas.haller@informatik.uni-luebeck.de Zusammenfassung Message
MehrNeuer Funkrufmaster: DAPNET Folien: Daniel Sialkowski. UKW Weinheim 2016 Dipl.-Ing. Ralf Wilke, Daniel Sialkowski, B.Sc.
Neuer Funkrufmaster: DAPNET Folien: Daniel Sialkowski UKW Weinheim 2016 Dipl.-Ing. Ralf Wilke, Daniel Sialkowski, B.Sc. 08.06.2016 Inhalt ) I. Einführung: Paging-Sendernetzwerke Vergleich mit Mobilfunknetzen
MehrZugriffskontrollmechanismen. Rechteverwaltung. und. Gonsu Veronique
Rechteverwaltung und Zugriffskontrollmechanismen Gonsu Veronique Überblick! Zugriffskontrolle! Acces Control List! Problemen mit Acces Control List! Capabilities! Capabilities-basierte Systemen! EROS!
MehrTechnische Richtlinie XML-Datenaustauschformat für hoheitliche Dokumente (TR XhD) 1 Rahmenwerk
Technische Richtlinie XML-Datenaustauschformat für hoheitliche Dokumente (TR XhD) 1 Rahmenwerk Version 1.4 18.11.2013 BSI TR-03123-1 Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63
MehrDBUS Interprozess-Kommunikation für Embedded-Plattformen
DBUS Interprozess-Kommunikation für Embedded-Plattformen Andreas Schwarz Neratec Solutions AG Firmenprofil Neratec Solutions AG Produkt-Entwicklungen für kundenspezifische elektronische Produkte Produkte
MehrBetriebssysteme Kap. 5: Netzwerkmanagement
Betriebssysteme Kap. 5: Netzwerkmanagement Winfried E. Kühnhauser Wintersemester 2017/18 Winfried E. Kühnhauser CSI Technische Universität Ilmenau www.tu-ilmenau.de Betriebssysteme, WS 2017/18 wk - 1 -
MehrÜbertragungswege Gateway - OFTP1 Migration
Übertragungswege Gateway - OFTP1 Migration Basware Corporation Copyright Basware Corporation All rights reserved Inhalt 1 Anmerkung zur Abschaltung von ISDN... 4 2 Übertragungsweg AS2... 5 2.1. Dokumente
Mehrgefördert. Bearbeiter:
Webservices for Devices als Integrationsplattform für intelligente Dienste der Gebäudetechnik Kurzbericht Der Forschungsbericht wurde mit Mitteln der Forschungsinitiative Zukunft Bau des Bundesinstitutes
MehrGoogle Gears Offline Web?
Google Gears ist eine Browsererweiterung, die es in sich hat. Dem Webanwendungsentwickler werden Dienste bereitgestellt, die es ermöglichen, Webanwendungen so zu schreiben, dass eine Offline-Arbeit möglich
MehrErläuterungen zu Darstellung des DLQ-Datenportals
Erläuterungen zu Darstellung des DLQ-Datenportals Definition zum Datenportal Das DLQ-Datenportal (DP) definiert fachliche Schnittstellen für den Datenaustausch zwischen verschiedenen Kommunikationspartnern.
MehrHochschule Prof. Dr. Martin Leischner Bonn-Rhein-Sieg Netzwerksysteme und TK Modul 7: SNMPv3 Netzmanagement Folie 1
Modul 7: SNMPv3 M. Leischner Netzmanagement Folie 1 SNMP-Versionen Party-Based SNMP Version 2 (SNMPv2p) User-Based SNMP Version 2 (SNMPv2u) SNMP Version 3 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997
MehrSODA. Die Datenbank als Document Store. Rainer Willems. Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG
SODA Die Datenbank als Document Store Rainer Willems Master Principal Sales Consultant Oracle Deutschland B.V. & Co. KG vs No Anforderungskonflikte Agile Entwicklung Häufige Schema-Änderungen Relationales
MehrFAQ 12/2015. PROFINET IO- Kommunikation. https://support.industry.siemens.com/cs/ww/de/view/
FAQ 12/2015 PROFINET IO- Kommunikation https://support.industry.siemens.com/cs/ww/de/view/109479139 Dieser Beitrag stammt aus dem Siemens Industry Online Support. Es gelten die dort genannten Nutzungsbedingungen
MehrWildFly Application Server Administration
WildFly Application Server Administration Seminarunterlage Version: 1.04 Version 1.04 vom 18. Januar 2017 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen
MehrBetriebssysteme Kap. 5: Netzwerkmanagement
Betriebssysteme, WS 2018/19 wk - 1 - Betriebssysteme Kap. 5: Netzwerkmanagement Winfried E. Kühnhauser Wintersemester 2018/19 Winfried E. Kühnhauser CSI Technische Universität Ilmenau www.tu-ilmenau.de
MehrInstant Messaging mit XMPP
Instant Messaging mit XMPP Norbert Tretkowski Email: norbert@tretkowski.de XMPP: norbert@tretkowski.de Linux User Schwabach 07. April 2016 Agenda Grundlagen Features Clients Erweiterungen Sicherheit Messenger
MehrClient/Server-Programmierung
Client/Server-Programmierung WS 2017/2018 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 12. Januar 2018 Betriebssysteme / verteilte
MehrGrundkurs Datenkommunikation
Peter Mandl Andreas Bakomenko Johannes Weiß Grundkurs Datenkommunikation TCP/IP-basierte Kommunikation: Grundlagen, Konzepte und Standards 2., überarbeitete und aktualisierte Auflage Mit 256 Abbildungen
MehrGrundlagen Internet-Technologien INF3171
Fachbereich Informatik Informationsdienste Grundlagen Internet-Technologien INF3171 Cookies & Sessions Version 1.0 20.06.2016 aktuelles 2 Erweiterungen wir betrachten zwei Erweiterungen: Personalisierung
Mehr