Skip to content

Core Messaging Service

Jump to bottom
nunonunes edited this page Sep 26, 2010 · 5 revisions

On this section we describe the usage of the core messaging service and detail the software implementing it.

Basic description of the messaging component

To fill in.

Open issues

Message structure and semantics

The messages that the system will pass back and forth between parts of the system must all adhere to a standard structure with well-defined semanthics.

Most messages will, in one way or another, carry at least one (and usually more than one) of the basic attributes (I, U, A, L --see the main page for more on these attributes) of the item is refers to, so that should probably be a stantard part of the message structure.

I think the messages should be encoded in a human-readable manner and be simple to parse.

Here are some examples of namespaces and actual messages that could make up the messaging structure:

  • /item/* - This namespace is used by items of information that are collected by the system as something that the user received via one of her incoming streams. Example messages on this namespace would look like:

    • /item/new/rss/<item_id>
    • /item/new/mail/<item_id>
    • /item/change/<item_id>/<new_IU_rating>

  • /user/* - This is the namespace that will be used to track messages regarding the system's users. Some examples of potencial messages in this namespace would be:

    • /user/<user_id>/important/<item_id> - User user_id marked item item_id as being important
    • /user/<user_id>/unimportant/<item_id>
    • /user/<user_id>/availability/<new_availability_rating>

Software choice

0MQ

0MQ is a messaging mechanism that seems like a pretty good base for our design. It is extremely simple to use, it is higly efficient, fast and has bindings for a great many programming languages.

It has it's drawbacks, of course, not the least of one being lack of persistence of the messages. It is a brokerless solution.

One way we could introduce a boker into the mix (if we decide we really need it), would be to, for exemple, use a RabbitMQ broker into the mix, since it has support for 0MQ messaging (as an add-on / built-in?).

Other possibilities

These other systems are under consideration, please add whatever you think is relevant about each one here.

  • SapoBroker - I've used it and like it. It is written in Java (I'm not sure anything else in the echosystem will be, so we'd need to have java support just for this one system) and it had (a long time ago) ;-) bindings for a few languages;

  • OpenAMQ - Since the main guys behind it (iMatix) are abandoning it soon, I don't think this will turn out to be a good alternative for us. Thoughts?

  • Redis - This is a swiss army-like data store which, among other things, implements a messaging system. Might be good to look at this, especially since it is also under consideration for the Core Data Store system.

Clone this wiki locally