(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Einführung in .NET Framework 3.0

Veröffentlicht: 28. Aug 2006
Von David Chappell

Die Version 3.0 von Microsoft .NET Framework bietet ein diversifiziertes Paket verschiedener Technologien an, von denen jede auf eine andere Problemstellung der Anwendungsentwicklung abgestimmt ist.

Auf dieser Seite

Beschreibung von .NET Framework 3.0 Beschreibung von .NET Framework 3.0
Anwenden von .NET Framework 3.0: ein Szenario Anwenden von .NET Framework 3.0: ein Szenario
Erläuterungen zu .NET Framework 3.0: die Technologien Erläuterungen zu .NET Framework 3.0: die Technologien
Verwenden von .NET Framework 3.0: Verteilungsoptionen  Verwenden von .NET Framework 3.0: Verteilungsoptionen
Schlussbemerkung Schlussbemerkung
Weiterführende Literatur Weiterführende Literatur
Der Autor Der Autor

Beschreibung von .NET Framework 3.0

Das Ziel bei der Anwendungsentwicklung ist immer das gleiche: die bestmögliche Software mit möglichst geringem Zeitaufwand zu erstellen. Die Anforderungen steigen jedoch laufend, da die Plattformen, die Entwickler verwenden, ständig besser werden. In Windows wurde beispielsweise die ursprüngliche Win32-Schnittstelle vom sehr viel funktionaleren .NET Framework absorbiert. Sowohl die Version 1.0 von Framework, die 2002 freigegeben wurde, als auch die Version 2.0 aus dem Jahr 2005 bieten eine deutlich bessere und produktivere Umgebung für Entwickler von Windows-Software.

.NET Framework 3.0 (ehemals unter der Bezeichnung WinFX bekannt) ist die nächste Stufe in dieser Entwicklung. Anwendungen, die basierend auf dieser neuen Framework-Version entwickelt werden, können mit Visual Studio 2005 erstellt werden, weshalb die meisten Windows-Entwickler sich gleich damit vertraut fühlen. .NET Framework 3.0 stellt jedoch auch eine Weiterentwicklung dar, die auf der Version 2.0 von Framework aufbaut und ihr Funktionsangebot erweitert. Die Freigabe der .NET Framework-Version 3.0 ist für Ende 2006 geplant und wird für Windows Vista, Windows Server 2003 und Windows XP zur Verfügung stehen.

Dieser Artikel bietet einen allgemeinen Einblick in .NET Framework 3.0 und seine Komponenten. Ziel ist es, die neue Version vorzustellen, die einzelnen Technologien kurz zu beschreiben und ihre Verwendung zu erläutern.

Entwickeln moderner Anwendungen: Die Herausforderungen

Die Entwicklung einer typischen Anwendung ist heute keine einfache Aufgabe, da sie hohen Anforderungen genügen muss. Die traditionellen Schwerpunkte wie die Arbeit mit gespeicherten Daten und die Ermöglichung des Zugriffs über einen Webbrowser sind weiter von Bedeutung, reichen aber nicht mehr aus. Moderne Anwendungen müssen einer Reihe neuer Anforderungen gerecht werden, zu denen Folgende zählen:

  • Unternehmen verwenden mehr und mehr prozessorientierte Ansätze für ihre betrieblichen Abläufe. Da die meisten Anwendungen Teile des Geschäftsprozesses automatisieren, kann es hilfreich sein, die Schritte dieses Prozesses explizit in den Code zu schreiben. Ein wirksames Verfahren, dies zu erreichen, ist die Verwendung von Workflow-Technologie; hierzu müssen workflowbasierte Anwendungen unterstützt werden.

  • Anwendungen kommunizieren gewöhnlich mit anderen Anwendungen innerhalb und außerhalb des Unternehmens. Moderne Anwendungen müssen sich zudem in eine serviceorientierte Architektur (SOA) einfügen und dazu einen Teil der eigenen Funktionen als interoperable Dienste anderen Softwareanwendungen zugänglich machen. Zur Erreichung dieser Ziele müssen serviceorientierte Anwendungen unterstützt werden.

  • Die Benutzer einer Anwendung müssen in der Regel Informationen über ihre Identität weitergeben. Es sind viele verschiedene Technologien für die Definition und Verwendung digitaler Identitäten erhältlich, und Probleme wie Phishing sind keine Seltenheit. Aus diesem Grund müssen moderne Anwendungen und ihre Benutzer eine konsistente Benutzerkontrolle digitaler Identitäten nutzen können.

  • Die Anforderungen an eine moderne Benutzeroberfläche sind stark gestiegen. Eine Benutzeroberfläche, die den Bedürfnissen der heutigen Geschäftswelt gerecht werden will, muss es ermöglichen, mit verschiedenen Arten von Dokumenten zu arbeiten, zwei- und dreidimensionale Grafiken zu verwenden, Videos anzuzeigen usw. All dies muss sowohl in systemeigenen Windows-Clients als auch in Webbrowsern möglich sein. Damit diese Anforderungen erfüllt werden, ist ein einheitliches Verfahren für verschiedene Benutzeroberflächen erforderlich.

Angesichts der Tatsache, dass die heutigen Anwendungen gewöhnlich mehreren dieser Anforderungsprofile oder gar allen gerecht werden müssen, sollte auch die Plattform, auf der diese Anwendungen erstellt werden, diese Problemstellungen auf kohärente und praxisorientierte Weise meistern. Ziel von .NET Framework 3.0 ist es daher, genau das für Windows-Anwendungen zu leisten.

Lösungen für Problemstellungen: Was .NET Framework 3.0 leistet

Wie aus Abbildung 1 hervorgeht, baut die Version 3.0 von .NET Framework auf der Vorgängerversion auf. Tatsächlich hat sich in der Version 2.0 von .NET Framework nichts geändert, weshalb bestehende Anwendungen, die für diese Grundlage erstellt wurden, weiter wie gewohnt funktionieren. .NET Framework 3.0 umfasst jedoch vier neue Komponenten: Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace und Windows Presentation Foundation. ln diesem Abschnitt werden die Funktionen von .NET Framework 2.0 und der neuen Komponenten kurz beschrieben.

Abbildung 1
Abbildung 1

.NET Framework 2.0: Eine allgemeine Grundlage für Windows-Anwendungen

Wenngleich es weiter möglich ist, Programme zu schreiben, die die Win32-Schnittstelle direkt verwenden, etabliert sich .NET Framework immer mehr als dominierende Umgebung für neue Windows-Anwendungen. Die wichtigsten Komponenten sind:

  • ASP.NET unterstützt die Erstellung webfähiger Anwendungen.

  • ADO.NET ermöglicht es Anwendungen, auf relationale oder andere Daten zuzugreifen.

  • Windows Forms unterstützt die Erstellung grafischer Benutzeroberflächen (GUIs) für Windows-Anwendungen.

  • System.XML ermöglicht es, dass Anwendungen mit XML-definierten Daten arbeiten können, einschließlich der Verwendung von XSLT und XPath.

Die Version 2.0 von Framework erweiterte die Vorgängerversion um mehrere hilfreiche Funktionen, unter anderem eine deutlich verbesserte Technologie für die Erstellung von ASP.NET-Webanwendungen, Unterstützung für 64-Bit-Anwendungen, die unter 64-Bit-Versionen von Windows ausgeführt werden, sowie eine neue Methode für die Verwaltung von Transaktionen. Während Teile von .NET Framework 2.0 durch die neuen Komponenten der Version 3.0 ersetzt werden (die Erläuterung folgt weiter unten), bleiben die Technologien von Version 2.0 ein grundlegender Baustein der neuen Version.

Windows Workflow Foundation: Unterstützung workflowbasierter Anwendungen

Der Workflow ist ein einfaches Konzept: Er ist nichts anderes als eine Abfolge von Schritten, die in einer bestimmten Reihenfolge ausgeführt werden. Man könnte sogar sagen, dass jede Anwendung einen Workflow implementiert, da jede Anwendung Prozesse ausführt. Der traditionelle Ansatz bei der Erstellung einer Anwendung mit C#, Visual Basic oder einer anderen Programmiersprache besteht jedoch darin, die Schritte in diesem Prozess durch den Code zu implizieren. Das ist natürlich möglich, jedoch wird der Prozess selbst dadurch auch tief in die Logik eines Programms eingebettet, weshalb der Prozess schwieriger zu implementieren und zu ändern ist.

Die Verwendung von Workflow-Technologie zur Implementierung von Prozesslogik kann ein wirksames Verfahren zur Lösung dieses Problems sein. Anstatt die Logik in normalen Code einzuflechten, wird jeder Schritt des Prozesses explizit definiert und dann mit einem Workflow-Modul ausgeführt. Das Ergebnis ist eine saubere Implementierung des Prozesses selbst.

Workflow-Module sind keine neue Idee, es sind bereits mehrere für Windows und andere Systeme verfügbar. Microsoft hat Workflow-Module sogar in einige seiner Produkte eingebettet. Da sich die Verwendung von Workflows jedoch immer stärker und auf breiter Ebene durchsetzt, ist es sinnvoll, eine einzige Workflow-Technologie für Windows bereitzustellen. Und so ist Windows Workflow Foundation entstanden (das offizielle Akronym dafür lautet WF). WF bietet eine Windows-übergreifende Workflow-Technologie, damit alle workflowbasierten Anwendungen auf derselben Grundlage erstellt werden können. Software von Microsoft wird in Zukunft WF verwenden, einschließlich des Systems Microsoft Office 2007 und Windows SharePoint Services, und die Anwendungen anderer Anbieter werden dies ebenfalls tun.

Die Bereitstellung einer gemeinsamen Workflow-Technologie stellt jedoch auch eine Herausforderung dar. Wie kann beispielsweise ein einziges Verfahren den verschiedenen Anforderungen unterschiedlicher Workflow-Anwendungen gerecht werden? WF löst dieses Problem, indem es den Workflow sehr allgemein definiert. Abbildung 2 zeigt, dass ein WF-Workflow nichts anderes als eine Gruppe von Aktivitäten ist, die vom WF-Modul ausgeführt werden. Jede Aktivität stellt eine Klasse dar, die jede Art von Aufgabe enthalten kann, die der Workflow-Ersteller für nötig erachtet. Die Aktivitäten können in anderen Workflows wiederverwendet werden, wodurch die Erstellung automatisierter Lösungen für neue Probleme erleichtert wird.

Abbildung 2
Abbildung 2

Eine andere Herausforderung bei der Entwicklung einer gemeinsamen Workflow-Technologie stellt sich aufgrund der traditionellen Trennung zwischen personenorientierten und systemorientierten Workflows. Workflow-Anwendungen, die überwiegend von Menschen verwendet werden, müssen flexibel sein und situationsbedingte dynamische Prozessänderungen zulassen. Solche, die überwiegend von Systemen, d. h. von Programmen verwendet werden, sind in der Regel statischer, müssen dabei aber so effizient wie möglich sein. WF ist für beide Anwendungsvarianten konzipiert und umfasst daher personenorientierte Funktionen, wie z. B. die Möglichkeit der Änderung eines laufenden Workflows, und unterstützt gleichzeitig eher systemorientierte Funktionsweisen.

Durch das Bereitstellen einer gemeinsamen Workflow-Technologie für Windows macht .NET Framework 3.0 dieses nützliche Paradigma für die Softwareerstellung allen Entwicklern verfügbar. Mit zunehmender Popularität des prozessorientierten Ansatzes bei der Softwareentwicklung wird wahrscheinlich auch die Verwendung von Workflows weiter steigen.

Windows Communication Foundation: Unterstützung serviceorientierter Anwendungen

Ganz gleich, ob sie mit einem Workflow oder einem anderen Ansatz erstellt wurden, die meisten Anwendungen müssen mit anderen Anwendungen kommunizieren. Die Abwicklung dieser Kommunikation hat sich in den letzten Jahren deutlich verbessert. Nach Jahrzehnten der Uneinigkeit haben inzwischen alle wichtigen Anbieter zugestimmt, dieselben Protokolle für die Anwendungskommunikation zu unterstützen. Dieses globale, auf SOAP basierende Abkommen über Webdienste macht die Interoperabilität zwischen Anwendungen, die auf unterschiedlichen Technologieplattformen wie z. B. J2EE oder .NET Framework erstellt wurden, sehr viel einfacher, als dies in der Vergangenheit der Fall war. Zudem wird das Konzept der serviceorientierten Architektur dadurch für die meisten Unternehmen viel überzeugender.

Es existiert natürlich bereits eine Vielzahl von Kommunikationskonzepten. In .NET Framework 2.0 stehen beispielsweise die folgenden Optionen zur Verfügung:

  • ASP.NET Web Services bietet interoperable SOAP-basierte Kommunikation.

  • .NET Remoting dient vorwiegend der Kommunikation zwischen .NET-Anwendungen.

  • Enterprise Services bietet Unterstützung für skalierbare, transaktionsorientierte Anwendungen.

  • System.Messaging unterstützt Message Queuing mithilfe von Microsoft Message Queuing (MSMQ).

  • Web Services Enhancements (WSE), eine Erweiterung von ASP.NET Web Services, unterstützt neuere Spezifikationen wie beispielsweise WS-Security.

Alle diese Technologien sind wertvoll und haben ein wichtige Rolle gespielt. Aber wieso gibt es mehrere verschiedene Lösungen, die sich im Grunde genommen demselben Problem widmen? Wäre es nicht besser, eine einzige Grundlage für die Anwendungskommunikation basierend auf interoperablen Diensten zu entwickeln?

Genau das leistet Windows Communication Foundation (WCF). Entwickler brauchen nicht für jede Art der Kommunikation eine andere Technologie mit einer anderen API (Application Programming Interface) zu verwenden, da WCF (vorheriger Codename "Indigo") eine gemeinsame Methode mit einer gemeinsamen API bietet. In der .NET Framework 3.0-Umgebung werden die meisten Anwendungen, die sonst eine der aufgeführten Technologien verwendet haben, stattdessen WCF für die Kommunikation verwenden.

WCF bietet verlässliche Unterstützung für interoperable Kommunikation über SOAP, einen unabdinglichen Bestandteil moderner Computertechnik. Das beinhaltet die Unterstützung mehrerer der WS-*-Spezifikationen, darunter WS-Security, WS-ReliableMessaging und WS-AtomicTransaction. WCF erfordert jedoch nicht zwingend das Protokoll SOAP, weshalb auch andere Methoden verwendet werden können, einschließlich eines optimierten Binärprotokolls, Message Queuing mit MSMQ und einfache REST-basierte Kommunikation. WCF ist darüber hinaus ein explizit serviceorientiertes Kommunikationsverfahren. Anstatt für eine transparente Kommunikation zwischen Objekten zu sorgen, fügt WCF einen leicht abstrahierten Dienst zwischen die Kommunikationsparteien ein. Das führt unter anderem dazu, dass einige der engen Verknüpfungen, die in verteilten Objektsystemen vorkommen können, gelockert werden. Dadurch wird die Interaktion weniger fehleranfällig und lässt sich einfacher ändern.

Die Kommunikation zwischen Anwendungen, sei es innerhalb eines Unternehmens oder zwischen Unternehmen, ist ein grundlegender Bestandteil moderner Software. .NET Framework 3.0 stellt sich dieser Herausforderung, indem es den serviceorientierten Ansatz von WCF verwendet.

Windows CardSpace: konsistente Benutzerkontrolle digitaler Identitäten

Denken Sie einmal daran, wie Menschen heute ihre Identität im Internet angeben. In der Mehrzahl der Fälle wird die digitale Identität einer Person als einfacher Benutzername wiedergegeben. In Verbindung mit einem Kennwort dient diese Identität dem Zugriff auf E-Mail-Konten, Online-Verkaufsseiten und sogar Online-Banken und andere Finanzinstitute. Trotz ihrer Einfachheit (und weit verbreiteten Verwendung) sind mit Benutzernamen und Kennwörtern verschiedene Nachteile verbunden. Das sind die beiden wichtigsten:

  • Viele Menschen haben Schwierigkeiten, sich an alle Benutzernamen und Kennwörter zu erinnern, die sie für die verschiedenen Sites gewählt haben. Viele verwenden dieselben Benutzernamen und Kennwörter für unterschiedliche Sites. Die Benutzer können sich so die Daten zwar besser merken, aber das Sicherheitsrisiko steigt durch diese Vorgehensweise.

  • Benutzernamen, Kennwörter und andere persönlichen Daten können von Phishern gestohlen werden. Durch das Versenden von Täuschungs-E-Mails versuchen Phisher ihre Opfer dazu zu bewegen, sich auf einer Website anzumelden, die beispielsweise der Website ihrer Bank zum Verwechseln ähnlich sieht. Die Website wird jedoch vom Phisher kontrolliert, und sobald das Opfer seinen Benutzernamen und sein Kennwort eingegeben hat, kann der Phisher diese Informationen dazu verwenden, sich auf der echten Website anzumelden.

Um diesen Problemen zu begegnen, ist ein neues Verfahren zur Verwaltung digitaler Identitäten erforderlich. Windows CardSpace, ursprünglicher Codename "InfoCard," ist in diesem Zusammenhang ein wichtiges Tool. Um Personen bei der Verwaltung ihrer digitalen Identitäten zu helfen, stellt CardSpace jede Identität als gesonderte Informationskarte dar. Akzeptiert eine Website CardSpace-Anmeldungen, wird Benutzern bei der Anmeldung ein Bildschirm mit einer CardSpace-Auswahl wie der in Abbildung 3 dargestellten angezeigt. Durch die Auswahl einer Karte wählen Benutzer eine digitale Identität, die für den Zugriff auf die Website verwendet wird. Anstatt sich eine Unmenge von Benutzernamen und Kennwörtern merken zu müssen, brauchen die Benutzer lediglich die Karte wiederzuerkennen, die sie verwenden möchten. Verschiedene Karten können zudem unterschiedliche Informationen enthalten, so dass Benutzer genau steuern können, welche ihrer persönlichen Daten an die jeweilige Website weitergeleitet werden.

Abbildung 3
Abbildung  3

Die durch diese Karten repräsentierten Identitäten werden durch einen oder mehrere Identitätsprovider erstellt. Jedes Unternehmen kann einen Identitätsprovider stellen, und anstatt nur mit einfachen Benutzernamen und Kennwörtern zu arbeiten, werden in der Regel für diese Identitäten wirksamere Verschlüsselungsmechanismen verwendet, um den Benutzern die Möglichkeit zu geben, ihre Identität nachzuweisen. CardSpace selbst umfasst ebenfalls einen Provider für selbst ausgestellte Identitäten, der auf Clientcomputern ausgeführt wird. Mit diesem Provider können Benutzer ihre eigenen Identitäten erstellen, die ohne Kennwörter für die Authentifizierung auskommen. Websites können diese selbst erstellten CardSpace-Identitäten anstatt herkömmlicher Kennwortverfahren verwenden und so Probleme im Zusammenhang mit Kennwörtern vermeiden.

Werden keine Kennwörter zur Anmeldung auf einer Website verwendet, können Phisher diese auch nicht stehlen. Wenn Phisher einen Benutzer dazu bringen können, sich auf einer gefälschten Website anzumelden, könnte es ihnen auch gelingen, Benutzern andere Informationen zu entlocken, beispielsweise vertrauliche Patientendaten. Um das zu verhindern, müssen Benutzer in der Lage sein, echte Seiten von gefälschten Nachahmungen der Phisher zu unterscheiden. Hierzu kann sich ein Unternehmen, das eine Website besitzt, ein Hochsicherheitszertifikat ausstellen lassen. Im Gegensatz zu den einfachen SSL-Zertifikaten, die heute verwendet werden, muss zur Beantragung dieser neuen Art von Zertifikat ein strenger Prozess durchlaufen werden, bei dem noch sorgfältiger geprüft wird, ob der Antragsteller tatsächlich der ist, für den er sich ausgibt. Ein Hochsicherheitszertifikat kann auch das Logo eines Unternehmens sowie andere Informationen beinhalten, die es dem Benutzer ermöglichen, die Rechtmäßigkeit der Website, die das Zertifikat verwendet, zu überprüfen. Wenn ein Benutzer auf eine neue Website zugreift, zeigt CardSpace die Zertifikatsinformationen der Website immer auf einem Standardbildschirm an. Je nach der Strenge des ausgestellten Zertifikats gibt dieser Bildschirm unterschiedliche Sicherheitsstufen der Website-Identität an. Das Ziel ist es, eine ausdrückliche Entscheidung seitens der Benutzer über die Vertrauenswürdigkeit einer Website abzufordern und ihnen dabei zu helfen, die vertrauenswürdigen Websites zweifelsfrei zu ermitteln.

Windows CardSpace ist Teil eines größeren Identitätsmetasystems. Dieses ganz und gar auf offenen, öffentlichen Protokollen basierende Metasystem definiert ein Verfahren zur übereinstimmenden, plattform- und anwendungsübergreifenden Nutzung (einschließlich anderer Betriebssysteme als Windows und anderer Webbrowser als Internet Explorer) verschiedener digitaler Identitätstechnologien. Durch das Bereitstellen eines einheitlichen Verfahrens zur Auswahl von Identitäten und anderem für Windows nimmt CardSpace eine Schlüsselposition im Metasystem ein. Indem CardSpace Lösungen für das grundlegende Problem der Identitäten bietet, spielt es auch für .NET Framework 3.0 eine entscheidende Rolle.

Windows Presentation Foundation: einheitlicher Ansatz für verschiedene Benutzeroberflächen

Die Benutzeroberfläche ist ein wichtiger Bestandteil nahezu jeder Anwendung. Die Ansprüche, die Benutzer an Benutzeroberflächen stellen, sind jedoch erheblich gestiegen. Herkömmliche menügesteuerte GUIs werden natürlich weiterhin benötigt, aber Anwendungen müssen häufig auch in der Lage sein, Videos anzuzeigen, Animationen auszuführen, zwei- und dreidimensionale Grafiken darzustellen und mit verschiedenen Arten von Dokumenten zu arbeiten. Und all das muss unabhängig davon möglich sein, ob über einen installierten Desktopclient oder einen Webbrowser auf die Anwendung zugegriffen wird.

Allen diesen Aspekten der Benutzeroberfläche wurde von Windows auf unterschiedliche Weise Rechnung getragen. Beispielsweise kann ein Entwickler Windows Forms, einen Bestandteil von .NET Framework, verwenden, um eine Windows-GUI zu erstellen. Die Erstellung einer Webbrowser-GUI erfordert die Verwendung von HTML und möglicherweise Java-Applets oder JavaScript-Code. Die Anzeige von Videos kann beispielsweise mit Windows Media Player oder Programmen wie Flash Player von Adobe erfolgen, während Dokumentenformate durch Microsoft Word oder PDF von Adobe o. Ä. definiert werden kann. Die Problemstellung für die Entwickler ist klar: Das Erstellen einer einheitlichen Benutzeroberfläche für unterschiedliche Arten von Clients, die unterschiedliche Technologien verwenden, ist nicht einfach.

Vorrangiges Ziel von Windows Presentation Foundation (WPF), ursprünglicher Codename "Avalon", ist die Lösung dieses Problems. Indem WPF eine solide technische Grundlage für alle diese Aspekte der Benutzeroberfläche bietet, erleichtert es Entwicklern ihre Arbeit. Dank seines innovativen Ansatzes, der Videos, Animationen, zwei- und dreidimensionale Grafiken und verschiedene Arten von Dokumenten unterstützt, ermöglicht WPF den Benutzern, Informationen auf neue Weise zu verwenden. Indem WPF eine gemeinsame Grundlage für Desktopclients und Browserclients bereitstellt, erleichtert es zudem die Entwicklung von Anwendungen, auf die von beiden aus zugegriffen werden kann.

Die Beispiel-Benutzeroberfläche in Abbildung 4 enthält Bilder, Echtzeitgrafiken, dreidimensionale Ansichten und mehr und zeigt damit nur einige der Möglichkeiten auf, die WPF bietet. Benutzeroberflächen wie diese können jetzt in einem einheitlichen Verfahren erstellt werden und fordern den Entwicklern daher keine Kenntnisse verschiedener Technologien ab.

Abbildung 4
Abbildung  4

Ein Problempunkt bei der Erstellung effektiver Benutzeroberflächen ist seit jeher durch die verschiedenen Fachkräfte bedingt, die dazu nötig sind. Für das Erstellen der Logik, die hinter der GUI steht, werden Softwareentwickler benötigt, die jedoch kaum die am besten geeigneten Spezialisten für die grafische Gestaltung der GUI sind. Softwaredesigner, die auf die Interaktion zwischen Mensch und Maschine spezialisiert sind, eignen sich für diese Aufgabe in der Regel viel besser. Ältere Technologien wie Windows Forms sind jedoch ausschließlich für Entwickler konzipiert. Es gibt keine effektive Möglichkeit der Zusammenarbeit für Entwickler und Designer. Zur Lösung dieses Problems stützt sich WPF auf die eXtensible Application Markup Language (XAML). XAML ist eine XML-basierte Sprache und gestattet die Spezifikation einer Benutzeroberfläche durch Deklarationen anstatt mit Code. Dadurch wird es Tools erleichtert, eine Schnittstellenspezifikation auf der Basis der visuellen Darstellung, die von einem Designer entworfen wurde, zu generieren und damit zu arbeiten. Microsoft bietet ein neues Produkt an – Expression Interactive Designer –, das genau zu diesem Zweck entwickelt wurde. Designer werden dieses Tool (und andere Tools von Drittanbietern) dazu verwenden können, um eine Benutzeroberfläche zu gestalten und anschließend eine XAML-Definition dieser Benutzeroberfläche zu generieren. Der Entwickler kann diese Definition dann in Visual Studio importieren, um die Logik für die Schnittstelle zu erstellen.

Wenn Entwickler eine installierte WPF-Anwendung erstellen, die direkt unter Windows ausgeführt wird, können sie auf alles zugreifen, was WPF bietet. Um hingegen einen Client zu erstellen, der in einem Webbrowser ausgeführt wird, können Entwickler eine XAML-Browseranwendung erstellen, die gemeinhin als XBAP bezeichnet wird. Da die XBAP auf derselben Grundlage wie die installierte WPF-Anwendung erstellt wird, ermöglicht sie die Darstellung desselben GUI-Stils in einer herunterladbaren Browseranwendung. Möglicherweise kann derselbe Code für beide Arten von Anwendungen verwendet werden, was bedeuten würde, dass Entwickler nicht länger über Fähigkeiten sowohl auf dem Gebiet der Desktopclients als auch der Browserclients verfügen müssen. Für diese Art der umfassenden Internetanwendung ist es typisch, dass eine aus dem Internet heruntergeladene XBAP in einer sicheren, begrenzten Umgebung (Sandbox) ausgeführt wird, wodurch die Funktionsweise der Anwendung eingeschränkt wird. Dennoch kann ein großer Teil der GUI-Funktionalität einer installierten WPF-Anwendung auch in einer XBAP verwendet werden.

Sowohl WPF-installierte Anwendungen als auch XBAPs können die Unterstützung moderner Grafikfunktionen durch WPF nutzen, beispielsweise die Fähigkeit, Hardwarebeschleunigung zu verwenden, die Unterstützung von Vektorgrafiken usw. Indem WPF anspruchsvollere Grafikfunktionen unterstützt, ermöglicht es eine Reihe von Datenanzeigeoptionen, die mit Windows Forms oder anderen älteren Technologien nicht möglich sind. WPF bietet zudem die Grundlage für die XML Paper Specification (XPS), die ein Standardformat für die Anzeige, Verteilung und den Druck von Dokumenten mit festgelegtem Format definiert.

Benutzeroberflächen sind ein komplexer und wichtiger Bestandteil moderner Anwendungen. Mit WPF bietet .NET Framework 3.0 eine umfassendere und einheitlichere Lösung für Problematiken im Zusammenhang mit diesen Schnittstellen an. Ziel ist es, den Personen, die mit der Erstellung von Benutzeroberflächen befasst sind – sowohl Entwicklern als auch Designern –, ein effizienteres Arbeiten zu ermöglichen.

Anwenden von .NET Framework 3.0: ein Szenario

Das folgende Verwendungsbeispiel soll das Zusammenwirken der Gruppe von Technologien veranschaulichen. Für das Beispiel wollen wir von einer Anwendung ausgehen, die es Kunden und Versicherungsvertretern ermöglicht, Versicherungsanträge zu übermitteln. Wenn man zur Implementierung der Anwendung .NET Framework 3.0 verwenden würde, könnte das Ergebnis wie das in Abbildung 5 dargestellte aussehen.

Abbildung 5
Abbildung  5

Die Geschäftslogik der Anwendung, die oben links im Schaubild dargestellt ist, wird mit einem WF-Workflow implementiert. Die Bearbeitung eines Versicherungsantrags ist ein mehrstufiger Prozess. Der Antrag muss im Hinblick auf die Risikoübernahmeregeln des Unternehmens und eventuell die Kreditwürdigkeit des Antragstellers geprüft werden, und möglicherweise ist die Genehmigung eines Vorgesetzten einzuholen. Der Workflow implementiert jeden dieser Schritte als Aktivität und bezieht bei Bedarf andere Programme in den Vorgang mit ein. Um auf gespeicherte Daten zuzugreifen, verwenden die Aktivitäten dieses Workflows beispielsweise ADO.NET.

Die Versicherungsgesellschaft unterhält ein Call Center, damit Kunden telefonisch Versicherungen beantragen können. Die von den Mitarbeitern des Call Centers (oben rechts im Schaubild) verwendete Clientsoftware wird als installierte WPF-Anwendung implementiert. Dieser Client kommuniziert über WCF mit der Geschäftslogik der Anwendung und verwendet dazu ein für die WCF-WCF-Kommunikation optimiertes Binärprotokoll. Wie aus der Abbildung hervorgeht, nutzen die Call-Center-Mitarbeiter Windows CardSpace, um die Identität für die Anmeldung in der Anwendung auszuwählen.

Kunden können ebenfalls über das Internet Versicherungen beantragen, und Versicherungsvertreter können Anträge übermitteln. Die Anwendung verwendet zu diesem Zweck ASP.NET, um mit Webbrowsern zu kommunizieren. Wie in der unteren linken Ecke des Schaubildes dargestellt ist, können Kunden, die Internet Explorer verwenden, um über eine normale HTML-Schnittstelle auf diese Anwendung zuzugreifen, trotzdem CardSpace verwenden, um die gewünschte Identität auszuwählen. Drittanbieter können ebenfalls einen Identitätsauswahlmechanismus für andere Client-Betriebssysteme und Browser implementieren und das Identitätsmetasystem so auf Windows-fremde Clients und Webbrowser ausdehnen.

Versicherungsvertreter, die über das Internet auf diese Anwendung zugreifen, benötigen wahrscheinlich eine funktionalere Schnittstelle. Sie können sich einer XBAP anstatt einer einfachen HTML-Schnittstelle bedienen. Wie unten in der Mitte des Schaubilds zu sehen ist, können diese Anwender auf diese Weise einen Großteil der GUI-Funktionen nutzen, die von der im Call Center verwendeten WPF-Desktopanwendung bereitgestellt werden. Beide sind auf derselben Grundlage erstellt worden, weshalb die Entwickler der Anwendung denselben Code für beide Arten von Clients verwenden können. Wie bei den anderen Arten von Clients können die Versicherungsvertreter auch hier CardSpace zur Auswahl der Identität verwenden, mit der sie sich bei der Anwendung anmelden wollen.

Schließlich ist es sicher noch erforderlich, dass die Anwendung auf andere Anwendungen zugreifen kann und dass die anderen Anwendungen auf sie zugreifen können. Wenn die Genehmigung eines Kundenantrags beispielsweise eine Kreditauskunft erfordert, ist dazu höchstwahrscheinlich die Inanspruchnahme eines externen Dienstes notwendig. Die Anwendung könnte aber auch Anforderungen direkt von anderen Programmen übernehmen und Dienste verfügbar machen, die diese externen Anwendungen aufrufen. In diesen Fällen (unten rechts in der Abbildung dargestellt) nutzt die Anwendung WCF, um anhand von Standard-Webdiensten zu kommunizieren. Ganz gleich, welche Technologien diesen Anwendungen zugrunde liegen, durch die Unterstützung von SOAP kann WCF problemlos mit ihnen interagieren.

Dieses Szenario zeigt, wie einige der wichtigsten Komponenten von .NET Framework 3.0 in einer typischen Anwendung genutzt werden. Viele Optionen wurden hier jedoch nicht berücksichtigt, betrachten Sie dieses einfache Beispiel also nicht als vollständige Beschreibung der Funktionen dieser Technologiefamilie. Ziel war es vielmehr, deutlich zu machen, wie die verschiedenen Komponenten von .NET Framework 3.0 zusammenwirken und zur Lösung realer Geschäftsprobleme herangezogen werden können.

Erläuterungen zu .NET Framework 3.0: die Technologien

Damit Sie sich eine genauere Vorstellung davon machen können, was .NET Framework 3.0 leistet, werde ich im Folgenden näher auf die einzelnen Technologien eingehen, aus denen es sich zusammensetzt. Dieser Abschnitt liefert eine kurze Einführung in jede der fünf Komponenten von .NET Framework 3.0. Nähere Einzelheiten zu den Komponenten finden Sie in den Beiträgen, die im Abschnitt "Weiterführende Literatur" am Ende dieses Artikels aufgeführt sind.

.NET Framework 2.0

Abbildung 6
Abbildung  6

.NET Framework 2.0 ist heute ein grundlegender Bestandteil der Windows-Entwicklung und darüber hinaus die Basis von .NET Framework 3.0. Abbildung 6 stellt die beiden Teile von Framework dar: die Common Language Runtime (CLR) und die .NET Framework-Klassenbibliothek. Einige Komponenten von .NET Framework 3.0, darunter WF, WCF und WPF, sind weitgehend als Erweiterungen der .NET Framework-Klassenbibliothek implementiert worden. Wie bereits zuvor beschrieben, sind viele Teile der Klassenbibliothek weiterhin wichtiger Bestandteil der Arbeit eines Entwicklers, während andere von den neuen Technologien in .NET Framework 3.0 absorbiert wurden. ASP.NET stellt beispielsweise noch immer die Grundlage für die Erstellung von Anwendungen dar, auf die Browser zugreifen können, und ADO.NET wird weiter dazu verwendet, mit gespeicherten Daten zu arbeiten. Entwickler, die mit .NET Framework 3.0 arbeiten, verwenden vielleicht aber eher WPF als Windows Forms, um eine systemeigene Windows-GUI zu erstellen. Zudem werden sie in der Regel WCF gegenüber ASP.NET Web Services, .NET Remoting oder Enterprise Services den Vorzug geben. Trotz dieser Änderungen sollten Sie sich bewusst sein, dass die Vorgängerversion von Framework auch nach Einführung von .NET Framework 3.0 ein wichtiger Bestandteil der Arbeit von Entwicklern bleibt.

Windows Workflow Foundation

Bei einem Großteil von Windows-Programmen bildet ein prozessorientiertes und von einem Workflow gesteuertes Design den am besten geeigneten Ansatz. Zweck von WF ist es, Entwicklern die Erstellung und Ausführung dieser workflowbasierten Anwendungen zu ermöglichen. Abbildung 7 zeigt die Komponenten, die WF hierzu bereitstellt.

Abbildung 7
Abbildung  7

Wie schon gesagt, besteht jeder Workflow aus einer bestimmten Anzahl von Aktivitäten. Sowohl die Workflows als auch die Aktivitäten sind einfach Klassen, weshalb sie beide direkt als Code erstellt werden können. WF beinhaltet zudem den Workflow Designer, ein in Visual Studio eingebundenes Grafiktool zum Erstellen von Workflows. Ganz gleich, wie ein Workflow erstellt wird, seine Aktivitäten können aus der Base Activity Library (BAL) von WF oder einer beliebigen anderen Quelle abgerufen werden.

Nachdem ein Workflow definiert wurde, wird er schließlich vom WF-Laufzeitmodul ausgeführt. Dieses Modul nutzt eine Reihe von Laufzeitdiensten, um den Workflow-Status festzuhalten, die Ausführung des Workflows zu verfolgen usw. Alle diese Bestandteile – die Laufzeitdienste, das Laufzeitmodul und der Workflow selbst – sind in einem Hostprozess zusammengefasst. Bei diesem Prozess kann es sich um einen beliebigen Windows-Prozess handeln, von einer einfachen Konsole oder einer auf einem Desktop ausgeführten WPF-Anwendung bis zu einem skalierbaren Serverprozess.

Um WF besser verstehen zu können, sind einige grundlegende Kenntnisse seiner Komponenten erforderlich. In den folgenden Abschnitten werden sie jeweils kurz beschrieben.

Workflows

Grundsätzlich handelt es sich bei einem Workflow um nichts anderes als eine Gruppe von Aktivitäten. WF bietet integrierte Unterstützung für zwei Workflow-Stile:

  • Sequenzielle Workflows: Sie führen Aktivitäten in einer definierten Reihenfolge aus. Wie ein traditionelles Ablaufdiagramm kann auch ein sequenzieller Workflow Verzweigungen, Schleifen oder andere Steuerungsstrukturen aufweisen. Standardmäßig werden die Aktivitäten jedoch eine nach der anderen ausgeführt.

  • Statusmechanismus-Workflows: Sie implementieren einen traditionellen finiten Statusmechanismus. Welche Aktivität zu welchem Zeitpunkt ausgeführt wird, hängt wie bei jedem Statusmechanismus von der Kombination aus aktuellem Status und empfangenem Ereignis ab.

Die sequenzielle Option ist für gut definierte Workflows geeignet, wie sie in rein softwarebasierten Prozessen verwendet werden. Sie sind einfach zu erstellen und leicht verständlich und erscheinen den meisten Entwicklern anfangs einleuchtender. Statusmechanismus-Workflows eignen sich besser, wenn der Ausführungspfad nicht gut vorhersehbar ist. Ein gutes Beispiel dafür ist ein Workflow, der die Interaktion mit Personen beinhaltet, von denen jede den Workflow jederzeit abbrechen kann. Auch in dieser Situation kann ein sequenzieller Workflow verwendet werden, jedoch könnte jeder Schritt eine Verzweigung sein: Wird der Workflow abgebrochen, geht es auf einer Seite weiter, wird er nicht abgebrochen, geht es auf der anderen Seite der Verzweigung weiter. Die Umsetzung eines solchen Verhaltens ist mit einem Statusmechanismus erheblich einfacher, da eine Anforderung zum Abbruch des Workflows nichts weiter als ein Ereignis ist, das jederzeit empfangen und verarbeitet werden kann.

Die Unterstützung von Statusmechanismus-Workflows ist ein Beispiel dafür, wie WF sowohl von Menschen gesteuerte als auch System-Workflows unterstützt. Ein anderes Beispiel dafür ist die Möglichkeit in WF, laufende Workflows zu ändern. Menschen ändern ihre Meinung, und nicht selten kommt es vor, dass jemand einem Workflow einen Schritt hinzufügt, einen Schritt daraus löscht oder eine andere Änderung am Prozess vornehmen möchte, während dieser bereits ausgeführt wird. Um dies auf kontrollierte Weise zu ermöglichen, kann der Entwickler, der einen Workflow erstellt, in WF angeben, ob und wie ein Workflow während der Ausführung geändert werden kann.

Die Base Activity Library

Entwickler können Aktivitäten frei definieren. Ziel von Microsoft ist es denn auch, das Wachstum eines WF-Systems voller wiederverwendbarer Aktivitäten zu fördern. Aller Anfang ist jedoch schwer, weshalb ein gemeinsamer Satz grundlegender Aktivitäten bereitgestellt wird. Dieser gemeinsame Satz ist in der Base Activity Library (BAL) enthalten.

Ein Workflow muss keine Elemente aus der BAL verwenden. Viele Entwickler werden jedoch der Ansicht sein, dass die BAL ihre Arbeit, zumindest am Anfang, erleichtern kann. Zu den in der BAL enthaltenen Aktivitäten gehören die Folgenden:

  • IfElse (WennDann): Sie führt die Aktivitäten zweier oder mehr möglicher Pfade aus, je nachdem, ob eine Bedingung erfüllt ist.

  • While (Solange-Schleife): Sie führt eine oder mehrere Aktivitäten wiederholt aus, solange eine Bedingung wahr ist.

  • Sequence (Sequenz): Sie führt eine Gruppe von Aktivitäten nacheinander in einer definierten Reihenfolge aus.

  • Parallel: Sie führt zwei oder mehr Gruppen von Aktivitäten parallel aus.

  • Code: Sie führt einen definierten Codeteil aus.

  • Listen (Warten): Sie wartet auf ein bestimmtes Ereignis und führt eine oder mehrere Aktivitäten aus, sobald dieses Ereignis empfangen wird.

  • InvokeWebService (Webdienstaufruf): Sie ruft einen Webdienst auf.

  • State (Status): Sie stellt einen Status in einem Workflow-Statusmechanismus dar.

  • EventDriven (Ereignisgesteuert): Sie definiert einen Übergang aus einer oder mehreren Aktivitäten, die ausgeführt werden sollen, wenn ein bestimmtes Ereignis empfangen wird, während sich der Workflow in einem bestimmten Zustand befindet.

  • Policy (Richtlinie): Sie ermöglicht das Definieren und Ausführen von Geschäftsregeln mit einem von WF bereitgestellten Regelmodul.

Anstatt eine bestimmte Sprache für die Spezifikation von Workflows zu definieren, geht WF allgemeiner vor und verwendet Aktivitäten. Die BAL stellt eine "Sprache" zur Verfügung, aber jeder, der WF verwendet, kann auch seine eigene definieren.

Tools für Windows Workflow Foundation: der Workflow Designer

Einer der Vorteile der Erstellung von Anwendungen mit Workflows besteht darin, dass die Workflows grafisch dargestellt werden können. Der Workflow Designer von WF macht dies möglich (siehe Abbildung 8). Standardmäßig erscheinen die Aktivitäten aus der BAL in der Toolbox, von wo aus die Entwickler sie mit Drag & Drop in das Entwurfsfenster des Tools ziehen können, um einen Workflow zu erstellen.

Abbildung 8
Abbildung  8

Manche Entwickler mögen keine grafischen Designtools und schreiben lieber Code. In WF ist auch das möglich (und manchmal sogar erforderlich, da Aktivitäten grundsätzlich direkt in Code geschrieben werden). Die beiden Vorgehensweisen können auch kombiniert werden, d. h. ein Workflow kann unter Verwendung sowohl des Workflow Designers als auch der direkten Programmierung erstellt werden. Entwickler können daher die Verfahrensweise wählen, die für sie am produktivsten ist. Und damit Workflows von einer größeren Zahl Tools unterstützt werden, können sie auch in XAML geschrieben werden, derselben Sprache, die auch von WPF verwendet wird. Workflows, die mit dem Workflow Designer erstellt werden, sind daher standardmäßig auf XAML-Definition eingestellt.

Laufzeitmodul und Laufzeitdienste

Wie bereits erwähnt, ist es die Aufgabe des WF-Laufzeitmoduls, die Aktivitäten in einem Workflow auszuführen. Hierzu setzt es eine Gruppe von Laufzeitdiensten ein. WF umfasst Standardimplementierungen dieser Dienste, ehrgeizige Entwickler können sie jedoch nach Belieben ersetzen. Diese Dienste unterstützen verschiedene Funktionen, von denen zwei besonders interessant sind:

  • Persistence (Persistenz): Ein Workflow, der blockiert ist, weil er auf ein Ereignis wartet, kann diesen Dienst verwenden, um seinen im Speicher erfassten Status automatisch dauerhaft auf Festplatte zu speichern. Wenn das Ereignis eintritt, lädt der Dienst automatisch den Workflow-Status neu und startet die Ausführung erneut. Das ist insbesondere für Workflows von Nutzen, die Eingriffe von Personen erfordern, da Stunden, Tage oder noch größere Zeiträume vergehen können, während auf eine Antwort gewartet wird.

  • Tracking (Verfolgung): Die Aktivitäten in einem Workflow grenzen die Ausführung des Prozesses, den sie implementieren, deutlich ab. Anhand des Trackingdienstes von WF kann ein Entwickler festlegen, dass Informationen über die Workflow-Ausführung automatisch in eine Datenbank geschrieben werden. Ein Entwickler kann beispielsweise erfassen lassen, wann ein Workflow beginnt und endet, wann die einzelnen Aktivitäten beginnen und enden sowie andere Informationen.

Windows Workflow Foundation und andere Microsoft-Technologien

Durch die Einführung neuer Verfahren werden bestehende Technologien unweigerlich beeinflusst. Das trifft auch auf die neuen Technologien von .NET Framework 3.0 zu, von denen sich jede einzelne auf andere Microsoft-Technologien auswirkt. WF wirkt sich dabei besonders stark auf Windows SharePoint Services, das System Microsoft Office 2007 und BizTalk Server aus.

Um es Entwicklern zu erleichtern, Workflow-Anwendungen für den Austausch von Dokumenten und anderen Informationen zu erstellen, ist die WF-Laufzeit in die Version 3 von Windows SharePoint Services eingebunden. Office SharePoint Server 2007, das Teil des Office 2007-Systems ist, baut auf der WF-Unterstützung in Windows SharePoint Services auf. Durch das Hinzufügen dieses Servers wird es unter anderem ermöglicht, InfoPath-Formulare direkt in Office 2007-Clientanwendungen anzuzeigen und einen Satz vordefinierter Workflows für sich häufig wiederholende Aufgaben wie die Genehmigung von Dokumenten zu verwenden.

Wer mit BizTalk Server vertraut ist, wird sicherlich die Ähnlichkeit zwischen den Orchestrierungsfunktionen dieses Produkts und den Funktionen von WF bemerkt haben. Daher wird in der Nachfolgeversion von BizTalk Server 2006 die Orchestrierungsfunktion durch WF ersetzt werden. Zudem werden Tools für die Migration bestehender Orchestrierungen zu WF-Workflows bereitgestellt werden. Dabei ist jedoch zu beachten, dass WF und BizTalk Server 2006 für recht unterschiedliche Anforderungen konzipiert wurden:

  • WF bietet ein allgemeines Rahmenwerk für die Erstellung workflowbasierter Windows-Anwendungen. WF kann in jeden beliebigen Prozess eingebunden werden, alle Arten von Aktivitäten verwenden und zur Bewältigung unterschiedlichster Geschäftsszenarios eingesetzt werden, einschließlich von Menschen gesteuerte und System-Workflows.

  • BizTalk Server ist ein lizenziertes Produkt für die Integration von Unternehmensanwendungen, die Business-to-Business-Integration und die Verwaltung von Geschäftsprozessen. Es umfasst eine große Auswahl an Adaptern für die Verbindung mit verschiedenen Systemen und Programmen, Beschleuniger für die Implementierung von Standards wie RosettaNet und SWIFT sowie Unterstützung von Geschäftsaktivitätsüberwachung. BizTalk Server bietet zudem eine Verwaltungsinfrastruktur und Tools und unterstützt erhöhte Skalierbarkeit.

Da WF die Standardtechnologie für Workflows unter Windows ist, könnte WF in Zukunft auch in andere Microsoft-Produkte und -Technologien integriert werden. Wie auch immer Microsoft sich entscheiden wird, WF ist ein Platz in vielen der Anwendungen sicher, die von den Microsoft-Kunden erstellt werden.

Windows Communication Foundation

Der Wechsel zu serviceorientierter Kommunikation leitet eine neue Ära der Anwendungsinteraktion ein. WCF ist für die Unterstützung serviceorientierter Anwendungen konzipiert und spiegelt diesen Wechsel wider. In diesem Abschnitt werden die wichtigsten Merkmale von WCF erörtert. Dazu gehören Dienste und Clients, Kommunikationsoptionen und die Unterstützung von Sicherheit, zuverlässiger Kommunikation und Transaktionen.

Dienste und Clients

Abbildung 9
Abbildung  9

Wie in Abbildung 9 zu sehen, ist das Basiskonzept von WCF einfach: Ein Dienst macht eine Schnittstelle verfügbar, auf die Clients zugreifen können. Diese Schnittstelle kann mit der Web Services Description Language (WSDL) definiert und anschließend in Code umgewandelt werden. Sie kann aber auch direkt in einer Sprache wie C# oder Visual Basic programmiert werden. Im Falle einer einfachen Schnittstelle, die einen Antragsstellungsdienst für Versicherungen verfügbar macht, könnte sie folgendermaßen aussehen:

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

Die Definition dieser C#-Schnittstelle ist mit dem Attribut ServiceContract markiert. Dieses Attribut gibt an, dass WCF in dieser Schnittstelle Methoden als remote aufrufbare Operationen verfügbar machen kann. Welche der Schnittstellenmethoden verfügbar gemacht werden, hängt davon ab, welche mit dem Attribut OperationContract markiert sind. In diesem einfachen Beispiel ist jede Methode durch dieses Attribut gekennzeichnet, weshalb alle für Remote-Aufrufe verfügbar gemacht werden. Das ist aber nicht zwingend – das Attribut OperationContract kann auch nur auf einige der Methoden einer Schnittstelle angewendet werden. Wie auch immer die Wahl ausfallen mag, eine Klasse in der Anwendung muss diese Schnittstelle implementieren, indem sie Code für die von der Schnittstelle definierten Methoden übergibt. Sobald dies geschehen ist, macht WCF die mit OperationContract markierten Methoden automatisch den Clients dieses Dienstes zugänglich.

In Abbildung 10 wird etwas detaillierter dargestellt, wie ein Dienst seinen Clients verfügbar gemacht wird. Anstatt direkt auf eine Schnittstelle zuzugreifen, stellt ein Client die Verbindung zu einem spezifischen Endpunkt her. Ein Dienst kann mehrere Endpunkte zugänglich machen und auf diese Weise verschiedenen Clients den Zugriff auf unterschiedliche Weise ermöglichen.

Abbildung 10
Abbildung  10

Wie aus der Abbildung hervorgeht, spezifiziert jeder Endpunkt drei Dinge:

  • Einen contract (Vertrag), der die Operationen beschreibt, die mit diesem Endpunkt aufgerufen werden können. Zur Identifizierung des Vertrags kann einfach der Name der Schnittstelle verwendet werden, die diese Operationen definiert, in diesem Fall "IInsuranceApplication".

  • Eine binding (Bindung), die definiert, wie die Operationen des Endpunkts aufgerufen werden können. Jede Bindung definiert verschiedene Dinge, unter anderem, welches Protokoll zum Aufrufen der Operationen und welche Art der Sicherheit verwendet werden soll usw. WCF umfasst einen Satz vordefinierter Bindungen, beispielsweise die hier gezeigte BasicHttpBinding, für die am häufigsten vorkommenden Szenarios. Es können jedoch auch benutzerdefinierte Bindungen erstellt werden. Da ein einzelner Dienst mehrere Endpunkte verfügbar machen kann, kann er gleichzeitig Zugriff auf verschiedene Arten von Clients über unterschiedliche Protokolle und mit unterschiedlichen Sicherheitsoptionen gewähren.

  • Eine address (Adresse), die angibt, wo sich der Endpunkt befindet. Wie in der Abbildung gezeigt, wird die Adresse als URL dargestellt.

Die Grundstruktur von WCF ist einfach. Wie bei den meisten Kommunikationstechnologien können die Details komplex werden, da es viele Optionen gibt, aber die Erstellung normaler WCF-Anwendungen ist nicht schwierig.

Kommunikationsoptionen

Unterschiedliche Arten von Anwendungen, die von verschiedenen Entwicklern erstellt wurden, benötigen unterschiedliche Kommunikationsverfahren. Für die meisten Entwickler ist das einfachste Verfahren der Remote Procedure Call (RPC), der es Clients ermöglicht, Remote-Operationen ähnlich wie lokale Operationen aufzurufen. In der zuvor angeführten Beispielschnittstelle würde ein Client jede Operation in der normalen synchronen Weise aufrufen und auf eine Antwort warten. Diese Option ist für Entwickler einfach und stellt unter bestimmten Umständen die richtige Wahl dar.

WCF umfasst jedoch noch weitere Optionen. Dazu gehören u. a. Folgende:

  • Anrufe, die keine Antwort erfordern. Sie werden mit dem Attribut OneWay markiert. Diese Art der Kommunikation kann für das Senden von Ereignissen oder andere einseitige Interaktionen nützlich sein.

  • Asynchrone meldungsbasierte Kommunikation unter Verwendung direkter Sende- und Empfangsvorgänge mit XML-Meldungen

  • Explizite Bearbeitung der SOAP-Meldungen, einschließlich der Fähigkeit, Elemente direkt in den SOAP-Header einzufügen

Sicherheit, Zuverlässigkeit und Transaktionen

Basiskommunikation, d. h. die Fähigkeit, Daten zwischen Systemen zu übermitteln, ist nützlich, kommt aber selten vor. Die Mehrzahl der Anwendungen stellt höhere Anforderungen. Die meisten der verteilten Anwendungen benötigen eine wie auch immer geartete Sicherheitsfunktion. Für Sicherheit zu sorgen, kann sich als komplexe Aufgabe erweisen, da die Palette der unterschiedlichen Verfahren und Technologien, die heute angewendet werden, immens ist. Damit Entwickler verteilte Anwendungen sicher erstellen können, ohne alle Einzelheiten bis ins Kleinste kennen zu müssen, nutzt WCF hauptsächlich Bindungen für die Sicherheit. Die Bindung BasicHttpBinding, die schon zuvor angesprochen wurde, kann für die Verwendung von HTTPS anstatt des einfachen HTTP konfiguriert werden. Andere Bindungen bieten noch mehr Sicherheitsoptionen. WsHttpBinding unterstützt beispielsweise WS-Security und ermöglicht so die interoperable SOAP-basierte Authentifizierung, Datenintegrität und Datenvertraulichkeit. Entwickler können auch eine individuelle Bindung mit genau den Sicherheitsdiensten erstellen, die ihre Anwendung erfordert.

Für viele Anwendungen ist es ebenfalls entscheidend, die Zuverlässigkeit der Kommunikation sicherzustellen. In einigen Fällen ist es ausreichend, das herkömmliche Webdienstverfahren (SOAP über HTTP) zu verwenden. Dieses wird auch von BasicHttpBinding verwendet. In vielen Situationen reicht diese häufig verwendete Option nicht aus. Für Nachrichten, die einen oder mehrere SOAP-Knoten passieren, reicht dieses einfache Verfahren für die End-to-End-Zuverlässigkeit nicht. Für diese Fälle implementiert WCF die Option WS-ReliableMessaging. Indem ein Entwickler eine Bindung wählt, die diese Option unterstützt, z. B. WsHttpBinding, erreicht er automatisch einen interoperablen zuverlässigen Nachrichtentransfer.

Verteilte Transaktionen können ebenfalls in einigen Anwendungen wichtig sein. WCF baut auf System.Transactions, einem Bestandteil vom .NET Framework 2.0, auf, um das Erstellen von Transaktionssoftware zu ermöglichen. Eine Methode kann das Attribut OperationBehavior verwenden, um anzugeben, dass sie eine Transaktion erfordert, und um zu definieren, wie das Transaktionsverhalten sein soll. Um verteilte Transaktionen zu ermöglichen, die herstellerübergreifend interoperabel sind, verwendet WCF die Spezifikation WS-AtomicTransaction. Unter Verwendung der in diesem Herstellerabkommen definierten Technologie können WCF-Anwendungen an Transaktionen teilnehmen, die verschiedene Technologien (z. B. J2EE) umspannen.

Windows Communication Foundation und andere Microsoft-Technologien

Wie schon erwähnt, ersetzt WCF mehrere ältere Microsoft-Technologien für die Erstellung verteilter Anwendungen. Die meisten Anwendungen, die mit ASP.NET Web Services, .NET Remoting, Enterprise Services, System.Messaging oder WSE erstellt worden wären, werden nun auf der Grundlage von WCF entwickelt werden. WCF-Anwendungen können mit ASP.NET Web Services-Anwendungen – beide unterstützen Standard-SOAP – sowie mit Anwendungen interoperieren, die mit Enterprise Services, MSMQ und Version 3.0 von WSE erstellt wurden. WCF kann auch von BizTalk Server 2006 verwendet werden, und die Folgeversion von BizTalk Server wird noch unmittelbarer auf WCF gründen.

Es ist wichtig zu wissen, dass alle Technologien, die von WCF ersetzt werden, Teil dieser Version von Framework bleiben und weiterhin unterstützt werden, obgleich .NET Framework 3.0-Anwendungen sie in der Regel nicht nutzen werden. Anwendungen, die mit früheren Versionen dieser Technologien erstellt wurden, funktionieren ebenfalls weiter normal. Durch die Installation und Ausführung von .NET Framework 3.0 wird der bestehende Code nicht verändert.

Windows CardSpace

Benutzer greifen gewöhnlich über ein Netzwerk auf Anwendungen zu, sei es, dass sie hierzu einen Webbrowser oder eine andere Art von Client verwenden. Da die Benutzer sich in der Regel gegenüber diesen Anwendungen identifizieren müssen, ist es unausweichlich, dass die Anwender regelmäßig gezwungen sind, Identitätsinformationen zu beantragen und an Remote-Programme weiterzugeben. Ein gängiges Beispiel hierfür ist der Zugriff auf Internetanwendungen über einen Browser, aber auch Benutzer von Intranets stehen vor demselben Problem.

Wie schon eingangs erwähnt, verwenden die meisten Menschen heute Benutzernamen und Kennwörter als digitale Identitäten – trotz der Risiken, die damit verbunden sind. Windows CardSpace, das Teil eines größeren Identitätsmetasystems ist, bietet ein alternatives Verfahren zur Lösung dieses Problems. Um zu verdeutlichen, wie CardSpace dabei vorgeht, werde ich mit der Erläuterung der Grundkonzepte des Identitätsmetasystems beginnen.

Windows CardSpace und das Identitätsmetasystem

Wenn Benutzer auf eine Anwendung zugreifen, sei es von einem Webbrowser, einem anwendungsspezifischen Client oder einem anderen Programm aus, müssen sie in der Regel eine digitale Identität nachweisen. Digitale Identitäten gibt es in vielen Varianten, aber praktisch alle werden im Netzwerk durch ein Sicherheitstoken dargestellt. Während ein einfaches Sicherheitstoken auch nur aus einem Benutzernamen bestehen kann, können komplexere Token beispielsweise ein X.509-Zertifikat oder ein XML-Dokument umfassen. Unabhängig davon, wie sie dargestellt werden, sind Sicherheitstoken heute der übliche Mechanismus für die Darstellung digitaler Identitäten im Netzwerk.

Die Vorstellung, dass wir irgendwann alle ein einheitliches Sicherheitstokenformat verwenden werden, ist verlockend, aber eher unrealistisch. Wahrscheinlich wird es weiterhin verschiedene Formate geben. So wie wir heute mehrere Ausweise in unserer Brieftasche mitführen – Führerschein, Personalausweis, Mitgliedsausweise etc. –, werden wir auch immer mehrere digitale Identitäten haben, die von unterschiedlichen Sicherheitstoken dargestellt werden. Kein Identitätssystem kann eine universell geeignete Lösung bieten, und deshalb werden immer mehrere Sicherheitstoken notwendig sein.

Benutzer müssen jedoch in der Lage sein, auf konsistente Weise mit ihren verschiedenen digitalen Identitäten zu arbeiten. Wenngleich ein einziges Identitätssystem nicht ausreichen wird, ist es doch möglich, ein System aus Identitätssystemen zu erzeugen – ein Identitätsmetasystem, das die Verwendung einer Vielzahl digitaler Identitäten auf einheitliche Weise ermöglicht. Microsoft arbeitet auf diesem Gebiet mit anderen Herstellern zusammen und hat eine Vorreiterrolle bei der Definition dieses Metasystems übernommen. Dieses Metasystem definiert auf der Basis offener Webdiensttechnologien wie WS-Security und WS-Trust, auf welche Weise digitale Identitäten erstellt und verwendet werden, und zwar unabhängig vom Typ des Sicherheitstokens.

Der Prozess der Ausstellung, Übertragung und Verwendung digitaler Identitäten erfordert drei verschiedene Rollen. Diese Rollen sind wie folgt:

  • Benutzer: Die Benutzer sind die Inhaber der digitalen Identitäten.

  • Identitätsprovider: Ein Identitätsprovider weist einem Benutzer eine digitale Identität zu. Bei digitalen Identitäten, die beispielsweise von einem Arbeitgeber zugewiesen werden, übernimmt in der Regel ein System wie Active Directory die Rolle des Identitätsproviders. Die digitale Identität, die Sie z. B. für Amazon verwenden, definieren Sie selbst, indem Sie einen Benutzernamen und ein Kennwort auswählen. Sie sind daher praktisch Ihr eigener Identitätsprovider. Von verschiedenen Identitätsprovidern erstellte digitale Identitäten können unterschiedliche Informationen beinhalten und unterschiedliche Sicherheitsniveaus in Bezug auf die Identität der Benutzer bieten.

  • Relying Party: Eine Relying Party ist eine Anwendung, die digitale Identitäten verwendet. Eine Relying Party verwendet eine Identität (d. h. die im Sicherheitstoken der Identität enthaltenen Informationen) zur Authentifizierung eines Benutzers und fällt dann eine Autorisierungsentscheidung, um dem Benutzer den Zugriff auf Informationen zu gewähren oder zu verweigern. Eine Relying Party kann die Identität auch dazu verwenden, eine Kreditkartennummer abzufragen, um zu prüfen, ob derselbe Benutzer zu unterschiedlichen Zeiten auf sie zugreift, oder zu anderen Zwecken. Typische Beispiele für Relying Partys sind Websites von Banken, Online-Händlern und -Auktionen im Internet sowie alle Anwendungen, die Anforderungen über Webdienste entgegennehmen.

Diese drei Elemente interagieren im Identitätsmetasystem. Abbildung 11 veranschaulicht diese Interaktionen und zeigt, wo CardSpace zum Einsatz kommt.

Abbildung 11
Abbildung  11

Der Prozess beginnt, wenn ein Benutzer über eine CardSpace-kompatible Anwendung auf eine Relying Party zugreift. Die Anwendung fordert die Richtlinie der Relying Party an (Schritt 1), um zu erfahren, welche Art des Sicherheitstokens von der Relying Party abgefragt wird. Wird mit einem Browser auf eine Website zugegriffen, was der Normalfall ist, wird die Richtlinie der Website in HTML ausgedrückt und als Teil einer Webseite zurückgeschickt. Anwendungen, auf die über Webdienste zugegriffen wird, verwenden stattdessen das von WS-MetadataExchange definierte Standardprotokoll, um die Relying Party nach ihrer Richtlinie zu fragen. In diesem Fall wird die Richtlinie in WS-SecurityPolicy ausgedrückt, einem anderen Industriestandard. Ganz gleich, wie die Richtlinieninformationen eingeholt werden, sie geben immer an, welche Art von Sicherheitstoken diese Relying Party akzeptiert und welche Informationen in diesen Token enthalten sein müssen.

Sobald CardSpace Kenntnis davon hat, welche Art des Sicherheitstokens die Relying Party benötigt, zeigt es den zuvor abgebildeten Identitätsbildschirm an. Alle für einen Benutzer zur Verfügung stehenden digitalen Identitäten werden in Form von Informationskarten auf diesem Bildschirm dargestellt. Karten, die von einer externen Relying Party ausgestellt wurden, werden als verwaltete Karten bezeichnet, während die vom CardSpace-Provider für selbst ausgestellte Identitäten ausgestellten Karten als selbst ausgestellt bezeichnet werden. Beide Arten von Karten können auf diesem Bildschirm angezeigt werden, und der Benutzer kann jeweils eine auswählen. Um die Entscheidung zu erleichtern, wird auf dem Bildschirm auch angezeigt, welche Identitäten die Anforderungen der Relying Party erfüllen, indem die Karten abgeblendet werden, auf die das nicht zutrifft. Der Benutzer wählt dann eine als digitale Identität aus, die er verwenden möchte (Schritt 2).

Eine Karte beinhaltet jedoch kein Sicherheitstoken. Stattdessen enthält sie die nötigen Informationen, um den betreffenden Identitätsprovider zu ermitteln und ein Sicherheitstoken für den Benutzer anzufordern. (Jede Karte wird nämlich ursprünglich von einem Identitätsprovider ausgestellt.) CardSpace verwendet die Daten der vom Benutzer ausgewählten Karte, um ein Sicherheitstoken beim Identitätsprovider anzufordern, der die Karte ausgestellt hat (Schritt 3). Für die Anforderung wird WS-Trust verwendet, ein weiteres Industriestandardprotokoll. Die Benutzer hingegen authentifizieren sich gegenüber dem Identitätsprovider mit Kerberos, einem X.509-Zertifikat mit digitaler Signatur, oder einem anderen Mechanismus. Das Token wird in verschlüsselter Form zurückgegeben und enthält einen Zeitstempel, der verhindert, dass das Token bei der Übertragung gestohlen und später wiederverwendet wird.

Nachdem das angeforderte Sicherheitstoken zurückgegeben wurde, wird es an die Relying Party gesendet (Schritt 4). Die Art und Weise, wie die Relying Party die Informationen im Token nutzt, kann variieren. Enthält das Token beispielsweise ein X.509-Zertifikat und eine digitale Signatur, verwendet die Relying Party wahrscheinlich das Token zur Authentifizierung des Benutzers. Allerdings besteht keine Verpflichtung dazu, das Token zur Authentifizierung oder zu irgendeinem anderen sicherheitsbezogenen Zweck zu verwenden. (Der Begriff "Sicherheitstoken" ist daher eigentlich irreführend.) Ein Token kann Informationen wie einen Altersnachweis des Benutzers, Anspruch auf Rabatt in einem Internet-Einkaufsportal o. Ä. enthalten. Die Authentifizierung ist eine wichtige Verwendungsmöglichkeit für Sicherheitstoken, jedoch längst nicht die einzige.

Zudem ist es wichtig zu wissen, dass weder CardSpace noch das Identitätsmetasystem als Ganzes das Format oder die für das Sicherheitstoken verwendete Technologie beachten. Ziel des Metasystems ist es nicht, eine neue einheitliche Quelle für digitale Identitäten oder ein Standardformat für Sicherheitstoken zu erstellen, sondern ein kohärentes Verfahren für die Verwendung digitaler Identitäten bereitzustellen, die unterschiedlicher Art sind und auf unterschiedlichen Sicherheitstoken basieren. CardSpace bietet eine Windows-Implementierung der Kernkomponenten des Metasystems und spielt daher eine wichtige Rolle bei der Umsetzung dieses allgemeinen Verwendungssystems für digitale Identitäten.

Schutz vor Phishing

Identitätsprovider sind häufig nicht mit dem Benutzer identisch, z. B. dann nicht, wenn eine Identität vom Arbeitgeber zugewiesen wird. Es gibt allerdings viele Situationen, in denen die Benutzer selbst Identitätsprovider sind. Wird CardSpace nicht verwendet, müssen Benutzer beim Zugriff auf viele Websites einen Benutzernamen und ein Kennwort angeben, die sie beide selbst definiert haben. Nachdem die Benutzer ihre Identität erstellt haben, können sie sich mit ihrem Benutzernamen und ihrem Kennwort anmelden und dann je nach Website ihren Kontostand abfragen, ein Buch kaufen usw.

Wegen der Verwendung von Kennwörtern ist diese Art der selbst ausgestellten Identität, wie bereits erwähnt, Ziel von Angriffen der Phisher. Um solche Angriffe zu verhindern, bietet CardSpace ein alternatives Verfahren zur Erstellung selbst ausgestellter Identitäten. Dieser Provider für selbst ausgestellte Identitäten wird lokal im Windows-System des Benutzers ausgeführt. Anstatt einen Benutzernamen und ein Kennwort zu verwenden, werden die vom Provider für selbst ausgestellte Identitäten erzeugten Sicherheitstoken mit der Security Assertion Markup Language (SAML) definiert, einem OASIS-definierten Standard. Diese Token verwenden öffentliche Schlüssel statt Kennwörter, um die Identität des Benutzers nachzuweisen. Wenn sie von der Relying Party akzeptiert werden, erfüllen sie den gleichen Zweck wie die gewohnten Benutzernamen und Kennwörter. Der Vorteil dabei ist, dass es kein Kennwort gibt, das von Phishern gestohlen werden kann. Indem Kennwörter seltener verwendet werden und die Identität von Websites durch die zuvor beschriebenen Hochsicherheitszertifikate strenger kontrolliert wird, kann das Phishing wirksam bekämpft werden.

Windows CardSpace und andere Microsoft-Technologien

CardSpace steht im Zusammenhang mit mehreren anderen Microsoft-Technologien. Hierzu zählen unter anderem:

  • WCF: CardSpace verwendet WCF für die Kommunikation, weil WCF Webdienststandards wie WS-Security und WS-Trust verwendet. Daher kann der Entwickler einer WCF-Anwendung diese anweisen, CardSpace zu verwenden, indem er einfach die entsprechende Bindung spezifiziert.

  • Active Directory: Auch wenn dies heute noch nicht möglich ist, wird Active Directory irgendwann in der Lage sein, als Identitätsprovider im Metasystem zu fungieren.

  • Windows Live ID (ehemals unter dem Namen "Passport" bekannt): Wie schon für Active Directory hat Microsoft auch für sein Authentifizierungssystem Live ID bekannt gegeben, dass es überarbeitet werden wird, um als Identitätsprovider fungieren zu können. Beachten Sie jedoch, dass CardSpace kein Ersatz für Live ID ist, da beide für ganz unterschiedliche Problemstellungen konzipiert wurden. Live ID wird vielmehr wie jeder andere Identitätsprovider Teil des Identitätsmetasystems sein.

Microsoft hat darüber hinaus weitere identitätsbezogene Technologien entwickelt, die etwas andere Aufgaben erfüllen als CardSpace. Active Directory Federation Services (ADFS) dient beispielsweise der Erstellung verbundener Identitäten in Partnerunternehmen. Dabei handelt es sich um eine wichtige Problemstellung, die von vielen Unternehmen gelöst werden muss, die mit anderen Unternehmen zusammenarbeiten. Diese Problematik unterscheidet sich jedoch stark von den allgemeineren Problemen, die mit CardSpace und dem Identitätsmetasystem gelöst werden können.

Windows Presentation Foundation

Workflowbasierte Logik, serviceorientierte Kommunikation und Identität sind drei wichtige Aspekte moderner Anwendungen. Dennoch legen die Benutzer meist mehr Wert auf das, was zu sehen ist: die Benutzeroberfläche. WPF zielt darauf ab, Lösungen für Probleme zu bieten, die bei der Erstellung von Benutzeroberflächen für moderne Anwendungen auftreten. Nachfolgend wird die umfangreiche Funktionspalette von WPF beschrieben, die dazu zur Verfügung steht.

Die Funktionen von Windows Presentation Foundation

Entwicklern steht es frei, die Benutzeroberfläche einer WPF-Anwendung komplett in C#, Visual Basic oder einer anderen CLR-basierten Sprache zu erstellen. Wie schon erwähnt, ermöglicht es WPF aber auch, eine Benutzeroberfläche in der XML-basierten Sprache XAML zu schreiben. Die Elemente und Attribute von XAML lassen sich direkt den Klassen und Eigenschaften von WPF zuordnen. Es folgt das Beispiel einer einfachen Schaltfläche, die in XAML definiert wurde:

<Button Background="Red">
   No
</Button>

Dieser Beispielcode erzeugt eine rote Schaltfläche mit der Aufschrift "No". Das gleiche Ergebnis kann auch mit dem folgenden Code erzielt werden:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Praktisch jede WPF-Anwendung weist dasselbe Grundmodell auf, unabhängig davon, wie sie definiert wurde. Die Anwendung erbt vom WPF-Standardanwendungsobjekt, das grundlegende Methoden, Ereignisse und Eigenschaften bereitstellt. Eine WPF-Anwendung kann entweder eine herkömmliche dialoggesteuerte GUI oder eine Navigations-GUI besitzen, die in der Funktionsweise der eines Browsers ähnelt. Eine mit einer Navigations-GUI erstellte Anwendung wird gewöhnlich als Gruppe von Seiten implementiert, von denen jede aus einer in XAML definierten Benutzeroberfläche und einer in Code geschriebenen Logik besteht. Um diese Seiten miteinander zu verknüpfen, enthält XAML ähnlich wie HTML ein Hyperlink-Element. Die Anwendung zeigt jeweils eine Seite an, ermöglicht dem Benutzer das Vor- und Zurückblättern auf den Seiten, führt eine Verlaufsliste und vieles mehr. Wenngleich eine Navigationsanwendung innerhalb eines Webbrowsers als XBAP ausgeführt werden kann, ist das nicht zwingend; ein Entwickler kann diesen Schnittstellenstil ebenso in installierten WPF-Anwendungen verwenden. Ziel ist es, Programme zu entwickeln, die die besten Eigenschaften einer Browser-GUI und einer systemeigenen Windows-GUI vereinen.

Unabhängig vom Stil der Benutzeroberfläche kann eine WPF-Anwendung Panels (Bereiche) für die Basisstruktur verwenden. Jeder Bereich enthält gewöhnlich Controls (Steuerungen). Die WPF-Steuerungen umfassen unter anderem Button (Schaltfläche), TextBox (Textfeld), ComboBox (Kombinationsfeld), Menu (Menü) und viele mehr. Wie diese Steuerungen angeordnet werden, hängt von der Art des gewählten Bereichs ab. Die Option "Grid" (Raster) ermöglicht das Positionieren von Steuerungen auf einem angegebenen Raster, während die Option "Canvas" (Leinwand) es dem Entwickler ermöglicht, Steuerungen beliebig innerhalb der Begrenzungen zu platzieren. Wie für eine GUI üblich, werden die vom Benutzer generierten Ereignisse von den verschiedenen Steuerungen und anderen Klassen in der Anwendung erfasst und verarbeitet. Darüber hinaus können Stile und Vorlagen auf Gruppen von Steuerungen angewendet werden, damit Anwendungen sich optisch einheitlich präsentieren.

WPF unterstützt noch viele weitere GUI-Funktionen neben diesen grundlegenden. Dazu gehören Folgende:

  • Dokumente: Eine WPF-Anwendung kann XPS-Dokumente mithilfe des XAML-Tags FixedDocument anzeigen. Eine Anwendung kann zudem Fließdokumente mithilfe des Tags FlowDocument anzeigen. Ein Fließdokument ähnelt in der Funktionsweise einem herkömmlichen Bildschirmdokument und gestattet es dem Benutzer, seinen Inhalt durchzublättern. Durch Einstellen verschiedener Attribute für dieses Tag kann ein Entwickler das Dokument jedoch stärker an dessen Umgebung anpassen. Ein Dokument kann beispielsweise jeweils nur eine Seite anzeigen, damit der Leser nicht mehr vor- und zurückblättern muss. WPF bestimmt zudem automatisch basierend auf der Größe des Fensters, in dem das Dokument angezeigt wird, in wie viele Spalten es unterteilt werden sollte. Dadurch soll erreicht werden, dass Bildschirmdokumente besser lesbar sind.

  • Grafiken: WPF unterstützt die Erstellung zwei- und dreidimensionaler Vektorgrafiken. Für die Arbeit mit 2D-Grafiken bietet WPF Standardabstraktionen wie z. B. Formen, Pinsel und Stifte, während mit 3D-Grafiken ein Modell definiert werden kann, dem Beleuchtungs- und Kamerapositionsinformationen zugewiesen werden können. Im Gegensatz zu älteren Technologien wie Windows Forms, die GDI+ für Grafiken verwendete, werden bei WPF Grafiken nicht durch eine separate Funktionspalette, mit der sich Entwickler zusätzlich befassen müssen, vom Rest der Anwendung getrennt. Stattdessen können die für Grafiken verwendeten XAML-Elemente auf natürliche Weise mit anderen Elementen für die Benutzeroberfläche kombiniert werden. Schaltflächen können grafische Inhalte umfassen, Text und Grafiken können kombiniert werden usw.

  • Bilder: Mithilfe des XAML-Tags Image kann eine WPF-Anwendung Bilder in verschiedenen Formaten anzeigen, darunter JPEG, GIF und andere mehr. WPF verwendet Windows Imaging Component (WIC), um ein Standardrahmenwerk für Codec-Software bereitzustellen, die Bilder anzeigt und speichert. Auch ein Image-Element kann in WPF mit anderen kombiniert werden; auf diese Weise kann z. B. eine Schaltfläche mit einem Bild anstelle eines einfachen Textlabels definiert werden.

  • Medien: Eine WPF-Anwendung kann das Tag MediaElement zur Wiedergabe von Video- und Audioaufnahmen in verschiedenen Formaten wie beispielsweise WMV, AVI und MPEG verwenden. Auch dieses Element kann mit anderen XAML-Elementen kombiniert werden. So kann beispielsweise ein 3D-Würfel erstellt werden, auf dessen Seiten Videobilder angezeigt werden.

  • Animation: WPF unterstützt die Animation der meisten Komponenten einer Benutzeroberfläche. Ein Kreis kann beispielsweise wachsen und schrumpfen und eine Schaltfläche allmählich ihre Größe ändern. Anwendungen können zudem Verlaufstafeln mit Zeitleisten definieren und somit koordinierte Sequenzen von Animationen ermöglichen.

  • Datenbindung: Da viele WPF-Anwendungen Daten anzeigen, ist es sinnvoll, Daten automatisch Elementen der Benutzeroberfläche zuordnen zu lassen. WPF bietet diese Art der Datenbindung für Informationen aus Objekten und anderen Quellen. Die WPF-Datenbindung ermöglicht zudem das Sortieren und Filtern von Daten, bevor diese angezeigt werden.

Anwenden von Windows Presentation Foundation

WPF beinhaltet ein großes Angebot an GUI-Funktionen, die es Entwicklern und Designern ermöglichen, attraktive Benutzeroberflächen zu erstellen. Eine Clientanwendung kann aber noch so attraktiv sein, manche Unternehmen sehen aufgrund von Bereitstellungsproblemen vielleicht lieber von der Verwendung ab. Wenn die Einführung einer neuen Version des Clients manuelle Eingriffe auf jedem Desktopcomputer erfordert, auf dem die Anwendung installiert ist, können die Kosten für Upgrades beträchtlich sein. Dieses Problem wird heute gerne durch die Erstellung browserbasierter Clients anstatt systemeigener Windows-Clients umgangen. Allerdings haben systemeigene Windows-Clients im Allgemeinen bessere, reaktionsfähigere Benutzerschnittstellen als Browser. Installierte WPF-Anwendungen können mit ClickOnce eingerichtet werden, wodurch Probleme bei der Bereitstellung dieser Clients vermieden werden. Die Technologie ClickOnce kam erstmals in .NET Framework 2.0 zur Anwendung. Sie ermöglicht es Internet Explorer-Benutzern, eine Anwendung über das Internet auszuwählen und automatisch auf ihrem lokalen Computer zu installieren. Nachdem sie installiert wurde, kann die Anwendung auch automatisch aktualisiert werden, sobald eine neue Version verfügbar ist. Zweck dieser Technologie ist es, die einfache und kostengünstige Bereitstellung eines Webclients mit der Leistungsstärke und Funktionalität einer installierten WPF-Anwendung zu verbinden.

Insbesondere dann, wenn installierte WPF-Anwendungen anhand von ClickOnce bereitgestellt werden, stellen sie eine gute Clientoption für viele Anforderungssituationen dar. Dennoch gibt es Fälle, in denen diese Art der Anwendung auch dann ungeeignet ist, wenn die Benutzer von der Benutzeroberfläche, wie WPF sie bietet, profitieren würden. Denken Sie einmal an den Versicherungsvertreter aus dem weiter oben beschriebenen Szenario oder einen Internethändler, der 3D-Grafiken, Videos und andere moderne Funktionen, die von WPF unterstützt werden, nutzen möchte. Es ist eher unwahrscheinlich, dass die Benutzer dieser Anwendung eine systemeigene WPF-Anwendung installieren würden, um auf die Website zuzugreifen. Eine bessere Lösung wäre es, den Benutzern eine Schnittstelle im WPF-Stil innerhalb ihres Webbrowsers bereitzustellen.

XAML-Browseranwendungen – XBAPs – sind genau hierfür entwickelt worden. Anstatt eine installierte WPF-Anwendung bereitzustellen, kann ein Internet Explorer-Benutzer eine XBAP direkt in den Browser herunterladen. Die Anwendung wird innerhalb von Internet Explorer ausgeführt und zeigt dem Benutzer eine WPF-basierte Benutzeroberfläche an. Das Herunterladen und Ausführen von Code über Internetseiten birgt jedoch Risiken. Um Benutzer vor böswilligen Entwicklern zu schützen, werden alle aus dem Internet geladenen XBAPs in einer teilweise vertrauenswürdigen Sandbox ausgeführt. Basierend auf der Sicherheitsrichtlinie für den Codezugriff von .NET Framework beschränkt diese Sandbox die Funktionsweise der XBAPs. Eine aus dem Internet heruntergeladene XBAP kann keine eigenständigen Fenster erstellen oder neuen Fenster öffnen, einen von der XBAP selbst gestarteten Speicher-Dialog anzeigen oder auf das Dateisystem zugreifen (außer in einem isolierten Speicherbereich). Trotz der Beschränkungen, die von der Sandbox auferlegt werden, kann eine XBAP einen Großteil der WPF-Funktionen nutzen und beispielsweise zwei- und dreidimensionale Grafiken, Animationen, Bildschirmdokumente, Bilder, Videos und vieles mehr anzeigen.

Wie schon erwähnt, zeigen WPF-Anwendungen angepasste Dokumente mithilfe des XAML-Elements FlowDocument an. Dokumente, deren Gestalt sich in Abhängigkeit davon ändert, wie sie angezeigt werden, sind jedoch nicht immer die beste Lösung. Dokumente mit festgelegtem Format, die auf dem Bildschirm und im Ausdruck immer gleich aussehen, stellen manchmal die bessere Wahl dar. Die XPS-Dokumente von WPF sind dafür konzipiert. XPS-Dokumente sind mit einer Untergruppe von XAML definiert und können von jedem System gelesen werden, das einen XPS Reader beinhaltet. Sie bieten zudem ein neues Druckformat für Windows, das komplexe Grafiken genauer wiedergibt. Damit die Arbeit mit unterschiedlichen Dokumentarten konsistenter wird, verwenden sowohl XPS-Dokumente als auch Office 2007-Dokumente die Open Packaging Conventions von Microsoft. Sie legen gemeinsame Verfahren zum Speichern von Dokumentinhalten, digitalen Signieren von Dokumenten und anderen Vorgängen fest.

Tools für Windows Presentation Foundation

Jede WPF-Benutzeroberfläche kann direkt als Code geschrieben und/oder mit einem normalen Texteditor in XAML erstellt werden. Viele Anwender wünschen sich jedoch bessere Tools, weshalb Microsoft Erweiterungen für Visual Studio 2005 anbietet, mit denen Entwickler WPF-Anwendungen erstellen können. Die nächste Version von Visual Studio – ihr Codename lautet "Orcas" – wird mit dem Visual Designer für Windows Presentation Foundation ein noch größeres Funktionsangebot umfassen. Mit diesem Tool können Entwickler die Benutzeroberfläche, die sie erstellen wollen, grafisch definieren und den Code dafür vom Tool generieren lassen.

Entwickler sind jedoch häufig nicht die qualifiziertesten Personen für die Gestaltung der Benutzeroberfläche. Designer bringen dafür die besseren Voraussetzungen mit, denn sie sind auf die Kommunikation mit Menschen spezialisiert. Die meisten Designer schreiben jedoch keinen Code, weshalb der Visual Designer für Windows Presentation Foundation, der in Visual Studio eingebunden ist, ein für diese Gruppe bestens geeignetes Tool ist. Damit Designer in einer WPF-Umgebung effektiv arbeiten können, hat Microsoft Expression Interactive Designer entwickelt. Ein Designer kann mithilfe dieses Tools das Erscheinungsbild einer Benutzeroberfläche definieren, Animationen spezifizieren sowie weitere Eigenschaften festlegen und dann das Tool anweisen, eine XAML-Version der erstellten Benutzeroberfläche zu generieren. Ein Entwickler kann diese XAML-Version dann in Visual Studio importieren und Code für Elemente wie beispielsweise Verarbeitungsereignisse hinzufügen. Da Visual Studio und Expression Interactive Designer dasselbe Buildsystem verwenden, können Entwickler und Designer gemeinsam iterativ an einem Projekt arbeiten und jeweils das Tool verwenden, das sie bevorzugen. Ziel ist es dabei, Fachleuten aus den Spezialgebieten Softwaredesign und Softwareentwicklung eine effektivere Zusammenarbeit zu ermöglichen.

Windows Presentation Foundation und andere Microsoft-Technologien

Wie die anderen Komponenten von .NET Framework 3.0 beeinflusst auch WPF die bestehenden Microsoft-Technologien. Davon betroffen sind vor allem die folgenden Komponenten:

  • Windows Forms: Das ursprünglich von .NET Framework für die Erstellung von Anwendungs-GUIs bereitgestellte Tool Windows Forms wird heute in vielen Anwendungen verwendet. Aus diesem Grund ist es möglich, Windows Forms-Steuerungen in WPF-Anwendungen einzubinden und WPF-Steuerungen in Windows Forms-Anwendungen. Beispielsweise könnte eine Windows Forms-Anwendung eine WPF-Steuerung für die Anzeige dreidimensionaler Daten einbinden. Die Erstellung von Anwendungen, die beide Technologien verwenden, ist ebenfalls möglich, unterliegt jedoch bestimmten Einschränkungen. Beachten Sie in diesem Zusammenhang, dass bestehende Windows Forms-Anwendungen in einer .NET Framework 3.0-Umgebung weiter unverändert arbeiten.

  • Win32 und Microsoft Foundation Classes (MFC): Ähnlich wie bei Windows Forms ist es auch in diesem Fall möglich, WPF-Steuerungen in bestehende Anwendungen einzubinden. Die Interoperabilität gestaltet sich allerdings etwas schwieriger als bei Windows Forms, da Win32-basierte und MFC-basierte Anwendungen im Gegensatz zu Windows Forms nicht auf der Grundlage der CLR erstellt sind. Die Interoperabilität mit WPF erfordert daher auch die Zuordnung von CLR-basiertem Code zu systemeigenen Win32-Code.

  • Direct3D: Direct3D gehört zur API-Familie DirectX und ermöglicht es Anwendungen, 3D-Grafiken zu erstellen und anzuzeigen. Mit der Einführung von .NET Framework 3.0 können gängige Windows-Anwendungen die 3D-Funktionen von WPF anstelle der stärker spezialisierten Methode von Direct3D verwenden. Jedoch werden einige Anwendungen, die Hochleistungsfunktionen benötigen, beispielsweise für 3D-Spiele, weiter auf Direct3D zurückgreifen. Auch WPF verwendet daher intern Direct3D für alle Darstellungsvorgänge.

  • Windows Communication Foundation: Wie aus dem weiter oben beschriebenen Szenario ersichtlich ist, können WPF-Anwendungen WCF verwenden. XBAPs können WCF jedoch in der Regel nicht verwenden, da WCF volle Vertrauenswürdigkeit erfordert. Jede aus dem Internet heruntergeladene XBAP wird in einer teilweise vertrauenswürdigen Sandbox ausgeführt, weshalb ihr der Zugriff auf WCF verwehrt bleibt. XBAPs können aber ASP.NET Web Services verwenden und so SOAP-Aufrufe ausführen, die mit WCF und anderen Webdienstimplementierungen interoperieren.

  • "WPF/E": Eine weitere Komponente von WPF sollte an dieser Stelle noch erwähnt werden, obwohl sie nicht Teil von .NET Framework 3.0 ist. Ihr Codename lautet "WPF/E", und ihr Ziel ist es, Benutzeroberflächen im WPF-Stil in Systemen zu unterstützen, die WPF selbst nicht unterstützen. Das "E" im Namen steht für "Everywhere", da diese Technologie überall verfügbar sein soll, einschließlich Macintosh, kleiner Geräte und anderer Systeme. WPF/E wird eine Untergruppe der WPF-Funktionen enthalten, darunter Funktionen für 2D-Grafiken, Animation und Videowiedergabe, und voraussichtlich kurze Zeit nach der Freigabe von WPF erhältlich sein.

Verwenden von .NET Framework 3.0: Verteilungsoptionen

Damit eine Anwendung .NET Framework 3.0 verwenden kann, muss diese Version von Framework auf den Computern installiert sein, auf denen die Anwendung ausgeführt wird. Für Windows Vista wird .NET Framework 3.0 standardmäßig installiert. Das bedeutet, dass neue Computer, auf denen Windows Vista installiert ist, oder bestehende Computer, die auf Vista aktualisieren, automatisch .NET Framework 3.0-Anwendungen ausführen können. .NET Framework 3.0 kann jedoch auch unter Windows XP und Windows Server 2003 ausgeführt werden. Um die .NET Framework 3.0-Komponenten bestehenden Benutzern dieser Systeme verfügbar zu machen, wird Microsoft die Software zum kostenlosen Download bereitstellen.

Schlussbemerkung

.NET Framework 3.0 ist die Weiterentwicklung des Windows-Programmiermodells. Die Version 3.0 baut auf der Version 2.0 von .NET Framework auf und erweitert sie, um die Erstellung moderner Anwendungen zu ermöglichen. Zu diesem Zweck bietet die Version 3.0 ein diversifiziertes Paket verschiedener Technologien an, von denen jede auf eine andere Problemstellung der Anwendungsentwicklung abgestimmt ist. Indem Microsoft diese vielfältigen Technologien auf einer gemeinsamen Grundlage entwickelt, soll ein Zusatznutzen geschaffen werden, der über die Summe der Leistungsmerkmale der einzelnen Komponenten hinausgeht. Dabei wird es Entwicklern ermöglicht, Anwendungen zu erstellen, die die verschiedenen Bestandteile von .NET Framework 3.0 auf kohärente Weise verwenden.

Ganz gleich, welche Funktionen dieser neuen Version von einem Unternehmen eingesetzt werden, die Technologie wird seine Windows-Software revolutionieren. Entwickler, Softwarearchitekten und Entscheidungsträger, deren Arbeitsgebiet von dieser Neuerung betroffen ist, sollten sich umgehend näher mit den Vorteilen von .NET Framework 3.0 beschäftigen.

Weiterführende Literatur

Understanding .NET, Zweite Ausgabe. David Chappell, Addison-Wesley, 2006

Introducing Windows Workflow Foundation (in englischer Sprache)

Introducing Windows Communication Foundation (in englischer Sprache)

Introducing InfoCard (Windows CardSpace) (in englischer Sprache)

Introducing Windows Presentation Foundation: (demnächst verfügbar)

Der Autor

David Chappell ist Principal der Chappell & Associates (www.davidchappell.com) in San Francisco, Kalifornien. Mit der von ihm verfassten Fachliteratur und seinen Beratungsdiensten hilft er IT-Fachkräften auf der ganzen Welt dabei, Unternehmenssoftware zu verstehen und zu verwenden und unterstützt sie bei der Entscheidungsfindung.


Anzeigen:
© 2014 Microsoft