Helfer bei verteilten Anwendungen

Mit Visual Studio 2005 Team System bekommen nicht nur Software-Architekten, Designer und Entwickler mächtige Tools in die Hände, sondern erstmals auch das Betriebspersonal der IT-Abteilungen. All die mitgelieferten Werkzeuge sind der erste Ansatz der sogenannten Dynamic Systems Initiative (DSI), die von Microsoft gestartet wurde. Die grösste Errungenschaft ist die Unterstützung des Testprozesses. Einerseits wurde ein sehr leistungsfähiges Unit-Testing-Framework für Entwicklertests integriert, andererseits stehen aber auch Tools zur Verfügung, mit denen Lasttests für Webanwendungen durchgeführt werden können. Zusätzlich kann Team System über offene Schnittstellen mit Test-Tools von Drittanbietern erweitert werden.
Ein weiterer wichtiger und umfangreicher Bereich, den Team System adressiert, ist das Source-Code-Control-System. Microsoft hat dazu in den letzten Jahren immer Visual Source Safe angeboten, das jedoch nicht für grössere Software Entwicklungsprojekte verwendet werden kann, da einfach die notwendigen Funktionalitäten fehlen. In Team System gibt es ein rundum erneuertes Quellcodeverwaltungssystem, das auch in Teams mit mehr als 100 Personen ohne Probleme eingesetzt werden kann. Zusätzlich zu den bereits erwähnten Ver- Helfer bei verteilten Anwendungen besserungen hat Microsoft in Visual Studio einen Klassendesigner integriert, mit dem in einer UML ähnlichen Notation Klassenbibiotheken designt werden können. Weiter wird standardmässig das Reverse-Engeneering zwischen Code und Modell unterstützt.
Die Herausforderung bei der Architektur und dem Design von verteilten Anwendungen ist, dass sie immer komplexer werden, da die verschiedenen Programmierplattformen immer leistungsfähigere Features anbieten. Mit Hilfe von standardisierten Mechanismen wie XML Webservices wird mit einer Service-orientierten Architektur (SOA) versucht, einen nachrichtenbasierten Austausch zwischen verschiedenen Computerplattformen zu schaffen. Dabei können bei der Architektur solcher Systeme verschiedene Probleme auftreten.
Das Darstellen der Architektur einer verteilten Anwendung für Dokumentationszwecke wird immer komplexer, weil auch die beiliegenden Systeme immer komplexer werden. Zusätzlich sind die verschiedenen Systeme der Unternehmen immer weiter gewachsen und vielleicht noch auf verschiedenen Plattformen implementiert worden. Eine solche Architektur, in einem standardisierten Weg darzustellen, wird auch immer schwerer und zusätzlich ist es meistens auch nicht möglich, dass jeder der Projektmitglieder (Architekten, Entwickler, IT-Betriebsführung) etwas mit der Darstellung anfangen kann. Damit die Dokumentation von verteilten Anwendungen immer aktuell ist, ist eine enge Kommunikation zwischen Architekten, Entwickler und der IT-Betriebsführung notwendig. Doch auch mit dem durchdachtetsten Prozess wird über kurz oder lang die Architekturdokumentation nicht mehr synchron zur aktuellen Implementierung sein.

Meistens werden verteilte Anwendungen entwickelt, ohne dass Architekten oder Entwickler über die Konfi guration der Zielumgebung Bescheid wissen. Weiter kann festgestellt werden, dass die IT-Betriebsführung meistens nicht in den Softwareentwicklungsprozess eingebunden ist. Daraus resultieren Systeme, mit denen es beim ersten Deployment auf das Echtsystem ein böses Erwachen gibt.

Der Application Connection Designer (ACD) (Screen 1) hilft Architekten und Entwickern, die Anwendungen zu defi nieren, aus denen eine verteilte Anwendung besteht. Dabei wird bereits ein Set von vordefi nierten Anwendungen mitgeliefert, wie Webanwendungen, Windows-Forms-Anwendungen, Webservices und Biztalk Services. Zusätzlich wird ein generischer Anwendungsprototyp mitgeliefert, der an benutzerdefi nierte Einstellungen angepasst werden kann. Mit dem ACD können verteilte Anwendungen von Grund auf neu entworfen aber auch aus einer bestehenden Visual Studio 2005 Solution ein Diagramm für den ACD erstellt werden.
Jeder Service, der von einer Anwendung zur Kommunikation angeboten wird, wird als sogenannter Endpunkt im Diagramm dargestellt. Über diese Endpunkte können die Anwendungen miteinander kommunizieren. So lässt sich ein Webservice-Endpunkt konfi gurieren. Dazu können Webservice-Methoden definiert und vorgefertigte WSDL-Dokumente importiert werden. Dadurch kann die komplette Konfiguration eines Webservices durchgeführt werden, ohne dass eine einzige Zeile Code geschrieben werden muss. Mit dem Logical Datacenter Designer (LDD) (Screen 2) können Diagramme erstellt werden, die die logischen Verbindungen zwischen Servern in einer IT-Umgebung beschreiben. Diese Diagramme enthalten sehr wichtige Informationen über die Zielumgebung, die für die Entwickler notwendig sind. Dieser Designer kann von der IT-Betriebsführung verwendet werden, um
die verschiedenen Server entsprechend ihrer Ausstattung und ihres Einsatzszenarios zu konfi gurieren. Zusätzlich lässt sich noch spezifi zieren, welche Kommunikationsprotokolle verwendet werden können und in welchen Richtungen überhaupt miteinander kommuniziert werden darf. Nachdem ein solches Diagramm erstellt wurde, kann es von der IT-Betriebsführung gesperrt werden, damit es von Entwicklern nur mehr für Referenzzwecke verwendet werden kann.
Gleich wie beim ACD bietet der LDD in der Toolbar verschiedene logische Server- Prototypen an, die direkt zum Diagramm hinzugefügt werden können. Server-Prototypen sind Windows Clients, Webserver (IIS), SQL Server und auch generische Server, die an spezielle Bedürfnisse angepasst werden können. Alle Einstellungen, die ein Serverprototyp mit sich bringt, können den eigenen Bedürfnissen angepasst werden. Damit aber auch eine bestehende IT-Infrastruktur sehr schnell mit dem LDD abgebildet werden kann, besteht die Möglichkeit, dass die notwendigen Einstellungen von realen Servern in das Diagramm importiert werden können. Einstellungen die hier vorgenommen werden, können von Entwicklern nicht mehr überschrieben werden. Wird einmal festgelegt, dass bei einem Webserver die integrierte Windows-Sicherheit verwendet wird, muss diese in der Entwicklung entsprechend angewendet werden.
Der System Designer (Screen 3) wird verwendet um Anwendungen zusammenzustellen und zu konfi gurieren, die im ACD defi niert wurden. Eine Systemdefi nition, die mit dem System Designer erstellt wird, kann komplett unabhängig von der mit dem ACD defi nierten Entwicklungskonfi guration festgelegt werden. Wenn es erlaubt ist, können sogar Anwendungseinstellungen vom ACD im System Designer überschrieben werden. Zusätzlich besteht auch die Möglichkeit, dass mehrere Systemdefi nitionen angelegt werden, damit auch unterschiedliche Deployment-Szenarien abgebildet werden können, wie etwa für verschiedene IT-Infrastrukturen und Kunden.
Der Deployment Designer (Screen 4) wird eingesetzt, um eine verteilte Anwendung in einer logischen IT-Infrastruktur zu deployen. Dieser Designer wird typischerweise von Architekten und Entwicklern verwendet, um festzustellen, ob sich die erstellte Anwendung überhaupt entsprechend den Policies in der Zielumgebung deployen lässt. Dabei besteht die Möglichkeit, dass eine Anwendung anhand eines LDD-Diagramms validiert wird. Hier werden auch die Vorteile des SDM-Modells sichbar: Es handelt sich nicht nur um losgelöste Diagramme, die eigenständig eingesetzt werden können, sondern um Diagramme die miteinander zusammenarbeiten. Über die Validierungsmechanismen kann sehr leicht festgestellt werden, ob Kommunikationsrichtlinien eingehalten wurden und ob Anwendungen nur in den vordefi nierten Richtungen miteinander kommunizieren.

Die Konfiguration einer verteilten Anwendung ist ein zeitaufwändiger und komplizierter Prozess, weil sehr viele verschiedene Systeme darin involviert sind. Aktuell gibt es beispielsweise keine Möglichkeit die Sicherheitseinstellungen eines Produktivsystems so darzustellen, damit bereits während des Architektur- und Design-Prozesses darauf Rücksicht genommen werden kann. Die Aufzählung verdeutlicht, dass das Erstellen einer verteilten Anwendung keine leichte Aufgabe ist, wenn es sauber und professionell durchgeführt werden soll. Visual Studio 2005 Team System bietet eine Reihe von Designern an, mit denen eine verteilte Anwendung grafi sch entworfen und auch während des Architektur-, Design- und des Entwicklungs-Prozesses entsprechend den Anforderungen der Produktivumgebung validiert werden kann. Diese Designer verwenden das sogenannte System Defi nition Model (SDM) für die Speicherung der Metadaten. Diese Metadaten beschreiben die Einstellungen der Zielumgebung wie verschiedene Kommunikationsmöglichkeiten zwischen Servern, Abbildung der Netzwerktopologie, aber auch geltende Richtlinien hinsichtlich der Sicherheit.

Die Reihe dieser leistungsfähigen Werkzeuge erleichtern das Design und die Entwicklung von verteilten Anwendungen wesentlich. Zusätzlich bietet jeder dieser Designer offene Schnittstellen an. Die volle Leistungsfähigkeit werden sie jedoch erst dann ausspielen können, wenn auch Fremdsysteme wie J2EE-Applikationsserver und Tomcat-Webserver eingebunden werden können. Denn welche IT-Infrastruktur besteht nur aus Microsoft-Technik? Zu hoffen ist, dass in Zukunft Server- Prototypen zur Verfügung stehen, die die meisten vorhandenen Fremdsysteme abbilden können.