News Stay informed about the latest enterprise technology news and product updates.

A Messaging Primer: How Messaging Solves Today's Business Problems

This paper outlines messaging middleware. It is a high-level discussion that describes how these technologies work, and it talks about the various types of business problems that are being solved today using messaging. This whitepaper discusses the various types of messaging implementations, along with the advantages over RPC-based mechanisms.

A Messaging Primer: How Messaging Solves Today's Business Problems


Businesses are constantly searching for ways to improve efficiency and, therefore, their bottom line. The global availability provided by the Internet, and the constant advances in technology, offer more and more choices when deploying business-critical systems.

Those charged with making such technology decisions need to understand the business factors involved in making infrastructure decisions. This paper outlines one of those infrastructures - messaging middleware. It is a high-level discussion that describes how these technologies work, and it talks about the various types of business problems that are being solved today using messaging. This whitepaper discusses the various types of messaging implementations, along with the advantages over RPC-based mechanisms.

When selecting a messaging implementation, you must evaluate several criteria in order to determine product suitability. This whitepaper alerts the decision maker to these key areas of concerns.

What is messaging?

At its core, messaging middleware is software that allows two entities to communicate by sending and receiving messages. In the same way that today's e-mail systems allow communication between two or more people, messaging allows communication among two or more applications, without requiring human intervention. These applications can reside independently on a wide variety of hardware devices.

One of the most fundamental aspects of messaging is its asynchronous nature - the sender of the message does not have to wait for the recipient to receive the information. Going back to the e-mail analogy, once an e-mail has been sent, the sender does not wait for a reply - they are free to continue working while waiting for the recipient to respond. Sending applications are free to generate messages at an appropriate speed, handling peak periods as they occur, without having to wait for recipients to deal with the requests. There are instances, however, where synchronous communication is required (for example, awaiting the result of a complex mathematical calculation before making a decision). In these instances, it is essential that the messaging implementation that you choose can handle this type of communication, as well as the asynchronous form.

Messaging is being widely using today in support of business-to-business (B2B) and business-to-consumer (B2C) transactions, often occurring over the Internet.

What problems does messaging solve?

Messaging technologies have been with us since the 1970s when they were used primarily to facilitate communication among back-office mainframe applications running on dedicated network connections. The messaging paradigm has become popular again due to changing business practices and technological advances such as the widespread acceptance of the Internet (due to its low cost and geographic accessibility), and the proliferation of mobile networked devices such as laptop PCs, handheld digital assistants, and other web-enabled input devices.

Disparate system integration

In the business world, mergers and acquisitions take place every day. More often than not, the merging organizations each have different internal systems that reflect their different business practices. To force one organization to change its internal systems in order to work with the application on the other side is a costly and sometimes disastrous endeavor. Decision makers often find that allowing these applications to coexist and communicate without disrupting everyday business processes is fundamental to ensuring a successful merger. Integration among applications is often required within an enterprise as well. Off-the-shelf applications are preferable to custom-built solutions in most enterprises. The wide variety of applications contributes to the disparity that large organizations face as they try to deal with a many heterogeneous applications and platforms. A low-cost, easy-to-implement, and flexible solution is required. Messaging technologies are often used, as they require little or no change to the underlying applications in order to guarantee communication among them. This decoupling of applications allows the different business units to keep operating through the merger.

Exchanging information with business partners

Successfully conducting business requires collaboration with a variety of business partners, both on the supply side and on the distribution side. All parties constantly exchange information, but not always reliably:

  • Price promotions are sent via faxes that are easily lost.
  • A phone call is made to check on accounts payable, but the caller can't reach the right party
  • E-mail is used to place orders, but the numbers are transcribed incorrectly into the purchase order.

You can use messaging technology to coordinate these communications and guarantee that the correct information is transmitted and received. The quality of service levels available with today's messaging systems ensure that the right information is exchanged among the appropriate parties, and that the appropriate security measures are in place.

Automating common business functions

Streamlining today's business practices offers a measure of efficiency that directly affects the bottom line of a company's performance. Where possible, companies are looking at technologies that automate common business tasks or transactions that traditionally have required costly and slow user interaction.

Challenges of building next generation applications

Portals and E-Marketplaces

There is no doubt that the Internet has significantly changed the way organizations do business. By removing geographic boundaries, the Internet has allowed businesses to exchange information and conduct transactions without requiring face-to-face interaction. Other technologies, such as XML, allow businesses to communicate in a standard way, giving them access to a wider range of potential business partners. These technologies, along with messaging, have given birth to the portal or e-marketplace concept. These portals allow organizations that are interested in doing business with like-minded companies to seek out and conduct business with each other. By joining an e-marketplace, companies can conduct business with all other organizations on that portal.

Messaging systems are fundamental in e-marketplaces. They ensure that information in the form of messages are sent reliably to a potentially massive number of recipients, while still providing a very high level of throughput and providing robust security.

Global business transactions

In today's global economy, organizations are thinking and deploying globally. Doing business in a geographically dispersed fashion presents its own sets of problems. How will the systems communicate? How can you keep costs down? How can you administer remote locations? The messaging model caters to geographically disperse locations.

What types of messaging implementations are there?

Messaging middleware products vary in their implementations. The two most common implementations are described below. Each has benefits, and it is up to the implementor to determine which best suits the needs of the organization.

Hub-and-spoke architectures

In a hub-and-spoke architecture, all applications are connected to a central process, called a message server. The message server handles all communication among the connected applications, called the application client. The message server is responsible for routing messages correctly, authenticating and authorizing user access, and guaranteeing the delivery of the message. Each application client can either be a sender of messages, a recipient, or both.

Benefits to using a hub-and-spoke architecture include:

  • Reduced number of network connections: Each application client only needs to connect to a message server in order to send information to all other clients.
  • Flexible client deployment: As the message server handles all routing, senders and receivers are unaware of each other, so they can be moved around with minimal disruption to the system.
  • Minimal software requirements on the application client: Because most of the messaging logic is contained within the message server, smaller software components (or even no components) may be required in the application clients in order to establish connections.

Bus architectures

In a bus architecture, there is no centralized message server to coordinate the distribution of messages. Instead, each application client contains the functionality typically found in a message server (such as message persistence, transaction support, and security). All application clients are connected to a message bus, typically the network layer of the IP multicast protocol. This multicast network layer routes messages among each of the application clients, but the clients must perform all checks and balances to ensure that the message is delivered securely and reliably.

One major drawback to using multicast on a bus architecture is that administrators might not allow broadcast message traffic through their secure firewalls. Hence, if Internet deployments are important, avoid multicast and bus architectures in general.

What about RPC-based mechanisms?

Messaging is not the only way to communicate with other applications. Other technologies, such as CORBA, Java's RMI, and Microsoft's DCOM, all use a Remote Procedure Call (RPC) mechanism to transfer information among applications.

RPC-based mechanisms also cause sending applications to block, or wait for a task to complete, before continuing processing, forcing all processing to occur sequentially. The recipient of the information must complete its processing before the sending application can continue. In a loosely coupled asynchronous-based topology, however, after the message server has acknowledged a message sent to it, the sending application can continue processing, secure in the knowledge that the message server guarantees that the message is sent to its final destination reliably and securely.

What should I look for in a messaging implementation?

There are various criteria that decision makers must evaluate when choosing a messaging implementation. The following section outlines some of the more common areas of concern. Depending on the business problem, other criteria may emerge, but this guide provides a starting point for discussions with vendors.

Multiple domain support

There are two basic messaging models, or domains, that you can use when designing applications. A messaging product should be able to handle both domains, even though one domain may be more appropriate for a particular messaging implementation.

Publish-and-subscribe domain

In a publish-and-subscribe (or pub/sub) domain, a single sending application, or publisher, broadcasts a single message to several receiving applications, or subscribers.

Pub/sub messaging is useful when you want to broadcast the same information to a wide audience. Sample implementations include stock price tickers, notification of promotional offers, and requests for bids or proposals.

Point-to-point domain

In a point-to-point (P2P) domain, information is exchanged between a sending application, the sender, and one recipient, the receiver.

P2P messaging is useful when messages should be acted upon only once. Examples include stock trade placements, purchase order submissions, and airline reservations.

Guaranteed reliability

Business-critical systems demand reliable communication, and the Internet is far from a reliable communication channel. There is no point in transmitting information at lightning speed if there is no guarantee that the information will reach its intended destination. A messaging product must offer different levels of service to guarantee delivery of information. Is it critical that a message is received? In the case of a stock price update, the answer would be no, as another quote will be available soon after. When placing a stock trading order, however, the sender must be confident that their order has been received and will be processed.

Advanced security features

The Internet is infamous for its ability to compromise system security. There are daily reports of intentional maliciousness to businesses. As more and more business is conducted over the Internet, participants must be assured that information will be passed on only to those with the appropriate authority to receive the information. A messaging implementation must be able to handle the myriad of security controls and architectures that are required when dealing with the Internet. These controls include encryption technology such as SSL, authorization and authentication, and firewall technologies. Without support for these technologies, users run the risk of transmitting sensitive information over an insecure channel - a recipe for disaster.

Massive scalability

It is not enough that a messaging implementation offers support for multiple domains. It must also be highly scalable across all of those domains. Today's widespread acceptance of the Internet as an application-deployment platform makes it difficult, if not impossible, to reliably predict peak workloads and user connections. Administrators deploying messaging-based applications must be assured that that their messaging implementation can scale to thousands of users, while delivering throughput of hundreds of thousands of message transactions per day - all while showing no appreciable performance degradation.

Often, initial estimates for the size of a system are quickly outgrown when deploying systems to the Internet. Administrators need the capability to grow the system's topology to suit their needs with little disruption to the production environment, while maintaining ease of manageability. Message servers that are deployed in remote locations must be able to be administered by one person from a central site.

Standards-based implementation

The Java Message Service (JMS) specification, created by Sun Microsystems, defines how clients and servers communicate in an asynchronous messaging environment. It has been gaining wide acceptance in the messaging middleware market place. A messaging product that adheres to the latest standards in connectivity and application design is far easier to implement than one that requires specialized proprietary knowledge. A Java programmer can easily understand and write to a Java-based messaging interface. However, proprietary systems, such as IBM's MQSeries, require detailed programming knowledge specific to that product. Consequently, hiring programmers is often prohibitively expensive.

eXtensible Markup Language (XML) is rapidly becoming the common language for doing business over the Internet. XML allows you to use standardized formatting so that any application can understand information from other applications using XML. More and more application vendors are choosing to support XML, so a messaging implementation should be able to handle the XML-formatted information without requiring translation to some other format.

Implementing a standards-based architecture also allows easier integration with other systems and services, thus providing additional functionality to the messaging system.

Connectivity to other messaging systems

Industries rarely standardized on one technology implementation. Therefore, individual organizations that want to do business with others in their industry, and large organizations looking to integrate their systems, must be able to access information from a variety of sources. These sources may already be part of a messaging infrastructure, and reluctant to introduce another. In that case, the messaging implementation must be able to connect to these existing infrastructures, and to transfer information to and from them without disturbing the processes that are already in place.

Application server neutrality

Application servers are widely used to centralize application processing to machines that are more powerful. Some application servers have a messaging infrastructure that allows them to communicate with other applications in an asynchronous manner in an easy to use, embedded manner. However, using an embedded messaging solutions means that each messaging node requires the implementation of one application server. The processing overhead of an application server, along with the cost required to support and manage such an environment, far outweigh any benefits it may provide to a pure, non-embedded messaging implementation. A messaging implementation should be application server agnostic. That is, it should not rely on application server in order for the messaging infrastructure to work. However, a messaging implementation should be able to coexist within an application server architecture, where such a topology is required.

Global vendor support

In today's business world, the Internet means that your organization never sleeps. Customers and partners want to have access to your information around the globe and around the clock. Your messaging implementation should come from a vendor with experience in global customer support, so that assistance is readily available, whenever and wherever you need it.

How does the SonicMQ messaging implementation work?

SonicMQ, from Sonic Software Corporation, is a 100% Java, JMS-based messaging server. It provides support for both the publish-and-subscribe and point-to-point messaging domains through a hub-and-spoke architecture. In order to alleviate the processing load of potentially thousands of clients connecting to a single server, SonicMQ implements a clustered server architecture.

Clustered architectures also provide a level of redundancy. If one server in the cluster fails for any reason, clients can reconnect to any of the existing servers and continue processing.

There are, however, some inherent difficulties in clustered topologies. Each server is connected to every other server in the cluster. If there a large number of servers are required, this could involve complex connection topologies that may become unmanageable. If communication across servers is not frequent, this wastes network bandwidth. Also, in order to establish such connections, servers must be aware of the security access information of every other server. Sharing information in this manner is not acceptable.

To overcome these issues, SonicMQ introduced the Dynamic Routing Architecture (DRA). The DRA allows servers and clusters to operate independently of each other, but lets them connect on an as-needed basis.

With SonicMQ's DRA implementation, organizations can easily and securely develop e-marketplace-style applications, as well as conduct global business in a cost-effective fashion.

Support for XML-formatted information makes SonicMQ suitable for cross-organizational, as well as cross-application use.

Connectivity to other messaging systems is provided by a series of SonicMQ Bridges. These bridges allow two-way communication between SonicMQ systems and other messaging and communication infrastructures. Currently, the following bridges are available:

  • SonicMQ Bridge for MQSeries: Allows two-way communication through the native interface to IBM's MQSeries messaging product.
  • SonicMQ Bridge for JMS: Allows two-way communication to a wide variety of messaging implementations using the JMS standard interface.
  • SonicMQ Bridge for FTP: Allows FTP file transfers to hook into a messaging infrastructure, ensuring guaranteed delivery of files.
  • SonicMQ Bridge for Mail: Allows e-mail systems to send e-mail within a SonicMQ messaging infrastructure, ensuring guaranteed delivery of e-mail messages.

SonicMQ is developed by Sonic Software Corporation, a wholly owned subsidiary of Progress Software Corporation. With offices worldwide, technical support centers located in three geographical regions offering 24x7 support, and expert consulting services in each region, Sonic Software Corporation stands ready to support any worldwide deployment of SonicMQ.


E-mail systems have long been used to facilitate communication among people. That same level of communication is now required among applications. Messaging middleware is rapidly gaining favor once again as the technology that allows these applications to communicate with each other, and is being used to solve a wide variety of today's business problems. The latest messaging implementations, such as SonicMQ, offer rich functionality to handle messaging tasks from a simple application integration problem, to a complex, geographically dispersed e-marketplace, all while offering the massive scalability, 24x7 reliability, and advanced security required by these systems.

Copyright 2001, Sonic Software. Reprinted by permission.


Ask our messaging expert your questions

The Best Web Links for Messaging Middleware

Sonic Software

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.