4

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?

2 Answers 2

7

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.

4
  • I agree, the workflow I have to maintain is hard to maintain, hard to document and hard to extend.
    – kevinskio
    Jan 10, 2014 at 19:44
  • thanks! the long-running workflows is what interests me the most as well... yet if it's the only benefit i don't know that it justifies introducing a technology that everyone seems to agree is not easy to maintain. or does it? I've built a similar system and it was a lot of plumbing code - to maintain state of a multi-step process.
    – diegohb
    Jan 11, 2014 at 15:18
  • Something that made it difficult for us is that our requirements were changing frequently, and so our workflows were constantly being changed. In a situations where your workflows are mostly static I guess WF's maintainability weakness might be less of an issue.
    – MetaFight
    Jan 11, 2014 at 16:15
  • Thank you @MetaFight! I think the checkin of useless changes is what bothers me the most at this point. For long-running processes that maintain state, I think I'd be leaning to something like OWIN hosted outside of IIS maybe.
    – diegohb
    Dec 18, 2014 at 0:24
1

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)

3
  • The WWE (wrestling) already lost that battle to the WWF (wildlife)!
    – ozz
    Jan 10, 2014 at 21:12
  • lol - thanks! so WF could possibly be used to exercise the long-running workflow that acts to publish mssages and then reacts to subscribed messages ? was thinking the webhooks rabbitmq plugin.
    – diegohb
    Jan 11, 2014 at 15:12
  • Updated answer for you
    – Kevin
    Jan 11, 2014 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.