Many people take integration messaging for granted, and many organizations assume that any messaging platform is as fully featured as any other. But in today’s increasingly connected world, with the emergence of major trends in consumer and enterprise technology like mobile, cloud computing, big data, and the Internet of Things, your organization needs to carefully review its messaging platforms and capabilities if you hope to continue to reliably serve your customers and deliver and maintain critical advantages over your competition.
To illustrate how vital and varied messaging platforms can be, let’s explore what exactly messaging is and compare several different approaches to meeting your organization’s messaging needs.
What is integration messaging?
Integration messaging is the means by which data flows between different IT systems using mutually agreed upon and understood protocols. Messaging answers the question, “I’m alpha software. You’re beta software. How are we going to talk?” As such, messaging is critical to enable interoperability between different enterprise applications and devices.
In our big connected world, traditional messaging takes place using TCP/IP-based protocols. TCP/IP is both the wire protocol and the message protocol on top of it, which establishes a physical Internet connection between two systems. The issue then becomes how to format, transmit, receive, store-and-forward, and use low-level packet data. This is the issue messaging protocols aim to solve.
The evolution of messaging from the data center to the Internet of Things
Although TCP/IP will likely always remain central to messaging, developments outside of TCP/IP are emerging. The Internet of Things, for example, can utilize mesh networks and high latency/low reliability connectivity. Although still in its early stages, the Internet of Things is projected to become tremendously important in the near future. Messaging is often taken for granted, which might mislead people into thinking that your refrigerator, which speaks a different language, will easily communicate with the Internet. But that isn’t always the case. Messaging itself is evolving as the number of connected things that need to talk to each other continues to increase.
Many messaging product families and protocols--such as old IBM MQ and even JMS--were created with the data center in mind. We still live in that world to a certain extent, but now there’s a need for broader messaging with protocols like MQTT, STOMP and RESTful Web Services. These newer protocols are favored by sensing and mobile devices, but they still rely on TCP/IP networks.
TCP/IP isn’t going away and will still run inside the data center. But if you consider the vast tract of messaging protocols--from old-guard JMS to newcomers MQTT and REST--you discover that the proliferation of messaging formats and protocols depends on where we are in the connectivity stack. As a result, your messaging platform, rather than being taken for granted, should be carefully chosen and capable of supporting many different protocols.
Organizations rarely switch messaging platforms unless they encounter problems with their messaging or it becomes too expensive. It’s like ripping the plumbing out of your house. But that doesn’t mean you can’t install newer, better plumbing in the addition. In the same way, you can have multiple messaging systems within the same organization and build bridges between the two.
Say, for example, you already use IBM MQ and have too many systems hooked into it to rip it out and replace it, but your organization also wants to do more mobile development. You believe in using MQTT for the protocol because it uses less bandwidth and power in mobile devices. But you find that IBM’s MQTT solution is too expensive. You could take a modern, modular offering that supports MQTT, such as Red Hat JBoss A-MQ, and implement it to provide MQTT for mobile devices, and then bridge over into IBM MQ. Messaging systems don’t have to be isolated. They can be complementary and collaborate with one another, which is a powerful, economical, and too commonly overlooked option.
How to choose your messaging platform
In this age of cloud, mobile, big data, and the Internet of Things, messaging is something most people take for granted and assume will be there in all its fully-featured glory and in most cases part of an integration platform or enterprise service bus (ESB). But as we’ve seen, this isn’t always the case. When you’re reviewing your existing messaging platform or choosing a new messaging platform for your organization, keep the following questions in mind:
- Does the messaging platform support all the protocols you need? How will your systems talk to each other? Are the protocols open or proprietary?
- What are the platform’s economics? It’s one thing to be able to architect a single system; it’s another to be able to afford it.
- Which messaging features do you need to get the job done? How secure do you need your messages to be, and how reliable? While it can be tempting, you don’t have to over-engineer your system. Use only what you need.
- Does the platform’s vendor offer complementary products and services?
- How reliable is the messaging? Once implemented, you want to be able to forget your messaging system is there. Choose a platform from a proven, trusted vendor.
With the right messaging platform in place, your organization will be in a more stable and reliable place to deliver strong business results and triumph in today's increasingly competitive world.
Complete stacks vs. boutique solutions: Red Hat JBoss A-MQ vs. MuleSoft
One fundamental similarity between modern, modular messaging platforms like JBoss A-MQ and older products like IBM webSphere MQ is that both Red Hat and IBM offer complete integration and infrastructure stacks. Other enterprise integration vendors like MuleSoft, which until recently didn’t offer messaging, lack many capabilities. The MuleSoft theory is that if you need more extensive capabilities, you can implement that infrastructure separately and then hook into it using their product.
On other hand, Red Hat and IBM offer both the messaging platform and the rest of the integration stack so that messaging is available for all your integration systems as well as your business process engine, complex events processing engine, and other middleware services. Having a single vendor for your entire stack greatly simplifies subscription, implementation, and support.
Open source vs. proprietary messaging platforms: Red Hat JBoss A-MQ vs. IBM MQ and TIBCO
Avoiding messaging systems that provide a single messaging protocol like Oracle WebLogic JMS provider, Oracle Advanced Queueing, and IBM MQ Lite and instead selecting a messaging platform that supports multiple protocols like JBoss A-MQ, IBM webSphere MQ, and TIBCO is a good start. But exactly which protocols do they support? Are they open protocols, or are they proprietary? And how will you license them?
One fundamental difference between JBoss A-MQ on the one hand and IBM webSphere MQ and TIBCO on the other is which messaging protocols are included in the product subscription or license. Unlike JBoss A-MQ, which bundles every protocol the product supports in a basic subscription--including newer protocols like MQTT and AMQP--IBM and TIBCO both offer what is referred to as bolt-on messaging capabilities. In other words, while IBM webSphere MQ can also handle MQTT and AMQP, you would need to license an additional product to gain access to them.
The range of messaging protocols supported also differs across platforms. IBM webSphere MQ--an older, deeper product--encompasses virtually every protocol and is capable of being extended to address virtually every messaging use case. But as mentioned above, these extensions may only be available separately, which can introduce a large amount of cost and complexity. JBoss A-MQ, on the other hand, is lighter weight and more cost-effective while still capable of handling the vast majority of use cases, including those associated with mobile and the Internet of Things.
Finally, there is a significant difference between proprietary and open source protocols. For example, TIBCO offers add-on capabilities for low latency/high frequency, which is often used by large financial institutions for high-speed transactions. But when you adopt these add-on capabilities, you are often adding layers of proprietary messaging. Unless a proprietary platform is the only one that can provide a certain protocol or capability, think carefully before choosing it over an open source platform. Proprietary messaging inhibits the adoption of hybrid messaging. All things equal, open source messaging platforms increase portability and interoperability, which gives you more flexibility in your infrastructure.