The term workflow is perhaps among the most overloaded words in the realm of software engineering, from computer science 101 to the most elaborate business systems it generally manages to carry weight on many an application design. In the upcoming paragraphs we will address one of the most recent additions to this space: Windows Workflow Foundation and how it will influence service-orientated designs.
Workflows lend themselves to the granular nature of services. In other words, services fulfill a very small unit of work in favor of being reusable for many different scenarios, this in turn creates the possibility of stitching together an innumerable number of outcomes as workflows, so at a very simplistic level a workflow is nothing more than a series of services glued together to fulfill a particular business process.
In the very specific case of services, many approaches have emerged to solve this workflow problem: WSFL (Web Services Flow Language), XLANG (Web Services for Business Process Design) and ...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
BPEL (Business Process Execution Language), to name a few. Among them, the one with the most traction is without a doubt BPEL, in part due to its backing not only from major industry vendors, but also from boutique shops specializing in service-oriented architectures.
But while BPEL provides the semantics and depth to orchestrate elaborate Web services scenarios, it's still relegated to a niche status confined to the services world. If you ponder the aspect of creating workflows strictly from services, you will arrive at the very realistic conclusion that workflows in many enterprises require the integration of non-serviceable legacy applications or even non-system human tasks, workflows that would fall beyond the scope of BPEL or any other orchestration technique currently applicable to SOA. In light of this last possibility comes Windows Workflow Foundation (WF) .
The basic premise behind WF is that the nature of a workflow lends itself to span across many different tiers or software components. Think of a workflow composed not only of Web services, but one that can be combined with desktop applications, Web services and legacy systems. It's a powerful abstraction, being that a workflow's parts need not be serviceable -- in the strict SOAP/XML sense -- required by approaches like BPEL.
WF is of course tightly integrated into Microsoft technologies, but its architecture has many similarities to what you may have experienced with other Web services workflow engines. At the heart is the WF runtime, which provides the backbone to execute and coordinate workflow instructions, a component that would be analogous to a BPEL engine.
But contrary to a BPEL engine which forms part of a server-tier deployment, the architecture behind the WF runtime makes it deployable not only in the classical context of Web services on the server side, but also embeddable in other applications like those on a desktop -- such as Office -- and any other application that can be linked to the .NET framework, which is the main building block for current Microsoft technologies.
For defining workflows, WF leaves the door open to use any .NET-targeted language or the preferred language named Extensible Application Markup Language (XAML), a process which allows users to create workflows with previously known languages, something that is in stark contrast to many workflow platforms which require learning a specific language in order to attain proficiency with the tooling.
While WF is still in its infancy in terms of adoption, it's a worthy undertaking since it attempts to provide an all encompassing approach to an old problem. But where does this leave the development of Web services workflows as we know them or approaches such as BPEL? The short answer is, with a more powerful supplement to structure workflows.
As it turns out, WF ties into two related Microsoft initiatives which play a role in placing its workflows in the context of Web services: WCF (Windows Communication Foundation) and BizTalk Server. You can obtain more background on both project in the previous columns: WCF: Microsoft's 'newest' services way and BizTalk Server: Microsoft's SOA building block .
BizTalk server is Microsoft's answer to solving the enterprise integration issues common to service-oriented architectures, which in itself has the capabilities to orchestrate service workflows based on industry accepted standards like BPEL. But as it name implies, this platform is designed to operate on the server side, and, as mentioned previously, BPEL does not lend itself to managing workflows beyond the context of services.
Building on this limitation, WF's focus is to offer an environment in which to execute workflows irrespective of their location and also regardless of the type of tasks to be fulfilled. To this end, BizTalk server can be embedded with a WF runtime capable of supplanting and enriching a BPEL-type approach, opening the possibility to include desktop type applications with services. But perhaps more importantly, once workflows are structured in the form of WF contracts, the possibilities for executing/deploying workflows become even more powerful given the lightweight/embeddable design of WF.
With this we conclude our overview of the Windows Workflow Foundation, a technology which along its closely linked projects -- Windows Communication Foundation and BizTalk server, all of which are under the broader umbrella named WinFX -- will form part of the next generation Windows platform designed to deal with the creation of service-orientated applications.
About the author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at: http://www.webforefront.com/
