Kick@26° nutzt GAE und Wicket

W-JAX Challenge: Projekt in der Cloud

Fußball, Software und Challenge? Drei Schlagworte, die das Projektteam um Kick@26° hellhörig machten. Das Ganze noch im Mantel der WJAX-Konferenz hat dann den Ausschlag gegeben als Mannschaft, bestehend aus drei Personen, das Finale der Challenge zu forcieren. Der Name Kick@26° steht für „Kicken in Johannisburg“, denn auf dem 26. Breitengrad liegt einer der Austragungsorte der kommenden WM.

Da wir alle im Beruf oder Studium stehen und mehrere hundert Kilometer voneinander entfernt wohnen, haben wir uns abends in Skype-Konferenzen getroffen. Schnell stand fest, dass mit kurzen Entwicklungszyklen von einem Tag am effektivsten das Ziel erreicht wird. Pro Person waren etwa 15 Stunden Aufwand nötig, insgesamt also etwa 45 Stunden.

Wir haben uns im Vorfeld der Challenge immer wieder mit dem interessanten Themenkomplex „Platform as a Service“ (PaaS) auseinandergesetzt. Jetzt stand die Challenge an, und schnell war klar, wir entwickeln und hosten unsere Anwendung bei einem PaaS-Provider. Die Wahl fiel auf die Google App Engine, da mit geringem Aufwand und ohne Kosten sofort die Google-Infrastruktur für die eigene Anwendung genutzt werden kann. Als IDE haben wir Eclipse genutzt, da es für die GAE ein Plug-in gibt, das „per Knopfdruck“ die lokale Anwendung in die Cloud deployt.

Als SVN, Wiki nutzten wir das Project Hosting von Google Code, da es uns aus einem anderen noch laufenden Projekt bekannt und sehr schnell ohne besonderen Aufwand einzurichten war. Da wir dezentral zusammengearbeitet haben und mit möglichst wenigen zeitlichen Ressourcen zum Ziel kommen wollten, hatten wir hinsichtlich der verwendeten Technologien und der Architektur besonders hohe Anforderungen. Zum einen musste die Architektur eine parallele Entwicklung einzelner Komponenten ermöglichen, zum anderen sollte ein Höchstmaß an Testbarkeit und Wartbarkeit erreicht werden. Außerdem sollte die eingesetzte Technologie eine Rollentrennung zwischen Frontend-Designer und Entwickler ermöglichen, komponentenorientiert sein und die Entwicklung ansprechender Web-2.0-Oberflächen auf Basis objektorientierter Paradigmen in Java ermöglichen.

Abbildung 1

Im Frontend kommt Apache Wicket zum Einsatz, weil es die für uns o. e., hochgesteckten Anforderungen im Bereich der Frontend-Architektur gut erfüllt.

Die Möglichkeit der Rollentrennung kommt in Wicket durch die Trennung von Layout und Logik zustande. Dabei wird das Layout ausschließlich im HTML-Markup beschrieben, die Logik in der Java-Klasse. Dadurch wird das Webdesign von der Java-Entwicklung entkoppelt.

Abbildung 2

Wicket ermöglicht es außerdem, komponentenorientiert zu arbeiten. Fachlich abgekapselte Fragmente konnten so parallel entwickelt werden. Ein weiterer Punkt war das in Wicket integrierte Testframework. Mit wenig Aufwand konnten so Unit-Tests für die Oberflächenkomponenten entwickelt werden:

@Test public void testHitliste(){ myTestService.setReturnValues( Arrays.asList(BenutzerFixture.FIXTURE, BenutzerFixture.FIXTURE, BenutzerFixture.FIXTURE, BenutzerFixture.FIXTURE, BenutzerFixture.FIXTURE )); startTest(); assertTableRowCount("table", 5); }

[ header = Seite 2 ]

In der Anwendung selbst findet auch eine Rollentrennung statt: Einerseits der Admin, der die notwendigen Daten zum Tippen hinterlegt, andererseits der Tippspieler:

Abbildung 3

Für beide Rollen wurden unterschiedliche Oberflächen mit den rollenspezifischen Widget-Komponenten implementiert.

Abbildung 4

Abbildung 5

In der Businessschicht kommt das Open-Source-Framework Spring zum Einsatz. Die Restriktionen in der GAE erlauben keine JEE-Frameworks, das brachte uns schnell zu Spring, denn es bietet uns ein breites Spektrum an Funktionalitäten zur Implementierung von Prozessen und ermöglicht die Entkopplung einzelner Komponenten. Spring bietet des weiteren Querschnittsaspekte wie Security und Transaktionshandling durch deklarative Beschreibung.

Persistenz in einer relationalen Datenbank? Google sagt: „Nein“! Der auf BigTable basierende DataStore ist vom Konzept her eine hierarchische Anordnung von Entitäten. Google setzt BigTable selbst ein, um die riesigen Mengen an Daten zu verwalten, die unter anderem in Google Maps, Earth oder auch in YouTube anfallen.

Vermutlich aus Gründen der Skalierbarkeit bietet Google keine Möglichkeit, eine relationale Datenbank „in the cloud“ zu nutzen. Zur Anbindung der Persistenz wird die Spring-JPA-Integration mit Datanucleus als JPA-Provider verwendet, um den Zugriff auf die Datenhaltung zu kapseln.

[ header = Seite 3 ]

Im Rahmen des Projekts wurde schnell deutlich, dass der Entwickler Transaktionen, Entity-Beziehungen und Abfragen anders designen muss als beim Mapping von Objekten auf eine relationale Datenbank via Hibernate oder ähnlichen Frameworks.

Die Authentifizierung der Benutzer erfolgt durch Anmelden mit einem vorhandenen Google-Konto. Das hat uns die Konzeption und Implementierung einer Benutzeranlage und Authentifizierung erspart.

Abbildung 6

Neben den durch die Challenge-Spezifikation vorgegebenen Funktionen hat sich das Team eine Schnittstelle mit „Schmankerl“-Charakter überlegt: Basierend auf dem XMPP-Protokoll können Benutzer des Systems mit ihrem jeweiligen XMPP-Client ihren aktuellen Punktestand abfragen. Dazu müssen diese einfach unsere Anwendung als „Buddy“ in ihre Liste holen und per Direktchat den Namen des Benutzers senden.

Damit XMPP in der GAE-Anwendung zur Verfügung steht, muss in Appengine-web.xml der Dienst eingebunden werden:

<inbound-services> <service>xmpp_message</service> </inbound-services> 

In einer speziellen Servlet-Implementierung lassen sich die Nachrichten empfangen, parsen, und eine Antwort erstellen:

Message lRe = new MessageBuilder().withRecipientJids(lMsg.getFromJid()) .withBody(lReBody).build(); lXMPP.sendMessage(lRe); 

Die Idee der Kommunikation via XMPP bietet noch viel mehr Potenzial, denn über diesen textbasierenden Kommunikationskanal mit dem Benutzer lässt sich eine ganz eigene DSL abbilden:

Abbildung 7

Die Entwicklung auf Basis der Google App Engine verlief erstaunlich problemlos. Die uns bekannten Frameworks Spring und Wicket spielten im Rahmen des kleinen Projekts ihre Stärken zur komponentenorientierten Entwicklung voll aus.

Die einzeln entwickelten Fragmente ließen sich so nahtlos zusammensetzen. Nur so konnten wir die Anforderungen in so kurzer Zeit umsetzen. Zum Ende hin bekamen wir noch einige Probleme mit der Anbindung der GAE-Persistenz. Nachdem wir das Persistenzkonzept des Google-Datastores durchschaut und unsere Anwendung daraufhin angepasst hatten, waren auch diese schnell Geschichte.

Die WJAX-Challenge war für uns die Chance, uns neben Beruf und Studium mit interessanten Technologien und Frameworks auseinanderzusetzen. Spannend war auch die Betrachtung der Mitstreiter-Schöpfungen.

Alexander Elsholz ist Senior-Softwarearchitekt bei WidasConcepts IT-Consulting, Robert Kolle ist Student der Informatik an der Hochschule Bonn und teilzeitangestellter Softwareentwickler bei der HDI-Gerling und Philipp Schütz, Student der Wirtschaftsinformatik an der Hochschule Niederrhein und teilzeitangestellter Softwareentwickler bei WidasConcepts IT-Consulting.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.