Die Anforderungen an die Schnittstellen sind schnell umrissen: Die Interaktionspartner (Smart TV und Second Screen App) sollen Events senden und empfangen können. Idealerweise soll die Implementierung der Kommunikationsschicht plattformunabhängig umgesetzt werden. Für den Anwender soll die Koppelung der Geräte möglichst einfach durchzuführen sein.

Unter Berücksichtigung dieser Anforderungen entstand folgendes Architekturkonzept.

Architekturkonzept

Eine zunächst naheliegende direkte Kommunikation zwischen den Geräten scheitert derzeit an einheitlichen Standards. Schnittstellen, wie Apples AirPlay oder DLNA, werden nicht von allen Geräten zuverlässig unterstützt. Aus diesem Grund haben wir uns für eine indirekte Kommunikation über einen Server entschieden.

Wird die HbbTV-Anwendung auf dem Smart TV aufgerufen, kommuniziert diese mit einem Web-Server. Auch die Anwendung auf dem Second Device (Smartphone oder Tablet) verbindet sich mit diesem Server. Die Architektur besteht aus drei wesentlichen Komponenten:

• einem Second Device (z. B. Tablet), das als Bedienungsgerät dient,
• einem HbbTV-fähigen Fernsehgerät und
• einem Kommunikationsserver.

Damit das Second Device mit dem Fernseher interagieren kann, muss sich das Bediengerät mit dem Server verbinden. Über den Server kann es Informationen übermitteln, die der Server  an das Fernsehgerät weiterleitet. Für den Benutzer der Anwendungen interagiert das Second Device scheinbar direkt mit dem Fernseher, obwohl die Verbindung über den Server hergestellt wird.

Betrachtet man den Server im Detail, kann dieser in zwei Komponenten unterteilt werden. Es gibt einen Content-Server, der die Informationsinhalte bereitstellt und einen Event-Server, der die Kommunikation zwischen den Anwendungen verarbeitet.

Betätigt der Benutzer der Second Screen Anwendung eine Taste oder macht eine Eingabe, schickt die Anwendung einen Event an den Event-Server. Dieser leitet den Event an die HbbTV-Anwendung weiter. Der Fernseher empfängt den Befehl und verarbeitet diesen in der App. Durch die bidirektionale Verbindung können auch Informationen von der TV-App an das Second Device geschickt werden.

In einem praktischen Beispiel veranschaulicht hieße dies, dass während einer Kochsendung das Rezept und Zubereitungsinformationen direkt abgerufen werden könnten. Damit die Second Screen App überhaupt weiß, welche Inhalte angezeigt werden sollen, werden dann die ausgelesenen EPG-Informationen in umgekehrter Richtung aus der TV-App an den Server geschickt.

Technische Umsetzung

In der von uns implementierten Lösung wurde ein Framework erstellt, welches in erster Linie eine plattformunabhängige, auf Standards basierte Lösung zur Kommunikation zwischen Fernsehgerät und Second Device bildet. Durch den immer weiter wachsenden Markt an internetfähigen Geräten, ist es wichtig, eine unabhängige Möglichkeit zur Verbindung der unterschiedlichen Geräte haben. Durch die Nutzung von offenen Webstandards kann das geforderte System ohne einschneidende Einschränkungen genutzt werden.

Obwohl die Hersteller der TV-Geräte versprechen, den HTML5 Standard zu unterstützen, sieht die Realität anders aus. Anspruchsvolle Komponenten, wie zum Beispiel Websockets werden nur teilweise, meist auch gar nicht unterstützt. Aus diesem Grund muss das Framework durch Fallbacks sicherstellen, dass eine Verbindung auch dann hergestellt wird, wenn keine Websockets verfügbar sind. Als Eventserver wurde ein Server auf Basis von Node.js genutzt. Mit Hilfe des Erweiterungspaketes Socket.io wird die Kommunikation zwischen den Geräten gewährleistet.

Das Framework Node.js ist eine Software-Plattform, die zur Programmierung von serverseitigen JavaScript-Anwendungen dient. Sie setzt auf Googles JavaScript-Engine V8 auf, welche auch in Googles Browser Chrome verwendet wird. Node.js bietet zusätzlich eine JavaScript VM mit der JavaScript auf der Konsole ausgeführt werden kann.

Des weiteren bietet Node.js die Möglichkeit, eine Vielzahl von Erweiterungen durch diverse Module einzubinden. Diese lassen sich über den integrierten Paketmanager NPM verwalten. Eine solche Erweiterung ist Socket.io.

Socket.io managed den Verbindungstyp während der Laufzeit. Das heißt im Detail, dass die API einen transparenten Fallback auf nachfolgende Verbindungstypen bereit stellt:

• Adobe Flash Socket
• AJAX long polling
• AJAX multipart streaming
• Forever Iframe
• JSONP Polling

Durch nur wenige Codezeilen lässt sich ein WebSocket-Server mit Hilfe von Node.js und der Erweiterung Socket.io realisieren.

Im folgenden Codebeispiel wird ein WebSocket-Server erstellt, der auf den Port 8080 hört und eingehende Nachrichten weiterleitet.

// will create a http server and listens on port 8080
var io = require('socket.io').listen(8080);
io.sockets.on('connection', function (socket) {
   socket.on('message', function(message){
      //logs Messages Received by Server
      console.log('I received a private message saying', message);
      //send to all connected sockets
      io.sockets.emit('message', message);</p>
      // send to all connected sockets expect the one that send it
      socket.broadcast.emit('message', message);
      // send to a special socket<br />
      io.sockets.send(sessionID).emit('message', message);
   });
});

Neben der serverseitigen Implementierung benötigt Socket.io auch eine clientseitige Komponente. Diese Komponente muss bei allen Clients implementiert werden, die sich mit dem Socket-Server verbinden möchten. Ein einfaches Beispiel, wie die clientseitige Implementierung aussehen kann, zeigen folgende Code-Zeilen:

<script src="/socket.io/socket.io.js"></script>
<script type="text/javascript">
	url = "http://localhost:8080";
	var socket;
	socket = io.connect(url);
</script>

Wurde Node.js erfolgreich installiert und Server wie Client nach dem vorangegangenen Beispiel eingerichtet, verbindet sich der Client beim Aufruf der HTML Seite automatisch mit dem Server.

Gestatten, ich bin das Second Device

Nun besteht eine prinzipielle Verbindung zwischen Second Device und Fernsehgerät. Um jedoch beliebige Geräte miteinander zu koppeln, müssen diese einander bekannt gemacht werden. Dazu wird bei der initialen Koppelung ein Token ausgetauscht. Dies kann eine Ziffernfolge oder ein QR-Code – der mit dem Smartphone fotografiert wird – sein. Durch die Bestätigung des Tokens kann der Server die beide Geräte miteinander verknüpfen. Diese Verknüpfung kann sogar applikationsübergreifend genutzt werden. Die Koppelung muss nur einmal pro Gerätepaar auf dem Server vorgenommen werden.

Zusammenfassung

Da sich die internetfähigen Endgeräte in vielen Aspekten unterscheiden (Bedienbarkeit, Netzwerkbandbreite, Rechenleistung), ändert sich auch die Darstellung und Nutzung der Anwendungen. Gerade die HbbTV Gerätehersteller versprechen viel, in der Praxis hinken sie im Vergleich zu Desktop und mobilen Lösungen spürbar hinterher. Der aktuelle Stand der Technik bietet durch die mangelnde Unterstützung der Browser noch keine optimale Performance. Die Verarbeitung von JavaScript und die Nutzung von neuen Technologien wie HTML5 können noch nicht problemlos eingesetzt werden. Laut der Hersteller von HbbTV fähigen Geräten soll HTML5 unterstützt werden. In der Praxis zeigt sich, dass gerade die neu hinzugekommenen Technologien wie Websockets noch nicht kompatibel oder voll implementiert sind. Trotz der festgestellten Schwachpunkte kann die Lösung bereits genutzt werden. Sie skaliert sogar mit der eingesetzten Plattformtechnologie.

Es ist davon auszugehen, dass das Zusammenwirken von Smart Devices und TV-Geräten in der Zukunft noch deutlich mehr genutzt wird, um den Benutzern neue Möglichkeiten in Kombination mit dem Fernsehgerät zu bieten. So werden die TV-Hersteller auch die Kommunikation zwischen den Geräten weiter optimieren und ein Framework das alle Kommunikationswege unterstützt bleibt als stabile Komponente im Technologie-Stack.

Interaktion: iPad und Smart TV

TV-Castingshows, bei denen Zuschauer für ihren Lieblingssänger voten können, gibt es schon lange. Bisher wurden diese Abstimmungen über Telefonanrufe oder SMS-Services realisiert. In letzter Zeit tauchen aber immer häufiger Anwendungen für den sogenannten Second Screen auf. Neben nützlichen Zusatzinformationen werden dort auch interaktive Aktionen zur Verfügung gestellt.

Laut einer Studie der Unternehmensberatung Anywab, nutzen in Deutschland ca. die Hälfte aller Zuschauer im Alter von 14-49 Jahren bereits den Second Screen während sie fern schauen.

Second Screen beschreibt die Nutzung des Internets auf einem Zweitgerät wie PC, Tablet oder Smartphone während des Fernsehens mit Bezug auf den aktuellen Inhalt der Sendung. In der Wikipedia wird er wie folgt definiert:

Second Screen (engl. für zweiter Bildschirm) ist ein um 2010 entstandener Begriff, der die Nutzung eines zweiten Bildschirms parallel zum laufenden Fernsehprogramm beschreibt. Der zweite Bildschirm ist typischer Weise ein internetfähiges Telefon (Smartphone) oder ein tastaturloser berührungsempfindlicher Tablet-Computer. Über den zweiten Bildschirm ruft der Nutzer zusätzliche und über das Fernsehprogramm hinausgehende Informationen ab oder kommentiert das Programm interaktiv mit anderen online.

Der Fernsehzuschauer nutzt also den Second Screen beispielsweise, um weitere Informationen zu der aktuellen Sendung zu bekommen oder kommentiert und diskutiert in sozialen Netzwerken über diese.

Der Studie von Anywab zufolge nutzen 2/3 der Befragten den Second Screen zur Recherche von Zusatzinformationen, dicht gefolgt von Aktivitäten in sozialen Netzwerken (56%). Die Experten stellen – wie auch auf dem NewTV Summit des BITKOM – offen die Frage, welcher Bildschirm tatsächlich der First und welcher der Second Screen ist. Worauf legt der Konsument seinen primären Fokus? Die Abgrenzung zwischen First Screen und Second Screen verschwimmt also zunehmend.

Interaktion zwischen den Screens

So wie die Priorisierung der Screens zunehmend verschwimmt, verschmelzen die Geräte durch spezielle Anwendungen für den Anwender zu einem Device. Durch die Koppelung des Smart TV mit dem Tablet oder Smartphone lassen sich nicht nur Zusatzinformationen benutzerfreundlich bereitstellen, sondern mit dem Einsatz der Gestensteuerung wird auch die Bedienung erleichtert und für Flexibilität in der Nutzung gesorgt.

Der stark wachsende Markt im Bereich Smartphones und Tablets hat zur Folge, dass immer mehr Fernsehzuschauer den Second Screen für sich entdecken werden. Durch die weitaus entspanntere Bedienung der mobilen Geräte wird das „leanback“ Feeling, das man am Fernsehen so schätzt, nicht durch PC oder große Laptops zunichte gemacht.

Smart TV mit Joy of Use

Die Bedienung eines Fernsehers mit Hilfe eines Second Devices ist sinnvoll, da Navigation und Texteingabe mit der herkömmlichen Fernbedienung schwer bis fast unmöglich machbar sind. Die User Experience bei reinen HbbTV-Anwendungen hat noch Potential! Die entscheidenden Erfolgsfaktoren einer Anwendung auf dem Smart TV sind die Usability sowie die Einfachheit der Bedienung. Der Einsatz eines Second Device mit einer einfachen, intuitiven Oberfläche steigert den Erfolgsfaktor und schafft gleichzeitig ein neues Bedienungserlebnis (Joy of Use).

Auf dem Second Device kennt der Nutzer die Bedienelemente bereits und kann die Anwendung ohne Einführung oder weiterer Instruktionen nutzen. Bei „reinen“ mit der Fernbedienung gesteuerten HbbTV Anwendungen verliert man hingegen oft den Überblick in der Navigation. Die Pfeilnavigation macht keinen Spaß. Der Anwender wird automatisch in den Lean-Forward Modus gezwungen oder beendet die Anwendung frustriert.

Smartphone calls TV

Der Markt an Second Screen Anwendungen wird täglich größer. Immer weitere Interaktionsmuster werden für den Benutzer bereitgestellt. Gerade bei der Synchronisation der Geräte werden unterschiedliche Ansätze  und Technologien eingesetzt. Bei den am Markt verfügbaren Anwendungen kann man drei Modelle der Synchronisation unterscheiden.

Zahlencode

Diverse Anbieter nutzen einen Zahlencode, der auf dem Second Device eingegeben werden muss. Dazu wird eine Connect-Aktion auf dem Smart TV ausgelöst. Diese stellt auf dem TV-Gerät einen Zahlen-Code bereit. Dieser Code muss in der App auf dem Second Device eingetippt werden. Jetzt kennen sich beide Geräte und können miteinander interagieren.

Ich höre, was Du siehst

Ein anderer Ansatz ist das Überwachen und Analysieren von Video- bzw. Audioinhalten. Die Second Screen App nimmt für einen Moment das Audiosignal über das integrierte Mikrofon auf, gleicht dieses mit einer Datenbank ab und erhält so die Informationen zum richtigen Programm (z.B. wywy). Auch die für Audiotitel ausgelegte App Shazam möchte zu Beginn des Jahres 2013 den Videomarkt mit ihrem Angebot so abdecken.

QR-Code

Bei der dritten Möglichkeit wird ein QR-Code bereitgestellt, der mit dem Second Device vom TV-Gerät abfotografiert werden kann. Zeitgemäße Smart Devices besitzen alle eine Kamera und können QR-Codes verarbeiten. Durch einen einfachen Scan kann sich der Benutzer schnell mit der App verbinden und erspart sich lange Konfigurationen.

Möchte man aber Geräte ohne Kamera wie das iPad der ersten Generation unterstützen, sollte man in jedem Fall über eine Alternativlösung nachdenken.

Ausblick

Im ersten Teil dieser Artikelreihe haben Sie einen Einblick zum Thema Second Screen und Interaktion mit dem Smart TV erhalten. Im Folgeartikel wird dann auf technische Details eingegangen und eine Möglichkeit gezeigt, wie sich eine Interaktion zwischen den Devices implementieren lässt.

Leider gibt es kein Patentrezept für den Erfolg mit Social Media. Darüber, was dringend vermieden werden sollte, waren sich jedoch alle Referenten einig: Verwenden Sie keine produktbezogenen Beiträge! Der Mensch sei resistent gegen Werbung und fühle sich davon gestört. Auf lange Sicht würden produktbezogene Beiträge eher ignoriert als honoriert, so die einhellige Erfahrung.

Positive Resonanz erzeugten hingegen Beiträge wie:

• Mitarbeiterprofile
• Fachartikel (auch gerne Hinweise auf Beiträge anderer Autoren)
• Umfragen
• Videoreihen (ein super Beispiel ist der Barfußmann)

Menschliche Kommunikationsebene
Entscheidend für den Erfolg einer Social Media Strategie sei außerdem, die Kommunikation auf einer menschlichen Basis zu halten. Neben der Informationsgewinnung will der Konsument in erster Linie unterhalten werden und, ganz wichtig, nicht mit einer Marke kommunizieren –  man sollte also ruhig auch einmal die Gesichter zeigen, die hinter den Beiträgen stecken.

Zuhören vs. schweigen
In Zukunft sollen audio-visuelle Medien das Geschehen bestimmen. Vor allem die Plattform Pinterest wurde in diesem Zusammenhang mehrfach empfohlen, welche als Pinnwand für Bilder und Grafiken dient. Weiterhin soll auf Kundenbeiträge primär reagiert und nicht, wie es die meisten Unternehmen aktuell handhaben, lediglich eine Flut von Beiträgen erzeugt werden. Zuhören ist dabei oberste Prämisse und bei den Antworten sollte auf eine kurze Reaktionszeit geachtet werden.

Erreichbare Ziele
Wie anhand der genannten Beispiele bereits deutlich wird, hat Leadgenerierung nicht die höchste Priorität. Social Media zielt auf Image. PR-Maßnahmen sollen die Marke stärken und, mit Blick auf das überwiegend junge Publikum, soll das Personal-Recruiting angetrieben werden. Nicht zuletzt steht die Platzierung in Suchmaschinenrankings im Fokus, da Suchmaschinen zunehmend die Social Media Relevanz von Seiten in ihren Algorithmen verwenden.

Mein Fazit
Im Gegensatz zu den Ergebnissen verschiedener Umfragen die im Netz kursieren, scheint mir nur ein geringer Anteil der B2B Unternehmen bereits eine ausgereifte Social Media Strategie zu verfolgen. Anhand der Fragestellungen der Teilnehmer war jedoch erkennbar, dass die meisten bereits konkrete Pläne für die Zukunft entwickeln. Für mich war es ein absolut spannender Tag mit abwechslungsreichem Programm. Im Februar 2013 soll ein eigenes Social Media B2B Event in München veranstaltet werden. Ich bin gespannt, was sich in der schnelllebigen Online-Welt bis dahin tut.

dmexco 2012

Diese Woche war ich auf der dmexco. Eine wirklich lohnenswerte Messe wenn man mal wieder auf allen Kanälen mit Information zugestopft versorgt werden will. Apropos Kanäle: Wichtigstes Thema im Bereich E-Business war natürlich – wie zurzeit eigentlich überall – die User Journey im Cross-Channel-Marketing. Also die Reise des Kunden durch verschiedene Kanäle:

von Adwords, über Landingpages / SEO, Facebook, Newsletter, den Besuch im guten alten Ladengeschäft, bis natürlich zum Online-Shop. Die große Frage dabei ist immer wieder, welchem Touchpoint, also welchem Kanal welcher Anteil an der Verkaufsprovision zusteht. Hat der Kunde gekauft weil der Online-Shop so sexy war? Weil die Argumente im Newsletter einfach genau den Bedarf getroffen haben? Weil die Facebook-Werbung genau im richtigen Moment aufgepoppt ist? Zur Beantwortung dieser Fragen existieren bereits Lösungen, die Sie leicht finden können, indem Sie nach dem Begriff „Attributionsmodelle“ googeln.

Habe gelernt

Für mich war dieses Jahr interessant, dass viele Händler, die sowohl Online-Shops als auch Ladengeschäfte betreiben, vor der Herausforderung stehen, nicht nur die online User Journey ihrer Kunden aufzuzeichnen, sondern die Besuche im Ladengeschäft zu bewerten. Meine Erkenntnis an dieser Stelle war, dass alle Ansätze in dieser Richtung über mobile Geräte führen. Bisher waren Apps für mich entweder Shops oder eben ein weiterer Kanal zur Kommunikation mit Kunden. Tatsächlich können Apps aber viel mehr: Nur durch mobile Apps lässt sich die User Journey bis ins Ladengeschäft verfolgen. Das habe ich durch die vielen interessanten Gespräche auf der dmexco wirklich begriffen.

Panel des BVDW zum Thema: Everywhere Commerce – reines Multichannel war gestern

Beispiel:

Vor ein paar Wochen wollte ich ein Zelt für unseren anstehenden Sommerurlaub kaufen. In meinem Lieblingsladen haben mir zwei Zelte ganz gut gefallen, ich wollte das also mit meiner Frau besprechen. Verständlicherweise wollte der Verkäufer aber nicht seine Provision sausen mich ohne Kauf ziehen lassen. Eine unangenehme Situation.
Wäre es jetzt wirklich schwierig, mir für beide Zelte einen QR-Code zu geben (hier kommt die App ins Spiel!), mit dem ich dann am Abend vom Sofa aus, direkt im Online-Shop das jeweilige Zelt finde und mit meiner Frau klären kann welches wir kaufen? Natürlich fehlt dann noch die Kundenbindung. Z.B. ein kleiner Rabatt, oder einfach nur, dass ich vom Kunden-Service meiner Vorort-Filiale so überzeugt bin, dass ich das Produkt nicht an anderer Stelle im Internet erstehe.
Das Ende vom Lied war: Nachdem ich mich mit meiner Frau besprochen hatte, musste ich noch einmal ins Auto sitzen, um das Ding offline zu kaufen. Einen Onlineshop hat mein Lieblingsladen nämlich keinen und wenn ich mein Zelt bei Amazon gekauft hätte, wäre dieser auch bald pleite. Ob ich das aber noch oft so mache, weiß ich noch nicht.

Nachrichtenportale, Blogs und Webseiten ermöglichen uns ständig auf dem aktuellen Stand der Dinge zu sein. Informationen in Form von Texten sind allgegenwärtig. Doch wer kann von sich behaupten das für sich relevante schnell und effizient zu finden? Mehr Informationen führen nicht automatisch zu mehr Informiertheit.

Bereits in den 1950er Jahren veranschaulichte der zweite Sputnik-Schock diese Problematik. Damals benötigten die USA ein halbes Jahr, um den Signalcode der Sputnik zu entschlüsseln. Dabei wurde übersehen, dass der Signalcode bereits zwei Jahre zuvor in einer russischen Zeitschrift veröffentlicht wurde, die übersetzt in vielen Bibliotheken des Landes auslag. Das infolge dessen von John F. Kennedy in Auftrag gegebene Gutachten bestätigte die Problematik und enthält einen Maßnahmenkatalog zur Optimierung der Informationsvermittlung. Ein Punkt in diesem Katalog ist, dass Texte nur zusammen mit Schlagworten veröffentlicht werden sollten. Doch die Generierung  ist aufwändig und wird oft nicht oder nur unzureichend durchgeführt.

Auch unsere Kunden haben dieses Problem und wir haben es für sie gelöst indem wir den Prozess zur Erstellung passender Schlagworte automatisiert haben. Die aufwändige Arbeit für den Autor entfällt und die generierten Schlagworte sind homogen und einheitlich. Doch weil uns das allein nicht reicht und wir unsere Kunden begeistern möchten, haben wir die Funktionalität dahingehend erweitert, dass nicht nur Schlagworte, sondern auch relevante Metainformationen zu den Schlagworten erzeugt werden.

Der typische Anwendungsfall

Stellen Sie sich den Arbeitsablauf eines Redakteures vor: Dieser schreibt einen Artikel und publiziert diesen unter Verwendung eines Content Management Systems (CMS). Gleichzeitig wird der geschriebene Text automatisch an unseren Service weitergegeben und von diesem verarbeitet. Im Text genannte Entitäten, also Personen, Orte, etc. werden von der Software erkannt und zusammen mit Metadaten an das CMS zurückgegeben. Diese Informationen können dann beliebig genutzt werden. Denkbar wäre beispielsweise die Anzeige von Steckbriefen zu den im Text erwähnten Personen, oder die Anzeige der im Text genannten Orte auf einer Karte. Und das Beste daran: Es funktioniert automatisch und ohne Zutun des Redakteures.

Technische Umsetzung

Die von uns implementierte Lösung verwendet ein Natural Language Processing (kurz NLP) Framework zum Finden von Entitäten in einem Text. Dieses funktioniert jedoch nicht „Out of the box“ da die in dem Framework verwendeten Algorithmen statistische Modelle zur Erkennung benannter Entitäten benötigen, welche nicht in deutscher Sprache verfügbar sind. Daher müssen zuerst geeignete statistische Modelle erzeugt werden. Voraussetzung dafür ist wiederum eine  große Textsammlungen (Korpus) in der möglichst alle vorkommenden Entitäten, also Personen, Orte, etc. gekennzeichnet sind.

Aufgrund der minimalen Größe von 15.000 Sätzen ist die manuelle Erzeugung eines annotierten Korpus nicht praktikabel. Wir haben deshalb eine automatisierte Lösung entwickelt, die basierend auf frei verfügbaren Texten, einer Ontologie und strukturierten Informationen geeignete annotierte Korpora erzeugt.

Die verwendete Ontologie als auch die strukturierten Informationen werden von DBpedia zur Verfügung gestellt. DBpedia extrahiert diese Informationen aus Wikipedia und stellt das Extrakt in einem standardisierten Format frei zur Verfügung. Dieser Datenbestand ist mehrere Gigabyte groß und enthält eine Fülle an relevanten Informationen, die bei Bedarf durch Datensätze anderer Anbieter ergänzt werden können. Wir nutzten diese Daten zudem auch für die Anreicherung der in einem Text gefundenen Entitäten mit Metadaten, wenn eine eindeutige Zuordnung möglich ist.

Für uns hat sich die Frage gestellt, wie das entwickelte System in die Softwarelandschaft möglichst vieler Kunden mit unterschiedlichen CMS integriert werden kann. Hier haben wir uns für die Verwendung von Webservices entschieden. Dabei wird der zu analysierende Text an den Webservice gesendet. Dieser erkennt die in dem Text vorkommenden Entitäten, reichert diese soweit möglich mit Metadaten an und gibt das Ergebnis im JSON-Format zurück.

Fazit

Die Möglichkeit homogene Schlagworte automatisch zu generieren ist ein erheblicher Vorteil wenn es darum geht Texte – und speziell die darin genannten Informationen – leicht auffindbar zu machen. Dies ist jedoch nur ein Aspekt unserer Lösung. Die zusätzliche Anreicherung mit Metadaten ist ebenfalls bedeutend, da dadurch viel mehr Möglichkeiten geschaffen werden die ermittelten Daten sinnvoll zu nutzen. Steckbriefe zu den vorkommenden Personen beispielsweise können einen großen Mehrwert für den Leser haben, da dieser nicht zwangsläufig mit den genannten Personen vertraut sein muss und sich bei Bedarf schnell und unkompliziert informieren kann. Eine weitere Möglichkeit ist die Verwendung von Ortsnamen bzw. deren GPS-Koordinaten zur Darstellung der Orte auf einer Karte. Der Nutzer könnte dann ortsbezogen navigieren und so Nachrichten zu einem Ort einfach abfragen da diese automatisch verknüpft werden.

Die genannten Beispiele für die Nutzung der extrahierten Informationen sind nur Anregungen was mit dem System möglich ist. Durch konsequente Integration und Verwendung der Daten kann ein großer Mehrwert für den Nutzer und für den Redakteur geschaffen werden. Wie und in welchem Umfang dies geschieht kann jeder Kunde für sich selbst bestimmen.

Bild: goran_zec/Flickr (Lizenz: CC BY-SA 2.0)

Vielmehr geht es darum, wie man effektiv Webanwendungen an ihre Lastgrenzen bringt und wie man aus den gewonnenen Daten die richtigen Schlüsse zieht.

Wenn es bei einer neu entwickelten Website mit extrem hohen Zugriffszahlen in Richtung Go-Live geht, stellt sich die Frage, ob die Gesamtlösung aus CMS, Media Asset Management, CDN, Cache etc. in ihrer Leistungsfähigkeit ausreichend für die erwarteten Besucherzahlen ausgelegt ist.

Gleichung mit mehreren Unbekannten

Dieses Frage ist nicht trivial, da es in dieser auf den ersten Blick einfachen Gleichung viele Unbekannte gibt, die man erst einmal mit plausiblen Annahmen hinterlegen muss.

Da ist zunächst die Anzahl der Benutzer. Wenn man Glück hat, erstellt man eine Website nicht auf der grünen Wiese, sondern kann auf eine bestehende Nutzerstatistik zurückgreifen. Hier gilt es dann wesentliche Kennzahlen zu ermitteln:

• Wie viele Page-Visits pro Monat sind zu erwarten
• Welches sind die normalen Lastspitzen (Peaks) in diesem Zeitraum
• Gibt es Statistiken zu Peaks bei besonderen Ereignissen (9/11, Fukushima, Fußball WM, Olympiade, Live-Events)

Wenn man ein CMS-Projekt für eine noch nicht bekannte Nutzer-Reichweite durchführt, hat man den Vorteil, dass sich die Nutzungszahlen nach dem Launch meistens kontinuierlich entwickeln.

Das Konzept muss daher sinnvolle Annahmen für die wichtigen Kennzahlen als Ausgangsbasis enthalten. Wichtig ist in diesem Zusammenhang ein schlüssiges Skalierungskonzept in der Hinterhand zu haben, um mit steigenden Nutzerzahlen und wachsendem Content klar zu kommen.

Request Profil Aufzeichnung

Hat man die Nutzer in ihrer Gesamtheit, so kann man diese auch versuchen in typische Benutzerprofile aufzuteilen. Im Grunde geht es darum eine Verteilungsfunktion für die Seiten des Angebots zu finden, die von Tests simuliert werden kann. Man wird also analysieren welche Seiten des Angebots aller Wahrscheinlichkeit nach überdurchschnittlich häufig aufgerufen werden. Im Idealfall bekommt man durch diese Analyse oder geeignete Annahmen eine handvoll Benutzerprofile, die man als Grundlage für ein Lastprofil nutzen kann.

Diese Daten benutzt man, um Abrufprofile zu erstellen indem man die entsprechenden Seiten und alle Ressourcen, die mit einem clientseitigen Abruf enthalten sind (z.B. Bilder, JS, CSS, Flash, Audio/Video) aufzeichnet und das Abrufprotokoll als Basis für die Lastsimulation nutzt.

Hierzu gibt es unterschiedliche Strategien. Will man nah an den Benutzerprofilen bleiben, muss man die Requests in einem Browser ausführen, um auch Einflüsse des User Agent und Abrufe die erst beim Rendering zum Tragen kommen, beispielsweise Ressourcen aus dem CSS, zu berücksichtigen. Man sollte sich nicht auf einfache Spidertools (wie wget o.ä.) verlassen. Diese sind nur hilfreich, wenn man die Gesamtheit der Webseite als Basisprofil in dem Lasttest zugrunde legt.

Eine gute Möglichkeit beide Welten miteinander zu verbinden, ist Mozilla Spider, eine Chrome/XUL Anwendung für Mozilla basierte Browser. Damit kann man die Webseite abspidern und hat dennoch ein realistisches Request-Profil, denn die Seiten werden komplett gerendert. Die Request-Protokolle kann man entweder clientseitig mitschneiden oder dem Logging des Webservers entnehmen.

So früh wie nötig, so spät wie möglich

Wann ist der richtige Zeitpunkt für Lasttests? Testet man zu früh, dann geht man das Risiko ein, dass mit ausstehenden Feature-Implementierungen noch Bestandteile hinzukommen, die sowohl Einfluss auf die Performance als auch auf die Benutzerprofile haben. Dann ist die Aussagekraft eines solchen Tests gering und mit einer gewissen Unsicherheit behaftet.

Testet man jedoch zu spät, wird man in vielen Fällen Probleme bei der Behebung der Performance-Engpässe bekommen, was den Go-Live im schlimmsten Fall verzögert oder das Projekt verteuert.

Welche Bestandteile möchte man eigentlich bei einem Lasttest überprüfen? Meiner Meinung nach erreicht man die beste Aussagekraft, wenn man alle Komponenten in ihrer Gesamtheit, möglichst nahe am Produktiv-Betrieb testet. Denn nicht nur die Ausspiel-Webserver und ein Content-Management / Redaktionssystem haben großen Einfluss auf das Lastverhalten, sondern auch die vorgelagerten Komponenten, wie Load-Balancer, Firewall, Cache-Server, CDNs und die gesamte Hardware-Infrastruktur inklusive Internetanbindung.

Diagramm Lasttest

Over the top

Ich glaube, eine wirklich belastbare Antwort darauf, wie gut ein System mit Last umgehen kann, wird man nur finden, wenn man es an seine Grenzen bringt, den Lasttest als Stresstest auslegt.

Die Hauptschwierigkeit ist dabei die Rolle von Caching und Cache-Invalidierung zu beurteilen. Um einen realistischen Betrieb auch Backend-seitig zu simulieren und dabei das richtige Verhältnis von Cache-Invalidierung und Abruf gecachter Seiten zu finden, braucht man in vielen Fällen eine Glaskugel.

Deshalb bin ich der Meinung, dass man eine sehr viel verlässlichere Datenbasis bekommt, wenn man bei einem Stresstest die Grenzfälle testet. Das heißt gänzlich gecachte Inhalte-Ausspielung und vollkommen ungecachte Ausspielung.

Diese beiden Fälle sollte man mit den angenommenen Benutzerprofilen mit steigenden parallelen Zugriffen bis an die Grenzen des Gesamtsystems testen. Die Prämisse ist also das Gesamtsystem so zu belasten, dass es nicht mehr zufriedenstellend funktioniert, damit dieser Fall nicht im produktiven Betrieb auftritt und man vorher reagieren kann:

Macht kaputt, was euch kaputt macht!

Ein solcher Stresstest sollte folgende Erkenntnisse bringen:

• Wann ist die Grenze zumutbarer Antwortzeiten durch die Ausspielserver erreicht?
• Wann ist die Bandbreite der Anbindung ausgereizt?
• Wann ist die Belastungsgrenze der Ausspielserver erreicht?
• Gibt es anhaltende Ausfalleffekte, die sich mit dem Verringern der Last nach dem Stresstest nicht auflösen?
• Welche Maßnahmen lassen sich ergreifen, um die Lastgrenze weiter nach oben zu verschieben?

Um die Daten eines Lasttests zu interpretieren, sollte man sich intensiv vorbereiten. Nur das Antwortzeitverhalten zu messen ist definitiv zu wenig. Man kann so keine Aussage machen, welche Komponenten die begrenzenden Faktoren darstellen.

Folgende Messzahlen sollte man erfassen:

• Antwortzeiten / Anzahl der Aufrufe über die Zeit auf Clientseite
• Prozessorauslastung der Ausspielserver
• Festplattenzugriffe
• Speicherentwicklung
• Monitoring von Load-Balancer und Firewall
• Monitoring der Netzwerk-Anbindung und Auslastung der Bandbreite

Lastesel

Ein Problem ist die Last realitätsnah zu erzeugen. Man benötigt genügend Lasttreiber mit einer ausreichenden Bandbreite bezüglich der lokalen und verteilten Komponenten. Um Lasttests mit minimalem Aufwand durchzuführen, nutzen wir intern eine Test-Grid, welches mit bootbaren Linux-Live Distributionen arbeitet. Hier kann man ohne langwierige Konfiguration einen beliebigen Rechnerpool in kurzer Zeit zu einem Lasttest-Treiber machen.

Wichtige Voraussetzung ist, dass die begrenzenden Faktoren dieser Konfiguration bekannt sind, da man sonst die Ergebnisse nicht interpretieren kann und eventuell sinnlose Tests durchführt. Man sollte also die Ausgangskapazitäten für Netzwerk und die Multithreading-Fähigkeiten der Prozessoren in der konkreten Konfiguration des Test-Sets berücksichtigen.

Cloud Power

Interessante Entwicklungen auf diesem Gebiet sind die Nutzung von Cloud-Computing zur variablen Gestaltung der Basis für einen Last- und Performance-Test. Hier kann man mit wenig Aufwand einen umfangreichen Rechnerpool aufbauen, ohne diese Systeme selbst vorhalten zu müssen oder viel Zeit in die Basiskonfiguration zu investieren.

„Last“ words

Welche Schlüsse sind aus einem Lasttest zu ziehen? In den wenigsten Fällen wird man eine einfache Antwort erhalten. Meist ergibt sich doch eine Verkettung von verschiedenen Parametern.

Im dem einen Fall wird es ausreichen, die Prozessorleistung zu erhöhen, um akzeptable Werte zu erhalten. Im nächsten Projekt wird man eine umfangreiche Laufzeitoptimierung der Applikation vornehmen müssen.

Was immer es auch ist, es ist besser diese Fallstricke vorher zu kennen, als mit dem Launch in einen offenen Beta-Test zu gehen. So bringt man dann auch ein Portal zur Olympiade performant an den Start.

Titelbild: gazeronly / flickr.com (CC BY 2.0)

“All Media mobile”, unter dieses Motto könnte man vordergründig das diesjährige Medienforum.NRW in Köln stellen. Doch ganz wird es der Vision nicht gerecht, denn es geht nicht nur um die mobile Nutzung, sondern auch um die unmittelbare Verfügbarkeit – immer und überall. Im Folgenden möchte ich dazu die Visionen und Meinungen aus dem Kongress skizzieren.

Mobile, mobile, mobile, …

Ein ganz zentrales Thema war natürlich das Thema Mobile. Dabei ging es im Gegensatz zum vergangenen Jahr überhaupt nicht mehr um die Technologien: iOS, Android, Windows 8 oder doch HTML5/JavaScript? Nein, vielmehr sind die Ökosysteme und Marktplätze Dreh- und Angelpunkt. Man hat erkannt, dass die Technik nicht ausschlaggebend ist. Sicher, sie muss funktionieren, aber viel wichtiger sind Zusammenspiel der Betriebssysteme, App-Stores und Bezahldiensten und schlussendlich die Auffindbarkeit der Apps. Auch das Mobilfunknetz gehört als zentrales Element zu diesem Ökosystem. So hat der Sohn eines Erikson-Managers seinen Vater als Looser gesehen, so berichtete er persönlich: Als Manager bei Erikson hat er es nicht geschafft WLAN, für den Nintendo DS spielenden Sprössling, ins Familienauto zu bringen. Die Verfügbarkeit des Netzes wird immer und überall erwartet. Mit LTE steht ein Standard in den Startlöchern, der auch die Performance verspricht, die man für Videos benötigt. Bei LTE Adv. werden in Zukunft 16 Mbps durch den Äther gebeamt.

Bewegtbild auf dem Smart TV

Neben der mobilen Nutzung der Medien ist der Smart TV bereits in den Wohnzimmern angekommen. Es wird zwar noch heiß diskutiert, wie viele Smart TV wirklich “connected”, also mit dem Web verbunden, sind. Doch sind sich die meisten Experten einig, dass Web und Broadcast, das klassische Fernsehen auf den Fernsehern, im Wohnzimmer verschmelzen. Marc Schröder von RTL verglich den aktuellen Stand der Smart TV mit WAP auf den Handys der 1990er: Die Bedienung ist noch sehr umständlich. Bedienkonzepte mittels klassischer Fernbedienungen aus dem letzten Jahrtausend und numerisch vergebene Programmplätze für die Sender bieten nicht die notwendige Userexperience, um das Lean-Back-Gefühl vom linearen Fernsehprogramm auf die Webebene des Fernsehers zu transportieren.

Glotz ich noch TV?

Immer Online: Die Smartphone-Nutzung - ohne Telefonate

Apropos S-Bahn, die Nutzung der mobilen Dienste findet nach einer Untersuchung 70-80% zu Hause statt,  beim Tablet eher mehr. Beim Smartphone sind es immer noch 70% der Nutzungszeit. Die Kombination TV und Smartphone ist also bei dem Fernsehkonsum von durchschnittlich 195 Minuten ein wichtiger alltäglicher “Use-Case” für Fernsehsender und Anbieter der Endgeräte. Das Werben um den Verbraucher ist im vollem Gange.

Content is King, Package is God

Durch die Verschmelzung – der Konvergenz der Medien – die durch die Geräte massiv unterstützt wird, wird auch das klassische lineare Fernsehen verändert. WebTV in seinen Facetten wird vermehrt zur Alternative der klassischen Fernsehkanäle. Zunächst denkt man hier an die Klassiker, wie YouTube oder MyVideo, doch der Markt des WebTVs ist weit größer. Jeder Dienst versucht sein Alleinstellungsmerkmal zu positionieren: Video on Demand (VoD), Social Community, kuratierte Channels oder exklusiver Content.  Jan Lerch von Tape.tv hat einen Satz geprägt, der mir in diesem Zusammenhang sehr treffend erscheint:

Content is King, Package is God!

- Jan Lerch, Tape.tv

Durch eine redaktionelle Zusammenstellung des Contents wird der Surfer mit Inhalten bedient. Im Gegensatz zum linearen Fernsehen jedoch zeitunabhängig. Zurück gelehnt kann sich der Zuschauer aber mit den vorgeschlagenen Inhalten bedienen lassen.

Exklusivität des Fernsehens

In einer der Podiumsdiskussionen konstatierte einer der Redner, dass dem Fernsehen das gleiche Los wie dem Rundfunk beschert sei. Wo unsere Großeltern sich gemeinsam vor dem Radio für eine Sendung im Wohnzimmer versammelt haben, läuft heutzutage das Radio in Bad und Küche nebenher. Gleiches prognostizieren die Experten dem Fernsehen. Schon heute ist durch die Parallelnutzung von Smartphone und Tablet der Weg dahin beschert, dass das Fernsehprogramm die exklusive Aufmerksamkeit der Zuschauer verliert.

Durch Eventshows und interaktive Elemente versuchen die Broadcaster dem entgegenzuwirken und blenden beispielsweise Werbung auch als Banner in die laufende Sendung ein, um so die volle Aufmerksamkeit zu bekommen.

Werbung und Smart TV

Apropos Werbung, es gab eine recht hitzige Diskussion zur aktuellen Gesetzeslage in Verbindung mit Smart TV Applikationen. Der Politik wurde vorgeworfen, die Entwicklungen verschlafen zu haben und eine schnelle Reaktion wurde gefordert. Thematisiert werden Apps auf den Fernsehgeräten, die als Overlay Teile des Livebildes überlagern können und so beispielsweise Werbung überlagert wird. Ein Problem für die Broadcaster, die maßgeblich auf die Werbeerlöse angewiesen sind.

Das Spannungsfeld zwischen Gerätehersteller und Broadcaster wurde in der Diskussion sichtbar. So verweigern beispielsweise einige TV-Sender die HbbTV-Ausspielung auf bestimmten Geräten: Die Gerätehersteller halten sich aus Sicht der Sender nicht an Bedingungen, die diese erwarten: Das zuletzt ausgewählte TV- Programm ist beim Wiedereinschalten nicht voreingestellt und es erscheint Werbung des TV-Herstellers beim Einschalten. Man merkt, keiner möchte von seinem Kuchen etwas abgeben. Zumal noch keiner richtig weiß, wo die Reise des Smart TV letztendlich wirklich hin geht.

Fazit

Diskussion zum WebTV

Nach dem Smartphone werden Smart TVs die Haushalte erobern. Hersteller wie Fernsehsender versuchen die Chancen der Verbindung von linearen mit nichtlinearen Inhalten. Aber auch die Interaktion mit dem Zuschauer wird geprobt. So gibt Richard Gutjahr offen zu, dass er in der vierwöchigen Pilotsendung Rundshow alles an Interaktionsmöglichkeiten eingebaut hatte, was nur ging. Es war eine einmalige Chance zu experimentieren, was mit aktueller Technik machbar ist.

Aus schnell zusammengestellten Lösungen werden zukünftig professionelle und tragfähige Lösungen entwachsen müssen, damit auch ein interaktiver Tatort den Zugriffen standhalten kann. Aktuell will noch jeder der erste an der Zielgerade sein, doch schon bald werden strukturierte und auch technisch auf festem Fundament gegründete Lösungen den Verbraucher überzeugen, bevor dieser den Spaß verliert.

Der Begriff der Batch- bzw. Stapelverarbeitung stammt aus der Anfangszeit der Datenverarbeitung, als ein Programm noch aus einem Stapel von Lochkarten bestand. Heute versteht man darunter einen Prozess, der ohne Benutzerinteraktion eine oft große Datenmenge sequentiell abarbeitet. Auch heute sind Batchverarbeitungen von großer Bedeutung. Oft handelt es sich um komplexe Berechnungen auf großen Datenmengen, deren Ergebnisse sehr wichtig für die Unternehmen sind wie z.B. Lohnabrechnungen, Monatsabschlüsse und Ähnliches.

An Batchverarbeitungen werden also hohe Anforderungen in Sachen Robustheit, Skalierbarkeit, Performanz und Wartbarkeit gestellt. Zwar haben sich über die Jahre verschiedene Prinzipien zur Batchverarbeitungen bewährt, bis vor kurzem mussten diese jedoch insbesondere in der Java-Welt immer wieder neu in den spezifischen Projekten implementiert werden. Bei der Entwicklung von komplexen Batch-Prozessen nimmt die technische Einbindung der Batchverarbeitung meist sehr viel Zeit in Anspruch, die sinnvoller für die Business-Anforderungen investiert werden sollte.

Mit Spring Batch hat sich die Spring Foundation diesem Missstand angenommen und stellt ein interessantes Framework bereit, um die Entwicklung von Batchverarbeitungen deutlich zu vereinfachen. Wie bei Spring-Projekten üblich, verfolgt auch Spring-Batch einen leichtgewichtigen Ansatz, der die Businesslogik mit wenigen spezifischen Anpassungen belastet.

Dieser Artikel gibt im Folgenden eine kurze Einführung in Spring-Batch. Für tiefere Einblicke sollte die sehr gute Dokumentation zu Rate gezogen werden. Da Spring-Batch in der Version 1.3 oder in der Version 2.0 eingesetzt werden kann, muss darauf geachtet werden, auf welche Version sich die Dokumentation bezieht.

Spring Batch Elemente

Spring-Batch gliedert sich in die zwei Komponenten Core und Infrastructure. Während ersteres die grundlegenden Interfaces und Implementierungen beinhaltet, bietet letzteres Paket Interfaces zur Anpassung an spezielle Ausführungsumgebungen wie JMS, ESB/SEDA oder Grid-Architekturen. Mitgeliefert ist eine einfache Ausführungsumgebung, die für allgemeine Fälle ausreichend ist. Diese beinhaltet bereits Implementierungen für vereinfachtes Handling von Datenbanken oder zeilenweises Auslesen und Verarbeiten von Dateien in Batchprozessen.

Job & Step

Ein Job bezeichnet die Definition eines Batch-Prozesses. Ein Job besteht aus einzelnen Steps, die in einer vorgegebenen Reihenfolge durchlaufen werden.

<job id="footballJob">
  <step id="playerload" next="gameLoad"/>
  <step id="gameLoad" next="playerSummarization"/>
  <step id="playerSummarization"/>
</job>

JobInstance, JobParameter & JobExecution

Eine JobInstance ist eine geplante Ausführung einer Job-Definition, z.B die Ausführung eines Jobs zu einer bestimmten Uhrzeit. Eine JobInstance wird mit den JobParameters, z.B. dem Ausführungszeitpunkt,  parametrisiert.

Eine JobExecution ist die tatsächliche Ausführung einer JobInstance. Die Unterscheidung von JobInstance und JobExecution ist darin begründet, dass eine JobExecution fehlschlagen kann. Dann muss es möglich sein, dieselbe JobInstance erneut auszuführen, ohne dass die in der JobExecution gespeicherten Informationen über die Ausführung verloren gehen.

ItemReader, ItemWriter & ItemProcessor

Innerhalb eines Steps werden die einzelnen Verarbeitungseinheiten definiert. Diese Verarbeitungseinheiten sind ItemReader, ItemProcessor und ItemWriter.

ItemReader ist ein einfaches Interface, das vom Entwickler implementiert werden kann. Ein ItemReader ist dafür verantwortlich, einen Datensatz aus der Datenquelle zu lesen und zurückzugeben.

public interface ItemReader<T> {
 T read() throws Exception, UnexpectedInputException, ParseException;
}

SpringBatch bringt schon eine Vielzahl von ItemReader Implementierungen mit – wie beispielsweise FlatFileItemReader, JdbcCursorItemReader oder JpaPagingItemReader – welche sich einfach konfigurieren und benutzen lassen.

ItemProcessor ist ein Interface, um ein Item – welches vom ItemReader eingelesen wurde – zu verarbeiten. Hier spielt sich typischerweise ein wichtiger Teil der Business Logik ab. Es können Berechnungen durchgeführt sowie Daten transformiert werden. In vielen Anwendungsfällen sind jedoch keine gesonderten Berechnungen nötig, daher ist die Definition eines ItemProcessors innerhalb eines Steps optional.

public interface ItemProcessor<I, O> {
  process(I item) throws Exception;
}

Eine ItemWriter implementierende Klasse ist das Gegenstück zum ItemReader. Sie ist dafür verantwortlich die Daten zu persistieren.

public interface ItemWriter<T> {
  void write(List<? extends T> items) throws Exception;
}

Auch hier bietet Spring-Batch eine Vielzahl vorgefertigter ItemWriter-Implementierungen an.

In Spring-Batch 2.0 ist eine Verarbeitung in so genannten Chunks vorgesehen. So werden ItemReader, ItemWriter und optional ItemProcessor für jeden Step innerhalb eines Chunks definiert. Der ItemReader liest eine bestimmte (konfigurierte) Zahl von Datensätzen ein, die der ItemProcessor dann verarbeitet. Der ItemWriter persistiert aber immer einen Chunk, also mehrere Datensätze gleichzeitig. Die Größe eines Chunks ist mit dem commit-interval konfigurierbar.

Sequenzdiagramm Reader-Writer (Quelle: Spring Batch Dokumentation)

Jobs werden im Spring Context File definiert. Durch den von Spring bekannten Dependency Injection Mechanismus können Implementierungen von ItemReader, ItemWriter oder ItemProcessor als einfache POJOs deklariert werden. Durch die Separation der einzelnen Schritte in einzelne Klassen lassen sich die Schritte einfach warten und können auch wiederverwendet werden.

Beispiel Job:

<job id="sampleJob" job-repository="jobRepository">
 <step id="step1">
   <tasklet transaction-manager="transactionManager">
     <chunk reader="itemReader" writer="itemWriter" commit-interval="10"/>
   <tasklet>
 </step>
</job>

Spring Batch bietet viele weitere Funktionalität für den Aufbau von transaktionalen Jobs, bei denen im Fehlerfall feingranular gesteuert werden kann, ob und wieweit die bisher verarbeiteten Daten gespeichert oder ob ein Rollback durchgeführt werden soll.

Für querschnittliche Aspekte wie zum Beispiel Logging oder Fehlerbehandlung können diverse Listener implementiert und über die XML-Konfiguration gesetzt werden.

Praxiseinsatz

Bei einem unserer Projekte stand ein Refactoring der Suchindizierungslogik an. Im Zuge dessen haben wir die bestehende Logik auf Spring Batch umgebaut.

Aufgabe: Befüllen eines Solr-Suchindexes aus XML-Daten. In den XML-Daten sind diverse „Dokumenttypen“ enthalten, unter anderem Audio/Video, Artikel, Segmente und GeoSegmente. Vor dem Indizieren werden die einzelnen Solr-Einträge mit umfangreichen Berechnungen aus den Roh-Daten erzeugt. Dabei gibt es einen initialen Prozess, welcher einen leeren Solr-Index aus dem kompletten Datenbestand befüllt und einen kontinuierlichen Update-Prozess, der nur noch Änderungen geschickt bekommt und die entsprechenden Solr-Einträge anpasst.

Bisher wurden  zum Indizieren mehrere Java-Klassen mit zum Teil sehr langen Methoden eingesetzt. Nach dem Umbau auf Spring Batch zerfielen diese in sehr viele kleine Java-Klassen. Die Jobs werden in einer Spring-XML deklariert, dabei können die deklarierten Beans mehrfach verwendet werden.

Ein Vorher/Nachher Vergleich mit CodeCity bietet folgendes Bild:

CodeCity mit dem "alten" Code vor der Spring Batch Umstellung

Gut zu erkennen sind mehrere hohe und vor allem breite Gebäude. Das blaue breite Gebäude ganz vorne bildet die Hauptklasse für die Indizierungslogik in Solr ab. Dieses Gebäude wurde durch den Einsatz von Spring Batch „abgerissen“. Anstelle des ehemals unansehnlichen „Klotzes“ entstand eine gemütliche Neubausiedlung aus vielen kleinen Einfamilienhäusern, wie der grün markierte Bereich in dem folgenden Bild veranschaulicht.

CodeCity mit dem Code nach der Spring-Batch Umstellung

Hinweis:
Durch die Einführung von Spring Batch wurden auch gewisse Klassen in andere Packages verschoben. Das erklärt den leicht anderen Aufbau der CodeCity. Zudem macht die mit Spring Batch umgesetzte Funktionalität nur ein Teil des gesamten Modul-Codes aus.

Zusätzlich zu den Klassen gibt es noch eine Spring XML-Datei, welche die benötigten Jobs (initialer Job, Update Job, sowie zusätzliche Jobs) mit allen ihren Steps und Listener definiert.

Performance

Die Umstellung auf Spring Batch brachte einen großen Performance Vorteil, da am eigentlichen Code durch die Modularisierung einige Schwachstellen (z.B. zu häufiges Committen an den Solr-Index) gefunden und eliminiert werden konnten. Den Overhead, den Spring Batch mit sich bringt, war bei unserem Projekt vernachlässigbar gering. Nach unserer Erfahrung geht die meiste Zeit in einem Programmablauf beim „warten“ auf externe Systeme (Datenbank,  Suche-Index, Web-Service, Filesystem etc.) verloren. D.h. durch ein Optimieren dieser Aufrufe lässt sich meist mehr Zeit einsparen, als ein Framework wie Spring Batch kostet.

Fazit

Spring Batch, wie auch Spring im Allgemeinem, hilft dem Entwickler seinen Code modularer zu gestalten. Das Design von Spring Batch hilft dem Entwickler dabei kleine und übersichtliche Klassen zu implementieren.

Des Weiteren hilft die Modellierung des Batch-Ablaufs in XML, die Prozesse besser zu verstehen. Auch können relativ schnell kleine Verzweigungen, bzw. spezielle Abfolgen modelliert werden, ohne dass eine Zeile Java-Code geschrieben werden muss. Somit konnten für den Update Prozess viele Beans aus dem initialen Prozess wiederverwendet werden.

Die XML-Datei(en) werden jedoch auch sehr schnell sehr groß und unübersichtlich. Hier bietet sich ein fein granulares Aufteilen auf mehrere „thematische“ XML-Files an.

Es lassen sich auch leicht bestimmte „Hilfssteps“ integrieren, z.B. um eine Commit-Meldung an Solr zu schicken. Dies war bisher im Java-Code versteckt und wird jetzt durch Spring Batch explizit aufgerufen.

Last but not least bekommt man bei Spring Batch viele Dinge wie Transaktionsfähigkeit, mit Restartmöglichkeit im Fehlerfall, geschenkt.

Titelbild: paulesson/flickr.com (CC BY-SA 2.0)

„Trimedialität“ ist eines der großen Zukunftsthemen der Medienbranche. Der noch nicht im Duden gelistete Begriff umfasst die redaktionelle und technische Zusammenarbeit zwischen Radio, Fernsehen und Internet. Im Bereich Fernsehen wurde in den letzten Jahren einiges erreicht, um eine Vernetzung von TV- und Online-Medien zu erleichtern.

Im Zuge einer unserer LabDay-Veranstaltungen haben wir dieses Thema aufgegriffen und eine TV-App auf Basis des Samsung Smart TV SDK umgesetzt. Es stellte sich als eine sehr einfache und interessante Zusammenführung von TV und Web heraus.

Samsung bietet hierfür eine Entwicklungsumgebung mit integriertem Emulator. Die Apps können mit HTML/JavaScript oder mit Flash entwickelt werden. Wir haben uns für den zukunftsorientierteren Standard  HTML/JavaScript entschieden.

Die Vision

Wie immer beim Entdecken einer neuen Technologie, fragt man sich selbst: „Was baue ich jetzt tolles damit?“

Unsere selbst gesetzte Anforderung war, einen bestehenden Online-Dienst bzw. ein Online-Angebot sinnvoll in die Welt des Fernsehens zu integrieren. Nach Abstimmung im Labday-Team war eine Integration von Twitter in das aktuell laufende Programm unser Ziel.

Labday: Das Samsung-App Team

Die Anwendung sollte dabei in Abhängigkeit der aktuell laufenden Sendung zugehörige Twitter-Meldungen in einem Teilbereich des Fernsehers darstellen und in regelmäßigen Abständen aktualisieren. Das generieren der benötigten Twitter-Hashs sollte sowohl redaktionell aber auch automatisiert (durch einen Algorithmus) erfolgen. Beim Umschalten des Senders sollen die Twitter-Meldungen automatisch angepasst werden.

Die User Stories

Folgende User Stories lassen sich aus unserer Labday-Vision formulieren:

• Der Fernsehzuschauer möchte am Bildschirmrand Twitter-Meldungen zur aktuellen Sendung verfolgen.
• Der Zuschauer möchte, dass sich die Meldungen regelmäßig aktualisieren.
• Der Zuschauer möchte durch die Liste der Meldungen mittels Fernbedienung navigieren können.

Während des Labdays haben wir also eine App Samsungs Smart TV entwickelt, die aus dem aktuellen TV-Programm den Titel ausliest und damit bei Twitter nach Meldungen zur Sendung sucht und diese neben der Sendung anzeigt. Die Meldungen werden regelmäßig (alle 10 Sekunden) aktualisiert.

Das Samsung SDK

Über das SDK, welches Samsung anbietet, kann eine Anwendung in Form von HTML und JavaScript entwickelt werden. Das SDK stellt hierfür verschiedene Schnittstellen bereit. Über diese kann auf Aktionen der Fernbedienung oder auf Eigenschaften des Fernsehers zugegriffen werden.

Samsung Entwicklungsumgebung

Anatomie einer Samsung TV-App

Eine auf HTML und Javascript basierte App besteht immer aus folgenden Bestandteilen:

• Die config.xml legt die Rahmenbedingungen der App fest. Z.B. ob diese im Fullscreen, als Single-Wide-App oder Ticker am unterem Bildschirmrand läuft.
• HTML-Files definieren die Inhalte bzw. die einzelnen Ansichten und binden die notwendigen Plugins als Object-Tags ein.
• CSS-Dateien zum Layouten der Applikation.
• Die Javascript-Dateien enthalten die Logik der App.
• Images etc.: Notwendige Media-Assets.

Die Umsetzung

Da wir als Supporter für HbbTV bereits unsere Anwendungen auf Samsung-Geräten testen, konnten wir von unserem HbbTV-Team ein Testgerät bekommen und unsere App unter Live-Bedingungen testen.

Zunächst haben wir uns aber Gedanken gemacht, wie wir am besten vorgehen.

Zwei Dinge sind für die Twitter-App wichtig:

1. Welche Sendung läuft gerade?
2. Unter welchen Twitter-Tags wird zu dieser Sendung getwittert?

Das laufende TV-Programm auslesen

Das Auslesen des Programm-Titels erfolgt über ein natives Plugin von Samsung, welches in der HTML Seite eingebunden werden muss:

<body onload="Main.onLoad()" onunload="Main.onUnload();" onkeydown="Main.MainKeyHandler();">

   <OBJECT id="pluginObjectTv"  border="0" classid='clsid:SAMSUNG-INFOLINK-TV' style='opacity:0.0; background-color:#000000;'> </OBJECT>
   <OBJECT id="pluginObjectPlayer"  border="0" classid='clsid:SAMSUNG-INFOLINK-PLAYER' style='opacity:0.0; background-color:#000000;'> </OBJECT>
...

Die zu implementierende Logik greift dann in JavaScript auf diese Objekte zu:

   var playerPlugin = document.getElementById("pluginObjectPlayer");
   playerPlugin.play(„http://….“);

So kann auch der benötigte Titel aus dem laufenden Programm via JavaScript ermittelt werden:

   var TVPlugin = document.getElementById("pluginObjectTv");
   var programTitle = TVPlugin.GetPresentProgram_Title();

Die passenden Tweets

Anhand eines redaktionell gepflegten Mappings wird der Hashtag ermittelt und die zur Sendung verschickten Tweets über die API von Twitter abgerufen. So wird zum Beispiel bei der Sendung „TV Total Wok WM 2012“ der Hashtag #wokwm gesucht und die dazugehörigen Tweets angezeigt.

Nicht gepflegte Sendungen werden über einen einfachen Algorithmus angenähert, welcher in Abhängigkeit der Wortanzahl einen Hashtag zusammensetzt. Wir haben folgenden Algorithmus implementiert:

1. Falls ein Bindestrich vorkommt, wird alles nach dem Bindestrich  weggeschnitten. So wird z. B. aus „Rach – der Restauranttester“ der Hashtag #rach.
2. Ersetzen aller möglichen Sonderzeichen (, : ; usw.) durch ein Leerzeichen
3. Splitten nach Leerzeichen
   1. Besteht der Titel aus mehr als zwei Worten, wird eine Abkürzung mit den ersten Buchstaben als HashTag verwendet: „Wer wird Millionär“ wird somit #wwm.
   2. Bei zwei oder weniger Worten wird ein Hashtag aus den zusammengesetzen Worten erzeugt. Aus„Verbotene Liebe“ wird #verboteneliebe.
4. Zusätzliche Oder-Verknüpfen der Strings aus Punkt 2 (in Anführungszeichen gesetzt) und des aus Punkt 3 gewonnenen HashTags. Z. B. für “Wer wird Millionär”: „wer wird millionär“ OR #wwm

Samsung App Deployment

Reicht der Emulator der Entwicklungsumgebung nicht aus, kann über einen Apache Webserver die App komfortabel auf einen Samsung-Fernseher übertragen und dort unter Livebedingungen getestet werden. Um die App zu deployen muss das TV-Gerät zunächst in den Entwicklungsmodus versetzt werden. Hierzu loggt man sich als Benutzer „develop“ und dem identischen Passwort über die Samsung-Konto-Einstellungen auf dem TV ein.  Des Weiteren benötigt man zum Deployment einen Apache Web Server. Dessen IP-Adresse wird im Entwickungsmodus auf dem TV konfiguriert. Nach Abschluss der Konfiguration kann eine App, die zuvor über das SDK gepackt wurde, deployed werden. Dazu verbindet sich der Samsung TV mit dem Apache Server und holt die als zip-File gepackte App ab und installiert diese.

Welche Apps sich der TV abholen und installieren kann, wird in der widgetlist.xml konfiguriert. Diese liegt ebenfalls im htdocs-Verzeichnis des Apache. Das Ablegen der gepackten App auf dem Server sowie das erzeugen des Eintrags in der widgetlist.xm kann automatisiert vom SDK während des Packaging-Prozesses vorgenommen werden.

Samsung widgetlist.xml

Die App erscheint in der Übersichtliste des Smart TV und kann mit der Fernbedienung gestartet werden.

Das Ergebnis kann sich nach unserer Meinung sehen lassen:

Die Samsung Twitter-App im Einsatz

Stolz wurden im Anschluss einige Tests mit der App durchgeführt: Unser Algorithmus hat für alle Serien passende Tweets gefunden!

Download der Demo-App

Im nachfolgenden Link ist ein Zip-Datei mit der hier beschriebenen App. Diese Zip-Verzeichnis muss entpackt und als Projekt im Samsung SDK 2.5 geöffnet werden. Anschließend kann die App wie oben beschrieben auf den Fernseher deployed werden.

Download twapp.zip

Teaser-Bild: kevenlaw/flickr.com (CC BY-SA 2.0)

Cache bei Repository-Zugriffe

In der Regel basieren Anwendungen, welche mit der CAE realisiert werden, zum größten Teil auf Inhalten aus einem CoreMedia Content-Repository. Zugriffe auf das Content-Repository erfolgen mittels der Unified API (UAPI) von CoreMedia. An dieser Stelle gibt es den ersten Cache, den UAPI-Cache. Er speichert alle Zugriffe auf das Content-Repository, um bei einem erneuten Zugriff auf die selben Daten und somit die Zugriffszeit zu verkürzen. Denn anstatt die Daten nochmals aus dem entfernten Content-Repository abzufragen, kommen diese direkt aus dem UAPI-Cache. Dieser Cache wird im Hauptspeicher vorgehalten.

Die Aktualität der im Cache abgelegten Daten gewährleistet ein eventbasierter Ansatz. Die Daten des Cache werden verworfen sobald die zugrunde liegenden Inhalte im Content Repository geändert werden. So bleibt die Verwendung des UAPI-Cache für den Entwickler vollkommen transparent. Die UAPI kümmert sich vollkommen selbständig um die Verwaltung und Einbindung des Cache.

Cache in der Business-Logik

Um zeit- oder lastkritische Berechnungen in der Business-Logik zwischenzuspeichern bietet CoreMedia in der CAE die Dataviews an. Dabei handelt es sich um eine Caching-Schicht deren Programmcode auf Basis einer XML-Konfiguration automatisch generiert wird. In der Business-Logik muss kein Programmcode für das Caching implementiert werden. Der Programm-Code ist frei von irgendwelchen API-Calls für das Caching. Mit Dataviews lassen sich ein Netz von Business-Objekten aufbauen deren Berechnungsergebnisse im Hauptspeicher gehalten werden. Dabei lassen sich nicht nur Berechnungsergebnisse zwischenspeichern, welche auf Daten aus dem Content-Repository basieren. Diese nutzen für die Verwaltung des Dataview-Cache auch die Events des Content-Repository. Es können auch Berechnungen, welche auf andere Datenquellen basieren im Dataview-Cache vorgehalten werden. Dabei erfolgt die Verwaltung der Daten zeitbasiert. Als Alternative zur zeitbasierten Verwaltung kann für die jeweilige Datenquelle ein geeigneter Benachrichtigungs-Mechanismus implementiert werden. Über diesen Mechanismus wird der Cache benachrichtigt, falls es in der Datenquelle Änderungen gibt. Hierfür bietet CoreMedia in der API entsprechende Schnittstellen.

Die verschiedenen Caches der CoreMedia CAE.

Cache bei Auslieferung

Neben den bisher angesprochenen Caches, welche innerhalb der Anwendungslogik agieren und nur im Hauptspeicher existieren, bietet CoreMedia auch einen Cache, welcher auf der Kommunikationsebene zwischen Web-Server und Browser ansetzt. Der HTTP-Cache, speicherte komplette HTTP-Antworten. Dieser Cache speichert nicht die Zugriffe auf das Content-Repository oder die Berechnungsergebnisse einzelner Business-Objekte sondern die komplett aufbereitet Darstellung, wie sie an den Browser des Benutzers geschickt wird.

Von ähnlichen Cache-Mechanismen, welche mit gewöhnlichen Webservern realisiert sind, hebt sich der CoreMedia HTTP-Cache durch die Tatasche ab, dass er für die Verwaltung der zwischengespeicherten HTTP-Antworten auch wieder auf die Events des CoreMedia Content-Repository zurückgreifen kann. Der entscheidende Unterschied zu den bisher angesprochenen Caches ist die Tatsache, dass es sich beim HTTP-Cache um einen nicht flüchtigen Cache handelt. Der HTTP-Cache steht auch nach einem Neustart der CAE im selben Zustand wie vor dem Herunterfahren zur Verfügung. Der HTTP-Cache persistiert seinen Inhalt auf der Festplatte. Zur Verwaltung der Daten nutzt er eine relationale Datenbank.

Fazit

Ich denke es wird deutlich, dass CoreMedia dem Entwickler in der CAE an entscheidenden Stellen Mechanismen zum Caching bietet. Bereits der UAPI-Cache beeinflusst die Bearbeitungszeit der eingehenden Anfragen positiv, da er die Netzwerkkommunikation mit dem Content-Repository beträchtlich verringert. Vor allem aber ist der UAPI-Cache fester Bestandteil der UAPI und muss weder gesondert konfiguriert werden, noch muss etwas zusätzlich implementiert werden.

Aufwändiger gestaltet sich hingegen die Einführung der anderen Caches. Die Szenarien in welchen der Einsatz des Dataview- oder HTTP-Caches sinnvoll sind, sind spezieller. Der Dataview-Cache spielt seine Stärke vor allem bei komplizierten Berechnungen innerhalb der Business-Logik aus, typische Fälle für den Dataview-Cache sind die Berechnungen der Navigation oder die Anbindung von externen Datenquellen. Wobei sich der Dataview-Cache für Beans und Methoden, welche auf Inhalte aus dem Content-Repository aufbauen, durch eine XML-Konfiguration noch relativ einfach aufsetzen lässt. Für das Caching von externen Datenquellen muss für eine flexible reagierende Lösung schon mehr Entwicklungsaufwand investiert werden.

Der HTTP-Cache eignet sich vor allem in Fällen in welchen die Erzeugung der Darstellung aufwändig ist. PDFs könnte beispielsweise nach der Generierung im HTTP-Cache abgelegt werden.

Daher ist es vollkommen legitim die Verwendung der beiden zuletzt genannten Caches erst in Betracht zu ziehen wenn sich ein konkreter Engpass, zum Beispiel im Laufe eines Lasttest, in der Web-Applikation abzeichnet.

Titelbild: twicepix / flickr.com