Web Service
Messaging
by Senthil Krishnamurthy from Aspire Systems (India) Pvt.
Ltd.
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, 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 functionality, it makes sense that
Messaging should also be a part of it.
Contact me at [email protected]
See Also:
Coding Tips
for Messaging
Related Article:
Web Services
Interoperability