daemon-kit & ruote duo

[Kenneth Kalmer]

Hi everyone

First off, my apologies for posting to both the ruote and daemon-kit lists, but this is news for both groups

John and myself had a great chat in #ruote a couple of hours ago on how to extend daemon-kit to abstract away the complexities of writing the remote ends of the AMQP/XMPP participants. I've completed a proof of concept implementation of the remote end of an AMQPParticipant.

The results are a new branch and a simple quickstart to show how the functionality works.

To get going, following these steps:

$ git clone git://github.com/kennethkalmer/daemon-kit.git
$ git checkout ruote
$ rake gem
$ gem install pkd/daemon-kit-0.1.7.10.gem --no-ri --no-rdoc

$ mkdir dk-ruote
$ daemon-kit pd -i ruote
$ cd pd
$ ./bin/pd

In another terminal

$ cd dk-ruote
$ gem install ruote --no-ri --no-rdoc      <- Get the dependencies
$ git clone git://github.com/jmettraux/ruote.git       <- But we'll use edge
$ wget http://gist.github.com/raw/144861/49be37e0456bf0fe5018d45516ce03f44a569e0d/daemon-kit-engine.rb
$ ruby daemon-kit-engine.rb

If all goes well, you should have a random quote appear on the console.

Files to note in the daemon:

* libexec/pd-daemon.rb
* lib/pd.rb
* lib/sample.rb
* config/ruote.yml
* config/amqp.yml

And daemon-kit-engine.rb from the gist

You need a running rabbitmq server, the samples all use guest:guest on the / virtualhost to communicate. You also need the amqp & json gems installed.

The whole aim of this branch is to stabalize over the weekend and release a 0.1.7.10 release. I already maintain remote participants written with daemon-kit, so extracting the common code and cleaning it up a bit wasn't a big undertaking. The stable branch should give any ruote & daemon-kit user the ability to get going with remote ruote participants quite easily and not interfere with the way they setup their business processes.

With changes scheduled for ruote 2.0 we'll be able to have a less verbose process definition, specifying things like queue names during participant registration. My initial brainstorm with John revolved around this gist: http://gist.github.com/144471.

I'll expand this to the XMPP side in a later release.

Hope this helps learning ruote more fun and helps power plenty of autonomous processes !

Thanks

--
Kenneth Kalmer
kenneth...@gmail.com
http://opensourcery.co.za
@kennethkalmer

[John Mettraux]

On Sat, Jul 11, 2009 at 7:48 AM, Kenneth Kalmer<kenneth...@gmail.com> wrote:
>
> The whole aim of this branch is to stabalize over the weekend and release a
> 0.1.7.10 release. I already maintain remote participants written with
> daemon-kit, so extracting the common code and cleaning it up a bit wasn't a
> big undertaking. The stable branch should give any ruote & daemon-kit user
> the ability to get going with remote ruote participants quite easily and not
> interfere with the way they setup their business processes.
>
> With changes scheduled for ruote 2.0 we'll be able to have a less verbose
> process definition, specifying things like queue names during participant
> registration. My initial brainstorm with John revolved around this gist:
> http://gist.github.com/144471.

Hello Kenneth,

thanks for sharing and explaining ! Priceless.

For those on the list that don't follow his blog, I'd like to point to
one of Kenneth's latest posts :

http://www.opensourcery.co.za/2009/07/06/driving-business-processes-in-ruby/

Where he explains some of the details of his system's architecture
which uses, among others ruote and state_machine
(http://github.com/pluginaweek/state_machine/)

Best regards, thanks again !

--
John Mettraux - http://jmettraux.wordpress.com

[Kenneth Kalmer]

On Sat, Jul 11, 2009 at 2:34 AM, John Mettraux <jmet...@openwfe.org> wrote:

On Sat, Jul 11, 2009 at 7:48 AM, Kenneth Kalmer<kenneth...@gmail.com> wrote:
>
> The whole aim of this branch is to stabalize over the weekend and release a
> 0.1.7.10 release. I already maintain remote participants written with
> daemon-kit, so extracting the common code and cleaning it up a bit wasn't a
> big undertaking. The stable branch should give any ruote & daemon-kit user
> the ability to get going with remote ruote participants quite easily and not
> interfere with the way they setup their business processes.
>
> With changes scheduled for ruote 2.0 we'll be able to have a less verbose
> process definition, specifying things like queue names during participant
> registration. My initial brainstorm with John revolved around this gist:
> http://gist.github.com/144471.

Hello Kenneth,

thanks for sharing and explaining ! Priceless.

For those on the list that don't follow his blog, I'd like to point to
one of Kenneth's latest posts :

 http://www.opensourcery.co.za/2009/07/06/driving-business-processes-in-ruby/

Thanks for the promo John, and mentioning the post is actually spot on with what I'm busy implementing.

I've polished the implementation a little since I posted this morning, and added some docs. The main documentation is available in the RuoteParticipant.txt file (http://github.com/kennethkalmer/daemon-kit/blob/e00a5bfd2bc254c6b10a64f134716fbc08848829/RuoteParticipants.txt).

The only major tweak is that the pseudo-participants implemented in daemon-kit will only ever have their public methods called. I hope this helps close a potentially serious security hole since the whole implementation is driven by trust.

Any case, I'll be continuing implementing my own remote participants and further polish/toughen the implementation before merging back to master and tagging 0.1.7.10.

Best

[Kenneth Kalmer]

Hi everyone

The original thread [1] has the history if you've missed everything leading up to this.

I merged the ruote branch into master on daemon-kit, bringing the ruote integration to a close and fixing some other small nuisances in between as well.

Again no version bump, I'll probably do that in the next day or two as I continue implementing remote ruote participants with daemon-kit.

So far this has been the most promising work in daemon-kit, and combined with ruote it really makes for a great way to delegate work to autonomous participants. The code is solid (and in production already).

I'll do a write-up on my blog over the weekend on exactly how to use these two great projects together, and I'll prepare another "state of the project" post to reflect on where we're going with this baby.

Thanks for all the great feedback and support over the last month, and my apologies for the times I took my time to respond to github messages and direct emails.

Best

[1] - http://groups.google.com/group/daemon-kit/browse_thread/thread/e3e3178e4b200520