Goal:

• Monitoring configuration, including WF tracking and System.Diagnostics tracing
• SQL WF persistence, and WF host settings
• Auto-start of applications and services
• Service throttling
• Service certificate
• Endpoint addresses
• Endpoint transport quotas
• Start/Stop of WCF and WF applications and service instances

AppFabric Tools:

Much of the AppFabric management experience resides inside of IIS Manager in order to deploy and manage WAS-hosted services. ASP.NET applications are already configured via IIS Manager, and hence, adding the AppFabric configuration experience helps provide a seamless Web service configuration environment in IIS Manager. We also provide a rich scripting experience for all UI configuration via PowerShell cmdlets. So, most of the settings supported in AppFabric management UI can also be changed using PowerShell, giving you the ability to script post-deployment configuration. Most of the application/service configuration experience we introduced in IIS Manager can be found in a single configuration dialog available at all IIS scopes:

• Server, site, application, virtual directory scopes: select a server, site, application, or virtual directory in IIS Manager’s navigation pane, and select Configure under the .NET 4 WCF and WF section of the context menu
• Service scope: open the new Services feature under the Application Server Extensions for .NET 4 area in the central pane, select a service in the list, and choose Configure in the context menu

Figure 1: Configuration dialog at the application scope

Tabs used in the configuration UI provide configuration options for various sections, which gives you a single dialog/UI to edit all configuration from. All of these tabs are context-sensitive, i.e., depending on the scope, they vary slightly. For example: you can only enable Auto-start (Availability tab) at the application or the service scope.

Defaults:

What does it really mean to configure at all of these scopes? The WCF and WF service project templates in Visual Studio 2010 make use of a new simplification of the configuration system in NET 4: The <service> tag can be omitted in the configuration, in which case, services use certain defaults, including a default service behavior. That default service behavior is by convention the service behavior that has no name (the name attribute is omitted or set to an empty string), aka a “nameless behavior”. It turns out that many of the settings we have chosen to tool are in fact service behaviors. So when we offer the ability to edit a setting in a service behavior at the service scope (ex: service throttling), we edit whichever behavior the service is using, named or nameless. But at the virtual directory, application, site, and server scopes, when editing that same setting, we will in fact edit a nameless service behavior at that scope. Now, in the realm of service behaviors merging like regular collections in .NET 4, what this really means is that you can manage an inheritance chain of “default” settings that will apply to your services. For example, you could define a default SQL WF Persistence store at the server scope. That setting will apply to all WF services on your server that use the default service behavior. And this setting could be modified for specific sites on your server, or even disabled for certain 3d applications or services.

Details worth noting

This default story in AppFabric configuration has one consequence though. If your service is still using the “old configuration” standard of <service> tag and named (i.e., non-default) service behavior, this entire hierarchy of configuration that you set up with the dialog will not apply to the service. We offer a way to opt-into this new world, with the “Use Defaults” button in the configuration dialog’s general tab at the service scope. Additionally, the monitoring settings defined at the application, site, or server scope will actually apply to all of your services. This is because the monitoring configuration in general is not service behavior based. Note that out of all the monitoring settings, only WF tracking is defined in a service behavior. Additional information to keep in mind during configuration:

• Auto-start requires a three-level configuration:
• The application pool needs to be enabled for auto-start (this can be done in the Availability tab at the application scope).
• Then the application itself needs to be enabled as well.
• Finally, if the auto-start mode of the application is set to custom, individual services also need to opt-in (i.e., auto-start needs to be enabled on individual services using the Availability tab at the service scope).
• If any piece in this chain is missing, auto-start will not be enabled.
• The Net.pipe protocol needs to be enabled in order for WF instance control to be operational. This is why in AppFabric Beta1, we provide warnings if we detect that this protocol is not enabled. Moving forward, in the next release of the Beta, we will assist you by additionally attempting to add Net.pipe to the list of protocols enabled on the application if you try to enable WF instance control at the application or service scope.

In conclusion, the Windows Server AppFabric leverages  the new configuration features introduced in .NET 4 to provide a rich tooling experience in IIS Manager and via PowerShell for the configuration settings that application owners are most likely to change.