SportEventAnalyserJingle
Das SportEventAnalyserJingle Projekt bündelt sämtliche Funktionen, die zur Kommunikation mit Jingle (XEP-0166) notwendig sind. Die Kernkomponente stellt die SportEventAnalyserJingle-Klasse dar. Sie ermöglicht den Aufbau einer Peer-to-Peer-Sitzung über XMPP und kann sowohl zum Senden, als auch zum Empfangen von Nachrichten eingesetzt werden. Damit ist sie wesentlich für die Kommunikation zwischen dem Traffic-Generator und dem Mobilis Service zuständig.
Mit der Jingle (XEP-0166) genannten XMPP-Erweiterung kann eine Peer-to-Peer-Sitzung vereinbart werden. Als wesentlicher Bestandteil der Spezifikation umfasst das Jingle Signalling die Traversierung von NAT. Die Peer-to-Peer-Kommunikation erfolgt über UDP.
Das Projekt ist nicht eigenständig nutzbar und soll ausschließlich die Funktionen um Jingle kapseln.
Da sowohl der Traffic-Generator neue Events über die aufgebaute Verbindung senden möchte, als auch der Mobilis Service 
diese empfangen soll, muss das Projekt von beiden Projekten referenziert werden.
Die Aufgabe des Projektes ist die Umsetzung einer auf der Jingle-Spezifikation basierten Peer-to-Peer-Kommunikation. Als Grundlage zur Aushandlung der Peer-to-Peer Kommunikation wird die Jingle-Umsetzung von SmackX genutzt. Sie ermöglicht die Aushandlung, Auswahl und Kontrolle einer Peer-to-Peer-Verbindung über XMPP.
Da das SportEventAnalyserJingle Projekt auf der SmackX Library aufsetzt, ist die Struktur weitestgehend vorgegeben. Es sind allerdings einige Dinge im Bezug auf die Definition eines Kommunikationsobjektes wichtig, sowie die Schnittstelle zur Nutzung des Projektes.
Als grundlegendes Kommunikationsobjekt wurde die abstrakte Raw-Klasse definiert. Nur Objekte, die von dieser Klasse erben, können als Kommunikationsobjekte verwendet werden.
Ein Raw-Objekt muss zur Kommunikation in eine binäre Repräsentation umgewandelt (serialisiert) werden. Da eine Umwandlung zur Laufzeit über Java-Reflection den Serialisierungsprozess wesentlich verlangsamen würde, implementiert die Raw-Klasse das Externalizable-Interface. Dadurch ist jedes Raw-Objekt selbstständig für die Serialisierung und anschließende Deserialisierung zuständig.
Um ein Objekt wieder in seine ursprüngliche Version überführen zu können, muss dises aus dem eingehenden Binärdatenstrom eindeutig identifiziert werden können. Daher muss ein Raw-Objekt stets einen eindeutigen, wohldefinierten payloadType besitzen. Dieser stellt sicher, dass das Objekt der richtigen Objektstruktur zugeordnet werden kann und somit die Daten korrekt deserialisiert werden.
Zuletzt muss ein Raw-Objekt stets das Interface Cloneable implementieren und die clone()-Methode umsetzen. Eine korrekte Umsetzung dieser Methode ist Pflicht, damit eine prototypische Deserialisierung durchgeführt werden kann. Die clone()-Methode wandelt schließlich den gefüllten Prototyp in ein eigenständiges Objekt um.
Die Schnittstelle für das Projekt stellt die SportEventAnalyserJingle-Klasse dar. Sie bietet alle notwendigen Operationen an, um Objekte zu senden bzw. Listener für eingehende Objekte zu registrieren.
Neben den Methoden für eine Nutzung des SportEventAnalyserJingle Projektes erfolgt in der Klasse auch die Registrierung von neuen Payloads (in der registerPayloads()-Methode). Sämtliche Payloads, die an dieser Stelle registriert wurden, sind dem System bekannt und können als Objekte versendet/empfangen werden.
Obwohl die SmackX-Library eine weitestgehende asynchrone Jingle-Aushandlung durchführt, kann das SportEventAnalyserJingle Projekt ohne Wartezeiten genutzt werden. Ein zusätzlich umgesetzter SessionObserver ermöglicht die Nutzung des Projektes bereits während der Initialisierungsphase.