Hi Andreas,
On 10/23/07, andreas <[EMAIL PROTECTED]> wrote:
>
> If an external application read the workitem from the queue what does
> it mean for this application to implement ... until the workitem
> comes back from the queue ... --> What does it mean (without using
> SqsListner ) ?
> Is it possible to give a short explanation.
Well, at first the workitem should have been encoded in a format
understandable by the application reading it on the queue (JSON, XML,
it depends...). Out of the box, the current SqsParticipant serializes
the workitem as YAML encoded in Base64.
The application is then free to manipulate the decoded workitem.
Then at some point, if required, the application has to send back the
workitem to the engine.
> >>>Most of the time, there is a one to one relation, one participant
> >>>dispatches a workitem, and it somehow comes back via a listener. The
> >>>participant is sometimes passed a 'timeout'.
>
> >>>The 'listen' expression is about tying listening behaviours to do
> >>>cross process instance tricks. I think this 'listen' expression is
> >>>close to the BPEL "receive activity" thing.
>
> Does it mean that there is no way to have a "receive only"
> participant ?
It's possible, participant implementations are really out of the scope
of the process definitions in OpenWFE[ru].
> Potentially this is related to the problem: How do you define the enty
> point in a running process instance ?
That's maybe where the "listen" expression would be useful. Currently
"listen" doesn't work without a children expression, but it would be
easy to make it look more like a "participant" expression, blocking
until a reply comes.
It's perfectly fine to have participants that "listen only", it's just
a matter of implementation.
That's what I like with Ruby, everything is so open, putting tests
into place is so easy. I don't have to implement everything.
> This is not really a problem but it could be a source for confusion.
> >From my point of view it could be better to make some small syntax
> changes to describe more intentionally in which way the communication
> between the engine an the participant should be performed.
>
> Somethink like:
>
> concurrence do
> participant :alice, :listen
> participant :bob, :call
> participant :alpha :send
> end
>
> -------------------------------
>
> :listen, :call, :send are values for a standar parameter which
> defaults to
> :call (asynchron request/response )
>
> - :call correspond to the current standard notation
> - :send correspond to forget
> - :listen is from implementation point of view the same as :call but
> the only meaningfull infos which are needed from workitem is the "flow
> expression id" .
>
> :listen, :call, :send are only examples for possible values.
>
> What do you think ?
Somehow you can have that out of the box with OpenWFEru.
participant :toto, :behaviour => :send
The :behaviour => :send is passed in the workitem under the "params"
attribute. You're then free in your participant implementation to use
that information.
I have to say I like the <forget> concept as an expression on it owns,
you can build more things on top of it than with the :forget / :send
limited to the participant expression.
We can certainly implement BPEL expressions within OpenWFEru, but I
somehow would like to keep that "higher level feeling" to OpenWFEru.
If you have a BPEL mindset, I'd be glad to help you taylor OpenWFEru
to your needs.
Maybe you have a use case / process you'd like to model, we could use
it as a further base for this definition language discussion.
Herzliche Gruesse,
--
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
-~----------~----~----~----~------~----~------~--~---
