One of the core features of Windows Workflow Foundation that enables authoring workflows in a declarative fashion [1] is activity binds, which enable you to connect inputs of one activity with the outputs of another (or properties of the workflow itself), saving the developer from having to write custom code to move data from one step of the workflow to another manually.

Activity Binding is actually a pretty powerful feature and works fine in many cases. Unfortunately, it also has a few limitations. One of the limitations is the very basic support for binding against items in a collection.

To clarify, you can most certainly bind a property of an activity that has a collection type (say, a List<T>) to an property of another activity of the same type. However, there's no easy way to bind, say, a property of an activity of type System.String to a specific item in the collection exposed by another activity's property (for example, binding it to the fourth item in the list).

One thing that surprised me a bit a couple of days ago was that, actually, the core ActivityBind class almost supports this, it's just not exposed through the Workflow designer in Visual Studio. For example, if Activity a exposes a property of type Dictionary<string, string>, you can bind a System.String property against it with an expression such as this:

Activity=DictionaryWorkflow, Path=Phones["Mary"]

Notice how the last part actually especifies the exact item against which to bind. While a cool trick, this isn't nearly as useful as it may appear at first since a) it requires the user to manually and carefully edit the binding expression in the Properties window in the designer, bypassing the Activity Bind dialog and b) it's hardcoded.

One could imagine an extended support for this kind of operation having the ability to allow the indexer to be represented by a nested activity binding expression, though it's not clear yet to me how that would work out. Don't expect something like that anytime soon, btw.

The way I've worked around this limitation in the past has been to create my custom activity that needs the binding with two different dependency properties: One of a collection type, and one of the type of the indexer to bind. This way I can bind the collection property itself directly to the entire collection, and in the second property specify the item I want to extract the value for. In the example above, my custom activity would have two properties then: 1) PhoneDirectory and 2) PersonsName. Using those two at runtime the activity would have all the information needed available.

This works very well, but it's less explicit, it requires writing more code, and worse, does not work if you have to work with an existing activity you can't modify. In the latter case, I've sometimes used wrapper adapter activities, but it can be quite a bit of work (depending on the complexity of the activity being wrapped) just to get this functionality.

Dynamic Properties

A second limitation in the current activity binding mechanism is one I've already heard a few people complain about: You can't bind against a dynamic property. This means that if you have a custom activity that exposes a pseudo property at design time by implementing IDynamicPropertyTypeProvider and a custom activity designer, there's no way (at least that I've found) to bind a property in a different activity against it. 

Or at least, if there is, I haven't found a way to get this to work. Surprinsingly enough, you can do the opposite with attached dependency properties, though the syntax is a bit more awkward (and it does indeed subvert the mechanism a bit).

[1] Not that this is any easy at all to do in many cases with WF...

Windows Workflow Foundation

Paul Andrew announced recently a coming CTP [1] that will provide BPEL 1.1 support to Windows Workflow Foundation. This will provide a set of custom WF activities that map to BPEL 1.1 constructs as well as tooling to import BPEL processes into WF XAML workflows and export the other way around.

I think overall this is very good news and, as Paul says, highlights the power and flexibility offered by the domain-neutrality of the WF runtime. Paul also mentions that this will, in the end, be supported in a future release of BizTalk Server, once the orchestration engine is built on top of WF, and by that time the toolkit support should have already been expanded to provide BPEL 2.0 compatibility in both WF and BizTalk. Pretty exciting stuff which I'm sure will provide some good selling points for both products (even if many people don't use it eventually).

One important aspect of this that is interesting to consider: the WF approach to writing workflows means that, if BPEL compatibility is an aspect you care about, you'll need to restrict yourself to a subset of the power of WF in order to remain compatible (and meaning being able to later export your WF workflows into BPEL). This is something I completely expected and understand (and even welcome, to a point), but it's something some people might not realize right away.

[1] Am I the only one getting lost along the miriads of CTPs coming out of Redmond lately? Seems pretty imposible to keep up if you actually have a day job!

Windows Workflow Foundation, BizTalk Server, WF, BPEL

I got a review copy of K. Scott Allen's "Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#" book and I just finished reading it recently, and wanted to take a moment to mention my opinion about it.

First of all, I'm probably not quite Scott's target audience, seeing how I was already familiar with WF before getting into the book. From my point of view, the book aims to provide a quick introduction to what WF is and how to get started programming it. In that aspect, I think it does a pretty good job.

The book starts by quickly introducing what WF and what it is composed of (the runtime, activities, designer, XAML and so on). Chapter 2 then talks in a bit more detail about how to create and design workflows, covering both the principal aspects of how the VS designer works, as well as writing workflows in code and XAML. But this chapter also goes a bit further and covers using the workflow compiler both from the command line (wfc.exe) as well as programmatically and XAML workflow activation.

Chapter 3 is dedicated to writing sequential workflows, though it also covers basic host <-> workflow communication using the workflow runtime events, workflow parameters and external data services. The latter are taken up in more detail in chapter 4, which covers most of the basic activities in the base activity library.

Chapter 5 introduces how to write custom activities. While the cover here is somewhat light (as expected given the breath of the topic), Scott does quickly cover important topics like activity binding and dependency properties and gives a quick look to readers of how to write custom activity designers and validators. Chapter 6 covers the hosting facilities in WF, including how to correctly use the WorkflowRuntime class, and all the built-in runtime services, including scheduling, persistence and tracking.

Chapter 7 covers State-Machine workflows, including some simple examples of how to interact with the workflow from the host (like quering possible transitions from the current state). Chapter 8 covers host <-> workflow communication in detail, including the use of correlation tokens, role authorization and an explanation of workflow queues. Finally, Chapter 9 covers the rules engine in WF and using code and rule conditions in activities.

As I said earlier, I'm probably not the the target reader for the book. Many of my readers probably won't also, so if you're looking for a comprehensive, in depth look at WF, you'll want to find some other source.

However, if you are not familiar with WF yet, I believe Scott's book is a pretty good place to start. Here's why:

• The book is short, about 230 pages. Most people should be able to go through the book pretty quickly.
• Scott's writing is very much to my liking. He's direct, goes straight to the point without any B.S. and he's style is pretty engaging overall, so you won't get easily bored. Chapters are also very reasonably paced and good in length, so you can very easily read it chapter-at-a-time (I hate books with never-ending chapters!).
• Even though the book is short, Scott still manages to cram a lot of useful information and cover a lot of topics (some in much more detail than I honestly expected) and I think its fair to say he does a good job of putting all the options and facilities in WF in front of his readers.

While on the topic of introducing WF, my good friend Sam Gentile wrote a couple of days an introductory post on WF which is pretty good. Like others, I'm also looking forward to seeing Sam share a bit more of his findings and what he has learned about the platform just as he has in the past with WCF and other technologies.

Look for my take on Dharma Shukla's and Bob Schmidt's "Essential Windows Workflow Foundation" book in a post near you!

Windows Workflow Foundation, WF, Book Reviews

Harry Pierson posted a story about Windows Communication Foundation and his "epiphany" (my words) on the usefulnes of WS-ReliableMessaging in Web Services. I found several comments here that made me think. Sam Gentile recently commented as well on the importance of WS-RM, and I did a few quick posts there.

Let me first start this discussion that I believe that the basic concept behind reliable messaging (and WS-RM) is indeed very important and very needed in the Web Services World to make it easier to implement reliable services and integrate disparate applications.

That said, I've been frank in the past and say that I believe that the WS-RM spec, as it exists right now, is remarkably lacking. Harry mentioned the core point: It does not demand persistence of the message and conversation state from the endpoints involved in the communication. Thus, as WS-RM currently exists, and how platforms such as WCF implement it, it means you don't really have the guarantee of reliablity. At best, all you have is the illussion of reliability. The only thing you can be sure of is that one of your endpoints is gonna fail, sooner or later.

If there is one thing that I have learned from my work on Application Integration (with and without BizTalk), is that ensuring reliable communication across a distributed application infrastructure is a tough nut to crack. There's a lot of very significant issues that can arise here, depending on the type of problem domain you're solving: Message delivery, delayed deliver, synchronous and asynchronous interchanges, ordered deliver (and even tougher, in-order processing), lost and duplicated messages and so on.

A spec like WS-RM doesn't try to solve all this issues, for obvious reasons, and that really is fine. A lot of these issues cannot be taken into account by themselves, but only in the context of the overall architecture and requirements. In particular, how the individual endpoints are designed can make a huge impact in which of the issues mentioned before are significant and how significant.

Some architectural choices will make some of these problems go away without having to write more code for it. For example, a given service might have a set of messages created in such a way that the operations they represent are idempotent. In that case, duplicated messages should not be a problem, and spending a lot of time to avoid them would not be an efficient use of your development budget, as they are a non issue. In other contexts, for example, missing one or two messages during high load might also not be important because perhaps the contents can be reconstructed from subsequent exchanges.

So given this, why do I make so much fuss about WS-RM if it wasn't meant to be the end-all solution anyway? Because of the way it has been positioned by the marketplace: It is usually portrayed as saying that it "finally solves the reliable messaging problem for Web Services". It doesn't. Unfortunately, the WCF literature hasn't helped clear this misconception and actually has made the problem a bit worse.

The other problem I have with WS-RM is that it does a bare minimum of work to help the reliability issue. And for better or worse, it doesn't do what I consider is a significant element of what that bare minimum should be, which is to require implementations to force endpoint applications to survive restarts/crashes. My bigguest concern is people building solutions assuming that because they used WCF and turned the RM bit on then they are done and their services are reliable, because that's not really true. Reliable services take a lot of work, and flipping a bit is just not gonna do it, but unfortunately in the way it has been sold to the masses, it sure sounds like learning about all those pesky reliability issues isn't needed when "WCF just does it for us" [1]...

That's my opinion, by the way, and I might be wrong. You need to do your own decision about whether the required/supported functionality is enough for your needs, but be aware of what it is that WS-RM brings to the table and be sure you're making an informed decision.

Harry made a really interesting comparison in his post: "If HTTP is basically UDP, then WS-* is trying to be TCP". I won't comment on whether the comparison is valid or not, but I do want to say that if we (as in "the community", or the "developer world" or whatever) just spent several years working on reliable messaging for webservices just to get what the underlying transport protocol, invented more than 20 years ago, already did to start with, then boy, we have really lost the train this time.

What I want to say by this is if we're going to work on creating a significant improvement on the reliable messaging field, then we need to move forward to solve higher level problems with higher level abstractions. Abstractions such as Workflow and Orchestration are significant advances in this field, for example, because they make it easier to write the endpoint applications in such a way that state can be persisted and thus it's easier for them to survive restarts and allow easier retry mechanisms.

That's why I sometimes despair when I see a whole bunch of fuss made about using Workflow Foundation for such tasks such as driving navigation between three pages in a web application: Great way to make something that was already very easy into a significantly more complex solution that brings dubious benefits (in my humble opinion) to the table. There are far more interesting uses for something like WF but hey, that's just me

One last comment Harry made that got my attention was right at the end, when he says "Eventually, I would love to see something that has the programming semantics of SSB and the interoperability of WCF". It sounds to me (though I might be misinterpreting him) that what he wants sure sounds like an interoperable, open queued messaging platform.

Personally, I'm very interested in such a platform as I believe it would be a great asset to implement reliable and interoperable message driven systems. That's the reason I'm watching very closely the development of the Advanced Message Queuing Protocol (AMQP) especification. And, there's no reason why AMQP could not be a great transport protocol for reliable Web Services!

[1] I do want to be very clear that I'm not bashing the WCF team here. Technically speaking, they're within what the WS-RM spec requires of them (and I fault the spec directly for that), and they probably have the best intentions in the world about trying to make it easier for us developers to use these technologies. They also had to make some very tough decisions about what they would support in V1.

Architecture. Web Services, WCF, WF, Messaging

Two new articles just got published to MSDN covering the Tracking facilities in Windows Workflow Foundation in great detail.

The first one is "Windows Workflow Foundation: Tracking Services Introduction", by David Gristwood, and provides a high-level introduction to what Tracking is and how it works in WF. It also shows how to instrument (add tracking) to a workflow and a brief example of how to use SqlTrackingQuery on your app to read the information written by the workflow tracking service. Towards the end, the article discusses Tracking Profiles and what they do.

The second article is "Windows Workflow Foundation: Tracking Services Deep Dive" by Ranjesh Jaganathan, and this one focuses on the underpinings of the tracking facilities. One thing I liked here was the whole discussion about how profiles, trackpoints and locations are related to one another, as they provide a clear overview of how it works for anyone wanting to create custom tracking profiles, as well as how to use Extracts in your trackpoints to extract the data you want tracked from your workflow and activity instances.

Windows Workflow Foundation, WF, Tracking