I've been here before

Posted on 2/8/2008 @ 6:44 AM in #Vanilla .NET by | Feedback | 4948 views

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!

Sound off but keep it civil:

Older comments..


On 2/8/2008 10:02:39 AM Kent Boogaart said ..
I agree the tooling around WPF is inadequate, but my concern is not so much with the designers (which I wouldn't use even if they were "adequate") but with stuff like performance testing, profiling and debugging.

WPFPerf.exe is a bug-ridden piece of poo that has been released so many times that no one knows what version is current. And who cares anyway, because you run it and try to do something useful with it and it'll invariably crash. And Snoop/Mole are tools that should have been provided by MS as part of VS2008 at the very least.

I'm not sure what your bone is with the binding syntax - I quite like it. Then, I'm a little {Binding Path=Odd} when it comes to XAML. I enjoy the liberation (http://kentb.blogspot.com/2008/01/xaml.html).

As for WF, I have a little experience with it, including doing exactly what you describe. When I was struggling with this, I assumed it was just because I hadn't read enough on the topic. Perhaps I was wrong...


On 2/10/2008 6:02:42 PM Bill said ..
Come on you old grouch. How can you criticize the easy to use and intuitive WPF Databinding syntax? What part of "{StaticResource Whatever}" or "{Binding Path=Blah}" is hard? Those braces are totaly intuitive, no? Actually, you're right, it's freaking nightmare. The only upside is that you really have a sense of accomplishment once you finally get it and you know that it's a huge barrier to entry so it keeps competition minimized. I mean, when you're learning it, you'd never get confused by the completely optional Path= syntax. And who would stumble at first on the difference between StaticResource and DynamicResource? I mean, I've been working with .NET for 6 years when I started learning Avalon and it only took me about 4 full books and two months before I could correctly think through databinding in my head - compared to a day for old school winforms. And let's not forget about Templates vs Styles. Even among gurus you'd be hard presed to find a lot of folks that can tell you when to use which and why in two sentences. Yah, wayyy to much up front difficulty.

Workflows - well, yah. In the context of SSIS or Biztalk it's pretty easy to pick up but in the context of your typical business app, a lot of pain up front.

Glad you wrote this post b/c i have thought each of your points before (on several occassions in some cases) but wimped out on voicing it.


On 2/10/2008 10:44:36 PM Sahil Malik said ..
No point in wimping out. I'm just a normal guy.

But I have actually learnt WF/WCF/WPF. Learning it doesn't mean it isn't complex. My biggest issue these days is, finding others who can do all this, so I can scale out.

Unfortunately, there is still a project management cult, that believes technology is unimportant and the easy part to figure out.

SM


On 7/19/2010 3:08:04 PM Travis Riffle said ..
At first I hated WPF, but you have to admit that once you learn the power of declarative programming that it's extremely powerful. Take for example data triggers.

I'm still uncertain on binding syntax and if you can't figure out why it's not showing pay attention to your output window as it'll complain about what path it's looking for... From that I can usually tell what I did wrong syntactically.

Even though I've been doing WPF for a year though I can tell you I still don't feel like a pro as I constantly have to look up the syntax especially when attempting a control template that I haven't done on a control in two months.

Like every thing it has its pros and cons...

I can not speak intelligently on WF other than other developers I know have got very, very frustrated with the technology. Granted this was in 3.0 or 3.5 before they did the big rewrite so maybe things have vastly improved!

Anyways, thanks for the blogs!!