There have been some posts exploring WF and CSLA, so I thought I'd post my latest discoveries.
First, I realize now that one of my previous "issues" with WF, that it really didn't do much on its own, is I think completely warranted. I now think of WF like maybe XML - it's very powerful in what it enables, but not really so much in what it is itself. Part of my previous dilemna was really trying to make WF more than what it is. (And if you go to the Microsoft WF presentations it doesn't help - they begin by selling WF as the solution to all the world's problems, and then proceed to demonstrate it as really just a graphical tool for developing procedural applications.)
That's not to dismiss WF as insignificant any more than XML is. But the real value comes from what you build around it.
And Microsoft is definitely building on top of it. Specifically, the really complete picture from Microsoft's perspective is to consider WF with SharePoint and InfoPath, particularly with Office SharePoint (MOSS). It creates a very powerful and significant set of technologies indeed. But there are some caveats, not the least of which are the $50k+ price tag once you assemble all the pieces and the question of where Microsoft might take you or leave you in a couple years.
But in addition to that, it's important to understand the philosophy. The WF/SharePoint/InfoPath view is that the workflow components are the business layer. In fact, "true believers" go so far as to say that there's no longer a need for smart OO business objects at all. (I think that is part of the SOA worldview, and Rocky's blogged a few times on that if you're interested.) The application in this model is essentially the myriad of workflow components (actions), the organization of them into workflows, and the forms used in those workflows. The process to add a customer isn't the proverbial form that's interacting with a business object, it's perhaps the following chain of actions: StartWorkflow -> Display AddCustomer form to initiator -> Verify data entered -> Display VerifyCreditLimit form to accounting persion -> Return to step 2 if denied -> Otherwise run PersistCustomer action.
The marketing idea is that the end users might decide that the verify credit limit needs to go to an entirely different person and can modify the workflow without any assistance from the developers. Even "better", they may decide that they need to split up the AddCustomer form between two people entering different pieces of information and can split that up between them without any developer's help. Or they may decide that they want to add an email notification every time a credit limit is approved.
Now all that is great, but at the end of the day you still have developers writing and maintaining those key workflow actions. They must enforce business rules that are required for database integrity or other business processes, for example. And while it might be very cool to allow a user to adjust a workflow so it branches depending on the amount of the requested credit limit, turning over business rules to end users is obviously a slippery slope. It is a dangerous path - with great caution, we must proceed, as Yoda would say.
Rocky has expressed the position that all business logic should be encapsulated in the business layer, and everything that uses the business layer can be considered a UI. I personally am quite dogmatic about that (as anyone who remembers my old threads on reporting knows), and have found that thinking this way is helpful in this case as well.
To me, the SharePoint and InfoPath solution, and the WF actions that support them, should be considered as yet another UI just like a windows form or a web service. The ultimate responsibility for all business logic behavior and data handling stays tightly within the realm of the CSLA business objects. Many of the WF actions wouldn't be much more than shells exposing business layer functionality. If you would want to call them part of the business layer at that point is up for discussion, but that language would mean something quite different than Microsoft does.
That would leave us with the question of the value of WF (the free technology) itself. IMO, unless you're going all the way you're not going to get much from WF. And if you take the approach described in the previous paragraph, it's not going to be a radical redesign of your business layer to introduce it later.
I foresee that I will bring in WF and Sharepoint/Infopath as part of our solution maybe a year from now. We have a few processes that lend itself to that kind of paradigm - one where we must gather a bunch of pieces of information from across departments to create a new customer, and others where there is a actual "document" that travels through a branching business process. Again, I see that as adding on some additional UI functionality just as if I decided to exposes some of the behavior via web services. One interesting part of that is that the information gathering process collects a lot of data that I couldn't care less about. I mean it is just information not related to anything else. So it will be pretty powerful, especially with the next SQL version, to allow users to define a schema of information to collect and manage the forms and workflow to do so without a developer even needing to know about it. But I see that as always being support of specific use cases, not a model for developing enterprise applications in general.
Hope that helps.
Copyright (c) Marimer LLC