Anwendungsarchitektur für.net: Entwerfen von Anwendungen und Diensten

Transkript

1 Anwendungsarchitektur für.net: Entwerfen von Anwendungen und Diensten Einführung Anwendungsarchitektur für.net: Entwerfen von Anwendungen und Diensten bietet Anwendungsarchitekten und -entwicklern, die verteilte Lösungen mit Microsoft.NET Framework erstellen, Anleitungen für die Architektur- und Entwurfsebenen. Sie sollten dieses Handbuch lesen, wenn Sie: Architektur auf hoher Ebene für Anwendungen oder Dienste entwerfen. Passende Technologien und Produkte für spezielle Aspekte Ihrer Anwendung oder Ihres Dienstes empfehlen. Entwurfsentscheidungen treffen, um funktionelle und nicht funktionelle (Betriebs- )Anforderungen zu erfüllen. Passende Kommunikationsmethoden für Ihre Anwendung oder Ihren Dienst auswählen. Dieses Handbuch erklärt Ihnen die wichtigsten Entwurfsentscheidungen, die Sie in der anfänglichen Entwicklungsphase treffen müssen und bietet Ihnen Anleitungen für die Entwurfsebenen, um Ihnen bei der Wahl zwischen verschiedenen Entwurfsoptionen zu helfen. Mit diesem Handbuch können Sie durch eine konsistente, aus verschiedenen Komponententypen bestehende Architektur, die Ihnen einen gut durchdachten Entwurf und eine optimale Nutzung der Vorteile der Microsoft-Plattform ermöglicht, ein Gesamtdesign entwerfen. Obwohl dieses Handbuch keine Anleitungen auf Implementierungsebene für jeden Aspekt der Anwendung enthält, finden Sie darin jedoch Verweise auf bestimmte Microsoft Patterns & Practices-Handbücher, MSDN-Artikel und Communitysites, in denen die verschiedenen Aspekte für das Entwerfen von verteilten Anwendungen besprochen werden. Betrachten Sie dieses Handbuch als Wegweiser für die wichtigsten Entwurfsprobleme bei verteilten Anwendungen, auf die Sie bei einer Verwendung der Microsoft-Plattform stoßen werden. Dieses Handbuch konzentriert sich auf verteilte Anwendungen und Web Services, die möglicherweise Integrationsfunktionen für mehrere Datenquellen und Dienste

2 bereitstellen müssen und eine Benutzeroberfläche für ein oder mehrere Geräte benötigen. Es wird davon ausgegangen, dass Sie mit der Entwicklung von.net-komponenten und den grundlegenden Prinzipien für das Entwerfen von verteilten Anwendungen mit verschiedenen Schichten vertraut sind. Inhalt des Wegweisers Dieses Handbuch enthält fünf Kapitel: Kapitel 1, "Einführung", erklärt den Zusammenhang zwischen Anwendungen und Diensten. Kapitel 2, "Entwerfen der Komponenten einer Anwendung oder eines Dienstes", führt Sie schrittweise durch die Architektur und erklärt Ihnen dabei die Rollen und Entwurfskriterien jeder Komponentenschicht. Kapitel 3, "Richtlinien für Sicherheit, Betriebsverwaltung und Kommunikation", erklärt Entwurfsprobleme, die für die gesamte Anwendung gelten, wie beispielsweise Ausnahmeverwaltung und Autorisierung. Kapitel 4, "Physische Bereitstellung und Betriebsanforderungen", zeigt Ihnen, wie sich der Anwendungsentwurf auf die Bereitstellung und die Verwaltung von Änderungen auswirkt, Darüber hinaus erklärt es die in gut durchdachten Lösungen verwendeten allgemeinen Bereitstellungsmuster. Kapitel 5, "Anhänge", enthält Abbildungen sowie ein Glossar mit in diesem Handbuch verwendeten Termini. Diese Kapitel sollten zwar am besten der Reihe nach gelesen werden, aber jedes Kapitel enthält Informationen, die auch unabhängig von den anderen Kapiteln hilfreich sein können. Inhalt dieses Kapitels Dieses Kapitel enthält folgende Abschnitte: Ziele beim Entwerfen von verteilten Anwendungen Dienste und Dienstintegration Komponenten und Ebenen in Anwendungen und Diensten

3 Ein Beispielszenario Ziele beim Entwerfen von verteilten Anwendungen Beim Entwerfen einer verteilten Anwendung müssen Sie Entscheidungen hinsichtlich der logischen und physischen Architektur sowie der zur Implementierung der Funktionen einzusetzenden Technologien und Infrastruktur treffen. Um diese Entscheidungen effektiv treffen zu können, müssen Sie die Geschäftsprozesse, die die Anwendung durchführen soll (ihre funktionellen Anforderungen), sowie das erforderliche Maß an Skalierbarkeit, Verfügbarkeit, Sicherheit und Wartbarkeit der Anwendung (ihre nicht funktionellen bzw. betrieblichen Anforderungen) gut kennen. Ihr Ziel ist es, eine Anwendung zu entwerfen, die: Das Geschäftsproblem löst, für das sie konzipiert ist. Sicherheitsfragen von Anfang an berücksichtigt und dabei auf die entsprechenden Authentifizierungsmechanismen, die Autorisierungslogik und eine sichere Kommunikation achtet. Hohe Leistung bietet und für allgemeine Operationen in verschiedenen Bereitstellungsmustern optimiert ist. Verfügbar und widerstandsfähig ist und in redundanten Datenzentren mit hoher Verfügbarkeit eingesetzt werden kann. Sich an die erwarteten Anforderungen anpassen lässt und eine Vielzahl von Aktivitäten und Benutzern bei minimaler Ressourcenbeanspruchung unterstützt. Sich verwalten lässt und es Operatoren ermöglicht, die Anwendung entsprechend dem Szenario bereitzustellen, zu überwachen und Fehler darin zu beheben. Wartungsfreundlich ist. Jeder Funktionsteil sollte an einem logischen Ort zu finden und so entworfen sein, dass unterschiedliche Anwendungsgrößen, Teams mit verschiedenen Fähigkeiten sowie sich ändernde geschäftliche und technische Anforderungen berücksichtigt werden. In verschiedenen Anwendungsszenarios und Bereitstellungsmustern arbeitet. Jedes dieser Ziele wird in den Entwurfsanleitungen der nachfolgenden Kapitel behandelt. Darüber hinaus werden die Gründe für bestimmte

4 Entwurfsentscheidungen erläutert, wenn ein entsprechendes Hintergrundwissen erforderlich ist. Dienste und Dienstintegration Das Wachstum des Internets und der zugehörigen Technologien sowie das Bestreben von Organisationen, ihre Systeme über Abteilungs- und Organisationsgrenzen hinweg zu integrieren, hat zu einem dienstbasierten Ansatz bei der Entwicklung von Lösungen geführt. Aus der Sicht des Verbrauchers ähneln Dienste vom Konzept her herkömmlichen Komponenten, außer dass Dienste ihre eigenen Daten beinhalten und genau genommen nicht Teil Ihrer Anwendung sind, sondern von dieser lediglich verwendet werden. Anwendungen und Dienste, die integriert werden müssen, sind möglicherweise auf verschiedenen Plattformen, von unterschiedlichen Teams und nach unterschiedlichen Zeitplänen erstellt worden und werden unter Umständen unabhängig voneinander gewartet und aktualisiert. Es ist daher entscheidend, dass Sie eine Kommunikation mit einer möglichst geringen Kopplung implementieren. Wir empfehlen Ihnen, für die Kommunikation zwischen Diensten nachrichtenbasierte Techniken einzusetzen, um ein hohes Maß an Zuverlässigkeit und Skalierbarkeit zu gewährleisten. Sie können Nachrichtenkommunikation explizit implementieren (beispielsweise durch das Schreiben von Code für das Senden und Empfangen von Message Queuing-Nachrichten) oder Infrastrukturkomponenten verwenden, die die Kommunikation für Sie implizit verwalten (zum Beispiel, indem Sie einen von Microsoft Visual Studio.NET erstellten Web Service-Proxy einsetzen). Anmerkung: Der Ausdruck Dienst bzw. Service wird in diesem Handbuch für jede externe Softwarekomponente verwendet, die Geschäftsdienste anbietet. Dies umfasst auch (ist aber nicht begrenzt auf) XML Web Services. Dienste stellen eine Dienstschnittstelle bereit, an die alle eingehenden Nachrichten gesendet werden. Unter einem Vertrag versteht man eine Gruppe von Nachrichten, die mit einem Dienst ausgetauscht werden müssen, damit dieser eine bestimmte Geschäftsaufgabe ausführt. Sie können sich eine Dienstschnittstelle als Fassade

5 vorstellen, die potenziellen Kunden die im Dienst implementierte Geschäftslogik bereitstellt. Beispiel hierfür wäre eine Verkaufsanwendung, über die Kunden Produkte bestellen. Die Anwendung nutzt einen externen Kreditkarten-Autorisierungsdienst, um die Kreditkarteninformationen des Kunden zu überprüfen und den Verkauf zu autorisieren. Nachdem die Kreditkartenangaben überprüft wurden, wird die Lieferung der Ware über einen Kurierdienst organisiert. Das folgende Sequenzdiagramm (Abbildung 1.1) stellt dieses Szenario dar. Abbildung 1.1 Ein mithilfe von Diensten implementierter Geschäftsprozess Bei diesem Szenario sind der Kreditkarten-Autorisierungsdienst und der Kurierdienst an dem Geschäftsprozess des Warenerwerbs beteiligt. Im Gegensatz zu herkömmlichen Komponenten residieren Dienste innerhalb ihrer eigenen Vertrauensgrenzen und verwalten ihre eigenen Daten und zwar außerhalb der Anwendung. Sie müssen daher sicherstellen, dass die Verbindung zwischen der aufrufenden Anwendung und dem Dienst sicher und authentifiziert ist, wenn Sie bei der Anwendungsentwicklung auf einen dienstbasierten Ansatz zurückgreifen. Darüber hinaus könnten Sie auch eine nachrichtenbasierte Kommunikationsmethode implementieren. Damit eignet sich Ihr Entwurf besser für das Beschreiben von Geschäftsprozessen (auch als Geschäftstransaktionen oder langwierige Transaktionen bezeichnet). Des Weiteren ist er auch für das lose Koppeln von Systemen, wie sie häufig in großen, verteilten Lösungen zu finden sind insbesondere, wenn der Geschäftsprozess mehrere Organisationen und verschiedene Plattformen umfasst geeignet. Wenn bei dem in Abbildung 1.1 dargestellten Prozess beispielsweise nachrichtenbasierte Kommunikationsmethoden eingesetzt werden, kann der

6 Benutzer die Auftragsbestätigung Sekunden oder Stunden nach den Verkaufsinformationen erhalten. Das hängt davon ab, wie schnell die Autorisierungsund Lieferdienste reagieren. Durch nachrichtenbasierte Kommunikation können Sie Ihre Geschäftslogik unabhängig von dem zugrunde liegenden Transportprotokoll entwerfen, das zwischen den Diensten verwendet wird. Wenn Ihre Anwendung einen externen Dienst nutzt, wirkt sich die interne Implementierung des Dienstes nicht auf Ihren Entwurf aus, solange der Dienst die von ihm erwartete Funktion erfüllt. Sie müssen lediglich die Geschäftsfunktionen des Dienstes sowie die Details des einzuhaltenden Vertrages kennen (wie zum Beispiel Kommunikationsformat, Datenschema, Authentifizierungsmechanismus usw.), um mit dem Dienst kommunizieren zu können. Im Beispiel der Verkaufsanwendung bietet der Kreditkarten-Autorisierungsdienst eine Schnittstelle an, über die die Verkaufs- und Kreditkarteninformationen an den Dienst sowie eine Antwort, ob der Verkauf genehmigt wird, übermittelt werden können. Aus der Sicht des Entwicklers der Verkaufsanwendung ist es unwichtig, was innerhalb des Kreditkarten- Autorisierungdienstes geschieht. Er muss lediglich festlegen, welche Daten an den Dienst gesendet werden müssen, welche Antworten vom Dienst empfangen werden und wie die Kommunikation mit dem Dienst erfolgt. Intern betrachtet enthalten Dienste viele gleichartige Komponenten wie herkömmliche Anwendungen. (Der weitere Teil dieses Handbuchs befasst sich mit den verschiedenen Komponenten und ihren Rollen im Anwendungsentwurf.) Dienste verfügen über logische Komponenten, die die auszuführenden Geschäftsaufgaben orchestrieren, über Geschäftskomponenten, die die eigentliche Geschäftslogik des Dienstes implementieren, sowie über Datenzugriffskomponenten, die auf den Datenspeicher des Dienstes zugreifen. Sie stellen ihre Funktionen über Dienstschnittstellen zur Verfügung, die die Semantik für die Bereitstellung der zugrunde liegenden Geschäftslogik übernehmen. Ihre Anwendung ruft über Dienst- Agenten auch andere Dienste auf, die im Auftrag der aufrufenden Clientanwendung mit dem Dienst kommunizieren. Obwohl nachrichtenbasierte Dienste so entworfen werden können, dass sie synchron aufgerufen werden, kann es sich als vorteilhaft erweisen, asynchrone Dienstschnittstellen zu erstellen, die einen etwas loser gekoppelten Ansatz bei der Entwicklung einer verteilten Anwendung ermöglichen. Die von asynchroner

7 Kommunikation unterstützte lose Kopplung erlaubt es, skalierbare und langlebige Lösungen mit hoher Verfügbarkeit zu erstellen, die aus vorhandenen Diensten zusammengesetzt sind. Ein asynchroner Entwurf bringt allerdings auch andere Anforderungen mit sich: Wenn Sie die asynchrone Kommunikation einsetzen, müssen Sie bei Ihrem Entwurf möglicherweise besondere Aspekte in Betracht ziehen, wie Nachrichtenkorrelation, die Verwaltung vollständiger Datenparallelität, Geschäftsprozesskompensation und die Nichtverfügbarkeit von externen Diensten. Anmerkung: In Kapitel 3, "Richtlinien für Sicherheit, Betriebsverwaltung und Kommunikation", werden die bei der Implementierung von Dienstkommunikation auftretenden Probleme detailliert erläutert. Weitere Informationen zu Diensten und verwandten Konzepten finden Sie unter "Application Conceptual View" (in Englisch) auf der MSDN-Website ( Komponenten und Ebenen in Anwendungen und Diensten Es ist zu einem weit verbreiteten und allgemein anerkannten Grundsatz geworden, dass man beim Entwurf einer verteilten Anwendung diese in Komponenten aufteilen sollte, die Darstellungs-, Geschäfts- und Datendienste bieten. Komponenten mit ähnlichen Funktionen können in Schichten gruppiert werden, die in vielen Fällen aneinander gereiht werden, sodass Komponenten "oberhalb" einer bestimmten Schicht die von dieser zur Verfügung gestellten Dienste nutzen und jede Komponente zur Ausführung ihrer Aufgaben die von anderen Komponenten auf ihrer Ebene oder auf "darunter" befindlichen Ebenen angebotenen Funktionen verwendet. Anmerkung: Der Begriff Schicht wird in diesem Handbuch verwendet, wenn es sich um einen Komponententyp handelt und der Begriff Ebene, wenn es um physische Verteilungsmuster geht.

8 Diese partitionierte Darstellung einer Anwendung lässt sich auch auf Dienste übertragen. Von einer hohen Ebene aus kann eine dienstbasierte Lösung so aussehen, als bestünde sie aus mehreren Diensten, die durch den Austausch von Nachrichten miteinander kommunizierten. Vom Konzept her können Dienste als Komponenten der Gesamtlösung betrachtet werden. Intern jedoch besteht jeder Dienst, wie jede andere Anwendung, aus Softwarekomponenten. Diese Komponenten können logisch in Darstellungs-, Geschäfts- und Datendienste gruppiert werden, wie in Abbildung 1.2 dargestellt. Abbildung 1.2 Eine dienstbasierte Lösung Bei dieser Abbildung sind folgende wichtige Punkte zu beachten: 1. Dienste werden normalerweise so entwickelt, dass sie mit einer möglichst geringen Kopplung miteinander kommunizieren. Der Einsatz nachrichtenbasierter Kommunikation hilft dabei, die Verfügbarkeit und Skalierbarkeit der Dienste abzukoppeln. Wenn Sie Industriestandards wie XML Web Services verwenden, können Sie die Dienste mit anderen Plattformen und Technologien integrieren. 2. Jeder Dienst besteht aus einer Anwendung mit eigenen Datenquellen, Geschäftslogik und Benutzeroberflächen. Ein Dienst kann intern einem

9 herkömmlichen Anwendungsentwurf mit drei Ebenen gleichen, wie beispielsweise die Dienste (2) und (4) in der obigen Abbildung. 3. Sie können einen Dienst erstellen und bereitstellen, dem keine Benutzeroberfläche direkt zugeordnet ist (ein Dienst, der über eine programmtechnische Schnittstelle von anderen Anwendungen aufgerufen wird). Dies zeigt Dienst (3). Beachten Sie, dass die Komponenten, aus denen ein Dienst besteht und die Komponenten, die die Geschäftsschichten einer Anwendung bilden, ähnlich entworfen sein können. 4. Jeder Dienst enthält seine eigenen Daten und verwaltet atomare Transaktionen mit seinen eigenen Datenquellen. Es ist wichtig zu verstehen, dass es sich bei den Schichten lediglich um logische Gruppierungen der Softwarekomponenten handelt, aus denen die Anwendung oder der Dienst besteht. Die Schichten helfen dabei, zwischen den verschiedenen Aufgabenarten zu unterscheiden, die von den Komponenten ausgeführt werden und erleichtern es Ihnen somit, die Lösung wieder verwendbar zu gestalten. Jede logische Schicht enthält mehrere in Unterschichten gruppierte Komponententypen, wobei jede Unterschicht eine bestimmte Aufgabenart ausführt. Durch Identifizieren der generischen Arten von Komponenten, die in den meisten Lösungen zu finden sind, können Sie eine aussagekräftige Übersichtskarte einer Anwendung oder eines Dienstes erstellen und diese dann als Blaupause für Ihren eigenen Entwurf verwenden. Die Abbildung 1.3 zeigt eine vereinfachte Darstellung einer Anwendung und ihrer Schichten.

10 Abbildung 1.3 Gemäß ihrer Rollen in Schichten aufgeteilte Komponenten Eine verteilte Anwendung muss unter Umständen mehrere Organisationen oder physische Ebenen umspannen. In diesem Fall besitzt sie eigene Richtlinien hinsichtlich der Anwendungssicherheit, Betriebsverwaltung und Kommunikation. Diese Vertrauenseinheiten oder Zonen können eine physische Ebene, ein Datenzentrum bzw. eine Abteilung, ein Bereich oder ein Unternehmen sein, in der/dem derartige Richtlinien festgelegt wurden. Diese Richtlinien geben zusammen Regeln für die Umgebung vor, in der die Anwendung bereitgestellt wird und bestimmen, wie die Dienste und Anwendungsebenen kommunizieren. Sie gelten für die gesamte Anwendung und ihre Implementierungsweise wirkt sich auf die Entwurfsentscheidungen für jede Ebene aus. Die Richtlinien beeinflussen sich auch gegenseitig (die Sicherheitsrichtlinie kann beispielsweise einige Regeln der Kommunikationsrichtlinie festschreiben, und umgekehrt). Anmerkung: Weitere Informationen zum Entwerfen von Sicherheits-, Betriebsverwaltungs- und Kommunikationsrichtlinien finden Sie in Kapitel 3, "Richtlinien für Sicherheit, Betriebsverwaltung und Kommunikation". Ein Beispielszenario

11 Dieses Handbuch enthält Beschreibungen einer Beispielanwendung, die externe Dienste verwendet, um Ihnen dabei zu helfen, allgemeine Komponententypen zu identifizieren. Obwohl sich dieses Handbuch auf ein bestimmtes Beispiel konzentriert, gelten die Entwurfsempfehlungen, ungeachtet des konkreten Geschäftsszenarios, für die meisten verteilten Anwendungen. Das verwendete Beispielszenario ist eine Fortsetzung der weiter vorne in diesem Kapitel beschriebenen Verkaufsanwendung. Bei diesem Szenario bietet ein Einzelhandelsunternehmen seinen Kunden die Möglichkeit, Produkte entweder über eine E-Commerce-Website oder per Telefon zu bestellen. Internetbenutzer können die Website des Unternehmens besuchen und dort die Produkte aus einem Onlinekatalog auswählen. Alternativ dazu haben Kunden aber auch die Möglichkeit, Produkte aus einem Versandkatalog telefonisch bei einem Vertriebsmitarbeiter zu bestellen, der die Bestelldetails über eine Microsoft Windows-basierte Anwendung eingibt. Nachdem eine Bestellung fertig gestellt ist, werden die Kreditkarteninformationen des Kunden über einen externen Kreditkarten- Autorisierungsdienst autorisiert und die Lieferung wird mit einem externen Kurierdienst arrangiert. Wir schlagen für dieses Szenario eine komponentenbasierte Entwurfslösung wie in Abbildung 1.4 vor, die aus mehreren Komponenten besteht.

12 Abbildung 1.4 Die Verkaufsanwendung als eine Gruppe von Komponenten und zugehörigen Diensten Die Verkaufsanwendung in Abbildung 1.4 besteht aus mehreren Softwarekomponenten, die gemäß ihrer Funktionen in logische Ebenen gruppiert wurden. Beachten Sie, dass die Kreditkartenautorisierung und der Kurierdienst vom Standpunkt der Verkaufsanwendung aus gesehen externe Komponenten sind. Diese Dienste werden intern jedoch fast wie gewöhnliche Anwendungen implementiert und enthalten dieselben Komponententypen (die Dienste in diesem Szenario verfügen zwar über keine Darstellungsebene, stellen Ihre Funktionen jedoch über eine programmtechnische Dienstschnittstelle bereit). Der nächste Schritt Dieses Kapitel hat Sie mit den dienstbasierten Lösungen bekannt gemacht und Ihnen erklärt, dass ein Dienst, wie jede andere Anwendung, aus mehreren Softwarekomponenten besteht, die in logischen Ebenen gruppiert werden können. Die Komponenten, aus denen eine Anwendung oder ein Dienst besteht, können mit generischen Begriffen beschrieben werden. Ein Verständnis der verschiedenen

13 Komponententypen, die für gewöhnlich in verteilten Anwendungen verwendet werden, hilft Ihnen beim Entwerfen besser durchdachter Lösungen. In Kapitel 2, "Entwerfen der Komponenten einer Anwendung oder eines Dienstes", werden die allgemeinen Komponententypen beschrieben und Empfehlungen dazu gegeben, wie Sie diese am besten entwerfen. Feedback und Support Fragen? Kommentare? Vorschläge? Wenn Sie uns Feedback zu diesem Handbuch schicken möchten, senden Sie bitte eine an (in Englisch) Microsoft Corporation. Alle Rechte vorbehalten. Rechtliche Hinweise.