Jakarta Enterprise Beans: Clients, Containers, and the Runtime Environment

This lesson explains the relationship between clients, containers, managed components, and the Jakarta EE runtime environment. Older Enterprise JavaBeans lessons often used the terms EJB client, EJB server, EJB container, and bean. Those terms are still useful historically, but they need to be interpreted through the broader Jakarta EE 11 programming model.

In older EJB architecture, the client called a business component through a client view, the container intercepted the call, and the bean executed the business logic. The server supplied the runtime environment around the container. That basic idea remains valuable: a managed component should not be treated as an ordinary unmanaged object. The Jakarta EE container surrounds the component and applies infrastructure services such as dependency injection, lifecycle management, security checks, transaction boundaries, interceptors, persistence context behavior, validation, messaging integration, and concurrency rules.

The modern difference is that Jakarta EE 11 is not centered only on remote Enterprise JavaBeans. Many applications now use CDI managed beans as the ordinary application component model, Jakarta RESTful Web Services as the explicit remote boundary, Jakarta Persistence for database work, Jakarta Transactions for transaction control, Jakarta Security for access control, and Jakarta Messaging or Jakarta Concurrency where asynchronous or managed background work is needed. Jakarta Enterprise Beans remain useful when their specialized services are required, but they are no longer the default answer for every business class.

From EJB Server to Jakarta EE Runtime

Older diagrams often placed an EJB server around an EJB container. That terminology reflected the distributed-object period of enterprise Java, when remote objects, ORBs, RMI, and RMI-IIOP were central topics. In a Jakarta EE 11 course, the better term is application server runtime or Jakarta EE runtime.

The runtime is the deployed environment that hosts the application. Depending on the product and profile, it may provide a web container, CDI container, Enterprise Beans container, REST runtime, persistence provider, transaction manager, security services, messaging integration, validation services, resource injection, naming, and managed concurrency. The application server coordinates these services so that application code does not have to implement them manually.

Examples of Jakarta EE runtimes include products such as WildFly, Payara, GlassFish, Open Liberty, and TomEE-style runtimes where applicable. The exact feature set depends on the runtime and profile. A plain servlet container is not the same thing as a full Jakarta EE server. For example, Apache Tomcat is widely used as a servlet container, but Enterprise Beans support requires an Enterprise Beans-capable runtime or an appropriate Jakarta EE product.

Modern Jakarta EE Runtime Architecture

The diagram modernizes the older EJB server picture. Instead of treating ORB, RMI, and DCOM as the primary integration model, it shows a Jakarta EE 11 runtime that receives calls through explicit application boundaries. A browser, REST client, Java client, service client, or messaging producer does not normally reach directly into a business object. It enters through a defined service boundary such as a REST resource, Servlet, WebSocket endpoint, Jakarta Pages page, Jakarta Faces view, or messaging listener.

Inside the runtime, CDI managed beans and Jakarta Enterprise Beans can collaborate with platform services. CDI supplies dependency injection and contextual component management. Jakarta Transactions defines transaction boundaries. Jakarta Persistence handles object-relational persistence. Jakarta Security provides authentication and authorization services. Jakarta Messaging supports asynchronous communication. Jakarta Bean Validation supplies declarative validation. Jakarta JSON Binding and JSON Processing support JSON-oriented service boundaries. This combination is the modern replacement for the older EJB-centered distributed-object diagram.

What the Container Does

A container is the managed environment that surrounds an application component. The container does not merely create an object and call a method. It applies a set of rules and services before, during, and after the component method executes.

For CDI managed beans, the CDI container controls contextual lifecycle, dependency injection, qualifiers, producers, events, interceptors, decorators, and scoped instances. For Jakarta Enterprise Beans, the Enterprise Beans container may also apply Enterprise Beans-specific services such as session bean lifecycle rules, pooling, timers, message-driven behavior, declarative transaction attributes, and container-managed concurrency. The Jakarta EE platform specification describes standard services that products must support and explains that containers provide the APIs components use to access those services. :contentReference[oaicite:2]{index=2}

The container exists so application developers do not have to hand-code the same infrastructure repeatedly. A business component should not need to know how to authenticate users, open and close transaction managers, look up every dependency manually, create every persistence context by hand, or implement every cross-cutting concern inside business methods. The container applies those concerns according to annotations, configuration, deployment rules, and platform contracts.

Clients and Service Boundaries

A client is anything that asks the application to perform work. In an older EJB lesson, the client was often shown as a remote Java program calling an Enterprise JavaBean. That can still happen in specialized cases, but it is not the dominant modern model.

In Jakarta EE 11, a client may be a browser, REST client, mobile application, Java client, another Jakarta EE component, another service, a message producer, or a scheduled process. The client might enter the application through a REST endpoint, Servlet, WebSocket endpoint, Jakarta Faces view, Jakarta Pages page, messaging destination, or local injected component.

The key point is that clients usually communicate through a defined service boundary. A REST client calls a URI with an HTTP method. A messaging client sends a message to a destination. A local Jakarta EE component may call an injected CDI service. A remote Enterprise Bean client may use a remote business interface when that architecture is required. Each of these approaches defines what the client is allowed to call and what the application promises to provide.

The Client View Contract

The client view contract defines the visible interface between the client and the application component. It answers the question: what can the client call, and what shape does that call take?

In older EJB architecture, the client view might have been a local business interface, remote business interface, home interface, or remote object reference. In modern Jakarta EE applications, the client view is often a REST API contract, a DTO and JSON payload structure, a messaging destination, a WebSocket message protocol, or a local injected service interface.

A REST client view contract may include the resource path, HTTP method, request body, response body, status codes, authentication requirements, and error representation. A messaging contract may include the destination name, message type, headers, payload format, retry behavior, and dead-letter strategy. A local component contract may be a Java interface or injected class. The form changes, but the architectural purpose remains: the client does not receive unlimited access to the internal component. It communicates through a defined view.

The Component Contract

The component contract defines the rules the managed component must follow so the container can manage it correctly. In older EJB language, this was sometimes called the bean-container contract. The bean supplied business methods and metadata, and the container supplied infrastructure services.

For Jakarta Enterprise Beans, the component contract may include annotations such as @Stateless, @Stateful, @Singleton, or @MessageDriven. It may also include business methods, lifecycle callbacks, transaction attributes, security annotations, timer methods, and messaging configuration.

For CDI managed beans, the component contract may include annotations such as @ApplicationScoped, @RequestScoped, @SessionScoped, @Dependent, @Inject, @Produces, @Observes, qualifiers, and interceptor bindings. CDI 4.1 is the Jakarta EE 11 CDI release and defines a model for obtaining objects in a way that improves reusability, testability, and maintainability compared with factories, constructors, or service locators. :contentReference[oaicite:3]{index=3}

Modern Jakarta EE Contract Model

The second diagram preserves one of the most important ideas from the older EJB object model: there are two contracts. The first contract is between the client and the container-facing view of the service. The second contract is between the managed component and the container.

This means the client is not supposed to bypass the container and manipulate the raw managed component as an ordinary object. The container stands between the client-facing view and the component implementation. That is how transaction rules, security checks, interceptors, validation, lifecycle rules, and persistence context behavior can be applied consistently.

CDI as the Modern Default Component Model

CDI is the central component model for many Jakarta EE 11 applications. CDI managed beans are usually the first choice for ordinary application services because they are lightweight, type-safe, testable, and well integrated with the platform.

A CDI managed bean may represent an application service, business service, repository collaborator, validation helper, event producer, event observer, REST resource collaborator, or integration service. It can be injected into other components and can receive dependencies through @Inject. Its lifecycle can be controlled through scopes such as application, request, session, or dependent scope.

In many modern applications, a Jakarta REST resource receives a request and delegates business work to CDI managed beans. Those CDI beans may then use Jakarta Persistence, Jakarta Transactions, validation, messaging, or external service clients. This is the ordinary shape of many current Jakarta EE applications.

When Jakarta Enterprise Beans Still Matter

Jakarta Enterprise Beans remain part of the Jakarta EE ecosystem. The Jakarta Enterprise Beans specification defines an architecture for component-based business applications, and Jakarta EE 11 includes Enterprise Beans Lite in its technology set. :contentReference[oaicite:4]{index=4}

Enterprise Beans are still relevant when an application needs Enterprise Beans-specific services. Examples include stateless session services, stateful conversational services, singleton services with container-managed concurrency, message-driven beans, timers, EJB-style declarative transaction attributes, or compatibility with an existing EJB-based application.

The practical rule is that CDI managed beans are usually the first choice for ordinary application services. Jakarta Enterprise Beans should be selected when their specialized container services are actually needed or when an existing architecture already depends on them.

Modern Equivalent Mapping

Physical Runtime versus Logical Architecture

The older lesson asked what form these entities have in the “physical universe of the computer.” That is still a useful question. The answer is that many of these entities are logical roles, not separate physical programs.

A client, service contract, container, managed component, transaction manager, persistence provider, and runtime may be shown as separate boxes in a diagram, but the implementation can vary by vendor and deployment model. A Jakarta EE product may combine several services into one runtime process. Another product may modularize services differently. A cloud deployment may place the application runtime in a container image while external systems such as databases, message brokers, identity providers, and REST services run elsewhere.

The important point is not that every diagram box maps to a separate executable file. The important point is the separation of responsibilities. The client uses a contract. The container applies services. The managed component contains business logic. The runtime hosts the containers and coordinates platform services. External systems provide data, identity, messaging, or integration endpoints.

Learning Objectives

After completing this lesson, students should be able to:

1. Describe the role of clients, containers, managed components, and application servers in Jakarta EE 11.
2. Explain why clients do not invoke managed components as raw unmanaged objects.
3. Define the client view contract.
4. Define the component or bean-container contract.
5. Explain what services the Jakarta EE container provides.
6. Distinguish the application server runtime from the logical container.
7. Explain how CDI managed beans and Jakarta Enterprise Beans relate.
8. Identify when CDI is the preferred component model.
9. Identify when Jakarta Enterprise Beans are still useful.
10. Map legacy EJB architecture diagrams to modern Jakarta EE 11 terminology.

Summary

Older EJB architecture described a relationship among clients, servers, containers, and beans. The client called a view, the container intercepted the call, the bean performed business logic, and the server supplied the runtime environment. That architecture taught an important lesson: enterprise components are managed components, not ordinary unmanaged objects.

Jakarta EE 11 preserves the value of container-managed services but broadens the programming model. CDI managed beans are now the ordinary component model for many application services. Jakarta Enterprise Beans remain available when specialized Enterprise Beans services are needed. Clients usually enter through explicit boundaries such as REST endpoints, messaging destinations, WebSocket endpoints, local interfaces, or remote business interfaces where appropriate.

The modern way to understand the lesson is through contracts. The client view contract defines what the client can call. The component contract defines how the managed component participates in the container. The Jakarta EE runtime hosts the containers and supplies the services that make enterprise applications secure, transactional, maintainable, and scalable.