Feature Article

Web Service Messaging

April 20, 2005

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 is differ 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, 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 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 functionalityPsychology Articles, it makes sense that Messaging should also be a part of it.

See Also: Coding Tips for Messaging

Related Article: Web Services Interoperability

Source: Free Articles from ArticlesFactory.com

ABOUT THE AUTHOR


K.Senthil B.E., is working in Aspire Systems (India) Pvt. Ltd.