I watched a webcast on how to use the WCF/WF integration that comes with .NET 3.5 and VS2008. It looks like they've added some features that make it very easy and very powerful to use WCF with WF workflows.
Here are the things that caught my attention:
WCF Service Host
VS 2008 comes with a built in WCF Service Host. It acts similar to the Cassini web server that VS 2005 uses for asp.net web sites. The cool thing is that you don't need to create a host project to host the WCF service. Just the WCF library project. Then VS automatically spins up the WCF host for you! Nice!
WCF Service Tester
When you go into debug mode with a WCF service, it spins up the WCF service in the service host. It also spins up a WCF Service Tester UI that lets you invoke any method on your service. It gives a UI for entering the parameters and then shows the output. Very nice!
As a side note, the service tester doesn't understand workflow context very well, so it doesn't work well for multi-call WF based services.
With the .NET 3.5 implementation, defining a WCF service with a WF workflow feel natural. The service interface is still defined with a .NET Interface. Then the WF implements the interface via new WCF specific send and receive shapes. These shapes have a native understanding of WCF, but can also invoke non-WCF services (like ASMX).
With the 3.5 framework, WCF and WF have the concept of a context. This is basically the workflow instance GUID, but can contain additional info in certain scenarios. The context is important when you have a workflow with multiple operations exposed. The client and the server need a way to identify which instance of the workflow to use when the client invokes a method.
The context can be passed in a variety of ways depending on the binding that you use with WCF. If you have WCF on both sides, then you just use the new context aware bindings and it will automatically transmit context between the client and the service. If you have an ASMX or Java client, then you pull the context out of the soap header.
In the 3.0 framework, the system would transfer this Instance UID, but it did it via a cookie. This was not ideal because by default, web service proxies didn't support cookies. It's also a bit of an unnatural implementation when SOAP supports a better way via SOAP headers.
The initial receive shape in a workflow must return something if the client wants to get the context. In other words, if the initial shape is OneWay, then the client will not have the context and will be unable to call the next step in the workflow.
WF in .NET 3.5 supports the concept of a conversation. This is configured by working with the OwnerActivity property on the context settings. If set, then the context contains the workflow instance UID, plus the UID of the owner activity. This can be useful if a workflow is expecting responses from multiple clients and needs to be able to identify which client is responding back to the workflow.
For example, if the workflow submitted quote requests to 3 vendors and then waits for a response from each vendor. The vendors must pass more than just the workflow instance UID. They need to pass the conversation UID so that the workflow runtime can pass that response back to the correct activity in the workflow.
When working with a solution where you have a client and WF based service in the same solution, VS won't automatically discover the WF service until you close and re-open VS.
Operation Availability (Enable / Disable)
The WCF integration understands the state of the workflow and will automatically throw an exception if an operation is not valid at this time.
For example, if the WF has three steps and each step is an operation exposed via the WCF service interface. A client should call step 1, then step 2, then step 3.
If the client calls step 1 and then step 3, the WCF host will automatically throw an exception indicating that step 3 is not available at this time. The only step that is valid right now is step 2. (This was a bit challenging in the .NET 3.0 framework with the ASMX implementation.)
The demos showed some pretty neat demos where the workflow took advantage of WCF's ability to do bidirectional communication. It didn't use the duplex contract, but it did show how a client can expose an endpoint too. Then it can pass that endpoint information to the workflow so that the workflow can "call back" to the client. This is useful in long running scenarios where the client would like to start something and get notified when the work is complete.
We had practically abandoned WF in the .NET 3.0 due to the challenges of hosting and the designer slowness.
.NET 3.5 makes WF + WCF look like a viable option again. I'm sure there are still challenges, but they've closed a significant gap.