Windows Workflow Foundation by itself is a great tool, but when combined with other technologies, it can do even greater things. Over the past few years, Microsoft’s strategy has included providing an encompassing set of complementary technologies. The following sections highlight these technologies and how they relate to developing workflow applications.
You can use SQL Server as the backbone to workflow application development. You can persist workflow instances and store tracking data in SQL Server’s relational tables. Basically, you can write any data to the database and later recall it. As you continue to read this book, you’ll see that SQL Server plays an important role in the Windows Workflow Foundation platform and architecture.
If you’ve had any exposure to Microsoft’s BizTalk Server, you may have had had a knee-jerk reaction when you first heard about Windows Workflow Foundation. This is because on the surface, there might appear to be some traits of both technologies that seem to overlap. Some of the differences between BizTalk and Windows Workflow Foundation are described later, including pointers on when you should use one technology over the other. First, here’s some background information on what BizTalk is and how it works.
Microsoft initially released BizTalk as BizTalk 2000. At a high level, BizTalk was built to tackle the problem domain of Enterprise Application Integration (EAI). EAI describes the concept of helping applications talk to one another. This becomes difficult because applications speak myriad dialects. For example, an enterprise’s payroll system might communicate with the outside world by dumping a flat file on an FTP site. Conversely, the system that handles new hires is a little more progressive and exposes some XML web services. Without some kind of translation between the two systems, you’re out of luck regarding communication.
A common way to describe a system such as BizTalk is as a hub-and-spoke model. That is, BizTalk sits in the middle (the hub) and branches out to a series of software systems (the spokes) while sending and receiving messages to and from each application (see Figure 3-7). This minimizes the amount of glue code that developers have to write and maintain to make each system talk to another one. Without a system like BizTalk, a developer would have to write custom code for the CRM system to talk to the ERP system, and vice versa. There would also have to be code for the custom application to talk to the external trading partner and SharePoint site. The list goes on and on. As you can see, the number of touch points increases greatly every time a new system is added to the mix.
The concept of messages is key to the purpose of BizTalk in life. BizTalk receives messages from certain applications and delivers pertinent information to other applications interested in particular data. Because of this, BizTalk has to be able to understand each message type an application generates. If BizTalk understands how Application A and Application B talk, it is reasonable that BizTalk can act as a translator between the two.
Though integrating two applications isn’t very interesting and probably not a worthy use of BizTalk, the value starts to go up when numerous systems are added to the picture. For example, say an HR system exposes data related to employee training efforts, and there are three pieces of software in an organization that are interested in this information. Furthermore, one of these applications might be interested in only the training related to information technology. All three systems could easily be informed when an employee takes a training class, but the application concerned with technology training can subscribe to messages exposing that specific data.
A typical BizTalk project contains several common entities that facilitate the concept of EAI. First, because BizTalk has to be able to understand the messages from all involved applications, there needs to be a definition of what these messages look like. This definition is called a schema and is a standard XSD file.
Mapping enables one application’s messages to be sent to another system. Mapping is a visual, typically straightforward process. The source schema is displayed on the left side of the screen, and the destination is displayed on the right. In simple scenarios, a field-to-field translation is as easy as dragging one node of the schema from the source to another node on the destination. See Figure 3-8 for an example of the BizTalk mapping interface.
The schema map can take an XML file that looks like this:
<Person> <Person> <First>Bryan</First> <Last>Roberts</Last> </Person> </Person>
and make it look like this:
<customer customerFirstName="Bryan" customerLastName="Roberts" />
Ports are another core concept within BizTalk. Ports in BizTalk are conceptual and do not correlate directly to ports in a networking sense (such as port 80 for a web server). A port defines a location where a message can be received or sent. During development, you can keep these ports completely conceptual and not tied to a physical location such as a file drop or web service URL. However, after the project moves to production, you must bind a port to a real location. There are many different types of transports for sending and receiving messages, such as FTP, e-mail, web services, and SharePoint document libraries. BizTalk provides an adapter infrastructure to handle different transport types. Each adapter has to be configured to allow BizTalk to use a specific port. For example, the FTP adapter needs a URL, user name, password, and a folder in which to look for messages.
Finally, the piece that might cause some confusion related to BizTalk and Windows Workflow Foundation is called orchestration. As you might imagine, the fact that BizTalk can act as an organization’s central hub for message handling and delivery means that it should also be able to facilitate complex business processes related to all this data. For example, if BizTalk is used to handle messages related to customer orders, it should be able to make decisions and route messages based on predefined processes and rules. A simple scenario might be one where all orders over $500 are routed to a customer specialist for approval and special service. Furthermore, this process of orchestration, like many other things in BizTalk and Windows Workflow Foundation, is visual. You drag and drop shapes from the Toolbox on to the orchestration designer to define a process. This is where the knee-jerk reaction mentioned previously comes in - initially, you might be confused about how these two pieces of software relate to each other. The next section covers this topic.
Although other pieces of BizTalk are quite interesting and important, those topics are better left to the numerous comprehensive resources that are readily available. Other key components include the BizTalk Rules Engine, Business Activity Monitoring, and pipelines. For more about BizTalk Server, refer to Professional BizTalk Server 2006, R2 (available at www.wrox.com).
Because both and Windows Workflow Foundation share the concept of process definition, you may wonder why they exist separately. There is a compelling answer for this dilemma, and key differences exist between the two entities.
This biggest differentiator between the two is that BizTalk is a server product that is installed, configured, and subsequently maintained in a production environment. As mentioned, Windows Workflow Foundation is a software development framework that is not meant to run on its own. Because BizTalk is a product, it also costs a lot more than Windows Workflow Foundation, which is free. The Enterprise edition of BizTalk 2006 currently costs $29,999, and for that price tag, you get the application integration features previously mentioned. In addition, Windows Workflow Foundation does not include technology out of the box that parallels the BizTalk adapter and schema mapping functionality.
After reading the previous paragraph, you might be wondering what is so great about Windows Workflow Foundation compared with BizTalk. BizTalk is not better than Windows Workflow Foundation; it is simply different. First, not all development efforts require the enterprise-level features BizTalk provides, such as guaranteed message delivery.
In addition, you can use Windows Workflow Foundation in scenarios where BizTalk would not make sense, and vice versa. For example, if you’re tackling the problem of integrating internal applications and external business partners on a singular platform, BizTalk makes sense. However, when you’re automating a process that does not contain an integration component, Windows Workflow Foundation might be a better solution.
Windows Workflow Foundation also provides functionality that BizTalk does not. For example, BizTalk does not provide dynamic update. After an orchestration is defined at design time in a BizTalk project, it cannot change without a developer performing alterations and a redeployment of the solution. Windows Workflow Foundation also contains functionality for state-driven processes, whereas BizTalk does not.
Another feature specific to workflows is the availability of extensible activities. The shapes that come with BizTalk are set in stone and cannot be changed, and new shapes cannot be developed. This point plays further into the extensibility aspects of Windows Workflow Foundation compared with BizTalk - the workflow framework essentially is fully extensible. Although BizTalk is very customizable, there is a limit to what you can develop on its platform; the sky is the limit for Windows Workflow Foundation.
To reiterate, BizTalk and Windows Workflow Foundation are separate although complementary technologies that are meant to solve different categories of problems. You need to evaluate a project’s needs on a case-by-case basis in order to decide which software to use.
Because BizTalk’s concept of visual orchestration is similar to what Windows Workflow Foundation provides, Microsoft has announced that the next version of BizTalk (likely around 2008) will use that framework as its core for the orchestration component. This makes sense because it is probably not a great idea for Microsoft to maintain two separate process design technologies going forward. This is also good news for developers because it signifies that Microsoft is serious about supporting Windows Workflow Foundation in the long term.
The integration between Windows Workflow Foundation and SharePoint will likely be an extremely compelling area as the workflow platform becomes more widely adopted. SharePoint, Microsoft’s answer to portals, is a server-side product for activities such as team collaboration, document management, and search.
End users of the SharePoint web front end are able to create sites and web pages related to different topics as well as customize these items to fit the different needs of individual organizations. For example, a project manager could set up a site to monitor the progress of a company’s latest acquisition efforts. Other sites and pages might be set up so that developers can share technical articles found on the web. Figure 3-9 shows a sample SharePoint site.
Because document management is one of SharePoint’s strong points, the adoption of workflow is an obvious progression. Typical scenarios will include document approval and expiration, and some of this technology is included out of the box. However, because workflows are able to run in the context of SharePoint, there will be many scenarios geared toward specific business domains. Insurance claim processing and HR-related tasks come to mind.
InfoPath is another increasingly popular front end for process-based software. InfoPath is used to easily model data entry forms. In the past, developers had to create ASP.NET web forms or Windows Forms applications for even the simplest of data entry scenarios. InfoPath provides a rich interface that can be used by developers and end users alike to create and deploy forms. InfoPath 2003 was a client-only tool, so the end user was required to have the InfoPath software installed on his or her machine to fill out developed forms. In Office 2007, the InfoPath Server does not have this requirement. Forms are designed and deployed to the server and then, when requested, are rendered in HTML and displayed in the ubiquitous web browser.
Because workflows should easily interact with people, InfoPath or another forms technology is often a natural fit. A form requesting assistance from the help desk might actually kick off a workflow, whereas another InfoPath form might enable the help-desk worker to update a user’s case. Figure 3-10 shows a sample InfoPath form representing an expense report.
Chapter 15 goes into more detail about how Windows Workflow Foundation fits in with the Office and SharePoint technologies.
Chapter 1 gave a short introduction to service-oriented architecture (SOA). Windows Communication Foundation (WCF) is Microsoft’s next-generation platform for developing distributed, or services-oriented, applications. Although Windows Workflow Foundation and WCF are two mutually exclusive pieces of technology, they can also go hand in hand.
Just as activities are the building blocks of workflows, services are the building blocks for SOA. Furthermore, services are generally built to support business processes. They are meant to perform one discrete piece of functionality and nothing more. This means that typically services are meaningless by themselves. This is where workflow comes into the picture. Workflow can orchestrate these standalone services into a meaningful set of steps governed by rules and logic.
Chapter 14 provides more insight into WCF and how it relates to Windows Workflow Foundation.
Because workflows can be hosted in any type of .NET application, in many respects ASP.NET is no more special than a Windows Forms or a console application. However, anyone who has done web development can attest to the fact that there many factors that set the web paradigm apart from other forms of client-side development.
The most glaring characteristic of web development is the fact that it is a stateless environment. This means that every request made by an end user is separate from any other request made by the same user. Web development platforms such as ASP.NET provide the infrastructure to deal with these issues using concepts such as Sessions and ViewState.
Another trait that sets web development apart from Windows development is the fact that the user has a different experience related to processing and UI interactivity. On the web, a page isn’t returned until it is processed and ready for viewing. In Windows, the UI is always visible even if something is going on in the background. In this case, developers generally perform long-running tasks asynchronously so that the UI appears to be responsive and the user is able to interact with the form even if other work is being done behind the scenes.
By default, workflow instances are started asynchronously and control is immediately returned to the host. Although this behavior may be desirable in a Windows application, you may not want this to occur in your ASP.NET applications. The workflow platform enables you to modify this type of behavior.
Windows Workflow Foundation’s relation to ASP.NET is discussed in Chapter 13.