I recently attended the DevLink event in Murfreesboro Tennessee and participated in an open space (which oddly enough I submitted) about “selling” SOA to clients. Specifically the talk was around how to communicate the benefits and opportunities that moving to a service oriented architecture can bring to an Enterprise.
As with many discussions of this nature that I’ve taken part in (and despite my best efforts) the topic of the discussion started to turn toward discussion of specific middleware providers. An issue raised by one of the participants was that it was difficult to sell a client on BizTalk when the belief is that Microsoft Workflow Framework (WF), coupled with Microsoft Communication Foundation (WCF) provided the same functionality as BizTalk orchestrations and was free. It was clear that the group needed to take a moment and discuss the difference between an orchestration and a workflow.
Apples and Oranges – The Basics
Generally speaking, a workflow is a small series of steps that performs a specific task yet is generic enough that it can be used in a wide variety of applications. Workflows can be deployed as standalone entities in a SOA or can be implemented as a part of a smaller application. Workflows are best when they are performing short, quickly completed tasks that require little or no human interaction. For the most part, workflows do not enlist long-running processes or services that cross company boundaries as described by the WS-Choreography standard. Tasks that are good candidates for Workflows are things like validating an address against a central database or scoring a credit report.
An Orchestration is a larger and more complex interaction of services and resources within an Enterprise and its trading partners. Orchestrations are usually longer running and may have steps and processes that require human interaction. An Orchestration can implement processes that cross corporate boundaries and interact with Orchestrations, Workflows and processes running in a trading partners domain. This is made easier by implementing the WS-Choreography standard.
Orchestrations can be composed of Workflows. Workflows can launch Orchestrations; however in general will not wait for a long-running Orchestration to complete or need to know the disposition of the Orchestration to proceeded.
Apples and Oranges – An Example
Let’s look at an example of a Workflow:
An application receives a customer order message. A Workflow is launched that examines the order and verifies that the warehouse has enough of each item ordered on-hand to fulfill the order and ship it immediately. If there are enough items in inventory to complete the order, an Order Picking and Packing Workflow in launched to print a pick-sheet and shipping information for the order fulfillment staff to fill and ship the order. If there is not sufficient supply of the items the Workflow can determine, based on a set of business rules, if the order should be split in two, with the available items being shipped immediately and the remaining items being placed on back-order, or if the whole order should be placed on back-order to be fulfilled at a later date by a different process. If any items are placed on back-order an e-mail is generated and sent to the client and the clients account representative listing the back-ordered items. Also, when items are on backorder this Workflow launches another Workflow that informs a purchasing agent to order more of the back ordered item.
In this example the work flow is able to examine a warehouse database and make a decision based on the data it contains. When an item is not available, a rules engine can determine if the partial order should be shipped or the whole order should be placed on back-order. If items are back-ordered an e-mail is sent to the customer and the customer’s account representative. The tasks in this workflow can be executed quickly with no human interaction. It does not need to interact with processes or services in a trading partner’s domain. This Workflow makes quick, simple decisions based on the information readily at hand.
Admittedly, this Workflow is a little simplistic. There’s a lot more automation that could be added here. Let’s look at this same scenario as an Orchestration:
A service hosted by the Enterprise receives a customer order. An Orchestration to handle order fulfillment is launched. The Orchestration launches a Workflow that verifies that the warehouse has enough of the ordered items to fulfill the order. If the Workflow indicates that there are sufficient items in inventory to place the order, the Orchestration launches an Order Picking and Packing Orchestration to have the order picked and filled. Once the Order Picking and Packing Orchestration confirms that the order is picked and ready to ship, the Orchestration uses a series of business rules to determine the preferred shipper based on a series of criteria (weight of shipment, speed to destination, availability of insurance, price) and invokes an Orchestration at the appropriate shipper to have the package picked up and add the shipping to the Enterprises monthly shipping invoice.
If there is not sufficient supply on hand to complete the order, the Orchestration will use a series of business rules to determine if the partial order should be shipped or the whole order should be held till it can be fulfilled at the same time. If the partial order can be shipped, the Orchestration splits the original order into two separate orders. The shippable order is picked, packed and shipped (using the Shipping Orchestrations described above.) A Purchasing Orchestration is launched that based on a set of business rules either orders more items or notifies an Purchasing Agent that more items are needed. An e-mail is sent to the client and the clients account representative explaining the back-order and provided expected shipping date (if available). The Orchestration periodically checks to see if the back-ordered items are available until the entire order is shipped or the order is canceled.
As you can see, our Orchestration of the order fulfillment process is much more complex. In addition to all the functionality that was provided by the Workflow version, our Orchestration invokes other Workflows and Orchestrations, some of which are owned by trading partners. It waits for human interaction and enters a possible long-running state if items are placed on backorder.
Which to Use and When
So, since Orchestrations are more advanced, they’re better, right? Well, not exactly.
Orchestrations generally need to run on a middleware product such as BizTalk. There is additional cost and complexity with this type of solution in hardware, software and training. On the other hand, middleware products provide for robust message routing and long running transaction processing. A home-grown WF/WCF solution will not provide these out of the box. It can be built-in, but this will incur a large amount of expense and development that likely do not provide strategic value to the Enterprise.
While a custom-built solution using WF/WCF will not provide the functionality of a middleware product like BizTalk it can be idea for small, departmental applications that do not require the features of a full-blown middleware solution. In all likelihood your development staff already posses the knowledge and experience to implement a solution based on WF and WCF and moving to a middleware product when (if) the time comes is not difficult.
In Conclusion
It’s important as Architects to understand the distinction between Workflows and Orchestrations and when/how they should be used. Trying to use a Workflow to do an Orchestrations job is going to lead to a lot of “plumbing” code that adds little business value to your solution. On the other hand using an Orchestration where a Workflow is better suited is kind of like trying to kill a fly with a shot-gun; you’ll get the job done, but you’ll end up creating a lot more work for yourself. Always remember the Architects mantra: It depends…
written by James Bender
James has been involved in software development and architecture for 13 years. He has worked as a developer and architect on everything from small, single user applications to Enterprise scale multi-user systems. He is currently an Architect with Quick Solutions in Columbus OH, leader of the Columbus Architects Group (ColARC) and Senior Editor (First-Party Content) for nPlus1.org. You can read his blog at www.jamescbender.com
Subscribe (RSS)
