John, > From: John Mettraux <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Fri, 26 Oct 2007 23:26:00 +0900 > To: <[email protected]> > Subject: [openwferu-dev] Re: Database Persisted Engine > > > Hi Pat, > > On 10/26/07, 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. > > Kudos, you're on every front ! You are doing all the work. I am just your marketing man! > >> 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 > > OK. > >> 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) > > Could you explain that (AtomPub) a little bit more ?
Here is the protocol description: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html This codifies a little more the RESTful approach. This provides a symmetrical Atom in / Atom out approach. This also provides a consistent and seamless publishing with Atom (Atom syndication format) and georss extension for GIS market ( http://georss.org/) > >> 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). > > I don't understand the transitions from RESTful webservice to GUI (the > Matelot designer) to Densha (engine + worklist + GUI). > > As I understand it, Matelot is a BPMN designer that exports to XPDL. The way I see the GUI is as a front-end to the OpenWFE backend. So, yes it does save the model in XPDL for persistence but would allow to connect to the backend and upload a new flow definition (either in XPDL or native). If upload is XPDL (which would make sense), the wrapper would convert it to native OpenWFE XML. >> What's missing is a generic forms engine. John is looking at FormsPlayer >> but this is Microsoft/PC centric soooo....not good for me. > > Well, in fact, the FormsPlayer guys are using OpenWFEja and they are > considering transitioning to OpenWFEru. They use the old REST[unful] > interface of OpenWFEja. So it's rather the other way around (I avoid > windows boxes). FormsPlayer only runs on Windows, right? > FormFaces and Mozilla XForms would be great, not sure about FormFaces > license. Densha forms can be switched on a per workitem basis... Yes. Forms are a non-issue with Densha. >> 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 available >> http://www.mozilla.org/projects/xforms/ > > You're far ahead on that. Thanks for the scout work. > > >> Would be great so see some convergence and leverage synergies... > > Yes, of course. > > For this RESTful workflow webservice, my impression is that there are > currently 3 visions for it. > > 1) Fluxr, Matt attempt at a very simple wrapper around the OpenWFEru > engine. Matt emphasis on making things simple for his fellow > developers is interesting > > 2) Kisha, my hypothetic webservice, à la John, that Matt commented as > being too confusing for a developer > http://groups.google.com/group/openwferu-dev/browse_frm/thread/e54d4014365d521 > 2# > > 3) GeoBPMS, for and from Pat's front line. > > Fluxr is / was rather comfortable for me as it's another project. > GeoBPMS is a bit cosmopolitan, some aspects in it are IMO not relevant > to OpenWFEru (for example workflow definition metadata), they could be > layered on top of Kisha though. > > > Half-baked mail reply sorry. > > I wish I could give more time to OpenWFEru. I think you are doing an unbelievable great job with OpenWFEru. GeoBPMS is really an enhanced and RESTful Densha. Light frontend and solid OpenWFE integrated within RAILS. This combination would be an ideal Rails wrapper for OpenWFE. Still some major infrastructure work to do for realtime debugging... I am not sure what Kisha is yet. Fluxr/kisha could be an alternative to the Flex approach (Matelot) and provide the designer environment for Densha++. GUIs are very difficult to keep generic so I would like to see them decoupled from the "wrapper". SO I do not think that we are that far off. Regarding the comment on relevance for meta-data, here is my use-case. A designer starts working on a workflow. Designer registers/publishes a workflow name, id, .. Author, organization... security access level and other things like that. This does not change that much. This is the workflow resource that gets created. Then, the designer starts working on the workflow and creates the actual flow using the BPMN tool (fluxr/kisha/matelot). This can go through several iterations (versioning). Many definitions can be uploaded and available at anytime. They can be enabled/disabled... As far as user is concerned, she only executes a workflow by name. The latest enabled definition will be used (unless she specifies a specific version). This is critical when workflows are changing and you need to go back to older version for testing. RESTful approach requires a good analysis of what the resources really are. So I really see: workflows, definitions, instances and traces. I would love to get your feedback on what you think it ought to be. Pat. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
