As I mentioned in my post last week covering the changes in WF 4 since the CTP release, I promised that I would cover the WCF changes this week. As I sit down to write this post, this will have a different feel from the prior post – where the last post dealt with telling the story of why changes were made, I apologize in advance if this one reads more like a release notes document. That being said, let’s dive in to the changes…

In the upcoming Beta 1 release of .NET 4, Windows Communication Foundation (WCF) is receiving a series of enhancements aimed at expanding its usefulness and capabilities for connecting applications together using the .NET Framework. In this post, I would like to attempt to give you a quick tour of these improvements, to help guide you through items of interest as you think about evaluating the upcoming beta of Visual Studio 2010.

Workflow Services

I’m going to start with Workflow because it is a topic that is close to my heart, and WCF Workflow Services is a primary focus for WCF 4 improvements: to provide hosting and messaging capabilities to workflow-enabled services. In Beta 1, the team has worked with the Windows Workflow Foundation (WF) team to provide new messaging activities, made adding service references easier, and added a new workflow service host to make hosting a WCF workflow service even easier in .NET 4.

• New messaging activities: With Beta 1, several messaging activities are being added to WF 4 that makes use of WCF underneath to receive and send messages. Messaging activities features include:
  • A Serialization programming model for messaging activities has been added to support both typed and untyped content for WCF code services
  • Contract settings have been moved to individual messaging activities to simplify the service modeling of complex messaging activities. In these cases, the WSDL is inferred from the contract settings on the individual messaging activities.
  • Transactions support for messaging activities that allow you to now flow transactions into workflows.
  • Correlation in WF now supports long-running conversations using protocol-based and content-based correlation. This allows you to route messages to workflow instances based on either content or protocol parameters, allowing for correlation of messages from multiple clients.
  • Durable Duplex: Beta 1 provides first-class support for long-running, two-way conversations between workflow services using the enhancements in correlation.
• Add Service Reference in WF: Add Service Reference has been augmented to support generating typed client-side activities based on the WSDL, which makes it easier to create workflows that consume other services.
• Declarative Service Authoring: To enable XAML authoring of workflows that send and receive messages, we support representing WCF constructs in XAML. In particular one can author a WCF workflow Service in XAML.
• Workflow Service Host (a subclass of WCF ServiceHostBase) provides WF programs with support for
  • Adds the WCF plumbing for messaging activities
  • Integrated configuration
  • Activation of workflows authored in XAML as well code. For workflow programs and workflow services authored in XAML, we introduced a .xamlx extension together with a corresponding registered IIS handler
  • Instance management via a system provided control endpoint, so you can start, pause and resume
  • Durable delay to allow you to put your workflows to sleep and resume later

For those who read my post last week covering the WF 4 changes, these changes plug into the changes to the out of the box activities, and this continues a story that demonstrates the complementary story of using services and processes together. The integration of WCF and WF started with .NET 3.5, as the teams started implementing extensions within each technology to take advantage of the two technologies together, and this story will get even better as the Windows application server technology extensions (codenamed ‘Dublin’) are released, which makes it even easier to host workflow services within Windows Process Activation Service (WAS) and IIS 7. As has been covered in PDC in October and will be discussed at TechEd next week, ‘Dublin’ provides a pre-built host environment that includes a database for workflow persistence and monitoring, along with management tooling built upon IIS Manager and PowerShell to allow you to manage and control WCF and WF instances.

Config Simplification

WCF Configuration simplification also receives a good number of enhancements in .NET 4 to address a common concern around getting started with WCF. This was most acutely felt by developers coming over from the ASP.NET world, where they are used to working with ASMX services.

To help reduce the complexities that .NET developers currently experience while getting simple services set up, the team has made the following investments in Beta 1:

• <service> tags not required: An explicit <service> tag is no longer required to configure a service. As a result, many deployments won’t need a “per service” configuration; instead, the service will infer a default configuration, allowing you to deploy a .svc file onto your IIS instance without the need of creating or configuring a web.config file in order for the service to be callable. This behavior should be quite analogous to the creation and deployment of ASMX files in ASP.NET.
• Default bindings and behaviors: In Beta 1, you can add behaviors to a config file without using a behavior name. Within the context of that config file, those behaviors become the default behavior, and they will be used for endpoints that don’t specify a behavior.
• Standard endpoints: With Beta 1, the team is providing reusable system-provided endpoint configurations to facilitate scenarios where similarly configured endpoints are used across many services.
• Support for .svc-less activation: When applications have many services to them, it results in an application that has a single folder with a large number of .svc files, where each .svc file is a one-line file to represent each service. The result is often a challenge in file management. As an alternative to having these .svc one-line files, WCF 4 enables you to list all of your services in a single web.config.

If we think about at deploying one or more WCF services into an activated environment (i.e., Internet Information Server (IIS) or Windows Process Activation Service (WAS)), this allows for the ability to deploy services into an environment without having to do explicit configuration. By default, WCF in .NET 4 will make assumptions for a web environment; but WCF 4 allows for these defaults to be specified at standard configuration levels available to the .NET programmer using the standard configuration options (i.e., app.config, web.config, machine.config, etc). This should make it easier for WCF services to be managed and moved between environments as the service progresses from development to production.

Messaging Improvements

WCF Beta 1 also introduces a series of messaging improvements that improve the discoverability, performance, and scalability of systems that build upon WCF.

• Service Discovery: Beta 1 adds service discovery using WS-Discovery
  • Ad-hoc discovery: Services are able to publish their own services on a local subnet using a UDP multi-cast channel that is specific to the discovery feature
  • Proxy-managed discovery: WCF also allows for the use of a WS-Discovery proxy to use discovery over a larger network or to reduce UDP multi-cast traffic
  • Interoperable with Windows Vista’s WS-Discovery support
• Router Service: With Beta 1, WCF now includes a configurable WCF-based router service that supports content-based routing and protocol bridging.
  • The new content based routing capability allows for WCF to perform message filtering based on content contained in either the SOAP headers or within the message body (using a specified XPATH). Protocol bridging in WCF 4 enables the creation of bridge system bindings; for example, you may have a WCF service that uses WS-* SOAP endpoint to communicate with business partners outside the firewall and with non-.NET systems, but to use NetNamedPipes or TCP inside the firewall to communication with your other .NET services.
  • Error handling routing is implemented to allow increased flexibility. With Beta 1, WCF 4 allows for the definition of alternative send destinations. If the routing service encounters a CommunicationException or Timeout while routing your message, it will automatically resend the message to the next destination endpoint your configured.
• Support Queues with competing consumers: In .NET 3.5, it is difficult to implement long-running processes that worked with queues without having to make extensive use of the “poison queue” – particularly when a developer wanted to have multiple processes/machines working a single queue.
  As an example, imagine a system that uses queues with WCF Workflow Services. In this example, WCF needs to be able to peek into the queue and lock the message so that it can try to dispatch it to a corresponding WF instance for work. If it is not yet possible to process the message (due to the WF instance already being locked), WCF needs to put the message back into the queue – which is problematic in .NET 3.5. In .NET 4 Beta 1, WCF 4 adds support for a “peek / lock” mechanism to the WCF MSMQ channel that now allows WCF to solve this issue.
• BLOB encoder: Beta 1 provides an encoder that is optimized for sending opaque binary content as a message. In this implementation, it’s simply a write-through wrapping encoder that takes what you give it and pushes it across the wire. While it may not be as full-featured as many might want, this was something that we needed for our internal needs, and we’re exposing it for others to use if they find it useful.

In addition to the above, the team made Serialization improvements in Beta 1 that adds extensibility around dynamic “known types” resolution to improve serialization in WCF on the wire. In .NET 3.5, the DataContractSerializer class requires developers to explicitly specify a white list of “known types” that can occur in the object graph. With .NET 4 Beta 1, the team adds a new DataContractResolver class that allows the .NET developer to override this “white list” constraint by overriding what type name gets serialized and what type gets deserialized. While a lower-level and more complicated feature, it’s functionality that has been long-promised for those wanting increased control over how data is serialized and deserialized. Examples of scenarios that can be accomplished using the new feature: removing the “known types” constraint for tightly coupled scenarios; making entire assembly “known” to serializer; etc

REST Improvements

We also continue to augment WCF REST support with features that have already been made available as part of the WCF REST Starter Kit preview releases. For the Beta 1 release, the team has added a couple of the Starter Kit features into WCF 4: (a) the capability for WCF REST services to make use of the ASP.NET caching infrastructure; and (b) automatically generated help pages that allow WCF REST services describe themselves through an automatically generated help web page – detailing which URLs to call, schemas, and examples of the request and response messages (both XML and JSON).

Tracing and Diagnostics

Last but not least, tracing and diagnostics in WCF 4 reduces the noise and the performance overhead of tracing WCF events by making use of Event Tracing for Windows (ETW) and to improving the performance of using performance counters. With Beta 1, the team has refactored diagnostic events and WCF is now sending a few high-value events via ETW. This change also surfaced in my posting on new features in WF 4 Beta 1; and, as with WF, there will be SDK samples to help folks understand better this and take advantage of this high-performance tracing option. These improvements should yield significant improvements to folks debugging a live system in production.

Features in the Beta 1 that Won’t Make RTM

Lastly, as with any beta release, it represents an evolving codebase as it moves toward a releasable product, and the features and functionality can [and typically do] shift. Within the Beta 1, there are two features that are unlikely to appear in .NET 4 that I’d like to quickly touch upon:

• Local Channel: We won’t be able to deliver the high-performant in-AppDomain channel in time for .NET 4. The beginning of a local (also known as 'in-proc') channel shows up in the Beta 1, but it’s in its early stages and unfinished; given resources and timing, the local channel capability will be removed in .NET 4 and won’t be present in the RTM bits.
• Durable Service Host Extensions: WorkflowServiceHost provides an extensibility mechanism called DurableServiceHostExtension that allows host application developers to receive notifications for state changes of the service instance and perform control operations specific to the service instance. This general extensibility mechanism will likely go away in .NET 4 RTM in exchange for a more scoped, but robust, functionality.

And it’s off to TechEd!

I’m off to TechEd for the next week, and I’ll try to give some word from the ground, but I’m likely to disappear again for a couple weeks. When we get back from TechEd, I’m going to try and work my way back another step – discussing what WCF 4 and WF 4 mean for the .NET 3.5 developer, and how those developers should approach the technologies.

I hope that this (and the prior) post is useful and informative. At least a few customers that I’ve spoken with over the past year have expressed a desire to get information out in this fashion. If you’re at the event next week, I’m a huge fan of feedback.