Web services are revolutionizing the Internet by enabling applications to speak a common language: XML. While Web services technology enables the execution of remote functions, it does not provide a robust infrastructure for handling information.
As the solution of this problem this article describes the concepts of web services with messaging.
Web Services
Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes.
How it differs from web application
Where the current web enables users to connect to applications, the web services architecture enables applications to connect to other applications. A web service is therefore a key technology in enabling business models to move from B2C (Business to Consumer) to B2B (Business to Business).
Web Services provide companies with a standards-based technology to simply integrate applications, share information with partners, and provide access to enterprise systems through a variety of devices.
Where is the problem?
An enterprise-class application that communicates with Web services must ensure that the data can be handled appropriately.
When employing Web services, one must ask questions like: Can our application scale to increased messaging demands? If our application crashes, is the Web service's data lost? How do we connect our Web-services-facing applications to back-end systems? These problems are created but unfortunately not solved through the Web services architecture. Web services must be combined with additional technology called Messaging for robust enterprise messaging.
Messaging Concept
Messaging provides high-speed, asynchronous, program-to-program communication with guaranteed delivery.
A simple way to understand what messaging does is to consider voice mail (as well as answering machines) for phone calls. Before voice mail, when someone called, if the receiver could not answer, the caller hung up and had to call back later to see if the receiver would answer at that time. With voice mail, when the receiver does not answer, the caller can leave him a message; later the receiver (at his convenience) can listen to the messages queued in his mailbox. Voice mail enables the caller to leave a message now so that the receiver can listen to it later, which is often a lot easier than trying to get the caller and the receiver on the phone at the same time. Voice mail bundles (at least part of) a phone call into a message and queues it for later; this is essentially how messaging works.
In enterprise computing, messaging makes communication between processes reliable, even when the processes and the connection between them are not so reliable.
There are two main defacto messaging standards for enterprise computing:
1. The Java 2 Platform, Enterprise Edition (J2EE) includes the Java Message Service API (JMS).
2. The Microsoft .NET Framework SDK (.NET) includes the System. Messaging namespace for accessing MicroSoft Message Queue (MSMQ).
JMS
At its simplest level, JMS is java based messaging that sends messages between servers and clients. The format of these messages is quite flexible and can include ordinary text messages (including raw text, SOAP, and XML), entire Java objects, and "empty" messages that are suitable for basic communication (like acknowledgments).
What's different about JMS compared with, say, low-level TCP/IP packets and Java Remote Method Invocation (RMI) is that while the other methods normally require real-time connectivity and messages that are sent synchronously, JMS systems are more flexible. In asynchronous mode, which is the default mode for JMS, clients don't have to be connected all the 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 the queue, the first on queue having the 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 the MQIS (Message Queue Information Store) and replicated throughout the Enterprise. Any computer on the Enterprise can hence locate them.
Private queues: These are queues that are not published in the MQIS and can only be accessed by systems that have access to the full path name or format name of the 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 the application to find and communicate with remote systems, but does not implement data reliability, salability. The addition of Messaging creates a second generation for architecting Web services systems, as shown in following Figure.

The inclusion of messaging servers decouples the application from the tasks of handling messages and web service clients. Applications communicate through an adapter to the messaging server.
In this new architecture, hybrid Messaging and Web services clients handle the bulk of the messaging duties. Information is passed through the Messaging server, which natively handles issues like fail over, load balancing, and guaranteed message delivery. By decoupling the Web services client from the application, several applications can effortlessly reuse a single Web services client. Decoupling makes it a simpler process to upgrade the Web service as inevitable software changes occur. Additionally, an application that becomes busy will have its Web services data automatically queued in the Messaging server until it is able to process the messages.
Conclusion
This decoupled architecture of Messaging and Web service clients is obviously more complex than an application that makes the Web service call directly. However, as the number of applications and Web services grow, the importance of the loosely coupled architecture becomes more evident. Messaging forms the backbone of many integration projects for good reason: it simplifies and enhances the 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.
Related Articles
- Web Services InteroperabilityInteroperability is one of the main promises of Web services. Web services are designed to be independent of the underlying operating system and programming language.
In this article we will address some basic web services interoperability issues that are useful for developers. We will focus on... - Should Your Join a Social Networking Website or Not?Social networking is defined as the grouping of individuals together into to specific groups, often like a small community or a neighborhood...
- Branding in BusinessBranding can bring more money to your business than SEO. See you can brand your site inexpensively and efficiently.
- See the Destruction of Email Messaging from the Comfort of Your Home!!!Spam and other commercial messages are throttling emails simple appeal. And no-one is offering a credible remedy.
- Ecommerce Basics: Three Things To AvoidWhen you decide to put your ecommerce website together there are a few mistakes that are easy to make, yet easy to avoid.
- The Top 15 Essential Ingredients Of Every WINDOWS HOSTING Plan (Package)First things First. Why would you like to have Windows Based Hosting when there are Linux packages for cheaper rates ? The answer is - it depends on what application you are looking to use for your hosting. Consider the tools and scripting languages you plan to use - if you use PHP, Perl or MySQL, L...
- 7 Inexpensive Ways To Generate Traffic!!Inexpensive Ways To Generate Traffic!
- Sticky And Viral Site MarketingNothing markets a site better, spreading it like wildfire, than having a viral product, tools or processes. And nothing makes it more capable of generating revenues than being sticky, because people only part with their money after they are comfortable with a product, after they
- What do People Want Online?Its not what you think it is. What people want online is a question guerrillas ask themselves a lot. Whether its for fun or work or something else, understanding a c...
- The Top Seven Strategies for Website SuccessWhether youre concerned with business-to-business, or business to consumer, whether your organization is large or small, commercial or nonprofit, these are some fundamental questions a...
