EJB support in Websphere Traditional vs Liberty

I am working on a project where we are planning to use WLP (WebSphere liberty) instead of traditional WAS.

The code is having ejb modules (ejb 2 and 3) for different components. EJB client of one component is used by some other components to talk with the EJB server module.

I know that liberty has some ejb features. But does liberty have same level of support/features for EJB as available in WAS 9?

What are the limitations/issues of using EJB with liberty ?

WebSphere v9 and WebSphere Liberty both support the full EJB 3.2 specification (which includes back level support for EJB 1 & EJB 2). However, there are some limitations in WebSphere Liberty when it comes to supported optional features and extensions that go beyond the EJB specification. The current limitations in WebSphere Liberty compared to WebSphere v9 are:

• Entity beans : Liberty does not support the optional 2.x / 1.x CMP/BMP Entity Beans API group.

• JAX-RPC Web Service Endpoints : Liberty does not support the optional JAX-RPC WebService Endpoints API group. (JAX-WS Endpoints are supported) Update: New in January 2022, a Maven/Gradle conversion tool is available to migrate JAX-RPC applications to JAX-WS. See the following blog post and documentation for details.

• Embeddable EJB Container : Liberty does not provide an implementation of the optional Embeddable EJB Container API group.

• Transaction propagation : Liberty does not support outbound or inbound transaction propagation for remote EJB methods. Transactions are propagated within the server process, but not from a client or with another server process.

• EJB Thin Client support : Liberty does not provide an EJB thin client, though does support use of the WebSphere v9 EJB thin client. Liberty does provide the full Java EE application client. Also, Liberty does not provide tooling to manually generate EJB stub classes for use with a thin client, though stubs generated with either RMIC (EJB 2.x/1.x) or the createEJBStubs command (EJB 3.x) from WebSphere v9 are supported.

• Custom JNDI names : Liberty does not support binding EJBs into JNDI using custom names (from ibm-ejb-jar-bnd.xml). EJBs are made available in the specification defined locations in java:global, java:app, and java:module. Note: this support is in development, and you may follow the progress as detailed here : https://github.com/OpenLiberty/open-liberty/issues/7918 Update: Now available starting with Liberty 20.0.0.12.

• Persistent timer failover : Liberty does not support failing over EJB persistent timers to other server instances. Note: this feature is in development (and currently in beta), and you may follow the progress as detailed here : https://github.com/OpenLiberty/open-liberty/issues/7774 Update: Now available starting with Liberty 20.0.0.5.

• Stateful session failover : Liberty does not support failing over the state of Stateful session beans to other server instances.

• WLM : Liberty does not provide capability similar to the Workload Management support available in WebSphere v9 for remote EJB calls.

• PMI : Liberty does not support the WebSphere Performance Monitoring Infrastructure that is provided on WebSphere v9.

• Local optimization for remote EJB interfaces : Remote EJB calls within the same server process are not optimized, they will go through the full RMI/IIOP stack.

• EJB MDB support for listener ports : Liberty supports using Activation Specs with message-driven beans.

Based on the description of your application, you may have issues with the use of EJB remote interfaces, due to the lack of support for transaction propagation, an EJB thin client, and WLM. You may want to consider exposing those beans as Webservice Endpoints instead (@WebService). Also, if the application uses custom JNDI names, like ejb/ABean or ejblocal:ABean, then you would need to switch those to looking up the beans using the specification defined locations such as java:global/<app>/<module>/ABean!<interface>.