Konfigurationsvorgang in Windows Server AppFabric

Die AppFabric-Erweiterungen für IIS Manager und die Windows PowerShell-Cmdlets für AppFabric stellen geradlinige Verfahren für Anwendungsbesitzer oder IT-Fachleute zum Konfigurieren von Webanwendungen zur Verfügung, die auf WCF- oder WF-Diensten basieren. In diesem Thema wird beschrieben, was in Web.config-Dateien beim Konfigurieren eines Diensts oder einer Webanwendung in den Erweiterungen von IIS-Manager oder mithilfe der AppFabric-Konfigurations-Cmdlets geschieht. Zuerst werden die Web.config-Dateien beschrieben, die beim Konfigurieren eines Diensts verwendet werden. Anschließend werden die direkte Konfiguration eines Diensts und schließlich die Konfiguration der Standardwerte behandelt, die ein Dienst erben soll.

Weitere Informationen zur Verwendung von Web.config-Dateien in ASP.NET finden Sie unter ASP.NET-Konfiguration.

Die Hierarchie der „Web.config“-Dateien

Jedes der Elemente in der IIS-Konfigurationshierarchie kann eine eigene Web.config-Datei besitzen, und ein Dienst kann Konfigurationsstandardeinstellungen von Web.config-Dateien erben, die einem Server, einer Website, einer Webanwendung und einem Unterverzeichnis zugeordnet sind, zu denen ein Dienst gehört. Aus diesem Grund ist die Konfiguration eines Diensts durch eine Hierarchie von Web.config-Dateien definiert. In diesem Abschnitt werden die Regeln beschrieben, die festlegen, welche Web.config-Dateien in der Hierarchie die Konfiguration eines Diensts definieren, und welche Elemente in diesen Dateien Vorrang besitzen.

Wenn AppFabric auf einem Server installiert wird, wird eine Web.config-Serverdatei (wenn nicht bereits vorhanden) im gleichen Verzeichnis wie die Datei Machine.config erstellt (<Laufwerk>:\Windows\Microsoft.NET\Framework\v4.0.xxxxx\Config). Die Konfiguration in dieser Web.config-Serverdatei ermöglicht Dienstnachverfolgung, Workflowpersistenz und Workflowinstanzverwaltung. Es kann auch eine Web.config-Datei für eine Website im Websiteverzeichnis (<Laufwerk>:\inetpub\wwwroot), für eine Webanwendung im Anwendungsstammverzeichnis und für ein Anwendungsunterverzeichnis vorhanden sein. Die Web.config-Dateien der Website, der Website und des Unterverzeichnisses werden nicht vom AppFabric-Setup installiert. Wenn Sie versuchen, die AppFabric-Erweiterungen für IIS-Manager zum Ändern der Konfiguration in einem Bereich zu verwenden, und in diesem Bereich ist keine Web.config-Datei vorhanden, wird die Web.config-Datei erstellt.

Die Web.config-Datei auf einer beliebigen Ebene kann Konfigurationseinstellungen enthalten, die direkt für einen Dienst gelten. Wenn Sie den Dienst jedoch direkt in der Benutzeroberfläche von IIS-Manager definieren möchten, verwenden Sie die Dienstdefinition in der Web.config-Datei der Webanwendung. Neben diesen Einstellungen können Web.config-Dateien auf der Server-, Site-, Anwendungs- und Unterverzeichnisebene Konfigurationsstandardeinstellungen enthalten, die von einem Dienst geerbt werden können. Die durch die Benutzeroberfläche der AppFabric-Erweiterungen für IIS-Manager und die Konfigurations-Cmdlets festgelegte Anwendungskonfiguration wirkt sich nur auf Web.config-Dateien und nicht auf machine.config- oder andere Dateien aus, die die Umgebungskonfiguration definieren. Eine Ausnahme dieser Regel besteht darin, dass der automatische Start für eine Webanwendung in der Datei applicationHost.config auf Serverebene definiert wird.

Eine Web.config-Datei enthält eine geschachtelte Hierarchie von XML-Tags und -Untertags mit Attributen, die die Konfigurationseinstellungen angeben. Einige Konfigurationseinstellungen für einen WCF- und WF-basierten Dienst werden im Dienstverhalten definiert. In AppFabric bearbeiten die meisten Konfigurationstools (jedoch nicht alle) Verhaltensweisen. Einige Konfigurationseinstellungen werden jedoch außerhalb des Dienstverhaltens definiert. Überwachung, Endpunktadressen und Bindungstransportkontingente für einen Dienst werden z. B. in der Web.config-Datei konfiguriert, jedoch außerhalb eines Verhaltens. Die Ereignissammlungs- und Systemdiagnosekonfiguration wird nicht in Verhaltensweisen konfiguriert. Beiden wird der Bereich auf Anwendungsebene oder einer höheren Ebene zugewiesen.

Direktes Konfigurieren eines Diensts

Sie können einen Dienst mithilfe eines benannten Dienstverhaltens in einer Web.config-Datei konfigurieren. Zu diesem Zweck geben Sie ein Tag <service> mit einem Attribut behaviorConfiguration in die Web.config-Datei ein, das auf ein Dienstverhaltentag verweist. Ein benanntes Verhalten kann für einen Dienst in einer Web.config-Datei auf Anwendungsebene oder einer höheren Ebene definiert werden. Das folgende Beispiel zeigt einen Dienst namens TestService, dessen Konfiguration in einem benannten Dienstverhalten mit dem Namen TestGetMetaData definiert ist:

<system.serviceModel>
   <services>
      <service name="TestService" behaviorConfiguration="TestGetMetaData" >
         <endpoint address="/TestService" binding="wsHttpBinding" contract="ITestService"/>
         <endpoint address="mex"  binding="mexHttpBinding"  contract="IMetadataExchange"/>
      </service>
   </services>

   <behaviors>
      <serviceBehaviors>
         <behavior name="TestGetMetaData"> <serviceMetadata httpGetEnabled="true" httpGetUrl=""/> </behavior>
      </serviceBehaviors>
   </behaviors>
</system.serviceModel>

In .NET Framework 3.5 bestand das einfachste Verfahren zum Konfigurieren zahlreicher Aspekte eines Diensts in der Verwendung eines benannten Dienstverhaltens in der Web.config-Anwendungsdatei (oder der -Unterverzeichnisdatei) des Diensts. In .NET Framework 4.0 ermöglichen die neuen -Vorlagen die Verwendung namenloser Verhalten, durch die ein Dienst eine Standardkonfiguration erbt. Weitere Informationen finden Sie weiter unten in diesem Abschnitt unter „Konfigurieren von Standardwerten, die ein Dienst erbt“.

Die AppFabric-Konfigurationstools ändern das folgende Dienstverhalten:

• sqlWorkflowInstanceStore (Persistenz)

• etwTracking (Überwachung)

• serviceThrottling (Leistung)

• serviceCredentials/serviceCertificate (Sicherheit)

• workflowIdle

• workflowUnhandledException

• 1

Konfigurieren von Standardwerten, die ein Dienst erbt

Die Verwendung eines benannten Dienstverhaltens in der Web.config-Anwendungsdatei ist nicht das einzige Verfahren zum Konfigurieren eines Diensts. Ein Dienst kann auch Konfigurationsstandardeinstellungen aus den Web.config-Dateien für den Server, die Websitedie Webanwendung und das Unterverzeichnis erben, zu denen der Dienst gehört. Einige Konfigurationsstandardeinstellungen für WCF- und WF-basierte Dienste werden in einem namenlosen Dienstverhalten definiert.

Verwenden namenloser Verhalten

Wenn ein benanntes Dienstverhalten vorhanden ist und das Attribut behaviorConfiguration darauf verweist, verwendet der Dienst die Einstellungen im benannten Verhalten. Außerdem erbt er Einstellungen aus allen anderen benannten Verhalten mit dem gleichen Namen in übergeordneten Ebenen. Er verwendet nicht die Standardeinstellungen für das Dienstverhalten, die in den Web.config-Unterverzeichnis- Anwendungs-, Website- und -Serverdateien definiert sind, die für den Dienst gelten. Sie können jedoch das Tag <service> in der Web.config-Anwendungsdatei so ändern, dass der Dienst Standardwerte erbt. Sie definieren zu diesem Zweck ein namenloses Dienstverhalten in der Web.config-Datei für eine Ebene oder mehrere Ebenen und geben an, dass der Dienst das namenlose Verhalten verwendet. Der Dienst verwendet das namenlose Verhalten, wenn der Name des Attributs behaviorConfiguration eines Dienstelements auf eine leere Zeichenfolge festgelegt ist, wie im folgenden Code gezeigt:

<services>
   <service name=”TutorialService” behaviorConfiguration=””
      <endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
   </service>
</services>

Das Auslassen des Attributs behaviorConfiguration (wie im folgenden Code gezeigt) hat den gleichen Effekt. Im Beispiel oben wird das namenlose Verhalten ausdrücklich verwendet, während es im Beispiel unten implizit verwendet wird.

<services>
   <service name=”TutorialService”
      <endpoint address=”” binding=”wsHttpBinding” contract=”IService” />
   </service>
</services>

Das namenlose Element behaviorConfiguration bewirkt, dass der Dienst seine Konfiguration von mindestens einem der namenlosen Verhalten erbt, die im Element serviceBehavior definiert sind. Das folgende namenlose Element serviceBehavior wird von der Standardeinstellung auf Serverebene definiert. Diese Standardkonfiguration für den Server (wie von AppFabric-Setup erstellt) ermöglicht Dienstnachverfolgung, Workflowpersistenz und Workflowinstanzverwaltung.

<behaviors>
   <serviceBehaviors>
      <behavior name=””>
         <workflowIdle timeToUnload="00:01:00" timeToPersist="infinite" />
         <workflowInstanceManagement authorizedWindowsGroup=”AS_Administrators" />
         <etwTracking profileName="HealthMonitoring Tracking Profile" />
      </behavior>
   </serviceBehaviors>
</behaviors>

Ein namenloses Verhalten kann in einer Web.config-Datei auf jeder Ebene in der Hierarchie definiert werden. Wenn namenloses Verhalten auf mehreren Ebenen definiert wird, die den Dienst enthalten, besteht die Konfiguration für den Dienst aus den zusammengeführten Einstellungen jedes namenlosen Verhaltens, das in seiner Hierarchie definiert ist. Wenn zwei oder mehr namenlose Verhalten in der Hierarchie eines Diensts Einstellungen enthalten, die Konflikte verursachen, wird die Einstellung auf der niedrigeren oder niedrigsten Ebene verwendet. Dieser Vorgang der Aggregation von Konfigurationseinstellungen für einen Dienst aus mehreren namenlosen Verhalten wird als Verhaltenszusammenführung bezeichnet.

Entfernungs- und Löschtags können ebenfalls in Verhaltensabschnitten in Web.config-Dateien verwendet werden. Ein Entfernungstag entfernt eine Einstellung für ein namenloses Verhalten, das es enthält. Ein Löschtag entfernt alle Verhalten für einen Dienst.

Alle Dienste, für die behaviorConfiguration auf eine leere Zeichenfolge festgelegt ist, erben Konfigurationsstandardwerte von den namenlosen Verhalten in ihrer Hierarchie. Für eine Ebene darf in einer Web.config-Datei nur ein namenloses Verhalten vorhanden sein.

Ein namenloses Verhalten wird implizit (durch Auslassen des Attributs behaviorConfiguration) für implizite Dienste (auch als „taglose Dienste“ bezeichnet) verwendet. Ein tagloser Dienst ist ein Dienst, der nicht in einer Web.config-Datei deklariert wird. Er besitzt keinen zugehörigen Dienstknoten in einer Web.config-Datei. Standardmäßig erstellen neue Projekttypen in Visual Studio 2010 taglose Dienste. Wenn das Laufzeitmodul auf einen taglosen Dienst trifft, wendet es automatisch die Standardwerte auf den Dienst an, die aus den entsprechenden namenlosen Verhalten zusammengeführt wurden. Beachten Sie, dass Sie die Endpunkte eines taglosen Diensts in den Erweiterungen von IIS-Manager nicht ändern können. Sie können zu diesem Zweck nur der Web.config-Datei ein benanntes Dienstelement hinzufügen.

Einige Konfigurationsstandardeinstellungen für WCF- und WF-basierte Dienste werden in einem namenlosen Dienstverhalten, andere außerhalb eines namenlosen Dienstverhaltens definiert. Für Verbindungszeichenfolgen oder Auflistungen erbt ein Dienst z. B. Konfigurationswerte aus allen Konfigurationsdateien in der Hierarchie.

Konfigurieren von Standardwerten in IIS-Manager

Sie können eine Anwendung direkt in den AppFabric-Erweiterungen für die Benutzeroberfläche von IIS-Manager konfigurieren. Wenn Sie auf diese Weise vorgehen, legt AppFabric das benannte Dienstverhalten in den betreffenden Web.config-Dateien fest (normalerweise auf Anwendungsebene). Sie können auch IIS-Manager zum Ändern der Dienstkonfiguration für die Verwendung von Standardwerten aus der Unterverzeichnis-, Anwendungs-, Website- und Serverebene verwenden, anstatt den Dienst direkt zu konfigurieren. When you do so, the nameless behaviors of the Web.config file are changed. AppFabric führt eine Verhaltenszusammenführung aus, um die vollständige Sammlung der Anwendungskonfigurationsparameter zu erstellen.

Wenn die gleiche Konfigurationseigenschaft in mindestens zwei Web.config-Dateien auf einen anderen Wert festgelegt ist, verwendet AppFabric den Wert aus der niedrigeren oder der niedrigsten Ebene. Die Felder des Dialogfelds Dienst konfigurieren für den Dienst werden mit Werten aus dem namenlosen Verhalten in den zugehörigen Web.config-Dateien aufgefüllt. Sie können diese Werte in der Konfigurationsbenutzeroberfläche auf der Dienstebene ändern. In diesem Fall wird das namenlose Verhalten für die entsprechende Anwendung geändert. Sie können jedoch auch die Standardwerte auf Unterverzeichnis-, Website- und Serverebene ändern. Wenn Sie eine Standardeinstellung im namenlosen Verhalten auf einer höheren Ebene ändern, nachdem das namenlose Verhalten der Anwendung erstellt wurde, wird die Änderung am namenlosen Verhalten der höheren Ebene an die Dienstebene propagiert, wenn sie nicht auf der niedrigeren Ebene außer Kraft gesetzt wird.

Wenn Sie die Standardeinstellungen für die Anwendungs-, Unterverzeichnis-, Website- oder Serverebene in IIS-Manager definieren möchten, wählen Sie die Ebene im Verbindungsbereich aus und klicken dann im Aktionsbereich unter WCF- und WF-Dienste verwalten auf Konfigurieren. Sie können auch mit der rechten Maustaste im Verbindungsbereich auf die Ebene klicken, auf WCF- und WF-Dienste verwalten zeigen und dann auf Konfigurieren klicken. Nun wird das Dialogfeld Konfiguration für die Ebene angezeigt. Wenn keine Web.config-Datei für eine Ebene vorhanden ist, wenn Sie die Standardeinstellungen für die Ebene in der Benutzeroberfläche ändern, erstellt AppFabric diese Datei.

Wenn Sie in den AppFabric-Erweiterungen für IIS-Manager einen Dienst konfigurieren, wählen Sie nicht die benannte Verhaltenskonfiguration aus, die verwendet wird. Sie geben im Dialogfeld Dienst konfigurieren Werte ein oder treffen eine Auswahl für den Dienst. AppFabric bearbeitet dann die Web.config-Datei. Sie können auch Windows PowerShell-Cmdlets für AppFabric verwenden, um viele der Verhaltenskonfigurationseinstellungen festzulegen.

Verwenden von Speicherorttags

AppFabric unterstützt Lesevorgänge für Speicherorttags in Web.config-Dateien. Ein Speicherorttag ist neben der Verwendung eines benannten Dienstverhaltens oder dem Definieren von Standardverhalten mithilfe eines namenlosen Dienstverhaltens oder eines taglosen Diensts eine andere Methode zum Definieren der Konfiguration eines Diensts. Ein Speicherorttag ist ein in eine Web.config-Datei eingebettetes Element, das Konfigurationseinstellungen auf eine Entität anwendet, die es besonders identifiziert. Ein Speicherorttag enthält mindestens eine Konfigurationseinstellung. Es enthält außerdem einen Pfad, der die Entität angibt, auf die die Konfigurationseigenschaften angewendet werden. Im Gegensatz zu einem benannten Dienstverhalten (das im Knoten <services> der entsprechenden Web.config-Anwendungsdatei enthalten sein muss) kann ein Speicherorttag in eine beliebige Web.config-Datei eingegeben werden. Im Gegensatz zu einem namenlosen Verhalten erfordert das Speicherorttag kein namenloses Element behaviorConfiguration im Knoten <service> der Web.config-Anwendungsdatei, um diese ordnungsgemäß zu rendern.

Das folgende Beispiel zeigt ein Speicherorttag in einer Web.config-Websitedatei, die eine Konfigurationseinstellung auf einen Dienst s1 in einer Webanwendung app1 anwendet:

<location path=”app1/s1.svc” overrideMode=”Allow”>
   <defaultDocument enabled=”true”>
      <files>
         <add value=”Developer.htm” />
      </files>
   </defaultDocument>
</location>

Wird kein Pfad deklariert, wird der Pfad aus der Ebene verwendet, in der das Speicherorttag definiert wird, sowie aus den darunter liegenden Ebenen bis zu allen untergeordneten Pfaden (Das Äquivalent der Angabe eines Punkts (.)). Diese Vorgehensweise in der Datei applicationHost.config führt zur Angabe der Konfiguration für die globale Ebene. Wenn das Element overrideMode im Speicherorttag auf Allow festgelegt ist, kann die im Speicherorttag festgelegte Konfiguration auf niedrigeren Ebenen der Hierarchie bearbeitet und außer Kraft gesetzt werden. Wird das Element overrideMode nicht festgelegt und sind mehrere Speicherorttags vorhanden, die verschiedene Werte für die gleiche Konfigurationseinstellung im gleichen Dienst angeben, wird eine Regelsammlung für die Priorität angewendet, um die zu verwendende Einstellung zu ermitteln.

Eine Konfigurationseinstellung, die über ein Speicherorttag auf einen Dienst angewendet wird, kann weder in den AppFabric-Erweiterungen für die Benutzeroberfläche von IIS-Manager noch durch ein AppFabric-Konfigurations-Cmdlet geändert werden. Der Inhalt eines Speicherorttags ist für die Benutzeroberfläche und Cmdlets schreibgeschützt. Wenn Sie mithilfe von IIS-Manager oder einem Cmdlet versuchen, das Speicherorttag zu ändern, gibt diese Aktion einen Fehler zurück. Wenn Sie eine durch ein Speicherorttag angewendete Einstellung ändern möchten, müssen Sie das Speicherorttag manuell in der Web.config-Datei ändern.

Wiederverwendung

Bei jedem Klicken auf Übernehmen oder OK im Dialogfeld Dienst konfigurieren in IIS-Manager und Ändern einer Web.config-Datei erfolgt eine Wiederverwendung der zugehörigen Anwendungsdomäne durch das System. Bei jedem Klicken auf Übernehmen oder OK, um Standardeinstellungen auf Unterverzeichnis-, Anwendungs-, Website- oder Serverebene einzurichten und Ändern einer Web.config-Datei erfolgt eine Wiederverwendung der Anwendungsdomänen für alle Dienste unterhalb dieses Bereichs. Es wird empfohlen, die Anzahl der Neukonfigurationsvorgänge (insbesondere auf höheren Ebenen) gering zu halten, um die Kosten der Wiederverwendung zu senken. Wenn Sie Standardwerte konfigurieren, sollten Sie folgendermaßen vorgehen: Konfigurierend er Server- und der Websitestandardwerte (in beliebiger Reihenfolge), Importieren der Webanwendungen und anschließendes Konfigurieren der darin enthaltenen Webanwendungen und Dienste. Der Grund für diese Reihenfolge besteht darin, dass das Konfigurieren von Standardwerten bewirken kann, dass die gesamte Struktur wiederverwendet wird. Führen Sie nach Möglichkeit die Konfigurationsschritte aus, bevor Webanwendungen tatsächlich ausgeführt werden, um die Kosten für die Wiederverwendung von Anwendungen zu vermeiden.

  2011-12-05