| Sprache: |
Die Anforderungen an eine Anwendung ändern sich häufig im Laufe des Lebenszyklus. Eine tragfähige, offene und flexible Architektur ermöglicht es der Anwendung mitzuwachsen. Zusätzlich vereinfacht diese eine Arbeit im Team und verkürzt damit die Entwicklungszeit und die damit verbundenen Kosten.
Eine Serviceorientierte Architektur stellt eine solche Basis zur Verfügung. Die Entwicklung einer klassischen Windows Anwendung hin zu einem Cloud-basierten Service wird hierdurch ermöglicht, wie ein Blick auf die Historie der AIT NETFactory zeigt.
In einer klassischen Anwendung läuft die gesamte Applikation in einem Prozess. Eine Betrachtung von parallelen Zugriffen, der Skalierbarkeit sowie von Sicherheitsaspekten ist zunächst nicht gefordert. Es lohnt sich jedoch bereits zu diesem Zeitpunkt über mögliche Zukunftsszenarien nachzudenken. Gegebenenfalls später notwendige Architekturanpassungen sind häufig mit sehr hohen Kosten verbunden. Aus diesem Grund lohnt es sich bereits jetzt die Basis für eine flexible Architektur zu legen. Hierzu gehören eine saubere Trennung der Schichten der Anwendung nach dem MVVM Pattern, eine Kapselung der Business Logik in Services sowie eine Integration der einzelnen Komponenten über das Managed Extensibility Framework (MEF). Die zusätzlich entstehenden Kosten werden durch eine deutlich verbesserte automatisierte Testbarkeit zum Teil kompensiert.
Um mit mehreren Bearbeitern an einem Projekt parallel arbeiten zu können, ist eine Skalierung erforderlich. Die vorbereitete Aufteilung der Komponenten ermöglicht ein Herauslösen der Business Logik. Diese kann auf einem zentralen Server als Service bereitgestellt werden. Die per ClickOnce verteilten Smart Clients greifen auf diese mithilfe der Windows Communication Foundation zu (WCF).
Eine Verteilung erhöht die Komplexität. Clients müssen sicher authentifiziert, die Datenübertragung abgesichert und auf mögliche Verbindungsabbrüche reagiert werden. Die Erweiterungen werden durch den Einsatz Windows Identity Foundation (WIF) und einem generierten Proxy für den Dienstzugriff gelöst.
Die bestehenden Views, ViewModels und Services müssen nicht verändert werden. Die zusätzlich investierten Aufwände in eine saubere Architektur im ersten Schritt zahlen sich nun aus.
Eine weitere Skalierung der Anwendung kann durch die Verteilung der einzelnen Services auf unterschiedliche Rechner erreicht werden. Eine Bearbeitung der unterschiedlichen Projekte ist durch eine Vielzahl von Mitarbeitern nun parallel möglich.
Die benötigte Infrastruktur wird umfangreicher und komplexer. Die bestehende Architektur erlaubt es Teile oder auch die gesamte Anwendung in die Cloud, auf Windows Azure, auszulagern. Ein Dienstleister kann den Betrieb der Services übernehmen. Dies ermöglicht dem Anwender eine volle Konzentration auf das Projektgeschäft. Gleichzeitig werden neue Geschäftsmodelle eröffnet. Die Dienste können auch anderen Kunden angeboten werden. Eine Abrechnung wird in Abhängigkeit der tatsächlichen Nutzung ermöglicht.
Trotz der fortlaufend veränderten Anforderungen an die Anwendung konnten wir den im ersten Schritt gewählten Architekturansatz fortführen. Aus den Komponenten können flexible Pakete für einen Einsatz auf einem Einzelarbeitsplatz oder eine Arbeit in Teams unterschiedlicher Größe geschnürt werden. Die zusätzlichen Investitionen in der Anfangsphase und die Betrachtung möglicher zukünftiger Szenarien haben sich gelohnt.
Weitere Informationen
Ansprechpartner