The customer I've been working with has a general concern I haven't run into in a while: They don't trust messaging.
The issues for why they don't trust messaging are varied, but ones I've heard before from other customers (and reviewers of EIP): Is messaging reliable? Is messaging slow? How do I know the receiver got the message? What format should my messages be? Should messages be text so that I can read them? (You may find it helpful to review Basic Messaging Terminology.)
It's funny how messaging seems to be held to a higher standard than other parts of the app. Take reliability: Messaging systems (good ones, anyway) are highly reliable, because of the way they use transactions and persistence to make sure data doesn't get lost. Messaging systems are more reliable than most of the apps that use them--how certain are you that your app can't possibly lose or corrupt data?--so worrying about the messaging system is probably focusing on the wrong place.
Another issue with reliability is: What if a message gets stuck? What if one app has asked another to perform a task, but it's not getting performed, how will the first app know? Well, how can this happen? Either the message can't get transmitted because of network problems, or the receiver is not consuming messages properly. In either case, remote procedure invocation wouldn't work any better. But at least the caller would know that RPC wasn't working, because it would get an error (like RemoteException), at which point the app would intelligently and reliably handle the error ... how? In any event, that's supposedly better than not knowing whether or not the message is stuck in a queue somewhere.
So what should an app do if its message gets stuck? Part of the send and forget (aka fire-and-forget!), asynchronous, time-independent paradigm of messaging is that you shouldn't really care where the message is or if it's stuck in a queue; that's the messaging system's problem, not the app's. Nevertheless, you hope your company's enterprise systems are running properly, not getting messages stuck in queues. So this is a monitoring issue. Your monitoring software, probably SNMP-based, should be monitoring your queues, looking for problems. How will it know when there's a problem? It should monitor queue depth, indicating that the receivers are not running or are not processing messages fast enough. It should also monitor message age, indicating that messages are sitting on the queues too long and are not getting processed quickly enough. What should the monitoring software do when it detects these problems? Whatever monitoring software does: Restart the systems and/or alert the sys admin.
Take performance: Messaging is generally about as fast as your network, and perhaps the applications doing the work; the messaging system doesn't add that much overhead. If your messages are slow, that's because of network problems, in which case remote procedure invocation would be just as slow or not work at all. The issue isn't so much how quickly a message gets from the sender to the receiver, because messaging is asynchronous, and therefore the apps aren't supposed to be highly time-sensitive. The issue is throughput: How quickly can the sender produce messages, and more importantly, how quickly can the receiver process messages? Throughput is far more dependent on the efficiency of the senders and receivers than on the messaging system, since they're not just putting and getting messages in a tight loop. Messaging, being asynchronous, actually helps throughput because it lets the senders and receivers run at different speeds, and queues up the requests for the receivers to process at their maximum sustainable rate.
Take format: I've already discussed Serialization: Binary or XML?, so the conclusion there is that Java-to-Java messaging might as well use (binary) serialized objects. Keep in mind that as long as the senders and receivers agree on the message format, the message can be in Swahili for all the messaging system cares. There are a few exceptions: If the messaging system is using any transformers, those care very deeply about format, and in fact are quite useful when the sender and receiver don't agree on format. A content-based router which keys off of data in the message body cares about message format so that it can parse the message, but it's much better for content-based routers to key off of header values, specifically so that the router doesn't have to parse the body and therefore doesn't have to know the body's format. Other than transformers and not-so-well-designed routers, the messaging system doesn't care about the message body's format, that's just payload, no more than an IP packet cares about what's in the packet.
Which brings us to human-readable formats: Shouldn't the message format be XML or some other text so that people can read it? I don't know; why do people want to read messages? People seem to have no problem with remote procedure invocation, which in Java usually (RMI, CORBA, remote EJB, etc.) runs as IIOP containing serialized Java objects. If serialized objects are good enough for IIOP, why aren't they good enough for messaging? If no one cares about IIOP data format, then why all the hand-wringing about messaging data format? I blame those darn queue browsers (like MQ Explorer). Most developers are not going to set up a packet sniffer to watch their IIOP packets flow, but they will use a queue browser since it and the messages are right there in front of them. Generally, messaging systems only care about what's in the message header, and that's all the programmers should care about; the body can be in Swahili and that shouldn't hurt the programmers a bit.
So why is messaging held to a higher standard? I think it's an issue of control: Developers control the code they write, so somehow they trust it more than the code in some messaging system. While an app is performing an RPC, it's in control of the call (not really, but the app feels like it is); with messaging's fire-and-forget, the app looses control of the message and has to rely on the messaging system to do its job. With messaging, app developers feel like they have less control. Actually, this gets back to basic human psychology, like I discussed from Freakonomics: People fear what they don't know or can't control.
Yet developers trust databases. They trust web servers. They trust virtual machines. It's time to start trusting messaging systems as well.
JMS: Can Messaging Be Trusted?