Aufbau
Der Aufbau des WM-Tippspiels ist serviceorientiert. Es gibt verschiedene Komponenten, welche über diverse Nachrichtenkanäle, wie z.B. Web Services, Remoting und MSMQ kommunizieren - diese verbinden die einzelnen Bereiche der Anwendung miteinander. Die Kommunikation zwischen den Client-Anwendungen und dem Server wurde mit Web Services realisiert. Dabei handelt es sich um den TippService und den NewsService auf der Serverseite und den ReceiveService auf der Client-Seite. Der wichtigste und funktionsreichste Service ist der TippService. Dieser bietet Funktionalitäten für die Verwaltung von Spielen, Ergebnissen, Benutzern und deren Tipps sowie zusätzlicher Daten. Für die Datenhaltung wird die Objektdatenbank db4o [1] eingesetzt. Dadurch ist kein O/R Mapping oder gar ein Umsetzen der relationalen Strukturen in .NET-Objekte notwendig. Zur Präsentation der Daten werden drei Anwendungen eingesetzt. Als Hauptanwendung kommt eine ASP.NET-Webseite zum Einsatz - diese verwendet den TippService mit seinen vielfältigen Funktionen. Eine zweite Anwendung ist ein WinForms-Client, der DesktopTicker, hauptsächlich für das Darstellen der News und den persönlichen Tipps zuständig ist. Der DesktopTicker (Subscriber) registriert sich am Server (Publisher) für den Empfang von News und neuen Spielständen mit einer Rückrufadresse. Nun übernimmt der DesktopTicker die Rolle eines Servers, der unter dieser Adresse einen Web Service zur Verfügung stellt. Dieser Web Service wird jedoch nicht im IIS sondern in einer eigenen AppDomain der Anwendung durch einen System.Net.HttpListener (dank der großartigen Unterstützung durch Christian Weyer von thinktecture [5]) gehostet. Wenn sich nun ein Spielstand ändert, wird der DesktopTicker vom Server davon benachrichtigt und kann diese Information entsprechend anzeigen. Hier wurde das Observer-Pattern [2] eingesetzt, wodurch die technischen Details vor dem DesktopTicker versteckt worden sind. Eine dritte Anwendung ist der Administrator. Dieser nutzt vor allem die Verwaltungsfunktionen des TippService.Tabelle 1: 16 Projektbausteine sollt ihr sein
|
Projektlebenslauf
November/Dezember 2005 In der Novemberausgabe des Jahres 2005 warb das dot.net magazin mit einem Artikel um die Teilnahme am Projekt „WM-Tippspiel“. Anfangs waren neben dem Team- und Projektleiter Thomas Becker vier weitere Entwickler beteiligt. Bei der Anmeldung konnte man seine Lieblingspositionen angeben - meistens wurden diese auch berücksichtigt. Durch leichte Kommunikationsprobleme und das nahende Weihnachten kam das Projekt im Jahr 2005 nicht richtig in Gang. Januar 2006 Die ersten Unternehmungen laufen an. Die Positionen sind weitgehend aufgeteilt. Zusätzlich melden sich auch noch zusätzliche Entwickler, die am Projekt teilnehmen möchten. Dies ist auch notwendig, da einige der Teammitglieder wieder absagen müssen. Am Ende des Monats pegelt sich die Projektgruppe bei acht Entwicklern ein. Die Entwicklung des Kontraktes des zentralen Web Service läuft an. Für bessere Kommunikation wird ein Projektportal mittels SharePoint Portal eingerichtet - dieses bietet Möglichkeiten für Diskussionen, Kontakt, Aufgabenvergabe, Link-Sammlung und ein Projektblog. Im Endeffekt hat sich aber die Kommunikation über Mail und Instant Messenger durchgesetzt. Februar 2006 Es ist immer noch Dynamik im Projektteam vorhanden. Durch die nahende BASTA! Spring Edition in Frankfurt/Mörfelden [3] bietet sich die Möglichkeit, erste persönliche Kontakte zu schließen. Durch die weite Verteilung aller Teammitglieder beschränkt sich das Treffen aber auf zwei Mitglieder - Thomas Becker und Andreas Gräfe. Hier wird der Kontrakt des Web Services festgesetzt und das weitere Vorgehen besprochen. Nun sind eigentlich alle Spielplätze belegt. Manche sind sogar mit zwei Entwicklern bemannt, wie z.B. das Mittelfeld mit Jan Schuster und Andreas Gräfe. Zum Ende des Monats wird die endgültige Architektur aller Komponenten festgelegt - nur im Bereich Datenbank gibt es noch Probleme. März 2006 Die Entwicklung des Middle Tier ist in vollem Gange. Zu den schon erstellten DataTransferObjects, die das Datenmodell darstellen, werden BusinessLayer, ServiceAccessLayer und Web Service erstellt. Der ServiceAccessLayer ist auf der Client-Seite angesiedelt und dient als Factory. Im ServiceAccessLayer sind zwei Provider implementiert. Der ServiceProvider greift die Daten direkt vom Web Service ab. Der DummyProvider wird zum Testen des Interfaces und der Datenstruktur eingesetzt. Somit können die Client-Entwickler sofort gegen den ServiceAccessLayer programmieren, ohne dass der Backend-Bereich fertig gestellt ist. Dies ermöglicht eine weitestgehend parallele Entwicklung des Systems. Mit weiteren Zugängen im Projektteam wird nun auch die Idee vom Desktopticker als WindowsForms-Projekt umgesetzt.
Details der einzelnen Komponenten
Durch den Einsatz der Objektdatenbank db4objects war von Anfang an klar, dass dieses Projekt in neue Gefilde der Software-Entwicklung vordringen soll. Natürlich bestand auch die Möglichkeit auf den SQL Server 2005 zu setzen. Ein Referenzprojekt sollte aber nicht an altbewährten Technologien festhalten - im Nachhinein können wir das nur bestätigen. Im Middle Tier war die Vorgehensweise auch sehr schnell geklärt: Contract First lautete das Zauberwort. Als Modellierungssprache für die Datenobjekte entschieden wir uns für XML-Schema. In einem längeren Entwicklungsprozess entstanden die benötigten Datenobjekte, die anschließend für die Modellierung der Nachrichten Anwendung fanden. Die Erstellung der Schemas bildete einen großen Anteil an der Gesamtarbeit. Bis zu diesem Zeitpunkt wurde noch keine Zeile C#-Quellcode geschrieben. Nun mussten wir uns entscheiden, welches Tool wir für die Generierung der Datenobjekte und Nachrichten als .NET-Klassen, Schnittstellen usw. verwenden. Zur Auswahl standen hier das Tool xsd.exe aus dem SDK oder das Tool WSCF von thinktecture [5]. Hier kam die BASTA! 2005 Spring Edition genau richtig - Christian Weyer von thinktecture überließ uns auf der BASTA! die neue Version seines Tools. Dadurch konnten wir schon drei Wochen vor dem Release mit der Version WSCF 0.6 experimentieren. Im Vergleich mit xsd.exe glänzte dieses Tool vor allem durch seine Benutzerfreundlichkeit. Auch Ralf Westphal [6] hat uns ein Geschenk zur BASTA! gemacht - von ihm haben wir die Präsentationsvorlage für die Darstellung als Software-Zellen erhalten. Nun aber zum Aufbau - Abbildung 5 zeigt sehr schön das Zusammenspiel der einzelnen Komponenten.
