Some random gibberish

[Kevin O'Neill]

I've been thinking about how I might like to use werkflow to determine
actions in an application. These are part notes, part conversation
piece, part gibberish (or the more localised version "kevineese").

Here's a use case I would like to support using werkflow.

Create User
-----------

Steps
-----

1. Gather - Get the user login, password and email address.
2. Validate - Ensure that the login and password are compliant with our
rules.
3. Store - Store the users record with an unverified flag
4. Send Confirm - Send a notification to the registered address with a
request for confirmation confirmation
5. Receive Confirm - Update the unverified flag for the user
6a. Send Sys Alert - Notify System admin of new user registration
6b. Index - Add the user to the list of active users
6c. Add the user to the announcements mailing list
7. End Process

Alternatives

2.1 -- Failed Validation
2.1.1 Notify - Notify user of validation errors.
2.1.2 End process

5.1 -- Confirm not received in 48 hours
5.1.1 Remove - Remove user record.
5.1.2 Send alert - Notify sys admin of fail registration
5.1.3 End process.

5.2 -- Receive Confirm after 5.1.1
5.2.1 Notify - Notify expiration of confirmation.
5.2.2 End process

---

Okay so it's a pretty straight forward use case (and I'm not a analyst
so excuse any trespass on use case no-nos) but it does highlight each of
the points I want to make from here.

Now lets talk a little about the implementation of this use case.

Our user environment; the user will interact with the system via a
series of html pages delivered via http(s). Notifications will be sent
via email.

----

Event initiation
----------------

I see four messages (1, 5, 5.1, 5.2).

1 is initiated via a an http request. It would be nice be be able to
call the werkflow engine in a blocking mode to handle the 1,2,2.1
interaction

5.1 is a timed event. 5.2 is probably an error (ie the associated case
has been completed)

5 and 5.2 are initiated by email. James?

A shot at some werkflow bits
----------------------------

<process id="confirm" initiation="call">
<attributes>
<attribute id="login" in="true">
<java:attr-type type="java.lang.String"/>
</attribute>
</attributes>

<parallel>
<java:action type="com.example.notify">
...
</java:action>
<jelly:action>
...
</jelly:action>
<java:action type="com.example.index">
...
</java:action>
</parallel>
</process>

enough for now. I'm thinking I want to start on a full working example
with web, email interaction etc. User management seems to fit the bill,
what do others think.


-k.

ps: sorry for cutting this short ... have to go and make dinner for
children :).

[bob mcwhirter]

Post by Kevin O'Neill
Here's a use case I would like to support using werkflow.
Create User
-----------
Steps
-----
1. Gather - Get the user login, password and email address.
2. Validate - Ensure that the login and password are compliant with our
rules.

For this typs of interactive thing, where you want to keep displaying
the form until folks have entered enough of the right data, I'm thinking
will be another layer outside of what we know as 'werkflow' at the moment.

I like having werkflow be messaging-based, but that doesn't lend itself
to interactivity with immediate feedback. So, by having a 'portal'
layer that builds/displays/accepts form input and then shoots off a
message to the core, we can maintain the distinction.

Post by Kevin O'Neill
3. Store - Store the users record with an unverified flag

I'd call this the 1st action of the core after receiving a message.

Post by Kevin O'Neill
4. Send Confirm - Send a notification to the registered address with a
request for confirmation confirmation

2nd action.

Post by Kevin O'Neill
5. Receive Confirm - Update the unverified flag for the user

a <receive> to wait for response.

Post by Kevin O'Neill
6a. Send Sys Alert - Notify System admin of new user registration

3rd action.

Post by Kevin O'Neill
6b. Index - Add the user to the list of active users

4th action.

Post by Kevin O'Neill
6c. Add the user to the announcements mailing list

5th action.

Post by Kevin O'Neill
7. End Process
2.1 -- Failed Validation
2.1.1 Notify - Notify user of validation errors.
2.1.2 End process
5.1 -- Confirm not received in 48 hours

Yah, I've still got to work on timeouts.

Post by Kevin O'Neill
5.1.1 Remove - Remove user record.
5.1.2 Send alert - Notify sys admin of fail registration
5.1.3 End process.
5.2 -- Receive Confirm after 5.1.1
5.2.1 Notify - Notify expiration of confirmation.
5.2.2 End process
1 is initiated via a an http request. It would be nice be be able to
call the werkflow engine in a blocking mode to handle the 1,2,2.1
interaction

We could, but I'd ask you think of another layer, possibly informed
by the engine, but separate. ie, maybe we have a <form> syntax to
define your abstract forms, and it presses out a struts Action or
something to handle the validation and message generation to the
wf core.

Post by Kevin O'Neill
5.1 is a timed event. 5.2 is probably an error (ie the associated case
has been completed)

Right, designed but not implemented.

Post by Kevin O'Neill
5 and 5.2 are initiated by email. James?

You can have a chunk that POPs email or acts like an SMTP server to
receive email, process it into some other easy-to-act-upon message
which then can flow through the MessagingManager to the core.

Post by Kevin O'Neill
enough for now. I'm thinking I want to start on a full working example
with web, email interaction etc. User management seems to fit the bill,
what do others think.

I think the first 'problem' to solve is the user-interactive parts.
I am working on support for synchronous actions, but there's still
a thread-pool involved, so it won't be a blocking call. Maybe we
can add some blocking semantics, but I'm still leaning towards a
UI layer external to the core sending messages.

Thoughts?

-bob

[duncan]

Here is a slightly different perspective ....

I have a real time visualization of the Towers of Hanoi demo running and
would like to hook up a view of the towers as well. This would let you
see the petri net with it's token(s) in one window and a the three
towers with moving disks in another.

The events from the engine are put into a queue which I animate later. I
chose this approach so as to not block the engine or consume excessive
cpu cycles when the ui receives large numbers of events from the engine.

So the engine solves the problem in < 1 sec and it takes me minutes to
animate what just happened in a way that a user would find useful. The
UI could also let the user rewind or fast forward the animation.

To keep the animation synchronized with the tower display I could use
the ui event queue to store hanoiDiskMovedEvents. Do we need a generic
way for any ui to tell the engine to pause? Like a 'step' command in a
debugger?

Later

D

Post by bob mcwhirter

Post by Kevin O'Neill
Here's a use case I would like to support using werkflow.
Create User
-----------
Steps
-----
1. Gather - Get the user login, password and email address.
2. Validate - Ensure that the login and password are compliant with our
rules.

For this typs of interactive thing, where you want to keep displaying
the form until folks have entered enough of the right data, I'm thinking
will be another layer outside of what we know as 'werkflow' at the moment.
I like having werkflow be messaging-based, but that doesn't lend itself
to interactivity with immediate feedback. So, by having a 'portal'
layer that builds/displays/accepts form input and then shoots off a
message to the core, we can maintain the distinction.

Post by Kevin O'Neill
3. Store - Store the users record with an unverified flag

I'd call this the 1st action of the core after receiving a message.

Post by Kevin O'Neill
4. Send Confirm - Send a notification to the registered address with a
request for confirmation confirmation

2nd action.

Post by Kevin O'Neill
5. Receive Confirm - Update the unverified flag for the user

a <receive> to wait for response.

Post by Kevin O'Neill
6a. Send Sys Alert - Notify System admin of new user registration

3rd action.

Post by Kevin O'Neill
6b. Index - Add the user to the list of active users

4th action.

Post by Kevin O'Neill
6c. Add the user to the announcements mailing list

5th action.

Post by Kevin O'Neill
7. End Process
2.1 -- Failed Validation
2.1.1 Notify - Notify user of validation errors.
2.1.2 End process
5.1 -- Confirm not received in 48 hours

Yah, I've still got to work on timeouts.

Post by Kevin O'Neill
5.1.1 Remove - Remove user record.
5.1.2 Send alert - Notify sys admin of fail registration
5.1.3 End process.
5.2 -- Receive Confirm after 5.1.1
5.2.1 Notify - Notify expiration of confirmation.
5.2.2 End process
1 is initiated via a an http request. It would be nice be be able to
call the werkflow engine in a blocking mode to handle the 1,2,2.1
interaction

We could, but I'd ask you think of another layer, possibly informed
by the engine, but separate. ie, maybe we have a <form> syntax to
define your abstract forms, and it presses out a struts Action or
something to handle the validation and message generation to the
wf core.

Post by Kevin O'Neill
5.1 is a timed event. 5.2 is probably an error (ie the associated case
has been completed)

Right, designed but not implemented.

Post by Kevin O'Neill
5 and 5.2 are initiated by email. James?

If you need a soft copy please let me know.
You can have a chunk that POPs email or acts like an SMTP server to
receive email, process it into some other easy-to-act-upon message
which then can flow through the MessagingManager to the core.

Post by Kevin O'Neill
enough for now. I'm thinking I want to start on a full working example
with web, email interaction etc. User management seems to fit the bill,
what do others think.

I think the first 'problem' to solve is the user-interactive parts.
I am working on support for synchronous actions, but there's still
a thread-pool involved, so it won't be a blocking call. Maybe we
can add some blocking semantics, but I'm still leaning towards a
UI layer external to the core sending messages.
Thoughts?
-bob
_______________________________________________
werkflow-interest mailing list
http://lists.werken.com/mailman/listinfo/werkflow-interest

[bob mcwhirter]

Post by duncan
To keep the animation synchronized with the tower display I could use
the ui event queue to store hanoiDiskMovedEvents. Do we need a generic
way for any ui to tell the engine to pause? Like a 'step' command in a
debugger?

Hm.

I definitely won't want a WfmsAdmin.pause() or step() methods.

Possibly some way to make a particular case explicitly stepped,
so then a processCase.step() might possibly fire a transition.

Though, there are significantly more Transitions in the petri than
there are steps in something like Hanoi. So, we'd have to be
able to step by at the Petri-level and at the Idiom level.

That's entirely possible. Though, I'm going to say "no" to
"can we rewind a flow" at this point. Too many other things
higher on the priority list. :)

-bob

[Kevin O'Neill]

Post by bob mcwhirter

Post by duncan
To keep the animation synchronized with the tower display I could use
the ui event queue to store hanoiDiskMovedEvents. Do we need a generic
way for any ui to tell the engine to pause? Like a 'step' command in a
debugger?

Hm.
I definitely won't want a WfmsAdmin.pause() or step() methods.

I agree. This looks like a case where the process if initiating the subsequent
events.

Post by bob mcwhirter
Possibly some way to make a particular case explicitly stepped, so then a
processCase.step() might possibly fire a transition.
Though, there are significantly more Transitions in the petri than there
are steps in something like Hanoi. So, we'd have to be able to step by at
the Petri-level and at the Idiom level.
That's entirely possible. Though, I'm going to say "no" to "can we rewind
a flow" at this point. Too many other things higher on the priority list.
:)

In this case couldn't the gui read the event output (a list, messages,
whatever) and manage it's own playback/replay?

Post by bob mcwhirter
-bob

[Kevin O'Neill]

Post by bob mcwhirter

Post by Kevin O'Neill
Here's a use case I would like to support using werkflow.
Create User
-----------
Steps
-----
1. Gather - Get the user login, password and email address. 2. Validate
- Ensure that the login and password are compliant with our rules.

For this typs of interactive thing, where you want to keep displaying
the form until folks have entered enough of the right data, I'm thinking
will be another layer outside of what we know as 'werkflow' at the moment.
I like having werkflow be messaging-based, but that doesn't lend itself
to interactivity with immediate feedback. So, by having a 'portal'
layer that builds/displays/accepts form input and then shoots off a
message to the core, we can maintain the distinction.

Gather is obviously and outside operation =(in this sample done via a html
page). The HTTP form would contain the information required to initiate
the process. I was careful not to introduce a loop into this, it's just
work or fail (fail ending the case).

My reason for wanting to keep it in the work flow is simple. One place. I
don't need to care if the system is running struts, webwork, maverik or
cocoon (I envisage adapters to extract parameters and initiate events for
each of these environments).

The blocking should not be a part of the werkflow but rather an indication
from event initiator that it wants to wait (how we determine when it
returns is a point for discussion).

Post by bob mcwhirter

Post by Kevin O'Neill
3. Store - Store the users record with an unverified flag

I'd call this the 1st action of the core after receiving a message.

I don't excpect to see errors like the database is dead, or you run out of
disk space etc, in the use case. We will need to allow a response to the
error condition though (email admin, hide under the bed etc).

I can see three possible places (excuse my ignorance if it's already
there), Engine, process and case.

Post by bob mcwhirter

Post by Kevin O'Neill
4. Send Confirm - Send a notification to the registered address with a
request for confirmation confirmation

2nd action.

Post by Kevin O'Neill
5. Receive Confirm - Update the unverified flag for the user

a <receive> to wait for response.

Post by Kevin O'Neill
6a. Send Sys Alert - Notify System admin of new user registration

3rd action.

Post by Kevin O'Neill
6b. Index - Add the user to the list of active users

4th action.

Post by Kevin O'Neill
6c. Add the user to the announcements mailing list

5th action.

Post by Kevin O'Neill
7. End Process
2.1 -- Failed Validation
2.1.1 Notify - Notify user of validation errors. 2.1.2 End process
5.1 -- Confirm not received in 48 hours

Yah, I've still got to work on timeouts.

Post by Kevin O'Neill
5.1.1 Remove - Remove user record.
5.1.2 Send alert - Notify sys admin of fail registration 5.1.3 End
process.
5.2 -- Receive Confirm after 5.1.1
5.2.1 Notify - Notify expiration of confirmation. 5.2.2 End process
1 is initiated via a an http request. It would be nice be be able to
call the werkflow engine in a blocking mode to handle the 1,2,2.1
interaction

We could, but I'd ask you think of another layer, possibly informed by
the engine, but separate. ie, maybe we have a <form> syntax to define
your abstract forms, and it presses out a struts Action or something to
handle the validation and message generation to the wf core.

See my notes above :)

Post by bob mcwhirter

Post by Kevin O'Neill
5.1 is a timed event. 5.2 is probably an error (ie the associated case
has been completed)

Right, designed but not implemented.

Post by Kevin O'Neill
5 and 5.2 are initiated by email. James?

You can have a chunk that POPs email or acts like an SMTP server to
receive email, process it into some other easy-to-act-upon message which
then can flow through the MessagingManager to the core.

Post by Kevin O'Neill
enough for now. I'm thinking I want to start on a full working example
with web, email interaction etc. User management seems to fit the bill,
what do others think.

I think the first 'problem' to solve is the user-interactive parts. I am
working on support for synchronous actions, but there's still a
thread-pool involved, so it won't be a blocking call. Maybe we can add
some blocking semantics, but I'm still leaning towards a UI layer
external to the core sending messages.

I don't think that the process itself should have a blocking note (I might
be calling this process from a bulk loader). I do think that the caller
though should be able to wait on a response.

-k.