On 15/07/10 15:31, John Mettraux wrote:
On Thu, Jul 15, 2010 at 09:22:47AM +0100, David Greaves wrote:
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".
So I still see this as a useful analogy.
AMQP has the launchitem listener which takes different types of message;
currently 'definition' and 'receive'
I propose supplementing that with 'register'
[snip]
ruote-amqp is about communicating between an engine and a participant. Engine
emits work towards participant, later on, the participant may reply.
Yes, this is clearly work.
There is
also the case where a participant emits work towards an engine (launch).
OK. This involves passing in a process definition which of course defines and
names a number of process steps. Less work-y but I concur.
These are "work" operations.
What you are asking about is adding "admin" operations over that channel. I'm
a bit reluctant.
Agreed and I see your point (I did actually wonder myself but it was needed to
make the PoC operate and it worked well).
It would seem trivial for me to offer a parallel "enginecontrol" queue/service
which would be a little more RPC-like (insofar as it would be nice for a remote
registrant to receive acknowledgement that a registration has succeeded).
There's still need for a cancel operation (and we've identified a possible
progress-query operation) on a wfid(?) in an AMQP Remote Participant and I
propose using a simple RPC over AMQP framework based on Kenneths design.
I have started to add that to my local tree; I'll extend it to the enginecontrol
idea.
OK, let's explore two different classes of solutions to that.
Class A is about using the decoupling AMQP provides, so that registering
participants is not necessary,
OK - although I feel that this exposes AMQP and loses a lot of the elegance in
Ruote.
while class B is the straightforward
exploration of "let's add participants to that engine".
Having read ahead I think what I'm after is less about dynamically adding
participant *classes*; more about adding mappings to allow elegant use of
dynamically connecting AMQP Participants. This may influence your thinking?
A decoupled Route can have a process launched from a remote location that uses
Participant instances that weren't even written when the engine was deployed.
Again thinking DB-server like.
== class A
[snip]
=== A.0 'amqp-x'
Let's register a participant under a regex :
engine.register_participant 'amqp-.+', RuoteAMQP::Participant, 'queue' =>
'y'
All the workitems for a participant whose name begins with 'command-' will go
there.
No offence but ... ugh !
I would like ruote's *beautiful* and readable process definitions that don't
care if amqp is involved. Lets move quickly on ... :)
... although, in the limit:
engine.register_participant '.+', RuoteAMQP::Participant, 'queue' => 'y'
but it would be a bit blunt and I'd just move the mapping to the thing handling
queue y.... not nice.
=== A.1 command :variant => 'x'
engine.register_participant 'amqp', RuoteAMQP::Participant, 'queue' => 'y'
then in your process definition
participant 'amqp', :variant => 'x' participant 'amqp', :variant => 'y'
Same basic complaint.
== class B
OK, so you really need to add participant to the engine.
Was it something I said? :)
Although as mentioned I think I just want to add a mapping... maybe there's no
real difference.
=== B.0 programmatically adding
You have access to the engine. You can register participants on the fly :
require 'my_participant' engine.register_participant 'toto', MyParticipant,
'flavour' => 'vanilla', 'position' => -2
How does this differ from:
if item.has_key?('register')
return unless item.has_key?('name')
register_participant(item["name"],
RuoteAMQP::Participant,
item["options"])
other than the message transport?
I *think* it's very similar - I like it.
Nb I would like register_participant to complain if the name is taken and
:overwrite != True.
In most cases I'd guess that registering a 2nd participant with the same name is
a bug although I can certainly see uses for it.
=== B.1 ruote-kit
Order over http to ruote-kit to register a participant
POST /_ruote/participants HTTP/1.0 Content-Type: application/json
[ "toto" [ "MyParticipant", { "flavour": "vanilla", "position": -2 } ] ]
The only problem is that Torsten and I still have to integrate that into
ruote-kit... Sorry.
No problem...
This looks like what I want.
However if most of my systems are using AMQP for communication, why use http?
=== B.2 modifying the participant-list in the storage directly
[snip]
Please note that the upcoming ruote 2.1.11 has methods that simplify that
approach :
[snip]
No need to restart the engine.
OK - but I wouldn't want that code replicate in every remote participant - I'd
pull it back to a service that would understand the storage I'm using.... and
we're back to B.0
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
