About

SAFMQ Provides Asynchronous Assured Delivery Messaging

The SAFMQ server provides Asynchronous Messaging.  Message Publishers send or enqueue a message with the SAFMQ server.  The SAFMQ server stores that message until the point at which the message can be forwarded on to the client.  Message Publishers are assured that the messages are delivered.  That's how SAFMQ got it's name.

Timely Messaging

SAFMQ provides the ability to perform timely message delivery.  So, if a Message Publisher wants a message to be read by a Message Subscriber in a certain amount of time, or not read at all, then the Message Publisher can prescribe a Time-To-Live for the message it publishes.  SAFMQ will notify the Message Publisher about messages which have outlived their Time-To-Live, or a Message Publisher can choose to ignore the event.

Round-Trip, PsudoSynchronous Messaging

Round-Trip, or PsudoSynchronous Messaging is when a Message Publisher acts as a Message Subscriber after sending a "query" message.  A Message Publisher may want to receive information back from the Message Subscriber.  Thus after the first message is sent by a Message Publisher and is received by a Message Subscriber, the original Message Publisher and Message Subscriber switch rolls.

SAFMQ provides a special messaging context element for Round-Trip/PsudoSynchronous Messaging.  It's called a Receipt ID.  When ever a message is Enqueued in a SAFMQ server, it is given a Universally Unique Identifier or UUID for short.  When a Round-Trip message event is taking place, the original Message Subscriber publishes a message with a Recipt ID identiacal to the Message ID assigned to the message sent by the original Message Publisher.  Then the original Message Publisher (now a subscriber) waits for a message with a Receipt ID equal to the Message ID the original Message Publisher sent.

Batch Processing

Not every task is best handled real-time.  Sometime there are real money benefits to send transactions to a trading partner in a large group or batch.  SAFMQ can be an intermediary between real-time systems and a back-end batch processor.  The real-time system knows that the messages will be delivered, and the batch processor can let data queue up until it is ready to send all the data.  The batch system can even respond via SAFMQ and a real-time system can instantly see the results.

Special Thanks

Special Thanks go out to the all those who have helped out bring SAFMQ to where it is today:

• Drew Rash -- For his efforts developing a PHP interface
• Mike Liedy -- For his general knowledge of deploying projects in UNIX environments and systems administration help
• Nicolas de Bari Embriz Garcia Rojas -- For providing access to FreeBSD systems

Thanks guys!

-Matt