Die Entwicklung einer komplexen Unternehmensanwendung mit verschiedenen Clients war bisher für unerfahrene Programmierer nur sehr schwer möglich. Auch nach einer intensiven Einarbeitungszeit und vielen schlaflosen Nächten waren die Resultate meist schlecht wartbar und nicht erweiterbar. Unterstützende Starter Kits und kleine Beispiele gibt es viele, diese decken jedoch meist nur einzelne Teilbereiche des Technologie-Portfolios ab. Soll eine leistungsfähige und skalierbare Client-Server-Anwendung erstellt werden, ist es wünschenswert, sich an einer umfassenderen Beispielanwendung als Vorlage zu orientieren. AdventureWorks Cinema bietet genau diese und stellt dabei gleichzeitig verschiedene Client-Technologien für Windows, Office, Windows für Pocket PC und Web vor. Die mit Visual Studio 2005 entwickelte Anwendung pictureet mit fünf Frontend-Samples und einem Backend-Sample einfache Prozesse aus dem Umfeld eines Kinos ab. Das Szenario "Kino" wurde vom Projektteam, bestehend aus zehn über Deutschland verteilten Microsoft Student Partner ausgewählt, um Entwicklern unabhängig von der Sprache und Kenntnissen anderer Kulturen die Möglichkeit zu geben, sich mit einfachen und bekannten Prozessen schnell und leicht in die Beispielanwendung einzuarbeiten. Damit sich auch Programmierer ohne .NET-Erfahrung schnell zurechtfinden, wurde der Code möglichst einfach gehalten. Anhand einiger "Best Practices" wird gezeigt, wie umfangreiche Client-Server-Architekturen strukturiert aufgebaut und erweitert werden.

Feature-Überblick

Das erste der insgesamt sechs Samples ist eine Windows-Anwendung, über die der Kinobetreiber Informationen zu Filmen, Vorstellungen und News verwaltet. Über einen mit den Visual Studio Tools for Office (VSTO) auf Word aufbauenden Client ist es ihm außerdem möglich, Werbeprospekte zu generieren und Newsletter zu versenden. Der Kinobesucher holt sich diese Informationen über eine mobile Anwendung auf seinen PDA - verwirklicht mithilfe des Compact Framework 2.0 - oder via Web über eine ASP.NET 2.0-Anwendung und kauft sich dort die Tickets, die mit einem Ticketcode belegt werden. Dieser muss wiederum auf Seiten des Kinobetreibers über die Windows-Applikation verifiziert und entwertet werden. Über einen RSS-Feed können sich Filmliebhaber über Neuigkeiten informieren, sowie einen personalisierten Feed anfordern, der anhand seines in der mobilen Applikation angelegten Profils erstellt wird. Der Schwerpunkt bei AdventureWorks Cinema wurde bewusst nicht auf die Anzahl der Features für eine vollständige und einsetzbare Kino-Anwendung gelegt, sondern auf die Gesamtstruktur und Neuerungen des .NET Framework 2.0. Denn die bestehenden Funktionalitäten sind hinreichend komplex und ausreichend, um die Architektur zu erweitern oder an eigene Problemstellungen anzupassen. Tabelle 1 zeigt eine Übersicht der wichtigsten in AdventureWorks Cinema eingesetzten Technologien und Konzepte und angewendeten Programmiersprachen.
 

Architektur

"Auf die Anwendung sollen mehrere Benutzer gleichzeitig zugreifen können, sowohl unsere Mitarbeiter über eine Windows-Oberfläche als auch unsere Kunden über ein Webportal", so lautet häufig eine Anforderung an moderne Anwendungen. Eine einfache Möglichkeit ist, die einzelnen Anwendungen direkt mit dem Datenspeicher, meist eine Datenbank, kommunizieren zu lassen. Dies ist zum einen aus Sicherheitsaspekten bedenklich, denn jeder Windows-Client muss so die Verbindungsdaten und damit das Passwort für den Datenzugriff kennen, zum anderen auch aus Sicht der Wartung, denn sollten später auch nur kleinste Änderungen am Datenbankschema vorgenommen werden, muss jeder Client aktualisiert werden. Deutlich besser ist eine Client-Server-Architektur, wie sie in AdventureWorks Cinema implementiert wurde. Der Server kümmert sich um die Basis der gesamten Anwendung, also die Datenhaltung und die zugehörige Geschäftslogik. Letztere stellt er den Clients über eine spezifizierte Schnittstelle zur Verfügung. Zur Datenhaltung wurde eine SQL-Server-2005-Express-Datenbank [2] direkt in das Server-Sample integriert. Die Schnittstelle zwischen Client und Server ist ein Web Service, der von den fünf Client-Samples konsumiert wird. Das Spezifizieren dieser Schnittstelle hat den Vorteil, dass beliebig viele weitere Clients problemlos an die bestehende Architektur angebunden werden können und existierende Funktionalität wieder verwendet werden kann.

Schichtenmodell

Wiederverwendbarkeit, Sicherheit, Wartbarkeit und Flexibilität wird heutzutage von Software erwartet, die von sich behauptet, State-of-the-Art zu sein. Dies führt zu einem Schichtenmodell, bei dem jeder Bereich eigene Schnittstelle besitzt und im Allgemeinen keinen Zugriff auf seine Interna bietet. Zusätzliche Einschränkungen legen fest, dass jede Schicht nur mit der direkt unter ihr liegenden Schicht interagieren darf. Damit wird „Wildwuchs“ innerhalb der Anwendung verhindert und der Kontrollfluss bleibt nachvollziehbarer. Darüber hinaus können Grenzen klar definiert werden, die einen erheblichen Einfluss auf Infrastruktur und Sicherheit haben können. Das Schichtenmodell vereinfacht in realistischen Anwendungen die Wartung, da Verantwortlichkeiten isoliert voneinander implementiert sind.

Abpictureung 1 zeigt das Schichtenmodell von AdventureWorks Cinema. Die unterste Ebene ist die Datenzugriffsschicht, kurz DAL. Sie ist für jegliche Kommunikation mit der Datenbank zuständig. Die Server-Geschäftslogik baut auf die Datenzugriffsschicht auf. Sie überprüft die Einhaltung der Geschäftsregeln und Sicherheitsrichtlinien. Der Abstraktionsgrad der Server-Geschäftslogik von der Datenzugriffsschicht hängt im Allgemeinen von der zu entwickelnden Anwendung ab. Clientkommunikation und die Geschäftslogik haben wenig gemein, weshalb eine eigene Schicht für die Web Service-Schnittstelle diese beiden Teile klar voneinander abtrennt. Diese Trennung ermöglicht beispielsweise, später eine Schnittstelle anbieten zu können, die über .NET Remoting mit den Clients kommuniziert. Auf Seiten der Clients ist das Bild sehr ähnlich. Um die Flexibilität des Servers effizient nutzen zu können, gibt es bei allen Clients eine einheitliche Servicezugriffsschicht, kurz SAL (Service Access Layer), die für die Kommunikation mit dem Server zuständig ist. Bei AdventureWorks Cinema übernimmt diese Schicht auch das Caching der Ergebnisse von Anfragen. Für offlinefähige Clients sollten Teile der Geschäftslogik, von denen zu erwarten ist, dass sie sich eher selten ändern, auch auf den Clients zur Verfügung gestellt werden -
das ermöglicht auch offline eine Prüfung der Geschäftsregeln. Die Alternative ist, die Prüfungen erst durchzuführen, wenn der Client wieder online ist. Für den Benutzer wäre das jedoch stark von Nachteil, da mögliche Fehler erst deutlich später festgestellt werden, was eine Korrektur häufig schwieriger gestaltet. Dies darf natürlich die Prüfung der Geschäftsregeln auf dem Server nicht ersetzen. Bei AdventureWorks Cinema nennt sich diese Schicht Shared Business Logic (SBL), da sie von allen Client-Anwendungen gleichermaßen verwendet wird.
Auf oberster Ebene befindet sich die Präsentationsschicht. Sie ist aufgrund unterschiedlicher Basistechnologien (Windows Forms, VSTO, ASP.NET) spezifisch für jeden Client (Abpictureung 2 zeigt den Windows Client). Dadurch ist eine Erweiterung um einen zusätzlichen Client ohne großen Aufwand möglich, da nur die Präsentationsschicht zu den bereits bestehenden Schichten SBL und SAL hinzugefügt werden muss.

Fazit

Mit AdventureWorks Cinema wurde von Microsoft erstmals eine Beispielanwendung speziell für den deutschsprachigen Raum geschaffen, welche mit ihrer Architektur und ihrem Schichtenmodell ein Vorpicture für die Entwicklung komplexerer Anwendungen sein kann. Besonders .NET-Einsteiger finden hier eine geeignete Vorlage, die auf die Neuentwicklung von Unternehmensapplikationen mit mehreren Clients angewendet werden kann. Die Samples werden in der MSDN Online Library [1] als einzelne Zip-Dateien zum Download zur Verfügung stehen.
Manuela Miller (info@manuela-miller.de) studiert Angewandte Informatik an der Universität Augsburg und leitete als Projektmanagerin die Entwicklung von AdventureWorks Cinema. Thomas Dallmair (dallmair@in.tum.de) studiert Informatik an der TU München und arbeitet als Software-Entwickler bei der The Project Group Informationstechnologie GmbH. Er war Mitglied des Entwicklerteams des AdventureWorks Cinema Server Samples.

Links & Literatur

• [1] Download und Dokumentation aller Samples auf der MSDN Online Library
• [2] Die deutsche Seite für Visual Studio 2005
• [3] Download von SQL Server 2005 Express Edition