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.
note: a_listener object must be able to respond to the message:
receive_message(message)
5. sent messages are persisted using a database or a flat file and must
be serializable
6. once a message is delivered to all registered listeners for a queue
the message is deleted from persistent store
7. 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.
On 12/28/05, Mark Watson <mark.watson@gmail.com> 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).
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.
note: a_listener object must be able to respond to the message:
receive_message(message)
5. sent messages are persisted using a database or a flat file and must
be serializable
6. once a message is delivered to all registered listeners for a queue
the message is deleted from persistent store
7. 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 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?
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
···
On Thu, Dec 29, 2005 at 04:32:54AM +0900, Mark Watson 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).
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.
note: a_listener object must be able to respond to the message:
receive_message(message)
5. sent messages are persisted using a database or a flat file and must
be serializable
6. once a message is delivered to all registered listeners for a queue
the message is deleted from persistent store
7. 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.
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.
On 12/28/05, Mark Watson <mark.watson@gmail.com> 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).
>
> 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)
>
> 5. sent messages are persisted using a database or a flat file and must
> be serializable
>
> 6. once a message is delivered to all registered listeners for a queue
> the message is deleted from persistent store
>
> 7. 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
>
>
>
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.
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
···
--
<URL:http://www.pobox.com/~meta/>
My parents went to the lost kingdom of Hyrule
and all I got was this lousy triforce.
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
···
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.
--
ara [dot] t [dot] howard [at] noaa [dot] gov
all happiness comes from the desire for others to be happy. all misery
comes from the desire for oneself to be happy.
-- bodhicaryavatara
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.
--
ara [dot] t [dot] howard [at] noaa [dot] gov
all happiness comes from the desire for others to be happy. all misery
comes from the desire for oneself to be happy.
-- bodhicaryavatara