One of the big components included in .Net 4.0 Beta1 is the WF4 framework that I unveiled at PDC. The team is blogging here, and I’ll be including ongoing tidbits for WF and WCF to help smooth out speed bumps encountered by our customers.

More at www.microsoft.com/net/wcf/champ.

1. Introduction
2. Framing Protocol Overview
3. Preamble Records
4. Encoding Records
5. Upgrade Negotiations (security, compression, etc)
6. Message Data

#3-5 are the details behind the "handshake" I alluded to here.

You should check it out (probably starting tomorrow) at: http://channel9.msdn.com/pdc2008/TL31/

UPDATE: You can download the SDK here and start playing with writing your own custom language. Fun stuff!

For those of you that were able to attend my session in person, please fill out the evaluation form (we’re currently at about 5% participation).

For those that couldn’t join me in person, the session was videotaped and is available at http://channel9.msdn.com/pdc2008/TL17/. Enjoy!

In particular there are two sessions that I’d like to call out.

The first is Ed Pinto’s session, where you’ll find out about the significant investments we’ve made to improve the WCF authoring experience:

WCF 4.0: Building WCF Services with WF in Microsoft .NET 4.0.

Eliminate the tradeoff between ease of service authoring and performant, scalable services. Hear about significant enhancements in Windows Communication Foundation (WCF) 4.0 and Windows Workflow Foundation (WF) 4.0 to deal with the ever increasing complexity of communication. Learn how to use WCF to correlate messages to service instances using transport, context, and application payloads. See how the new WF messaging activities enable the modeling of rich protocols. Learn how WCF provides a default host for workflows exposing features such as distributed compensation and discovery. See how service definition in XAML completes the union of WF and WCF with a unified authoring experience that simplifies configuration and is fully integrated with IIS activation and deployment.

Once you’ve built your services, you will need to deploy, host, and manage them.  Windows Server "Dublin" handles this complexity, and Dan Eshner will unveil the details here:

Hosting Workflows and Services

Hear about extensions being made to Windows Server to provide a feature-rich middle-tier execution and deployment environment for Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) applications. Learn about the architecture of this new extension, how it works, how to take advantage of it, and the features it provides that simplify deployment, management, and troubleshooting of workflows and services.

1. Most of what I’m working on hasn’t been publicly disclosed
2. I’m prepping for PDC 2008 where I can finally discuss the past 2 years of my life without an NDA

If you want to see the latest and greatest Microsoft technologies that we’ve been cooking up, register now, and then mark your schedule for my talk:

Windows Workflow Foundation 4.0: A First Look

Programs coordinate work. The code for coordination and state management often obscures a program’s purpose. Learn how programming with Windows Workflow Foundation (WF) 4.0 provides clarity of intent while preserving the functional richness of the .NET framework. See how easy it is to build workflows with the new Visual Studio workflow designer. Learn about text-based authoring options for WF. Hear how WF integrates well with other Microsoft technologies (WCF, WPF, ASP.NET). If you’ve looked at WF before, come and see the changes to data flow, composition, and new control flow styles. Significant improvements to usability, composability, and performance make Workflow a great fit for a broad range of solutions on both the client and the server.

Other great (and related) talks include Doug Purdy’s Lap Around Oslo, Matt’s Building WF Activities session, and Ed’s chocolate & peanut butter talk on WCF+WF.

41 days and counting…

Now, sometimes the underlying channel can complete immediately (UDP will drop the packet if the network is saturated, TCP may copy bytes into a kernel buffer if there’s room, etc). However, depending on the amount of data transmitted and the number of simultaneous calls to a proxy, you will often see blocking behavior. HTTP, TCP, and Pipes all have throttling built into their network protocols.

If this isn’t desirable, there are a few alternatives depending on your application design. First off, if you want a truly non-blocking call, you should call channel.BeginSend/client.BeginXXXX (i.e. generate an async proxy). This is step one if you want non-blocking calls. With an asynchronous proxy, we will always be non-blocking from a thread perspective (which is always my recommendation for middle tier solutions, though there’s some quota coordination necessary to avoid flooding outgoing sockets).

For one-way operations, when your async callback is signaled it means that the channel stack has "successfully put the message on the wire". When this happens depends on your channel stack:

• TCP signals when the socket.[Begin]Send() of the serialized message has completed (either because it’s been buffered by the kernel or put onto the NIC)
• Pipes are a similar process (NT Named Pipes work similarly to TCP under the covers but without the packet loss)
• MSMQ signals when the Message has been transferred successfully to the queue manager
• HTTP signals when we’ve received an empty response. The only other alternative would be to remove all guarantees (and have to arbitrarily propagate the exception through some other call or thread). Trust me, this is better
• UDP will complete when the UDP socket send completes (which is effectively instantaneous)

For two-way operations, when your async callback is signaled it means that the channel stack has "successfully put the message on the wire and then received a correlated response".

Asynchronous operations can be tricky, and can often get you into flooding trouble when used incorrectly. So be careful, use quotas to manage your flow control, and always remember that the internet is not a big truck; it is a series of tubes and sometimes they get clogged. And you shouldn’t try to fight the clogs by pouring more data down the tubes