MSDN Magazine - December 2008 - (Page 57)

Remember that WF is a runtime unto itself. Avoid common pitfalls by developing a basic understanding of the WF threading, scheduling, and serialization concepts. It’s Not All or Nothing It’s a common anti-pattern when first adopting a new technology to apply it everywhere, sometimes to the exclusion of other options, the proverbial “when wielding a hammer, everything looks like a nail” syndrome. We’ve all been guilty of this at some point. And while this is certainly possible with WF, its nature as a low-level plumbing technology with many integration points and extensibility hooks allows you to apply it in many distinct problem domains. WF works equally well in highly multithreaded environments, such as ASP.NET, or in desktop client applications built with Windows Forms or WPF. Common uses for WF in these scenarios include implementation of UI-driven logic, where you implement user interface event-handling logic in a workflow instead of imperative code; task-oriented asynchronous background work, such as fetching and processing Web search results or manipulating large files on disk, typically invoked on a separate thread; and page flow, in which workflow logic dictates UI navigation for ASP.NET or smart clients. Figure 5 shows the design surface for a Microsoft sample PageFlow application (go.microsoft.com/?linkid=6923851). Each top-level activity in the workflow defines the view (the Web page or application form) to display, as well as any custom processing for each view. The allowed transitions between views are also depicted here. Contrast a clean graphical representation like this with dozens of lines of C# or Visual Basic to codify the same information and you can see where WF has obvious benefits. WF and Windows Communication Foundation (WCF) are natural technology mates in service-oriented applications. A workflow is, in essence, a service that you invoke to perform a specific function, and WCF is designed for exposing services for consumption. To make it easy on you, the .NET Framework 3.5 ships with the SendActivity and ReceiveActivity activities that make WF-to-WCF integration possible right out of the box. You use ReceiveActivity to declaratively expose WF workflows behind a WCF address/ binding/contract facade. The workflow is the service implementation, and it is invoked by the WCF integration plumbing as requests are received. You can also expose long-running workflows this way, where a single workflow instance might expose multiple service operations and go through several execute/idle sequences. WCF binding types (BasicHttpContextBinding, WsHttpContextBinding, or NetTcpContextBinding) are used to correlate messages sent from clients to specific in-flight workflow instances. Finally, as you might guess, SendActivity allows you to configure outbound WCF client connections from your workflow to external services with relative ease. msdnmagazine.com WF is a runtime unto itself. Avoid common pitfalls by developing a basic understanding of key WF concepts. As a .NET integration technology, WF programs can interact with any library or technology consumable by .NET code. Your existing technology investments needn’t be discarded when implementing application logic in WF; to the contrary, the real value of the technology lies in enabling greater and more productive use of existing technology assets. WF is as much an integration technology as a means unto itself. WF is being used as a foundation technology within the Microsoft products that employ a workflow product. These include SharePoint, the Dynamics products, and the upcoming release of Office Communications Server and Office Project. This common usage allows for much easier integration between the technologies and your WF application. Expect to use it as part of a greater whole. In order to maximize integration opportunities, extensibility is a fundamental tenet of WF. Key pieces of the core infrastructure are configurable—or even replaceable with custom implementations. And while WF ships with numerous built-in activities for control flow, transactional semantics, and services communication (among others), none of these activities are required for use in your WF programs, and none of them uses special features unavailable to the WF programming community at large. Your own custom activities (or those of third-party vendors) are inherently no more or less capable than anything that ships out of the box. Action-oriented activities that map to domain-specific behaviors are obvious choices for custom implementation. A workflow used by a mortgage company to originate loans might contain custom activities for requesting flood insurance quotes, computing property taxes, and obtaining applicant credit scores, among others. These are useful and necessary, but the more interesting cases are Plug and Play Figure 5 A Workflow for Governing User Interface Navigation Steps December 2008 57 http://go.microsoft.com/?linkid=6923851 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.