Workflow and orchestration provides a declarative way to resolve common scenarios in service-oriented and integration solutions. In many cases, a business process will take minutes, hours, days or longer to complete. The system must persist not only the business data and state for the process, but the current step as well allowing the process to be resumed at a later time. Typical imperative style code hides the overall flow and steps of the process in disparate operations and makes it very difficult to understand without intimate knowledge of the business process. Workflows provided a declarative style approach that surfaces the business process and also introduced many infrastructure capabilities that naturally fit these long-running scenarios. Tracking activities, persisting idle workflows to a durable backing store for scalability and correlation to resume existing workflows became expectations on any middleware platform making workflows even more attractive to solve business problems.
Microsoft has made significant investments in these capabilities over the last decade, providing a variety of options for building workflow oriented solutions on-premise including Workflow Foundation (WF) and BizTalk Server Orchestration. These workflow engines generally relied on a messaging infrastructure (WCF or BizTalk Messaging) to deliver information to workflows. Service Bus gave us the first critical step for building out a true integration solution that worked at a cloud scale. While providing a PaaS messaging fabric was a significant step forward, it did not take long for developers to recognize key missing integration capabilities like pipelines, transformations and workflows.
Service Bus Integration Services/BizTalk PaaS, currently in CTP introduces key missing messaging capabilities including support for pipelines (bridges) bringing message validation, enrichment, transformation and routing to Service Bus. While these capabilities are critical to delivering real-world service-oriented composite solutions, the need for a process manager to orchestrate all of this messaging has been missing.
Welcome Workflow 1.0!
Fortunately, the wait seems to be over. This week Microsoft released the beta of Workflow 1.0. You can download the on-premise Beta here.
Wait. On-Premise? Don’t we already have a workflow host on-premise? Microsoft has traditionally taken a “cloud-first” approach to this new wave of middleware PaaS capabilities, promising symmetry and fidelity both on-premise and in the cloud. “SharePoint 15” utilizes this new workflow engine which drove Workflow 1.0 delivery on-premise first. The core design of Workflow 1.0 still centers around the Cloud and we should expect to see this capabilities offered in Azure sometime in the near future.
Let’s Take a Closer Look
The installation experience is pretty simple and will include an on-premise version of Service Bus Bus (please go here for an introduction on Azure Service Bus on-premise). The workflow engine is actually dependent on Service Bus for storing workflow persisted state and starting workflows.
Two main services make up the core workflow engine. The gateway service receives and processes management and runtime requests. The backend service manages the actual runtime workflows including starting new workflows, hydrating existing workflows and terminating workflows. The installation process also installs the configuration and management databases although most users will not spend time in these.
Most WF developers are already familiar with Activities, Workflows and Instances. Management of these artifacts in the cloud and on-premise falls to a new concept called a scope. Essentially scopes manage and secure Activities, Workflows and Instances of Workflows. Defining management and security boundaries becomes important as individual solutions will be deployed and co-exist with other solutions on the Azure platform.
Below are some characteristics of Scopes in Windows Azure Workflow:
- Activities, Workflows and Instances belong to a single scope.
- Scopes a hierarchical with parent-child relationships.
- Activities and Workflows can reference any activities in the same scope or any parent scope.
- Security settings such as managing scope entities and ability to publish to scopes are managed at the scope level. Child scopes inherit parent scope security settings.
- Entities must have a unique name in a scope. Parent or child scopes can contain entities with the same name.
Scopes currently affect deployment, management and runtime of workflows, activities and instances so start digging in to the concept as they will definitely affect how you design your Workflow 1.0 solution.
Something Old, Something New
Most of the shapes delivered in WF 4.0 still work in Workflow 1.0, so overall building workflows should have a comfortable feel for WF 4.0 veterans. There are a few activities that cannot be used in Workflow 1.0 and are listed below.
- WCF Messaging Activities
Hopefully we will see future support for the Transaction, Compensation and WCF Messaging Activities (at least outbound). These are important capabilities that will definitely make Workflow 1.0 a more complete workflow platform.
Workflow developers will also still have choice between Sequence, State Machine and Flowchart workflows. Microsoft has shifted the approach though with how we think about extending the existing workflow shapes. Previously when existing activities did not cover a scenario, developers had code activities, composite activities, native and dynamic activities to bridge gaps in existing activities. This approach showed up in most solutions as the existing activities were never meant to be comprehensive. What if you did not have to spend time building custom activities and what you wanted to do was already available?
When reviewing the new shapes available through the Microsoft.Activities assembly you’ll find a whole new set of activities. They range from mundane tasks like adding dates to more trendy activities like calling http services (HttpGet, HttpPut, HttpPost, HttpDelete) and working with JSON through DynamicValue activities.
While there are some great additions to the WF activity toolbox, there are also some changes that you’ll want to prepare for as you start to think about Workflow 1.0 in a PaaS capacity. Running workflows in the cloud brings up many questions around supporting custom activities, particularly because unlike on-premise or IaaS, your code is running on isolated but shared compute resources. For example, what if someone writes some really bad code that causes failures, eats up CPU time or any other evil scenario that we all have experienced (or caused)?
I believe it is impossible to cover every scenario developers will run into with out of box activities. For those concerned with relying on Microsoft to produce the appropriate activities for your workflow, there are capabilities to deploy code activities although the current version requires a few extra steps. Hopefully, we will see custom activity support work better out of the box in future versions. Stay tuned on this one.
One other important feature I have on my wish list is support for reading, writing and correlating workflows directly from Service Bus messages (Queues and Topics). This truly turns Workflow 1.0 into a Process Manager and would give us an easy button to work with the Service Bus messaging infrastructure.
Developers building workflow solutions should be pretty excited about these new capabilities for hosting and running workflows in the cloud! While the current Beta provides a peek at what the future of WF as a service will look like, it is important to remember that Workflow 1.0 is not yet feature complete and the PaaS version of Workflow 1.0 has not yet been released so there is still time to share your thoughts and feedback on what you like and what you’d like to see at release.
Go download the new bits and let me know what you think!