Question

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?

Was it helpful?

Solution

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.

OTHER TIPS

WF (Microsoft doesn't call it WWF to avoid battles with the wrestling organization and the conservatory) offers both pause and resume, and it also offers orchestration of activities.

Where an ESB can distribute messages and a workflow does not, a workflow orders the sequence to occur.


webhooks is new to me but it still looks like it's about distributing messages. WF would be used to create a context of Activity started -> Call Method#1 (method puts specific message on queue), Call Method#2 (method does something), Suspend until ..., Call Method#3 (method reads from queue), etc. until your context is complete.

Using WF to replace writing functions is just painful as MetaFight so eloquently stated. Its key purpose to is to provide a context the execution of > 1 operation. It can arrange operations in a GUI which can be a good visualization tool of the process, and provides the suspend / awaken / compensation activities for long running and fault-tolerant processes.

For example, and I'm picking a short process here rather than a long one:

Context is, user logs in

  1. Write audit log to database via AuditOperation();
  2. Put message on queue to notify friends user logged in
  3. Redirect user to their profile page

The execution of each of these operations has nothing to do with the other, but the sum of their parts is completing the scenario. For more information I would check out Data-Context-Interaction (http://en.wikipedia.org/wiki/Data,_context_and_interaction)

Licensed under: CC-BY-SA with attribution
scroll top