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 could 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 businesses with a standards-based technology to simply integrate applications, share data 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 could be handled appropriately.

When employing Web services, one must inquire of questions like: Can our application scale to increased messaging demands? If our application crashes, is the Web services data lost? How do we connect our Web-services-facing applications to back-finish 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, code -to-script communication with guaranteed delivery.



A simple way to understand what messaging does is to think about 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 measure . With voice mail, when the receiver does not answer, the caller can leave him a message; later the receiver (at his convenience) may 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 fairly often a lot easier than trying to get the caller and the receiver on the phone at the identical instant. Voice mail bundles (at least part of) a phone call into a communication 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 might add ordinary text messages (including raw text, SOAP, and XML), entire Java objects, and "empty" messages that are suitable for basic communication (like acknowledgments).



Whats 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-measure connectivity and messages that are sent synchronously, JMS systems are more flexible. In asynchronous mode, which is the default mode for JMS, clients dont have to be connected all the time.



MSMQ
MSMQ is Microsofts 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 may be prioritized and delivered depending on their position in the queue, the first on queue having the highest priority. Queues might 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 might 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 road title 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