On 15/07/10 02:00, John Mettraux wrote:
Hello,
some of you have been asking (mostly IRC), about "dynamic participants".
Hi guys
I am certainly interested in that.
One of the motivations went like "participants just for that process
instance", that got me thinking.
Although this is not my use-case.
The solution advocated was to register participants then unregister them via
the process. This is possible, but sounds like a lot of work (and you have to
unregister them).
I've been looking at an obscure feature about variables and indirection :
http://github.com/jmettraux/ruote/blob/ruote2.1/test/functional/ft_27_var_indirection.rb#L13-30
[snip]
For the AMQP people out there, it would look like
set 'v:customer' => [ 'MyProject::CustomerParticipant', { 'queue' => 'x' } ]
Maybe I should look at a new expression that could say :
register 'customer', :class => 'MyProject::CustomerParticipant', :queue =>
'x' register 'customer', :class => '${f:customer_participant_class}', :queue
=> '${f:the_queue}'
that would do the "set variable".
I know it's a bit confusing, but anybody has comments ?
Well, using Ruote in an AMQP setting my expected usage is a little different:
http://wiki.meego.com/BOSS/Presentation - FYI.
so this is to clarify that the solution above doesn't conflict with a
semi-dynamic AMQP participant registration (and eventually de-registration)
solution.
I see an analogy with a production sql database. You don't want to stop the
database server and restart it when a new database is created. You need a
mechanism to "create table".
AMQP has the launchitem listener which takes different types of message;
currently 'definition' and 'receive'
I propose supplementing that with 'register'
http://github.com/lbt/ruote-amqp/blob/register/lib/ruote-amqp/receiver.rb#L112-116
Eg:
A Ruote instance is running on system A using a storage engine
It has some registered processes in flow which are connected using amqp to
participants on systems B (a build engine) and C (a data warehouse)
This moves into production state.
A new business process is required.
Participants for system D (test system) and E (reporting application) are
developed.
Participants D and E start and register on the engine.
A workflow can now be started without changing A.
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
