Many clients are looking at ways to modernize their application development, taking advantage of technologies like Docker, Kubernetes and Helm. But many of these same clients still have a large set of Java EE applications in production today on traditional IBM WebSphere Application Server (abbreviated in this post to tWAS). In order to run those existing applications in a Docker container, they first need to be migrated to a Java EE application server that was designed with Docker in mind. IBM WebSphere Liberty is such an application server and is built on top of the IBM open source project Open Liberty. WebSphere Liberty brings a number of other benefits as it’s a relatively light-weight application server that starts in seconds and is a perfect fit for containerising Java EE applications.
IBM Cloud Private is a commercial offering from IBM and provides clients with an on-premises solution based on Docker, Kubernetes and Helm. It also comes with a tool to help clients to analyse their existing Java EE applications and determine the effort and complexity of migrating those applications to Liberty and/or IBM Cloud Private.
The purpose of this blog post is to highlight a few subtle but sometimes extremely relevant differences between tWAS and IBM WebSphere Liberty. We recommend that clients review these differences when they are about to undertake a migration.
Global transactions, remote EJB calls and WLM in tWAS
One of the luxuries of running Java EE applications on tWAS is that it comes with a proven transaction manager. It supports global (two-phase commit) transactions for Java EE applications, even when the transaction scope spans different Java Virtual Machine (JVM) processes[1]. Using the remote EJB interfaces, applications can make remote calls to other application components while propagating the transaction context.
IBM WebSphere Network Deployment (WAS ND) also comes with support for clusters, including EJB Workload Management (WLM)[2]. In other words when calling an application component remotely using the EJB interfaces, if that application resides on a tWAS ND cluster it can also take care of ensuring that discovery calls are load balanced across any of the available cluster members and transactional affinity maintained thereafter. This provides resilience and simplicity even in distributed systems that are tightly coupled by transactions.
The diagram below illustrates the support for global transactions spanning different JVM processes as well as built-in EJB WLM. This is only available when both EJB client and EJB server are deployed on tWAS ND clusters.
Global transactions, remote EJB calls and WLM in WebSphere Liberty
While Liberty has a number of advantages over tWAS, Liberty does not support remote propagation of transaction context to remote EJBs. This is typically not required for modern Java EE applications using microservices and REST, however this should be taken into account when migrating existing Java EE applications from tWAS.
The diagram below visualises the implications. You can make remote EJB calls, but you cannot span a global transaction across multiple JVM processes.
Note: WebSphere Liberty does support global transactions, as long as the transaction boundary remains within the Java Virtual Machine process of application starting the transaction.
Microservices applications and global transactions in WebSphere Liberty
With the above information in mind, it is worth highlighting the support for global transactions in microservices applications running on WebSphere Liberty. However the transaction boundary here cannot span more than a single JVM process. See the diagram below for some examples.
Note that from a Java perspective, the transaction boundary cannot span more than a single JVM process. But the actual scope of the global transaction can still involve several XA (two-phase commit) resources outside the JVM process (IBM Db2 database, Oracle Database or IBM MQ queue manager). Furthermore another EJB application can be called as well, and within the scope of the global transaction. It just has to reside within the same JVM process. Note that in this case, the EJB call does not go over RMI/IIOP but instead is called over its local interface from the Java thread of the client.
[1]IBM Knowledge Center WebSphere ND traditional 9.0.0.x – Global transactions
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/cjta_glotran.html
[2] IBM Knowledge Center WebSphere ND traditional 9.0.0.x – Clusters and workload management
https://www.ibm.com/support/knowledgecenter/SSAW57_9.0.0/com.ibm.websphere.nd.multiplatform.doc/ae/crun_srvgrp.html
Originally posted on IBM Developer blog “IBM Cloud Best Practices from the Field” by Hendrik van Run on 5 October 2018 (4277 visits)
IBM Cloud Best Practices from the Field 