John, I'm asking these questions not because I want to poke holes in OpenWFE, but because I want to better understand how you structured the system and why you chose to do it the way you did. Obviously you've given this a lot more thought than I have, so whenever something seems awkward to me, I assume it's my fault and not yours. For example I think the point you made about the worklist and about workitems in concurrence clarifies things for me a bit, and helps me better understand why things are the way they are.
Now, as for the REST API, I'm trying to organize it around our use case -- from the point of view of the other programmers here that will be using this workflow server. The server's perceived behaviour should allow the programmer to 1) instantiate a workflow with some piece of data, 2) find out where that piece of data is within the workflow, 3) provide additional information to participants within the workflow whenever needed. That's it. Nothing more, nothing less. The programmers shouldn't have to understand what an expression is, what participants are, what the engine is, etc. All these things can and should be abstracted away. For example, we might have a workflow defining an approval process for requesting a new project. The process involves 1) submitting some information (the project's proposed name, client, budget, etc.), 2) sending out approval requests to managers, and then 3) notifying the person who requested the project of the result. A programmer making use of this would place a call to the workflow server with two pieces of information: the name of the workflow definition to use (e.g. "new_project_request"), and the data payload (a hash with the project name, etc.). In return the programmer gets some identifier that lets them refer back to this later on. At this point the workflow server takes over, and the only thing the programmer might want to do is check whether the workflow is done or if its being held up somewhere, or to provide additional information to a participant waiting within the workflow. So, I think that to facilitate the above process, the server should expose only the following behaviours: 1) Launch a workflow based on some data payload, returning a reference identifier. 2) Return the state of the workflow, based on the given reference identifier. 3) Talk to a participant within the workflow (for example to update the data payload) Framing this behaviour in a REST interface, I think that the one you posted above is great in terms of reflecting the underlying structure of OpenWFE, and maybe even in terms of the conceptual structure of a general workflow system, but it would be a bit confusing to a programmer who just wants to throw some data into a workflow and cares only about its status and result. So maybe the interface for the workflow instance should be something like: == Resource: WorkflowInstance C: launch a new workflow instance (returns workflow instance id) R: get status of workflow instance (returns OpenWFE's ProcessStatus object, serialized) U: no operation D: cancels workflow instance This is great for behaviours (1) and (2), but leaves us with the problem of how to deal with (3). Can you explain a bit what you mean by the "participant /slash/ workitem_id" resource? What is a workitem_id in OpenWFE terms? My impression was that the only way to reference to a workitem sitting in a participant is by knowing the participant name and FlowExpressionId (i.e. engine.get_participant(name)[fei]). I agree that we need a resource that corresponds to a workitem sitting within a participant, but I can't quite get my head around conceptualizing it. Whatever it is, external application will need some way of addressing it directly. Lets say my workflow looks something like: 1) send approval request by email ---> 2) wait for response ---> 3) send response to original sender Once the workflow gets to (2), I need the external application to somehow know how to address (2), and right now -- as far as I can see -- the only way to do this is via a combination of the participant name and fei. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
