On Fri, Jul 16, 2010 at 07:06:54PM +0100, David Greaves wrote:
> On 15/07/10 15:31, John Mettraux wrote:
>
> >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.
Hello David,
Less "work" ? How do you launch workflows ?
Remember that you can also pass process definitions as URI references.
> >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).
Yes, this is were I don't want to wander (ie I don't want to have the
responsibility to maintain it).
Pushing messages over AMQP is simple enough. Building a RPC framework on top of
it...
> 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 will add the "cancel" message to the "work" messages listed above. It is a
must.
> >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.
Not.
> >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 !
Replace "amqp-" with "do_" and there is no exposition of AMQP at all.
> I would like ruote's *beautiful* and readable process definitions
> that don't care if amqp is involved. Lets move quickly on ... :)
Remember "engine.register_participant x, y, z" is not part of a process
definition. It's configuration logic happening on a different timeline.
> ... 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.
In my small one line example, I force the queue on the participant. You could
write logic to determine the queue based on the workitem content (or simply the
workitem.participant_name).
> >=== 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.
OK, ok, replace 'amqp' by 'gucci' and you've got the elegance and no AMQP
exposition (even loosely).
> >== 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.
OK, "please have a smart mapping" vs "I just want to add a mapping".
> >=== 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.
As said, the need to build a custom RPC framework on top of AMQP. HTTP is sweet
with its request/response system.
> 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.
Hence the need for RPC in your admin / control channel.
> >=== 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?
As said, the need to build a custom RPC framework on top of AMQP. HTTP is sweet
with its request/response system.
> >=== 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
That code would be needed in participants that need to register participants in
the engine.
I'd be glad to help with this control thing (read : [implement, ]write tests
and maintain), but the RPC thing feels inelegant. Maybe this control thing is
better under your control (in your fork / extension).
Best regards,
--
John Mettraux - http://jmettraux.wordpress.com
--
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
