Local Communication Services Explained
As promised. Here is a small tutorial/walkthrough/explanation of local communication services. There are probably other write-ups available, I just felt compelled to write this one up. This applies to Windows Workflow Foundation Beta1 and is still subject to change.

Introduction
Among many, one of my favorite explanations of a workflow… “a workflow is responsible for coordinating work which exists outside its own context. “
Given this definition, being able to communicate to entities external from the workflow is key to a successful workflow platform. There are many means of communications within Windows Workflow Foundation (queues, web services, parameters) but the one I’m writing about today is called Local Service Communication.
Local Service Communication allows a workflow to communicate with services/objects which reside within the host.
I’ve chosen to write about this one because from experience, it seems to be the most difficult topic to understand within the entire Windows Workflow Framework. To that point, I’m not going to talk about advanced messaging constructs like correlation, in-order delivery, convoys etc.
For the purposes of this blog entry, let’s take a simple loan approval scenario.
A host application will submit a loan application which includes loan name and loan amount to the workflow. Depending on the loan amount, the workflow will return back to the host the approval or rejection of the loan.
In this sample, our host application will just be a simple console application.
Moving Parts
As depicted above, there are three ‘core’ moving parts you need to think about when the local communication services
- The Communications Interface
- The Workflow
- The Host/Application
Conceptually, the single most important concept that will help you understand this topic is:
Data from the host to the workflow is passed through events.
Data from the workflow to the host is passed through method parameters.
Communications Interface
You can think of the communications interface as a contract between the workflow and the host application. This contract defines how the workflow and host will communicate with each other.
This contract is relatively straight forward. It’s a .NET interface with methods and events. You can see an example below. We’re exposing two methods and event. The methods are used by the workflow to notify the host if the loan is rejected or approved. The event is used by the host to submit the loan application to the workflow. Notice the [DataExchangeService] attribute.

You’ll notice that LoanEventArgs derive from WorkflowMessageEventArgs. Further, the constructor takes the LoanName and LoanAmount as arguments, but it also takes an instanceId which is passed to the base. The instanceId will be provided to us by the host (shown and described later) and is used to identify which workflow instance the host is sending and receiving messages from. You events must always derive from WorkflowMessageEventArgs.
As you’d expect, we’re also defining the loan name and loan amount as part of the event args.

The workflow
The communication interface (contract) between the host and the workflow has been established. Now the workflow needs use that contract to send and receive to the local service.
Just to re-cap, this workflow determines if the loan approval is accepted or rejected. The workflow will get the loan information from the host (via the event), then make a decision based on a rule (not covered in this blog entry) to determine if it should be approved or rejected. A simple diagram is shown below.
The way the workflow communications through the interface and to the host is through two activities: EventSink and InvokeMethod.
Conceptually, think of getting data into the workflow through EventSink(s) and pushing data out of the workflow through InvokeMethod(s).

The code below shows the definition of the EventSink activity within the workflow. You can see that the activity’s interface type is set to ILoanService and it’s syncing with “SubmitLoan”. The activity also pulls out the Loan ID (the name) and Loan Amount through parameter bindings. Note: this code would be generated for you if you use the designer.

The code below shows the definition of the InvokeMethod activity within the workflow. You can see that the activity’s interface type is set to ILoanService and it’s calling the “LoanApproved” method. Again, this code would be generated for you if you use the designer.

Host
Ok, we’ve defined the communications interface and the workflow we want to use to back our app.
The first thing we need to do is provide an implementation of the communications interface. This class will inherit from the ILoanService and provide the implementation for the two methods we defined. These are the methods which will be called by the workflow via the InvokeMethod activities. In this case, the implementation just outputs to the console.
As part of the implementation of the interface, we also need to implement the SubmitLoan event. You can see that I’ve created a method which then calls the event with the instanceID, the name of the loan and the loan amount. Exactly as is defined in the EventArgs.

We still need to get the instance ID from the runtime. But before we do that, we need to register our local communications service with the workflow runtime. As you can see below, we create a new LoanService and register it with the runtime. You’ll notice that the LoanService class also has an instanceId field. This value is the unique identifier of the workflow instance. Finally, we call the SubmitLoanToWorkflow we defined in our implementation of the communications interface, which will thus raise the event and kick off the workflow.

PDC Keynote videos now online
You can find them here.
I use my hands to talk. During one of the dry runs, John noticed that I occasionally made fists with my hands.
To help me relax, he made a comment along the lines of "only dictators who are invading countries close make fists when they give a talk". It cracked me up, and if you watch carefully, you can see me consciously think about opening my hands.
I'm writing up a lengthly article on how a specific communications feature with Windows Workflow Foundation works... keep your eyes open in the next few days.
Welcome Akash & Aditya
Welcome Aditya & Akash to the blogger world!
Aditya is the primary developer behind System.Workflow.ComponentModel.Design. He's extremely knowledgable in the Designer Component of the Activity Component Model, designer rehosting and pretty much everything you see in the Visual Studio Workflow Designer.
Akash, besides a deep understanding of the workflow framework, is the developer you can thank for the workflow debugger.
I took a bit of a breather after PDC to get over a cold and catch up on things I'd been ignoring until PDC was over.. expect to see a lot of activity on my blog and replies to your emails this week!
Workflow Installation Woes? Look here..
We've seen a lot of installation issues on the Windows Workflow Foundation forum. James created this post to help a few people out...
RSS Link Fixed
I took a bit of time off this week, taking care of the little things you forget when you prep for something like PDC (like renewing your car tabs!).
Part of this cleanup was figuring out why my RSS feed was broken.. it's fixed now.
If you didn't get a chance to come to PDC and watch the talk on Custom Activities, Bob Schmidt is doing a repeat of the session on Friday. Bob is a great presenter... definitely check it out!
Why workflow matters... custom activities.
Unfortunately, Dharma and I didn't get a chance to present at PDC this year. However, I think this proposed dialog/script provides an insight into
- why workflow matters
- why custom activities are so important
- some of the key tenets of Windows Workflow Foundation
Dennis: Do you remember one of our first conversations? I asked what "workflow" meant to you...
Dharma: Yeah I remember, one of the things I said was that a Workflow is an organization of activities.
Dennis: But why is a workflow is an organization of activities?
Dharma: Well, a workflow is a hierarchy of activities that in turn describes the control flow of the application in an explicit way. Control flow in an application are things While, IfElse, ForEach etc.
So, tied to this control flow is the declarative representation of the flow of data and other behaviors. You see, each node of the control flow is an activity.
Dennis: Right. so the arrangement of activities creates the control flow of the application. Why should the control flow be explicit? What is the value in making this explicit?
Dharma: Well, the more explicit the control flow is, the more a framework can reason over it. You see, one of the key things CLR enabled the type information explicit and ubiquitous. Today, you can walk up to any assembly and reflect on it and get the type information in a consistent way.
But you still do not have a way to reflect over the control flow of the application. The way the data flows. The way the application interchanges messages with the external world. Or the way the application does exception handling or deals with concurrency. All of which is buried and lost in some opaque code.
Dennis: Ok, but why should a runtime required to reason over the applications control flow or other behaviors?
Dharma: The simple answer is developer productivity. The more explicitly and declaratively you and I as programmers can express our intent to the underlying runtime, the more semantics we can push it down to the platform. For instance, I can ask the runtime to manage my state, I can have the runtime to take care of transactions, concurrency control and so on.
Dennis: How about this for an analogy: Today, an application expresses its intent to the .NET runtime in terms of CLR metadata and IL opcodes. These are the lexicons that the CLR understands. So, as long as you write your app in terms of the CLR metadata and IL, CLR will provide a certain set of execution guarantees and a managed execution environment.
In the same way, so long as you express your program semantics in terms of activities, the underlying WWF runtime can provide managed execution and can provide certain guarantees to your workflow. The Workflow Foundation runtime provides program durability, state management, transaction and compensation, concurrency control etc. to your application. Is that a fair analogy? Is that right?
Dharma: Exactly! Except, unlike IL, the vocabulary which you use to describe the semantics of the workflow is extensible. That is by design because we could not predict all the ways you could describe the control flow of you application.
Dennis: So clearly, this session is all about extending the workflow vocabulary.. or in other words, writing custom activities
Dave joins the workflow blogging world..
Dave, an Architect on the Windows Workflow Foundation has joined the blogger world.
I think he's the first person I heard use the expression "Guilding the lily"... clearly, he's an Englishman! Welcome Dave!
One last article link...
They even mentioned parts of my keynote demo!
http://www.internetnews.com/dev-news/article.php/3548656
Sites to learn more about Windows Workflow Foundation
Here are the Microsoft sponsored sites..
http://www.windowsworkflow.net/Default.aspx?tabindex=0&tabid=1
http://msdn.microsoft.com/windowsvista/building/workflow/
http://www.microsoft.com/presspass/press/2005/sep05/09-14PDC05Day2PR.mspx
And some other articles..
http://www.microsoft-watch.com/article2/0,2180,1859045,00.asp
http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId=170702983
Windows Workflow Founation
Two-ish years ago, I joined a team focused on delivering workflow to the .NET Framework.
Today, after years of work by a LOT of people, the Windows Workflow Foundation is born to the world.
Just getting off stage at the PDC in EricR's keynote, you could feel the developer excitement!!
.NET developers: get ready to revolutionize the way your write apps!
Only a few hours away...
Dry-Runs? Check.
Demos? Check.
Key Points? Check.
Today, Microsoft will provide developers the key tool and platform they need to be successful writing connected system applications.
More after the keynote!
Live from Backstage..
Sitting around with the keynote crew.. it's pretty exciting. Pictures coming soon!
In LA!
Arrived last night into LA with Dharma. We're heading off to the Convention Center now to scope everything out.
As practice makes perfect, the EricR keynote team will be there most of the day :)
Tag: PDC05
One of the coolest domain names
http://www.thispointer.com - is Ramraj's website... a co-worker of mine.
One of the most intune guys with MS technologies I've ever met..
Keynote Jitters
Participating in the preparation of the Eric Rudder PDC05 keynote has been arguably one of the most anxiety filled, exhausting, exhilarating, painful, fun, annoying, hard, ego-bruising, ego-building, eye-opening experiences I've gone through at Microsoft.
I look back at Chris' experiences and can relate to every single one.
MANY late nights (including this one) working on demos, tweaks, messages, scenarios...
We're getting close and soon I'll be focusing purely on 'romancing the talking points' -- a term I'd heard only for the first time this week.
Next stop.... LA!
Making fantastic progress on the keynote
Exactly a week from today, I'll be on stage with Eric talking about the new technology Microsoft is providing developers (the one my team has been developing).
Last night was a semi-marathon session with the keynote crew.
It started off with the weekly Vic Gundotra/CharlesF/Steve Cellini review and then a 4-9pm meetihng where John Montgomery played the role of "Task Master" to make sure the demo really kicks butt.
I've seen it. You'll be amazed.
We're building some really really hot tools for developers... come to the keynote and see them in action!
One kick-a** Evangelist
James Conard is the "Architect Evangelist" for the technology I work on. He's been silent on his blog for a long while... we've been putting him hard to work :)
Without question, he's one of the best 'non PM/Dev/Test' assets our team has.
I look forward to reading his blog... if it's at all reflective of the work he's put into our technology, it'll be one of the best resources on the net.
More details on Sept 14th (launch!!)
PDC! PDC! PDC!
T mins 4 business days... PDC is coming up full speed ahead.
The team who's participating in Eric's keynote has been meeting on daily basis... tweaking and perfecting the demos, slides and messaging.
I can't recall the last time I received so many auto-response "I'm working on PDC, so email responses will be slow" emails.
Ok, back to working on my demo :)