One of the fundamental things you'll need to get your head around when you start playing with workflows is how to go about getting stuff out of, but more importantly into your executing workflow. Here's my 30 second synopsis......

1. Your workflow runs inside a runtime engine.
2. All of your communications from the outside world will come to you via services provided by your host. In addition, in many cases your communications with the outside world will be sent by way of services provided by your host.

This is basically the provider pattern in action and it's an important concept to grasp... here's an example of why.

Say you build a workflow that manages registrations for your user group events via email. The logic is obviously going to be pretty simple, receive registration emails, send confirmations etc.... Your workflow declarativly defines the logic of what should happen in the sequence. Your workflow contains EventSink activities e.g. ReceiveEmail that allow your eworkflow to receive inbound mail. Try, as much as you can, to think of these EventSink activities in their abstract form. That is, your activity represents a mechanism by which your workflow receives an email but, as far as is possible, doesn't mandate or specify too much concrete implementation as to how that is delivered. The actual mechanics of how it does this will often depend on where your workflow might be running- e.g. You would probably receive the email in a different way depending on whether you are running your workflow in Outlook or on a server hosted in IIS. If we want to be able to use exactly the same Workflow definition, with exactly the same Activities then we need some sort of indirection mechanism to seperate the logical concept of ReceiveEmail with the actual concrete implementation of how we do it.

So let me give you an example. You have an activity that represents receiving an email. This is an abstract concept. You then create a workflow definition (in code or XOML/XAML) that uses this activity. You then host this workflow in a couple of different hosts. When you set up each of the hosts you can construct a different service type to service you ReceiveEmail activity depending on where you are running the host. When it is running, your activity is going to ask the runtime to provide it with a service that implements a certain known .NET Interface type. Thus you could have two different services that use two different email receipt mechanism, one for a desktop host and one for a server host. Through this mechanism you achieve the indirection that enables us to use the same delcarative business logic definition (the workflow) in a number of differnt contexts which may have markedly different requirements.