Matias Woloski’s Blog

While reviewing DinnerNow.net I found an interesting workflow implementation.

Scenario:

A customer place an order for food from multiple restaurants. DinnerNow acts as a hub that will grab the order, will check each item and will group them by restaurant.

How this is implemented? They have two workflows:

• Sequential: this workflow receive a customer order, splits and gorup the order items within a set of restaurant orders. For each restaurant order a state machine workflow is started.
• State machine: this workflow represents a single order workflow (open, ready for pickup, delivered, payed, complete)

You can download DinnerNow today and see this workinf in NET 3.0.

We’ve been working on some training material lately to show how to do this using NET 3.5. There is a new feature code-named "Silver" (read more on Matt Winkler blog) that basically are a couple of activities to integrate Workflow Foundation with Windows Communication Foundation: the ReceiveActivity and SendActivity.

The following illustration shows how to implement a splitter workflow exposed as a service with WCF:

This workflow is hosted using the new WorkflowServiceHost (that derives from the regular WCF ServiceHost). This new host will read the workflow and will associate the endpoints configured with specific contracts with the workflow implementation.

If you do the analogy with WCF, in WCF you create a service interface and then the implementation with a regular c# class. With Workflow Services you create the interface but the implementation is the workflow itself! And even more easy you can embed the contract metadata in the workflow and the host will read it and associate them with the endpoints.

When a client make a call to the PlaceOrder operation of the IOrderWorkflowService, a new workflow will be started (there is a property in the ReceiveActivity called CanCreateInstance to tell the runtime to do so). This call will be syncrounous but the workflow will start running and will split the orders.

The replicator is similar to a "foreach" statement but it can execute either in sequential or paralel. The first activity that executes is a "SendActivity". This is the counter part of the other activity and will allow calling a service. Either we can call a regular service or we can call another workflow that has a ReceiveActivity listening. And that is what we are doing here: a workflow conversation where the sequential calls the state and when the state finishes it will call the sequential again.

Of course, you will need to somehow manage a context between calls. If not how the workflow knows if you are refering to instance A or instance B.

We are provided with a new set of bindings that allow to do that (netTcpContextBinding and wsHttpContextBinding). This bindings provide a property to access the context:

proxy.PlaceOrder(order);
IContextManager cm = proxy.InnerChannel.GetProperty();
IDictionary<XmlQualifiedName, string>  context = cm.GetContext();

This context will have the workflow instance id of the recently created workflow. You can add things to the context and read them on the client and the workflow.

IContextManager cm = proxy.InnerChannel.GetProperty();
cm.SetContext(context);
proxy.UpdateShipping();

In the case of the child state machine workflow, how do we know which sequential workflow to return after we finish the order process? Simply, we bind the context on the ReceiveActivity of the initial state to a workflow depdendency property. This context is the one sent by the SendActivity of the parent workflow. Then when we get to the complete state we bind the saved context to the SendActivity.

More info:

Matt Winkler’s blog

Alex Thissen blog

Ezequiel Morito posted on his blog a hello world tutorial in spanish for the march ctp

Go get it from http://msdn.microsoft.com/webclientfactory

Lot of stuff shipped:

• PageFlow Application Block: design the navigation process of a web application using a state machine from Windows Workflow Foundation.
• Composite Web Application Block: helps you build web clients composed of independent, yet cooperating, modules and increase productivity and reduce overall development time through consolidating architect and developer efforts. From the wiki:
  • Decompose a complex Web site into independent visual and non-visual parts that can be built, assembled, and deployed by independent teams.
  • Minimize cross-team dependencies that allows team specialization for areas such as UI design, business logic implementation (business logic development may occur across multiple teams), and infrastructure code development.
  • Utilize an architecture that promotes reusability across independent teams.
  • Increase the quality of applications by abstracting common services that are available for the independent teams to use.
  • Promote proven practices for security without requiring everyone to be a security expert.
  • Incrementally deploy new capabilities while minimizing downtime.
  • Maximize the coverage of automated tests in the code base.
• Object Container DataSource: this is a web control similar to ASP.Net ObjectDataSource but instead of relying on a class that provides you with data it will raises events when it needs the data or when the data contained changes (insert/update/delete). This design allows the view (Web page) to delegate the responsibility of performing select operations, update operations, delete operations, and insert operations to the presenter.
• Web Client Development Automation: I posted about this already.
• QuickStarts: these are the quickstarts included: View-Presenter (with Application Controller), ObjectContainerDataSource, Modularity, Page Flow, Page Flow with Shopping Cart
• A Reference Implementation: this is a banking application inspired in a real world example to demonstrate the guidance in action.
• Documentation, How-Tos, patterns, etc.: available when you install the factory and soon to be published in the codeplex community

It was 6 months of hard work and it was great working again with the patterns & practices team: Blaine (PM), Eugenio (PDM), Mike (Dev Lead), Ed (Architect), Johnny (Dev), Mariano (Dev), Alan (Dev), Bob(Dev), Dragos (Architect), Tim (Tech writer), Juan Carlos (Dev), Prasad (Test) and Terrence (Test).

It was the last week during the Strategic Architecture Forum (SAF) here at Redmond.
More than 250 architects from all over the world assisted to this event where Billg gave a 90 minutes Q&A session among other great presentations by the Architecture Strategy Team. Wojtek from patterns & practices presented CAB and the Smart Client Software Factory. Also there was lots of Software as a Service content

From left to right: Matias Woloski, Bill Gates, Eric Rudder (behind) and Mariano Szklanny

As part of writing my thesis about Software
as a Service, I started to collaborate with Gianpaolo Carraro and Fred Chong from the Architecture
Strategy team. The interaction with them has been great
so far and some of the topics we’ve been discussing included how to enable
workflow in a multitenant environment.

When designing an application that will be
delivered as SaaS you might want to provide tooling to your tenants to allow
them extending the data model, the business process, the UI, etc. to fit their
unique needs. While thinking about how to customize business processes I came up
with a maturity model that I found descriptive.

First, I asked myself this question: How
a workflow can change?

• Behavioral
  (decisions/rules)
• Structural
  (activities)

The behavioral changes are related
to decisions that are modeled in the workflow. Like “If the PO is greater than
X then…”. So for TenantA that value might be $3,000, but for TenantB it could
be $1,000,000.

Let’s focus on behavioral changes for a
moment. These are the maturity levels I recognize regarding this kind of
changes:

• Level 1:
  every workflow decision lives inside the workflow

  
  

• Level 2:
  same as level 1 but the decisions could be dynamically updated on runtime

  
  

• Level 3:
  externalize decisions on policy and rulesets providing change management

  
  

Level 3 is very interesting because:

• Rules can be versioned
• Rules can be stored outside the workflow
• Rules support forward chaining
• Rules expose business language

Structural changes, on the other side, are changes to the workflow structure itself.
Like “After the approval of the PO call a webservice on url X”.

Here I also identified a maturity model for
the adoption

• Level 1:
  design a basic set of workflow flavors and let the tenant decides

  
  

• Level 2:
  design a base workflow and let the tenant perform fixed customizations

  
  

• Level 3:
  design a base workflow and let the tenant perform modifications using a
  workflow designer which exposes business terms

  
  

Some images have been taken from the article "The Amazing Race Metaphor", Vignesh Swaminathan, Architect Journal, Issue # 7

In my next post I will write about how can
we achieve some of these maturity levels using

Windows Workflow Foundation!

// TODO: learn it and use it…

Some links
Windows Workflow Foundation Site
Introducing Windows Workflow Foundation by David Chappel
Getting Started with Windows Workflow Foundation by Dino Esposito

Dave Green Blog
WWF HOLs download
WWF Beta 1 SDK download
WWF on msdn

We are playing with it here at Southworks and  the design surface
looks very similar to Biztalk Orchestation Designer. As always,
starting with HOLs is the best IMHO.