Are there any samples around using CSLA with Workflow Foundation components?
I have been reading the other posts around the integration of CSLA and WF, but not much code. I understand Rocky's point of the synchronous vs. asynch nature between the two and my design can be made to accommodate this (i.e. command-base writes a command record (think GoF command pattern) to a DB and kicks off a workflow). I am hoping to see an implementation to get some concrete ideas on wiring this up.
There is a small WF example in the CSLA .NET 3.0 download. Unfortunately it doesn't address your question, about submitting async workflows...
It is important to realize that something, on the server, must host the workflows. In other words, some EXE must be running on the server, within which your workflow can run asynchronously.In most cases this means a Windows service.
My first instinct, and what'd I'd probably try first, is to use MSMQ. Have your command object get to the app server, and write an entry into a private MSMQ queue by using System.Messaging. That's easy. It might also write data into the database, and just put a key into the queue - that's typically the best approach.
Then you'd write a Windows service that uses System.Messaging to listen for messages to arrive in the queue. Again, this isn't hard. When a message arrives, an event is raised, and you just need to handle that event to process the message: in this case by kicking off a workflow - passing in the data from the queued message.
The complexities you'll encounter are (at a minimum) these:
There aren't trivial answers to these issues (especially the retry one), other than perhaps Biztalk Server. Remember that WF is not designed to replace Biztalk, and if you want a robust async workflow engine on your server, WF is just a bare core on top of which you'll need to build plumbing somewhat like that provided by Biztalk Server.
One other option is to use COM+ queued messaging. They automatically do retries and have a mechanism for doing throttling (using COM+ object pooling). Getting .NET messages into queued messaging is a little harder than using raw MSMQ, but it is probably simpler than trying to roll your own retry infrastructure, etc.
There is also the option of using SharePoint Services. I've found the capabilities you get for free to be quite impressive and include document management, forums, surveys etc. capabilities as well as workflow hosting.
I'd suggest that if you're thinking of integrating a CSLA-based applilcation with WF, you may very well also need workflows that are pretty independent of that application. So you may need to look for something like SharePoint anyway.
As we've discussed before, the SOA/WF kool-aid is that the collection of workflows is the enterprise application. Dino Esposito gave a prensentation to that end chock full of illogic and falsehoods at Tech Ed which I thought was the most ridiculous thing I've heard on WF to date - but I digress.
If you still believe that n-tier is a good thing and believe in the principles behind CSLA, it is important to maintain the proper understanding of WF as not encroaching on the business layer, as has also been discussed at length previously. But as someone who's spent some time looking at WF and SharePoint, I can see those technologies having a much more significant place in an enterprise than I previously thought.
BTW, on a related note - I just read an article this morning about a survey that reported most people doing SOA are happy with the increase in integration capabilities, but most have not realized any increase in code reuse and some other things that are typically part of the SOA drink-the-kool-aid presentations. Just as those of us (including a very vocal Rocky) looking objectively would have predicted.
Dan,
Thanks for the details around Sharepoint Services - that is something new to me. My scenario can be handled largely by MSMQ, so I think I will go that route. But in the meantime, can you recommend any good books on Sharepoint Services? I see Ted Pattison has one out from MSPress - I am assuming that would be a good one based on his earlier books.
I don't doubt the SOA survey results - it's great for integration, but it introduces an entirely new bundle of issues.
Thanks again,
-Steve
Thank you, Rocky. I just downloaded the 3.0 bits - I am looking forward to digging into this.
My approach is better suited to raw MSMQ initially and then possibly moving to Biztalk server for the reasons you mention. The approach you mention makes a lot of sense - I am backing off the WWF angle for now.
I am taking an approach of extending the CommandBase<> object to build an AsyncCommandBase<...>. Your earlier posts on the issue of remaining transport agnostic makes a lot of sense, and the approach didn't hit until I thought about typical Ajax scenarios (submit request, periodic poll for completion, etc). The approach should work the same whether using a local indirection or MSMQ - with locally described timeout periods to aid the presentation layer. I am still working through the details, but this is an interesting/fun problem to work on.
Thank you for taking the time to reply and going over the options.
-Steve
Copyright (c) Marimer LLC