- Some Welcome Enhancements to the IDE
- Develop User Applications
- Write Connected, Service-Oriented Solutions
- Work with Data
- The Visual Studio Product Line
- Summary
Write Connected, Service-Oriented Solutions
Many business applications involve specific processes, or workflows, around documents, records, and related data. These business processes typically involve staged review and approval by business personnel; they might also require communication between various systems. A business process is also typically long-running—meaning the process is not a simple, single execution but rather a multistep process that has to "wait" before moving to the next step.
Building these processes into business application was typically a lot of custom development work with little guidance, or it meant tying your application to third-party tools. Web services helped but developers lacked an easy way to build them with support for multiple protocols, different transports, strong security, and transactional support.
Visual Studio 2008 now provides in-the-box (and in the .NET Framework) support for building business processes as workflows and reliably integrating them with other applications, systems, and partners. This section takes a look at Windows Workflow (WF) for defining reusable business process and Windows Communication Foundation (WCF) for unlocking that business process across system boundaries.
Develop an Application/Business Process
A workflow represents a set of actions (called activities) that are taken based on one another, business rules and conditions, and user actions. Workflows typically model business processes and often involve user interaction. Windows Workflow provides a framework, tools, and an engine for enabling workflows in your application. With it, you can create a workflow and know that it will run wherever the .NET Framework is installed.
You interact with workflows from within your application. This could be any type of application (Windows, ASP.NET, console, service, and so on). You typically submit data to the workflow and you might get a response, or you might use the workflow to kick off certain tasks or activities in your business process. The workflow can also persist itself during long-running transactions and then rehydrate on demand.
Two principal workflow types are built into Visual Studio 2008: sequential workflows and state-machine workflows. A sequential workflow follows a series of steps from top to bottom (as you design). Each step is gated based on the prior step and perhaps a set of conditions. A state-machine workflow, on the other hand, responds to different states (think status) being passed into the workflow. The states provide the gates between other states and may also trigger certain events.
You choose your workflow type at design type. There are both sequential and state-machine templates. Figure 1.35 shows an example of the workflow templates built into Visual Studio 2008. Notice also the SharePoint workflow templates. These provide the same workflows with extra hooks for SharePoint developers.
Figure 1.35 Creating a sequential workflow application.
Building a workflow is a very visual process. The thought behind this is that workflows themselves are traditionally illustrated as a set of steps (boxes) and connections (arrows). You still have access to code, but the designer provides a strong visual tool for building both sequential and state-machine workflows. With it, you can indicate a start and end point, add activities to the diagram, and configure each activity in terms of its task.
Figure 1.36 shows a sequential workflow inside Visual Studio. On the left are the workflow activity shapes. You use these to visually represent your workflow. Each shape has a set of properties that require developer configuration. This simple workflow example allows for the approval of a sales quote. There is an if/then condition set to determine whether the sales quote requires approval. If so, the quote waits (or listens) for approval. The quote is then either approved or rejected by a user. If the user does not respond in a timely manner, a timeout message is sent. You can follow this workflow through the visual representation in the diagram.
Figure 1.36 Designing a sequential workflow.
The workflow toolset also includes a basic rules and conditions editor. This editor allows you to set and manage workflow rules. These rules are then output as XML to be configured at runtime should the need arise. Figure 1.37 shows an example of the rules editor. In this dialog, the sales quote value condition from the previous example is being set. This condition is then attached to the if/then activity in the diagram.
Figure 1.37 Defining workflow rules and conditions.
Create and Consume Services
Most organizations have multiple systems, each designed for a specific purpose. They may have a financial system, HR, order management, inventory, customer service, and more. These applications each house specific business processes. However, most organizations need to unlock these business processes from their application and reuse them as part of an integrated solution. This is where service-oriented solutions have helped. By exposing an application's business process as a service, multiple clients can take advantage of that process.
The promise of code reuse has been with us a long time. However, service-oriented code reuse became very popular with the advent of web services. The ubiquitous nature of HTTP and port 80 coupled with XML-based interfaces allowed for a new level of communication between application boundaries. Developers began wrapping key business functions as services and calling them from multiple clients.
Visual Studio 2008 and the .NET Framework 3.5 represent another step forward in this service-oriented paradigm. With these tools, you can create services based on Microsoft's Windows Communication Foundation. WCF is a framework which recognizes that developers need multiple layers of communication (not just the SOAP protocol carried over an HTTP transport), require strong security, often need to support transactions, and do not want to write all the plumbing code to do so.
You create WCF services as a code library, as a workflow, or as a web service application. Figure 1.38 shows the new project templates listed under the WCF project types. From here you can indicate that your web service contains a workflow (think business process) or simply create a service library that will call custom code you write.
Figure 1.38 Selecting a WCF project type.
You can also still create .asmx web services through the web project templates. This same template area also provides access to the new, WCF Service Application template. With it, you can create a WCF service that is configured similarly to a web service.
WCF is all about configuration. It frees you from having to write all the service plumbing code. Instead, you can focus on the functionality of your service. For example, you can add service endpoints to your service depending on which communication stack you intend to support (HTTP, TCP/IP, MSMQ, Named Pipes, and so on). Figure 1.39 shows the WCF configuration editor. Notice how the binding support for an endpoint is a configuration (and not coding) task.
Figure 1.39 Configuration of a WCF service.