Messaging Systems

Inter-application communication has evolved over the years from proprietary protocols and fixed message formats to message queues and web services based systems using XML.

But it isn't unusual to see an application communicate via mechanisms more usually associated with real-world messaging between real people. eMail, for example, can be used to convey messages from one system to another although eMail isn't necessarily a great way of guaranteeing delivery of any message in my experience!

Bringing us right up-to-date is Twitter. Although Twitter is a way of communicating using short-based messages only (as it is limited to a mere 140 characters), it does have a good record of being almost always available. Sending a short-based message from one system to another could utilise the power of Twitter quite easily, surely?

Consider the following usage pattern...

An offsite managed service is being provided by a third party with support hours of 08:00 - 18:00. Overnight batch processes are to be checked each morning by the service provider. The service provider, however, introduces monitoring of systems which trigger exception alerts via Twitter for off-site pick-up via any amount of Twitter clients on any number of devices. Think about the following message:

2010-04-07 22:50:05 FATAL: Batch Feeder [BACS: Invalid Trailer Record]

Instead of waiting for support staff to analyse logs the following morning, they have a head start telling them exactly where to look.

Of course, we could just have the monitoring service raise a ticket or send an email or send SMS alerts. The point is not to show that Twitter is better than any of these delivery mechanisms but to show that Twitter is an alternative. (After all, it could be that we have a Twitter listener which queries these messages and raises the necessary problem records in the service desk.)

The point is the ultimate delivery mechanism of the message to the client isn't the responsibility of the message generating application. The application doesn't care if the message is to be viewed by a custom-built message reader on an iPhone, Tweetdeck on a PC or a shell script sending curl requests at twitter.com!

I'm sure my avid readers can come up with many more sophisticated use cases for the integration of Twitter into the enterprise.

NOTE: Any such inter-application communication using Twitter should ensure that the tweets are protected. There's no point in having "randoms" looking at your tweets, after all.