The March CTP of Orcas went out the door this week, which is notable for many reasons. The ones that have the most immediate impact on me and my life are as follows:

1) This is the first real public release my team has shipped since Vista (which is pretty cool, considering that Vista closed down for us about six months ago and Indigo V1 took...much longer than that :) )

2) This is the first release we've done since we combined the WF and WCF teams under one roof. As of about January, we're now all literally under one roof. The WF team came over to 42, so we're all located physically in the same space. It's much easier to talk to people when you don't have to trek across campus to Building 1 just to chat.

We've been pretty heads down on this since Vista (which accounts for the relative silence around this blog -- sorry about that), since we had to hit the ground running in order to make the pretty aggressive Orcas schedule. Beta 1 will I think be the real coming out party for our Orcas stuff but the March CTP has some really great WF/WCF stuff to tantalize the early adopters.

Although the Orcas release is a small release relative to our respective V1's (and that's only because V1 was so huge), it packs a big punch in terms of the scenarios it addresses and the value it adds.

From a WF/WCF perspective, the story of our Orcas feature set is told quite nicely by the two assemblies we're shipping:

• System.WorkflowServices - this is all about making WF + WCF play nicely together. The code in here lets you expose workflows as services and implement services with workflows. On the runtime side, we've taught the WCF channel infrastructure how to use the WF persistance mechanism, which enables durable context to be stored outside of the AppDomain hosting the service. All the goo required to maintain correlation state and differentiate Alice's conversation from Bob's conversation (or alternatively, messages targeted at different workflow instances) comes in at the binding level, so it's all nice and transparent. On the programming model side, we've got SendActivity and RecieveActivity which are how you get two workflows (or a service client and workflow service, or a workflow client and a remote service) to communicate via messaging.
• System.ServiceModel.Web - the code in here is all about making WCF + the Web play nicely together. Now let's not kid ourselves, the Web is all about plain old HTTP (sans SOAP)...which is why we're baking first-class support for REST/POX scenarios into the ServiceModel layer. While it was technically possible to do REST/POX programming in WCF V1, the programming experience wasn't exactly nice (I wrote the REST/POX sample, and I'll be the first to admit that I wouldn't want to write that code for a living...oh, wait...). To fix this, we've taught the dispatcher how to route messages to service operations via combinations of URI suffix (yay prefix matching!) and HTTP Method. There's a bunch of parameter binding stuff as well, which extracts values out of the URI/Query and binds them to operation parameters. You'll also be glad to know that we have a new standard binding for these scenarios -- the aptly named WebHttpBinding, which speaks SOAPless XML as well as JSON (!). In Orcas, JSON is a full citizen in the WCF world. Think ASP.NET AJAX clients running in the browser talking to WCF services on the server over JSON. The last chunk of this assembly is the data API for RSS + ATOM feeds which provides an object-oriented set of classes for constructing RSS/Atom XML documents. Hopefully, this is the last RSS/Atom DOM anyone will ever need to write on the .NET platform. Combine this data API with the HTTP programming model and you've got a great way to serve out your data as RSS feeds consumable by any standard client. Oh, and everything in this assembly works great in ASP.NET Medium Trust too...

So in summary, Orcas for me is about two things:

1) Teaching WF and WCF a bit more about each other
2) Teaching WCF a bit more about life on the rest of the Web

My intent over the next few posts is to crack open System.ServiceModel.Web in some detail, since that's what I've got the most context on. The feature set in this CTP will be pretty close to the Beta 1 feature set, so I'll talk about what's here now and what's will be here by Beta 2. There's some good stuff coming down the pipe that didn't quite make this CTP.

Overall, it's good to keep in mind that this is a (still early) CTP for us so lots of stuff isn't quite baked yet. But that means there's lots of room for feedback and constructive suggestions, so send those my way.

Happy hacking...