But what about speed? Isn't it faster just to open up a TCP socket on another machine and let my applications exchange information that way? Or maybe using a named pipe, or some other communication method? Well, in a narrow view of things, yes that is faster. But why should you as an application developer worry about these low-level issues when you should be worrying about how to solve your business problems.Even for the case of message delivery speed, if you are in a connected environment that supports these connected communication methods, then express delivery of message queue messages gives nearly similar performance. But what happens if the system is not connected using a high-speed, inexpensive link?
If your application is relying on communication protocols that require a permanent connection, then in order for that application to work, the connection has to be in place. This means having your system connected to the network at all times, via LAN or by phone, or by some other means. Even these types of connections are not always reliable. Communication protocols such as TCP require a reliable communication link, and writing code to handle breaks in the network can become very complex. Another problem with these types of links is that they can become rather expensive. When the means of connection is not inexpensive, this method of communication ceases to be an effective means of distributing an application. If the application supports queuing, then all that needs to happen during a connected state is an exchange of messages. All of the other work can take place off-line, when connect charges are not being incurred.