In this article, I will explore new WCF and WF Services features in the .NET 4.0 as well as the new application server capabilities provided by the "Dublin" (AppFabric) extensions. I will use many materials from MSDN and PDC conference. WF4 provides declarative authoring of programs that coordinate work Activities, Runtime and Tooling.
What is Windows Workflow Foundation? A framework for declarative programming or Tools for creating program definitions or A runtime for executing program logic? What is declarative workflow services? Services (WCF) extend the reach of workflows or declarative service authoring and composition? What benefits of declarative service authoring? Declarative flow control – parallel / async / compensation or Automatic state management or just Tracking / visibility. What declarative services ideal for: Long running, multi-interaction processes (e.g. approvals, applications), Coordinating multiple interactions (e.g. aggregation, composition).
WCF and WF are complementary technologies. If you are unfamiliar with them, a simple way to think about the pair is: WCF on the outside, WF on the inside. WCF is used to expose the external service interface of an application, and WF is used to describe the internal flow, states, and transitions of an application.
Although it's possible to implement WCF workflow services in the .NET Framework 3.5, it isn't easy. For starters, the integration layer between WCF and WF leaves something to be desired. In the .NET Framework 3.5, the WCF artifacts have to be defined and configured using the WCF programming and configuration model, while the workflow is defined using a different model. Ultimately, you end up with multiple artifacts that need to be deployed, configured, and managed separately.
Another reason for the difficulty is that the current base activity library concentrates on flow-control and logic activities and doesn't provide much in the way of work activities. So you must write a library of custom activities before you can implement real-world workflow services with WF. Given the complexity of that job, some developers have given up before they are able to experience the benefits of WF.
The .NET Framework 4.0 introduces a few core activities that provide more flow-control options, including the FlowChart, ForEach, DoWhile, and Break activities. The new FlowChart activity is one of the most interesting additions because it offers a nice middle ground between the Sequential and StateMachine flow-control models. FlowChart lets you use a step-by-step approach, enhanced with simple decisions and switches, but it also allows you to return to previous activities in the workflow.
The Workflow Runtime provides the ability to register services to be run inside it. The WF Runtime provides a set of core services that handle thread scheduling, persistence, transaction handling, queuing, and tracking. All of these except for the queuing service can be overridden.
Workflows are defined in XAML, but are usually edited graphically in Visual Studio. However, the workflow may also be expressed in code using any .NET-targeted language (VB.NET, C#, C++/CLI, etc.).
WF provides .NET developers with the ability to separate the business logic of their application from the underlying execution components. This provides a clearer and more manageable representation of an application. This approach lends credence to the growing process-driven application methodology which aims to separate an application's logical flow from its executable components at an enterprise level.
Each workflow consists of one or more activities that each perform a separate and discrete piece of logic. Developers can write their own custom activities and then use them in workflows. WF also provides a set of general-purpose activities that cover several control flow constructs such as if-else logic, parallel processing, looping logic, etc.
A Windows Communication Foundation approach to workflow communication was added in .NET Framework 3.5. This functionality comes in the form of two activities, SendActivity and ReceiveActivity, which send and receive WCF messages respectively. Workflows which include a ReceiveActivity expose a selected interface method as a WCF service. This could allow external code to, for example, make a Web Services call to a running workflow instance. The WF Runtime provides infrastructure to ensure that if a WCF call is made to a workflow instance that is in a persisted state (i.e. waiting for some external event like a WCF call or a timer event), then the instance will be reloaded into memory so that the message can be delivered to the workflow instance. Workflows which include a SendActivity are able to call external services via WCF.
When a workflow instance is created, the host application can provide arguments as Dictionary objects. These objects can be treated as both an input and an output to the workflow. Using the WF foundation, three different types of Workflow can be created: Sequential Workflow (Typically Flow Chart based, progresses from one stage to next and does not step back) State Machine Workflow (Progress from 'State' to 'State', these workflows are more complex and return to a previous point if required)
Rules-driven Workflow (Implemented based on Sequential/StateMachine workflow. The rules dictate the progress of the workflow).
WF also allows the workflow to update the host application through the WF Runtime of the progress of the workflow's execution. This is done by raising events in the WF Runtime to which the host application will subscribe. This includes the starting and ending of each workflow instance or moving into an idle or persisted state.
A new workflow designer added to Visual Studio 2010 provides a compelling graphical user experience for many of the key WCF and WF features discussed in this article. It provides features such as improved workflow navigation (drilling into composite activities) with bread-crumb trails for going back in scope, in-place activity editing (reducing the need for the Properties window), zoom capabilities, and overview navigation. In addition, the new designer provides an improved model for customization and re-hosting. Visual Studio 2010 will also offer a suite of new or improved project templates that make it easy to get started quickly with flowcharts and XAML-only workflows, and it will provide full support for XAML-based debugging when working with declarative workflows and services.
The new .NET Framework 4.0 activity programming model required some significant changes to the core WF runtime. As a result, custom activities designed for the .NET Framework 3.0 and 3.5 won't be able to run within a .NET Framework 4.0 workflow host without some special care.
To facilitate interoperability, the .NET Framework 4.0 comes with a special Interop activity that makes it easy to wrap a custom .NET 3.x activity within a .NET 4.0 host. This approach doesn't work for all .NET 3.x activities—it specifically does not work for root activities. Hence, when moving to Visual Studio 2010, you'll need to redesign your workflows using the new workflow designer (because it has also changed extensively), then you can wrap custom .NET 3.x activities using the new Interop activity within your new workflow definitions.
Windows Worflow Foundation supports:
- Single framework for building Workflow applications on Windows
- Programming model, runtime and tools
- Highly extensible
- Supports Human/System Workflow
- Supports long running Workflows and their state
Microsoft has been working on a new set of extensions to Windows Server—code-named "Dublin"—that provides valuable hosting and management features for your WCF and WF applications. "Dublin" is essentially a set of service management extensions built on top of IIS/WAS that will ship as part of Windows Server. When using the "Dublin" extensions, you'll still be hosting your service and workflows in IIS/WAS, but your applications will enjoy additional WCF and WF-specific management capabilities and tools that don't currently exist in IIS/WAS.
The various "Dublin" extensions will ship in a future version of Windows Server as part of the Windows Server Application Server role. Hence, the set of features is often referred to as the Windows Application Server, although that's not the official name sanctioned by Microsoft. For the rest of this article, I'll refer to the new Windows Server Application Server extensions as simply "Dublin."
What is Dublin or Windows Server AppFabric?
Windows Server AppFabric is a set of integrated technologies that make it easier to build, scale and manage Web and composite applications that run on IIS.
- Most WCF services are hosted in IIS / WAS.
- IIS tooling designed for managing web applications.
- Windows Server AppFabric = service management (Simplified configuration of services and workflows, Operations dashboard, Workflow service management, GUI and PowerShell tools).
- Scalable, manageable solution for hosting services on Windows.
Another common question is how "Dublin" relates to BizTalk Server. In a lot of ways, BizTalk Server inspired many of the features you see in "Dublin" today. Although both technologies provide similar management capabilities, there's a big difference between the two in terms of their focus. "Dublin" adds hosting and management extensions to Windows Server designed specifically for WCF and WF applications, whereas BizTalk Server is focused on application integration with non-Microsoft systems using a variety of different message formats, transports, and mapping techniques.
The primary focus of BizTalk Server has always been and will continue to be integration with non-Microsoft systems (line-of-business applications, legacy systems, RFID devices, and business-to-business protocols). BizTalk Server will remain focused on these core strengths in the years ahead. In general, you'll want to continue using BizTalk Server when you're focused primarily on these types of enterprise application integration (EAI) scenarios.
However, since many WCF and WF apps don't need these kinds of integration capabilities, BizTalk Server can often feel like overkill. This is precisely where "Dublin" fits into the picture—as a simpler alternative that provides similar management capabilities. In the end, "Dublin" will be more cost-effective for these scenarios than BizTalk Server since the "Dublin" extensions will ship as a core part of Windows Server and won't require you to buy integration adapters you don't need. It's likely that a future version of BizTalk Server will build upon the "Dublin" extensions in order to leverage the core management investments being made to Windows Server.
As you can see, "Dublin" provides several runtime databases that lay a foundation for service persistence and monitoring. There is a layer of runtime components and services provided by the .NET Framework that build on top of these databases. "Dublin" further extends these runtimes to provide integrated hosting, persistence, monitoring, and messaging capabilities. This layer, in conjunction with the underlying runtime databases, constitutes what is referred to as "Dublin."
The top two layers in the architecture are what make "Dublin" usable by humans. There's a management API layer that makes the various capabilities scriptable via Windows PowerShell cmdlets. On top of that there is an IIS Manager experience that should feel familiar to today's IIS administrators because it actually builds on the Windows PowerShell cmdlets. So everything you can do in IIS Manager you can also do in Windows PowerShell.
Microsoft has added numerous UI extensions to IIS Manager for performing the various hosting and management tasks described in this section. There are extensions for deploying and configuring applications, managing applications, and monitoring applications. These extensions also provide a runtime dashboard of your system showing things such as running, suspended, and persisted workflow instances.
Many environments do not allow developers to deploy services directly to their managed servers for security and isolation reasons. "Dublin" provides an alternate solution for deploying services through its application export/import features.
You can package up WCF and WF applications for deployment on other servers by selecting the Application Export feature in IIS Manager. This will bring up a dialog that asks you to select a specific application to export. Once you've specified a location, pressing Export will generate a file package with a .zip extension containing all the WCF and WF code as well as all the metadata and configuration settings for a single application. This package can then be moved and imported onto another server through the "Dublin" extensions. Now you can simply send the .zip file to the IT professional who manages your servers and let him take care of it.
The Windows PowerShell Export-Application cmdlet accomplishes the same thing. This Application Export capability is also very nice for system test and validation environments.
You can import a WCF and WF application by selecting the Application Import feature or by using the Import-Application cmdlet (you can also view the contents of a package by using the Get-PackageManifest cmdlet). The import feature will then prompt you to select the package (.zip file) that you want to import.
During the process, you can specify the application name, the application pool, and the physical path for the application, if desired. And since "Dublin" provides centralized persistence configuration, when you deploy your workflow services to another server, you don't need to worry about changing the persistence configuration at the application level. It will simply use the new persistence database associated with the new server. These features make the process of deploying WCF and WF applications in a server environment very approachable for the system administrator responsible for those tasks.
Original post: http://msdn.microsoft.com/en-us/magazine/dd347832.aspx
Website – www.Microsoft.com/WindowsAzure/AppFabric
Net Services MSDN Developer Center – http://msdn.microsoft.com/en-us/azure/netservices.aspx
Net Services Blog – http://blogs.msdn.com/b/netservices/
AppFabric Twitter – http://twitter.com/azure_appfabric
Biztalk Website – http://www.microsoft.com/biztalk/
Biztalk Website – http://msdn.microsoft.com/biztalk/
Biztalk Server Team Blog – http://blogs.msdn.com/biztalk_server_team_blog
Biztalk Blog – http://www.biztalkblogs.com/
Application Infrastructure Virtual Launch Event – www.appinfrastructure.com
AppFabric on Microsoft.com – http://www.microsoft.com/appfabric
Developer Center – http://msdn.microsoft.com/appfabric
Worflow forum - http://www.WindowsWorkflow.net/Forums Worflow Samples - http://www.WindowsWorkflow.net
WF_WCF_Samples.exe (15.48 mb)
The_Workflow_Way.pdf (820.22 kb)
Introducing_Windows_Server_AppFabric.pdf (1.56 mb)
Dublin__NET_4_overview.docx (37.11 kb)