For some reason my reply to this bounced back... here it is again: ----
Pat, I'm in strong agreement here. Some comments though: 1. I think there may be some confusion between 'workflows' and 'definitions', just based on the name. Someone jumping in may be confused by the difference between a 'workflow' and a 'definition'. I would suggest an alternative name for 'workflow', but I'm not sure I fully understand what it is (you mention it would have meta-data like the author.... why not just make that part of the definition? does this really deservie its own model?) 2. I would recommend that we call 'definitions' 'workflow_definitions' and 'instances' 'workflow_instances'. Otherwise there may be some ambiguity (a 'definiton' could refer to a participant definition, and an instance could refer to a workflow engine instance). I know that these names aren't as pretty, but at some point we may have to deal with participant definitions and engine instances as RESTful resources, and things would get ugly anyway. 3. Can you explain the 'trace' concept? In Fluxr, a 'trace' is basically a property of a workflow instance. I don't fully understand why this is a separate model. Thanks, Matt. On Oct 26, 8:43 am, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > RESTful API for workflows is critical. I would love to see that > standardized for interoperability. This is a hot topic of discussion at the > OGC (OpenGeoSpatial Consortium) and Workflow Management Consortium (WfMC). > Lots of players in these 2 communities and OpenWFE is now showing up on > their radar screen. > > I will be presenting current ideas > at:http://www.transformationandinnovation.com/pages/register_oct30.php > Presentation will be available online. > > It would be great to get more inputs/participations from this community too. > > So far my approach has been to breakdown the resources like this: > - worflows: high level meta-data registration (name/author...) > - definitions: flow itself so it can be versioned/enabled/disabled > - instances: created when a workflow/definition is selected by a user > - traces: participant trace history of specific instance > > You would use POST/PUT/GET/DELETE against those resources. > BUT I would rather use Atompub as the underlying protocol to support > discovery and serving of service document (as well as WADL) > > I am not sure if the GUI (Matelot), in this case, ought to be a wrapper of > OpenWFE or external to OpenWFE to allow different users to use different > guis. So I picked an external version. This still requires a wrapper to > OpenWFE. Densha would be a good candidate (this is my starting baseline > anyway). > > What's missing is a generic forms engine. John is looking at FormsPlayer > but this is Microsoft/PC centric soooo....not good for me. > > I am using this:http://www.formfaces.com/ > A simple javascript gets added to your html and you are ready to go. > Only problem is initial drawing of page... Until FF XForms are > availablehttp://www.mozilla.org/projects/xforms/ > > Would be great so see some convergence and leverage synergies... > Wdyt? > > Pat. > > > From: Matt Zukowski <[EMAIL PROTECTED]> > > Reply-To: <[email protected]> > > Date: Fri, 26 Oct 2007 01:14:42 -0000 > > To: OpenWFEru dev <[email protected]> > > Subject: [openwferu-dev] Re: Database Persisted Engine > > > This seems to be a lively discussion, so I thought I'd throw my hat > > in.... > > > In regards to the original post, this is more or less exactly what we > > were trying to do at our organization also -- a simple interface for > > the engine that would allow client apps to instantiate workflows. Here > > is the result:http://code.google.com/p/fluxr/ > > > Fluxr wraps OpenWFEru in a stand-alone web server that provides a REST > > interface for client apps. So for example, to instantiate a workflow, > > you would use a REST client (like ActiveResource) to place an HTTP > > POST call to: > > >http://your.fluxr.server/workflows?workflow_definition=my_approval_pr... > > > Or if you want to get info about all running workflow processes, do a > > GET call to: > > >http://your.fluxr.server/workflows > > > Now, fluxr is still a bit of a work-in-progress... a stalled one at > > that, because the company where I was developing this for decided to > > go with a different BPM solution (lack of a GUI tool for building > > OpenWFE workflows definitions was the deal-breaker)... but it is more > > or less functional at this point. My next step will be to provide a > > proper UI for viewing the status of a workflow... right now the HTML > > output is very simplistic, and not really end-user ready. > > > Hope this helps. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
