Entwicklung eines mobilen Web-Systems mit integrierter Wissensdatenbank zur Unterstützung von industriellen Instandsetzungsprozessen: Kommunikationsmodul

Inhaltsverzeichnis

1. Vorbetrachtung
1.1. Zweck
1.2. Ziel
1.3. Aufgabenbeschreibung
1.4. Kapitelstruktur

2. Grundlagen
2.1. JSF 2
2.2. JPA 2
2.3. XHTML
2.4. Applikationsserver
2.5. WebRTC
2.5.1. WebRTC Protokolle
2.5.2. RTCPeerConnection
2.6. Websocket
2.7. REST Web Services
2.8. JSON
2.9. Kurento
2.9.1. GStreamer
2.9.2. H
2.9.3. Kurento Module

3. Analyse
3.1. Erhebung
3.2. Analyseergebnis
3.2.1. Ressourcen des Kommunikationsmoduls
3.2.2. User Stories
3.2.3. Funktionale Anforderungen
3.2.4. Nicht-funktionale Anforderungen
3.3. Schnittstellen zu den anderen Projektbeteiligten

4. Konzeption
4.1. Kontinuierliche Integration
4.1.1. Versionsverwaltung
4.1.2. Build Automation
4.1.3. Deployment Pipeline
4.2. Kommunikationsprozess
4.2.1. Medienverhandlungsphase
4.2.2. Medienaustauschphase
4.2.3. Zusammenspiel der einzelnen Teilkomponenten

5. Realisierung

5.1. Kommunikation
5.1.1. Verbindung zum Media Server herstellen
5.1.2. Methoden des Media Servers
5.1.3. Einen anderen Benutzer kontaktieren
5.1.4. Verbindungsabbruch

6. Qualitätssicherung
6.1. Evaluierung
6.1.1. Interviews
6.1.2. Szenarien
6.1.3. Nicht-funktionale Anforderungen .

7. Fazit und Ausblick

A. Anforderungsanalyse
A.1. ÜbersichtfunktionaleAnforderungen

B. Media Server
B.1. Komplette Methodenliste des Media Servers
B.2. Beispielhafte Methodenverwendung

C. Interview
C.1. Ausgefüllte Interview Bögen

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Quellenverzeichnis

1. Vorbetrachtung

An die industrielle Produktion werden jetzt und mit hoher Wahrscheinlichkeit umso mehr in Zukunft hohe Anforderungen gestellt. Sie muss intelligent, wandelbar, effizient und nachhaltig sein. Die Verfügbarkeit von Produktionsanlagen gewinnt speziell im Zeitalter globaler Märkte immer mehr an Bedeutung und ist für den nachhaltigen Erfolg von Unternehmen entscheidend. Die Instandhaltung technischer Anlagen steht im direkten Zusammenhang mit der Wettbewerbsfähigkeit eines Unternehmens und leistet somit einen entscheidenden Beitrag zum Unternehmensergebnis.

Auch die Anforderungen an die Zusammenstellung von Instandhaltungsteams haben sich im laufe der Zeit verändert. Durch immer komplexer werdende Anlagensysteme, verknüpft mit elektronischen Komponenten und Computersystemen, werden vermehrt Spezialisten aus den Bereichen Elektronik und Informationstechnologie für die Instandhaltung benötigt. In vielen Fällen betreuen externe Experten und Berater gemeinsam mit den firmeneigenen Anlagentechnikern die instand zu haltenden technischen Objekte. Durch diese globalen Entwicklungen wird der Instandhaltung eine immer wichtigere Rolle zugeschrieben. Eine zielgerichtete und modern aufgestellte Instandhaltung kann zu einem entscheidenden Wettbewerbsvorteil führen. Um einen derartigen Vorteil für die Instandhaltung und damit das gesamte Unternehmen zu erzielen, ist es hilfreich, die benötigten Instandhaltungsprozesse durch moderne Kommunikationsund Informationstechnologien zu unterstützen.

1.1. Zweck

Vielerorts werden Ressourcen bei der Wartung eines technischen Systems ineffizient genutzt. Dies kann sowohl zu höheren Ausfallzeiten bei der Produktion und damit auch zu einem Verlust bei den Einkünften eines Unternehmens führen.

Fällt beispielsweise in einem Hotel der Fahrstuhl aus, so wird zuerst das Herstellerunternehmen des Fahrstuhls kontaktiert. Ist nun kein Techniker vor Ort anwesend, muss ein Techniker zu dem Hotel fahren, um sich das Problem anzusehen, eventuell wieder zurückfahren, um ein Ersatzteil zu besorgen, oder zu bestellen. Anschließend kann er dieses Ersatzteil einbauen, sodass der Fahrstuhl wieder funktionsfähig ist. Diese Leerlaufzeiten erzeugen Kosten beim Hersteller, sowie Ausfallzeiten beim Hotelbetreiber. Durch den Einsatz von modernen Technologien könnten diese drastisch gesenkt werden. Der Einsatz einer mobilen Instandhaltungssoftware hat das Potential Fehlermeldevorgänge effektiver zu gestalten.

1.2. Ziel

Diese Bachelorarbeit entsteht im Rahmen eines Teamprojekts. Ziel des Teamprojekts ist die Konzeption und prototypische Entwicklung eines mobilen Web-Systems zur Unterstützung von Instandhaltungsprozessen. Inspiriert ist sie aus der Vision Industrie 4.0. Das Web-System soll es einem Techniker ermöglichen, Probleme an Anlagen zu identifizieren und sie in einem Ticketsystem zu dokumentieren, ohne Vorort anwesend zu sein. Er kann auf eine Wissensdatenbank mit den bekannten Problemen zu diesen Anlagen zurückgreifen. Für die Wartung beauftragte Mitarbeiter sollen die Beschreibung eines Defekts in Form einer Problemmeldung an den zuständigen Hersteller senden können. Unterstützt wird der Prozess durch einen Echtzeitchat, eine Kommentarfunktion und einen Livestream. Durch Ihren Einsatz sollen Unternehmen Kosten und Lösungszeit sparen, in dem die Ausfallzeiten von defekten Geräten verringert werden.

Ferner dient die Bachelorarbeit der Verschriftlichung und Darstellung der zugrundeliegenden Prozesse und Erkenntnisse während des gesamten Entwicklungsprozesses.

1.3. Aufgabenbeschreibung

Zentraler Bestandteil dieser Bachelorarbeit ist die Konzeption und Entwicklung eines Prototypen für das Kommunikationsmodul des Web-Systems. Das Kommunikationsmodul stellt Schnittstellen bereit, welche sowohl von der mobilen Komponente, als auch von der Webanwendung genutzt werden können. Für die Umsetzung muss ein geeignetes Kommunikationsprotokoll erörtert und eingesetzt werden. Die dabei verwendeten Technologien sollen in ihren Grundlagen erläutert, und auf ihren Nutzen untersucht werden. Abschließend wird die Umsetzung evaluiert und hinsichtlich ihres Mehrwerts kritisch reflektiert, um so die Tauglichkeit für den produktiven Einsatz einschätzen zu können.

1.4. Kapitelstruktur

Zu Beginn wird in Kapitel 2 ein Einblick in die verwendeten Technologien gegeben.

Anschließend werden in Kapitel 3 die Analyseergebnisse beschrieben. Dabei werden die Anwendungsfälle erläutert, die zur Erhebung und zur Spezifikation der funktionalen Anforderungen an das Web-System entwickelt worden sind. Die Ergebnisse dieser Erhebung werden in einem Funktionskatalog festgehalten, der die funktionalen und nicht-funktionalen Anforderungen an das System darlegt.

Das Kapitel 4 beschreibt die Konzeption. In diesem Kapitel werden die für die Entwicklung wichtige Rahmenbedingungen erläutert. Daraufhin wird der in der Planungsphase entstandene Kommunikationsprozess erläutert.

Das 5. Kapitel beschäftigt sich mit der Realisierung. Es beschreibt die Entwicklung des Prototypen und die Umsetzung des in Kapitel 4 beschriebenen Kommunikationsprozesses. Darüber hinaus wird die Umsetzung der markante Eigenschaften des Kommunikationsmoduls erläutert.

Gefolgt wird diese Realisierung von den Maßnahmen der Qualitätssicherung. Dabei wird das angewandte Testkonzept erläutert, und eine durchgeführte Evaluierung der Anwendung beschrieben.

Abschließend wird ein Ausblick über die Zukunft des Projektes dargelegt und ein Fazit präsentiert.

2. Grundlagen

Um die folgenden Kapitel leichter verständlich zu machen, werden in diesem Kapitel Begriffe und verwendete Technologien grundlegend eingeführt.

2.1. JSF 2.2

Java Server Faces ist eine Technologie, um Web-Benutzeroberflächen zu entwickeln und ist Teil der Java EE Spezifikation. Die Referenzimplementierung der JavaServer Faces ist Mojarra. [vgl. Mül10, S. 10] JSF beinhaltet verschiedene Komponenten, die auf der Oberfläche durch Standard HTML Komponenten dargestellt werden. Der Vorteil besteht in der logischen Trennung der reinen HTML-Darstellung und der Logik, die in Java implementiert ist. Durch die Darstellung von HTML Code ist JSF plattformunabhängig und kann in jedem Webbrowser dargestellt werden. Ein weiterer Vorteil besteht neben der serverseitigen Validierung auch darin, die Komponenten durch Bibliotheken zu erweitern.

Per Expression Language kann auf Objekte und Methoden von Managed-Beans zugegriffen werden.

2.2. JPA 2.1

Die Java Persistence API ist ein Standard zur Realisierung des Objektrelationalen Mappings (ORM) und durch den Java Community Process im JSR 338 definiert. [vgl. JSR338] ORM ermöglicht die Abbildung von Standard-Java-Objekten (POJO) auf Datenbanktabellen. Neben der Referenzimplementierung EclipseLink, ist Hibernate eine weitere Implementierung des JPA-Standards. [vgl. MW12, S.17]

Die Tabellenstruktur wird in einer Java-Klasse über Annotationen definiert. Um aus einem POJO eine Entität zu erstellen müssen mindestens folgende Metadaten definiert werden:

- @Entity vor der Klassendefinition
- Definition eines Attributs als Schlüsselspalte mit Annotation @Id

Zudem muss ein Standard-Konstruktor in der Klasse definiert werden. Mit Hilfe des JPAProviders werden die Attribute und META-Informationen einer Entity-Klasse interpretiert und auf eine relationale Datenbank abgebildet. Um auf das Persistenzmedium zuzugreifen, muss ein EntityManager integriert werden, der verschiedene Funktionen implementiert. Er ist die Schnittstelle zwischen Geschäftsanwendung (Serviceschicht) und dem Persistenzbereich. Mit Hilfe von Hibernate können individuelle Queries definiert werden. Diese werden interpretiert, auf die jeweiligen Datenbanksprache übersetzt und auf die Datenbank angewandt.

2.3. XHTML5

HTML5 ist die fünfte Version der Hypertext Markup Language und wurde 2014 vom World Wide Web Consortium spezifiziert. Im Gegensatz zu den älteren Versionen kam in dieser Version die Multimediafunktionalität hinzu. So werden direkt in der Auszeichnungssprache Video, Audio oder dynamische 2D- und 3D Grafiken unterstützt.

XHTML steht für Extensible Hypertext Markup Language. Der Unterschied zu HTML ist, dass der XHTML Standard hundertprozentig XML Konform ist. [vgl. W3CHTML]

2.4. Applikationsserver

Im Bereich Java EE unterstützen einige Server den Java EE Standard. GlassFish V4.X ist die Referenz-Implementierung des Java EE Version 7 Standards und unterstützt somit die neusten Standards der Enterprise Edition (JSR 342). [vgl. Jav16] Glassfish unterstützt in seiner Grundkonfiguration JSF 2.2, JPA 2.1, Webservices und viele weitere Technologien und Standards. Des Weiteren besitzt GlassFish eine sehr umfangreiche Administrationsoberfläche.

2.5. WebRTC

WebRTC steht für Web Real-Time Communication und ist ein neues, quelloffenes Framework für das Web, welches es ermöglicht in Echtzeit Audio- und Videosignale auszutauschen. Es wurde 2011 von Google quelloffen veröffentlicht, beinhaltet alle grundlegenden Komponenten um Kommunikationsanwendungen für das Web zu entwickeln und befindet sich weiterhin in Entwicklung. Die einzelnen Komponenten können über eine JavaScript API angesteuert werden, wodurch die Nutzung von Drittanbieterkomponenten nicht mehr notwendig ist. Google, Mozilla und Opera unterstützen das WebRTC Projekt und sind in den Entwicklungsprozess involviert. [vgl. WRTC16]

Die Browser API wird von der Web Real-Time Communications Working Group des World Wide Web Consortiums weiterentwickelt. [vgl. W3C16] Die Erstellung der Protokollspezifikationen ist die Aufgabe der RTCWeb Group der Internet Engineering Task Force (IETF). [vgl. IETF16]

2.5.1. WebRTC Protokolle

UDP

Das User Datagram Protocol ist ein Teil der Internetprotokollfamilie. Es arbeitet auf der Transportschicht des OSI-Modells und setzt auf dem IPv4 oder IPv6 auf. Es ist ein verbindungsloses und nicht-zuverlässiges Transportprotokoll ohne Verschlüsselung, in dem die Daten in Datagramen übertragen werden. [vgl. UDP16]

UDP bietet die Dienstgüte best effort, also das Versenden der Daten unter bester Ausnutzung der Ressourcen. Damit wird eine möglichst geringe Latenz erwirkt, allerdings auch ein möglicher Paketverlust akzeptiert. [vgl. ITW16] Somit bildet UDP die Grundlage für die zeitemfpindliche Echtzeitkommunikation und wird häufig für Miltumedia-Verbindungen eingesetzt.

STUN

STUN steht für Simple Traversal of UDP through NATs (Network Address Translation. Es ist ein UDP-basiertes Protokoll und dient der NAT Traverse. Es ermittelt die öffentliche IP und die offenen Ports eines Peers. Zur Ermittlung der IP und nutzbaren Ports wird ein STUNServer angesprochen und aufgefordert, die IP zurückzusenden, welche als Absender der Anfrage angegeben wurde. Diese Anfragen werden initial über Port 3478 versendet, allerdings weist der STUN Server Clients an auch Verbindungstests über eine andere IP und einen anderen Port durchzuführen. Laut RFC 3489 sind diese aber nicht fest vorgegeben.[vgl. RFC3489]

TURN

Beim Traversal Using Relays around NAT handelt es sich um ein Protokoll, das eingesetzt wird, wenn mit dem Einsatz des STUN Protokolls keine NAT Traverse möglich war. Ist ein Peer hinter einem undurchdringlichen symmetischen NAT oder einer Firewall, kann dieser Peer eine Verbindung zum TURN Relais-Server aufbauen und über diesen mit dem anderen Peer kommunizieren. Da Relaying aber sehr viel Bandbreite verwendet, sollte TURN nur verwendet werden, wenn es keine andere Möglichkeit der direkten Kommunikation gibt. [vgl. RFC5766]

SDP

Das Session Description Protocol ist ein Anwendungsprotokoll. Es dient zur Beschreibung der Eigenschaften von Multimediaverbindungen, in einem definierten Format. Es beinhaltet Verbindungs-, Zeit- und Medieninformationen, die beim Verbindungsaufbau ausgehandelt werden können. Die Daten werden dabei als Bündel von Key-Value Paaren versendet. Tabelle 2.1 zeigt alle möglichen Felder des Session Description Protocols, allerdings beinhaltet eine SDPNachricht nicht zwangsläufig alle Attribute. [vgl. RFC4566]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1.: Mögliche Felder einer SDP-Nachricht

Zur Aushandlung wird ein Offer/Answer-Model benutzt. Dabei wird initial eine SDP-Nachricht als Offer an den Empfänger geschickt. Basierend auf dieser Nachricht, kann der Empfänger diesen Offer annehmen, ein oder mehrere Zeilen ändern, oder ablehnen. Die Antwort wird dann ebenfalls als SDP-Nachricht an den Versender zurückgeschickt. So können sich beide Peers auf gewissen Eigenschaften einigen. Jeder der Peers hat zu jedem Zeitpunkt der Session zusätzlich die Möglichkeit eine neue Anfrage zu versenden, um die Attribute der Session zu verändern. [vgl. RFC3264]

ICE

ICE bedeutet Interactive Connectivity Establishment. Es handelt sich um ein Protokoll, welches eine UDP-Verbindung zwischen zwei Peers herstellt. Um dies zu ermöglichen wird ein Offer/Answer-Modell [RFC3264] genutzt, um das verbindungsbeschreibende SDP [RFC4566] zwischen beiden Peers auszutauschen. Für den Austausch der SDP-Nachrichten wird ein dedizierter Signalkanal genutzt. Ist der Austausch der SDP-Nachrichten erfolgreich, ist es möglich eine Peer-to-Peer Verbindung herzustellen. Das ICE Protokoll sieht die Ermittlung und Verwaltung von möglichen Routingpfaden vor. Verwaltet werden auch die beteiligten Peers, beispielsweise durch die Kontrolle der Konnektivität. Um eine Peer-to-Peer Verbindung herzustellen wird das STUN Protokoll genutzt. [vgl. RFC5245]

SRTP

Beim Secure Real-Time Transport Protocol handelt es sich um eine AES verschlüsselte Variante des Real-Time Transport Protocols. Es ist ein UDP basiertes Transportprotokoll für die ÜbertragungvonVideo-undAudiodateninEchtzeit.EinSRTP-Datenpaketbestehtauseinem Header, dem Nutzdatenteil, der auch Payload genannt wird, und einem Authentifizierungs Tag. Beim Transport von Mediadaten werden RTP Pakete in SRTP Pakete eingebettet, der Header bleibt allerdings unverschlüsselt. Aufgrund des Authentifizierungs Tags kann allerdings trotzdem festgestellt werden, ob das Paket zwischenzeitlich manipuliert wurde, sodass der Payload in jedem Fall geschützt ist. [vgl. RFC3711]

SCTP

Das Stream Control Transmission Protocol ist ein modernes IP-basiertes Transportprotokoll. Es arbeitet auf der Transportschicht, wie auch TCP und UDP. Es ist mit Unterstützung der Protokollerweiterung Partial Reliability Extension ein zuverlässiges verbindungsorientiertes Protokoll und vereint die Vorteile von TCP und UDP. Es beherrscht Multi-Homing, nutzt parallele Datenströme für eine Verbindung und kann auch Datagramme versenden. Es ist sehr flexibel und lässt sich dem Einsatz entsprechend konfigurieren. Das API des RTCDataChannels bietet dem Entwickler Zugriff auf die Anpassungsmöglichkeiten zur Konfiguration beim Erzeugen des Objekts. Leider bietet es keine Verschlüsselung, sodass der DTLS Tunnel zwischen den Peers genutzt werden muss, um den Anforderungen der WebRTC Spezifikation gerecht werden zu können. [vgl. RFC4960]

DTLS

DTLS ist ein Verschlüsselungsprotokoll, welches zur Verschlüsselung von Datagramen einer UDP-Verbindung genutzt wird. Es wird fur Multimediaverbindungen von WebRTC eingesetzt, welche durch die Protokolle SRTP und SCTP realisiert werden. Beide Protokolle brauchen Unterstützung durch eine Verschlüsselung, um den Spezifikationen von WebRTC gerecht zu werden. DTLS wird zur Verschlüsselung der SCTP Verbindung genutzt. SRTP bietet zwar für den Medienstrom eine Verschlüsselung an, hat aber keinen eigenen Mechanismus zur verschlüsselten ÜbertragungderAES-Schlussel.DaherwerdendieNachrichtenzum ÜbertragenderAES- Schlüssel ebenfalls mit DTLS verschlüsselt. Die Sicherheit der Verschlüsselung entspricht TLS. Um die Funktion mit UDP als nichtzuverlässigem Transportprotokoll zu ermöglichen, wurden Änderungenvorgenommen.ZudeneingeführtenÄnderungen gehören die Nummerierung der Pakete und die Möglichkeit den Handshake, der beim Start der Session genutzt wird, wiederherzustellen. Dies ist erforderlich, da zum Entschlüsseln der Nutzdaten alle Pakete benötigt werden. [vgl. RFC6347]

2.5.2. RTCPeerConnection

Die RTCPeerConnection ist die grundlegende Verbindung bei der Verwendung von WebRTC. Unabhängig davon, welche Art von Daten übertragen werden sollen, ist es nötig eine Verbindung zwischen den Peers herzustellen. Bei der Erzeugung eines RTCPeerConnection Objekts muss mindestens eine STUN-Server Adresse angegeben werden. Optional können darin auch mehrere STUN-, wie auch TURN-Serveradressen angegeben werden. Werden nicht öffentliche STUN- oder TURN-Server eingesetzt, ist es möglich entsprechende Authentifizierungsdaten bei der Erzeugung des RTCPeerConnection Objekts anzugeben. Je nach Einsatzzweck der RTCPeerConnection wird nach dem Erzeugen einer RTCPeerConnection, ein RTCDataChannel Objekt erstellt oder ein Medienstrom vom Browser bezogen und der RTCPeerConnection übergeben. Die Eigenschaften der jeweiligen Verbindung werden beim Austausch der SDPNachrichten beschrieben. [vgl. RTCPI16]

Jedem RTCPeerConnection Objekt gehört ein sogenannter ICE Agent, und mehrere ICE Candidates an. Neben dem Austausch der SDP-Nachrichten, ist es nötig, dass die ICE Agents mögliche ICE Candidates ermittelt haben. Das Ermitteln von ICE Candidates startet mit dem Erzeugen eines RTCPeerConnection Objekts, da damit jeweils ein ICE Agent erzeugt wird. Der ICE Agent ermittelt mit Hilfe des STUN Protokolls, die eigene öffentliche IP und die

nutzbaren Ports zur Herstellung der RTCPeerConnection. Die ermittelten Verbindungsinformationen, über die eine RTCPeerConnection hergestellt werden kann, heißen ICE Candidates. Das Ermitteln beziehungsweise Sammeln dieser ICE Candidates wird auch ICE gathering genannt. Der ICE Agent informiert das RTCPeerConnection Objekt über die ermittelten ICE Candidates und koordiniert diese. Ermittelte ICE Candidates teilt der ICE Agent eines Peers seinem Remote Peer über den Signalkanal mit. Es ist möglich, aber nicht empfehlenswert, die ermittelten ICE Candidates in den SDP-Nachrichten mitzuteilen. Die Ermittlung der ICE Candidates kann gerade bei Verwendung mehrerer STUN-Server andauern und so den Ablauf der Offer/Answer verzögern. Daher ist es sinnvoll die Mitteilung der ICE Candidates in Nachrichten durchzuführen, die unabhängig vom Offer/Answer-Modell übertragen werden. Um die ICE Candidates außerhalb der SDP-Nachricht mitteilen zu können, wurde das ICEProtokoll erweitert. Die Erweiterung nennt sich ICE Trickling und ermöglich die inkrementelle Erfassung der ICE Candidates. Durch die Notwendigkeit die ICE Candidates zusätzlich an den Remote Peer mitzuteilen, werden mehr Nachrichten über den Signalkanal ausgetauscht. Empfängt ein Peer eine ICE Candidate Nachricht vom jeweiligen Remote Peer, wird daraus ein lokales RTCIceCandidate Objekt erzeugt. Das RTCIceCandidate Objekt wird dem lokalem RTCPeerConnection Objekt übergeben. Der lokale ICE Agent wird so über die ermittelten ICE Candidates des Remote Peer informiert. [vgl. RFC5245]

Ermittelt der ICE Agent einen ICE Candidate, wird die Callback Funktion onicecandidate des RTCPeerConnection Objekts aufgerufen. In der Funktion wird eine ICE Candidate Nachricht für den Remote Peer erstellt und an diesen versendet. Sind genug passende ICE Candidates von beiden beteiligten ICE Agents gefunden worden, so ist das ICE gathering abgeschlossen und die RTCPeerConnection wird initiiert. Werden nicht genug ICE Candidates gefunden, gilt die Peer-to-Peer Verbindung als gescheitert. Die RTCPeerConnection kann dann nur mit Hilfe einer Relaislösung, über einen TURN-Server hergestellt werden. In diesem Fall erhöht sich die Latenz der RTCPeerConnection, da alle Daten über den TURN-Server kommuniziert werden. [vgl. RTCPI16]

Bei der Ermittlung der ICE Candidates ist der ICE Agent immer bemüht eine möglichst gute Verbindung zu erzielen. So kann die Ermittlung wiederholt werden, wenn die bereits ermittelte Verbindung nicht für die zu transportierenden Daten ausreicht. Der ICE Agent ist auch für Konnektivitätskontrollen zwischen den Peers zuständig. Diese werden durch das Senden von Keepalive-Nachrichten, in Form von STUN Anfragen, umgesetzt. [vgl. RFC5245]

Soll eine RTCPeerConnection getrennt werden, bietet das Interface dazu eine Close Methode an. Wird diese Methode aufgerufen, wird der dem Objekt zugehörige ICE Agent zerstört und die Verbindung zum Remote Peer unterbrochen, unabhängig davon ob der Datenkanal oder der Medienstrom noch genutzt wird. Nach der Trennung werden alle benötigten Ressourcen wieder freigegeben. [vgl. RTCPI16]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: RTCPeerConnection API [CHI16]

2.6. Websocket

WebSockets werden zum bidirektionalen Austausch von Daten zwischen Computern in Netzwerken verwendet. Das bedeutet, dass sie sowohl Daten senden als auch empfangen können. Standardisiert wurde die Websocket API vom World Wide Web Consortium. [vgl. W3CWS16] Seit Version 4 von Google Chrome, Version 4 von Mozilla Firefox und den Großteil der mobilen Browsern ist es möglich, eine Websocket Verbindung mittels JavaScript zu einem WebSocketServer herzustellen. Die API stellt diverse Funktionen zum Senden und Emfpangen von Daten zur Verfügung (z.B. Zeichenketten, binäre Daten).

2.7. REST Web Services

REST ist die Abkürzung für REpresentational State Transfer und wurde in der Dissertation von Roy Fiedling maßgeblich geprägt. Es ist ein Satz aus mehreren Einschränkungen, denen eine Architektur genügen muss, um als REST-konformer Architekturstil zu gelten. Allerdings ist es keine eigene Architektur. Die Einschränkungen sind wie folgt definiert:

- Es muss ein Client-Server-System sein.
- Die Kommunikation soll zustandslos sein.
- Es muss ein Cachefähig sein
- Es muss einheitliche Schnittstellen anbieten. Jede Ressource braucht einen gültigen Zustand und eine eigene Adresse.
- Es muss ein geschichtetes System sein.
- Code on Demand (optional)

Damit die Kommunikation zustandslos sein kann, muss eine erfolgreiche Anfrage alle nötigen Informationen enthalten, die zu ihrer Bearbeitung nötig sind. Die Verwaltung der Sessions fällt daher in den Aufgabenbereich des Clients und gehört nicht zu den Aufgaben eines REST Services. Ein Nachteil ist die steigende Netzwerklast, aufgrund des erneuten Sendens von Informationen. Dieser Nachteil wird durch die nächste Einschränkung allerdings etwas kompensiert. Daher wird erfordert, dass die Antworten eines Servers implizit, oder explizit als cachefähig beziehungsweise nicht-cachefähig markiert werden können. Aufgrund der Schichtung ist es möglich Zwischenstationen, wie Proxies oder Gateways zwischen Server und Client einzuführen.

Die letzte Einschränkung, welche es ermöglicht eine Applikation zu ihrer Laufzeit zu erweitern, ist optional. Sollte Code on Demand eingesetzt werden, wird der Download des Codes erst bei Bedarf durch den Client ermöglicht, sodass der Service selbst leichtgewichtiger ist. Ein Beispiel dafür sind Java Applets. [vgl. San09, S.7-8]

In der Praxis nutzen REST Services Http Requests, um Daten zu senden, lesen und zu löschen. Dabei werden alle Daten für die vier CRUD Operationen über ein für Maschinen lesbares Format, wie JSON übertragen. Adressiert wird ein REST Web Service über einen Uniform Resource Identifier (URI) und ist so eindeutig adressierbar. [vgl. Fie00]

2.8. JSON

JSON steht für JavaScript Object Notation und beschreibt ein häufig im Kontext des Webs verwendetes Datenformat. Es besteht dabei aus zwei textuellen Strukturen, Key-Value Paare und geordnete Listen von Werten. Dadurch ist das Format einfach für Menschen zu lesen, aber auch effizient von Maschinen auswertbar und erstellbar. Es ist besonders bei Webentwicklern sehr beliebt, da es aufgrund der kompakten Form einfacher zu behandeln ist, als das ähnliche Datenformat XML. [vgl. JSO16]

2.9. Kurento

Kurento ist eine Sammlung an API’s, welche es ermöglicht fortgeschrittene WebRTC Anwendungen für das Web und für alle gängigen Smartphones zu entwickeln. Es wurde 2014 erstmals von dem gleichnamigen Unternehmen veröffentlicht und befindet sich seitdem unter der LGPL Version 2.1 Lizensierung. Es erweitert das WebRTC Framework insofern, dass Gruppenkommunikationen, Aufnahmen und Kodierungen von Videomaterial einfach implementiert werden können. Weitere Medienverarbeitung, wie beispielsweise Augmented Reality oder Sprachanalysen sind mit dieser API ebenfalls möglich, werden in dieser Arbeit aber nicht weiter verwendet. [vgl. KUR16]

Das Hauptelement von Kurento ist der Kurento Media Server. Er ist verantwortlich für Medienübertragungen, Weiterverarbeitung und die Aufnahmen von Videomaterial. Um die Ressourcennutzung so optimal wie möglich zu gestalten, wurde das Pipeline basierte Framework GStreamer verwendet. [vgl. KUR16]

2.9.1. GStreamer

GStreamer ist eine Bibliothek, zur Medienhandhabung. Sie ist ebenfalls unter den Richtlinien der LGPL veröffentlicht und die aktuelle API ist seit 2012 zugänglich. GStreamer ermöglicht die Nutzung von einfachen Audio Wiedergaben bis hin zu komplexen Audio / Video Streams. Ein besonderes Augenmerk liegt auf der transparenten Codec und Filter Technologie. GStreamer läuft auf allen größeren Betriebssystemen, wie Linux, Android, Windows, Mac OSX, iOS und viele mehr. [vgl. GSTR16]

2.9.2. H.264

H.264 ist ein Video-Kompressionsstandard, der von der Kurento API verwendet wird. Der H.264 Standard ist sowohl für mobile Anwendungen, als auch HD-Aufnahmen einsetzbar. Ziel war es eine Komprimierung zu erschaffen, die gegnüber anderen aktuell verwendeten Technologien die Datenrate um die Hälfte reduziert. Die Spezifikation besteht aus einem Video Coding Layer (VCL) und einem Netwok Abstraction Layer (NAL). [vgl. RFC6184] Aufgrund der nahezu verlustfreien Komprimierung eignet es sich besonders gut bei der Videodatenübertragung im Internet, da so das Material mit möglichst wenig Bandbreitennutzung übertragen werden kann.

2.9.3. Kurento Module

Die Kurento API besteht aus mehreren Plugins, welche Module genannt werden. Die Hauptmodule sind kms-core, welches die wichtigsten Komponenten des Kurento Media Servers beinhaltet, kms-elements, welches die Medien Elemente implementiert, und kms-filters, welches die Filter implementiert. Die wichtigsten Medien Komponenten, wie die Media-Pipelines, oder die WebRTC Umsetzung befinden sich ebenfalls im Modul kms-elements. Die weiteren mitgelieferten Module kms-pointerdetector, kms-chroma, kms-crowddetector und kms-platedetector werden nicht näher betrachtet, da diese sich hauptsächlich mit der Weiterverarbeitung von Mediendateien beschäftigen. Neben diesen mitgelieferten Modulen kann das Kurento Framework auch durch eigene Module erweitert werden. [vgl. KUMO16]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.: Kurento Module [KUMO16]

[...]