Matt, I am with you. We have similar needs for something fairly simple. In my case, I would like to interface a Flex BPMN Process Designer to a Rails Application running OpenWFERu. Several other clients/designers seem to be in the mill...so I would love to see everyone work together...
I am not certainly looking forward to writing a huge spec but I suspect that we are not the first ones to design such an similar interface. We will also need to handle RESTful security somehow! >From a client perspective, I am not sure it matters if you are running OpenWFERu or not. You still need something really standard to start/stop/cancel/status a process... Pat. > From: Matt Zukowski <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Mon, 23 Jul 2007 17:35:56 -0000 > To: OpenWFEru dev <[email protected]> > Subject: [openwferu-dev] Re: some conceptual REST questions > > > 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 -~----------~----~----~----~------~----~------~--~---
