MAS 9 Integration Modernization: REST, Kafka, and the End of RMI

If you have been running Maximo 7.6 for a decade, your integration story is a museum tour. You have SOAP web services, JMS queues, flat file exchanges, the legacy /maxrest/rest endpoint, and probably a couple of RMI bridges holding everything together. Maximo Application Suite 9 does not throw that museum away, but it does repaint the walls, change the lighting, and quietly remove a few exhibits that IBM has declared obsolete.

Three words summarize the new direction: JSON, Kafka, API keys. The old /maxrest/rest endpoint with basic auth has been replaced by /api with API key authentication. JMS queue-based messaging is being supplemented, and increasingly replaced, by Kafka event streaming. RMI for direct remote MBO access is deprecated outright and is expected to be removed in a future release. If you are starting a new MAS 9 project in 2026, none of those legacy choices should appear in your design document. If you are mid-upgrade, you need a clear migration plan for the ones you already have.

This article walks through every integration path that exists in MAS 9 today, explains what each one is good for, and gives you a practical decision tree for new work. We will look at the JSON API in depth, cover MIF and SOAP for backward compatibility, dive into Kafka for event-driven integration, and finish with a few words on OSLC, GraphQL, and the architectural principles IBM is steering everyone toward.

The Integration Landscape in MAS 9

Maximo Application Suite consolidates what used to be a sprawling patchwork of integration options into a smaller, more consistent set. At the platform level, MAS 9 exposes the Maximo Manage REST/JSON API as the primary integration path. The Maximo Integration Framework (MIF) still exists for legacy XML, SOAP, and flat file work, but IBM has been clear that engineering investment is going to the REST API, not MIF. Every other MAS application, including Monitor, Health, Predict, Assist, and Visual Inspection, exposes its own REST API. These are not parallel universes. They are a consistent family of JSON-over-HTTPS endpoints authenticated with API keys.

The other big shift is the event backbone. MAS 9 runs on Red Hat OpenShift, and OpenShift brings Kafka as a first-class citizen. Where Maximo 7.6 used JMS queues running inside the application server JVM, MAS 9 uses Kafka topics for publish-subscribe patterns. This unlocks patterns that were awkward or impossible before, like multi-consumer fan-out, durable replay, and stream processing with ksqlDB. If you have ever wanted to feed Maximo events into a data lake without writing a custom JMS bridge, Kafka is the answer.

Here is how the major integration options stack up in 2026:

The recommendation from IBM, and from senior practitioners in the community, is straightforward. Use the JSON API for synchronous request-response work. Use Kafka for asynchronous event distribution. Treat MIF as a migration liability, not a destination. Treat RMI as already gone.

The JSON API as the Primary Path

The Maximo Manage REST/JSON API is the recommended integration mechanism for all new work in MAS 9. If you build one integration skill for the upgrade, make it this one. The API follows standard REST conventions, returns clean JSON, and requires no pre-configuration of OSLC resources or object structure export channels to start using. The base URL pattern is:

https://<mas-host>/api/os/<objectstructure>

The <objectstructure> placeholder is the name of a Maximo Object Structure. Common ones include mxwo (work orders), mxasset (assets), mxpo (purchase orders), and mxitem (inventory items). The API supports the full set of HTTP verbs on each object structure, including GET for retrieval, POST for creation, PATCH for partial updates, PUT for full replacement, and DELETE for removal (though DELETE is rarely used in production).

Here is what a typical authenticated request looks like:

# Obtain an API key from the MAS API Keys application
# Store it as an environment variable for the session
export MAXIMO_API_KEY="ak_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# Query for high-priority work orders
curl -X GET \
  "https://mas.example.com/api/os/mxwo?oslc.select=wonum,description,status,asset{assetnum,description}&oslc.where=status%20in%20%5B%22WAPPR%22%2C%22APPR%22%5D%20and%20wopriority%3C3&oslc.pageSize=50&lean=1" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer ${MAXIMO_API_KEY}"

The lean=1 parameter is one of the most useful features added in recent releases. It strips out the OSLC namespace complexity from the response and returns pure, readable JSON. Without lean=1, every field comes back wrapped in RDF-style properties. With lean=1, the same request returns a clean array of objects with direct field names. For new integrations, always use lean=1.

A few features worth highlighting:

• Bulk operations: the _bulkid parameter enables batch creation or update of multiple records in a single request, dramatically reducing overhead for mass data changes.
• Attachment handling: upload and download attachments directly through the API using multipart form uploads, with support for doclinks.
• Saved queries as endpoints: any saved query you build in the Maximo UI can be exposed as a callable REST resource, which is a fast way to give mobile apps curated data slices.
• Pagination support: oslc.pageSize and the response next link handle large result sets without pulling the entire dataset at once.
• Field selection: oslc.select returns only the fields you need, reducing payload size and improving client-side parsing speed.

Authentication is API key based. API keys are managed through the API Keys application in Maximo Manage. Each key is scoped to a user account and inherits the security group permissions of that user. This is a significant security improvement over Maximo 7.6's basic authentication over HTTPS, because keys can be rotated, scoped, and revoked without touching the underlying user account. The same OAuth 2.0 token model is also supported for integrations that need short-lived tokens.

MIF and SOAP: Backward Compatibility, Not a Destination

The Maximo Integration Framework is not dead. It still works in MAS 9, and many organizations have hundreds of MIF configurations that they cannot just throw away. But it is no longer the recommended path, and IBM has been explicit that engineering effort is going to the REST API rather than MIF enhancements.

If you have an existing MIF configuration, the migration steps are usually minor. Most existing integrations continue to work, but you will need to switch from basic authentication to API keys for SOAP and REST calls. You should also test for behavioral changes between the versions, particularly around date handling, null fields, and the order of operations in processing chains. Some publish channels and enterprise services that were standard in 7.6 have been deprecated in favor of equivalent REST endpoints, and a small number of niche features have no REST equivalent at all.

Here is a short checklist for assessing a legacy MIF integration:

• Authentication: switch to API key auth, rotate credentials, store keys in a vault.
• Object structure review: confirm the object structure is still valid, including any custom fields added in 7.6.
• Processing class review: any custom Java processing classes need to be re-compiled against the MAS 9 libraries, and the JVM has changed from JRE 8 to JRE 17.
• Endpoint review: confirm that HTTP, JMS, and file endpoints are still reachable from the new MAS deployment.
• Error handling review: 7.6 error codes have been reorganized in some cases. Confirm that downstream consumers are not relying on numeric codes that have shifted.

The legacy REST API at /maxrest/rest is a special case. It was developed in the early 7.1/7.5 days and still exists in MAS, but it should not be used for new work. Most of its features are available in the new JSON API, and the ones that are not, like interacting with MBOs without using object structures, were intentionally not migrated. If you have integrations still on /maxrest/rest, they should be on your migration list.

RMI is in the same category but more urgent. RMI is deprecated in MAS 9 and will be removed in a future release. Every RMI-based integration needs a REST API rewrite, planned and budgeted now. The good news is that RMI integrations are usually isolated and small in number. The bad news is that the rewrite is not a drop-in replacement, so allocate engineering time for testing.

Kafka and Event-Driven Integration

The biggest architectural change in MAS 9 is not the JSON API. It is Kafka. Maximo 7.6 used JMS queues for asynchronous integration, and JMS is still available, but Kafka is the platform IBM is betting on. Every MAS deployment on OpenShift comes with a Kafka cluster (or at least the option to attach one), and the integration patterns that were awkward in JMS become trivial in Kafka.

The core idea is publish-subscribe. A Maximo event, like a work order being approved, gets published to a Kafka topic. Any number of consumers can subscribe to that topic. Each consumer gets its own copy of every message, processes it independently, and can replay historical messages if needed. This unlocks several patterns that were painful in JMS:

• Multi-consumer fan-out: one event can drive a downstream ERP update, a real-time dashboard, and a data lake ingestion simultaneously, without any of those consumers knowing about each other.
• Durable replay: if a consumer goes down for maintenance, it can rewind the topic to the last processed offset and catch up. JMS required fragile manual redelivery logic.
• Stream processing: ksqlDB or Apache Flink can sit on top of Kafka topics and compute aggregates, detect anomalies, or trigger alerts in real time.
• Loose coupling: producers and consumers do not need to know about each other. New consumers can be added without touching the producer.

In MAS 9, the recommended way to publish Maximo events to Kafka is through the integration framework's Kafka endpoint, which is configured the same way you would configure an HTTP or JMS endpoint. The payload is JSON, the topic name is configurable, and the message key is typically the record identifier (like wonum for work orders).

A typical event payload looks like this:

{
  "eventType": "WORKORDER_APPROVED",
  "eventTime": "2026-07-20T14:32:11.123Z",
  "objectStructure": "mxwo",
  "record": {
    "wonum": "WO1234567",
    "status": "APPR",
    "assetnum": "PUMP-001",
    "location": "PLANT-A-NORTH",
    "worktype": "PM",
    "schedstart": "2026-07-22T06:00:00.000Z"
  }
}

Downstream consumers can be written in any language with a Kafka client library. Python with confluent-kafka, Java with kafka-clients, or Node.js with kafkajs are all viable. The key design decision is the topic naming convention. A common pattern is <application>.<object>.<event>, like maximo.workorder.approved or maximo.asset.updated. Whatever you pick, document it and stick to it.

OSLC, GraphQL, and API-First Design

OSLC (Open Services for Lifecycle Collaboration) is still supported in MAS 9, but it is no longer the primary recommendation. The OSLC API exposed at /oslc/... uses RDF-style payloads and a more complex query syntax than the JSON API. It is still useful for existing OSLC clients, and the JSON API is built on the same code base, so features generally move in lockstep. But for new work, the JSON API with lean=1 is almost always the right answer.

GraphQL is a more recent addition to the conversation. Some MAS deployments are experimenting with GraphQL gateways that sit in front of the REST API and let clients request exactly the data they need in a single round trip. The performance gains are real, especially for mobile clients that need to render a screen with work order details, asset information, and attachment metadata. A REST API might require three sequential requests to render that screen. A GraphQL query can fetch all of it in one. Expect to see more GraphQL tooling in the Maximo ecosystem over the next year, particularly from third-party integration vendors.

The broader principle is API-first design. Before you write a single line of integration code, design the API contract. Document the endpoints, the request payloads, the response shapes, the error codes, and the authentication model. Use OpenAPI or AsyncAPI specifications to capture the contract. Generate client SDKs from the spec. Test the spec with contract testing tools. This is not Maximo-specific advice. It is just good engineering. But it is especially valuable in MAS 9, where the API surface is large and the consequences of a poorly designed contract can haunt you for years.

Practical Implications

For teams planning a MAS 9 upgrade, the integration work is often the most underestimated part of the project. Migrations that look like "just point the existing config at the new server" turn into multi-quarter engineering efforts when the underlying authentication, JVM, and event bus all change at once. The practical move is to audit your integration inventory early, classify each one as keep, migrate, or retire, and budget accordingly.

For new MAS 9 work, the API design checklist is short: use the JSON API with lean=1 for synchronous work, use Kafka for asynchronous event distribution, authenticate with API keys, and expose your integration contracts as OpenAPI specifications. If you find yourself reaching for SOAP, JMS, RMI, or /maxrest/rest for new development, stop and ask whether there is a REST or Kafka equivalent. In nearly every case, there is.

The total cost of ownership question is real but often missed. Legacy MIF integrations are expensive to maintain, partly because the skill set is rare and partly because the documentation is scattered. A focused effort to retire MIF integrations in favor of the JSON API can pay for itself in 18 to 24 months through reduced support costs, faster onboarding, and fewer production incidents. That is a conversation worth having with the budget owner before the upgrade, not after.

Bottom Line

The Maximo integration story in 2026 is JSON, Kafka, and API keys. The JSON API at /api/os/... is the primary path for synchronous request-response work. Kafka is the recommended backbone for asynchronous event distribution. API keys are the recommended authentication model. MIF, SOAP, and JMS still work for backward compatibility, but they are not where new investment should go. RMI is on its way out, and /maxrest/rest should be treated as already gone.

If you are starting fresh, design your integration layer around these three primitives and you will avoid most of the migration pain that earlier Maximo customers went through. If you are mid-upgrade, audit your existing integrations now, prioritize the highest-cost and highest-risk ones for migration, and budget the engineering time to do it right. The MAS 9 platform rewards teams that treat integration as a first-class architectural concern, not a checkbox at the end of the project.