EJB Architecture

An EJB container is the part of a Jakarta EE application server that manages enterprise beans. It creates bean instances and may pool them, injects their dependencies and controls their life cycle. Most importantly, it intercepts every business method call through a proxy and applies services around it: starting or joining a transaction, checking security roles, managing concurrency and running interceptors. The developer writes a plain class with annotations such as @Stateless and @TransactionAttribute, and the container provides the infrastructure behaviour declaratively. Many of these ideas later moved into CDI and are now used well beyond EJB.

There are two main kinds. Session beans implement business logic called by clients. A stateless session bean keeps no conversational state between calls, so the container can pool instances and give any instance to any caller. A stateful session bean keeps state for one client across several calls, such as a multi-step checkout, and is removed or passivated when no longer needed. A singleton session bean has exactly one instance per application, useful for shared caches or start-up logic, with container-managed concurrency. Message-driven beans are the second kind: they consume messages asynchronously from a queue or topic, usually through JMS.

Clients obtain an EJB reference either by injection or by lookup. Injection with @EJB, or with @Inject when CDI is used, is the usual approach inside the same application. Lookup uses JNDI with portable global names in the form java:global/app/module/BeanName!fully.qualified.Interface, which is useful from code the container does not manage. In every case the client receives a container-generated proxy, not the bean instance itself. That proxy is what lets the container apply transactions, security and interceptors on every call, and it is also why a remote client can call a bean running in another server.

Container services such as transactions, security checks and interceptors are applied by the proxy that sits between the client and the bean. When one business method calls another method on the same bean through this, the call goes directly to the instance and never passes through the proxy. As a result, the second method's @TransactionAttribute, for example REQUIRES_NEW, its security roles and its interceptors are silently ignored. The fix is to call through the container: inject the bean's own reference with @Resource SessionContext and use getBusinessObject, inject itself, or move the method into a separate bean. Spring proxies behave the same way.

Most of EJB's useful ideas were generalised so they work with any CDI bean, not just EJBs. Interceptors became a general Jakarta mechanism with @Interceptor and interceptor bindings. Declarative transactions are available through @Transactional from Jakarta Transactions. Declarative security uses @RolesAllowed and related annotations from Jakarta Security. Asynchronous methods and scheduled tasks are provided by Jakarta Concurrency, including managed executors and, in Jakarta EE 11, support for virtual threads. As a result, new Jakarta EE applications rarely need EJBs at all, while existing EJBs keep working alongside CDI beans in the same application.

Start with an inventory: every bean and its type, remote interfaces and their clients, timers and schedules, transaction attributes, security annotations, message-driven beans and any pooling or concurrency settings. Map each to its modern equivalent, such as CDI beans with @Transactional, Jakarta Concurrency for asynchronous work and schedules, or REST or messaging for remote interfaces. Flag behaviours that change subtly, such as which exceptions cause rollback, the loss of instance pooling limits that used to throttle load, and stateful bean passivation. Then migrate incrementally, protected by behavioural tests around each area, and record the target architecture in an ADR.