Matt, John,

I would really love to know where this is going.
I have only to-do list to implement a generic rest interface for workflow
engines (not limited to OpenWfe for interoperability).
There are too many of those interfaces floating around and not
interoperable.
We also need to think about security...

Here is a good generic picture:
http://www.wfmc.org/graphics/processmodel_large.gif

The WfMC has an older document here:
http://www.wfmc.org/standards/docs/if2v20.pdf

I am sure that Jboss/Oracle engines have something similar.
It would be nice for all of us to code to one interface if possible.
WDYT?
Pat.

> From: Matt Zukowski <[EMAIL PROTECTED]>
> Reply-To: <[email protected]>
> Date: Mon, 23 Jul 2007 16:40:00 -0000
> To: OpenWFEru dev <[email protected]>
> Subject: [openwferu-dev] some conceptual REST questions
> 
> 
> John, I'm trying to figure out the most sensical semantics for my REST
> interface, and need a little bit of guidance on this. As, you know,
> REST has four or five operational verbs for any particular resource:
> create, update, read, delete, and list. The update, read, and delete
> verbs generally take an identifier that specifies which instance of
> the resource they're dealing with.
> 
> My resource here is a 'Workflow', which corresponds to an instance of
> a running process definition. Its REST behaviour is as follows:
> 
> list -- Shows a list of all running workflows along with their status.
> 
> create -- Launches a new instance of a workflow. This takes two input
> parameters which specify the process definition to use, and the
> initial data for the workitem to feed into the workflow.
> 
> read(id) -- Shows the process status for some particular workflow. The
> id is the workflow id of the process.
> 
> delete(id) -- Cancels a process and does whatever else needs to be
> done to delete it.
> 
> update(id) ---- now this is where I'm feeling confused. My intention
> was to use this method to allow for updating the data of some workitem
> sitting in a storeparticipant, waiting to be updated. However, to do
> this, I need only three pieces of information: the name of the store
> participant waiting for an update, the flow expression id of the item
> to be updated, and the new data used to update the workitems
> attributes. I do not need an workflow id here at all. To me, the fact
> ath I don't need a workflow id suggests that I'm not really updating a
> workflow resource -- I'm updating something else... a participant, a
> workitem... I don't know. So maybe this is where trying to use a
> "Workflow" as my REST resources breaks down? Maybe my REST operations
> should be centered around a difference concept than the "Workflow"?
> Can you suggest something? On the other hand, maybe using a "Workflow"
> as the resource isn't wrong... only that a workflow system doesn't
> quite lend itself to CRUD operations, and it's okay to bend the
> meaning of the REST verbs here....
> 
> What do you think?
> 
> 
> > 



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to