- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Overview of WF
All applications have workflow, no matter how they automate it. Many applications also look to offer tools to allow others to build custom workflows on top of their product. WF's goal is to support both of these scenarios and do so at mainstream scale. If you are building an application on Windows that tracks orders, it is WF's goal to power this workflow. It doesn't matter if it is an ASP.NET, Windows Forms, Windows Service, or other application. If you are building a platform, like SharePoint, where people build their own custom workflows on top of it, WF's objective is to provide the tools for this as well. WF also intends to serve all three types of workflow: in-application, human, and integration-centric. WF includes all the foundational elements to create all three types of workflow.
WF must play well with others if it expects other applications to use it to power their workflow and potentially to permit custom workflows to be built with it on their platform. WF has to offer its services in such a way that the applications can use its services and cannot make assumptions about what elements will be available to the application. For instance, if WF is hosted (called from) in a Windows Forms application on a client, there may not be access to SQL Server. It therefore cannot build a hard dependency on storing idled workflows to SQL Server.
These higher-level functions, such as where to store idled workflows, how and if tasks should be stored, and functions such as BAM, are up to the host application to implement, as needed. An application using WF for in-application workflow support, for instance, may not need BAM. The host application can generally start from one of WF's building blocks to add higher level functionality. The host, for instance, can choose to use WF's persistence service that stores idled workflows to SQL Server out-of-the-box (OOB), or with minimal effort to another medium, such as Oracle. Likewise, the host can build on WF's tracking service to supply BAM. It is critical to WF that these building blocks are extremely powerful so that it will be embraced by other products looking for workflow support. Therefore, many WF features may not include the final user interface, but they will be based on an extremely strong infrastructure, as both the persistence and tracking services are.
SharePoint provides a fully functional WF host, as described in the "SharePoint Workflow" section of this hour. Many use SharePoint's WF implementation just for its hosting capabilities, even those not interested in SharePoint. Microsoft CRM also provides a host. Microsoft is in the process of building a "generic" host based on the combination of WF and WCF. WCF hosting of WF was added in the .NET Framework 3.5. Going forward, this tandem is likely to form a standard host that can be used by any Windows application that chooses to employ workflow functionality. Third parties, such as K2 BlackPearl, have also built hosts on top of WF.
By the end of this hour you will have a better understanding of the rich and powerful capabilities WF offers to create workflow applications and products. These concepts will be expanded on throughout this book.
Next, let's look at the fundamental pieces of WF.