I've been trying to find information online about where WWF 4.5 fits with in an architecture based around an enterprise message queue using central broker(s) (RabbitMQ in particular). It seems like responsibilities overlap a bit since WWF offers the ability to pause-and-resume (persist/restore) workflow instances. I'm wondering if I'm erroneously equating this pause-and-resume WWF functionality to the general message queuing concept. Having looked at MassTransit, in particular a code listing of a sample Saga showing parallel code activities that then combine when completed... it seems like WWF excluding the pause-resume functionality in this context, is better compared against MassTransit.. is this an accurate assessment?
Where does Windows Workflow Foundation fit into the messaging oriented middleware architecture?
soa;message queue;distributed development
I've had to use WF before in an integration scenario based on a Pub-Sub messaging system... and we found that using WF was a pain in the ass.Firstly, it's awkward to code with.  At first you'll be tempted to code all your logic with activities in the Designer, but this is a very bad thing.  Even simple things like object instantiation turns into either a mess of value-setting activities, or is hard to follow because it's all hidden within variable declaration default values.Secondly, it's god awful to debug with.  Even if you're lucky enough for your workstation to be one of the selected few where the debugger actually chooses to wake up, listen, and do work, then get ready for a horrible debugging experience anyway.  The debugger detaches from processes seemingly randomly and doesn't actually provide much valuable information any way.  I would have expected for the debugger to show me exceptions when they're thrown, but no such luck.  Get ready to sprinkle your catch blocks with break-points.If multiple developers are going to be working on the same workflows then you'll have a hard time merging changes.  This is because workflows are XML.  This wouldn't be too bad if it weren't also for the fact the the WF Designer's visual state is actually stored within the same XML.  Granted, they finally moved the visual state info to one contiguous block of text (instead of decorating 60% of all XML elements), but it's still a pain in the ass.  It means everytime you expand or collapse an activity your file changes.  Which means you'll be committing a lot of useless changes... and then you'll be stuck navigating through them later.The only thing I can see WF being good for is long-running workflows.NOT as a technology for building a message bus.