There is an upcoming DNR show with Brian Noyes. Now, I haven't heard that show yet (hasn't been released yet), but Carl & I have discussed a topic in the past - Workflows talking to each other, which was discussed in this show. This in fact ties in very well with what I started to talk about in my show. Basically that I've been here before. I have seen this mistake been made in COM world. And I see the same mistake being made all over again.

Here is what I mean.

What is the basic premise of WF? Well it gives you a visual view of your logic, so it makes maintaining that logic a whole lot easier. Right? It gives you more maintainable and robust applications!

Lets see how well that holds up.

Let me take the example of trying to make two workflows communicate with each other.

• First you need to write a host. This is an extremely loaded proposition, because for two WF hosts to talk to each other, you will then also need to know WCF, and all mushy concepts of threading.
• Then your WF will need to communicate with other WFs via the hosts. This makes sense because a WF doesn't keep running in memory for 3 months, when it is waiting for another WF to send an event. The WF sits in the database, and the communication occurs through the hosts.
• Okay, even for simpler scenarios, for local in-process communication, you have the CallExternalMethod activity, and HandleExternalEvent activities. Even in this case, you have to talk via the host, because the WF might have been passivated to the database. So in order to do so, you have to remember to do 3 things, decorate your interface with the ExternalDataExchangeAttribute, eventargs needs to derive from ExternalDataEventArgs, and event args is serializable.
• If you mess up in any of the items in #3, you get a very non-intuitive "InvalidOperationException". Sure the message says, "Service does not implement an interface with the ExternalDataExchange attribute", but it isn't until you look at the inner exception, that you really know what happened - i.e. you forgot to make it serializable. doh! But I did mark it as serializable. Actually, everything needs to be serializable, even the sender.
• Then you have to connect the WF activities, via the proper interface names and method names you are using to communicate.
• Finally, for even in-process WF communication, you have to remember to add your service to the ExternalDataExchangeService, and not the WF runtime. Otherwise, it will look like nobody is subscribing to the event. Not to mention, that this is one of those bug, that doesn't really throw an error. i.e. hard to track down!

So, in short, for the simplistic scenario of trying to make two workflows communicate, you need to have a good handle on the following:

• Writing windows apps (for the host)
• Threading
• WCF
• OOP Concepts
• All concepts of serialization
• Plenty of hooking up and non-intuitive details of WF itself.
• Ninja debugging skills.

This is way too complex!!

And I am willing to bet that there are less than 1% of mere mortal developers out there who can successfully architect a system, that will stand the rigors of time and changing requirements that involve the above scenario.

Now, why the title "I've been here before"?

Because I have! I saw the same mistake being committed in the late 90s with COM. COM was a beautiful technology, it was simple, elegant, and very well thought through. Okay sure the registry sucked, but that was an easy bandaid to apply. That in fact wasn't the real problem. The real problem that killed COM was towards the late 90's with COM+ etc., and ATL, you had Microsoft churning out way too much new stuff, without appropriate tooling, and without enough forethought that mere mortals will need to implement all this stuff.

So what happened? Did people not implement all that? Oh no they did! The ever growing demands of the tech industry, and testosterone loaded developers wanted to do one better than the other - and they DID implement all that fancy stuff, in a very bad manner.

The overall result?

You had tonnes of badly architected applications. Thus, COM got a bad rep. But was the problem really COM, or was it the tooling and the framework of the applications built around COM?

Do I see the same happening today with WPF and WF?

WPF - horrible tooling. Terrible databinding syntax. No clear direction on what tool to use for what, because each tool is inadequate.

WF - a finicky framework that requires you to know way too much before you can solve even a simplistic scenario.

.. you decide!