New project: Ruby Message System (RMS)


#1

I have relied on guarenteed delivery asynchronous messaging to build
large scale systems for 20 years. I was surprised when I could not find
something simular to Java’s JMS for Ruby so I decided to build my own
and release the server under a GPL license and the client libraries
under a LGPL license. When I have code to release it will be in the
usual place (www.markwatson.com/opensource).

If I am reinventing the wheel, please let me know! I only plan on
implementing what I need, but maybe when there is a public code base
other people might contribute. This project is in the planning stage
right now. Here are some rough notes:

  1. unlike Java JMS, there is currently no planned support for publish
    and subscribe

  2. the primary data structure of RMS is a shared collection of named
    message queues

  3. there is currently no planned support for security: it is
    anticipated that enterprise applications will use RMS behind a
    firewall. very limited security will be provided by an optional
    configuration file that specifies allowed IPs for clients.

  4. operations supported:

create_queue(name)
delete_queue(name)
send_message(queue, message)
register_listener(queue, a_listener)

note: a_listener object must be able to respond to the message:

receive_message(message)

  1. sent messages are persisted using a database or a flat file and must
    be serializable

  2. once a message is delivered to all registered listeners for a queue
    the message is deleted from persistent store

  3. eventually, I would like to support transparent interoperability
    with ActiveMQ via stump so Ruby code could interoperate with systems
    written in different languages that use ActiveMQ.

I would appreciate any suggestions, ideas, etc.

Thanks,
Mark


#2

How about this?
http://rubyforge.org/projects/stomp/
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/165089


#3

also there are ruby bindings for spread

http://www.spread.org/

j.

On 12/28/05, Wilson B. removed_email_address@domain.invalid wrote:

usual place (www.markwatson.com/opensource).
message queues
send_message(queue, message)
the message is deleted from persistent store


“Remember. Understand. Believe. Yield! -> http://ruby-lang.org

Jeff W.


#4

Thanks Wilson.

I have already been looking at ActiveMQ + stomp, but I wanted something
pure ruby and light weight.

That said, I just installed the stomp gem and am now installing
ActiveMQ server on one of my development machines.

-Mark


#5

On Thu, 29 Dec 2005, Mark Watson wrote:

Thanks Wilson.

I have already been looking at ActiveMQ + stomp, but I wanted something
pure ruby and light weight.

That said, I just installed the stomp gem and am now installing
ActiveMQ server on one of my development machines.

you may want to look at tuple spaces. i would think it would be about
25
lines to implement a msg queue on top of that. the publish/subscribe
bit is
already taken care of.

are you wanting your queue to be persistent? for instance across
reboots?

-a


#6

Thanks for the reference Jeff. Spread looks good, but I did not notice
any reference to ruby bindings for spread. Do you have a direct link?

Thanks,
Mark


#7

On Thu, 29 Dec 2005, Mark Watson wrote:

I used to use both a Linda-like systems and JavaSpaces, so I am
familiar with David Gelernter’s ideas.

I will give rinda a try when time permits.

please share when you do!

kind regards.

-a


#8

I used to use both a Linda-like systems and JavaSpaces, so I am
familiar with David Gelernter’s ideas.

I will give rinda a try when time permits.

Thanks,
Mark


#9

I have always used mail servers to do this in the past. I find the
actionmailer class in the rails package to be pretty handy for my
messaging purposes. The mail server handles queueing, guaranteed
delivery and basic security all the app has to do is send/receive and
log bounces. There are a number of other advantages with SMTP also,
like the ability to penetrate restrictive firewalls and backup MX
records for additional reliability. I’d say you could break from the
norm and come up with a messaging package build on top of Net::SMTP.

-Jeff


#10

Or you can try:
http://rubyforge.org/projects/reliable-msg/

Lightweight reliable messaging in Ruby, support for disk and database
store (right now MySQL, but I’m moving the code to use ActiveRecords),
message selectors, priority queues, delivery semantics, transactions.

assaf


#11

Mark W. wrote:

I have relied on guarenteed delivery asynchronous messaging to build
large scale systems for 20 years. I was surprised when I could not find
something simular to Java’s JMS for Ruby so I decided to build my own
and release the server under a GPL license and the client libraries
under a LGPL license. When I have code to release it will be in the
usual place (www.markwatson.com/opensource).

Any particular reason not to host it at RubyForge.org, with a gem
release?

James

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools


#12

Thanks Assaf.

As per my email to you, I am going to use your project, and not
implement my ideas. Thanks for saving me much time! I think that I will
also use your library in an example in my new book.

-Mark


#13

Jeffrey M. wrote:

I have always used mail servers to do this in the past.

The point of a message system is to ensure that:

  1. Messages are delivered only once.
  2. Messages can be sent without reliance on packet-based systems;
    specificially, without reliance on TCP/IP.
  3. Message delivery is reliable.
  4. Messages can be delivered using multiple channels in parallel.
  5. Messages can be broadcast correctly.

In general, none of those is true for an SMTP mail server, and 2, 4 and
5 are going to be very difficult to implement on top of SMTP unless you
also define which SMTP MTAs may be used.

I’d also question the original assumption that security isn’t an issue.
If you use SMTP as your transport, security is definitely going to be an
issue.

To put it another way: Sure, I’ve used SMTP instead of a real message
system. But if I wanted to build a real message system, I wouldn’t start
off with SMTP…

mathew