Pat, I'm intentionally trying to keep this dead simple. Our needs and scope for this are limited and rather short-sighted, so I'm avoiding trying to build a grandiose framework. All I need is something that lets me expose an external API for creating workflows, feeding additional data into a running workflow (e.g. the result of some human approval request step), and fetching information about the status of a given workflow (i.e. where it's currently at, what it's waiting for, etc.)... I've picked REST because it's simple and easy to implement in our client apps.
I have a feeling that the end result will be somewhat loose and un- enterprise-y. A 171-page API spec is definitely not something I was intending on implementing (or even looking at, really). Despite this though, I think that the end result will be a small, agile app filling a pretty deep niche. We -- and I suspect many others -- just need something that handles relatively simple business processes like request approvals, document filing, etc. That said, I do want to make sure that I've got my head wrapped around the key concepts here, so as not to come up with something that isn't awkward (and the fact that I'm having a hard time getting a feel for OpenWFEru's semantics makes me feel like I haven't yet quite gotten a good feel for what this is all about.... the alternative being that OpenWFEru is just awkward :). On Jul 23, 1:11 pm, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
