What's different about JMS compared with, say, low-level TCP/IP packets and Java Remote Method Invocation (RMI) is that while other methods normally require real-time connectivity and messages that are sent synchronously, JMS systems are more flexible. In asynchronous mode, which is default mode for JMS, clients don't have to be connected all time.

MSMQ MSMQ is Microsoft’s implementation of Messaging. It supports both Point-to-Point and Publisher-Subscriber models for messaging. Messages are typically kept in queues that are managed by Queue managers and applications access MSMQ via a simple client API.

Messages can be prioritized and delivered depending on their position in queue, first on queue having highest priority. Queues can be implemented both in memory as well as on secondary storage such as disk. While express messages are stored in memory, recoverable messages are stored on disk.

There are two types of queues in MSMQ.

Public queues: These are queues published in MQIS (Message Queue Information Store) and replicated throughout Enterprise. Any computer on Enterprise can hence locate them.

Private queues: These are queues that are not published in MQIS and can only be

accessed by systems that have access to full path name or format name of queue.

Combining Messaging with Web Services A first-generation Web-services-enabled application contains or directly interfaces with a client that communicates with Web services as following image shows

This architecture enables application to find and communicate with remote systems, but does not implement data reliability, scalability. The addition of Messaging creates a second generation for architecting Web services systems, as shown in following Figure.

The inclusion of messaging servers decouples application from tasks of handling messages and web service clients. Applications communicate through an adapter to messaging server.

In this new architecture, hybrid Messaging and Web services clients handle bulk of messaging duties. Information is passed through Messaging server, which natively handles issues like fail over, load balancing, and guaranteed message delivery. By decoupling Web services client from application, several applications can effortlessly reuse a single Web services client. Decoupling makes it a simpler process to upgrade Web service as inevitable software changes occur. Additionally, an application that becomes busy will have its Web services data automatically queued in Messaging server until it is able to process messages.

Conclusion This decoupled architecture of Messaging and Web service clients is obviously more complex than an application that makes Web service call directly. However, as number of applications and Web services grow, importance of loosely coupled architecture becomes more evident. Messaging forms backbone of many integration projects for good reason: it simplifies and enhances handling of data. Since Web services are simply another way to integrate information and functionality, it makes sense that Messaging should also be a part of it.

See Also: Coding Tips for Messaging

Related Article: Web Services Interoperability

I'm sure fact that my "presence" on-line is now much more professional I will get even more clients on a regular basis because they can contact me easily and my competition might take 3 days to get back to them.

Will it work for your site? Probably, if your selling anything it's nice to be able to talk with folks who are your customers. It leads to more referrals and additional work. If your not putting customer service at top of your priorities your missing out on best part of being a webmaster. Security.