Messaging and Integration From IBM: A Vital Source of Secure and Fast Application-Level Collaboration
In this edition of "z/OS and Friends," Joe Gulla explains the importance of messaging in the exchange of data, focusing on IBM MQ before discussing a collection of other messaging products
When computer applications started to become distributed, databases on one server and applications on another, there developed a need for ways to share data securely and quickly. The network providing a pathway between the application components (and servers) became very important as well. The IT industry went to work on ways to share data between systems, and messaging became an important tool to exchange data. Other integration techniques were developed as well. APIs emerged to access the application and the data it utilizes, from one system to another. API people call it expose; I use access.
In 2016, I became involved in the “API economy,” writing technical papers for a company that produced software that helped to create and manage APIs. I wrote about it and presented a paper at a conference at Marist College in 2017 called “Making Sense of the API Economy.” I did this to help other people, like me, who had a steep learning curve figuring out this IT phenomena. I had to learn to largely forget what I had previously known about APIs as an access method for availability management and to start thinking about them as programs. It seemed like the API industry had recycled the name API and used it for an almost entirely new purpose.
Don’t Make a Mess
If you think of APIs as programs, then you suddenly understand why you need a comprehensive management system to handle them. Like other programs, modern APIs need source control, distribution, maintenance and everything else involving their API life cycle. If you don’t manage them, you lose control. And then what do you have? A mess. If you are going to deploy APIs as a vehicle for integration, then you need to manage them like any other production asset. With care. Most advocates of APIs understand this by now.
My Plan
In the first part of this article, I discuss IBM MQ. That is the messaging product that is my focus. MQ is hugely important and I will give it its due. After MQ, I discuss a collection of other integration products. Some products help make integration assets; others help manage them so you don’t make a mess.
Integration Made a Leap Forward With IBM MQ
IBM MQ, originally known as MQSeries, was first released in December 1993, called MQM MVS/ESA V1.1 for IBM mainframes. It was developed to provide reliable, asynchronous messaging between applications across different platforms. This type of messaging is considered a foundational concept for enterprise integration.
IBM MQ was developed by the IBM Hursley Laboratory in the UK. From my articles on CICS, you might remember that I recognized IBM Hursley’s powerful contribution to CICS through development of the Command-Level Interface and debugging tools like CEDF. I was confident from the start that MQ would be a success based on my experience as a customer of CICS. The functions of MQ were needed, and the Hursley team was going to do what they do with excellence.
How successful has MQ been? As of June 30, 2025, IBM’s revenue for software was $28.17 billion for the trailing 12 months (labelled TTM). IBM MQ is part of the Automation and Integration category within IBM’s Software segment. This category includes integration products like IBM App Connect, IBM API Connect and IBM DataPower Gateway, alongside IBM MQ. While exact figures for MQ alone aren’t disclosed, the Software segment accounts for over 45% of IBM’s total revenue, and MQ is a foundational product used by thousands of enterprises globally.
6 IBM Messaging and Integration Products
IBM’s messaging and integration products for z/OS are designed to enable secure, reliable and scalable communication between applications—within the mainframe, on other servers and across hybrid cloud environments. They go about the challenge of integration in a straightforward way but understand that integration is not an easy matter.
1. IBM MQ
IBM MQ provides asynchronous messaging between applications. This ensures reliable delivery, even if systems are temporarily unavailable. Its basic features are shown in Table 1 below.
Table 1. Main Features of IBM MQ
| Feature | Function |
| Message Queuing | Applications send messages to queues, decoupling sender and receiver (asynchronous messaging). Messages can be big chunks of data. You will read how big later in the article. |
| Transactional Integrity | Supports two-phase commit for reliable business transactions. Whether to commit or abort (roll back) a transaction has long been important to business transactions. |
| Platform Interoperability | Works across z/OS, Linux, Windows and cloud platforms. The “scope of applications and systems” question below will expand on this. |
| Security | Offers TLS encryption, authentication and access control. |
I have questions. Maybe you do too:
How is IBM MQ typically used? Thousands of MQ customers mean hundreds of use cases. Examples of its use include payment processing and order fulfillment through inter-application communication across enterprise systems. There is an extraordinary IBM MQ video presented by the IBM MQ product manager that has great information about how MQ is used. Toward the end of the video there is a discussion about a customer success story with MODUSBOX and the US Federal Reserve System.
What can you send in an IBM MQ message? In IBM MQ, you can send a wide variety of data types in a message—essentially any kind of digital content—if it fits within the message size limits and is properly encoded. This can be text data (plain, structured or encoded), binary data (images, encrypted contents or serialized objects), business data (financial transactions or order details), or application payloads (SOAP or REST messages). See “MQ: Message Body Parts, Contents and Structure” on YouTube for an informative presentation on the MQ message.
How big (or small) can an IBM MQ message be? IBM MQ messages have size limits. A message can be 0 bytes (empty payload), typically used for signaling or control purposes. The default maximum size is 4 MB per message, which can be increased to 100 MB or more by adjusting MQ Queue Manager settings (MAXMSGL parameter).
What has happened to IBM MQ architecture since the early product architecture? IBM MQ has changed to meet growing customer wants and needs. Here are some examples:
Table 2. Features Added to IBM MQ After Early Releases
| Focus | Purpose |
| Clustering | Provides load balancing and high availability |
| Availability | Utilizes a multi-instance queue managers for failover |
| Performance | Supplies queue sharing groups on z/OS for parallel processing |
| Modernization | Supports SOAP, JMS and REST APIs |
| Cloud | Supports cloud-native deployments |
| Appliance | Provides an MQ Appliance for simplified hardware-based messaging |
| Advanced Option | Makes available an MQ Advanced option with enhanced security, telemetry and HA features |
| Availability | Introduced Native High Availability (HA) and Replicated Data Queue Manager (RDQM) for distributed systems |
| Modernization | Enhanced support for OpenTelemetry integration, event-driven architectures and hybrid cloud integration |
What is the scope of applications and systems that can participate in IBM MQ messages using a specific queue manager? The scope of systems that can participate depends on several factors, including the configuration of the queue manager, the network setup and the type of MQ clients or applications involved. The participants could be:
(1) Local applications (running on the same system)
(2) Remote applications on different systems (connected to the queue manager using client mode over TCP/IP)
(3) Other IBM MQ Queue Managers (part of a distributed MQ network)
(4) Through integration with other software systems like Enterprise Service Buses and Message Brokers—web services and REST APIs can play a role here too.
These application systems can run on z/OS, Linux, Windows, IBM I, AIX, Oracle Solaris, HP-UX, container platforms (Docker and Kubernetes, OpenShift and others), cloud platforms (IBM Cloud, AWS, Azure, Google Cloud) and mobile and embedded systems.
If you were not familiar with MQ messaging conventions, maybe a light just went on when you read the answers to these questions. Hopefully, this was a refresher on why powerful messaging capabilities are important for applications in distributed computing environments.
Let’s move on to IBM App Connect Enterprise for z/OS and begin a focus on products that use techniques and tools to integrate applications and systems.
2. IBM App Connect Enterprise (ACE) for z/OS
IBM App Connect Enterprise (ACE) on z/OS allows businesses to integrate modern applications with their existing mainframe systems. It does this by running ACE as a Docker container within the IBM z/OS Container Extensions (zCX) environment. This makes it possible to access mainframe data and applications as APIs through IBM z/OS Connect and their use by ACE, providing a unified platform for data flow and integration across diverse systems.
Key features: ACE runs natively on IBM z/OS mainframes. It uses Integration Toolkit (Eclipse-based IDE) for developing message flows. It is designed for high-performance, enterprise-grade integration with support for protocols like MQ, HTTP, SOAP and more. Its focus is complex orchestration, data transformation and protocol bridging.
How is it used? It is used to integrate COBOL applications with cloud-native services or for real-time data transformation and routing. Its focus is supplying APIs to expose application that run on mainframes. It is commonly used when connecting CICS and IMS applications to cloud services by providing real-time data transformation and routing and API orchestration.
Take away: Enterprise integration and orchestration on the mainframe.
3. IBM App Connect
IBM App Connect is an integration platform that enables businesses to connect applications, data and systems across hybrid cloud environments. It supports both event-driven and API-based integration.
Key features:
App Connect converts data formats (JSON, XML, CSV, etc.) between systems. It supports event-driven flows by reacting to events in real time, like when a new customer record triggers a workflow. It enables API creation and management supporting integration flows as REST APIs. It employs a low-code interface using a drag-and-drop flow designer for business users and developers. It has built-in connectors for hundreds of services and protocols (enterprise connectors). App Connect also supports many deployment options—cloud-native, on-premises, containerized and on z/OS for high-performance, secure integration with legacy systems.
How is it used? It is mainly used for application integration connecting cloud and on-premises apps like Salesforce, SAP, IBM MQ and databases.
Take away: Low-code integration for cloud and hybrid environments.
4. z/OS Connect Enterprise Edition (EE)
z/OS Connect EE makes it possible to access mainframe assets as RESTful APIs, enabling modern app development. This access is commonly called “exposing,” which some note is an unfortunate word to use. Functionally, it is similar to IBM App Connect Enterprise for z/OS, but they serve different purposes and are designed for different types of integration.
What does it do? It connects to CICS, IMS, Db2, MQ and other z/OS subsystems, utilizing OpenAPI (Swagger) for API definitions. It supports JWT, OAuth2 and other modern security standards, and enables cloud-native and mobile apps to access mainframe data.
How is it used? It is used in mobile banking apps accessing CICS transactions and cloud apps querying IMS databases. It provides an API gateway integrating with z/OS systems.
Take away: Expose mainframe services as REST APIs.
5. IBM API Connect
IBM API Connect is a full lifecycle API management platform. It is a tool to help you not create a mess. It is used to create, secure, manage, socialize, monetize and analyze APIs. The software includes an API Gateway, Developer Portal, Analytics and API Manager. It supports REST, GraphQL, SOAP, WebSockets and other API mechanisms. It offers AI-powered automation for API governance and security. It is deployable on-prem and in cloud or hybrid environments.
How is it used? A bank might use it to expose APIs to fintech partners while enforcing strict security and usage policies.
Take away: API lifecycle management including design, secure, publish and monitor.
6. IBM DataPower Gateway
IBM DataPower Gateway provides a secure gateway for APIs, web services and cloud workloads. It acts as a reverse proxy, security layer and traffic manager providing encryption, authentication, rate limiting and threat protection. The product works with IBM API Connect for policy enforcement. It is optimized for high-performance and low-latency environments.
How is it used? Protecting backend systems from external API traffic while enforcing compliance and throttling.
Take away: A security and mediation gateway.
How They Work Together
You have a mainframe COBOL application that you want to expose as a REST API, so you use z/OS Connect EE to accomplish that. The API you created is secured and managed using API Connect and DataPower Gateway. Next, App Connect or ACE orchestrates the API with other systems. These other systems might be Salesforce, SAP or some other commercial application. IBM MQ ensures reliable messaging between components—for example, between ACE and the backend. DataPower handles security, transformation and protocol mediation at the edge.
Perhaps this simplified flow helped you better understand the interaction and role of each product. This generalized scenario reflects the process steps in Figure 1. The steps’ names are often different depending on the software supplier. Frequently, orchestration is a process step named, as it is the process that coordinates multiple APIs.
6 in 1
Table 3. The Products and Their Relationship to One Another
| Product | Primary Role | Overlaps With | Unique Strength |
| IBM MQ | Messaging and transport | APP Connect in area of integration | Guaranteed delivery |
| IBM App Connect (ACE) for z/OS | High-performance integration engine | IBM App Connect, MQ, z/OS Connect EE, IBM DataPower | Deep integration and orchestration capabilities on z/OS |
| IBM APP Connect | Hybrid integration platform | MQ, z/OS Connect EE | Low-code automation |
| z/OS Connect Enterprise Edition (EE) | API exposure for mainframe | API Connect | REST APIs for z/OS |
| IBM API Connect | API management and governance | z/OS Connect EE | Full API lifecycle |
| DataPower Gateway | API security and traffic | API Connect | High-performance security |
One More Thing …
What is the difference between IBM App Connect Enterprise (ACE) for z/OS and IBM App Connect? You might be a little confused as their names are so similar. IBM App Connect Enterprise for z/OS and IBM App Connect are related but serve different purposes and audiences. Here is a quick way to visualize how they are utilized.
IBM App Connect Enterprise (ACE) for z/OS
Table 4. A short summary of App Connect Enterprise for z/OS
| Platform | Runs natively on IBM z/OS |
| Purpose | Provides advanced integration capabilities for mainframe environments |
| Features | Supports message flows, data transformation and protocol bridging |
| Integrates with CICS, IMS, DB2, and MQ on z/OS. | |
| Offers high-performance, low-latency and secure integration within mainframe workloads | |
| Uses the Integration Bus runtime, formerly known as IBM Integration Bus (IIB) | |
| When used | Ideal for organizations that want to keep integration logic close to their mainframe applications for performance and security |
IBM App Connect
Table 5. A Short Summary of App Connect
| Platform | Available as a cloud-native service, on-premises software or in a hybrid deployment |
| Purpose | Provides low-code integration and workflow automation across cloud and enterprise apps |
| Features | Drag-and-drop interface for building flows |
| Connects to hundreds of SaaS and enterprise apps (e.g., Salesforce, SAP, Microsoft 365) | |
| Supports event-driven, API-led and batch integrations. | |
| Can integrate with MQ, z/OS Connect EE and other IBM tools. | |
| When used | Ideal for business users and integration developers working across cloud and on-prem systems |
Now that you have a quick way to differentiate the App Connect products, I want you to see them side by side. Think of Table 6 as a cheat sheet.
Table 6. The App Connect Products, Side by Side
| Feature/Function | App Connect Enterprise for z/OS | IBM App Connect |
| Where is it deployed? | z/OS | On-premises or hybrid cloud |
| Who cares about it? | System integrators and mainframe computing teams | Business users and developers focused on integration |
| How does it work? | A toolkit for development | Uses a low-code approach including a designer |
| What is its integration focus? | CICS, IMS and Db2 subsystems on z/OS | Cloud applications, APIs and databases |
| What is its performance focus? | Mainframe workload focus, making sure it runs well | Focus is more on flexibility across environments |
Next Article
In the next “z/OS and Friends” article, I will dig deeper and broaden the integration topic and include a discussion of networking considerations. Once you understand the product set for messaging and integration, there are the challenges of putting them to good use.