Overview

Although other enterprise application models require platform-specific security measures in each application, the Jakarta EE security environment enables security constraints to be defined at deployment time. The Jakarta EE platform makes applications portable to a wide variety of security implementations by shielding application developers from the complexity of implementing security features.

The Jakarta EE platform provides standard declarative access control rules that are defined by the developer and interpreted when the application is deployed on the server. Jakarta EE also provides standard login mechanisms so that application developers do not have to implement these mechanisms in their applications. The same application works in a variety of security environments without changing the source code.

Jakarta EE applications are made up of components. A Jakarta EE component is a self-contained functional software unit that is assembled into a Jakarta EE application with its related classes and files and that communicates with other components.

The Jakarta EE specification defines the following Jakarta EE components:

Jakarta EE components are written in the Java programming language and are compiled in the same way as any program in the language. The differences between Jakarta EE components and "standard" Java classes are that Jakarta EE components are assembled into a Jakarta EE application, they are verified to be well formed and in compliance with the Jakarta EE specification, and they are deployed to production, where they are run and managed by the Jakarta EE server.

A Jakarta EE client is usually either a web client or an application client.

Jakarta EE web components are either servlets or web pages created using Jakarta Faces technology and/or Jakarta Server Pages technology. Servlets are Java programming language classes that dynamically process requests and construct responses. Jakarta Server Pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. Jakarta Faces technology builds on servlets and Jakarta Server Pages technology and provides a user interface component framework for web applications.

Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the Jakarta EE specification. Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components.

As shown in Figure 3, “Web Tier and Jakarta EE Applications”, the web tier, like the client tier, might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.

Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in either the business tier or the web tier. Figure 4, “Business and EIS Tiers” shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.

The enterprise information system tier handles EIS software and includes enterprise infrastructure systems, such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. For example, Jakarta EE application components might need access to enterprise information systems for database connectivity.

Containers are the interface between a component and the low-level, platform-specific functionality that supports the component. Before it can be executed, a web, enterprise bean, or application client component must be assembled into a Jakarta EE module and deployed into its container.

The assembly process involves specifying container settings for each component in the Jakarta EE application and for the Jakarta EE application itself. Container settings customize the underlying support provided by the Jakarta EE server, including such services as security, transaction management, Java Naming and Directory Interface (JNDI) API lookups, and remote connectivity. Here are some of the highlights.

Because the Jakarta EE architecture provides configurable services, components within the same application can behave differently based on where they are deployed. For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.

The container also manages nonconfigurable services, such as enterprise bean and servlet lifecycles, database connection resource pooling, data persistence, and access to the Jakarta EE platform APIs (see Jakarta EE APIs).

The deployment process installs Jakarta EE application components in the Jakarta EE containers, as illustrated in Figure 5, “Jakarta EE Server and Containers”.

The server and containers are as follows:

Extensible Markup Language (XML) is a cross-platform, extensible, text-based standard for representing data. Parties that exchange XML data can create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.

For example, a web service can use XML and a schema to produce price lists, and companies that receive the price lists and schema can have their own style sheets to handle the data in a way that best suits their needs. Here are examples.

Client requests and web service responses are transmitted as Simple Object Access Protocol (SOAP) messages over HTTP to enable a completely interoperable exchange between clients and web services, all running on different platforms and at various locations on the Internet. HTTP is a familiar request-and-response standard for sending messages over the Internet, and SOAP is an XML-based protocol that follows the HTTP request-and-response model.

The SOAP portion of a transported message does the following:

The Web Services Description Language (WSDL) is a standardized XML format for describing network services. The description includes the name of the service, the location of the service, and ways to communicate with the service. WSDL service descriptions can be published on the Web. Eclipse GlassFish Server provides a tool for generating the WSDL specification of a web service that uses remote procedure calls to communicate with clients.

An enterprise bean component, or enterprise bean, is a body of code that has fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Jakarta EE server.

Enterprise beans are either session beans or message-driven beans.

The Jakarta EE 9 platform requires Jakarta Enterprise Beans 4.0 and Jakarta Interceptors 2.0.

Jakarta Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.

In the Jakarta EE 8 platform, new Jakarta Servlet technology features include the following:

The Jakarta EE 9 platform requires Servlet 5.0.

Jakarta Faces technology is a user interface framework for building web applications. The main components of Jakarta Faces technology are as follows:

The following features support the GUI components:

All this functionality is available using standard Java APIs and XML-based configuration files.

In the Jakarta EE 8 platform, new features of Jakarta Faces technology include the following:

The Jakarta EE 9 platform requires Jakarta Faces 3.0 and Jakarta Expression Language 4.0.

Jakarta Server Pages technology lets you put snippets of servlet code directly into a text-based document. A Jakarta Server Pages page is a text-based document that contains two types of text:

The Jakarta Server Pages technology is derived from and compatible with the JavaServer Pages (JSP) technology.

For information about JSP technology, see The Java EE 5 Tutorial at https://docs.oracle.com/javaee/5/tutorial/doc/.

The Jakarta EE 9 platform requires Jakarta Server Pages 3.0 for compatibility with earlier releases but recommends the use of Facelets as the display technology in new applications.

The Jakarta Standard Tag Library encapsulates core functionality common to many Jakarta Server Pages applications. Instead of mixing tags from numerous vendors in your Jakarta Server Pages applications, you use a single, standard set of tags. This standardization allows you to deploy your applications on any Jakarta Server Pages container that supports Jakarta Standard Tag Library and makes it more likely that the implementation of the tags is optimized.

Jakarta Standard Tag Library has iterator and conditional tags for handling flow control, tags for manipulating XML documents, internationalization tags, tags for accessing databases using SQL, and tags for commonly used functions.

The Jakarta EE 9 platform requires Jakarta Standard Tag Library 2.0.

Jakarta Persistence is a Java standards–based solution for persistence. Persistence uses an object/relational mapping approach to bridge the gap between an object-oriented model and a relational database. The Jakarta Persistence can also be used in Java SE applications outside of the Jakarta EE environment. Jakarta Persistence consists of the following areas:

The Jakarta EE 9 platform requires Jakarta Persistence 3.0.

Jakarta Transactions provides a standard interface for demarcating transactions. The Jakarta EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the Jakarta Transactions to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.

The Jakarta EE 9 platform requires Jakarta Transactions 2.0.

Jakarta RESTful Web Services defines APIs for the development of web services built according to the Representational State Transfer (REST) architectural style. A Jakarta RESTful application is a web application that consists of classes packaged as a servlet in a WAR file along with required libraries.

In the Jakarta EE 8 platform, new RESTful web services features include the following:

The Jakarta EE 9 platform requires Jakarta RESTful Web Services 3.0.

Jakarta Managed Beans, lightweight container-managed objects (POJOs) with minimal requirements, support a small set of basic services, such as resource injection, lifecycle callbacks, and interceptors. Managed Beans represent a generalization of the managed beans specified by Jakarta Faces technology and can be used anywhere in a Jakarta EE application, not just in web modules.

The Jakarta Managed Beans specification is part of the Jakarta EE 9 platform specification. The Jakarta EE 9 platform requires Jakarta Managed Beans 2.0.

Jakarta Contexts and Dependency Injection (CDI) defines a set of contextual services, provided by Jakarta EE containers, that make it easy for developers to use enterprise beans along with Jakarta Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but typesafe way.

In the Jakarta EE 8 platform, new CDI features include the following:

The Jakarta EE 9 platform requires Jakarta Contexts and Dependency Injection 3.0.

Jakarta Dependency Injection defines a standard set of annotations (and one interface) for use on injectable classes.

In the Jakarta EE platform, CDI provides support for Dependency Injection. Specifically, you can use injection points only in a CDI-enabled application.

The Jakarta EE 9 platform requires Jakarta Dependency Injection 2.0.

The Jakarta Bean Validation specification defines a metadata model and API for validating data in JavaBeans components. Instead of distributing validation of data over several layers, such as the browser and the server side, you can define the validation constraints in one place and share them across the different layers.

In the Jakarta EE 8 platform, new Jakarta Bean Validation features include the following:

The Jakarta EE 9 platform requires Jakarta Bean Validation 3.0.

Jakarta Messaging is a messaging standard that allows Jakarta EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.

The Jakarta EE 9 platform requires Jakarta Messaging 3.0.

The Jakarta Connectors is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Jakarta EE product. A resource adapter is a software component that allows Jakarta EE application components to access and interact with the underlying resource manager of the EIS. Because a resource adapter is specific to its resource manager, a different resource adapter typically exists for each type of database or enterprise information system.

The Jakarta Connectors also provides a performance-oriented, secure, scalable, and message-based transactional integration of Jakarta EE platform-based web services with existing EISs that can be either synchronous or asynchronous. Existing applications and EISs integrated through the Jakarta Connectors into the Jakarta EE platform can be exposed as XML-based web services by using Jakarta XML Web Services and Jakarta EE component models. Thus Jakarta XML Web Services and the Jakarta Connectors are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.

The Jakarta EE 9 platform requires Jakarta Connectors 2.0.

Jakarta EE applications use the Jakarta Mail to send email notifications. The Jakarta Mail has two parts:

The Jakarta EE platform includes the Jakarta Mail with a service provider that allows application components to send Internet mail.

The Jakarta EE 9 platform requires Jakarta Mail 2.0.

The Jakarta Authorization specification defines a contract between a Jakarta EE application server and an authorization policy provider. All Jakarta EE containers support this contract.

The Jakarta Authorization specification defines java.security.Permission classes that satisfy the Jakarta EE authorization model. The specification defines the binding of container-access decisions to operations on instances of these permission classes. It defines the semantics of policy providers that use the new permission classes to address the authorization requirements of the Jakarta EE platform, including the definition and use of roles.

The Jakarta EE 9 platform requires Jakarta Authorization 2.0.

The Jakarta Authentication specification defines a service provider interface (SPI) by which authentication providers that implement message authentication mechanisms may be integrated in client or server message-processing containers or runtimes. Authentication providers integrated through this interface operate on network messages provided to them by their calling containers. The authentication providers transform outgoing messages so that the source of each message can be authenticated by the receiving container, and the recipient of the message can be authenticated by the message sender. Authentication providers authenticate each incoming message and return to their calling containers the identity established as a result of the message authentication.

The Jakarta EE 9 platform requires Jakarta Authentication 2.0.

Jakarta Security specification defines portable, plug-in interfaces for HTTP authentication and identity stores, and an injectable SecurityContext interface that provides an API for programmatic security.

Implementations of the HttpAuthenticationMechanism interface can be used to authenticate callers of web applications. An application can supply its own HttpAuthenticationMechanism, or use one of the default implementations provided by the container.

Implementations of the IdentityStore interface can be used to validate user credentials and retrieve group information. An application can provide its own IdentityStore, or use the built in LDAP or Database store.

The HttpAuthenticationMechanism and IdentityStore APIs provide an advantage over container-provided implementations in that they allow an application to control the authentication process, and the identity stores used for authentication, in a standard, portable way.

The SecurityContext API is intended for use by application code to query and interact with the current security context. The specification also provides for default group-to-role mapping, and defines a principal type called CallerPrincipal that can represent the identity of an application caller.

The Jakarta EE 9 platform requires Jakarta Security 2.0.

WebSocket is an application protocol that provides full-duplex communications between two peers over TCP. Jakarta WebSocket enables Jakarta EE applications to create endpoints using annotations that specify the configuration parameters of the endpoint and designate its lifecycle callback methods.

The Jakarta EE 9 platform requires Jakarta WebSocket 2.0.

JavaScript Object Notation (JSON) is a text-based data exchange format derived from JavaScript that is used in web services and other connected applications. Jakarta JSON Processing enables Jakarta EE applications to parse, transform, and query JSON data using the object model or the streaming model.

In the Jakarta EE 8 platform, new features of Jakarta JSON Processing include support for the following:

The Jakarta EE 9 platform requires Jakarta JSON Processing 2.0.

Jakarta JSON Binding provides a binding layer for converting Java objects to and from JSON messages. Jakarta JSON Binding also supports the ability to customize the default mapping process used in this binding layer through the use of Java annotations for a given field, JavaBean property, type or package, or by providing an implementation of a property naming strategy.

The Jakarta EE 9 platform requires Jakarta JSON Binding 2.0.

Jakarta Concurrency is a standard API for providing asynchronous capabilities to Jakarta EE application components through the following types of objects: managed executor service, managed scheduled executor service, managed thread factory, and context service.

The Jakarta EE 9 platform requires Jakarta Concurrency 2.0.

Batch jobs are tasks that can be executed without user interaction. The Batch Applications for the Java Platform specification is a batch framework that provides support for creating and running batch jobs in Java applications. The batch framework consists of a batch runtime, a job specification language based on XML, a Java API to interact with the batch runtime, and a Java API to implement batch artifacts.

The Jakarta EE 9 platform requires Jakarta Batch 2.0.

The Jakarta Activation is used by the Jakarta Mail. Jakarta Activation provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBeans component to perform those operations.

The Jakarta EE 9 platform requires Jakarta Activation 2.0.

The Jakarta XML Binding provides a convenient way to bind an XML schema to a representation in Java language programs. XML Binding can be used independently or in combination with Jakarta XML Web Services, in which case it provides a standard data binding for web service messages. All Jakarta EE application client containers, web containers, and Jakarta Enterprise Beans containers support the XML Binding API.

The Jakarta EE 9 platform requires Jakarta XML Binding 3.0.

The Jakarta XML Web Services specification provides support for web services that use the Jakarta XML Binding API for binding XML data to Java objects. The Jakarta XML Web Services specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints. The Enterprise Web Services specification describes the deployment of Jakarta XML Web Services based services and clients. The Jakarta Enterprise Beans and Jakarta Servlet specifications also describe aspects of such deployment. Jakarta XML Web Services based applications can be deployed using any of these deployment models.

The Jakarta XML Web Services specification describes the support for message handlers that can process message requests and responses. In general, these message handlers execute in the same container and with the same privileges and execution context as the Jakarta XML Web Services client or endpoint component with which they are associated. These message handlers have access to the same JNDI namespace as their associated component. Custom serializers and deserializers, if supported, are treated in the same way as message handlers.

The Jakarta EE 9 platform requires Jakarta XML Web Services 3.0.

The Jakarta SOAP with Attachments is a low-level API on which Jakarta XML Web Services depends. Jakarta SOAP with Attachments enables the production and consumption of messages that conform to the SOAP 1.1 and 1.2 specifications and the Jakarta SOAP with Attachments note. Most developers do not use the Jakarta SOAP with Attachments, instead using the higher-level Jakarta XML Web Services API.

Annotations enable a declarative style of programming in the Java platform.

The Jakarta EE 9 platform requires Jakarta Annotations 2.0.

The Java Database Connectivity (JDBC) API lets you invoke SQL commands from Java programming language methods. You use the JDBC API in an enterprise bean when you have a session bean access the database. You can also use the JDBC API from a servlet or a JSP page to access the database directly without going through an enterprise bean.

The JDBC API has two parts:

The Jakarta EE 9 platform requires JDBC 4.1.

The Java Naming and Directory Interface (JNDI) API provides naming and directory functionality, enabling applications to access multiple naming and directory services, such as LDAP, DNS, and NIS. The JNDI API provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Using JNDI, a Jakarta EE application can store and retrieve any type of named Java object, allowing Jakarta EE applications to coexist with many legacy applications and systems.

Jakarta EE naming services provide application clients, enterprise beans, and web components with access to a JNDI naming environment. A naming environment allows a component to be customized without the need to access or change the component’s source code. A container implements the component’s environment and provides it to the component as a JNDI naming context.

The naming environment provides four logical namespaces: java:comp, java:module, java:app, and java:global for objects available to components, modules, or applications or shared by all deployed applications. A Jakarta EE component can access named system-provided and user-defined objects. The names of some system-provided objects, such as a default JDBC DataSource object, a default Messaging connection factory, and a Transactions UserTransaction object, are stored in the java:comp namespace. The Jakarta EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC DataSource objects, and messaging destinations.

A Jakarta EE component can also locate its environment naming context by using JNDI interfaces. A component can create a javax.naming.InitialContext object and look up the environment naming context in InitialContext under the name java:comp/env. A component’s naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.

The Java API for XML Processing (JAXP), part of the Java SE platform, supports the processing of XML documents using Document Object Model (DOM), Simple API for XML (SAX), and Extensible Stylesheet Language Transformations (XSLT). JAXP enables applications to parse and transform XML documents independently of a particular XML-processing implementation.

JAXP also provides namespace support, which lets you work with schemas that might otherwise have naming conflicts. Designed to be flexible, JAXP lets you use any XML-compliant parser or XSL processor from within your application and supports the Worldwide Web Consortium (W3C) schema. You can find information on the W3C schema at https://www.w3.org/XML/Schema.

The Java Authentication and Authorization Service (JAAS) provides a way for a Jakarta EE application to authenticate and authorize a specific user or group of users to run it.

JAAS is a Java programming language version of the standard Pluggable Authentication Module (PAM) framework, which extends the Java platform security architecture to support user-based authorization.