ChatterBox

Using Twitter as a Collaboration Message Queue

As the web moved more towards mash-ups and other forms of heterogenous applications, there is a need to reliably send messages between these applications leveraging a common interface. While there are services out there that provide Internet-based message queuing, like OnlineMQ, cloudMQ, Amazon Simple Queue Service and others, I think another mechanism is staring us in the face. In looking at Twitter and how tweets are distributed and queued, in essence this really could be a Collaboration Message Queue. Twitter is mainly focused on human interactions. Could it be used as a platform for non-human collaboration?

Wikipedia defines a message queue as follows:

“… a message queue is a software-engineering component used for interprocess communication or inter-thread communication within the same process. It uses a queue for messaging – the passing of control or of content. Message queues provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.”

Twitter definitely provided the component necessary to use it as a message queue:

• RESTful API
• Ability to send short messages
• Messages can be broadcast to all listeners
• Messages can be replied to or directed to specific listeners
• Messages are queued until picked-up by the listener
• (Very) limited security in that updates can be kept private to only specifically approved listeners
• Ability to search messages (may or may not matter)

“Listeners” above would normally be referred to as “followers” for human collaboration.

So, what would a Twitter-based Collaboration Message Queue look like:

Each application leverages the Twitter API to speak with Twitter. The sending application authenticates to Twitter and initiates a conversation. The conversation can be broadcast to all of the listeners, sent specifically to one listener using an @reply/mention or sent privately to one listener using a direct message. The receiving application also authenticates to Twitter and checks for messages in its queue. Those message can then be read off the queue. Since the order of the messages in maintained, asynchronous communication is possible. Since there are multiple services that integrate with Twitter for sending binary information (think TwitPic) those API’s could also be leveraged to send non-text based messages.

A use case for this might include using Twitter as a way to federate site communication. If, for example, you have an application that sits out at your customer site and want an easy way for your application to send and receive inter-application messages, the Twitter API provides an extremely easy mechanism of accomplishing this. In the example of a workflow-based application, perhaps you want to assign a task outside of your company to a partner also using the same software. The application could send the task into the receiving application’s Twitter queue. The receiving application could then acknowledge the receipt of the task with a response and easily communicate back when the task is completed. Since the application would use the same language, each site is able to establish a dialog with the other sites.

To implement this type of model, each participant application would do the following:

1. Register a Twitter handle
2. Mark their updates as private
3. Each new participant follows the initial participant
4. The initial participant accepts the follow and follows the requesting participant back

The participants can now send messages into each other using the mechanisms called out above. Additionally, all participants will see broadcasts across the system. Using re-tweets, conversations happening between specific participants could be forwarded on to other participants allowing certain participants to act as distribution hubs.

I am unsure as to the usefulness of this approach. While this allows non-humans to collaborate with little new code, message limits of 140 characters and the fact that conversation security is limited lessen the overall value. Messages longer than 140 characters could be broken down and chunked across multiple messages. Since order is maintained, the listener could put the message pieces back together relatively simply.

I’m fairly sure that Twitter will mainly be a human collaboration platform, but if they’re looking to find some other ways to leverage their infrastructure, you never know. Maybe non-human social networks are the future.

As always, I would love to hear your feedback.

Todd

Posted by: Todd Clayton  |  April 18, 2009  |  categories: Social Media  |  tags: Development, Social Media, Twitter