Auto And Trucks 1946Business And Finance 11381Cellular Phones 10Collectibles 10College Articles 455Computers And Internet 4892Education 839Environment 825Family 3852Food And Drink 1559Gadgets And Gizmos 924Gardening 68Gifts And Gift Baskets 18Government 806Health 5196Hobbies 959Home Improvement 2196Humor 203Kids And Teens 804Legal 1609Marketing 6217Men 338Music And Entertainment 779Online Business 4940Parenting 1369Pets And Animals 951Recreation And Sports 2236Relationships 684Religion 694Self Improvement And Motivation 7987Site Promotion 1526Sports And Recreation 217Travel And Leisure 2668Web Development 3317Women 2242Writing 2437
Web Service Messaging
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
![]()
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