The Application Server Platform team (the team responsible for WCF and WF, who I affectionately still refer to as the Connected Framework team) has been hard at work on futures since before the release of .NET 4. And while the new feature area announcements made public today may not share the same spotlight as higher layers of the AppFabric onion, they are a welcome addition to the framework that continue to build on the theme of productivity ushered in the 4.0 release.
No doubt, some of these features should have made it within 4.0, but others are careful tuning; the result of direct feedback from customers, developers, MVPs and Business Platform Technology Advisors for making a fantastic set of technologies for exposing and composing applications both on-premise and in the cloud even better.
WF
Developers who prefer C# (such as myself) will welcome the addition of C# support to WF expressions. In truth, while at first I balked at the omission, I became used to the VB syntax much in the same way that I accepted the light C-style syntax in the BizTalk Expression Editor. That said, if I had a dollar for every time I got a validation error for adding the impulsive semicolon after initializing a variable, I’d have a higher balance in my bank account.
The community has protested about the absence of a State Machine Activity in WF 4 v1 ever since the first SDR when it’s omission was benevolently declared. However, the team has made this highly coveted activity available for evaluation in CTP form for some time, and it sounds like it is getting further baked, though no suggestion was made that it would RTM out-of-band.
@ronljacobs did a nice job showing off the designer, and it appeared that there have been some enhancements to the UX since the CTP. Additions such as compile-time semantic error checking (i.e. ensuring a state is connected to at least one transition state) and an intuitive composition experience whereby connections are made between states by simply nudging one state shape to the other and dropping a state on an existing connector to join the transition as an intermediary are very nice enhancements. Annotations, essentially the ability to add PowerPoint style comments on activities will be very helpful for scattering “WTF?’s”, I mean comments :-) within workflows for documentation as well as aiding in design/code reviews. These essentially become declarative TODOs, which as Ron showed are searchable and clicking each annotation brings you to the activity which is tagged. A big kudos to @mwinkle and team on this body of work as I know Matt has been working hard and actively soliciting and listening to the community and influencing investments based on this feedback for several months.
Speaking of activities, there are a number of very early non-control flow activites that made their first public appearance, including a set of data activities that make it easy to invoke SQL statements and stored procedures (ExecuteSqlQuery<T>, ExecuteSqlQuery and ExecuteSqlNonQuery). To be honest, I have mixed feelings about these activities. While you can certainly compose these activities within domain-specific activities, I think that they make it far to easy for developers to build kitchen sink outer activities that will have a tendency for abuse on the mainline. Of course, patterns alone don’t ship software, working software ships software, but just as I shudder to see references to System.Data in the business layer, the concepts of domain-specific encapsulation are really a key value proposition to declaratively orchestrating activities in a manner that reflects the intent of a workflow. Hopefully the guidance will remain to think about potential for reuse of every activity and consider taking advantage of the productivity benefits of these new data activities while not giving up intuitive composition.
Interestingly, I am more comfortable with the SendMail activity, whose purpose is self-explanatory. Perhaps this is because unlike DAL-specific activities, I’ve written one too may SMTP code activities. In truth though, I will likely stick with my own for demo purposes because the PickupDirectoryLocation technique taught to me by my friend and fellow MVP @Milnertweet of @pluralsight fame is just plain wicked.
There are also a number of new Messaging activities coming that are reflective of Microsoft’s full embracing of REST style composition (more on that shortly) including an HttpGet, HttpPost, HttpPut and HttpDelete activity. These will offer a nice alternative to dropping down to a code activity to issue a GET or a POST, making banging on an ODATA or POX feed easier than ever while allowing folks to debate the RESTfulness of their workflows in a fully declarative manner :-)
Workflow Services
Further evidence of the team listening and responding to feedback is the much anticipated support for contract-first Workflow Services. Many including myself have been very vocal about this. In WF 4 v1, you define your contract via properties on the Receive activity and the WSDL is generated based on these properties. This is the equivalent of slapping a ServiceContract attribute on a concrete type, which on my teams results in an instance electric shock being administered to the errant developer. Just because you can do something doesn’t mean you should, and while in WCF there is no excuse for this, in WCF 4 v1, it is the only way to expose a WCF service. Contract-First WF allows you to browse your assemblies or projects and choose an existing interface, ensuring that factoring decisions can continue to take place outside of the WF designer while embracing the pillars of separation of interface definition from implementation. The result of browsing and selecting an existing Service Contract is the generation of one activity per operation, the workflow way.
Versioning has been an interesting problem for as long as technologies have provided the ability to persist and resume application state. The canonical problem is this that if you persist the state of a workflow and in between the time it was persisted and later resumed, a new version of the workflow definition is deployed, what happens? The short answer is an exception indicating that you are asking the WF runtime to try to fit a round hole into a square peg. Leon Welicki (PM on the WF team and one of the nicest guys on earth) and team have found a solid solution which is to redirect, or bind a persisted workflow to the appropriate definition at runtime, and this is what Versioning and Dynamic Update do for you. By giving your workflow a name and version, you can map instances to that named instance, solving the versioning problem without giving up the performance benefits of keeping the definition and instance state as peas in the same pod.
Ron also provided a teaser for what the goodness of the Container in the Composition Model might do for Workflow Services. One area in particular he focused on was the ability to monitor WF instances, and I couldn’t help but compare it to HAT orchestration debugging in the BTS world. I can only hope that this capability will be available both on-premise as well as in the cloud, as the fidelity of features and workloads within AppFabric appear to be landing towards a single hybrid platform in which both WF and WCF play key roles.
WCF
While the slow uptick of developers embracing .NET workflow can be attributed largely in part to the nascent release of WF 4 v1 among the firehouse of new technologies release this year, WCF as a technology came out strong from the beginning and has only gotten better and better since its debut in .NET 3.0. As my hands down favorite .NET technology, I’ve worked very hard to understand why developers have such a hard time with WCF, but for reasons I still don’t fully understand, there is an intimidation factor in WCF that is difficult to reconcile. The team has worked hard to make the barrier to entry with WCF as low as possible, delivering significant improvements to the developer experience in WCF 4, including configuration-less F5 hosting, improvements in REST support and out-of-the-box support for WS-Discovery and message brokering via the Routing Service.
While admittedly a WS guy at the core, I cannot dispute that there is a need for different tools for every job, and WCF has remained true to its vision for delivering service-oriented enablement of applications across a variety of formats and styles. To this end, @gblock has taken some time away from slinging MEF to explore and deliver new ways of enabling developers to use WCF to expose resources of virtually any type over HTTP, transcending the boundaries that WS or even REST styles impose.
For example, by embracing the capabilities of the HTTP protocol, Glenn and his team are working to make it very easy to serve up content based on the encoding type defined in the HTTP header of a GET request. The implementation is reminiscent of the ActionResult API in MVC by which you can bind a requested content-type to a specialized response stream such as a JSONResul or XMLResult, however the new enhancements take it much farther by providing a very simple approach for serving up content of any supported content type, be it POX, PNG or PDF. Like WCF Data Services, these investments on top of WCF will allow developers of all backgrounds to take advantage of a simpler model for exposing and consuming multiple resource types in a very direct and lightweight manner.
Wrap Up
All of these features are welcome addition to the framework, and while there is no guarantee that everything discussed here will be be part of the next official shipping vehicle (what that is remains unclear), it is evidence that the team is continuing to move in the right direction, not only listening, but more importantly acting upon what the community is asking for.
You can download and explore the beta of the new WCF Web APIs that Glenn covered here: http://wcf.codeplex.com/ and as I mentioned earlier, CTP 1 for WF State Machine is available here: http://wf.codeplex.com/releases/view/43586.
There are no public announcements as to when we might expect the next rev of the State Machine CTP or the new WF goodies discussed above, however be sure to keep up with the WF team at http://msdn.microsoft.com/wf, endpoint.tv on channel9 http://channel9.msdn.com/shows/endpoint/ and stay tuned for “Endpoint Radio” a new podcast by Ron himself making its debut shortly.