Diplomarbeit Vernetzung dezentraler Mikro-Blogging-Systeme - Konzeption und prototypische Implementierung am Beispiel Communote -

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit Vernetzung dezentraler Mikro-Blogging-Systeme - Konzeption und prototypische Implementierung am Beispiel Communote -"

Transkript

1 Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Lehrstuhl Rechnernetze Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Communardo Software GmbH Dresden Kleiststraße 10a Dresden Diplomarbeit Vernetzung dezentraler Mikro-Blogging-Systeme - Konzeption und prototypische Implementierung am Beispiel Communote - zum Erlangen des akademischen Grades Diplomingenieur für Informationssystemtechnik Eingereicht von: Verantwortlicher Hochschullehrer: Betreuer TU Dresden: Betreuer Communardo: Adrian Mörchen Matrikelnummer Geboren am 04. August 1983 in Stralsund Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Dipl.-Inf. Marius Feldmann Dipl. Wirt.-Inf. Dirk Röhrborn Dipl.-Inf. Torsten Lunze Eingereicht am: 15. Oktober 2009

2

3

4

5 INHALTSVERZEICHNIS 1 Einleitung 1 2 Anforderungen Anwendungsfälle am Beispiel Schritt 1: Initialisierung Schritt 2: Kommunikation Schritt 3: Projektabschluss Anforderungen Features Austauschformat Kommunikationskanäle Sicherheit Datenhaltung Grundlagen Mikro-Blogging Twitter Identi.ca und Laconica Yammer Communote i

6 3.1.5 Zusammenfassung Kommunikationskanäle Hypertext Transfer Protocol (HTTP) Simple Mail Transfer Protocol (SMTP) Extensible Messaging and Presence Protocol (XMPP) Zusammenfassung Bestehende Ansätze und Technologien OpenMicroBlogging-Protokoll (OMB) Birds of a FETHR Google Wave Federation Protocol XML-basierte Nachrichtenverteilung Zusammenfassung Konzept und Entwurf Architekturentwurf Nachrichtenverteiler und Transports Komponentenbasierte Aufteilung Methoden Einladen und Einladung annehmen Nachrichten schreiben, ändern und löschen Nutzer benachrichtigen Kooperation auflösen Richtlinien Das Datenmodell Frontend REST über HTTP Signierung von Anfragen und Antworten Verschlüsselung der Übertragung ApiCalls für API-Aufrufe ii Inhaltsverzeichnis

7 4.7 Communote-Spezifika Anpassung des Datenmodells Änderungen erscheinen im Blog Implementierung Komponentenbasierte Aufteilung Die SharedBlogsApi Das Communote SharedBlogsApi-Plug-In Integration in die Communote-Plattform Frontend-Widgets Ressourcen Weitere Details Evaluierung Tests Modultests Performancetests Nutzereindruck Erfüllung der Anforderungen Features Austauschformat Übertragungsprotokoll Sicherheit Datenhaltung Zusammenfassung Zusammenfassung und Ausblick Zusammenfassung Ausblick Erweiterung der Implementierung Inhaltsverzeichnis iii

8 7.2.2 Modularisierung mittels OSGi und Equinox REST-Anwendung mittels EMF beschreiben Google Wave A Anhang 81 A.1 Ecore-Modell der SharedBlogsApi-Ressourcen A.2 Ressourcen-URLs A.3 Screenshots A.4 Fundamental Modeling Concept A.5 Sonstige B Begriffe und Abkürzungen 101 iv Inhaltsverzeichnis

9 1 EINLEITUNG Weniger ist mehr. Dieser Ausspruch trifft in gewisser Weise auch auf Mikro-Blogs zu. Trotz hoher Preise 1 ist SMS eines der meist genutzten Kommunikationsmittel. Jede SMS besteht aus maximal 160 Zeichen, das Versenden ist mit jedem Mobiltelefon und vielen Festnetztelefonen möglich. SMS können unauffällig während Meetings gelesen und geschrieben werden und wirken auch in der Straßenbahn nicht so störend wie ein Telefonat. Twitter hat das System der Kurznachrichten erfolgreich ins Internet portiert. Mit 140 Zeichen beschreiben Menschen ihre aktuelle Aufgabe oder halten ihre Freunde und Verwandte auf dem Laufenden. Der derzeitige Präsident der USA - Barack Obama - nutzte SMS und Twitter als moderne Kommunikationsplattformen für seinen Wahlkampf. In jüngster Zeit entdecken auch immer mehr Unternehmen diese Art der Kommunikation als Alternative oder Ergänzung bestehender Lösungen 2. Durch die Einfachheit können wichtige Themen schneller verbreitet und Fragen schneller beantwortet werden. Kommunikationshürden zwischen verschiedenen Fachbereichen und Führungsebenen können leichter überbrückt und Ideen fächerübergreifend diskutiert werden. Communote ist eines der Systeme, welches sich speziell an Unternehmen oder akademische Einrichtungen richtet. Jedes Unternehmen besitzt dabei ein in sich geschlossenes Mikro-Blogging-System mit Nutzern, Blogs und Beiträgen. Diese geschlossenen System stoßen in der Praxis jedoch oft an ihre Grenzen, da unterschiedliche Unternehmen immer mehr an gemeinsamen Projekten arbeiten müssen. Ziel dieser Arbeit ist es eine Möglichkeit zu schaffen, die Mikro-Blogging-Systeme verschiedener Firmen miteinander zu verknüpfen, um so gemeinsame, heterogene Arbeitsbereiche zu schaffen. Die Problematik ist hierbei vor allem, dass bestehende Systeme dabei selten oder gar nicht auf die speziellen Bedürfnisse von Unternehmen eingehen. Unternehmen benötigen Mechanismen, um ihre Informationen partiell 3 und sicher, für beispielsweise freie Mitarbeiter oder beauftragte dritte Firmen freigeben zu können. Dieser, vom Unternehmensnetzwerk unabhängige Mechanismus, wird benötigt, da unternehmensweite Richtlinien den direkten Zugriff auf das firmeneigene Netzwerk für Dritte oft nicht erlauben. 1 Zumindest in Deutschland kostet die Übertragung von 1MB Daten in Mobilfunktarifen immer noch mehr als 1000 Euro. Eine SMS benötigt etwa 140 Byte Bandbreite. Mit aktuellen Preisen für eine SMS lässt es sich leicht nachrechnen, z.b. ((1MB)/ (140Byte)) 19Cent 1423Euro. 2 Auch Twitter wurde ursprünglich für die Kommunikation innerhalb der Firma entwickelt. 3 In dieser Arbeit werden Blogs innerhalb eines Mikro-Blogging-Systems als Medium partieller Informationen betrachtet, die freigegeben werden sollen. 1

10 KERNFRAGEN Die folgenden Fragestellungen dienen der Eingrenzung des Themas und geben einen Überblick der zu erreichenden Ziele. 1. Welche Anforderungen muss ein transparentes Austauschformat eines Mikro-Blogs besitzen? Gibt es solch ein Format bereits und inwieweit ist es für die Erreichung der Ziele geeignet? 2. Wie sieht eine Architektur aus, um ein möglichst unverzügliches Verteilen der Informationen zu gewährleisten? Welche Sicherheitsanforderungen sind notwendig und wie werden diese von bestehenden Lösungen unterstützt? 3. Lässt sich eine technische Lösung finden, welche leicht auf unterschiedliche Systeme portiert werden kann? AUFBAU DER ARBEIT Ziel dieser Arbeit ist es einen Lösungsvorschlag zu entwickeln, der es erlaubt auf Basis von Blogs eines Mikro-Blogging-Systems Informationen zwischen verschiedenen unabhängigen Instanzen dieser Systeme auszutauschen. Am Beispiel der Communote-Plattform soll dieser Vorschlag prototypisch realisiert und verifiziert werden. Ziel ist es mehrere Communote-Instanzen technisch miteinander zu verknüpfen. Dazu werden in Kapitel 2.1 typische Abläufe anhand eines Beispiels gezeigt. Zur Verfeinerung der Problemstellung werden in Kapitel 2.2 Anforderungen identifiziert. Einen Überblick über Grundlagen und bestehende Ansätze gibt Kapitel 3. Kapitel 4 zeigt das Konzept, auf dessen Grundlage der Entwurf für die prototypische Implementierung (ebenfalls Kapitel 4) basiert. Die Implementierung selbst wird in Kapitel 5 besprochen. Eine Auswertung der Ergebnisse findet in Kapitel 6 statt. Das letzte Kapitel 7 enthält eine Zusammenfassung und Bewertung der Arbeit, sowie einen Ausblick für fortführende Arbeiten und mögliche Weiterentwicklungen. 2 Kapitel 1 Einleitung

11 2 ANFORDERUNGEN 2.1 ANWENDUNGSFÄLLE AM BEISPIEL Anhand eines fiktiven Projekts mit mehreren Partnern sollen Arbeitsweise und Funktionsumfang der Lösung gezeigt werden. Dazu werden mehrere Anwendungsfälle innerhalb des Projekts beschrieben. Das Projekt dient nicht nur dem besseren Verständnis der Problemstellung, sondern auch als Basis für die Anforderungen in Kapitel 2.2. Die Art des Projekts spielt keine Rolle, wichtig ist lediglich, dass es verschiedene Partner mit getrennten Mikro-Blogging-Systemen gibt. Solche Partner können beispielsweise Forschungseinrichtungen, staatliche Kontrollbehörden, Unternehmen verschiedenster Größen und Industrien, aber auch freie Mitarbeiter sein. Neben Projektwikis, Bugtracker und Groupware sollen Mikro-Blogging-Systeme für den schnellen und unkomplizierten Informationsaustausch genutzt werden. Die Firmen und Organisationen in den Beispielen sind frei erfunden und besitzen möglichst einfache und generische Namen Schritt 1: Initialisierung Nach dem Projektstart richtet ein Mitarbeiter der Firma A im firmeneigenen Mikro-Blogging- System 1 verschiedene Blogs für das Projekt ein, z.b. Release Notes, Terminabsprache oder Brainstorming. Für die Freigabe der Blogs benötigt er lediglich eine -Adresse der anderen Partner. Bereits aus anderen Projekten kennt er die Mitarbeiter der Universität B und weiß wer dort verantwortlicher Projektleiter ist. Er erstellt auf den zuvor genannten Blogs eine Freigabe und gibt als Partner die -Adresse des Projektleiters der Universität B an. Dieser bekommt daraufhin via eine Einladung zur Teilnahme an der Kooperation geschickt. Mit Hilfe der Nachricht kann der Mitarbeiter der Universität B die Einladung im eigenen System annehmen. Nach erfolgreicher Annahme der Einladungs sind die Blogs ebenfalls im System der Universität B verfügbar und können wie eigene Blogs verwaltet und genutzt werden. Es entsteht ein System wie in Abbildung 2.1(a). Diese Art der Verbindung wird im folgenden Kooperation genannt. Nach weiteren Einladungen zwischen den Partnern kann ein Kooperationsnetz ähnlich Abbildung 2.1(b) entstehen. Partner können über beliebige Verbindungen zwischen den Systemen miteinander kooperierenden. Dreiecksbeziehungen, wie zwischen Mikro-Blog 2, 3 und 4, werden ebenfalls berücksichtigt und Nachrichten erscheinen nicht doppelt in einem Blog. 1 Im Folgenden wird für Mikro-Blogging-System der Ausdruck System gleichbedeutend verwendet. 3

12 (a) Struktur des Systems nach der Initialisierung mit Firma A und Universität B (b) Mögliche Kooperationsstruktur mit 5 Partnern Abbildung 2.1: Kooperationsstruktur des Projekts nach der Initialisierung 4 Kapitel 2 Anforderungen

13 Abbildung 2.2: Zentralisiertes Kooperationsnetzwerk Schritt 2: Kommunikation Bereits in den ersten Tagen nach Projektstart tauschen die Mitarbeiter ihre Ideen aus und es entstehen neue Nachrichten in den Blogs. Zur Ideenkonsolidierung schlägt einer der Projektleiter einen Termin für eine Videokonferenz noch am gleichen Abend im Blog Terminabsprache vor. Zur Vorbereitung der Teilnehmer erstellt er eine Mindmap mit den bereits vorhandenen Vorschlägen und hängt sie als binären Anhang an seinen Blogbeitrag an. Das Mikro-Blogging-System versucht den Beitrag so schnell wie möglich an alle beteiligten Kooperationen zu verteilen, um allen Partnern die Information rechtzeitig zukommen zu lassen. Während des Termins wird bekannt, dass noch nicht alle Partner eine Kooperation eingegangen oder einer Einladung gefolgt sind. Im Laufe der nächsten Tage werden auch die Systeme der fehlenden Partner integriert. Die bereits bestehenden Beiträge werden zwischen den Systemen synchronisiert, so dass auch später hinzugekommene Partner auf ältere Informationen zugreifen können. Während des gesamten Projektzyklus kommen neue Partner hinzu und andere verlassen das Projekt wieder. Teilabschnitte sind abgeschlossen und Blogs damit unnötig, sie können archiviert werden. Neue Teilabschnitte beginnen und neue Blogs werden eingerichtet. Richtlinien zur Handhabung von Blogs Während des Projektverlaufs kommt es zu einem kritischen Vorfall. Ein Projektteilnehmer hat einen Projektblog einem seiner Partner freigegeben, der nicht am Projekt beteiligt war. Der Blog enthielt sensible Daten, welche nicht für die Weitergabe bestimmt waren. Über Umwege gelangten einige der Informationen zurück zur Projektorganisation. Daraufhin wurde beschlossen, dass die Vertrauensbasis der losen Kopplung nicht ausreicht und die Blogs nur mit Einschränkungen freigegeben werden dürfen. Die Richtlinien der freigegebenen Blogs wurden so geändert, dass dem Partner sofort ersichtlich wird, dass der Blog nicht erneut freigeben werden darf. Die verwendeten Systeme können die Richtlinie ebenfalls interpretieren und verhindern ein erneutes 2.1 Anwendungsfälle am Beispiel 5

14 Freigeben automatisch. Dadurch hat sich das Kooperationsnetz von einem dezentralisierten Netz zu einem zentralisierten Netz, wie in Abbildung 2.2 dargestellt, geändert. Die gesamte Kommunikation läuft nun über ein System. Publizierte Kooperation Die dargestellten Kooperationen nach der Initialisierung in Abbildung 2.1(b) zeigen auch gleichzeitig die Kommunikationswege (vgl. Abb. 2.3a). Eine Kooperation zwischen den Systemen 1, 4 und 5 über das System 5 bedeutet, dass Nachrichten aus System 1 erst zu System 5 gelangen und von dort zu System 4 weitergeleitet werden. System 5 hat die Kooperation erstellt und somit obliegt ihm auch die Verteilung der Nachrichten an die beteiligten Partner. Als Alternative zu dieser Art kann eine publizierte Kooperation erzeugt werden. Bei dieser Art der Kooperation werden allen Projektpartnern die Kooperationspartner mitgeteilt. Ein Vorteil dieser Methode ist, dass die Systeme direkt miteinander kommunizieren können ohne einen zusätzlichen Umweg nehmen zu müssen. Die Kommunikationswege sind in Abbildung 2.3b dargestellt. Gewollte oder ungewollte Einschränkungen in den Kommunikationswegen können dazu führen, dass nicht jedes System von allen anderen Systemen direkt erreichbar ist. Beispielsweise könnte eines der Systeme hinter einer Firewall stehen und lediglich mit Systemen bestimmter Adressräume kommunizieren dürfen. Durch eine hybride Lösung, bei welcher die Erreichbarkeit und Pfade der Systeme bekannt sind, kann diesem Problem entgegengewirkt werden. Abbildung 2.3: Kommunikationswege bei Kooperationen ohne (a) und mit (b) bekannten Projektpartnern Schritt 3: Projektabschluss Nach Abschluss des Projekts sollen die bestehenden Kooperationen beendet werden. Dazu muss von einem berechtigten Mitarbeiter eines der Unternehmen die Kooperation innerhalb des eigenen Systems gekündigt werden. Beteiligte Systeme werden über die Kündigung automatisch benachrichtigt, lösen die Kooperation bei sich ebenfalls auf und informieren die Mitarbeiter mit einem entsprechenden Blogbeitrag darüber. Wurden zuvor Richtlinien festgelegt, die z. B. ein Löschen aller Nachrichten bei Kündigung erfordern, werden diese jetzt automatisch ausgeführt. Ab diesem Zeitpunkt werden keine Nachrichten mehr zwischen den Systemen ausgetauscht. 6 Kapitel 2 Anforderungen

15 2.2 ANFORDERUNGEN In diesem Kapitel werden Anforderungen zur Lösung der Aufgabe formuliert. Die Anforderungen ergeben sich aus dem zuvor beschriebenen Beispiel, Unternehmensanforderungen von Communardo, die ein solches System nutzen würden, sowie daraus, dass das Web den Kontext der Aufgabe bildet Features Folgende Funktionen soll die Lösung bereitstellen: Blogs freigeben: Die Blog-Freigabe sollte möglichst einfach sein, dazu zählt auch das Einbinden freigegebener Blogs. Durch ein Einladen-Annehmen-Prinzip sollen die Nutzer dabei unterstützt werden und nicht auf technische Details achten müssen. Um das Prinzip unterstützen zu können muss jedes System eine eindeutige Adresse haben. Unverzügliche Auslieferung: Nachrichten sollen möglichst sofort ausgeliefert werden, daher ist ein Push-Verfahren notwendig. Synchronisation eingebundener Blogs: Alle Beiträge eines Blogs sollen verfügbar sein. Genauso sollen geänderte und gelöschte Beiträge synchronisiert werden. Zur Unterstützung nachträglicher Synchronisation von Beiträge ist ein Pull-Prinzip notwendig. Globale Eindeutigkeit: Blogs, Beiträge und Nutzer sollen global eindeutig identifizierbar sein. Das dient vor allem zur Unterstützung von Dreiecks-Beziehungen mit gleichen Freigaben. Um von der Kennung nicht auf das Ursprungssystem schließen zu können, ist es nötig sie als Hash oder anderes eindeutiges Merkmal zur Verfügung zu stellen Austauschformat Zur Wahrung der Transparenz ist es wichtig ein einheitliches Format zur Beschreibung von Blogs, Inhalten und Nutzerdaten zu verwenden. Das Austauschformat zeichnet sich durch folgende Punkte aus: Es ist wohlgeformt 2 und enthält alle relevanten Informationen zur Übertragung von Inhalten und ist unabhängig von der verwendeten Übertragungstechnik Kommunikationskanäle Zur Übertragung der benötigten Informationen auf Anwendungsebene gibt es verschiedene Möglichkeiten. Der verfügbare Kanal muss so gewählt werden, dass er auf möglichst vielen Plattformen zur Verfügung steht, modernen Standards oder de facto Standards entspricht, 2 Im Sinne von XML: 2.2 Anforderungen 7

16 eventuell bereits eigene Sicherheitsmechanismen zur Verfügung stellt (z. B. Kanalverschlüsselung) und vorhandene Bibliotheken zur Realisierung verfügbar sind. Solche Kanäle sind z. B. FTP/SFTP, SMTP, XMPP/Jabber, HTTP/S, SOAP/HTTP oder REST/HTTP Sicherheit Authentifizierung Zur Synchronisation beteiligter Systeme ist es nötig, dass diese sich gegenseitig authentifizieren. Autorisierung Die Autorisierung des Systems erfolgt durch den Blog Manager 4 indem er ein anderes System zur Teilnahme einlädt. Zusätzlich kann ein Client Manager 5 bestimmen, ob Kooperationen mit einem bestimmten Endpunkt durch einen Client Manager bestätigt werden müssen. Verschlüsselung Üblicherweise werden Daten während der Kommunikation im Internet über etliche Zwischenstationen geleitet, bevor sie ihr Ziel erreichen. Diese Zwischenstationen sind nicht per se vertrauenswürdig. Um ein Auslesen der Nutzdaten zu erschweren, sollte es möglich sein die serialisierten Daten zu verschlüsseln (Ende-zu-Ende-Verschlüsselung). Dadurch wäre auch eine Übertragung ohne Kanalverschlüsselung (vgl. Übertragungsprotokoll 2.2.3) möglich. Richtlinien Jedem Blog können verschiedene Richtlinien zugeordnet werden. Diese Richtlinien werden vom Einladenden an den Eingeladenen übermittelt. Beispiele für diese Richtlinien sind: Dieser Blog darf nur gelesen werden oder Dieser Blog darf nicht erneut freigegeben werden. Nutzerdaten Mit der Freigabe kann ebenfalls entschieden werden, welche Nutzerdaten bereitgestellt werden. Ein Minimum an zu übertragenden Daten ist eine eindeutige Kennung (Id). 3 Für den REST-Architekturstil[23, 24] wird hier besonders der Einsatz der URL als Adresse der Daten und XML als Austauschformat betrachtet. 4 Der Blog Manager darf den Blog verwalten. Genauer siehe Kapitel Der Client Manager verwaltet das Mikro-Blogging-System. Genauer siehe Kapitel Kapitel 2 Anforderungen

17 2.2.5 Datenhaltung Ebenfalls wichtig ist, dass die Daten erhalten bleiben. Hierbei gilt es vor allem den Informationserhalt sicherzustellen. Das umfasst folgende Punkte: Persistenz Kooperationen und damit verbundene Daten sollen nach einem Neustart nicht verloren gehen, sondern wieder zur Verfügung stehen. Fehler während der Übertragung: Es muss sichergestellt werden, dass die Informationen auch am Zielsystem angekommen sind. Nicht-Erreichbarkeit des Zielsystems: Ist das Zielsystem nicht verfügbar sollten die Informationen gespeichert und gegebenenfalls später erneut gesendet werden. 2.2 Anforderungen 9

18 10 Kapitel 2 Anforderungen

19 3 GRUNDLAGEN 3.1 MIKRO-BLOGGING Mit Mikro-Blogging 1 wird das Schreiben kurzer Nachrichten in Blog-ähnlicher Form bezeichnet, d. h. die Nachrichten erscheinen chronologisch geordnet. Der Unterschied zum Bloggen ist, dass die Nachrichten deutlich kürzer sind 2 und keine Medieninhalte, wie Bilder oder Videos, enthalten. Durch diese Einschränkungen wird die Kommunikation deutlich schneller und einfacher. Ziel ist es meist durch kurze Statusmeldungen Freunde und Familie auf dem Laufenden zu halten. Aber auch Firmen nutzen solche Dienste als weiteres Medium zur Informationsverbreitung. Zunächst soll eine Auswahl bekannter Mikro-Blogging-Dienste vorgestellt werden, wobei kein Anspruch auf Vollständigkeit besteht Twitter Twitter 3 gilt als das verbreitetste Mikro-Blogging-System und bildet die Grundlage für viele Nachfolger. Als interner Dienst der Firma Odeo 4 entwickelt, avancierte er schnell zu einem der meistgenutzten Dienste im Netz[15]. Twitter ist eine klassische 1-zu-N-Kommunikation ab, bei der genau ein Nutzer beliebig vielen Nutzern etwas mitteilt. Durch die Möglichkeit anderen Nutzern zu folgen (follow) und sie direkt anzusprechen (notify) entsteht ein riesiges soziales Kommunikationsnetzwerk. Twitter schränkt den Umfang der Nachrichten auf 140 Zeichen reinen Texts ein. Dokumente, Bilder und andere eingebettete Inhalte sind nicht möglich. Über eine Web-API 5 bietet Twitter den Zugriff auf die eigenen Nutzerinformationen an. Der Zugriff erfolgt nach dem REST-Prinzip und ist auf 60 Anfragen pro Minute beschränkt. Die Rückgabe erfolgt wahlweise im JSON- oder XML-Format. 1 Mikro-Blogging, Micro-Blogging oder Microblogging: Eine genaue Schreibweise ist durch den Duden noch nicht festgelegt. Zu Beginn der Arbeit hieß es laut Wikipedia Mikro-Blogging. 2 Oftmals maximal 140 Zeichen. In vielen Systemen ist diese Einschränkung technisch gegeben. 3 Twitter: 4 Odeo (Twitter-Erfinder): 5 Twitter API: 11

20 3.1.2 Identi.ca und Laconica Abbildung 3.1: Account bei Twitter Identi.ca 6 ist eine Plattform ähnlich zu Twitter. Im Gegensatz zu Twitter basiert Identi.ca auf der frei verfügbaren Software Laconica 7 und stellt deren Referenzplattform dar. Die Basisfunktionalitäten sind im wesentlichen die gleichen wie bei Twitter. Da Laconica aber quelloffene Software ist, kann sie angepasst und erweitert werden. Zum programmatischen Zugriff auf die eigenen Daten bietet Laconica ebenfalls eine Web-API 8 an. Die Schnittstelle implementiert die Twitter-API und ist somit mit dieser kompatibel. Eine weitere Möglichkeit ist der Zugriff mittels OpenMicroBlogging-Protokoll (OMB) (siehe Kapitel 3.3.1), welcher es erlaubt Nutzern auf anderen OMB-kompatiblen Systemen zu folgen Yammer Yammer 9 bietet die Twitter-Funktionalität für den Unternehmensbereich an, d. h. Firmen können sich einen separaten Raum zum gemeinsamen Informationsaustausch schaffen. Durch rechtebasierte Gruppen (Groups) lassen sich abgeschlossene Bereiche innerhalb des eigenen Systems schaffen. Nachrichten sind in Yammer nicht auf 140 Zeichen beschränkt. Zusätzliche Formatierungsmöglichkeiten gibt es hier aber auch nicht, dafür erlaubt es Dateianhänge. Über kostenpflichtige Angebote wird das Angebot erweitert, so ist z.b. die Integration eines firmeneigenen LDAPs möglich. Yammer bietet den Zugriff auf die eigenen Daten ebenfalls mit einer Web-API 10 an. Als Datenformate stehen XML und JSON zur Verfügung. Für die Kommunikation mit anderen Unternehmen stellt Yammer aber auch keine Methoden zur Methoden zur Verfügung. 6 Identi.ca: 7 Laconica: 8 Laconica API: 9 Yammer: 10 Yammer API: https://www.yammer.com/company/api/ 12 Kapitel 3 Grundlagen

21 Abbildung 3.2: Communote (Quelle: Communote Communote[19] 11 ist der Mikro-Blogging-Dienst der Communardo Software GmbH 12 in Dresden, der sich vornehmlich an Geschäftskunden richtet. Jeder Kunde besitzt einen eigenen Unternehmensbereich. Diese Bereiche werden im folgenden Client genannt und sind vollkommen unabhängig von anderen Clients. Je nach Konfiguration und Berechtigung können die Nutzer einzelner Clients Blogs lesen, anlegen, verwalten und an Diskussionen teilnehmen. Beiträge können mit Schlagworten und Anhängen versehen werden. Durch den Empfang und das Senden von Beiträgen via und Jabber beschränkt sich der Zugriff nicht nur auf eine Webschnittstelle. Mit Hilfe von Widgets lässt sich Communote ebenfalls in weitere Webanwendungen, z.b. Confluence 13, oder integrieren. Abbildung 3.2 zeigt einen Screenshot von Communote. Auf der linken Seite werden aktuelle Beiträge, sowie ein Eingabefeld für neue Beiträge angezeigt. Ausgewählte und verfügbare Filter werden auf der rechten Seite dargestellt. Zurzeit befindet sich Communote in einer öffentlichen Beta-Phase und kann von jedem frei genutzt werden. Lizenzen sind sowohl für den Online Service, als auch Inhouse-Installationen für Ende 2009 geplant. Für akademische Zwecke ist eine kostenfreie Nutzung geplant. 11 Communote: 12 Communardo Software GmbH: 13 Confluence: 3.1 Mikro-Blogging 13

22 Rollen im Communote Hier sollen die möglichen Rollen der Communote-Nutzer dargestellt werden, da diese für das spätere Verständnis wichtig sind. Folgende Rollen sind im Communote verfügbar: Client Manager: Client Manager verwalten die Anwendung und editieren globale Einstellungen, wie das Firmenlogo. Sie haben z. B. Zugriff auf die Nutzerverwaltung, können Nutzer aktivieren, deaktivieren und löschen. Blog Manager: Legt ein Nutzer einen Blog an, ist er automatisch dessen Blog Manager. Als solcher kann er die Eigenschaften des Blogs bearbeiten, den Blog löschen, globale Leseund Schreibrechte verwalten und weitere Nutzer mit speziellen Rollen im Blog ausstatten. Blog Viewer: Nutzer mit dieser Rolle haben expliziten Lesezugriff auf den Blog. Blog Writer: Zusätzlich zum Lesezugriff dürfen diese Nutzer Beiträge im Blog verfassen. Aufbau und Technologien Da die Implementierung in dieser Arbeit an der Communote-Plattform erfolgt, sollen an dieser Stelle einige technische Daten des Systems genannt werden. Beim Communote handelt es sich um eine mehrschichtige Java Enterprise-Anwendung, welche die typischen Komponenten Frontend, Geschäftslogik und Persistenz zur Verfügung stellt. Der direkte Zugriff des Frontends auf die Entitäten ist nicht möglich, ein ServiceLocator stellt die entsprechenden Service bereit. Zusätzlich zum Frontend wird eine REST-API und eine einfache XMPP-Anbindung zur Verfügung gestellt. Abbildung 3.3 zeigt eine Übersicht der Communote-Architektur. Im Folgenden sind wichtige Technologien, die während der Entwicklung von Communote verwendet wurden und immer noch werden, aufgelistet: Maven wird für das Build-Management eingesetzt. Magic Draw wird verwendet, um Datenstrukturen und wichtige Services als UML-Modelle zu beschreiben, mittels AndroMDA werden daraus Java-Klassen, Hibernate-Mappings und Datenbankskripte generiert. Hibernate wird als Persistenzframework für den Datenbankzugriff verwendet. Apache Tomcat 6.x kommt als Servlet-Container zum Einsatz und das Spring Framework zur Vereinfachung der Entwicklung. Mootools ist ein AJAX-Framework und wird im Frontend genutzt. Die Smack API wird zur Benachrichtigung von Nutzern via XMPP verwendet. 14 Kapitel 3 Grundlagen

23 Abbildung 3.3: Übersicht der Communote-Architektur Zusammenfassung Bis auf Communote sind die vorhandenen Plattformen sehr stark an Twitter angelehnt und greifen das 140-Zeichen- und Follower-Prinzip auf. Twitter und Laconica unterstützen außerdem keine Dateianhänge. Communote erlaubt die Erstellung zugriffsbeschränkter Blogs, bei Yammer heißen diese Bereiche Groups. Twitter, Yammer und Laconica erlauben den Zugriff durch eine Web-API, welche auf dem REST-Prinzip basieren. Die Daten werden im XML- oder JSON-Format bereitgestellt. Communote bietet einen ähnlichen HTTP-basierten Zugriff, welcher, als Ergebnismenge, Objekte im JSON-Format zurück gibt. Die Zugriffsmöglichkeiten der betrachteten Systeme beschränken sich immer auf einen konkreten Nutzer. Der Nutzer hat also die Möglichkeit auf genau seine Daten zuzugreifen. Ziel dieser Arbeit ist es Informationen zwischen verschiedenen Systemen nutzerunabhängig auszutauschen. Das wird bisher von keinem der Systeme unterstützt. 3.2 KOMMUNIKATIONSKANÄLE In diesem Abschnitt sollen mögliche Kommunikationskanäle vorgestellt werden. Alle Kanäle werden zum Nachrichtenaustausch in verteilten, heterogenen Systemen verwendet. Außerdem beruhen sie auf bestehenden Standards, sind in ihrer Anwendung stark verbreitet und unterstützen von sich aus geschützte Verbindungen. Zu jedem Kanal wird eine Aussage 14 zu folgenden Schwerpunkten gemacht (vgl. Tabelle 3.4 am Ende des Kapitels): Standard Gibt Auskunft darüber, ob es sich um einen Standard handelt. Dieser Punkt wird ausschließlich in der Tabelle 3.4 beantwortet. Skalierbarkeit Gibt es Performance-Engpässe? 14 Manche der Schwerpunkte sind so eindeutig, dass sie lediglich in Tabelle 3.4 beantwortet werden. 3.2 Kommunikationskanäle 15

24 Verbreitung Findet die Technologie eine breite Anwendung? Adressierung Art der Adressierung. Verschlüsselung Bietet die Technologie bereits Verschlüsselungsverfahren an? Authentizität Ist die Authentizität der Partner durch die Technologie gewährleistet? Integrität Ist die Integrität der Daten gewährleistet? Verfügbarkeit Welche Möglichkeiten gibt es, um die Verfügbarkeit des Systems zu gewährleisten? Kommunikation Asynchron oder Synchron. Synchrone Kommunikation bedeutet, dass bei einer Anfrage eine unverzügliche Antwort gesendet wird. Bei asynchroner Kommunikation sind zusätzliche Mechanismen notwendig, um beispielsweise einen Timeout zu detektieren. Dieser Punkt wird ausschließlich in der Tabelle 3.4 beantwortet. Aufwand Geschätzter Aufwand einer Implementierung. Hier wird insbesondere der Einarbeitungsaufwand stärker gewichtet, da davon ausgegangen wird, dass jemand mit Erfahrung in einer Technologie, den Aufwand mit dieser generell niedriger einschätzt. Zusätzliche Infrastruktur nötig Benötigt diese Technik weitere Infrastruktur, wie z. B. zusätzliche Server? Bibliotheken verfügbar Sind Bibliotheken zur Vereinfachung der Implementierung verfügbar? Für alle Technologien sind Bibliotheken verfügbar, deshalb wird die Frage nicht weiter beantwortet Hypertext Transfer Protocol (HTTP) HTTP und die damit verbundenen Technologien HTML und URL bilden den Grundstein für das World Wide Web. Bei der Nutzung von HTTP werden Daten mittels der URL eindeutig referenziert. Verschiedene Methoden, wie GET und POST, erlauben das Senden von Parametern, Dateien und anderer Anfragen. Die meistgenutzte Anwendungsform ist sicher das Browsen im Internet. Mit HTTPS wurde eine Erweiterung geschaffen, die es erlaubt Daten über verschlüsselte Kanäle zu senden. HTTP wird ebenfalls von vielen Webanwendungen zum Informationsaustausch genutzt. Zwei häufig verwendete Techniken sind SOAP und REST. Skalierbarkeit Moderne Webserver verfügen über die Möglichkeit durch Caching oder Load Balancing anfallende Last zu reduzieren und zu verteilen. Die Verwendung von HTTPS für die Kanalverschlüsselung bedeutet eine hohe Rechenlast während des Verbindungsaufbaus. Verbreitung Neben SMTP ist HTTP wohl die meist genutzte Technologie im Internet. Adressierung Daten werden über Uniform Resource Locator (URL) adressiert, z.b. Verschlüsselung Mittels HTTPS kann eine Kanalverschlüsselung erfolgen. Authentizität HTTP selbst bietet keine Möglichkeit zur Authentifizierung zwischen Server-zu- Server-Verbindungen. Viele Systeme basieren darauf, dass einer der Partner eine eindeutige Kennung zur Authentifizierung verwendet. Integrität Hier gilt das Gleiche, wie für die Authentizität. Verfügbarkeit Die Verfügbarkeit hängt von der Erreichbarkeit des Webservers ab. Moderne Webserver bieten die Möglichkeit die Last mittels sogenannter Load Balancer zu verteilen. Kommunikation Synchron. 16 Kapitel 3 Grundlagen

25 SOAP Ursprünglich stand SOAP[12] für Simple Object Access Protocol. Doch da es weder einfach ist, noch generell nur der Zugriff auf Objekte möglich ist, wurde dieses Akronym später wieder abgeschafft. Heute steht SOAP als Begriff für sich. SOAP ist ein Protokoll zum Datenaustausch zweier Systeme. Dazu verwendet es XML zur Datenbeschreibung und ein Internetprotokoll (meist HTTP) zur Datenübertragung. Die Daten werden vom sogenannten Envelope gekapselt. Der Envelope kann wiederum einen Header enthalten. In jedem Fall besitzt er einen Body, welcher die Nutzdaten enthält. Der Header kann für zusätzliche Informationen, wie Authentifizierung und Integrität der Daten, oder Erweiterungen des Protokolls verwendet werden. Listing 3.1 und 3.2 zeigen ein Beispiel für Anfrage und Antwort mittels SOAP. Aufwand Ein Nachteil von SOAP ist der hohe Einarbeitungs- und Entwicklungsaufwand, welcher für die meisten Anwendungsfälle nicht gerechtfertigt ist. Verschlüsselung, Authentizität und Integrität werden durch den WS-Security-Standard unterstützt. Dadurch wird eine direkte Ende-zu-Ende-Verschlüsselung möglich. 1 GET / Blogs HTTP / Host: example. org 3 Content Type: a p p l i c a t i o n / soap+xml ; charset=utf 8 4 Content Length: nnn 5 6 <?xml version= " 1.0 "?> 7 <env: Envelope 8 xmlns:env= " h t t p : / /www.w3. org /2003/05/ soap envelope " 9 xmlns:s= " h t t p : / /www. example. org / blogs "> 10 <env:body> 11 <s:getblogs> 12 <s:contains>unity< / s : U n i t y> 13 < / s:getblogs> 14 < / env:body> 15 < / env: Envelope> Listing 3.1: Beispiel SOAP: Anfrage 1 HTTP / OK 2 Content Type: a p p l i c a t i o n / soap+xml ; charset=utf 8 3 Content Length: nnn 4 5 <?xml version= " 1.0 "?> 6 <env: Envelope # 7 xmlns:env= " h t t p : / /www.w3. org /2003/05/ soap envelope " 8 xmlns:s= " h t t p : / /www. example. org / blogs "> 9 <env:body> 10 <s:blogs xmlns:s= " h t t p : / / example. org / blogs "> 11 <s:blog>brainstorming< / s:blog> 12 <s:blog>release Notes< / s:blog> 13 <s:blog>terminabsprache< / s:blog> 14 < / s:blogs> 15 < / env:body> 16 < / env: Envelope> Listing 3.2: Beispiel SOAP: Antwort 3.2 Kommunikationskanäle 17

26 REST Representational State Transfer (REST)[23] ist ein Architekturstil zum Datenzugriff über das Web. Ein wesentlicher Vorteil von REST ist seine Einfachheit. Es geht davon aus, dass jede Ressource eindeutig addressierbar ist. Es wird keine Aussagen über das Rückgabeformat gemacht, allerdings wird häufig XML oder JSON verwendet. Listing 3.3 und 3.4 zeigen das Beispiel von SOAP unter Verwendung des REST-Prinzips. Bereits dort ist zu sehen, dass REST mit deutlich weniger Bandbreite auskommt. Aufwand Durch die starke Einfachheit des REST-Prinzips ist der Implementierungsaufwand grundsätzlich gering. Die Schwierigkeit liegt hier vor allem in der korrekten Umsetzung des Datenmodells. Es muss strikt darauf geachtet werden, dass alle Operationen auf logischen Ressourcen und nicht Methoden durchgeführt werden. Bei REST spielt die Terminologie eine wichtige Rolle, so wird z. B. einer Liste von Entitäten eine weitere hinzugefügt und nicht eine Methode aufgerufen, welche eine weitere Entität hinzufügt. Verschlüsselung, Authentizität und Integrität werden durch REST nicht unterstützt. Zur Realisierung sind zusätzliche Technologien notwendig. Für XML-basierte Daten gibt es die Möglichkeit XML-Signing[18] und XML-Encryption[17] zu verwenden. Andere Daten und die aufgerufene URL werden damit allerdings nicht unterstützt. 1 GET / Blogs / Unity HTTP / Host: firmaa. de 3 Accept: t e x t / xml 4 Accept Charset: utf 8 Listing 3.3: Beispiel REST: Anfrage 1 HTTP / OK 2 Content Type: t e x t / xml ; charset=utf 8 3 Content Length: nnn 4 5 <?xml version= " 1.0 "?> 6 <blogs xmlns:s= " h t t p : / / example. org / blogs "> 7 <blog>brainstorming< / blog> 8 <blog>release Notes< / blog> 9 <blog>terminabsprache< / blog> 10 < / blogs> Listing 3.4: Beispiel REST: Antwort XML-RPC XML Remote Procedure Call (XML-RPC) 15 ist eine Spezifikation zum verteilten Methodenaufruf mittels XML. XML-RPC stammt von den gleichen Entwicklern wie SOAP und kann somit als dessen Ursprung gesehen werden. XML-RPC wird zum Beispiel von der Blogging-Software Wordpress 16 eingesetzt, um den Zugriff auf die Funktionalität auch ohne Webschnittstelle zu ermöglichen. Die Verwendung ist genauso wie REST deutlich einfacher als SOAP. Der Funktionsumfang ist aber auch deutlich eingeschränkter. Ursprünglich wurde XML-RPC für den Transport über HTTP entwickelt, es gibt aber auch eine Spezifikation zur Nutzung über XMPP 17. Listing 3.5 und 3.6 zeigen das Beispiel mit XML-RPC. 15 XML-RPC: 16 Wordpress XML-RPC: 17 Jabber-RPC: 18 Kapitel 3 Grundlagen

27 Aufwand XML-RPC ist, wie REST, einfach aufgebaut. Verfügbare Bibliotheken verringern den Aufwand erheblich. Verschlüsselung, Authentizität und Integrität: Hier gilt grundsätzlich das Gleiche wie für REST. Ein Vorteil besteht allerdings darin, dass hier alle Daten mittels XML übertragen werden und es somit nicht nötig ist gesonderte Verschlüsselungsmechanismen für andere Datentypen zu integrieren. 1 <?xml version= " 1.0 "?> 2 <methodcall> 3 <methodname>examples. getblogs< / methodname> 4 <params> 5 <param> 6 <value>< s t r i n g>unity< / s t r i n g>< / value> 7 < / param> 8 < / params> 9 < / methodcall> Listing 3.5: Beispiel XML-RPC: Anfrage 1 <?xml version= " 1.0 "?> 2 <methodresponse> 3 <params> 4 <param> 5 <value>< s t r i n g>brainstorming< / value>< s t r i n g> 6 <value>< s t r i n g>release Notes< / value>< s t r i n g> 7 <value>< s t r i n g>terminabsprache< / value>< s t r i n g> 8 < / param> 9 < / params> 10 < / methodresponse> Listing 3.6: Beispiel XML-RPC: Antwort Simple Mail Transfer Protocol (SMTP) Simple Mail Transfer Protocol (SMTP), genauer die darauf basierende , ist neben dem WWW einer der meist genutzten Dienste im Internet. SMTP ermöglicht den Nachrichtenversand zwischen mehreren verteilten Systemen. Dazu besitzt jeder Empfänger eine eindeutige Adresse in der Form Obwohl das häufigste Einsatzgebiet ist, kann der Dienst ebenfalls zur automatisierten Kommunikation zwischen mehreren System eingesetzt werden. s unterteilen sich in Header und Body. Mit Hilfe des MIME-Protokolls können auch Dateianhänge versandt werden. Listing 3.7 und 3.8 zeigen das Beispiel für SMTP. Die Anfrage wird über das Betrefffeld (Subject Listing 3.7 Z. 4) des SMTP-Headers formuliert. Die angeforderten Daten werden über den Inhalt (Content Listing 3.8 ab Z. 7) der Nachricht ausgeliefert. Skalierbarkeit Durch seine dezentrale Architektur ist SMTP sehr gut skalierbar und extrem robust. Verbreitung SMTP ist durch sehr stark verbreitet. Andere, praktisch angewandte Einsatzgebiete lassen sich nicht finden. Adressierung Adresse in der Form Verschlüsselung, Authentizität und Integrität werden zum Beispiel durch den Standard S/MIME unterstützt. 3.2 Kommunikationskanäle 19

28 Kommunikation Asynchron. Allerdings ist durch das Protokoll gesichert, dass die Nachricht angekommen ist. Lediglich die Rückgabe der Werte erfolgt asynchron. Aufwand Der Aufwand einer Implementierung mittels SMTP ist sicher höher, da es vor allem an Erfahrung und praktischen Beispielen fehlt. 1 Message ID : <GET_BLOGS_ > 2 From : C l i e n t de> 3 To : Service com> 4 Subject : GET / blogs / Unity 5 Content Type : t e x t / p l a i n ; charset=iso { No Content } Listing 3.7: Beispiel SMTP: Anfrage 1 Message ID : <GET_BLOGS_ > 2 From : Service com> 3 To : C l i e n t de> 4 Subject : Re : GET / blogs / Unity 5 Content Type : t e x t / xml ; charset=utf <?xml version ="1.0"? > 8 <blogs xmlns : s =" http : / / example. org / blogs " > 9 <blog >Brainstorming </ blog > 10 <blog >Release Notes </ blog > 11 <blog >Terminabsprache </ blog > 12 </ blogs > Listing 3.8: Beispiel SMTP: Antwort Extensible Messaging and Presence Protocol (XMPP) Das Extensible Messaging and Presence Protocol (XMPP) 18 ist ein offener Standard zum Austausch von Daten im XML-Format zwischen verteilten Systemen. Besser bekannt als XMPP, ist der darauf aufsetzende Instant Messaging-Dienst Jabber. Empfänger werden ähnlich zu SMTP via adressiert. Eine Stärke von XMPP ist das Presence-Handling. Konkret bedeutet dies, dass der Client sich gleichzeitig von verschiedenen Ressourcen einloggen kann. Eingehende Nachrichten werden an die Ressource mit der höchsten Priorität gesendet. Mit Hilfe sogenannter Transports ist der Austausch mit anderen System, wie ICQ oder MSN, möglich. Listing 3.9 und 3.10 zeigen das bereits bekannte Beispiel. Die Entscheidung zwischen Anfrage und Antwort wird hier z. B. durch die Typen get und result geregelt. XMPP besteht aus einer stabilen Kernspezifikation[7], welche die wichtigsten Eigenschaften des Protokolls enthält. Neben weiteren Kernspezifikationen 19 gibt es eine Reihe sogenannter Extensions, die sich größtenteils in einer Art stabilem Entwurf befinden. Sie sind also benutzbar, es können aber jederzeit Änderungen auftreten. Eine dieser Extensions beschreibt z. B. die Verwendung von SOAP über XMPP[16]. Skalierbarkeit Bei besonders kurzen Nachrichten entsteht durch die Kapselung des Protokolls in XML ein Mehraufwand durch XML-Tags. Verbreitung XMPP wird besonders für Instant Messaging verwendet, findet aber auch in der Server-zu-Server-Kommunikation große Anwendung. 18 XMPP: 19 XMPP RFC s: 20 Kapitel 3 Grundlagen

29 Adressierung Ähnlich wie SMTP mittels Die zusätzliche Ressource ermöglicht es dem Nutzer sich mit einem Account von verschiedenen logischen Orten gleichzeitig einloggen zu können. Diese logischen Orte werden häufig mit realen Orten verknüpft, beispielsweise Auf Arbeit oder Zu Hause. Eingehende Nachrichten werden an den Ort mit der höchsten Priorität 20 oder eine konkrete Ressource, sofern vom Absender angegeben, gesendet. Verschlüsselung, Authentizität und Integrität werden durch den Standard für Client-zu-Server und Server-zu-Server-Verbindungen geregelt. RFC 3923[8] beschreibt zwar eine Ende-zu- Ende-Verschlüsselung und Signierung, nur wird diese Spezifikation von den verfügbaren Bibliotheken nicht unterstützt. Verfügbarkeit Einer der großen Vorteile von XMPP ist, dass es dem Client erlaubt sich von mehreren Orten gleichzeitig einzuloggen. Der Client mit der höchsten Priorität bekommt die Nachricht, außer die Nachricht wurde direkt an eine bestimmte Ressource gesendet. Damit müssen keinen speziellen Vorkehrungen für verteilte Server getroffen werden. Kommunikation Asynchron. Aufwand Durch die Verwendung verfügbarer Bibliotheken ist die Realisierung mittels XMPP recht einfach. Unter der Annahme, dass die verwendeten Clients und Server korrekt für höchste Sicherheit konfiguriert sind, kann dieser Aspekt bei einer prototypischen Entwicklung erstmal außen vor gelassen werden. 1 <i q from= de 2 to= com type= get i d= > <query 3 xmlns= h t t p : / / example. org / blogs > 4 <blogs> 5 <contains>unity< / contains> 6 < / blogs> 7 < / query> 8 < / i q> Listing 3.9: Beispiel XMPP: Anfrage 1 <i q from= com to= de 2 type= r e s u l t i d= > 3 <reponse xmlns= h t t p : / / example. org / blogs > 4 <blogs xmlns:s= " h t t p : / / example. org / blogs "> 5 <blog>brainstorming< / blog> 6 <blog>release Notes< / blog> 7 <blog>terminabsprache< / blog> 8 < / blogs> 9 < / response> 10 < / i q> Listing 3.10: Beispiel XMPP: Antwort Zusammenfassung Der Zugriff auf Systeme mittels REST oder SOAP über HTTP nimmt durch Web 2.0 immer mehr an Bekanntheit und Bedeutung zu. Besonders REST erfreut sich dank seiner Einfachheit großer Beliebtheit und man findet kaum noch einen Dienst dessen API nicht darauf basiert. SOAP hat 20 Die Priorität kann z. B. vom Nutzer selbst festgelegt oder aus der Aktivität des eingeloggten Clients hergeleitet. 3.2 Kommunikationskanäle 21

30 Abbildung 3.4: Gegenüberstellung der Übertragungsprotokolle einen deutlich größeren Funktionsumfang und bietet mit WS-Security auch Sicherheitsmechanismen an, ist dafür aber alles andere als einfach zu verstehen und einzusetzen. Der Nachteil von REST ist, dass es sich durch die Nutzung der URL zur Funktionsbeschreibung nicht leicht in andere Protokolle außer HTTP einbetten lässt. Außerdem bietet es standardmäßig keine Sicherheitsmechanismen, z. B. zur Verschlüsselung oder Authentifizierung der Daten. SMTP ist dank weit verbreitet, leidet aber wegen mangelnder Mechanismen an extrem starkem Spam-Befall. Studien zufolge ist über 90% des täglichen -Aufkommens Spam[21]. Andere Einsatzszenarien sind eher weniger bekannt, aber durchaus möglich. Durch verschiedene Mechanismen beugt XMPP Spam deutlich besser vor. Sicherheitsmechanismen sind ebenfalls bereits in der Kernspezifikation vorhanden, nur leider nicht für Ende-zu-Ende-Verbindungen, sondern lediglich für sichere Verbindungen unter Servern und zwischen Client und Server. RFC 3923 beschreibt zwar sichere Ende-zu-Ende-Verbindungen, aber umgesetzt wird dieser Standard scheinbar von keinem Anbieter. Durch die Übermittlung von Presence-Informationen oder das ständige Versenden kurzer Informationen entsteht bei XMPP zusätzlich ein Mehraufwand an genutzter Bandbreite 21, da der Anteil an Nutzdaten im Vergleich zum umpackenden XML-Paket immer kleiner wird. Das Datenformat ist bei allen Verfahren ähnlich. Die eigentlichen Nutzdaten werden als XML übertragen. 3.3 BESTEHENDE ANSÄTZE UND TECHNOLOGIEN OpenMicroBlogging-Protokoll (OMB) Das OpenMicroBlogging-Protokoll 22 wurde von den Laconi.ca-Entwicklern spezifiziert, um in erster Linie den Nachrichtenaustausch zwischen verschiedenen Laconi.ca Instanzen zu vereinheitlichen. Das Protokoll basiert auf dem Publish-Subscribe-Prinzip, d. h. der Server wird nicht regelmäßig auf neue Nachrichten geprüft, sondern sendet diese automatisch an den Service eines anderen Servers. Das Protokoll sieht keine Rückgabe über ein erfolgreiches Senden der Nachricht vor. Generell ist es sehr einfach gehalten und unterstützt lediglich das schlanke Datenmodell welches von Twitter vorgegeben wurde. Nachrichten enthalten im Wesentlichen also nicht mehr als 21 Über 70% der Bandbreite werden angeblich für die Verfügbarkeitsinformationen (Presence) der Nutzer verwendet[14]. 22 OpenMicroBlogging-Protokoll: 22 Kapitel 3 Grundlagen

31 den Inhalt und benötigte Meta-Informationen, wie Autorendaten. Zum Auffinden des Services werden Yadis 23 und OAuth Discovery 24 verwendet, zur Authentifizierung OAuth 25. Das Protokoll bietet einen guten Ansatz zur Kommunikation zwischen mehreren Systemen. Die weitere Entwicklung scheint allerdings stehen geblieben zu sein oder zumindest sehr schleppend vorwärts zu gehen Birds of a FETHR In [26] wird ein Ansatz vorgestellt, um eine Art Twitter-Netzwerk dezentralisiert aufzubauen, Featherweight Entangled Timelines over HTTP Requests (FETHR) genannt. Zentralisierte Systeme besitzen den Nachteil, dass Nutzer an dieses gebunden sind und damit auch dessen Vorgaben, Einschränkungen und Erreichbarkeit unterliegen. Statt Nachrichten betrachtet FETHR micropublishing im Allgemeinen, also das Veröffentlichen besonders kurzer Inhalte. Daher macht FETHR auch keine Annahme über die Art der übermittelten Inhalte, sondern geht lediglich davon aus, dass sie kurz genug sind um ein skalierbares verteiltes System dieser Art zu realisieren. FETHR geht vom Subscriber-Prinzip aus (vgl. Abb. 3.5a), sendet neue Nachrichten aber nicht zwangsläufig an alle Abonnenten (vgl. Abb. 3.5b), sondern versucht sie gegebenenfalls über wenige ursprüngliche Empfänger im Netzwerk zu verteilen 26 (vgl Abb. 3.5c). Auf diese Art und Weise kann die erzeugte Last ebenfalls dezentralisiert werden. Als Sicherheit bietet FETHR unter anderem die Möglichkeit Nachrichten zu signieren und mit Hashkombination älterer Beiträge die zeitliche Reihenfolge sicherzustellen. Verteilung und Zugriff erfolgen über REST und HTTP. Adressiert werden Empfänger und Sender über eindeutige Adressen im Internet Google Wave Federation Protocol Mit dem Google Wave Federation Protocol (GWFP) 27 publiziert Google ein Protokoll zur veteilten Kommunikation in Echtzeit. GWFP ist eine offene Erweiterung für XMPP und befindet sich derzeit in einem frühen Entwurfsstadium[13]. Aufbauend auf das Protokoll bietet Google eine Referenzimplementierung für Python und Java, namens Google Wave 28, an. Laut Google soll diese auf lange Sicht die als Hauptkommunikationsmedium ablösen. Im Vordergrund steht die Echtzeitkollaboration mit beliebig vielen Teilnehmern gleichzeitig. Abbildung 3.6 zeigt den strukturellen Aufbau einer Wave-Kommunikation. Die wichtigsten Elemente sind Wave, Wavelet, Participant und Blip. Jedes Wave bildet dazu den Container einer verteilten Kommunikationsinstanz. Eine Wave kann beliebig viele Teilnehmer (Participant) enthalten. Um den Zugriff auf bestimmte Daten einzuschränken, können diese Teil sogenannter Wavelets sein, welche nur bestimmten Teilnehmern zugänglich sind. Dabei haben alle Teilnehmer die gleichen Rechte, sie dürfen Inhalte schreiben, lesen und ändern. Die aktuelle Version macht keine Angaben über eine feinere Rechtevergabe. Blip werden die kleinsten Informationseinheiten genannt. Neben Wave-spezifischen Daten enthalten sie auch die eigentliche Information. Eine starke Einschränkung der vorhandenen Implementierung ist es, Googles AppEngine 29 als Plattform verwenden zu müssen. Das bietet zwar den Vorteil, dass man sich über Verfügbarkeit und Verteilung der Anwendung keine Gedanken machen muss, allerdings ist man dadurch auf das Angebot von Google und dessen Preispolitik und technischen Einschränkungen angewiesen. Zusätzlich ist man damit auch verpflichtet, möglicherweise wichtige Unternehmensdaten 23 Yadis: 24 OAuth Discovery: 25 OAuth: 26 Dieser Mechanismus wird Gossip genannt (http://en.wikipedia.org/wiki/gossip_protocol Stand ). 27 Google Wave Federation Protocol: 28 Google Wave: 29 Googles App Engine: 3.3 Bestehende Ansätze und Technologien 23

32 Abbildung 3.5: FETHR: (a) Abonnieren (b) Veröffentlichen (c) Verteiltes Veröffentlichen (Quelle: [26]) 24 Kapitel 3 Grundlagen

33 Abbildung 3.6: Übersicht der Wave-Elemente (Quelle: auf den Google-Servern zu lagern. Die Richtlinien vieler Firmen verbieten dies. Hinzu kommt die beschränkte Verfügbarkeit von Google Wave. Man kann sich zwar für einen Entwicklerzugang registrieren, ob und wann der Account dann freigeschaltet wird ist unklar. Neben Google Wave gibt es auch einen prototypischen Wave-Server, FedOne, und Kommandozeilenclient. Beide sind bei Google Code verfügbar XML-basierte Nachrichtenverteilung [22] zeigt einen Aufbau zur Verteilung beliebiger Nachrichten im XML-Format (siehe Abbildung 3.7). Das System unterstützt sowohl das Push- als auch Pull-Prinzip. Als Empfänger stehen dem System und ein Web-Frontend zur Verfügung. Das Push-Prinzip wird mittels - Auslieferung realisiert. Zur Realisierung des Pull-Prinzips werden die Daten in einer Datenbank gespeichert und dann mittels eines Message Feeders im RSS- oder XML-Format zur Verfügung gestellt. Zur Verarbeitung der Nachrichten wird ein JMS-Server verwendet. Dieser bietet die Möglichkeit, dass sich konkrete Empfänger und Sender als Subscriber und Publisher für bestimmte Kanäle registrieren. So ist die Persistenz-Middleware ebenfalls ein Subscriber des entsprechenden Kanals. Die Idee erscheint sehr simpel, verschiedene Quellen und Empfänger registrieren sich an einem zentralen Verteiler, welcher die Nachrichten je nach Nutzerkonfiguration entsprechend weiterleitet. In der Zusammenfassung wird Sicherheit zwar erwähnt aber konkrete Lösungen bleiben aus. Der Einsatz von JMS ist interessant, aber für die Problemstellung weniger geeignet. JMS zielt mehr auf verteilte Komponenten im gleichen System ab, anstatt verteilter, unabhängiger Systeme. So wäre zur Nutzung sowieso eine Art Wrapper, wie der -Auslieferer in Abb. 3.7, zur Verteilung notwendig. 3.4 ZUSAMMENFASSUNG Aus Gründen der Übersichtlichkeit wird auf eine gesonderte Zusammenfassung von Kapitel 3.3 verzichtet. 30 Wave bei Google Code: 3.4 Zusammenfassung 25

34 Abbildung 3.7: Architektur eines Systems zum Verteilen beliebiger XML-Nachrichten (Quelle: [22]) Bestehende Systeme und Ansätze innerhalb des Problemkontexts sind schwer zu finden, aktuelle Forschung ist selten. Das liegt nicht zuletzt daran, dass das gesamte Themengebiet recht jung ist und bisher wenig erforscht. Existierende Systeme, wie Twitter, sind wohl auch eher technischen, als wissenschaftlichen Ursprungs. Mit dem großen Erfolg dieser Systeme innerhalb so kurzer Zeit 31 hat sicher niemand gerechnet, was nicht zuletzt durch die anfängliche Instabilität des Twitter-Service bestätigt wird 32. FETHR versucht einen dezentralisierten Ansatz zu bieten. Leider ist die existierende Arbeit ebenfalls recht jung und macht kaum technische und genauere Angaben über das Protokoll. Allerdings wird das Prinzip deutlich und die Funktionsweise kann aus dem verfügbaren Quelltext des Prototypen nachvollzogen werden. So wird zur Signierung ein Public-Key-Verfahren verwendet. Es besticht in jedem Fall durch die Einfachheit des Ansatzes und die damit verbundene Umsetzung nach dem REST-Stil. [22] zeigt auf Basis von JMS einen interessanten Verteilungsmechanismus, der es erleichtert die gleiche Information über mehrere Kanäle zu verteilen. Für die korrekte und sichere Übertragung zum Zielsystem sind dann die eigentlichen Verteiler verantwortlich. Ähnlich wie SMTP ist eine Implementierung mittels JMS deutlich aufwändiger. Ob sich OMB durchsetzen wird ist fraglich. Die Entwicklung ist offensichtlich stehen geblieben, da es nach Version 0.1, außer ein paar Beiträgen auf der Mailingliste, keine weiteren Informationen zur Weiterentwicklung gibt. Dadurch entsteht leicht der Eindruck, dass OMB lediglich entwickelt wurde, um kurzfristig mehrere Laconica-Instanzen zu verknüpfen und damit einen Wettbewerbsvorteil gegenüber Twitter zu erlangen. Zusätzlich setzen die Laconica-Macher neben OMB auf das Klonen der Twitter-API. 31 Zur Erinnerung: Twitter wurde Anfang 2006 veröffentlicht, alle anderen Systeme danach. 32 Twitter Status: 26 Kapitel 3 Grundlagen

35 GWFP und Google Wave kommen der Idee der verteilten Kommunikation mit vielen Partnern am Nächsten. Das Protokoll beschreibt die Struktur eines verteilten Kommunikations- oder Kooperationsaspekts. Google Wave liefert eine erste Implementierung. Der große Nachteil ist hier aber der aktuelle Entwicklungsstand. Das Protokoll ist momentan ein früher Entwurf, differenzierte Zugriffsregeln fehlen beispielsweise gänzlich. Daneben schränkt Google Wave die Nutzung auf Googles eigene Software und Server ein, was nicht mit den Datenschutzbestimmungen vieler Unternehmen vereinbar ist. Generell gilt, dass die existierenden Systeme zentralisiert erscheinen und über Web-APIs den Zugriff ermöglichen. Dabei bieten sie selten die Möglichkeit selbst aktiv zu handeln oder mit anderen Systemen zu kommunizieren, vielmehr müssen Clients den Server regelmäßig abfragen, um neue Daten zu bekommen. Ebenfalls bietet keines der Systeme eine Freigabe auf Blog- oder Gruppenebene an, sondern lediglich auf Nutzerebene. In jedem Fall ist es dann so, dass der Nutzer auf dem System einen Account benötigt. Gerade HTTP-basierende Systeme gehen meist von einer Client-zu-Server-Kommunikation aus, Ziel dieser Arbeit ist allerdings eine Server-zu-Server- Kommunikation. Um eine Überlastung zu verhindern wird der Zugriff zusätzlich oft auf wenige Anfragen pro Minute beschränkt. Das es deutlich weniger bekannte Systeme mit Lösungen auf XMPP- oder SMTP-Basis gibt wird sicher stark an der Einfachheit aktueller Scriptsprachen liegen und vor allem an der großen Anzahl kostenloser Webhoster für diese. Im Enterprise-Bereich findet XMPP stärkere Anwendung zum Datenaustausch zwischen Systemen, z. B. wird es von der Amerikanischen Marine als Nachrichtendienst 33 verwendet. Zusätzlich kommt der Aufruf einer Webschnittstelle dem Aufruf normaler Webseiten gleich und Entwickler müssen sich somit nicht mit neuen und komplexeren Technologien vertraut machen. Die Einstiegshürde für diesen Bereich ist also deutlich niedriger. Über den technischen Hintergrund der Anwendungen ist generell wenig gesagt, so dass hier keine Aussage getroffen werden kann. Ebenfalls ersichtlich wurde, dass Rückgabedaten immer in strukturierter Form vorliegen, alternativ im JSON- oder XML-Format, oft auch beides. Anfrageparameter werden nicht gesondert codiert, sondern als POST oder GET-Parameter übergeben. Zusammenfassend kann man sagen, dass es keine Lösung gibt, welche die Anforderungen vollständig abdeckt. Die APIs bekannter Systeme decken die benötigte Datenmenge nicht ab und sind auch technisch nicht weiter beschrieben. Bekannte Lösungen auf Basis der genannten Protokolle gibt es so gut wie gar nicht oder sie befinden sich ebenfalls noch in der Entwicklung. Das GWFP kommt einem möglichen Lösungsansatz am nächsten, ist aber leider noch zu unausgereift und lässt einige Fragen offen. Unter Verwendung von Google Wave besitzt jeder Teilnehmer die gleichen Rechte, was für die Verwendung innerhalb eines Unternehmens nicht geeignet ist. Zusätzlich werden sämtliche Daten auf Googles Servern gespeichert. 33 XMPP/ U.S. Marine: 3.4 Zusammenfassung 27

36 28 Kapitel 3 Grundlagen

37 4 KONZEPT UND ENTWURF Das folgende Kapitel beschreibt das Konzept und den Entwurf einer Anwendung zur Freigabe von Blogs und Verteilung der damit verbundenen Informationen an beteiligte Partner. Das Kapitel ist so aufgebaut, dass erst das jeweilige Konzept vorgestellt wird und im Anschluss der konkrete Entwurf dazu. Es ist nicht an allen Stellen möglich, das Konzept eins zu eins im Entwurf umzusetzen. Die konzeptionellen Ideen sollen möglichst unabhängig von bestimmten Technologien oder Plattformen sein, wobei der Entwurf bereits Communote-spezifische Details berücksichtigt. Abbildung 4.1: Möglicher Aufbau eines Systems zur Informationsverteilung 29

38 In Abbildung 4.1 ist der Aufbau einer Anwendung dargestellt, die einen internen Dienst zur Verteilung von Informationen verwendet. Über einen zentralen Nachrichtenverteiler werden einzelne Transports 1 (Kapitel 4.1) angesprochen. Transports realisieren den Nachrichtentransport zu anderen Systemen und den Empfang von Nachrichten kooperierender Systemen. Der Nachrichtenverteiler stellt transparente Schnittstellen und Extension Points zur Realisierung der Transports zur Verfügung. Dadurch wird gewährleistet, dass die Transports unabhängig von der eigentlichen Anwendung sind und somit auch in anderen Umgebungen verwendet werden können. Der Mikro-Blogging-Transport bildet die Schnittstelle zur API des eigenen Systems, ein XMPP-Transport könnte z. B. über XMPP mit kooperierenden Systemen kommunizieren. Jeder Transport ist selbst dafür verantwortlich Nachrichten nicht zurück an den ursprünglichen Sender zu schicken. Diese Voraussetzung geht daraus hervor, dass ein Transport mehrere Systeme bedienen können muss. Eine Alternative wäre offensichtlich, dass für jedes neue System eine eigene Instanz eines Transports verwendet wird. Diese Lösung würde allerdings nicht skalieren, da es dadurch sehr schnell zu einer hohen Anzahl an Transports und damit Laufzeitobjekten im System kommen würde. Jeder Transport muss in der Lage sein bestimmte Aufgaben zu erledigen. Er muss sicherstellen, dass Einladungen korrekt angenommen und Nachrichten wirklich empfangen werden. Wird eine Kooperation aufgelöst, muss dies auch den entsprechenden Partnern mitgeteilt werden. Eine Übersicht aller benötigten Methoden wird in Abschnitt 4.2 gegeben. Für diese Arbeit ist es angestrebt, einen Transport nach dem REST-Prinzip über HTTP zu realisieren. Die Gründe dafür und welche Schritte zur Realisierung notwendig sind, werden in Abschnitt 4.6 dargestellt. Es ist wichtig, dass definierte Richtlinien auf Kooperationen eingehalten werden. Einige Richtlinien müssen bei jedem Nachrichtenversand berücksichtigt werden, andere nur wenn eine Kooperation aufgelöst wird. Welche Richtlinien denkbar sind und wie diese realisiert werden wird in Abschnitt 4.3 gezeigt. Für den Datenaustausch zwischen verschiedenen Systemen wird ein Format benötigt, welches unabhängig von der verwendeten Technologie ist und sich in verschiedene Übertragungskanäle einbetten lässt. In Abschnitt 4.4 wird ein Datenmodell vorgestellt. Außerdem wird gezeigt, wie man mit Hilfe eines Generierungsansatzes daraus ein transparentes Austauschformat erzeugen kann. Über das Web-Frontend der Anwendung können Nutzer Kooperationen anlegen, verwalten und löschen. Entwürfe für die benötigten Dialoge zeigt Abschnitt 4.5. Am Ende des Kapitels werden dann noch einige Communote-spezifische Details betrachtet (Abschnitt 4.7). 4.1 ARCHITEKTURENTWURF Nachrichtenverteiler und Transports Communote stellt eine MessagerConnector-Schnittstelle bereit (vgl. Abbildung 4.2), welche für ausgehende Nachrichten genutzt werden kann. Der angestrebte Transport implementiert die Schnittstelle im CommunoteSharedBlogsMessagerConnector und wird vom Plug-In am MessagingManagement registriert. Nach erfolgreicher Registrierung werden alle neuen Nachrichten ebenfalls über den Connector gesendet. Dieser verwendet die in Kapitel beschriebenen ApiCalls zur Realisierung der Aufrufe. Um auf eingehende Ereignisse reagieren zu können ist eine Schnittstelle nötig, welche von der Shared Blogs API zur Verfügung gestellt wird und von der verwendenden Anwendung realisiert werden muss. Diese Schnittstelle heißt RequestHandler und ist in Abbildung 4.3 dargestellt. Zur Verwendung muss die Implementierung an der SharedBlogsApplication registriert werden und steht dann den Ressourcen über die abstrakte SharedBlogsResource zur Verfügung. 1 Der Begriff Transport ist angelehnt an Jabbers Verbindungen zu anderen IM-Diensten. 30 Kapitel 4 Konzept und Entwurf

39 Abbildung 4.2: MessagerConnector-Schnittstelle und MessagingManagement Abbildung 4.3: RequestHandler- und ResourceProvider-Schnittstellen 4.1 Architekturentwurf 31

40 Abbildung 4.4: Prinzip der entkoppelten Shared Blogs API Komponentenbasierte Aufteilung Damit die vorgesehene Shared Blogs API unabhängig von der Anwendung ist, muss sie so aufgebaut sein, dass sie sämtliche Funktionalität kapselt und für systemabhängige Werte geeignete Schnittstellen bereit stellt. Die Endanwendung muss diese Schnittstellen dann lediglich implementieren. Das Prinzip ist in Abbildung 4.4 dargestellt. Die konkrete Implementierung der API (im Bild Communote Shared Blogs Api Implementation) erweitert die Shared Blogs API und registriert sich an deren Schnittstellen, um über eingehende Ereignisse informiert zu werden. Gleichzeitig stellt sie die Funktionalität bereit, um mit der Communote-Plattform interagieren zu können. 4.2 METHODEN Notwendige Methoden sind in Abbildung 4.5 dargestellt. Die folgende Auflistung zeigt alle Methoden in der Übersicht, komplexere Methoden werden im Anschluss noch etwas genauer beleuchtet. Einladen (s. Abb 4.5a) Das System funktioniert nicht direkt nach dem Publish-Subscribe-Prinzip, sondern nach dem Invite-Publish-Prinzip. Um mit einem System kooperieren zu können ist es nötig von diesem Eingeladen worden zu sein. Nach erfolgreicher Annahme einer Einladung werden gegebenenfalls fehlende Informationen ausgetauscht. Kooperation anpassen (s. Abb 4.5b) Es kann vorkommen, dass sich eine Kooperation verändert. Kooperation beenden (s. Abb 4.5c) Die Kooperation wird durch eine einfache Anfrage beendet. Dabei soll das Zielsystem die vorher festgelegten Richtlinien berücksichtigen. Für die Beendigung einer Kooperation bedarf es keiner Rückmeldung, da der gemeinsame Datenaustausch automatisch unterbunden wird. Nachricht senden/ändern/löschen (s. Abb 4.5d) Es können Nachrichten gesendet, geändert und gelöscht werden. 32 Kapitel 4 Konzept und Entwurf

41 Nutzerdaten anfordern/senden (s. Abb 4.5e) Um unnötige Redundanz zu verhindern werden Nachrichten lediglich mit einer Referenz auf den Autor gesendet. Diese Referenz enthält zusätzlich einen Zeitstempel der letzten Nutzeraktualisierung. Komplette Nutzerdaten können bei Bedarf angefordert werden, z. B. wenn die Nutzerreferenz das Erste mal verwendet oder der Nutzer aktualisiert wurde. Beiträge anfordern (s. Abb 4.5f) Diese Methode bietet Kooperationen die Möglichkeit sich Beiträge anhand bestimmter Filter anzufordern. So ist es möglich, sich für neue Kooperationen, Beiträge aus der Vergangenheit anzufordern. Solche Filter sind beispielsweise Schlagwörter, Nutzer oder ein Zeitintervall. Die Antwort erfolgt nicht synchron zur Anfrage, sondern das System sendet die Nachrichten asynchron, wenn es Kapazitäten dazu frei hat. Es ist keine direkte Antwort auf diese Anfrage notwendig, da die Nachrichten auch als Nachricht senden geschickt werden können. Dadurch lässt sich die Fehleranfälligkeit verringern, indem z.b. viele Nachrichten nicht gemeinsam, sondern in kleineren Gruppen oder einzeln gesendet werden. Abbildung 4.5: Verfügbare Methoden Einladen und Einladung annehmen Um den Einladungsprozess zu vereinfachen werden Einladungen via versendet (vgl. Listing 4.1). In der Regel kennen Nutzer die -Adresse desjenigen, mit dem sie kooperieren wollen. Die Adresse des Mikro-Blogging-Systems zu kennen ist eher unwahrscheinlich. Mittels kann ein Nutzer eine Einladung für eine Kooperation verschicken. Die enthält einen speziell formatierten String, Shared Blogs Identifier (SBI) genannt, mit welchem der Empfänger in seinem Mikro-Blogging-System die Einladung bestätigen kann. Der SBI besteht aus folgenden Teilen: Endpunkt Um das Zielsystem zu kennen, muss der Endpunkt bekannt sein. Dieser ist die URL zum Einstiegspunkt der API, z. B Methoden 33

42 Geheimer Bezeichner Der Bezeichner ist insofern geheim, dass nur der einladende Server und der eingeladene Nutzer ihn kennen. Auf dem einladenden Server wird der Bezeichner verwendet, um auf die eigentliche Kooperation schließen zu können. Er wird folgendermaßen gebildet: Die Nutzung der E- Mail-Adresse erfordert weitere Sicherheitsmechanismen, da der verschickte Einladungslink von jedem beliebigen System verwendet werden könnte. Daher muss es für den Sender der Einladung oder generell den Client Manager möglich sein eine angenommene Einladung erneut zu kontrollieren und endgültig zu bestätigen. 34 Kapitel 4 Konzept und Entwurf

43 1 To : C l i e n t <thomas. de> 2 Subject : Einladung zu e i n e r Kooperation 3 4 H a l l o Thomas Test, 5 6 Sie wurden von Ken Mei ( ken. de ) zu e i n e r 7 Kooperation eingeladen. B i t t e fügen Sie i n Ihrem Mikro 8 Blogging System folgende Z e i l e i n das entsprechende Feld 9 ein, um der Einladung nachzukommen : http : / / blog. firmaa. de / a p i / shared / ae V i e l e n Dank. Listing 4.1: Beispiel der Einladungs- Der gesamte Prozess stellt sich wie folgt dar (vgl. Abb. 4.6): 1. Nutzer A gibt einen Blog frei. 2. Nutzer B bekommt eine vom System A mit dem SBI. 3. Nutzer B fügt den SBI in ein dafür vorgesehenes Feld in seinem System ein: (a) Nutzer B nimmt die Kooperation an. (b) Je nach Konfiguration müssen neue Kooperationen vom Client Manager bestätigt werden. Die Kooperation wird dann zwar von Nutzer B angenommen, wartet aber noch auf die endgültige Bestätigung durch den Client Manager. 4. Kooperation annehmen: (a) Nutzer B nimmt die Kooperation an. (b) Will Nutzer A die Kooperation bestätigen oder ist System A so konfiguriert, dass ein Client Manager sämtliche Kooperationen bestätigen muss, erfolgt das im Anschluss. Andernfalls fällt dieser Punkt weg und die Kooperation kommt automatisch durch die Annahme von Nutzer B zustande. 5. Nach erfolgreicher Herstellung einer Kooperation ist es möglich einen Synchronisationsprozess zu starten. Dieser Prozess sendet bereits alle vorhandenen Beiträge und Nutzerdaten an das andere System. Allerdings werden lediglich die Daten der explizit freigeschalteten Nutzer übertragen, da die Übertragung sämtlicher Nutzerdaten unter Umständen eine zu große Last- und Datenflut erzeugen würde, aber auch Sicherheitstechnisch nicht wünschenswert ist. Nach erfolgreicher Synchronisation tauschen die Systeme sich fortwährend aus Nachrichten schreiben, ändern und löschen Um Nachrichten zu versenden, geht das System die Liste der Kooperationen eines Blogs durch und sendet die Nachricht an alle entsprechenden Teilnehmer. Der Versand der Nachrichten sollte so erfolgen, dass statt Nutzerdaten nur eine Referenz auf den Nutzer gesendet wird. Ist der Nutzer dem anderen System unbekannt oder wurden seine Daten aktualisiert, kann dieses sich die benötigten Daten anfordern. Dadurch ist es nicht nötig bei jeder Nachricht alle Nutzerdaten mitzuschicken. Anhänge können entweder eingebettet oder ebenfalls nur als Referenz versendet werden. Gerade bei Nachrichten mit mehreren oder größeren Anhängen ist die Referenzierung 4.2 Methoden 35

44 Abbildung 4.6: Der Einladungsprozess vorteilhafter um so das System zu entlasten. Empfängt ein System Nachrichten eines unberechtigten Systems muss es diese ignorieren und eine Fehlermeldung (Not_authorized) zurückgeben. Geänderte Nachrichten werden genauso wie neue Nachrichten gesendet. Anhand der eindeutigen Kennung und des Zeitstempels kann das Zielsystem erkennen, ob die Nachricht bereits existiert und die empfangene Version aktueller ist. Gegebenenfalls wird eine existierende Nachricht überschrieben. Das Löschen einer Nachricht ruft einen einfachen Löschprozess auf. Wichtig hierbei ist, dass nur Nachrichten des eigenen Systems gelöscht werden können. Die Kommunikation der Systeme bei diesen Vorgängen ist in Abbildung 4.7(a) und 4.7(b) dargestellt Nutzer benachrichtigen Eine der wichtigsten Eigenschaften moderner Mikro-Blogging-Systeme ist die Benachrichtigung bestimmter Nutzer. Um einen Nutzer Thomas zu benachrichtigen wird häufig innerhalb einer Nachricht in Kombination mit dem Nutzernamen verwendet, Um auch Nutzer anderer Systeme adressieren zu können wird eine einfache Forderung aufgestellt: Nutzernamen oder -aliase dürfen lediglich aus Buchstaben und Zahlen bestehen. Weiterhin kann dann jedem Endpunkt eine eindeutige einfache Bezeichnung innerhalb des eigenen Systems zugeordnet werden. Diese Bezeichnung besteht dann wiederum lediglich aus Buchstaben und Zahlen. Für den Endpunkt könnte beispielsweise die Bezeichnung FirmaA gewählt werden. Um nun einen Nutzer des Systems FirmaA zu benachrichtigen wähle dessen Nutzernamen und verknüpfe ihn mit dem zuvor festgelegten Endpunktalias mittels eines Punkts, Die erstmalige Festlegung des Endpunktalias kann auf verschiedene Wege erfolgen: (1) Der Nutzer, welcher einer Einladung folgt, legt den initialen Wert fest, (2) unter Kenntnis eines Endpunkts kann ein Client Manager den Alias vorab definieren und (3) durch Annahme einer vom System zur Verfügung gestellten Kooperation wird ein Bezeichner anhand einer festgelegten Strategie gewählt. Nimmt ein anderes System eine Einladung an, muss dessen Endpunkt nicht bekannt sein. Da dieser Prozess automatisch abläuft, wird ein Bezeichner ebenfalls automatisch angelegt (Punkt (3)). 36 Kapitel 4 Konzept und Entwurf

45 (a) Nachrichten senden und ändern (b) Nachrichten löschen Abbildung 4.7: Prinzip für Nachrichten senden, ändern und löschen So wird gewährleistet, dass bereits nach Kooperationsbeginn Nutzer korrekt benachrichtigt und mögliche Fehler durch einen fehlenden Endpunktalias vermieden werden können. Der Bezeichner kann jederzeit von einem Client Manager geändert werden Kooperation auflösen Kooperationen können jederzeit von allen Seiten aufgelöst werden. Wird eine Kooperation aufgelöst ist es für die beteiligten Systeme nicht mehr möglich Informationen auszutauschen. Alle beteiligten Systeme müssen über die Auslösung informiert werden, um die Kooperation ebenfalls bei sich auflösen zu können. Behandlung der Richtlinien Mit einer Kooperation können Richtlinien verbunden sein. Grundsätzlich ist es nicht möglich ein fremdes System zu zwingen, diese Richtlinien technisch einzuhalten, da es einfach nicht kon- 4.2 Methoden 37

46 trollierbar ist. D. h. ein System, welches vorgibt die API zu implementieren, muss noch lange nicht die Durchsetzung von Richtlinien implementieren. Bei einer offenen Schnittstelle ist es nicht möglich den technischen Hintergrund und die Umsetzung kooperierender Systeme zu kennen, außer man ist selbst für ihre Implementierung zuständig oder hat Einblick in selbige. Im Idealfall wird aber davon ausgegangen, dass mit Kündigung einer Kooperation auch die mit ihr vereinbarten Richtlinien durchgesetzt werden. Sollen z. B. sämtliche Beiträge des Fremdsystems gelöscht werden, wird dieser Prozess auch ausgeführt. 4.3 RICHTLINIEN Richtlinien beschreiben Vorschriften zum Umgang mit Blogs und Nachrichten. Gerade im Unternehmensumfeld spielen Regeln auch rechtlich eine wichtige Rolle zur Absicherung der eigenen Firma. Erwähnt werden muss allerdings, dass sich durch die verteilte Architektur der Shared Blogs API eine explizite Umsetzung der Richtlinien nicht erzwingen lässt, da in der Regel keine Kontrollmechanismen für fremde Systeme zur Verfügung stehen. Prinzipiell ist es möglich sich beliebig viele Richtlinien zu überlegen, im Folgenden sind mögliche aufgezählt: NO_RESTRICTIONS (NOR) Diese Richtlinie steht für die leere Richtlinie und bedeutet, dass es keine Einschränkungen oder Regelungen gibt. Ist keine Richtlinie angegeben ist das gleichbedeutend mit der Richtlinie NO_RESTRICTIONS. READ_ONLY (RO) Der eingebundene Blog darf nur gelesen werden. SAME_POLICIES_ONLY SPO Der Blog darf nur unter Berücksichtigung der gleichen Richtlinien Teil einer weiteren Kooperation sein. DO_NOT_REMOTE_MODIFY (DNRM) Manager des eingebundenen Blogs dürfen nur Beiträge ändern, die durch Mitarbeiter des eigenen Systems entstanden sind. Ist diese Richtlinie nicht gesetzt, dürfen Manager auch die Beiträge anderer System ändern. DO_NOT_MANAGE (DNM) Das beteiligte System darf den Blog nicht verwalten, d. h. es dürfen lediglich die Personen an dem Blog teilnehmen, welche von dem Muttersystem angegeben wurden. DISTRIBUTION_ALLOWED (DA) Standardmäßig darf der eingebundene Blog nicht weiter freigeben werden. Durch diese Richtlinie wird eine weitere Freigabe explizit erlaubt. ANONYMIZE_ON_UNSUBSCRIBE (AOU) Wird die Kooperation aufgelöst müssen alle Beiträge anonymisiert werden, d.h. die Beiträge lassen nicht mehr auf den Autor schließen. Diese Einschränkung gilt lediglich für die Beiträge anderer Systeme. Die Beiträge des eigenen Systems brauchen nicht anonymisiert werden. DELETE_ON_UNSUBSCRIBE (DOU) Wird die Kooperation aufgelöst müssen alle Beiträge gelöscht werden. Diese Einschränkung gilt lediglich für die Beiträge anderer Systeme. Beiträge aus dem eigenen System dürfen erhalten bleiben. Tabelle 4.8 zeigt die Kombinationsmöglichkeiten der Richtlinien. Nicht jede Richtlinie kann mit jeder eingesetzt werden. 38 Kapitel 4 Konzept und Entwurf

47 Entwurf der Richtlinien Abbildung 4.8: Kombinationsmöglichkeiten der Richtlinien Richtlinien werden immer dann behandelt, wenn eine neue Nachricht gesendet oder empfangen wird, bzw. eine Kooperation zu Stande kommt oder aufgelöst wird. Abbildung 4.9 zeigt zwei Schnittstellenbeschreibungen, welche von Richtlinien implementiert werden können. Beide Schnittstellen besitzen die Methode getname zur Rückgabe der Richtlinienbezeichnung. Mit der Methode iscombinable kann überprüft werden, ob die Richtlinie mit einer anderen Richtlinie kombinierbar ist. Ansonsten besitzt die Schnittstelle MessagePolicyHandler Methoden, die vor und nach der Behandlung von Nachrichten aufgerufen werden. CooperationPolicyHandler stellt analog Methoden zur Behandlung von Kooperationen bereit. 4.4 DAS DATENMODELL In Abbildung 4.11 ist ein Diagramm der Datenstruktur des Systems abgebildet. Das Diagramm enthält den Basissatz an benötigten Daten, welche übertragen werden können. Die benötigten Daten ergeben sich zum einen aus der vorhandenen Datenstruktur des Communote-Systems, den Daten, die über die APIs der Systeme aus Kapitel 3 zur Verfügung gestellt werden, sowie weiteren Elementen, welche für die Realisierung benötigt werden. Um die Objekte weitgehend einfach zu halten, wurden möglichst wenige Felder explizit benannt. Dadurch wird die Anzahl der Felder auf ein notwendiges Minimum reduziert. Um die erlaubten Daten dennoch flexibel zu gestalten, können die meisten Elemente zusätzliche Informationen mittels Schlüssel-Wert- Paaren besitzen. Für den Kontext der Mikro-Blogs ist die Auswahl sicher ausreichend, da hier keine möglichst komplizierten Datenstrukturen übertragen werden sollen. Die Notation folgt den Fundamental Modeling Concepts (FMC) (Kurzreferenz in Anhang A.4). Global Id Einige Elemente sind mit Global Id gekennzeichnet. Diese Elemente besitzen einen global eindeutigen Bezeichner, welcher sich aus einem Wert und einem Typ zusammensetzt. Der Wert kann beispielsweise im Klartext vorliegen oder mit einer Hashfunktion verschlüsselt sein. Das Format des Werts wird durch den Typ bestimmt. So kann die Eindeutigkeit des Beitrags gewahrt und eine Rückverfolgung auf das Ursprungssystems verhindert 4.4 Das Datenmodell 39

48 Abbildung 4.9: Schnittstellen zur Richtlinienrealisierung Abbildung 4.10: Formatübersicht der Global Ids der einzelnen Elemente werden. Tabelle 4.10 zeigt eine transparente Möglichkeit zur Vergabe der Bezeichner. HOST und LOCAL_ID stehen dabei für variable Größen. Zusätzlich enthält die Tabelle die Hashes der Beispiele im CRC32-Format. Zeitstempel Der Zeitstempel gibt an, wann das Element angelegt wurde und wann die letzte Änderung erfolgt ist. Eigenschaft Bestimmte Elemente des Systems können mit zusätzlichen Eigenschaften näher beschrieben werden. Diese Eigenschaften bestehen aus einem Schlüssel und dem zugehörigen Wert. Schlagwort Einige Elemente unterstützen Schlagwörter (Tags). Schlagwörter besitzen lediglich einen Wert. Schlagwörter werden verwendet, um ein Element näher zu klassifizieren. Kooperation Die Kooperation kennt die beteiligten Partner in Form von Systemen. Zusätzlich zu den Partnern ist eines der Systeme der Anleger der Kooperation. Er darf die Kooperation verändern und Partner ausschließen, hinzufügen oder verstecken. Richtlinie Jede Kooperation kann verschiedene Richtlinien enthalten. Richtlinien verbieten z. B. das Antworten auf Beiträge. Jede Richtlinie besteht aus einem Wert und einer Beschreibung. 40 Kapitel 4 Konzept und Entwurf

49 Abbildung 4.11: Grundlegende Datenstruktur eines Blog-Systems System Jedes System besitzt einen Namen, eine Beschreibung, und einen Anbieter. Um weitere Eigenschaften zu unterstützen können diese als Schlüssel-Wert-Paar dem System hinzugefügt werden. Ist ein System bekannt kennen es alle beteiligten bekannten Partner einer Kooperation. Unbekannte Systeme sind nur dem Anleger bekannt und kennen ebenfalls nur den Anleger. Blogs Freigegebene Blogs sind ebenfalls Bestandteil einer Kooperation. Blogs besitzen einen Namen, eine Beschreibung und können mittels zusätzlicher Eigenschaften näher beschrieben werden. Schlagworte beschreiben Blogs genauer. Nachricht Nachrichten werden in Blogs gruppiert. Jede Nachricht besitzt einen Inhalt. Mit Hilfe von Eigenschaften und Schlagwörtern lässt die Nachricht sich flexibel mit weiteren Informationen erweitern. Nutzer Nutzer spiegeln die Autoren von Nachrichten wieder und lassen sich durch Eigenschaften näher beschreiben. Anhang Anhänge können direkt in die Übertragung eingebettet werden oder durch einen Link referenziert werden. Der Typ gibt Auskunft über die Art des Inhalts. Zwei mögliche Typen sind embedded und referenced. Über den MIME-Type wird der Datentyp selbst angegeben. Generierung des Datenmodells Das benötigte Datenmodell wird als Ecore-basiertes Modell 2 realisiert. Durch die Verwendung des Eclipse Modeling Framework (EMF) 1. ist das Modell automatisch XMI-konform, 2. stehen bereits Code-Generatoren für Klassen und einfache Editoren bereit, 2 Eclipse Modeling Framework: 4.4 Das Datenmodell 41

50 3. können Objektinstanzen 3 mit Bordmitteln in ein konformes XML-Format serialisiert und deserialisiert werden. Neben diesen, für diese Arbeit relevanten Vorteilen, bietet das EMF eine Reihe weiterer: so ist es ein offenes Framework mit stetiger Weiterentwicklung und großer Community. Zusätzlich kann der generierte Code programmatisch erweitert werden, indem das Ecore-Metamodell erweitert wird. Mit Hilfe von Adaptern kann auf Änderungen in Modellen reagiert werden. Verschiedene weitere Technologien erlauben unter anderem die Validierung 4, den Vergleich 5 und die Persistierung 6 von Modelle. Einen sehr guten Einstieg und weiteres Material bietet das Buch EMF: Eclipse Modeling Framework von Ed Merks u.a.[27]. 4.5 FRONTEND Vorerst sind lediglich einfache Kooperationen geplant, d. h. jeder Blog muss einzeln freigegeben und verwaltet werden. Im Folgenden sollen die benötigten Frontend-Komponenten vorgestellt werden. Client Administration Der Client Manager hat jederzeit die Möglichkeit bestehende Kooperation aufzulösen. Dies kann er über einen neuen Menüpunkt SharedBlogsApi in der Client- Verwaltung machen. Abbildung 4.12(a) zeigt einen Entwurf für die Elemente des Client Managers. Mit einer Tabelle kann er bestehende Kooperationen einsehen. Als Aktionen stehen ihm das Bearbeiten, Synchronisieren und Löschen einer Kooperation zur Verfügung. Ein einfacher Dialog erlaubt das Bearbeiten einer bestehenden Kooperation. Es gibt zwei Typen von Kooperationen: (1) Dieses System verwaltet die Kooperation und (2) Die Kooperation wird von einem anderen System verwaltet. Blog-Verwaltung Der Blog Manager darf Kooperationen auf Basis seiner Blogs anlegen. In der jeweiligen Blog-Verwaltung hat er Zugriff auf die Konfiguration. Abbildung 4.12(b) zeigt die Sicht des Blog Managers. Sie ähnelt der des Client Managers und beinhaltet die gleichen Funktionen. Einladung annehmen Um eine Einladung annehmen zu können ist ein einfacher Dialog geplant. Abbildung 4.12(c) zeigt den Dialog. Im ersten Schritt kann der Nutzer seinen Einladungslink eingeben und die Informationen zu der Kooperation mittels Lade laden. Danach kann er die vorgeschlagenen Werte nochmal anpassen und die Einladung über Einladung annehmen annehmen. 4.6 REST ÜBER HTTP Zur Realisierung eines ersten Transports ist die Kommunikation mittels REST über HTTP angestrebt. Gründe dafür sind: 1. die deutliche Einfachheit und geringe Einarbeitungszeit durch Verwendung bekannter Webtechnologien und 3 Objektinstanzen: hier Java-Objekte des Modells zur Laufzeit. 4 EMF Validation Framework: 5 EMF Compare: 6 EMF Teneo: 42 Kapitel 4 Konzept und Entwurf

51 (a) Benutzeroberfläche des Client Managers (b) Benutzeroberfläche des Blog Managers (c) Dialog, um eine Einladung anzunehmen Abbildung 4.12: Entwürfe der Benutzeroberflächen für Client und Blog Manager 4.6 REST über HTTP 43

52 2. der Mangel an zusätzlicher Infrastruktur, da die Anwendung bereits einen Webserver zur Verfügung stellt. Fehlende Sicherheitsmechanismen der REST-Architektur werden durch zusätzliche Maßnahmen ersetzt. Für die Implementierung der REST-Schnittstelle wird das Restlet-Framework 7 verwendet. Restlet bietet ein freies, leichtgewichtiges und verbreitetes Framework zur Realisierung von REST-APIs. Jede Anwendung wird dabei als sogenannte Application realisiert und kann somit weiterhin unabhängig von anderen Anwendungen eingesetzt und entwickelt werden. Abbildung 4.13 zeigt ein Prinzip der Shared Blogs-Applikation mittels Restlet. Durch diverse Erweiterungen unterstützt Restlet auch andere Vorgehensweisen, z.b. die reine Konfiguration einer Applikation über Spring Beans. Die SharedBlogsApplication erweitert die Restlet-Application um systemspezifische Funktionen. Sie dient gleichzeitig als Einstiegspunkt für die API und registriert die notwendigen Ressourcen. Alle Ressourcen erben von der SharedBlogsResource, welche wiederum von der Restlet-ServerResource 8 erbt. Die SharedBlogsResource kapselt die REST-Methoden GET, POST, DELETE und PUSH so, dass vor ihrer Ausführung bereits Sicherheitsüberprüfungen, wie die Signaturprüfung stattfinden. Jede Ressource wird über einen bestimmten Pfad innerhalb der Anwendung angesprochen, z. B. /api/cooperations/42db84 für eine konkrete Kooperation. Die Applikation selbst wird am Restlet-Router registriert, welcher dafür verantwortlich ist ankommende Anfragen an die korrekte Applikation und damit Ressourcen weiterzuleiten. Abbildung 4.13: Prinzip der Shared Blogs API-Restlet-Applikation 7 Restlet: 8 Restlet API: org.restlet.resource.serverresource 44 Kapitel 4 Konzept und Entwurf

53 Abbildung 4.14: Modell des Rückgabeobjekts Signierung von Anfragen und Antworten Zur Sicherstellung von Authentizität und Integrität müssen Anfragen und Antworten signiert werden. Zur Signierung wird ein Public-Key-Verfahren eingesetzt, bei dem sich die Signatur aus einer Kombination der Absenderadresse, einem Zufallswert, sowie den zu übertragenden Daten zusammensetzt. Der Zufallswert ist nötig, um auch bei sich wiederholenden Nachrichten, wie einfache Bestätigungen, unterschiedliche Schlüssel zu erzeugen. Da diese Verfahren nur bedingt zur Verschlüsselung großer Datenmengen geeignet sind, werden die Eingabeparameter zunächst mittels einer Hashfunktion verkürzt. Der entstandene Hash wird dann durch den privaten Schlüssel des jeweiligen Senders verschlüsselt. Der Empfänger kann die Echtheit nun mit Hilfe des öffentlichen Schlüssels des Senders prüfen. Anfragesignatur Zur Signierung der Anfrage werden sämtliche Parameter, sowie der Pfad zur Ressource, der Absender und die Zufallsvariable verwendet. Damit ist gewährleistet, dass die komplette Anfrage unverändert und vom korrekten Absender übertragen wurde. Zur Berechnung und Überprüfung der Signatur müssen die Parameter in der gleichen Reihenfolge angewandt werden. Es wird eine alphabetische Anordnung vorgeschlagen. Die Formel für die Anfragesignatur lautet: Signatur(Anfrage) = RSA(SHA2(CONCAT (parameters) + resource + sender + random)) (4.1) Rückgabesignatur Signieren der Rückgabe ist deutlich einfacher, da hier keine Parameter ausgewertet werden müssen. Jede Rückgabe wird in einem Response-Element gekapselt. Die zurückgegebenen Daten werden im content-feld der Response gespeichert. Zusätzlich enthält die Rückgabe neben der Signatur Informationen über den Status der Rückgabe (Okay, Fehler... ), eine Nachricht, sowie eine Zufallsvariable. Abbildung zeigt das Modell des Rückgabeobjekts. Das Response-Element selbst ist abstrakt und besitzt zwei konkrete Unterklassen zur leichteren Unterscheidung erfolgreicher und fehlerhafter Rückgaben. Zur Berechnung der Signatur wird hier die Kombination aus Status, Nachricht, String-Repräsentation der Daten und der Zufallsvariable verwendet. Die Formel für die Rückgabesignatur lautet: Signatur(Rueckgabe) = RSA(SHA2(status + message + content + random)) (4.2) 4.6 REST über HTTP 45

54 4.6.2 Verschlüsselung der Übertragung Es ist keine eigene Verschlüsselung geplant, da mit HTTPS bereits eine vertraute und etablierte Methode zur Kanalverschlüsselung zur Verfügung steht. Abbildung 4.15 zeigt allerdings eine Idee, wie die Anfrage mit Hilfe des öffentlichen Schlüssels des Empfängers verschlüsselt werden könnte. Dazu wird der Teil der URL ab dem Endpunkt der API, sowie die zu übertragenden Parameter 9 verschlüsselt. Statt dem ursprünglichen Endpunkt wird eine, um das Pfadfragment /crypt erweiterte, URL verwendet. Auf dem Server werden verschlüsselte URL und Parameter entschlüsselt und intern an die korrekte Ressource weitergeleitet. Abbildung 4.15: Prinzip der umgeleiteten Verschlüsselung ApiCalls für API-Aufrufe Für jede Ressource stehen die vier HTTP-Methoden GET, DELETE, POST und PUT zur Verfügung. ApiCalls abstrahieren von diesen Methoden und ermöglichen ihren Aufruf mittels einfacher Java-Klassen. Dazu muss für jede Methode einer Ressource ein ApiCall implementiert werden. Somit kann es für jede Ressource ebenfalls maximal vier ApiCalls geben. Abbildung 4.16 zeigt das Prinzip der ApiCall-Schnittstelle anhand eines einfachen Beispiels. Für die Ressource InvitationResource sind zwei ApiCalls abgebildet. Der GetInvitationInfoCall gibt Informationen über die ausgewählte Einladung und damit Kooperation zurück. Der AcceptInvitationCall nimmt eine Einladung für diese Kooperation an. Die Schnittstellendefinition ist in Abbildung 4.17 dargestellt. Der generische Parameter T definiert den Rückgabetyp des ApiCalls. Jeder ApiCall muss die zwei call-methoden implementieren. Jede dieser Methoden nimmt den Sender 10, den Endpunkt der Ressource und die benötigten Aufrufparameter entgegen. Die erste Methode ist konzipiert um einen synchronen Aufruf zu starten und das Ergebnis des Aufrufs unverzüglich als Rückgabe bereitzustellen. Die zweite call-methode hat zusätzlich einen ApiCallCallback als Parameter. Sie ist für asynchrone Aufrufe gedacht und soll unverzüglich zurückkehren. Sobald das Ergebnis vorliegt oder ein Fehler auftritt wird der Callback stattdessen informiert. Die Klasse AbstractApiCall soll die asynchrone call-methode unter Verwendung der synchronen implementieren. Neue ApiCalls können dann direkt von dieser Klasse erben und müssen somit nicht mehr die asynchrone call-methode implementieren. Die Schnittstelle ApiCallCallback stellt Methoden zur Behandlung asynchroner Rückgaben bereit. Im Erfolgsfall wird die Methode callsucceeded aufgerufen, andernfalls callfailed. 9 GET-Parameter werden mit der URL verschlüsselt. 10 Der Sender ist hier der Endpunkt des Aufrufers. 46 Kapitel 4 Konzept und Entwurf

55 Abbildung 4.16: Prinzip der ApiCalls Beispiel Das folgende Beispiel soll die Funktionalität der ApiCalls verdeutlichen. Um eine Nachricht an ein System zu senden oder eine Information anzufordern sind folgende Schritte nötig, welche von dem entsprechenden ApiCall vereinfacht werden: 1. Endpunkt des anderen Systems mit der Resourcen-URL verknüpfen. 2. Eine zufällige Zeichenkette für die Signatur erzeugen. 3. Alle notwendigen Parameter, den Endpunkt des Senders und des Empfänger, sowie die zufällige Zeichenkette zur Signatur verknüpfen. 4. Die Anfrage im richtigen Format (POST, GET... ) stellen. 5. Das Ergebnis auswerten. 6. Wird ein bestimmtes Ergebnis erwartet, dieses aus der Rückgabe extrahieren und dieses dem Aufrufer bereitstellen. Der Anwender muss also lediglich seinen eigenen Endpunkt, den des Empfängers, sowie die benötigten Parameter kennen. Der korrekte Aufruf wird vom ApiCall geregelt, welcher ebenfalls die Rückgabe oder eine Fehlermeldung bereit stellt. 4.6 REST über HTTP 47

56 48 Kapitel 4 Konzept und Entwurf Abbildung 4.17: ApiCall- und ApiCallCallback-Schnittstellen

57 4.7 COMMUNOTE-SPEZIFIKA Dieser Abschnitt beschreibt Communote-spezifische Änderungen und Anpassungen Anpassung des Datenmodells Die Aggregation von Informationen heterogener Systeme macht es nötig, diese auch als solche zu kennzeichnen. Im Communote betrifft das Nutzer, Blogs, Nachrichten und deren Anhänge. Die Kennzeichnung von Nachrichten und Anhängen ist relativ simpel, da diese einfach eine Referenz auf den ursprünglichen Beitrag bekommen. Blogs und Nutzer hingegen weisen eindeutige Merkmale wie einen Alias 11 auf. Nutzer besitzen zusätzlich eine eindeutige -Adresse. Diese Merkmale können bereits in anderen Systeme vorkommen. So ist es durchaus wahrscheinlich, dass es in sehr vielen Systemen jemanden mit dem recht häufigen Vornamen Thomas als Alias geben kann. Dieser Thomas ist nicht zwangsläufig überall die gleiche Person. Eine Lösung für Blogs ist wiederum recht einfach zu finden. Wird eine Kooperation hinzugefügt, kann der Nutzer die eindeutigen Daten des Blogs selbst bestimmen. Dabei werden die ursprünglichen Daten als Vorschlag verwendet. Existiert eines der Merkmale bereits, muss der Nutzer es ändern. Intern werden Blogs über den eindeutigen globalen Bezeichner referenziert. Bei Nutzern ist das ganze deutlich schwieriger, da gerade Merkmale wie der Alias auch zur Erkennung des Nutzers verwendet werden und es ermöglichen den Nutzer u. a. direkt zu benachrichtigen. In einem ersten Schritt werden die eindeutigen Merkmale verschleiert, indem sie aus einer Kombination der ursprünglichen Daten und des Ursprungssystems gebildet werden. Dadurch entstehen beispielsweise seltsame und falsche -Adressen, was aber nicht weiter problematisch ist, da diese Nutzer sowieso keinen Login auf dem eigenen System besitzen. Um die Nutzer benachrichtigen zu können wird wie in Kapitel beschrieben vorgegangen. Um möglichst wenige Änderungen in der Nutzersuche und den Frontend-Klassen vornehmen zu müssen wird der kombinierte Alias aus Nutzernamen und Systembezeichnung vorerst direkt als Alias abgespeichert. Dadurch ist die Last beim Ändern der Systembezeichnung zwar höher, da jeder Datenbankeintrag geändert werden muss, allerdings wird diese Operation in der Praxis sicherlich nicht häufig ausgeführt. Statt den Nutzer Thomas also auf einen bestimmten Endpunkt mit der Bezeichnung FirmaA zu referenzieren wird gleich die Kombination Thomas.FirmaA in der Datenbank abgelegt Änderungen erscheinen im Blog Wird eine Kooperation angelegt, geändert oder aufgelöst entsteht in dem jeweiligen Blog ein Beitrag, der darüber informiert. Dadurch kann die Transparenz gesteigert und die Rückverfolgbarkeit von Aktionen gewährleistet werden. 11 Hier: einfaches kurzes Pseudonym für einen langen Namen, ähnlich des Kosenamens bei Kindern 4.7 Communote-Spezifika 49

58 50 Kapitel 4 Konzept und Entwurf

59 5 IMPLEMENTIERUNG 5.1 KOMPONENTENBASIERTE AUFTEILUNG Es ist gelungen die SharedBlogsApi und die damit verbundene Kernfunktionalität sauber vom Communote-Kern zu trennen. Das CommunoteSharedBlogsPlugin konnte ebenfalls weitestgehend außerhalb des Kerns realisiert werden. Es implementiert die notwendigen API-Schnittstellen der SharedBlogsApi und registriert diese zur Initialisierung an der API. Zusätzlich implementiert es auf Communote-Seite den benötigten MessagerConnector (siehe Kapitel 4.1.1) und registriert ihn ebenfalls während der Initialisierungszeit. Abbildung 5.1 zeigt die Komponenten und ihre Interaktion miteinander Die SharedBlogsApi Als Basiskomponente hat die SharedBlogsApi keine Abhängigkeiten zum Communote, stellt aber dennoch wesentliche Funktionalitäten, wie das Datenmodell und die dazugehörigen Ressourcen und ApiCalls bereit. Durch die Anforderung der Unabhängigkeit besitzt sie keinen Zugriff auf konkrete Elemente, wie Nutzerdaten oder Nachrichten und kennt auch keine sonstigen Daten des Systems von dem sie verwendet wird. Abbildung 5.1: Komponenten der Implementierung 51

60 SharedBlogsApiApplication Das Kernelement der API ist die Klasse SharedBlogsApiApplication, diese erbt von der Restlet- Klasse Application 1 und spiegelt die eigentliche Anwendung wieder. Sie initialisiert die verfügbaren Ressourcen und sorgt somit dafür, dass diese zur Verfügung stehen und mittels Webzugriff aufgerufen werden können. Damit die Ressourcen letztendlich auf die korrekten Daten zugreifen können stellt die API die beiden Schnittstellen RequestHandler und ResourceProvider bereit (s. Kapitel 4.1.1). Konkrete Implementierungen müssen der SharedBlogsApi zum Initialisierungszeitpunkt zur Verfügung gestellt werden. Das geschieht als Parameter der SharedBlogsApiApplication. Datenmodell, Ressourcen und ApiCalls Das modellierte Austauschformat in Form eines EMF-Modells befindet sich im Anhang A.1. Innerhalb der Anwendung wird der generierte Code verwendet, um auf Objektinstanzen der Elemente arbeiten zu können. Der Teil der Ressourcen, welcher als Restlet-ServerResources für den HTTP-Zugriff implementiert wurde, wird in Kapitel 5.3 genauer beschrieben. Der Grund dafür ist, dass die konkrete Implementierung zwar Bestandteil der SharedBlogsApi ist, der Zugriff über HTTP aber transparent zu der darunter liegenden Anwendung stattfindet. Die ApiCalls wurden, wie in Kapitel vorgeschlagen, implementiert. Für jede implementierte ServletResource steht ein ApiCall zur Verfügung. Signierung und Verifizierung der Daten erfolgt automatisiert und wird in den nächsten Abschnitten betrachtet. Dort wird die Funktionsweise der ApiCalls ebenfalls deutlicher. Schlüsselverwaltung Eingehende Anfragen und ausgehende Daten werden mittels Public-Key-Verfahren signiert. Das signierende System verwendet dazu seinen privaten Schlüssel. Der öffentliche Schlüssel ist über die API für andere Systeme verfügbar und wird von diesen zur Überprüfung der Signatur verwendet. Diese Signierung und Überprüfung der Daten ist ebenfalls Bestandteil der SharedBlogsApi. Zur Bereitstellung der dafür benötigten öffentlichen und privaten Schlüssel stehen zwei Schnittstellen zur Verfügung: (1) KeyStore und (2) KeyProvider (s. Abbildung 5.2). Beide Schnittstellen machen Gebrauch des java.security-pakets, d. h. die Schlüssel können durch jede Implementierung der Java-Security-Schnittstellen erzeugt und bearbeitet werden 2. Für diese Arbeit wurden die Pakete von Bouncy Castle 3 verwendet. Zur Reduzierung der Datenmenge wird das SHA- 2-Verfahren mit einer Schlüssellänge von 256 Bit als Hashfunktion eingesetzt. Als Public-Key- Verfahren wird RSA mit einer Schlüssellänge von 512 Bit eingesetzt. Beide Verfahren sind als ausreichend sicher bekannt und in der Praxis bewährt. (1) KeyStore: Ein KeyStore stellt anhand des Endpunkts eines Systems dessen öffentlichen Schlüssel bereit. Dieser kann zur Überprüfung der Signatur genutzt werden. Die Standardimplementierung in KeyStoreImpl ermittelt den Schlüssel mit Hilfe des PublicKeyApiCalls und speichert ihn während der Programmlaufzeit in einer internen Tabelle. Ein erneuter Aufruf auf den Schlüssel gibt diesen aus dem Speicher zurück. Die beiden clean-methoden können verwendet werden, um den Speicher aufzuräumen. In der Standardimplementierung werden entweder alle Datensätze gelöscht oder nur der für den spezifischen Endpunkt. Ein Bezeichner für den KeyStore kann 1 In Restlet API: org.restlet.application 2 Das jeweilis verwendete Verfahren muss von den Implementierungen allerdings unterstützt werden. 3 Bouncy Castle: 52 Kapitel 5 Implementierung

61 Abbildung 5.2: KeyProvider- und KeyStore-Schnittstellen mittels getidentifier abgefragt werden. KeyStoreImpl gibt den Wert default zurück. Um den Zugriff auf verschiedene KeyStores zu erleichtern und einen zentralen Zugangspunkt bereitzustellen wird eine KeyStoreFactory verwendet. Diese stellt verschiedene statische Methoden zur Registrierung und zum Abruf von KeyStores bereit. KeyStoreImpl wird als default -Implementierung automatisch registriert, kann allerdings mittels addkeystore( default, mykeystoreobject) überschrieben werden. (2) KeyProvider: Im Gegensatz zum KeyStore dient der KeyProvider dazu, das eigene Schlüsselpaar zu verwalten und bereitzustellen. So stellt er z. B. den privaten Schlüssel zur Signierung der eigenen Daten bereit. Die Standardimplementierung in KeyProviderImpl erzeugt bei jeder neuen Objektinstanz ein neues Schlüsselpaar anhand der übergebenen Daten für den Algorithmus (z. B. RSA) und die Schlüssellänge in Bit, unter Verwendung der gegebenen Implementierung von java.security.provider, hier der BouncyCastleProvider. Ähnlich der KeyStoreFactory gibt es eine KeyProviderFactory als zentralen Zugriffspunkt für den KeyProvider. Signieren und Verifizieren Signieren und Verifizieren der Daten erfolgt vollständig automatisiert. Dazu gibt es eine Reihe von Hilfsklassen. So stellt die Klasse SecurityUtils beispielsweise statische Methoden bereit um übergebene Daten zu signieren und zu verifizieren (s. Abbildung 5.3). Die beiden wichtigsten Methoden sind getsignature und die verify-methode, welche den content als String erwartet. Alle anderen Methoden transformieren die Daten und verwenden dann die beiden anderen Methoden. Die Methode signurl verknüpft die Daten z. B. wie in Kapitel vorgeschlagen und gibt die korrekt gerenderte URL zurück. D. h. sie fügt der URL die Parameter, den Sender, das Zufallswort und die Signatur an. Die Methode wird für GET- und DELETE-Anfragen verwendet. Damit nicht jeder ApiCall die Verbindungslogik und das Erzeugen der Rückgabeobjekte realisieren muss, gibt es die Hilfsklasse EObjectConnectionUtils (s. Abbildung 5.4). Diese Klasse besitzt 5.1 Komponentenbasierte Aufteilung 53

62 je eine Methode für die vier HTTP-Methoden DELETE, GET, POST und PUT. Alle vier Methoden nehmen die gleichen Parameter entgegen: den eigenen Endpunkt (sender), den Endpunkt des Partners (endpoint), die Resource (resource, z.b. /cooperations/e5rf3) und die benötigten Parameter. Als Rückgabe gibt jede Resource ein Response-Objekt zurück. Ist das Objekt vom Typ SuccessResponse verlief die Anfrage erfolgreich. Der Typ ErrorResponse indiziert einen Fehler. Für die Anfragen wird intern der Apache HttpClient 4 verwendet. Die EObjectConnectionUtils verwenden die KeyStore- und KeyProviderFactory um auf die Schlüssel zuzugreifen und die zuvor beschriebenen SecurityUtils zur Signierung der Daten. Eine Möglichkeit der Rückgabe bei Restlet-Ressourcen ist die Klasse Representation 5. Diese enthält die eigentliche Rückgabe in einem bestimmten Format, z. B. String, und Informationen über den Typ, z. B. XML. Zur Erzeugung des entsprechenden Representation-Objekts als Rückgabe der Ressourcen wird die Klasse MessageUtils bereitgestellt. Diese enthält Methoden, um die konkrete Response als XML-String in Form einer StringRepresentation 6 darzustellen. Gleichzeitig nutzt sie SecurityUtils zur Signierung der Response. Die Klasse MessageUtils werden von den konkreten Ressourcen zur Rückgabe des Ergebnisses verwendet. Zugriffsbeschränkung auf Ressourcen Bevor eine Anfrage die konkrete Ressource erreicht, wird deren Signatur von der abstrakten SharedBlogsResource überprüft und die Anfrage gegebenenfalls mit einem ErrorResponse-Objekt beendet. Das Ergebnis enthält dann Informationen darüber, dass die Signatur nicht gültig war. Die SharedBlogsResource verwendet ebenfalls die SecurityUtils zur Überprüfung. Um den Zugriff auf bestimmte Kooperationen zu schützen sind alle Pfade unterhalb von /cooperation/{cooperation} durch einen CooperationAccessFilter geschützt. Beim Zugriff überprüft der Filter, ob der anfragende Server ein Partner der Kooperation ist und verhindert gegebenenfalls den weiteren Zugriff. Zusammenfassung Die SharedBlogsApi bildet das Fundament der Anwendung und stellt damit Basisfunktionalitäten für die Kommunikation und Einbindung der API bereit. Sie besteht selbst wiederum aus drei wichtigen Teilen: 1. Den konkreten Ressourcen als Restlet-ServerResourcen zur Darstellung des serverseitigen Teils der Anwendung. Die dazugehörigen ApiCalls ermöglichen Clients einen einfachen Zugriff. 2. Der SharedBlogsApplication als initialer Baustein, welcher die Ressourcen registriert, und Schnittstellen für den konkreten Datenaustausch mit der darüberliegenden Komponente bereitstellt. 3. Und vielen Hilfsklassen, welche u. a. Signierung und Verifizierung, sowie Serialisierung und Deserialisierung der Objekte vereinfachen. 4 Apache HTTP Client: 5 In Restlet API: org.restlet.representation.representation 6 In Restlet API: org.restlet.representation.stringrepresentation 54 Kapitel 5 Implementierung

63 Abbildung 5.3: SecurityUtils-Hilfsklasse Abbildung 5.4: EObjectConnectionUtils-Hilfsklasse Das Communote SharedBlogsApi-Plug-In Die zweite wichtige Komponente ist das CommunoteSharedBlogsPlugin. Es stellt den Vermittler zwischen SharedBlogsApi und Communote dar. Um dieser Rolle gerecht zu werden implementiert es sowohl von der SharedBlogsApi, als auch vom Communote Schnittstellen zur Datenbereitstellung und Ereignisverarbeitung. CommunoteSharedBlogsPlugin Die Klasse CommunoteSharedBlogsPlugin erbt von der SharedBlogsApplication und erweitert sie um Communote-spezifische Details. So registriert sie einen eigenen KeyProvider (s. weiter unten: Sicherheit) in der SharedBlogsApi und eine MessagerConnector-Implementation, um auf ausgehende Nachrichten reagieren zu können, auf Communote-Seite. Außerdem hält sie zusätzliche Parameter, wie den eigenen Endpunkt, bereit und registriert den BouncyCastle Security- Provider. Die Plug-In-Klasse wurde als Singleton konzipiert und steht über eine getinstance- Methode anderen Objekten zur Verfügung. Sie dient als zentraler Knoten der gesamten Plug-In- Komponente. ResourceProvider und RequestHandler Zur Verwaltung der Ressourcen implementiert das Plug-In drei RessourceProvider. Der ClientDelegateResourceProvider sorgt dafür, dass aktive Clients nur ihre eigenen Daten sehen können. Dazu erzeugt er für jeden Client einen eigenen ResourceProvider und wählt während des Zugriffs den korrekten aus. Der CommunoteNonPersistentResourceProvider speichert benötigte Ressourcen im Arbeitsspeicher des Systems und erlaubt den Zugriff auf konkrete Daten des Communotes. Um den Datenverlust durch einen Neustart des Systems zu verhindern wurde noch ein FileSystemPersistentResourceProvider implementiert, welcher das lokale Dateisystem als Speicher verwendet. Dieser wird zwischen ClientDelegete- und CommunoteNonPersistentResourceProvider geschaltet. Abbildung 5.5 verdeutlicht das Zusammenspiel der verschiedenen ResourceProvider. 5.1 Komponentenbasierte Aufteilung 55

64 Abbildung 5.5: Zusammenspiel der verschiedenen ResourceProvider Um eingehende Anfragen bearbeiten zu können wurde ein CommunoteRequestHandler implementiert. Der Handler stellt die Schnittstelle zum Communote her und sorgt dafür, dass z. B. neue Nachrichten im korrekten Blog erscheinen. Endpunktalias Um Nutzer eines anderen Systems benachrichtigen zu können, müssen diese transparent ansprechbar sein (siehe Kapitel 4.2.3). Dafür muss jedem Endpunkt eines anderen Systems ein Alias zugeordnet werden. Dieser Alias wird Endpunktalias genannt. Jeder Endpunktalias besteht aus den folgenden Daten: Endpunkt: Dem Endpunkt des Systems, Alias: Dem Alias zum Endpunkt und Bestätigung durch Client Manager: einem Flag, das dazu führt, dass wenn es gesetzt ist, jede eingehende Kooperation durch einen Client Manager bestätigt werden muss. Jeder Endpunkt und jeder Alias sind einmalig im System. Die Daten werden in der Datenbank gespeichert. Abbildung A.6 im Anhang zeigt die Entität und zugehörige Servicemethoden in MagicDraw. Da mit den Endpunktaliasen Nutzerinformationen verbunden sind, können diese vorerst nicht gelöscht werden. Würde der Alias gelöscht werden, würde auch der Bezug der Nutzer, die diesen Alias verwenden, zum ursprünglichen System verloren gehen. Erzeugt werden können die Aliase durch folgende Möglichkeiten: 1. Ein Client Manager kann den Alias in der Administrationsoberfläche hinzufügen (vgl. Abbildung A.3 im Anhang). Über die Verwaltung ist der Alias ebenfalls veränderbar. 2. Ein Nutzer kann den Alias bestimmen, sobald er einer Einladung nachkommt und der Endpunkt des anderen Systems bisher unbekannt ist. Ist der Nutzer kein Client Manager, müssen alle Kooperation vorerst bestätigt werden. 3. Es wird ein zufälliger Alias angelegt 7, sobald eine Einladung von einem anderen System angenommen und dieses auf dem eigenen System nicht bekannt ist. Die Client Manager werden mit einer darüber informiert und können den Alias dann anpassen. 7 Es wird der Hash (java.lang.object#hashcode()) der Kooperation verwendet. 56 Kapitel 5 Implementierung

65 Sicherheit Das CommunoteSharedBlogsPlugin stellt einen eigenen KeyProvider bereit. Der Communote- KeyProvider (vgl. Abbildung 5.2) sorgt für eine korrekte Persistierung der Schlüssel in der Clientdatenbank, so dass sie nach einem Neustart der Anwendung ebenfalls wieder zur Verfügung stehen Integration in die Communote-Plattform Durch die bestehende Architektur der Communote-Plattform war es nicht möglich alle Funktionalitäten sauber vom Kern zu trennen und diese Modular zur Verfügung zu stellen. Das betrifft vor allem die Widgets und somit alle Teile des Frontends (siehe Kapitel 5.2). Die Problematik war hier, dass es keinen Mechanismus gab, zur Laufzeit JSP- und JavaScript-Dateien, sowie Spring- Mappings der Anwendung bekanntzumachen. Aus dem gleichen Grund mussten die Mappings für das CommunoteSharedBlogsPlugin ebenfalls in die Konfiguration der Kernanwendung übernommen werden. Das Plug-In kann also nicht ohne weiteres ausgetauscht werden, es müssen mindestens die Konfigurationsdateien angepasst und die Anwendung neu gestartet werden. Außerdem mussten Hyperlinks in der Anwendung zum Aufruf der Widgets hart codiert werden, d. h. die Anwendung bot keine Möglichkeit beispielsweise neue Menüpunkte im Administrationsmenü dynamisch hinzuzufügen. Der entstandene Nachteil ist klar: Die entwickelten Komponenten sind trotz der starken Entkoppelung fest mit der Anwendung verbunden. Das Plug-In selbst lässt sich leicht austauschen, aber die darauf zugeschnittenen Frontend-Teile sind fest in die Anwendung integriert und lassen sich zur Zeit nur mit einigem Aufwand deaktivieren. 5.2 FRONTEND-WIDGETS Zur Umsetzung des Frontends wurden mehrere Widgets auf Basis des Communote Widget Frameworks entwickelt. Das Framework wird in der gesamten Communote-Oberfläche eingesetzt und vereinfacht die Entwicklung AJAX-basierter Oberflächen. Abbildung 5.6 zeigt den prinzipiellen Aufbau eines Widgets. Es besteht im Wesentlichen aus drei Teilen: (1) einer Java-Klasse vom Typ Widget für alle Backend-Operationen, (2) einer JavaScript-Klasse für alle Frontend-Operationen und (3) einer JSP-Datei zur Darstellung im Frontend. Die Verwaltung der Widgets wird von einem WidgetController übernommen. Auf die komplette Architektur und Arbeitsweise der Widgets wird hier nicht weiter eingegangen. Eine genauere Beschreibung ist in [20] zu finden. Um den Entwicklungsaufwand zu verringern und die Entwicklung von Widgets zu vereinfachen, wurden im Rahmen dieser Arbeit zwei Annotationen entwickelt: ViewIdentifier Die Annotation ViewIdentifier ersetzt die Methode getviewidentifier der Widget-Schnittstelle und kann auf Klassen angewendet werden. Durch den ViewIdentifier kann dem Frontend-Widget die korrekte Java-Klasse zugeordnet werden. Dank der neuen Annotation wird das Widget übersichtlicher und einfacher zu handhaben. Listing 5.1 zeigt ein Beispiel der Annotation am ListCooperationsWidget. 5.2 Frontend-Widgets 57

66 Abbildung 5.6: Aufbau von Widgets am Beispiel ListCooperationsWidget V i e w I d e n t i f i e r ( " widget. shared. blogs. cooperations. l i s t " ) 2 public class ListCooperationsWidget 3 extends AnnotatedMultiResultWidget <Cooperation >{ 4 5 / / Hier stehen die Methoden, V a r i a b l e n usw. 6 7 } Listing 5.1: Beispiel ViewIdentifier-Annotation WidgetAction Die Verwendung von Widgets führen im Frontend zu Aktionen, welche im Backend ausgeführt werden. Um die Definition von Aktionen zu vereinfachen wurde die WidgetAction-Annotation eingeführt. Diese Annotation wird auf Methoden angewendet und besitzt einen, innerhalb der Klasse eindeutigen Wert als Parameter. Die Methode wird ausgeführt, wenn ein Frontend- Formular abgesendet wird, welches einen Parameter widgetaction mit dem entsprechenden Namen besitzt. Listing 5.2 zeigt die Verwendung der Annotation in der Widget-Klasse, Listing 5.3 im Frontend. Der Vorteil dieser Methode ist, dass man den Code, um eine bestimmte Methode der Klasse aufzurufen, nicht mehr manuell schreiben muss. Vorher war es nötig, den korrekten Aufruf einer Methode mittels switch- oder if-anweisung programmatisch zur Verfügung zu stellen. ( " remove_ cooperation " ) 2 public void removecooperation ( ) { 3 4 / / Entferne die Kooperation. 5 6 } Listing 5.2: Beispiel WidgetAction-Annotation im Backend 1 <form : form> 2 <input type= " hidden " 3 name= " widgetaction " 4 value= " remove_ cooperation " / > 5 6 / / Weitere F o r m u l a r f e l d e r. 7 8 <button type= " submit " name= " button " class= " button "> 9 <span>löschen< / span> 58 Kapitel 5 Implementierung

67 10 < / button> 11 < / form : form> Listing 5.3: Beispiel WidgetAction-Annotation im Frontend Um die Annotationen anwenden zu können, müssen die entsprechenden Klassen von einer speziellen erweiterten Widget-Klasse erben. Diese und ein AnnotationProcessor stellen die korrekte Abarbeitung der Annotationen sicher. Durch die Verwendung der Annotationen wird die Performance der Anwendung nicht gemindert. Der ViewIdentifier wird lediglich bei der ersten Initialisierung der Klasse verwendet und der AnnotationProcesser merkt sich bereits gefundene WidgetAction-Methoden und muss die entsprechende Klasse nicht erneut danach durchsuchen. Folgende Widgets sind entstanden: AnnotatedSingleResultWidget Abstrakte Oberklasse zur Unterstützung der beschriebenen Annotationen für Widgets, welche nur auf einem Datensatz arbeiten. AnnotatedMultiResultWidget Abstrakte Oberklasse zur Unterstützung der Annotationen für Widgets mit einer Liste von Datensätzen. ListCooperationsWidget Dieses Widget listet alle Kooperationen auf und ermöglicht es, bestehende Kooperationen aufzulösen. Es wird sowohl im Adminbereich, als auch für den Nutzer verwendet. InviteUserWidget Dieses Widget ermöglicht es Blogs freizugeben und Nutzer zur Teilnahme einzuladen. Um aktuelle Kooperationen auf dem Blog anzuzeigen, verwendet das Widget das ListCooperationsWidget. AddEndpointAliasWidget Dieses Widget wird verwendet um einem Endpunkt einen Alias zu geben. Es wird sowohl im Administrationsbereich, als auch für den Nutzer verwendet, sobald er eine Kooperation mit einem unbekannten System eingeht EndpointAliasesViewWidget Dieses Widget listet alle Endpunkte mit ihren Aliasen auf. Es ermöglicht den Alias zu verändern oder den Endpunkt aus dem System zu entfernen. AddBlogFromCooperationFormWidget Dieses Widget ermöglicht es einen Blog aus einem Kooperationslink heraus anzulegen und damit gleichzeitig die Kooperation anzunehmen. AddBlogFromCooperationWidget Dieses Widget hat selbst keine Funktionalität und kapselt je nach Einladungslink weitere Widgets. Ist der Einladungslink unbekannt zeigt es z. B. zuerst das AddEndpointAliasWidget an. Erst nach Hinzufügen eines Alias wird das AddBlogFromCooperationFormWidget angezeigt. Im Vergleich zu den Entwürfen aus Kapitel 4.5 sind im Anhang A.3 Screenshots des implementierten Frontends abgebildet. 5.3 RESSOURCEN Das Modell aus Kapitel 4.4 stellt ein transparentes und einheitliches Austauschformat zur Übertragung der Daten zur Verfügung. Der Zugriff auf Elemente des Modells erfolgt via HTTP und wird in Form von Restlet-ServerResources auf dem Server bereitgestellt. Nicht für jedes Element des Modells existiert eine ServerResource, da dies nicht notwendig ist. Die verfügbaren Ressourcen werden weiter unten mit Hilfe ihrer URL innerhalb der API vorgestellt. 5.3 Ressourcen 59

68 Zur Realisierung der Blogsynchronisation 8 nach erfolgreicher Annahme einer Kooperation wurde ebenfalls darauf verzichtet, die Daten via Pull-Prinzip zur Verfügung zu stellen. Stattdessen wurde das Modell um eine Action-Ressource am Blog einer Kooperation erweitert. Unter /cooperations/- coop/blogs/blog/actions können mittels POST Aktionen angestoßen werden. Zur Synchronisation wird z. B. eine SendMessagesAction gesendet. Diese stößt auf der anderen Seite einen asynchronen Nachrichten-Senden-Prozess an, welcher die letzten Beiträge sendet. Diese Vorgehensweise ist sinnvoll, da dadurch der Entwicklungsaufwand sinkt und bei Verwendung einer Server-zu-Server-Architektur die Bandbreite gesenkt und damit Performance gesteigert werden kann. Die Funktionalität, um Nachrichten zu senden, ist sowieso gegeben. Der Aufwand eine neue Action zu entwickeln ist einfacher als die komplizierte Rückgabe möglicherweise komplexer Daten. Folgende Ressourcen stehen in der Webanwendung zur Verfügung und können über ihre URL innerhalb der API aufgerufen werden. Die Darstellung der jeweiligen Ressource erfolgt innerhalb ihres Pfads in der API und unter der Angabe der möglichen HTTP-Methode. Eine vollständige Liste der möglichen Ressourcen befindet sich im Anhang A.2. Bis auf eine, geben alle Ressourcen ein Element vom Typ Response zurück: /version GET /pubkey GET /privkey GET Gibt die Version der API als einfachen String zurück. Diese Ressource verzichtet als einzige auf die Verwendung eines Modellelements zur Rückgabe des Ergebnisses. Diese Resource gibt den öffentlichen Schlüssel des Systems zurück. Diese Resource gibt den privaten Schlüssel des Systems zurück. Der Zugriff ist nur bei gesetztem exposeprivatekey-flag möglich. /cooperations/invitations/{invitationid} GET Holt Informationen über die angegebene Einladung ein. POST Nimmt die angegebene Einladung an. /cooperations/{cooperationid} DELETE Kündigt die angegebene Kooperation. /cooperations/{cooperationid}/blogs/{blogid} GET Gibt Informationen über den ausgewählten Blog zurück. /cooperations/{cooperationid}/blogs/{blogid}/messages POST Mittels POST kann über diese Ressource eine neue Nachricht hinzugefügt werden. /cooperations/{cooperationid}/blogs/{blogid}/messages/{messageid} DELETE Löscht die angegebene Nachricht. /cooperations/{cooperationid}/blogs/{blogid}/messages/{messageid}/attachments/{id} GET Gibt den angeforderten Anhang zurück. /cooperations/{cooperationid}/blogs/{blogid}/actions POST Fügt dem Blog eine auszuführende Aktion hinzu. /cooperations/{cooperationid}/blogs/{blogid}/users/{userid} GET Gibt Informationen über den ausgewählten Nutzer zurück 5.4 WEITERE DETAILS Zusätzliche Initialisierungsparameter der SharedBlogsApplication sind die beiden Flags ignore- Signature und exposeprivatekey. Ist ignoresignature gesetzt wird die Signatur bei Anfragen ignoriert, exposeprivatekey stellt den privaten Schlüssel ebenfalls als Ressource bereit. Beide Parameter sind standardmäßig deaktiviert und dienen nur zu Testzwecken und sollten im Produktiveinsatz nicht gesetzt werden. 8 Mit Synchronisation ist hier nicht gemeint, dass sich die Blogs ständig gegenseitig aktualisieren, sondern bereits vor der Kooperation enthaltene Nachrichten zur Verfügung gestellt werden. 9 Dieser Wert ist in der Anwendung konfigurierbar. 60 Kapitel 5 Implementierung

69 Statt des Hosts des Systems, wurde für die Global Id eine UUID verwendet. D. h. jeder Host erzeugt für sich eine UUID. Dadurch kann sich die Adresse eines Systems ändern, ohne dass sich die Global Id der Daten ändert. Zeitgleich wird damit allerdings die Rückverfolgbarkeit der Beiträge erschwert, da es nur unter genauem Wissen des Systems, welches die UUID verwendet, möglich ist darauf zu schließen. Ein weiterer Nachteil ist, dass UUIDs zwar eindeutig sind, aber ohne zusätzlichen Aufwand nicht verhindert werden kann, dass mehrere Systeme die gleiche UUID zu verwenden. Ein prinzipiell einfacher Ansatz ist eine zentrale Vergabestelle für UUIDs. Allerdings widerspricht das den Grundzügen dezentraler und unabhängiger Systeme. So ist sicher davon auszugehen, dass nicht jedes System in einem solchen Verzeichnis gelistet werden will oder darf. Intern werden die Übertragungsparameter in einer TreeMap 10 vorgehalten. Die Abbildung der Parameter durch eine TreeMap garantiert eine aufsteigende, natürliche Ordnung der Parameter anhand ihres Schlüssels. Da der Schlüssel als String abgelegt wird, erfolgt die Ordnung alphabetisch. Anhänge werden nicht direkt, sondern als Referenz (ExternalAttachment) auf die entsprechende Ressource versendet. Das Partnersystem kann sich die Anhänge dann einzeln anfordern. Bei Anforderung des Anhang innerhalb des API-Pfades werden diese als EmbeddedAttachment zurückgegeben. Diese Vorgehensweise hat den Vorteil, dass nicht zu große Nachrichten auf einmal gesendet werden und damit möglicherweise irgendwelche Grenzen, wie Timeouts, überschritten werden, da die Dateianhänge wie Downloads angefordert werden können. Durch die Verwendung von Maven konnte der komplette Build-Prozess fast ohne weiteres in das bestehende Continues Integration-System 11 integriert werden. Da die Eclipse-Entwickler allerdings nicht auf Maven setzen und das bestehende Maven-Plug-In zur Generierung von Code aus Ecore-Modellen nicht mit Eclipse 3.5 kompatibel ist, wird hier ein anderer Build-Prozess verwendet. Es gibt einen Ant-Task 12, welcher Eclipse im so genannten Headless-Modus startet. Dabei wird Eclipse so ausgeführt, dass es ein bestimmtes Plug-In verwendet, um eine bestimmte Aufgabe abzuarbeiten. Damit kann verhindert werden, dass die grafische Oberfläche von Eclipse gestartet wird, was auf den meisten Continues Integration-Systemen nicht möglich ist, da diese oft auf einer Serverumgebung ohne grafische Oberfläche laufen. Dadurch konnte die Code-Generierung ebenfalls in den automatischen Build-Prozess integriert werden. Es musste lediglich eine aktuelle Eclipse-Version auf dem System zur Verfügung gestellt werden. Zum Loggen von Aktionen und Fehlern innerhalb der Anwendung wurde das bekannte Log4J 13 verwendet. 10 TreeMap: 11 Hudson: 12 EcoreGeneratorTask für Ant: javadoc/org/eclipse/emf/importer/ecore/taskdefs/ecoregeneratortask.html 13 Apache Log4J: 5.4 Weitere Details 61

70 62 Kapitel 5 Implementierung

71 6 EVALUIERUNG Die Evaluierung der Lösung setzt sich aus drei Teilen zusammen. Zu Beginn werden in Abschnitt 6.1 Modul- und einfache Performancetests beschrieben, mit deren Hilfe gezeigt wird, dass die Anwendung statisch funktioniert. Durch eine Nutzerbefragung in Abschnitt 6.2 wurde versucht den ersten Eindruck der Anwendung einzufangen und somit zu zeigen, dass die gewählten Frontend- Methoden den Erwartungen der Nutzer im Wesentlichen entsprechen. Der letzte Teil des Kapitels (Abschnitt 6.3) prüft inwieweit die Anforderungen aus Kapitel 2.2 erfüllt werden konnten. 6.1 TESTS Modultests Zur Überprüfung der Korrektheit und Qualitätssicherung wurden für die Implementierung der SharedBlogsApi verschiedene automatische Modultests geschrieben. Als Testframework wurde TestNG 1 eingesetzt. TestNG erweitert das bekannte JUnit 2 -Framework, um nützliche Funktionalitäten wie die Gruppierung von Tests und eine deutlich einfachere Konfiguration. Es findet eine breite Anwendung und kann u.a. nahtlos mit Eclipse und Maven, und damit auch dem Continous Integration-System, verwendet werden. Neben dem Test sämtlicher Hilfsklassen werden alle ApiCalls und damit auch Ressourcen getestet. Zur Realisierung der Tests wird ein Webserver benötigt, der die SharedBlogsApplication als REST-Anwendung bereitstellt und somit den Zugriff für die ApiCalls ermöglicht. Ein einfacher Server 3 ist bereits in Restlet enthalten und konnte dafür verwendet werden. Da die SharedBlogsApi unabhängig vom Communote ist wurden ein zusätzlicher ResourceProvider und RequestHandler zur Bereitstellung von Testdaten realisiert. Diese Stellen keine ausführlichen Daten bereit, sondern erzeugen in Abhängigkeit der Eingabeparameter einen Erfolg oder Misserfolg. Außerdem wurde der Filter zur Überprüfung der Zugriffsberechtigung für Kooperationen gegen einen ausgetauscht, der einen Zugriff immer erlaubt. Bereits hier ist zu erkennen, dass die API ohne besonderen Aufwand in eine Umgebung eingebettet und verwendet werden kann. Die Tests der ApiCalls funktionieren immer nach dem gleichen Muster. Es werden zwei Anfragen gesendet. Die erste Anfrage verwendet als Parameter eine gerade und die zweite eine ungerade 1 TestNG: 2 JUnit: 3 Basiert auf Jetty: 63

72 Abbildung 6.1: Prinzip der Modultests Zufallszahl. Der TestResourceProvider und der TestRequestHandler sind so konzipiert, dass sie bei einer geraden Zahl einen Erfolg zurückgeben und bei einer ungeraden Zahl einen Misserfolg, wodurch sich erfolgreiche und erfolglose Anfragen simulieren lassen. Zusätzlich zur zufälligen Zahl, werden weitere zufällige Parameter erzeugt, welche für einen Teil der Tests verwendet werden. Abbildung 6.1 zeigt das Prinzip der Tests am Beispiel des TerminateCooperationCalls, welcher eine bestehende Kooperation auflöst. Der Test nutzt den ApiCall und verwendet ihn zunächst mit einer geraden Zahl als Parameter für die Kooperation. Die CooperationResource auf dem Server wertet die Anfrage aus und leitet sie an den TestRequestHandler weiter. Da der Parameter gerade ist, gibt der Handler einen Erfolg zurück, welcher von der Ressource als SuccessResponse- Element an den Test zurück geliefert wird. Beim zweiten Aufruf wird eine ungerade Zahl als Parameter für die Kooperation gesendet. Dieses mal bricht der TestRequestHandler mit einem Fehler ab und die Ressource sendet ein ErrorResponse-Element zurück Performancetests Um die Leistungsfähigkeit der Anwendung eingrenzen und beurteilen zu können wurde das Programm JMeter 4 verwendet. JMeter ist ein freies Werkzeug der Apache Software Foundation und wurde entworfen, um Client-Server-Anwendungen unter Last testen zu können. In der Regel ist das Ziel der Tests die Grenzen und Flaschenhälse eines Systems erkennen zu können. Typische Fragestellungen sind: Wie viele Nutzer können gleichzeitig zugreifen oder wie hoch ist die Anzahl der maximalen Datenbankverbindungen? Zur Ausführung der Tests verwendet JMeter sogenannte Testpläne. Die Testpläne selbst können mit Hilfe der graphischen Oberfläche des Programms erstellt und verwaltet werden. Die Testausführung kann allerdings auch in den Build- Prozess, z. B. mit Maven, eingebunden werden. Durch seine vielfältigen Funktionen kann JMeter ebenfalls als Werkzeug für Frontendtests einer Webanwendung eingesetzt werden. Ziel der Tests dieser Arbeit ist es nicht Communote unter Vollast zu stellen und seine Grenzen zu finden. Das CommunoteSharedBlogsPlugin ist ja nur ein kleiner Bestandteil des Systems. Mit Hilfe der folgenden Tests sollen vor allem Antwortzeiten bestimmter Teile des Plug-Ins gemessen werden. Daraus wird dann versucht abzuleiten, welche Teile bereits ausreichend schnell arbeiten und wo Engpässe zu finden sind und was Gründe dafür sein könnten. 4 JMeter: 64 Kapitel 6 Evaluierung

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009

RSS Push Verfahren. Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI. 18. November 2009 RSS Push Verfahren Hongliang Jiang, Roland Höpfner Seminar Moderne Webtechnologien AG-NBI 18. November 2009 1 Übersicht RSSFeeds Polling Push RSSCloud PubSubHubBub Vergleich Quellen 2 Feeds FU-Berlin Institut

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

XMPP: Extensible Messaging and Presence Protocol

XMPP: 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

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

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

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

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

Workflow, Business Process Management, 4.Teil

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

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

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

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis

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...

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Zustandsgebundene Webservices

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

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Online Bedienungsanleitung elektronisches Postfach

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

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Das eigene Kandidatenfrontend

Das eigene Kandidatenfrontend Das eigene Kandidatenfrontend THEMA: Mit dem BeeSite API zum eigenen Job Board Dr. Sascha Juchem R&D Abteilung sascha.juchem@milchundzucker.de AGENDA Mit dem BeeSite API zum eigenen Job Board 01 Einleitung

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Mobilkommunikation REST-basierte Dienste für verteilte, mobile Anwendungen A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Fachhochschule Köln, Institut für Nachrichtentechnik Fachhochschule Köln Anton Gillert,

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08

XML-RPC & SOAP. Sven Heß & Fabio Caprera Systemprogrammierung SS 08 XML-RPC & SOAP & Fabio Caprera Systemprogrammierung SS 08 Inhalt XML-RPC Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile SOAP Überblick Entstehung Konzept Fehlerbehandlung Vor- und Nachteile

Mehr

Securing SOAP e-services

Securing SOAP e-services Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung

Mehr

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

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

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

Erstellen von Mailboxen

Erstellen von Mailboxen Seite 1 von 5 Erstellen von Mailboxen Wenn Sie eine E-Mail-Adresse anlegen möchten, mit Ihrem Domain-Namen, z. B. IhrName@Domain.com, müssen Sie eine Mailbox erstellen. Gehen Sie hierzu wie folgt vor:

Mehr

Anlage 3. EBICS- Anbindung. Folgende Legitimations- und Sicherungsverfahren werden in der EBICS-Anbindung eingesetzt:

Anlage 3. EBICS- Anbindung. Folgende Legitimations- und Sicherungsverfahren werden in der EBICS-Anbindung eingesetzt: Anlage 3 EBICS- Anbindung 1. Legitimations- und Sicherungsverfahren Der Kunde (Kontoinhaber) benennt dem Kreditinstitut die Teilnehmer und deren Berechtigungen im Rahmen der Datenfernübertragung auf dem

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Status DI Philip Helger, BRZ 16.06.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Status DI Philip Helger, BRZ 16.06.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Status DI Philip Helger, BRZ 16.06.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ziele Prozesse Nachrichteninhalt Organisatorische Rahmenbedingungen

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

Technische Beschreibung: EPOD Server

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

Mehr

Anwendungsprotokolle: HTTP, POP, SMTP

Anwendungsprotokolle: HTTP, POP, SMTP Anwendungsprotokolle: HTTP, POP, SMTP TCP? UDP? Socket? eingesetzt, um Webseiten zu übertragen Zustandslos Nutzt TCP Client schickt Anfrage ( HTTP-Request ) an Server, Server schickt daraufhin Antwort

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

SMS-Gateway HTTP(S) Schnittstellenbeschreibung

SMS-Gateway HTTP(S) Schnittstellenbeschreibung SMS-Gateway HTTP(S) Schnittstellenbeschreibung Version 1.01 02.05.2013 Web: http://www.sms-expert.de Allgemeine Beschreibung der HTTP(S)- Schnittstelle des SMS-Gateways Inhaltsverzeichnis 1. Einleitung...

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

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

Mehr

Man liest sich: POP3/IMAP

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

Mehr

Jabber. Florian Holzhauer. Proseminar Uni Ulm, 27. April 2005.

Jabber. Florian Holzhauer. Proseminar Uni Ulm, 27. April 2005. <page=1 max=22/> Jabber Florian Holzhauer Proseminar Uni Ulm, 27. April 2005 Idee, Geschichte Nachrichtentechnik Ausblick, Zukunft Gründe / Intention Grosse

Mehr

email, Applikationen, Services Alexander Prosser

email, Applikationen, Services Alexander Prosser email, Applikationen, Services Alexander Prosser WWW für Menschen und Maschinen SEITE 2 (C) ALEXANDER PROSSER WWW für Menschen (1) Mensch gibt Adresse ein, z.b. evoting.at oder klickt Link an (2) Server

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr

Der Austausch von Informationen erfolgt zunehmend über elektronische Medien.

Der Austausch von Informationen erfolgt zunehmend über elektronische Medien. Vorwort Der Austausch von Informationen erfolgt zunehmend über elektronische Medien. Neben den großen Vorteilen, welche uns diese Medien bieten, bergen Sie aber auch zunehmend Gefahren. Vorgetäuschte E-Mail-Identitäten,

Mehr

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken In diesem Tutorial zeigen wir Ihnen, wie Sie im Mozilla Thunderbird E-Mailclient ein POP3-Konto einrichten. Wir haben bei der Erstellung des Tutorials die Version 2.0.0.6 verwendet. Schritt 1: Auswahl

Mehr

Collax E-Mail Archive Howto

Collax E-Mail Archive Howto Collax E-Mail Archive Howto Howto Dieses Howto beschreibt wie ein Collax Server innerhalb weniger Schritte als E-Mail Archive eingerichtet werden kann, um Mitarbeitern Zugriff auf das eigene E-Mail Archiv

Mehr

Loadbalancing und Clustering mit Tomcat 6

Loadbalancing und Clustering mit Tomcat 6 Loadbalancing und Clustering mit Tomcat 6 Java Forum Stuttgart 3. Juli 2008 Michael Heß ORDIX AG, Paderborn mhe@ordix.de www.ordix.de Agenda Zielsetzung des Vortrags Webserver Integration Loadbalancing

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Secure E-Mail der Suva

Secure E-Mail der Suva Secure E-Mail der Suva Informationsbroschüre für Entscheidungsträger und IT-Verantwortliche SEM_Informationsbroschuere_06-2013_de / WasWoShop: 2979/1.D 1 Inhaltsverzeichnis Secure E-Mail der Suva auf einen

Mehr

Benutzerhandbuch WordPress

Benutzerhandbuch WordPress Benutzerhandbuch WordPress Handbuch zur Erstellung eines Weblogs Copyright 2008 by Eva-Maria Wahl & Dennis Klehr Inhaltsverzeichnis 1. Einführung 3 1.1 Blog 3 1.2 Web 2.0 3 1.3 Content Management System

Mehr

Reporting Services Dienstarchitektur

Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur In Reporting Services wird ein Berichtsserver als ein Windows - Dienst implementiert, der aus unterschiedlichen Featurebere i-

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Client/Server-Systeme

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

Mehr

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de XML-RPC, SOAP und Web Services Jörn Clausen joern@techfak.uni-bielefeld.de Übersicht Was ist RPC? Was hat XML mit RPC zu tun? Was sind XML-RPC und SOAP? Was sind Web Services? Wird das die Welt retten?

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

Apache HTTP-Server Teil 2

Apache HTTP-Server Teil 2 Apache HTTP-Server Teil 2 Zinching Dang 04. Juli 2014 1 Benutzer-Authentifizierung Benutzer-Authentifizierung ermöglicht es, den Zugriff auf die Webseite zu schützen Authentifizierung mit Benutzer und

Mehr

Information über die Secure E-Mail

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

Mehr

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL TCP/IP: Standard Protokolle Konrad Rosenbaum, 2006/7 DNS - Domain Name System hierarchische, global verteilte Datenbank löst Namen in IP-Adressen auf Host hat einen primären Nameserver, der Fragen selbst

Mehr

SINT Rest App Documentation

SINT Rest App Documentation SINT Rest App Documentation Release 1.0 Florian Sachs September 04, 2015 Contents 1 Applikation 3 2 Rest Service 5 3 SOAP Service 7 4 Technologiestack 9 5 Deployment 11 6 Aufgabe 1: Google Webservice

Mehr

Outlook Web App 2010. Kurzanleitung. interner OWA-Zugang

Outlook Web App 2010. Kurzanleitung. interner OWA-Zugang interner OWA-Zugang Neu-Isenburg,08.06.2012 Seite 2 von 15 Inhalt 1 Einleitung 3 2 Anmelden bei Outlook Web App 2010 3 3 Benutzeroberfläche 4 3.1 Hilfreiche Tipps 4 4 OWA-Funktionen 6 4.1 neue E-Mail 6

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

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

Mehr

AlwinPro Care Modul Schnittstelle TV-Steuerung

AlwinPro Care Modul Schnittstelle TV-Steuerung AlwinPro Care Modul Schnittstelle TV-Steuerung Beschreibung AlwinPro Care bietet die Möglichkeit TV für tageweise abzurechnen und stellt für die Freischaltung der Leistung einen Authentifizierungsserver

Mehr

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

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

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Roadtrip Plugin. Dokumentation

Roadtrip Plugin. Dokumentation Roadtrip Plugin Dokumentation Inhaltsverzeichnis Beschreibung... 3 Installation... 3 Konfiguration der Dienste... 3 Erläuterung...3 Twitter...3 Instagram... 5 Konfiguration der User...5 Eingabe... 5 Aktivierung...

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

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

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17 xi 1 Einleitung 1 1.1 Warum REST?...................................... 1 1.1.1 Lose Kopplung................................ 2 1.1.2 Interoperabilität............................... 3 1.1.3 Wiederverwendung.............................

Mehr

Google Cloud Print Anleitung

Google Cloud Print Anleitung Google Cloud Print Anleitung Version A GER Zu den Hinweisen In diesem Benutzerhandbuch wird für Hinweise der folgende Stil verwendet: Hinweise informieren Sie darüber, wie auf eine bestimmte Situation

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG Obwohl inzwischen immer mehr PC-Nutzer wissen, dass eine E-Mail so leicht mitzulesen ist wie eine Postkarte, wird die elektronische Post

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

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

Mehr

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

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

Mehr

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle Version: 1.0.0 Datum: 2013-11-20 Autor: Bernd Ennsfellner, Renate Pinggera gizmocraft, design and technology GmbH

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ausgangsbasis Webservice bei E-RECHNUNG.GV.AT SERWS Ziele

Mehr

DirectSmile CrossMedia und Salesforce

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

Mehr

Appery.io Mobile Apps schnell und einfach entwickeln

Appery.io Mobile Apps schnell und einfach entwickeln Appery.io Mobile Apps schnell und einfach entwickeln Cloud-basierte Entwicklungsumgebung, keine lokale Installation von Entwicklungsumgebung nötig. Technologie: HTML5. JQuery Mobile, Apache Cordova. Plattformen:

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers

GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers GeoServer in action Fortgeschrittene Möglichkeiten beim Einsatz des Geoservers Nils Bühner buehner@terrestris.de terrestris GmbH & Co KG Über uns Nils Bühner buehner@terrestris.de github.com/buehner Informatiker

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

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

Mehr

DROOMS Q&A / SPEZIALISTENSICHT HANDBUCH. www.drooms.com

DROOMS Q&A / SPEZIALISTENSICHT HANDBUCH. www.drooms.com HANDBUCH www.drooms.com DROOMS Q&A / SPEZIALISTENSICHT HANDBUCH Werter Nutzer, Egal ob Sie im Rahmen einer Due Diligence Fragen stellen, diese beantworten oder den Q&A-Prozess insgesamt verwalten wollen:

Mehr

Collax Mailserver. Howto. Dieses Howto beschreibt die Einrichtung eines Collax Servers als Mailserver.

Collax Mailserver. Howto. Dieses Howto beschreibt die Einrichtung eines Collax Servers als Mailserver. Collax Mailserver Howto Dieses Howto beschreibt die Einrichtung eines Collax Servers als Mailserver. Vorraussetzungen Collax Business Server Collax Groupware Suite Collax Platform Server inkl. Collax Modul

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

RACFBroker/z. Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP. RACFBroker/z ist ein Produkt der

RACFBroker/z. Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP. RACFBroker/z ist ein Produkt der RACFBroker/z Entfernter Zugriff auf das RACF Sicherheitssystem auf IBM Mainframes über TCP/IP RACFBroker/z ist ein Produkt der XPS Software GmbH Eching RACFBroker/z XPS Software GmbH Untere Hauptstr. 2

Mehr

Grundlagen Contenent Management

Grundlagen Contenent Management Grundlagen Contenent Management Andreas Anstock Inhaltsangabe: Kapitel 1: Definition Was ist Content Management? Was ist ein Content Management System? Kapitel 2: Motivation Kapitel 3: Der Content Lifecycle:

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

Magistrat Steyr Version 2.7

Magistrat Steyr Version 2.7 Version 2.7 24.06.2014 Wolfgang Patscheider E-Mail-Policy 24.06.2014 Seite 1 Inhaltsverzeichnis: 1. Geltungsbereich... 3 2. Allgemeine Grundsätze... 3 3. Einsatzgebiete von E-Mail... 3 4. Organisatorische

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

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

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

Mehr