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 !


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


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


> 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).

FormFaces and Mozilla XForms would be great, not sure about FormFaces
license. Densha forms can be switched on a per workitem basis...


> 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/e54d4014365d5212#

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.


Best regards,

-- 
John Mettraux   -///-   http://jmettraux.openwfe.org

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