Some historical background:
Although the software product currently known as App Connect Enterprise has been available even longer, about 20 years ago WebSphere Message Broker version 6 was the first version of our technology to provide message flow developers with a Java Compute node. This gave users the option to dip into ad hoc Java code as part of a flow implementation. Since then, on all our distributed platforms (and more recently on zOS too) we have provided an embedded JRE / JDK.  This approach, made possible thanks to Java’s excellent backward compatibility, makes life very straightforward for users … however more recent changes in the Java landscape have brought some disruption to this working model. After Java 8, removal of certain long-standing language features began, and for a good while we were able to cope with this internally within the ACE codebase without any major disruption for our users. However, the real challenge emerged with Java 11 (2018), which removed particular Java EE and CORBA modules (for example javax.xml.ws, javax.xml.bind, javax.activation, javax.corba, javax.transaction, javax.jws). These modules underpin critical ACE functionality such as our Global Cache (built using IBM’s WebSphere eXtreme Scale technology), and our SOAP, WSRR, and CORBA message flow nodes.  Initially, to mitigate this and allow us to maintain compatibility, we adopted Jakarta EE, which initially retained the javax namespace.  Meanwhile IBM has also continued its support of Java 8 which has enabled us to defer major changes that ensure that ACE 12 remains unaffected by the changes which we’ll dive deeper on through the rest of this article.

ACE 13 (September 2024 - present day):
When doing early planning for the ACE 13 major engineering version, it became clear that the timing of the product release would need to accommodate both mainstream lovers of Java 1.8 and also adopters of Java 17. ACE 13.0.1.0 was released in September 2024. The ACE integration server runtime process is written in code from a mixture of different languages: native C++, Java and JavaScript. Focussing on the features that utilize Java code, the vast majority of these ACE functionalities were able to run in an integration server using Java 17 when ACE 13.0.1.0 was released. These features that have been supported ever since 13.0.1.0, are summarized in the table below:

ACE 13.0.1.0 and all higher releases also support the Change Data Capture node in message flows deployed to integration servers using Java 17. This message flow node has never been supported to run inside integration servers using Java 1.8, due to the dependent libraries on which it is based requiring Java 11 or above.

Since the initial release of 13.0.1.0, we’ve shipped 13.0.2.0 (December 2024), 13.0.3.0 (March 2025), 13.0.4.0 (June 2025), 13.0.5.0 (September 2025) and 13.0.6.0 (December 2025). With each of these versions, we have been encouraging users to adopt integration servers that run using Java 17, whilst appreciating that a small number of users have needed to continue with Java 1.8 for a while longer until ALL features are available on Java 17. Below is a progress summary of the features that were impacted / remain impacted in versions of ACE more recent than 13.0.1.0:

As of ACE 13.0.6.0, the only remaining features yet to be supported in integration servers running Java 17 are WS-Security and WS-ReliableMessaging.  We’re working hard to provide this support by June 2026 at the latest, but it’s possible this work might complete sooner, in time for ACE 13.0.7.0 (March 2026).  Once these features have been delivered, we intend to continue shipping Java 1.8 as part of ACE 13 mod releases for a further 12 months to ensure that all customers have plenty of time for a smooth transition period. The final App Connect Enterprise modification release that will include running an integration server with Java 8 will be shipped in March 2027. This will also be the last modification release to include the CORBA and WSRR nodes.

The rest of this blog will provide a deeper focus on the functions described in each row of the above table.

Embedded Global Cache:
The Embedded Global Cache is a built-in caching mechanism that was first released in March 2025 in IBM App Connect Enterprise version 13.0.3.0. The Embedded Global Cache replaces a similar functionality known as the WXS embedded cache which was built upon IBM's WebSphere eXtreme Scale (WXS) technology. The old WXS embedded cache can still be used within integration servers that are running Java 8, but users are encouraged to adopt the Embedded Global Cache instead because the final App Connect Enterprise modification release that will include running an integration server with Java 8 will be shipped in March 2027.  The Embedded Global Cache allows for the in-memory storage of reusable data across message flows, whether within the same flow, between different flows, or flows running in different integration servers. The Embedded Global Cache is supported for use inside integration servers running both Java 8 and Java 17, and is also suitable for use within containerized ACE environments. The Embedded Global Cache is provided as a standard feature of the ACE product and does not bring any additional charge, nor does it require any other third-party pre-requisite technology.

You can interact with the Embedded Global Cache using a Mapping node or a JavaCompute node within a message flow. These message flow nodes can put data into a map, retrieve data from a map, and create a map if one does not exist.  Interactions with the cache happen outside the message flow transaction and are committed immediately. If an exception is thrown downstream of the message flow node that interacts with the cache, the cache interactions are not rolled back.

You can use ACE resource statistics and the ACE Activity Log to monitor the Embedded Global Cache, and ibmint commands are also available for discovering information about the current state of the cache entries. The ibmint display cache command can be used by an administrator to examine the current state of the Embedded Global Cache. The --all-maps attribute causes the integration server to list all of the map objects that have been defined, the number of keys they currently contain and the amount of memory being used:

ibmint display cache --admin-host localhost --admin-port 7604 --all-maps
BIP15355I: The server contains '1' maps:
BIP15349I: The map 'exampleMap' contains 2 keys, and is using 117 Bytes of memory.

The ibmint clear cache command is used to clear maps within the integration server against which the command is directed. The clear of the cache is not applied to other servers that the cleared server may be set up to replicate to. If you wish to clear the cache across a network of servers, you need to repeat the command on each server individually.

ibmint clear cache --admin-host localhost --admin-port 7600 --map-name exampleMap
BIP15358I: The map 'exampleMap' has had all data entries cleared from this server.

The architecture of the new Embedded Global Cache is a little different to the way in which the WXS embedded cache used to operate. For the new Embedded Global Cache, within each separate integration server, the message flows interact with the copy of the cache in that specific server:

• When a message flow attempts to read a value from its cache, if it cannot find the answer then the replicateReadsFrom configuration section of the server.conf.yaml file specifies a list of alternate servers from where the value can be retrieved. If multiple servers are specified in the list, then each server is synchronously tried (in order) until a value is found or until all servers have been tried.
• When a message flow attempts to write a value to its cache, if the replicateWritesTo configuration section of the server.conf.yaml file specifies a list of alternate servers then values that are put into the integration server’s local cache will also be asynchronously written to all of the servers in the list.
• Each integration server has the option to specify a ReplicationListener port number which is configured to allow the above cache communications between servers. Servers send internal communications across this port using either HTTP or HTTPS.

Consider the following diagram with an example of an ACE architectural topology that includes four integration servers configured to use the embedded global cache (for simplicity EnableTLS is set to false for each server, and each hostname is set to localhost):

WS-Trust:
WS-Trust is an OASIS security standard for web services that allows independent enterprise systems to establish a trust relationship and securely share information between SOAP-based web services.  The architectural approach for WS-Trust includes a client and a server who wish to communicate with one another. The process also involves a third-party Security Token Service (or STS for short), whose role is to create and issue security tokens to the client which assert user information, claims and a validity period. This means that WS-Trust involves four main actions: Issue (used when requesting a new security token from the STS), Validate (used when asking the STS to verify if a token is valid), Renew (used when renewing an existing token) and Cancel (used when asking to terminate a token's validity). Of these actions, Issue and Validate are relevant for ACE flows. The ACE support for WS-Trust involves the use of a complete Security Provider which can be referenced from both the SOAP Input node and a mid-flow Security PEP message flow node:

WS-Security:
The OASIS Web Services Security Specification provides a set of mechanisms to help developers of web services secure SOAP message exchanges. The WS-Security specification provides three mechanisms for securing web services at the message level: authentication, integrity, and confidentiality.

• Authentication uses a security token inserted in the request message to validate a user and determine whether a client is valid in a particular context. Supported security token types for authentication include Username tokens, X.509 certificates, SAML assertions, Kerberos tickets and LTPA binary tokens.
• Integrity is ensured using message signing to ensure that information is not changed, altered or lost accidentally. When integrity is implemented, an XML digital signature is generated on the contents of a SOAP message. If unauthorized changes are made to the message data during transmission, then on arrival the signature would not be validated and the server can protect itself.
• Confidentiality uses message encryption to ensure that other actors cannot access or disclose the information in the message. When a SOAP message is encrypted, only a service that knows the appropriate key can decrypt and read the message.

In order to allow ACE users to continue to phase their adoption of Java 17 and migrate at their own pace, within future ACE releases we hope to continue to support separate integration servers being able to execute using Java 17 alongside other older integration servers still executing using Java 1.8.  To achieve this with message flows that include functionality for WS-Security, is somewhat more challenging than the other functional areas discussed in this blog. We expect this to be possible using a dual stack approach, whereby class-loading code within the integration server process will selectively choose the libraries which should be loaded depending on whether the server is running under Java 1.8 or Java 17.

Java 1.8 SOAP stack:  An older SOAP stack, only loaded by integration servers running Java 1.8 (this will be the same stack used in previous ACE versions). This stack consists of:

• WebSphere Application Server (WAS) Axis2
• Additional WAS libraries
• Jakarta EE 8 (this version predates the API namespace move from javax to jakarta)

Java 17 SOAP stack: A new SOAP stack, only be loaded by integration servers running Java 17. This stack will consist of:

• Open source Apache Axis2
• Open source Apache Rampart
• Jakarta EE 10 (this version no longer uses the javax namespace and uses the jakarta namespace instead)

Due to our adoption of Apache Rampart for the future support of WS-Security in Java 17 servers, some of the ACE product externals may need to change – for example policy sets and bindings files.  Policy sets and bindings define the ACE configuration for WS-Security and WS-RM requirements, for the SOAPInput, SOAPReply, SOAPRequest, SOAPAsyncRequest, and SOAPAsyncResponse nodes.  A policy set is a container for the WS-Security and WS-RM policy types. A policy set binding is associated with a policy set and contains information that is specific to the environment and platform, such as information about keys.  More information about the current support for WS-Security in ACE is available in the IBM documentation.  When the new WS-Security capabilities are introduced in this first half of 2026, we will be in a position to share more details about the format of the configuration files that are needed and the migration process by which existing flows that use WS-Security can be carried forward for hosting inside Java 17 integration servers.

To summarize, ACE 13 already supports WS-Security within integration servers running Java 1.8 and IBM plans to provide WS-Security support within servers running Java 17 by June 2026 in an App Connect Enterprise modification release.

WS-ReliableMessaging:
WS-ReliableMessaging (WS-RM) is an OASIS specification that defines how two systems can send SOAP messages between each other reliably even in the event of network or system failures. The IBM documentation provides a good overview of how the SOAP message flow nodes provide for reliable message exchange as conformant to the WS-RM specification.  There is also a detailed interaction example in the IBM Documentation for how two systems can be configured for reliable message exchange.

The purpose of WS-RM is to ensure delivery of messages in situations such as the destination endpoint being temporarily unavailable (for example, in the case of a server restart) or the message path crossing multiple transport connections, any of which might fail (for example, across a firewall). The ACE WS-RM implementation is applicable only to the HTTP transport. If you configure WS-RM on a message flow that uses the JMS transport, the WS-RM settings are not used when the flow is deployed.  Systems that implement WS-RM retransmit messages that have not been successfully delivered and acknowledged and prevent duplicate messages from being delivered to the application destination.

To summarize, ACE 13 already supports WS-ReliableMessaging within integration servers running Java 1.8 and IBM plans to provide WS-ReliableMessaging support within servers running Java 17 by June 2026 in an App Connect Enterprise modification release.

CORBA Request Message Flow node:
CORBA (Common Object Request Broker Architecture) IIOP (Internet Inter-ORB Protocol) is a standardized communication protocol that operates over TCPIP networks. The standard describes CORBA objects (using Interface Definition Language files or IDL files for short) so that operations can be called on those objects.

WebSphere Service Registry and Repository message flow nodes:
Web Services capabilities in general received a lot of engineering focus from IBM during the period of Service Oriented Architecture adoption in the mid-2000s. Since that time, the broader industry focus has shifted towards newer API management integration technologies focussed more on API governance and modernization.  

IBM’s Product Lifecycle page provides up-to-date and historical information regarding important lifecycle dates for our software products, such as WebSphere Service Registry and Repository (also known as WSRR for short).  The most recent major version of the WSRR product (version 8.5.x) was made Generally Available in 2014.  All prior WSRR versions before 8.5 have already reached IBM’s End of Support classification.  In September 2025, IBM also made several further announcements relating to support dates for WSRR version 8.5.x:

• From February 2026, WSRR will no longer be available for ordering.
• From October 2027, WSRR will transition into sustained support.

WSRR is essentially a central repository of entities that can be queried for use inside other applications in a web service architecture. ACE provides two message flow nodes for WSRR interactions – the RegistryLookup node and the EndpointLookup node:

Summary:
For those who have not already adopted ACE 13 Integration Servers running on Java 17, IBM recommends that clients begin planning the upgrade to Java 17 now in order to ensure compatibility and avoid disruption. This blog has summarized all the recent updates for the provision of Java 17 support and has also highlighted the timing of some upcoming deadlines where your action may be required.

About the Authors:

Andreas Martens is a Senior Engineer working for App Connect Enterprise. He enjoys working with new shiny technologies, coding in C, C++, Java and occasionally Node.JS and Python. He also enjoys working directly with customers and on those gnarly hard problems!

Ben Thompson is Chief Architect of App Connect Enterprise, responsible for setting the technical and functional direction of the product, and driving external client and business partner relationships.