I have been intrigued with WWF and have been planning to use it for a large people management project, which requires several collaborators in the workflow. I started to divide responsibilities between the workflow service and the host apps, and also started to wonder about the benefits of what I was trying to do.
I am new to the technology, so please bear with me. It seems like I would need to have the workflow service running on a server, and communicate with it from client workstations (using Windows Communication Foundation? .Net Remoting?) Are there any examples of a real-world app available to help?
Thanks for any help anyone can give me.
I spent a few days playing with WWF and have talked to a few Microsoft people at other presentations and frankly I still don't "get it". I mean I understand what it is and what it does but I still don't see how it's all that useful to me, even when specifically designing a workflow application like I have to.
The last person I talked to (from Microsoft) admitted that it really is quite incomplete in itself - it is a "framework" after all. Microsoft intends for you to wrap additional functionality around it to turn it into something actually useful.
A colleague had the brilliant (I think) analysis that where this is going is that eventually the essence of an application can be represented as a portable self-contained entity. Think OO encapsulation at the application level. You have a workflow task that gets sent via email. It is just a big XML file which includes not only information about the task in the workflow context, but also details of how to create an input form and do something (XAML/WPF) and how to communicate back to the mothership if necessary (WCF) - all in nicely portable XML.
So, I think WWF makes a ton of sense in that bigger context, but I'm still not so convinced it's real meaningful for my work today.
Thanks for your thoughts.
At first blush I was totally enamoured with WWF. But if I am to do a large project using it, I need some solid reasons for my client as well as myself.
I could use the remoting techniques from CSLA to communicate between the workflow service and the client apps, but I still don't see clear benefits. What are the essential differences between a client-server app and a state machine workflow with client apps connecting to it? In a conventional client-server environment, the client server app persists state, and that state determines the stage of the workflow. All decent client apps are capable of determining operation paths based on state. Using WWF does consolidate the workflow in one encapsulated entity, so the clients have little responsibility for anything but reporting and raising events.
I like it but I'm not sure why :)
![Wink [;)]](/emoticons/emotion-5.gif)
Sold!
Thank you Rocky, for the most succinct, insightful summary of the benefits of WWF that I have seen. (And thanks for giving me great reasons to follow my heart and give it a whirl :)
Cheers,
Helen
Just be wary of one thing about building a work-flow application:
Users will tell you iron-clad rules that "must" be followed when what they really mean is guidelines that should be followed most of the time, except for the exceptions of course.
They are often willing to design a far more complete and comprehensive set of workflow rules than they are willing to live with in practice.
Make sure you account for that in your design or you'll have a complicated set of instant shelfware.
Having developed workflow applications for the better part of the last ten years, I have to say that I am terribly disappointed in what I've seen thus far with WF. I agree with Rocky that the concepts of workflow and what WF are trying to do are valid and apply to almost every application being developed in some fashion (even a Wizard is a form of a workflow) - but, extending the logic and designing from that point-of-view is different for most of us.
I laugh every time I bring a new developer in and we reach this topic during their orientation. I usually start by asking them to make a flowchart for a very simple application. Their flowchart is typically just as simple. Then we start talking about all of the 'little' steps that actually take place in between that must be part of the model if you are going to generate an accurate workflow. The most basic of these concepts is the difference between an action 'pending' and that action being 'completed'; where does it go, how does it get there, etc.. This is all part of state management (which is synonymous with workflow).
The reason I am disappointed in WF is that it is very cumbersome to use and the 'engine' leaves a great deal to be desired. The previous post regarding comments from Microsoft and that this is intended to be a starting point does make me feel better that MS didn't go into left field on this one.
I like the idea of XML driven workflows and the flexibility that provides. Especially given the knowledge that changes do occur, as David mentioned. But the format is difficult to teach and is almost like a language in and of itself. Not that I am a big fan of CDO, but it did provide for much more functionality than WF and that is an area that will lead to negative feelings about WF.
So, with all of that said, my advise is to go ahead and leverage WF if it suits your needs but don't expect it to be the be-all-end-all (as Rocky put it). For us, we are in the process of extending our existing workflow framework to leverage the good things from WF but still allow us the power, flexibility and ease-of-development that we require from our workflow engine. Ask yourself, what is WF really doing for you? At this point, from our perspective, that answer is, "not much."
Good luck.
I am certainly finding that structuring anything but the most simple exampleusing WWF is challenging. Perhaps one of the biggest benefits to me (whose first programming language -- self-taught -- was FORTRAN -- II (that's for Rocky)) is getting my mind around structuring my objects to work with WF. As Rocky points out, WF enables the marriage of procedural and OOP programming.
I am most grateful for all the thought-provoking feedback on this question.
Laters,
Helen
Helen W:
I am certainly finding that structuring anything but the most simple exampleusing WWF is challenging.
), Pascal or VAX Basic app that was actually procedural in the pure sense. They all cheated by using global variables, common blocks of memory or other techniques to avoid having to explicitly define and pack up the parameters needed for every procedure in the application... Here's an example of where I am having trouble. Let's say part of my workflow contains a sequence of 2 activities: "Complete Form" and "Email Form". So I develop 2 custom activities: Complete_Form (application specific) and SendEmail. SendEmail is a generic activity that requires the usual email properties. Complete_Form should not have dependencies on the next task, or even know what it is. So what is the best way of gluing these two activities together? The only place that I can see is in the underlying workflow. That means that the underlying workflow object will have more and more private variables to handle each activity. These variables will often only be used by 2 activities, but still have to be declared. Is this a problem? Is there a better way?
thx
Helen
Helen,
You've provided a perfect example of where we have found WF lacking. In our minds/world, the "document" behind the form is your one and only entity and, as you state, you have two activities: complete form and email form. As such, SendEmail should be a method on the document that is triggered by the underlying workflow engine in response to a given input and set of conditions. Your UI handles the complete form portion.
Using the approach we've adopted, our workflow engine would respond to the form's Submit or Save command (button-click), see that the document is in a "new" state, call the IsValid method on the document (where you perform validation on the user's entries) and, if true, call the ChangeState method on the document (which is a WorkflowItem) indicating that the document is transitioning to a "Submitted" state. In the handler for the StateChanged event, the SendEmail method would be called in response to the change.
This is pretty basic example but is representative of something that should be simple and has proven to not be so with WF. Perhaps it is our understanding of WF that still needs work, but connecting the "document" to the process to allow for flow such as this is not readily apparent nor do we see how to incorporate this level of control - not to mention things like notifications, assignments, etc. that aren't a part of this example.
For what it's worth; however, is if this is what you are trying to accomplish (and I assume it is only an example), then workflow is overkill. Something this simple can be handled without a workflow engine easily - probably more easily than trying to bolt it onto any worflow foundation/framework.
Hope that helps.
Hi SonOfPirate,
Yes, this was only an example -- actually the first 2 steps of a complex workflow that my project would require.
My understanding is that the workflow instance corresponds with your document. One of my concerns is that as the complexity of the workflow grows, the number of private instance variables would perforce increase in order for the workflow instance to be the only glue between individual activities, all of which would need to be persisted in a long-running workflow (unless one wrote persistence methods based on workflow state). Persisting these instance vars probably isn't a big deal because the instance variables would be keys to access the data anyway.
Isn't this alot like good old MVC? I am wondering how different this all is from a typical app written using the CSLA where the developer has been careful to encapsulate the various tasks.
I guess an example of what you think would cause an increase in private instance variables would help - at least me anyways.
Most of the applications we develop are workflow oriented and even though our WorkflowItem base class does extend our BusinessBase class with workflow specific methods, etc., there really isn't anything different about the way you setup the BO (outside of WF, I mean). Really the only difference to your BO is that it becomes stateful - meaning that it has awareness of its state and, where applicable, alters itself accordingly.
The simplest example of this has to do with security. One user may have rights to create a document while another has only reviewer rights once the document has been completed and submitted. In the access control code you have for your document, you would cross-reference the document's current state with the rights before granting or denying access. Aside from tracking its current state (which is part of the WorkflowItem base class), everything else is already part of the BO.
That's why I say that an example of how you see it working might help.
If I understand all of these excellent comments, I think everybody is saying the same things I found.
Since the BOs are really going to have to do the actual work anyway, it was hard to justify WWF and creating workflows to say there is a process that includes three steps. That's been a cornerstone concept in CSLA application design for as long as I've been on this forum (er, well this one and the old one). There is some interesting additions to the paradigm perhaps, like sleeping a workflow, but I can't find a real case that couldn't be solved otherwise that would justify adding WWF to the mix.
For automatic/unattended tasks it's still the BO that has to do the actual work. It doesn't seem like a complex problem to me to build a simple engine that can periodically call methods of BOs to accomplish things like "send an email to the owning customer of orders where the status is "approved" and the emailsent flag is false."
The heart of the matter is always just the data and BO functionality when you get down to it it seems to me.
Now, as I posted earlier, I think when the "approve order" workflow task can actually be sending you (who could be a vendor, manager, government agency, etc. etc.) a completely self contained XAML/WPF form that will run on a dozen major platforms including Macs, linux, mobile devices, phones, and PCs, then we'll really have something. (There is a WPFe, where the "e" is for "everywhere", project afoot at Microsoft, for those that didn't know it. There is currently a Mac version running. WPFe is a subset of WPF.)
An interesting thread, that I feel compelled to comment on. I have "seen" the WWF (at an MS roadshow) and thought it looked really interesting.
@DansDreams: "to build a simple engine" - Is this not what MS have done as part of WWF? So we don't have to worry about building another one ourselves? They've built an engine. And they've also built a front end visual designer to "draw" the workflow. What we have to do is identify the entities and the flow between them.
I agree that in a CSLA world the BO's should still "do" the work.
So an Order BO, would have methods like "Submit", "Approve", "CreateInvoice", "Dispatch" - you get the picture.
But doesn't WWF offer the flexibility to perform these different actions in a different sequence dynamically at runtime, depending on what workflow you have designed.
This may not be such a big deal for a bespoke application where there is only ever one version of the flow that doesn't change. But what about an application which is itself a product that is capable of being customised for different users.
So, imagine being able to "draw" the state changes (like you would in Visio) as part of the configuration process, using your existing toolbox of workflow entities. Customer A gets one version and Customer B gets a different version (reflecting their slightly different way of working - perhaps they have no Order.Approve step) - but it's still the same "product application". Just configured differently to meet different customer needs.
I'll agree that it's early days and I haven't actually touched WWF yet. But I'm hoping there's a place for it to co-exist with CSLA in some applications.
I'm going from 3-month-old memory of spending only a couple days on this, so I could be wrong and appreciate others' perspective and clarification.
IMO the problem David is that WWF doesn't really include any of the important details, and the 10% of the problem that it does address isn't that big a deal once you get past the fact that well it does have that designer that can draw pretty boxes and lines representing the workflow. (Although one of the somewhat confusing aspects of WWF is that there is a distinct division between discussions of the Visual studio extensions and graphical designer and the declarative point of view of hand-typing flows as XML).
There's no inherent mechanism for associating users and permissions with tasks, or defining reassignment capabilities, etc.
And for that seemingly minimal benefit you introduce some issues you don't have with straight data-driven tasks as I described. For example, suppose the task is "approve the order" and it's currently sitting in the CFO's "inbox" (not an inherent part of WWF either). What if somebody else cancels the order before the CFO performs her task? So, it seems to me you either have to have incredibly complex spaghetti relationships within the workflow, or the workflow task is simply a trigger that the BO may need to do something, or you have to have the BO aware of the whole task system. In those latter two cases I say you effectively really don't have something substantially different than the data-driven task system I described. In the third case I would wonder about encapsulation/scope creep.
I could be all wet on that last paragraph and as I said I'm really on more of a quest to find the person that can explain the pragmatic benefits of WWF more than I am out to beat it up, so if you "get it" please be patient and keep explaining.
Point taken.
You're more advanced in this subject, because you have at least spent two days looking at it ![Smile [:)]](/emoticons/emotion-1.gif)
, whereas all I've seen is the Microsoft smoke-and-mirrors show!
I'm sure we'd both like to see a proper example (like ProjectTracker) of exactly how the whole thing works so we can all "get it".
I guess we'll just have to wait...but I'm not holding my breath (at least not yet anyway).
If you want to see a full-blown WF system in all its glory, check out the Captaris product: http://www.captaris.com/workflow/index.html
It just so happened that I had just come off a week or so of evaluating the Captaris product when I heard about and looked at the MS WWF. My 10% figure is made up, but there really are many more things it doesn't do than there are existing features from what I could tell.
I think by the time you ended up adding the required functionality around WWF to make it actually useful you'd end up with something like the Captaris product. And in my evaluation of that product, even with all its functionality, I still couldn't justify it in the context of a CSLA enterprise given the interaction between the BOs and the workflows as I described in my last message.
Now, in 5 years when we get to the point of all this adding up to self-contained, transportable and cross-platform applications running around the world it's a different story - one that's going to shake n-tiered and even the current SOA thinking to their foundations IMO.
Actually I think WWF handles this scenario rather nicely. The WF engine is running on a server on the intranet, and the client apps connect to it when they start up. When a new order workflow starts up (i.e. when an order is created and submitted for review), the service raises the NewWorkflow event, and all the client apps listen for it. If the manager is running the client app, they will receive the notificaiton. If not, when they start up the client app, the client app can enumerate all the relevant workflows (providing the server app uses the WF persistence services) and if the order still requires approval, the manager will get the alert. The WF can be programmed to alert via email as well, but as you point out, if the email system is not integrated with the app, then there can be a synchronization problem.
It's not exactly true that WF does not have a concept of a person. It has an "Identity" value passed as part of any WF event args. (Sadly it is a string, but one can always either add the WindowsIdentity object to event args, or use the string to query the user datastore.) In our case, organizational data will be stored in AD, and we plan on using ADAM/AxMan for managing permissions, so this can all be integrated into our WF without too much bother.
I don't think we're really saying anything differerent about WWF, but I think the devil is in the details after seeing what WWF doesn't do compared to a full-blown WF application like the Captaris one. Again, I could be all wrong. I am taking a somewhat cynical tone and playing devil's advocate here, but I don't mean anything personal by it.
Actually I think WWF handles this scenario rather nicely. The WF engine is running on a server on the intranet, and the client apps connect to it when they start up.
This is WWF functionality you have to add to your app of course.
When a new order workflow starts up (i.e. when an order is created and submitted for review),
So the Order BO knows to start this workflow, or vice versa. The point being the tight integration of the two that's necessary.
the service raises the NewWorkflow event, and all the client apps listen for it. If the manager is running the client app, they will receive the notificaiton.
By this you mean the workflow interface that's been programmed into the client application.
If not, when they start up the client app, the client app can enumerate all the relevant workflows (providing the server app uses the WF persistence services)
More client code
and if the order still requires approval
Meaning the workflow task is really just a trigger that something might need to be done, as I described previously, right?
The WF can be programmed to alert via email as well
more functionality to code
It's not exactly true that WF does not have a concept of a person. It has an "Identity" value passed as part of any WF event args. (Sadly it is a string, but one can always either add the WindowsIdentity object to event args, or use the string to query the user datastore.) In our case, organizational data will be stored in AD, and we plan on using ADAM/AxMan for managing permissions, so this can all be integrated into our WF without too much bother.
My point is really that I think these kinds of details that are included in WWF are so granular as to not actually do much themselves. (In contrast, we know in CSLA the identity is a very powerful thing because with a line of code here and a line there we've got a complete authorization/permission system.) In WWF there's no inherent definition of who my peers are to whom I might transfer a task, or subordinates whose tasks I am able to monitor, etc.
So, boiling all this down, what we get from WWF is a service that can raise predefined "events" to which clients can listen if they're so programmed, and a way to predefine relationships or links among a group of related "events".
I'm still not seeing the advantage (given everything we've discussed) of having the engine and declaring two steps are related by typing XML or drawing pretty boxes in a designer compared to just saying they're related in the data itself. From a data driven perspective, the first step is approve work orders where the approved flag is false, and the "event" is that the result of such a query is not empty. The second step is ship orders where the approved flag is true and the shipped flag is false. And so on.
I might mention that the Captaris product has the concept of defining a set of data that is part of each instance of the workflow. A workflow of "hire employee" for example might begin with a form wherein a user would enter the person's name, SSN, etc., all of which would be available on the windows or web form (also potentially designed right within the product) that the person's manager would use to approve their salary. Their product is incredibly powerful, but what became apparent to me is that you really had to decide whether the workflow system was going to be framework for the enterprise application. I just couldn't get the concepts of that complex workflow application and a well-encapsulated n-tier enterprise application to line up in a way that justified the expense of the workflow product.
I want to preface my remarks by saying that I am most grateful for all feedback on this issue and certainly do not take it personally. I'm new at this myself, and I am finding this discussion most helpful.
I believe that I can put a service layer between my client apps and the server so that the client apps do not have to be aware of workflow. My service layer will raise events of interest to the clients, such as letting them know when a new workflow starts, etc. Also it will provide methods so that they can get the current workflow info (e.g. orders pending review, etc) when they log on.
As you point out, MS does not provide a rich set of WF activities out of the box, so we will need to create some generic activities to make this useful.
The BOs will probably need to know how to interface with the service -- I'll see how that works when I get a bit further.
For me, at the moment, the main benefit to the WF engine is synchronization of tasks. I do agree that this could be done in many other ways -- for instance SQL Notifications, another (in my view) underused MS technology that is way cool.
From past experience, I have found that adopting non-MS technology after MS has entered the marketplace ends up being sub-optimal. IAC, I am willing to see if WWF meets our needs without too much pain.
I'll keep you posted! In the meantime, keep those cards and letters coming!
Laters,
Helen
I'm confused by your description. You say the client apps won't need to be aware of workflow, but then you describe the workflow specifically in the context of the business application ("orders pending review, etc.") and the business application specifically needing to be aware of the workflow system ("The BOs will probably need to know how to interface with the service").
Again, I say in my attempt to wrap my feeble mind around this the problem was precisely this need for integration to the extent that the lines between WWF and the business application were horrendously blurred.
If you get a proof of concept working PLEASE post about it with some details about the design. I really was intrigued by the basic premise of WWF and definitely don't want to miss the boat if it sets sail to some place worthwhile.
I agree with DansDreams, if anyone gets a proof of concept of WWF going then please share if possible.
Let's take a very simple "workflow" scenario:
(1) An Employee writes a new Document for publication.
(2) A Reviewer reviews the Document and either approves it or sends it back for rework.
(3) When the Document has been approved a Distributor distributes the Document.
Now, I have said nothing in this flow about "how" the work will be done and I'm sure we all have different opinions about that (for example, is the distribution done using email or post).
So isn't one of the benefits of WWF being able to describe this "process" without implementing a hard-coded "flow". We can then build different "flows" to implement the same "process", but all of them use the same WWF engine?
Even as I'm writing this, I'm not sure of the answer from my own simple example ![Confused [*-)]](/emoticons/emotion-42.gif)
. Any thoughts?
But that's my point David. The WWF designer allows you to draw three pretty boxes with connector lines to indicate there are three steps that happen sequentially, and the XML aspect of it allows you to define that in XML (by hand if you want) - all very nice, but that's all it does.
No inherent indication of who does the steps, how they're notified, how those actors are related to each other, whether the step can be reassigned and if so to whom, who has authority to monitor the overall progress of the workflow, how each step is actually performed, and so on and so on
As I recall you can specify some of these in the workflow definition, like defining a certain method in a certain assembly is to be called, but that is still pretty primitive to the point of being a fairly minute portion of the problem IMO.
And to answer your specific question, no I think you are defining a specific workflow tied to specific actions as I described. If I'm wrong this may be a big breakthrough for me.
Ok, we may be approaching a lightbulb moment together ![Idea [I]](/emoticons/emotion-55.gif)
.
Yes you are 100% correct. I had to re-read my post again to see it properly. What I described was a SPECIFIC workflow with SPECIFIC actions. The workflow dictates exactly what should happen when a Document has been Approved - the Distributor must Distribute the Document.
However, what is not defined is the method of distribution. Does the Distributor publish the Document as HTML on a Web Site? Do they send it to an email address? Do they send it in the post? Or do they do all three?
These are all possible "actions" that need to be performed on the Document as part of the transition from the workflow state of "Approved" to "Distributed".
And this is the bit that we want to make dynamic. We want the flexibility to say, that something (i.e. a class) will perform the actions required to complete the required workflow transition from "Approved" to "Distributed".
And this something (the "action" or "doing" class), can be dynamically changed at runtime (i.e. by reflection or by dropping in a new DLL) so that the methods performed are flexible and not "hard-coded".
The workflow has remained exactly the same, but the mechanics of what happens is now much more flexible.
If that makes sense to you, then we may be on to something!
Well, the workflow definition has to indicate that something specific is to happen or its of no value. The idea is that when a client indicates that a certain step in the workflow is completed then the engine can determine what to do next from the definition. That specific thing could be calling some more intelligent code or could include some complex condition checking as part of the XML definition.
So in a nutshell my point is that if it's the former option then the workflow hasn't done much for me, and if it's the latter option then the workflow has become the business layer.
The workflow definition does indicate something specific is going to happen - it's going to call a method like (for example) "Workflow.Distribute()".
Inside the Distribute() method you get the relevant Document object and do stuff like:
Publish(Document);
Email(Document);
Print(Document):
When the method returns the workflow engine advances to the next state of "Distributed" and the workflow finishes.
The point being that the stuff inside the Distribute() method is not part of the BO. It's business process steps that you want to perform with the Document. You may need to call methods on the Document BO to perform some of those steps (e.g. Document.ToHTML()). And you may need to collaborate with other BOs as well.
But the actions are not part of the BOs themselves necessarily. So changing the actions that occur between workflow states is a "workflow" thing and may not need changes to the underlying BO. Yes you still have to change some code somewhere (that's always the case if you want to change what happens).
But the code you're changing is "workflow" code, not BO code.
You could think of it as a "plug-in" model. You plug-in a different Workflow.Dll to perform different actions, but using the same BOs and the same workflow "diagram".
I wouldn't say that what happens inside the Distribute() method is a Business Rule. Business Rules need to be tested for valid/invalid. I'm not sure that the actions themselves fall into that pattern.
But I agree with the question "Is there ever a time you need the same workflow"? The answer could be yes.
If it's the workflow action that you want to call again, then the fact you have the code in a common method (e.g. Workflow.Distribute()) is fine. This is just the same principle of extracting common code to a shared module. But for it to be a common "workflow" action you must have designed a workflow that needed the common action. You would still use it from within WWF in another workflow.
Hold on, wait a second.
If I recall correctly, WWF works from classes/methods marked up with special attributes - so it's all just code really. It can be called from outside the WWF engine if required.
So you are the one that's written Workflow.Distribute(), and it's in a DLL you can reference so just call it when you like. It doesn't have to be from inside a WWF "workflow".
There seems to be 2 questions being discussed here:
My first efforts at considering workflow come as a result of evaluating WWF, at which I am a total novice. However, evaluating WWF has forced me to think of how to structure my BOs to use it, which I am finding challenging. It does appear to me that there is a distinct type of BO that is a collaborator/distributor between other BOs. In the past we have automatically included these functions in our BOs because either we didn't really have a choice, or it was easier than trying to map it all out (as Rocky pointed out).
As for WWF as opposed to other commercially-available packages, since I am not about to evaluate these packages, I cannot compare them. However, the very existence of these packages suggests that there is indeed a place for workflow.
Please do not be to hard on me for being infatuated with WWF -- like all infatuations, it may not be very rational, and it may not last. ![Big Smile [:D]](/emoticons/emotion-2.gif)
As for WWF as opposed to other commercially-available packages, since I am not about to evaluate these packages, I cannot compare them. However, the very existence of these packages suggests that there is indeed a place for workflow.
Please do not be to hard on me for being infatuated with WWF -- like all infatuations, it may not be very rational, and it may not last.
Helen, I appreciate your perspective...
I was infatuated too until I learned WWF was just a time-mooching bum that sat on the couch all day. And yet, like all good infatuations I can't really get it completely out of my head.
The existence of the package like Captaris to me only proves 1) workflow is an important part of enterprise software systems. Surely nobody can argue that. 2) Some people value systems where novices can build such systems. Again, an obvious truth. 3) Such people have absolutely no understanding or interest in n-tiered architectures.
The Captaris product breaks edicts of both SOA and n-tiered design at every turn, and my problem is that I can't see how building a system around WWF wouldn't lead to the same thing. (Which is again why I say IMO when this is fully realized in 5 years both the SOA and n-tiered camps are going to be wondering where that semi that just ran over them at 90 mph came from.)
I was infatuated too until I learned WWF was just a time-mooching bum that sat on the couch all day. And yet, like all good infatuations I can't really get it completely out of my head.
Hey, that explains everything! I always get infatuated with time (and money!) - mooching bums that sit on the couch all day, as long as they are sexy!
Maybe I have swallowed the MS marketing bait (at least hook and line) but at the very least I have been prodded into thinking about structuring my BL in a new way.
Laters,
Helen
David,
Well, there might lay the source of my turmoil - the fact that I'm unwilling to accept this paradigm. I disagree that a business rule is a true/false issue.
From businessrules.org: "A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern the project are atomic -- that is, they cannot be broken down further." [My emphasis added]
From wikipedia: "Business rules or business rulesets describe the operations, definitions and constraints that apply to an organization in achieving its goals." [My emphasis added]
I agree with the previous poster that this flow of activities associated with processing this document is most definitely a business rule, and as such most definitely belongs encapsulated in the business tier in an n-tiered architecture.
Forget about arguing about this specific example... let your mind wander a little and I think we would all come to some gray area where it wasn't so clear.
A - Sally asks Jim to make her coffee - ok, not part of the business layer.
B - Sally startes the CreateOrder workflow, which will go to the Approve step and then the Ship step after she completes the Create step, but the order isn't valid until she defines 6 fields - most defiinitely part of the business layer.
Somewhere in between is the gray area as you see it... but the real point to think about example B and ask yourself in't it a business rule the order can't be shipped until it is approved? Those belong in the CSLA BO, right? I'm saying when I got to THAT point in my analysis and tried to determine what that line was I started talking to my scissors and looking over my shoulder for invading Tralfamadorians and never could make it work out in my head.
Dan,
In response to the "Business Rule" definitions you gave - I agree 100%. I was using the rather narrow CSLA definition of a "BusinessRule" when applied to a property (for example) within a BO.
What you are saying is correct, Business Rules (or Business Processes) describe a bigger goal or requirement for the business to achieve.
DavidDilworth:
I wouldn't say that what happens inside the Distribute() method is a Business Rule. Business Rules need to be tested for valid/invalid. I'm not sure that the actions themselves fall into that pattern.
Ok, I have another way to think about the Distribute() method, following on from ajj3085's (Andy isn't it) response.
The Distribute() method can live in the Document code file with all the other BO code - that's no problem. So the method becomes Document.Distribute(). If we want to, we can mark that up with attributes as a workflow thing - but I guess we don't have to.
In fact I think what I'm describing here is a concept referred to on the old boards as a "Unit Of Work" - someone please correct me if I'm wrong about this.
The Distribute() method is co-ordinating or orchestrating a series of tasks that need to be performed to complete the action required. But yes it's part of the Business Logic code associated with the Document class.
Or it's a separate Process type of BO that is performing the orchestration of tasks across many BOs. I guess this is how we do this kind of work at the moment anyway without WWF.
Yes David, and when you've coded all those Units of Work, or macro-operations, or whatever you want to call them, into the business layer, what is left to put into the workflow given that WWF is missing all the critical ingredients I've listed?
I mean, don't you end up with a workflow that says
Step1 - Somebody I know nothing about, do a bunch of stuff I know nothing about
Step2 - Somebody else I know nothing about, do some more stuff I know nothing about
and then what's the point?
I've been to no less than 3 Microsoft presentations on WWF and I just feel like I should be making it an integral part of my architecture because it sounds so cool and important, but I can't understand exactly how.
(Poor Helen, missing all our early morning banter back there still in bed in Victoria. Say hi to my mom.)
Dan you're probably right. I've just had a chat with a colleague at work who has offered up this possible definition.
"WWF may provide little beneft for intra-application workflow, but may provide the most benefit for inter-application workflow."
So, putting it simply, we can build our self-contained CSLA applications using our own state engines and our own workflow implementations.
But if we want to define workflows that involve systems and processes outside of our own CSLA application, then WWF could be a tool to achieve that.
This is along the lines (I believe) suggested by Rocky in his earlier post, where he made the distinction between interactive and non-interactive processing. We use interactive processes intra-application and we use non-interactive processes inter-application.
A bit like synchronous and asynchronous possibly?
(Yeah poor Helen, let's hope she joins in later on ).
I'm back! Where were you guys all yesterday afternoon? I thought you'd finally bailed.![Sad [:(]](/emoticons/emotion-6.gif)
OK, I agree with the person who stated that workflow would be useful for inter-app communication, rather than intra-app. My intent is to use it to streamline collaboration between different people who have varying responsibilities in the process. As was pointed out earlier, sending an e-mail alert to the person is fine, but it is not tied into the app (unless your app integrates with Exchange or Outlook).
One benefit that I see is that it helps separate the programming artifacts from our logical business objects. For example, primary keys. To keep our database happy, we programmers introduce the concept of primary keys. These to me are a programming artifact -- they often have nothing to do with the actual entity. (Of course, sometimes there is a PK that corresponds to a user entity, such as an invoice number, but often there isn't.) For example, when we add a person to a contacts table, we assign them a PK, for database performance reasons. But what the user wants to avoid is having the same person added twice. PKs don't solve that problem -- they only make sure that the database remains consistent.
Getting back to WF (you knew I would!) it seems desirable to me to separate as much as possible the programming artifacts from the business entities. I know that it is not practical (or even possible) to do that completely. But, for example, to me whether a document has been reviewed by a manager is not part of that document's state, from the user point of view. It's part of the workflow. So if WF allows me to have my applications more closly model the problem as seen by the user, that's a real benefit.
I believe WWF is here to stay, and will not be abandoned in future releases of the OS. After all, MS has had a few years of experience with the concept in Biztalk, and I doubt that they would have made it part of the OS if that experience was not positive.
BTW, it's Vancouver, not Victoria. But I would be more than happy to say "hi" to your mom.
Laters
Helen
I believe WWF is here to stay, and will not be abandoned in future releases of the OS. After all, MS has had a few years of experience with the concept in Biztalk, and I doubt that they would have made it part of the OS if that experience was not positive.
I would tend to agree with the WWF concept would be more useful as a way of orchestrating a business process that requires the integration of several applications, rather than sticking it into your CSLA app.
If you look at some of the commercial Enterprise Service Bus offerings, they each include orchestration engines that gives the developer ability to work at "higher abstraction level".
So for example, using the PTracker example, let's say someone wanted to deliver a message to the team members of projects that are running late, perhaps executing once a week. Using the PTService interfaces, an orchestration engine could do this utilizing the exposed services and not have to touch the Tracker application code. The workflow code could decide what "deliver a message" meant (email, snailmail) based on rules. Furthermore, PTracker wouldn't have know or care about how email is to be sent. It simply stores and returns email addresses... it's all handled outside the application.
Is this a good thing or bad thing.... I guess it depends... ;-)
Rob
Now you're heading toward what I keep mentioning as what I believe is the ultimate goal of these technologies.
(And BTW speaking of names I was just at a WCF presentation this afternoon and the slides referred to WinCF... guess you just pick whichever name you like.)
Now consider that with XAML and WPFe the technology will be there to be able to actually ship a form right along as part of the workflow that you're sending outside your organization/application.
On the one hand we can say "how cool is that?" Forget needing a web site for customers to interact with, you just send them the form which they run locally and it sends some information back via WCF when it's finished, or it talks back to the workflow server to see where the application goes next, etc.
On the other hand, I think it will lead to even more perversions of the n-tiered architecture than even some of the SOA addicts have already brought.
(Although, on that note I'm happy to report that the Microsoft presenter today described a good architecture as services (as in SOA) being a layer sitting on top of the business layer similar to, say, you're web site - just as Rocky has preached.)
But is it getting simplier?
No, nothing is getting simpler. Particularly not trying to keep up with all the new Microsoft offerings, let alone anything else which is non-Microsoft.
The requirements from the users (i.e. business) get more complex just as fast as the technology advances. They are not happy anymore with "silo" applications that only do one job. Everyone wants all their applications to talk to all their other applications in one huge seamless model of their entire business.
Hey, but it keeps us all in work though
Copyright (c) Marimer LLC