OK.
I'll stick my sticky beak in here because I'm guessing that one of the 'samples that use the hardest technique' that you may have looked at was written by me.
I'm going to talk about the whole ExternalDataExchange thing for a bit.
Take a look at that post from Brian for some detail on what I'm talking about. A key thing to remember with WF is that, more than any other part of .NET to date, it is aimed squarely at ISVs (and MSFT product teams who are the same sort of thing).
Basically the whole external data exchange mechanism is designed to make it easier to provide services to activites at run time. It's not the only way to communicate into and out of a workflow, but, if you are doing asynchronous processing it is the way that you *should* communicate into and out of the workflow.
The whole ExternalDataExchange mechanism has two key benefits.
1. It provides a disconnect between the abstract activity and the concrete implementation of that activity. If you take a look at my whit paper on MSDN you'll see we have the abstract SendEmail activity and three concrete implementations that send mail via SmtpService, Exchange WebDav and Outlook. By implementing these three as different services we can create a mechanism by which the administrator can chose how they want the SendEmal activity to be serviced at runtime- the appropriate implementation of ISendEMail can be bound in by a 'simple' configuration file setting. This benefit probably falls into the architecturally useful basket.
2. It provides reliable async messaging into and out of the workflow. When you implement the data exchange pattern your messages out of the workflow (method calls) and more importantly messages into the workflow (events) are proxied through a queing mechanism. It is very important that this happens and let me tell you right now, using the data exchange services is a BUNDLE easier than trying to do all the queuing stuff by hand. The reason it is important is that it allows workflows to be serialized out to disc and then deserliaized on receipt of a message. i.e. if we didn't queue the messages we'd have to dispatch the event into thin air or block the call while we retrieved the workflow back off disk into memory. This benefit falls into either the pretty much essential basket.
Now then. Brian has indicated that he thinks that doing the DataExchange stuff is a bit difficult. I encourage you all to read my white paper.
It shows how to use some command line tools that let you go straight from nicely written interface to strongly typed activities very easily.
If any of you are in Malaysia for SEA techEd this coming week I'll be presenting an ILL on this on Thursday I think.