Most people who have spent some time with me, are convinced that I am musically stuck in the eighties: The Cure, Siouxsie and the Banshees, The Sisters of Mercy and all those happy-sounding bands. But don't let the title of this post lead you to believe I'm talking about The Police. No, I'm talking about enterprise integration in the form of message queues.
In my last post, I talked about how interesting it would be if we could combine the easy-to-master power of cross-platform desktop software development tool Revolution with the heavy-weight champion in cross-platform development: Java. Well, the first way we can make these two technologies work together and play into one another's strengths, is by means of message queues.
Back in the old days, most application integration consisted of exchanging files: application A exported data into a file, and then application B would import the data from that file, usually at the click of two buttons. Convenient, even if you had to copy them to and from floppy disks. In the multi-user time-sharing Unix world, pipes have traditionally played an important role in data exchange, as one application connected its output pipe to the other application's input pipe and vice versa, and just wrote data to one another.
And of course, in the golden age of internetworked computers, you're bound to have enjoyed the miracles of TCP/IP and other networking protocols, as you surfed the web, exchanged instant messages and legally downloaded the occasional file. All thanks to the wonderful world of sockets that connected an application on your computer with an application running on another computer somewhere out there.
Sockets are also often used to let two applications talk to one another while running on the same computer - does the word 'localhost' ring a bell? The common theme in this type of information interchange is that both sides agree on the data format and talk to one another directly in one form or another. Now while that's pretty easy to put together as long as the two parties can come to an agreement, it gets complicated as you have to talk to more and more applications.
Think about it: if two apps talk to one another, you have one connection to develop; when a third app joins the party, two extra connections need to be made; a fourth app means adding three more to the mix. The mathematical formula is n x (n - 1) connections to interconnect n applications. And that's not such a strange scenario: nowadays, our applications can't sit there in their ivory towers - our users expect them to talk to one another seamlessly.
So, would you like to write an ever increasing number of connectors? Or would you prefer an approach that takes care of the plumbing? Enter message queues: think of them like a mass-mailing system for applications - you post a message to the queue and it will make sure that your message reaches all the applications that have declared their interest in receiving all or just certain types of messages. In this method, all you have to agree on is the message format and where it will be posted.
I'm sure you'll agree nothing is easier than speaking the same language and delegating the actual delivery of messages? Add to this the promise of delivering your messages to the applications that are hooked into the system - in order and exactly once! That's certainly a much better deal than people losing the USB-stick, deleting the email or forgetting to import those data exchange files, right? And how about this: when you change the data in one client application, you broadcast it via the message queue and all other clients pick up the message and refresh accordingly? Sounds good to me...
But enough theory, how can we do this in practice? The good news is that most Message Queue vendors have signed on to the Java Messaging System standard: JMS. Even better news is that in these days of open-source software development, we can pick up a solid implementation for free: Apache ActiveMQ - yes, from the makers of the server that's running most of the worldwide web. And the best news (not just for Revolution developers), is the STOMP project: a combination of a bridge and a standard protocol, which allows any socket-wielding application to talk to just about all JMS-enabled Message Queues.
You guessed it: the first way of combining Java and Revolution is using sockets to talk to a JMS-enabled Message Queue. Armed with the STOMP-specs and earlier experiments with socket communication, I put together a STOMP library in a few hours yesterday morning. Now don't rush over to the quartam.com website just yet, as it needs more testing and tweaking before it's ready for general use. But I can tell you that sending and receiving messages works like a treat. Yet another reason to add Revolution to your developer toolbox if you haven't done so already.
So where does the bottle come into this story? Well, I happily drank the rest of the bottle of dry white wine that I opened yesterday evening, while typing this post. Or maybe I was just trying to lure you in with the title of one of the most famous songs by The Police. Then again, wouldn't it be nice if all the messages we carefully wrote as a child at the beach, shoved in a coke bottle and threw into the sea, actually made it to their destinations?
No comments:
Post a Comment