views:

481

answers:

2

We're currently building a system that abstracts all kinds of technical details about web services from some other systems. It's a bit like an Enterprise Bus, but it does a little more.

We decided to use Windows Workflow to handle the requests. As soon as we figure out what kind of action is requested, we'll start a workflow that is specifically designed to handled the action. Now, some of the web services we'll call are asynchronous, so the workflow should wait for an answer. The basic idea is that we'll implement the callback web service on our end and when the callback arrives 'somehow' give it's data to the running workflow that's waiting on the answer.

So far I've seen two possibilities:

  1. the ExternalDataExchangeService
  2. the WorkflowQueuingService

The first service is relatively easy to use, but is event based, so if you miss the event, you miss the data. We need a queue-based solution, because it's technically possible to receive the callback from a web service even before we've gotten the synchronous response that tells us we'll get a callback shortly.

The second service seemed perfect, but it is very limiting in how it may be used. Getting an item into the queue is very straightforward, but we need to make sure the queue exists before we can do that. And creating the queue seems only to be possible in the Execute override of an Activity. Since we have a lot of different workflows, we have a base workflow class that does some work in it's Initialize override and would very much like to do the queue creation in there, so we won't have to create a special "Initialize" activity that every workflow should start with. We would also like to have the notification for when a new item is received to be in the base-class. So the specific workflow would only have to wait on an WaitHandle to know there is data on the queue. Finally we want to be able to read the data from the queue from a Code Activity on the specific workflow (after the WaitHandle is signalled).

Does anyone have an idea, doesn't have to be with the two services I mentioned, but we would really like to keep things as simple as possible.

+1  A: 

In WF all the communications between the runtime or services and the actual workflows are queue based. The ExternalDataExchangeService appears to use events but these are just a thin layer around the WorkflowQueuingService and WorkflowQueue mechanism.

In general I prefer to use the WorkflowQueuingService as it gives full control. Once you understand the basics it is even easier to work with that the ExternalDataExchangeService in most cases.

Maurice
A: 

Turns out my assumption was wrong. I was 100% sure I had tested the scenario and ran into problems, but after a discussion with a colleague I retested it and the ExternalDataExchangeService worked just fine. So no need to find a more complex solution, for now we just go with the ExternalDataExchangeService .

Jeroen-bart Engelen