| Lesson 9 | Development and Deployment Responsibilities |
| Objective | Explain how Jakarta EE 11 defines development and deployment responsibilities and how modern teams fulfill them. |
Jakarta EE 11 Development and Deployment Responsibilities
Jakarta EE applications depend on more than application code. Components must be implemented, packaged, configured for a target environment, deployed to a compatible runtime, and operated after release. The Jakarta EE specifications describe these activities as roles. A role is a logical set of responsibilities and contracts, not a required job title or a rule about how a company must organize its staff.
One developer can perform several roles in a small project. In a larger organization, application developers, build engineers, platform engineers, security teams, database administrators, release engineers, and site reliability engineers may divide the same work. A CI/CD pipeline can automate many steps, but the people and policies behind that pipeline still own the decisions. The role model remains useful because it identifies what each stage receives, what it must produce, and which assumptions must cross from one stage to the next.
Roles Are Responsibility Boundaries
The Jakarta EE 11 Platform specification defines platform-wide roles. The Jakarta Enterprise Beans 4.0 specification defines a related set focused on Enterprise Beans. These are complementary views. The platform roles cover all Jakarta EE component types, while the Enterprise Beans roles describe the contracts around session beans, message-driven beans, and their container.
The boundaries separate portable application intent from product implementation and environment configuration. A component can declare that it needs a data source, a transaction, or a security role without embedding a production database password or a product-specific deployment command. The assembler preserves those requirements in an artifact, the deployer maps them to a real environment, and the runtime provides the requested container services.
Jakarta EE 11 Platform Roles
Jakarta EE 11 identifies seven platform roles. The names are formal, but the modern implementation column shows how their work often appears in a current software delivery organization.
| Jakarta EE role | Specification responsibility | Typical modern implementation | Primary output or concern |
|---|---|---|---|
| Jakarta EE Product Provider | Implements and supplies a Jakarta EE product, its supported containers, APIs, deployment capabilities, and management facilities. | Application-server vendor or open-source runtime project and distribution. | A compatible runtime with documented deployment and management behavior. |
| Application Component Provider | Develops application components and declares their requirements. | Application developer or feature team. | Source, tests, classes, annotations, descriptors, and portable dependency declarations. |
| Application Assembler | Combines components or modules and supplies assembly information. | Build or release engineering performed through Maven, Gradle, and CI. | A versioned WAR, JAR, or multi-module EAR ready for deployment. |
| Deployer | Installs and configures an application for a specific operational environment. | Release engineer, platform engineer, deployment pipeline, or cloud automation. | A configured, started, and verified application with resolved dependencies. |
| System Administrator | Administers infrastructure and oversees the runtime well-being of deployed applications. | Operations, platform engineering, cloud engineering, or SRE team. | Availability, monitoring, patching, capacity, recovery, and infrastructure health. |
| Tool Provider | Supplies development, packaging, deployment, management, or monitoring tools. | IDE, build-tool, testing, deployment, and observability projects or vendors. | Tools that support repeatable work across the application lifecycle. |
| System Component Provider | Supplies system-level components integrated through Jakarta EE contracts. | Resource-adapter or policy-provider project or vendor. | Connector resource adapters and other infrastructure integration components. |
Component Development and Assembly
An Application Component Provider may create CDI managed beans, Jakarta REST resources, servlets, Jakarta Persistence entities, Jakarta Faces components, session beans, or message-driven beans. Its output includes the code and metadata needed to describe the component. That metadata can declare injection points, resource references, security constraints, transaction behavior, persistence units, interceptors, and component names.
The Application Assembler turns components into a coherent deployable unit. Modern builds usually perform this work automatically: compile code, run tests, include dependencies, merge resources, validate descriptors, and create a versioned artifact. A single WAR can be a complete application. A separate Enterprise Beans JAR is useful for an Enterprise Beans module, while an EAR is appropriate when several modules must be assembled and deployed together. Jakarta EE does not require every complete application to use an EAR.
Deployment and Operation
The Deployer adapts a portable artifact to a real environment. That work can include binding logical resource names to data sources or messaging destinations, mapping application roles to users or groups, supplying external configuration, selecting runtime settings, deploying the artifact, starting it, and running health or acceptance checks. The specification does not require a graphical administration tool. A server command line, administrative API, CI/CD pipeline, container platform, or infrastructure automation can perform the deployment.
The System Administrator is responsible for the environment in which the deployed application runs. Current responsibilities commonly include runtime configuration, operating-system and server patching, certificates, secrets, network access, monitoring, alerting, capacity, backups, recovery, and incident response. Titles such as platform engineer, cloud engineer, operations engineer, and site reliability engineer are practical mappings, not Jakarta EE specification roles.
Jakarta Enterprise Beans Roles
Jakarta Enterprise Beans uses six roles to describe the contracts specific to Enterprise Beans. Three roles overlap with the platform model: Application Assembler, Deployer, and System Administrator. The other three identify who produces beans and who supplies their container and server environment.
| Enterprise Beans role | Enterprise Beans responsibility | Relationship to platform or modern team |
|---|---|---|
| Enterprise Bean Provider | Implements bean classes, business methods, client views when needed, and declarative component metadata. | A component developer specializing in session beans or message-driven beans. |
| Application Assembler | Combines beans and other components, resolves application-level relationships, and produces deployable modules or applications. | Often the same team as the Bean Provider, with assembly automated by the build. |
| Deployer | Resolves bean dependencies and configures the packaged application for one Enterprise Beans runtime environment. | A release or platform responsibility, frequently executed by a pipeline. |
| Enterprise Beans Server Provider | Supplies the underlying execution environment and lower-level services used by the container. | Usually part of the same application-server product as the container. |
| Enterprise Beans Container Provider | Supplies the container that manages bean instances and implements the Enterprise Beans component contract. | The runtime provider that delivers lifecycle, injection, transactions, security, concurrency, timers, naming, and related services. |
| System Administrator | Configures infrastructure and manages the running Enterprise Beans environment and applications. | The operations, platform, or SRE responsibility for runtime health. |
The Enterprise Bean Provider writes business logic, but its responsibility is not limited to method bodies. The provider also declares how the component expects container services to behave. An annotation or descriptor can specify transaction attributes, security permissions, resource references, interceptor bindings, timer behavior, or concurrency rules. The provider declares the intent; the compatible container implements and enforces it at runtime.
The Container Provider and Server Provider are separate logical roles because their contracts describe different layers. They do not have to be separate companies. A modern application server commonly supplies both layers as one product. Likewise, one programmer can be both the Enterprise Bean Provider and Application Assembler. Client code is application code and does not require a separate formal "Client Programmer" role in the current six-role Enterprise Beans model.
Contracts Between Application and Environment
Annotations and optional deployment descriptors communicate requirements from component development and assembly to deployment tooling. Common declarations identify resources, security roles, transaction policies, persistence units, environment entries, component dependencies, and interceptors. XML descriptors can supplement or override annotation metadata where the applicable specification permits, but annotations do not remove the need for deployment configuration.
Consider an application that declares a persistence unit using a logical data source name. The Application Component Provider writes the entity and service code and declares that dependency. The Application Assembler packages the persistence metadata in the application. The Deployer binds the logical name to a production data source without putting production credentials in the artifact. The runtime supplies persistence and transaction integration. The administrator manages database connectivity, credentials, monitoring, patching, and backups.
Security has a similar shared boundary. A component provider declares application roles and protects methods or endpoints. The assembler checks that role names are consistent across modules. The deployer maps those roles to identities or groups in the target environment. The container enforces the policy, while administrators and security operations maintain identity integration, certificates, secrets, audit data, and runtime patches. Security is therefore shared work, not a task handed entirely to one role.
| Boundary | Portable or environment-specific contents | Examples |
|---|---|---|
| Application artifact | Portable business logic, component metadata, tests, and declared dependencies. | Classes, annotations, descriptors, persistence-unit names, security roles, and resource references. |
| Jakarta EE runtime | Standard APIs, containers, and the services implemented by the selected product or profile. | Lifecycle management, dependency injection, transaction coordination, security enforcement, naming, and managed concurrency. |
| Operational environment | Concrete infrastructure and settings for a deployment target. | Data sources, brokers, identity stores, secrets, certificates, network policy, capacity, observability, and backups. |
The exact boundary varies by runtime and deployment model, but portable applications should avoid hard-coding environment-specific endpoints, credentials, and vendor commands. Jakarta EE standardizes the application-to-platform contract; it does not make every product's tuning, deployment command, or management interface identical.
From Source Code to a Running Service
A modern delivery workflow maps naturally to the formal responsibilities:
- Design and implement: component providers write code, tests, and portable metadata.
- Compile and test: the build verifies behavior and catches contract violations early.
- Assemble and package: the assembler produces a versioned WAR, JAR, or EAR.
- Publish and promote: the immutable artifact moves through an artifact repository and approved environments.
- Configure: the deployer supplies environment settings, identity mappings, secrets references, and resource bindings.
- Deploy and verify: automation installs the artifact, starts it, and runs health and acceptance checks.
- Operate: administrators and platform teams monitor, patch, scale, back up, recover, and support the service.
CI/CD automates transitions and creates a repeatable audit trail, but it does not redefine Jakarta EE roles. A pipeline acts on behalf of the teams that own component quality, artifact composition, deployment policy, security approval, and operational health. The same principle applies to DevOps, GitOps, cloud engineering, and SRE practices: they are ways to perform the work, not additional roles defined by Jakarta EE.
Tomcat 11 and Full Platform Responsibilities
Tomcat 11 is a Servlet container that implements the Jakarta web specifications associated with its release and commonly deploys WAR files. It is not a full Jakarta EE 11 Platform implementation. Plain Tomcat does not provide the complete Enterprise Beans container or every integrated Platform service described in this lesson.
A web application can deploy successfully to Tomcat when it stays within Tomcat's supported web technologies and supplies any additional libraries and configuration it needs. An application that depends on full-platform Enterprise Beans and integrated Platform services should use a compatible Jakarta EE runtime. The JavaDeploy site demonstrates a web-application deployment model, while this lesson describes the broader responsibility model used across Jakarta EE products and components.
Summary
Jakarta EE roles make ownership and contracts explicit. Component providers express portable application intent, assemblers create deployable artifacts, deployers adapt those artifacts to a target environment, product and component providers supply the runtime and tools, and administrators keep the system healthy. Enterprise Beans applies the same idea to bean, container, and server responsibilities.
Modern teams may combine these roles and automate much of their work, but the boundaries remain valuable. They keep business logic separate from runtime implementation and environment configuration, improve portability, and make releases easier to test, audit, operate, and recover.