Workflow persistence: your thoughts please..

[Andrew Jaquith <an...@mac.com>]

Hi everybody,

Ever since I created the workflow APIs, I've regretted the lack of a  
way to save workflows between WikiEngine restarts. Today, if you turn  
on workflows for things like page saves or user profile creation, and  
the WikiEngine stops, they vanish. So, workflow persistence is highly  
desirable.

The most obvious and "simplest" way (in theory) to persist workflows  
would be to serialize them to disk. However, this requires that we  
change the public APIs in the workflow packages that pass or return  
Objects to Serializable instead. This is probably not a big deal: few  
3rd party developers use the workflow package today.

So, here are my questions:

1) What does this group think about workflow persistence as a JSPWiki  
feature? Do we need it? (I think we do...)

2) If we need it, when should we implement it? 2.8 or 3.0? (2.8 might  
be easier, considering everything that is slated for 3.0)

BTW, the API changes are pretty minor (everything that used to say  
"Object" would be changed to "Serializable"):

public interface Step extends Serializable
+-- public Serializable[] getMessageArguments()

public class DecisionQueue implements Serializable

public class Fact implements Serializable
+--- public Fact(String messageKey, Serializable value)

public Serializable getValue()

public final class Outcome implements Serializable

public class Workflow implements Serializable
+--- public final void addMessageArgument( Serializable obj )

public final synchronized Serializable getAttribute( String attr )
+--- public final Serializable[] getMessageArguments()
+--- public final synchronized void setAttribute(String attr,  
Serializable obj)
+--- public final synchronized Serializable getAttribute( String attr )

In short: any custom workflows (of which there are only two in JSPWiki  
out of the box) would need to make sure that if they add message  
arguments or Facts that these are serializable objects. Pretty easy.

There are some other things we'd need to tackle, not all of which I  
have a complete grip on yet. The PreSave/SaveWikiPageTask that  
PageManager uses to route wiki page saves through its workflow would  
need to be slightly refactored.

We would also need to add some writeReplace/readResolve methods in  
objects that should be replaced during the deserialization process. In  
particular, any WorkFlowManager references would need to be  
dynamically replaced during deserialization with the one used by the  
current WikiEngine.

How would we do this, given that readResolve() et al doesn't accept  
parameters? I think one way to do it might be to turn util.Serializer  
into a singleton, and stash object instances there that  
deserialization methods could use. For example, before deserializing a  
Workflow object we could call  
Serializer.getInstance().stash(WorkflowManager.class,  
m_workflowManager), then inside WorkflowManager's readResolve call use  
Serializer.getInstance.get(WorkflowManager.class) to retrieve it.

What do you think? Worth doing in the short term? Am I missing anything?

Andrew

Re: Workflow persistence: your thoughts please..

[Harry Metske <ha...@gmail.com>]

Andrew,

I have never used the workflow stuff at all, neither on my personal wiki's
nor the one we run at the office.
I also don't have any plans on using it either. I can't really give you any
good feedback on this.

regards,
Harry

2008/6/23 Andrew Jaquith <an...@mac.com>:

> Hi everybody,
>
> Ever since I created the workflow APIs, I've regretted the lack of a way to
> save workflows between WikiEngine restarts. Today, if you turn on workflows
> for things like page saves or user profile creation, and the WikiEngine
> stops, they vanish. So, workflow persistence is highly desirable.
>
> The most obvious and "simplest" way (in theory) to persist workflows would
> be to serialize them to disk. However, this requires that we change the
> public APIs in the workflow packages that pass or return Objects to
> Serializable instead. This is probably not a big deal: few 3rd party
> developers use the workflow package today.
>
> So, here are my questions:
>
> 1) What does this group think about workflow persistence as a JSPWiki
> feature? Do we need it? (I think we do...)
>
> 2) If we need it, when should we implement it? 2.8 or 3.0? (2.8 might be
> easier, considering everything that is slated for 3.0)
>
> BTW, the API changes are pretty minor (everything that used to say "Object"
> would be changed to "Serializable"):
>
> public interface Step extends Serializable
> +-- public Serializable[] getMessageArguments()
>
> public class DecisionQueue implements Serializable
>
> public class Fact implements Serializable
> +--- public Fact(String messageKey, Serializable value)
>
> public Serializable getValue()
>
> public final class Outcome implements Serializable
>
> public class Workflow implements Serializable
> +--- public final void addMessageArgument( Serializable obj )
>
> public final synchronized Serializable getAttribute( String attr )
> +--- public final Serializable[] getMessageArguments()
> +--- public final synchronized void setAttribute(String attr, Serializable
> obj)
> +--- public final synchronized Serializable getAttribute( String attr )
>
> In short: any custom workflows (of which there are only two in JSPWiki out
> of the box) would need to make sure that if they add message arguments or
> Facts that these are serializable objects. Pretty easy.
>
> There are some other things we'd need to tackle, not all of which I have a
> complete grip on yet. The PreSave/SaveWikiPageTask that PageManager uses to
> route wiki page saves through its workflow would need to be slightly
> refactored.
>
> We would also need to add some writeReplace/readResolve methods in objects
> that should be replaced during the deserialization process. In particular,
> any WorkFlowManager references would need to be dynamically replaced during
> deserialization with the one used by the current WikiEngine.
>
> How would we do this, given that readResolve() et al doesn't accept
> parameters? I think one way to do it might be to turn util.Serializer into a
> singleton, and stash object instances there that deserialization methods
> could use. For example, before deserializing a Workflow object we could call
> Serializer.getInstance().stash(WorkflowManager.class, m_workflowManager),
> then inside WorkflowManager's readResolve call use
> Serializer.getInstance.get(WorkflowManager.class) to retrieve it.
>
> What do you think? Worth doing in the short term? Am I missing anything?
>
> Andrew
>



-- 
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081

Re: Workflow persistence: your thoughts please..

[Andrew Jaquith <an...@mac.com>]

There's no formal theory behind it... it's basically a finite-state  
machine with the ability to hook together branching and decision  
logic. The Workflow class itself provides a pretty good overview of  
the different parts, but in a nutshell a workflow is composed of  
Decisions and Tasks (both implement the Step interface). Both  
Decisions and Tasks can have Outcomes; depending on the Outcome, a  
previously-assigned next step executes.

Right now, JSPWiki only uses the workflow package in two places: for  
saving wiki pages (in PageManager) and creating user profiles (in  
UserManager). It's an extremely generic package that isn't really  
dependent on JSPWiki at all.

Andrew

On Jun 23, 2008, at 11:08 AM, Florian Holeczek wrote:

> Hi Andrew,
>
>> 1) What does this group think about workflow persistence as a JSPWiki
>> feature? Do we need it? (I think we do...)
>
> Sure! I didn't have the time to have a look at the workflow API yet,
> but I implicitly expected the implementation to persist it.
>
> BTW, is there a specific formal theory the workflows are based on,
> e.g. Petri nets or activity nets? Or is it a more or less simple
> document based workflow?
>
> Regards,
> Florian

Re: Workflow persistence: your thoughts please..

[Florian Holeczek <fl...@holeczek.de>]

Hi Andrew,

> 1) What does this group think about workflow persistence as a JSPWiki
> feature? Do we need it? (I think we do...)

Sure! I didn't have the time to have a look at the workflow API yet,
but I implicitly expected the implementation to persist it.

BTW, is there a specific formal theory the workflows are based on,
e.g. Petri nets or activity nets? Or is it a more or less simple
document based workflow?

Regards,
 Florian

Re: Workflow persistence: your thoughts please..

[Andrew Jaquith <an...@mac.com>]

Florian is correct. The definitions are persistent -- in the sense  
that every time you invoke the 'save wiki page' workflow, for example,  
it works the same way every time. The STATE of an individual workflow  
doesn't persist between WikiEngine reboots, though, which is what I  
was thinking about fixing.

Really, the goal with workflow was to make it easy to write code that  
did different things based on user input. It's a pain to write  
separate UIs for every single "do you want to do X or Y?" choice, right?

I don't have any specific plans for using it more in the short term  
(other than light refactoring of the existing workflow tasks),  
although it could clearly be used more extensively to support page  
moderation or admin tasks. Anything that has a human component  
("please review and approve...") could make use of it.

Andrew

On Jun 23, 2008, at 2:47 PM, Florian Holeczek wrote:

> Hi Terry,
>
>> (Like Florian, however, I presumed that the workflows were
>> persistent - not sure what value they'd have if they had to be
>> created from scratch all the time.)
>
> that's a misunderstanding... the workflow definitions are persistent
> of course, because they're java code implementing the workflow API.
> Only the workflow instances' states aren't persistent at the moment,
> and that's what I was presuming.
>
>> PS: It would be helpful if any list members who actually use the
>> workflow functionality (particularly in a production environment)  
>> could
>> comment about their use of it.  Also, maybe Andrew could comment on  
>> any
>> larger plans he has for moving it into a more central role in  
>> JSPWiki?
>
> Well, I've been playing around with the two implemented workflows
> which ship with JSPWiki already. They definitely are useful.
>
> Just think of workflow technology as an approach towards higher code
> reusability. I can imagine many use cases of extending JSPWiki in
> which this API is able to reduce time and effort considerably.
>
> Florian

Re: Workflow persistence: your thoughts please..

[Florian Holeczek <fl...@holeczek.de>]

Hi Terry,

> (Like Florian, however, I presumed that the workflows were
> persistent - not sure what value they'd have if they had to be
> created from scratch all the time.)

that's a misunderstanding... the workflow definitions are persistent
of course, because they're java code implementing the workflow API.
Only the workflow instances' states aren't persistent at the moment,
and that's what I was presuming.

> PS: It would be helpful if any list members who actually use the
> workflow functionality (particularly in a production environment) could
> comment about their use of it.  Also, maybe Andrew could comment on any
> larger plans he has for moving it into a more central role in JSPWiki?

Well, I've been playing around with the two implemented workflows
which ship with JSPWiki already. They definitely are useful.

Just think of workflow technology as an approach towards higher code
reusability. I can imagine many use cases of extending JSPWiki in
which this API is able to reduce time and effort considerably.

Florian

Re: Workflow persistence: your thoughts please..

[Terry Steichen <te...@net-frame.com>]

I think it would help a LOT if we could provide practical examples of
how workflows create unique benefits.  (And maybe pull the explanations
out of the javadocs and put it into a regular documentation form.)  Just
to show my ignorance in its full glory, in general, if I need a stateful
process, I will try to capture the steps in a JSP which handles all the
decision and processing logic within itself.  Presumably the workflow
capability provides a way to do this without the need for a dedicated
JSP (using my example).  But, like Harry, I've never used this
capability so don't know if it would be of any benefit or not.  (Like
Florian, however, I presumed that the workflows were persistent - not
sure what value they'd have if they had to be created from scratch all
the time.)

I also think this might provide an example for us to rethink what we're
doing with JSPWiki.  I see from the subsequent posting that JSPWiki uses
workflows in two places (and I had thought it was also involved in
login?).  That limited role suggests that workflow functionality may be
quite far removed from core JSPWiki functionality.  And there's
something to be said for keeping such capabilities out of the core.

Knowing Andrew's capabilities, I feel certain that the workflow
implementation is probably quite elegant.  However, at this point I
don't feel strongly about the usefulness of the workflow capability
(largely because I don't know much about it).  And, I think it does
provide an example for considering just how far to expand JSPWiki, in
what directions.

Terry

PS: It would be helpful if any list members who actually use the
workflow functionality (particularly in a production environment) could
comment about their use of it.  Also, maybe Andrew could comment on any
larger plans he has for moving it into a more central role in JSPWiki?