Chapter 14: Windows Workflow Foundation and Connected Systems

This chapter is about how workflows relates to connected systems. Workflows sometimes need to talk to the outside world, and conversely, the outside world may need a way to call in to a workflow. Web services can serve as a great way to provide widespread communications in software; therefore, this chapter includes an in-depth discussion of these services.

In addition, there are architectural issues that you need to consider before applying workflow and web services in your organization. Services-oriented architecture (SOA) has been a very popular buzzword in recent years, and when studied and applied sensibly, it can greatly enhance a company’s ability to componentize software and become more agile.

This chapter also covers a new Microsoft technology referred to as Windows Communication Foundation (WCF). WCF encompasses a great deal of functionality related to developing connected systems, and not just around standard web services. You can also use WCF in conjunction with Windows Workflow Foundation to expose workflow functionality outside the bounds of a single application.

Connected Systems and Services-Oriented Architecture

Connected systems and SOA are two often-overloaded terms (connected systems probably more so than SOA). Connected systems can be defined as a concept that has software applications communicating through services. Although these services are commonly XML web services, they do not have to be. E-mail and FTP are other ways in which applications can communicate with one another as well as people. For example, the software system at a company that sits there and waits for orders from the outside world can be considered a connected system.

SOA is a bit easier to define. However, the concept of SOA is still discussed with great passion today, and there are different ideas about what it means. As its name implies, SOA is a way of building systems using services. Although services are commonly implemented with web services, it’s not a requirement. Services generally do a single thing well while having no knowledge of other tasks. This concept of having many individual services allows a building-block approach to developing software.

If an organization has a suite of dozens of services that all do different tasks related to the business, building new software applications can become a matter of grabbing one service from here and another service from there. Services can also be exposed by parties outside the organization. The beauty is that no matter what the service is, what its interface is, or where it originates, it can be brought together with other services to provide something useful.

The technology community has generally accepted the following four tenets to describe what SOA is and how SOA services should behave:

• Service boundaries are explicit.

• Services are autonomous.

• Services share a schema and contract.

• Service compatibility is based on policy.