Windows Server AppFabric Beta 2 已经发布

Windows Server AppFabric Beta 2是一个包含完全功能的AppFabric版本（This build represents our “feature complete” milestone. That is, it contains all the features that we plan to ship in Windows Server AppFabric v1 by Q3 of 2010），也就是RTM的时间是在2010年的Q3，那么在.net 4/vs2010 RTM的时候这个产品还没有正式发布。这个版本提供了一个provider model.

New features and changes in Hosting and Service Management include:

· For Monitoring, now when an application is configured at the Health Monitoring level (the default level) the Event Collector aggregates the WCF Operation Completed events instead of writing the individual events to the database. The OperationCompleted event is the most common event because it is fired whenever a WCF call succeeds. The Event Collector now aggregates these events that it receives over a 10 second window. It groups the OperationCompleted events by virtual path and operation name and records one AggregateOperationCompleted event instead of the raw OperationCompleted events. You can disable the aggregation at the Health Monitoring level by changing a flag in the Event Collector’s configuration file. The Release Notes document explains how to do that.

On the Dashboard in IIS Manager you will still see the total count of completed calls. However, when you drill into the Tracked Events page you’ll see the AggregateOperationCompleted events, assuming that you’re looking at an application set to the Health Monitoring level. On this page we have added “Operation Name” and “Call Duration (ms)” columns when WCF events are shown. The individual call duration or the average duration property, depending on whether the event is raw or aggregated, is shown in the “Call Duration (ms)” column.

· Windows Server AppFabric now takes advantage of three new WCF events that are available for custom tracing—a user defined information, user defined warning, and user defined error event. There is a sample posted at http://msdn.microsoft.com/en-us/library/ee667248(VS.100).aspx that shows how to emit these events from your WCF service. In the AppFabric Dashboard in the WCF Calls section we’ve made the Errors header more general to include Service Model errors and any user defined errors that your services emit. On the Tracked Events page we show all three types of user defined events, with the name of the event that you’ve defined (suffixed with the actual event type name in parentheses) shown in the Event Type column.

· In IIS Manager we now fully support the “tagless service” feature that .NET 4 provides. This feature allows you to omit explicit service definitions in the web.config files for WCF or WF services. When there is no <service> tag the runtime makes some assumptions about your service—it applies default endpoints and the “nameless” (name=“”) behavior configuration. See http://msdn.microsoft.com/en-us/library/ee354381.aspx for more details.

The Endpoints list in IIS Manager now shows you the endpoints that are explicitly defined inside <service> tags in your web.config files and also those that are applied by the runtime. This includes the service endpoints for tagless services and the standard endpoints (like the MEX endpoint and the workflow control endpoint).
The application and service configuration modules in IIS Manager now support “behavior merge”. This .NET 4 feature merges the configuration for the nameless behavior across various scopes in the IIS tree. For example, when you install Windows Server AppFabric we create the nameless behavior at the root of your server (in the web.config file inside the .NET configuration files directory). In that behavior we enable monitoring at the Health Monitoring level. This means that any service on the machine (as long as it does not use a named behavior configuration) will get this behavior by default. If you want a particular application to use a different monitoring level you can use the configuration tools (in IIS Manager or PowerShell) to change the configuration for that application. When the tools write the configuration change into the application’s web.config file they write a local nameless behavior that contains only the different monitoring setting. At runtime the system level nameless behavior gets merged with the local one defined at the application level. The net effect is that your application gets all the system defaults + the different monitoring level.

· In .NET 4 some changes were made to how workflow persistence is configured. Some of the settings (like “Unload instances when Idle” and “Action on Unhandled Exception”) were moved from the instance provider behavior to separate host-related behaviors. The IIS Manager configuration tools have been updated accordingly. You will see that some of the settings that were under the “Workflow Persistence” tab in Beta 1 have been moved to a “Workflow Host Management” tab.

· We replaced the System Services, Persistence Databases, and Monitoring Databases modules in IIS Manager with a Configuration wizard. As before, you use the Setup wizard to select which features you want to install. The features are grouped into a “Runtime Features” category and an “Administration Tools” category. When it has finished, the Setup wizard launches the Configuration wizard, but you can also run the Configuration wizard whenever you want to change your monitoring, persistence, or cache settings.

New features in Distributed Cache include:

· We have added PowerShell cmdlets for configuring cache clusters. The commands are New-CacheCluster, Add-CacheHost, Get-CacheClusterInfo, Register-CacheHost, Remove-CacheCluster, Remove-CacheHost, and Unregister-CacheHost. These commands give you granular control of cluster deployment.

· The Cache service now throttles when it is under memory pressure. When it is in the throttling state the service will allow all “read” and “delete” requests but will reject all “write” and “update” operations. This prevents the service from engaging in excessive paging. Throttling events get logged to the Event Log and allow administrators to free available memory, add nodes to the cluster, or change the expiration or deletion policy of cached items, for example.

· The Cache service now logs information to two ETW channels. The Admin channel is enabled by default and collects all events like Start Cache Service and Stop Cache Service and any unhandled exceptions. The Operational channel is disabled by default. When it is enabled it captures all warnings from the Cache service. The Event Viewer shows the collected data under Applications and Services Logs -> Microsoft -> Windows -> Application Server – System Services.

 

msdn的文档：http://msdn.microsoft.com/en-us/library/aa139632.aspx