Yay. In case you're looking for a release, there is none. Not yet, we are maybe going to release one, but it's a question of time rather than a lack of good will.
Why. In my current position, I am building a set of applications ( most of them rails based ) communicating with each other in a RESTful manner. This is, well, just continue reading my ActiveResource rant here. It's not really nice to use the official ActiveResource thing. It's a lot of hardcoding ( e.g. you have to set the remote service' URL in the model, not in some kind of configuration file, which makes switching from development to testing and production a pain ) and other shortcomings. It's a good idea, yet far from being perfect. And the two things that bothered me most were service discovery, meaning, the easy ability to resolve a service by its name than by its url, and authentication. Both of them are crucial for a system exceeding the hello world boundaries. That is, what I'm doing. So, utilizing all of Ruby's beauty, a) a Rails plugin was developed and b) a standalone Server acting as a Central Authentication Service and Service Discovery instance. And from what I can tell, it's beautiful ( not the codebase, at the moment, but the functionality ).
What is this thing able to do? Well, for the simple parts, it handles all your authentication needs. No more password juggling, just do it in one place, and nowhere else. OpenID compatibility is on the way, both as consumer and provider. It's nice to have this kind of functionality by only installing a plugin and create a before_filter.
The next big thing is the service discovery. ActiveResource wasn't used as an entry point for customizations, it was HyperactiveResource. I extended it to provide the ability to connect to the above mentioned central instance ( the address of this instance is defined in a configuration file, by the way ) to retrieve a services' address. A simple thing, yet it makes life so much easier.
Is there a clue? Yes. Bundling the two features above, you are able to allow and disallow communication between two services at your will. Bidirectional, so assuming you do have an E-Mail-service and an AddressBook-service, you now can allow the E-Mail to access your AddressBook, without allowing the other direction. Authentication is handled completely transparent to the developer, and the rest of the usage is like HyperactiveResource. Just a charm.
And for me? Fun is back :-)