Jakarta EE Platform Team, https://projects.eclipse.org/projects/ee4j.jakartaee-platform · jakarta.ee

Specification: Jakarta EE Platform
Version: 9.1
Status: Final Release
Release: April 27, 2021

Copyright

Copyright (c) 2018, 2020 Eclipse Foundation.

Eclipse Foundation Specification License

By using and/or copying this document, or the Eclipse Foundation document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:

Permission to copy, and distribute the contents of this document, or the Eclipse Foundation document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:

  • link or URL to the original Eclipse Foundation document.

  • All existing copyright notices, or if one does not exist, a notice (hypertext is preferred, but a textual representation is permitted) of the form: "Copyright (c) [$date-of-document] Eclipse Foundation, Inc. <<url to this license>>"

Inclusion of the full text of this NOTICE must be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.

No right to create modifications or derivatives of Eclipse Foundation documents is granted pursuant to this license, except anyone may prepare and distribute derivative works and portions of this document in software that implements the specification, in supporting materials accompanying such software, and in documentation of such software, PROVIDED that all such works include the notice below. HOWEVER, the publication of derivative works of this document for use as a technical specification is expressly prohibited.

The notice is:

"Copyright (c) [$date-of-document] Eclipse Foundation. This software or document includes material copied from or derived from [title and URI of the Eclipse Foundation specification document]."

Disclaimers

THIS DOCUMENT IS PROVIDED "AS IS," AND THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE COPYRIGHT HOLDERS AND THE ECLIPSE FOUNDATION WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.

The name and trademarks of the copyright holders or the Eclipse Foundation may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.

In Memory Of Bill Shannon

1. Introduction

Enterprises today need to extend their reach, reduce their costs, and lower the response times of their services to customers, employees, and suppliers.

Typically, applications that provide these services must combine existing enterprise information systems (EISs) with new business functions that deliver services to a broad range of users. The services need to be:

  • Highly available, to meet the needs of today’s global business environment.

  • Secure, to protect the privacy of users and the integrity of the enterprise.

  • Reliable and scalable, to ensure that business transactions are accurately and promptly processed.

In most cases, enterprise services are implemented as multitier __ applications. The middle tiers integrate existing EISs with the business functions and data of the new service. Maturing web technologies are used to provide first tier users with easy access to business complexities, and eliminate or drastically reduce user administration and training.

The Jakarta™ EE Platform reduces the cost and complexity of developing multitier, enterprise services. Jakarta EE applications can be rapidly deployed and easily enhanced as the enterprise responds to competitive pressures.

Jakarta EE achieves these benefits by defining a standard architecture with the following elements:

  • Jakarta EE Platform - A standard platform for hosting Jakarta EE applications.

  • Jakarta EE Compatibility Test Suite - A suite of compatibility tests for verifying that a Jakarta EE platform product complies with the Jakarta EE platform standard.

  • Jakarta Compatible Implementations - Certified implementations for building and deploying Jakarta EE applications.

This document is the Jakarta EE platform specification. It sets out the requirements that a Jakarta EE platform product must meet.

1.1. Acknowledgements for the Initial Version of Java EE

This specification is the work of many people. Vlada Matena wrote the first draft as well as the Transaction Management and Naming chapters. Sekhar Vajjhala, Kevin Osborn, and Ron Monzillo wrote the Security chapter. Hans Hrasna wrote the Application Assembly and Deployment chapter. Seth White wrote the JDBC API requirements. Jim Inscore, Eric Jendrock, and Beth Stearns provided editorial assistance. Shel Finkelstein, Mark Hapner, Danny Coward, Tom Kincaid, and Tony Ng provided feedback on many drafts. And of course this specification was formed and molded based on conversations with and review feedback from our many industry partners.

1.2. Acknowledgements for Java EE Version 1.3

Version 1.3 of this specification grew out of discussions with our partners during the creation of version 1.2, as well as meetings with those partners subsequent to the final release of version 1.2. Version 1.3 was created under the Java Community Process as JSR-058. The JSR-058 Expert Group included representatives from the following companies and organizations: Allaire, BEA Systems, Bluestone Software, Borland, Bull S.A., Exoffice, Fujitsu Limited, GemStone Systems, Inc., IBM, Inline Software, IONA Technologies, iPlanet, jGuru.com, Orion Application Server, Persistence, POET Software, SilverStream, Sun, and Sybase. In addition, most of the people who helped with the previous version continued to help with this version, along with Jon Ellis and Ram Jeyaraman. Alfred Towell provided significant editorial assistance with this version.

1.3. Acknowledgements for Java EE Version 1.4

Version 1.4 of this specification was created under the Java Community Process as JSR-151. The JSR-151 Expert Group included the following members: Larry W. Allen (SilverStream Software), Karl Avedal (Individual), Charlton Barreto (Borland Software Corporation), Edward Cobb (BEA), Alan Davies (SeeBeyond Technology Corporation), Sreeram Duvvuru (iPlanet), B.J. Fesq (Individual), Mark Field (Macromedia), Mark Hapner (Sun Microsystems, Inc.), Pierce Hickey (IONA), Hemant Khandelwal (Pramati Technologies), Jim Knutson (IBM), Elika S. Kohen (Individual), Ramesh Loganathan (Pramati Technologies), Jasen Minton (Oracle Corporation), Jeff Mischkinsky (Oracle Corporation), Richard Monson-Haefel (Individual), Sean Neville (Macromedia), Bill Shannon (Sun Microsystems, Inc.), Simon Tuffs (Lutris Technologies), Jeffrey Wang (Persistence Software, Inc.), and Ingo Zenz (SAP AG). My colleagues at Sun provided invaluable assistance: Umit Yalcinalp converted the deployment descriptors to XML Schema; Tony Ng and Sanjeev Krishnan helped with transaction requirements; Jonathan Bruce helped with JDBC requirements; Suzette Pelouch, Eric Jendrock, and Ian Evans provided editorial assistance. Thanks also to all the external reviewers, including Jeff Estefan (Adecco Technical Services).

1.4. Acknowledgements for Java EE Version 5

Version 5 (originally known as version 1.5) of this specification was created under the Java Community Process as JSR-244. The JSR-244 Expert Group included the following members: Kilinc Alkan (Individual), Rama Murthy Amar Pratap (Individual), Charlton Barreto (Individual), Michael Bechauf (SAP AG), Florent Benoit (INRIA), Bill Burke (JBoss, Inc.), Muralidharan Chandrasekaran (Individual), Yongmin Chen (Novell, Inc.), Jun Ho Cho (TmaxSoft), Ed Cobb (BEA), Ugo Corda (SeeBeyond Technology Corporation), Scott Crawford (Individual), Arulazi Dhesiaseelan (Hewlett-Packard Company), Bill Dudney (Individual), Francois Exertier (INRIA), Jeff Genender (The Apache Software Foundation), Evan Ireland (Sybase, Inc.), Vishy Kasar (Borland Software Corporation), Michael Keith (Oracle Corporation), Wonseok Kim (TmaxSoft, Inc.), Jim Knutson (IBM), Elika Kohen (Individual), Felipe Leme (Individual), Geir Magnusson Jr. (The Apache Software Foundation), Scott Marlow (Novell, Inc.), Jasen Minton (Oracle Corporation), Jishnu Mitra (Borland Software Corp), David Morandi (E.piphany), Nathan Pahucki (Novell, Inc.), David Morandi (E.piphany, Inc.), Ricardo Morin (Intel Corporation), Nathan Pahucki (Novell, Inc.), Matt Raible (Individual), Dirk Reinshagen (Individual), Narinder Sahota (Cap Gemini), Suneet Shah (Individual), Bill Shannon (Sun Microsystems, Inc.), Rajiv Shivane (Pramati Technologies), Scott Stark (Jboss, Inc), Hani Suleiman (Ironflare AB), Kresten Krab Thorup (Trifork), Ashish Kumar Tiwari (Individual), Sivasundaram Umapathy (Individual), Steve Weston (Cap Gemini), Seth White (BEA Systems), and Umit Yalcinalp (SAP AG). Once again, my colleagues at Sun provided invaluable assistance: Roberto Chinnici provided draft proposals for many issues related to dependency injection.

1.5. Acknowledgements for Java EE Version 6

Version 6 of this specification was created under the Java Community Process as JSR-316. The spec leads for the JSR-316 Expert Group were Bill Shannon (Sun Microsystems, Inc.) and Roberto Chinnici (Sun Microsystems, Inc.). The expert group included the following members: Florent Benoit (Inria), Adam Bien (Individual), David Blevins (Individual), Bill Burke (Red Hat Middleware LLC), Larry Cable (BEA Systems), Bongjae Chang (Tmax Soft, Inc.), Rejeev Divakaran (Individual), Francois Exertier (Inria), Jeff Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat Middleware LLC), Gang Huang (Peking University), Rod Johnson (SpringSource), Werner Keil (Individual), Michael Keith (Oracle), Wonseok Kim (Tmax Soft, Inc.), Jim Knutson (IBM), Elika S. Kohen (Individual), Peter Kristiansson (Ericsson AB), Changshin Lee (NCsoft Corporation), Felipe Leme (Individual), Ming Li (TongTech Ltd.), Vladimir Pavlov (SAP AG), Dhanji R. Prasanna (Google), Reza Rahman (Individual), Rajiv Shivane (Pramati Technologies), Hani Suleiman (Individual).

1.6. Acknowledgements for Java EE Version 7

Version 7 of this specification was created under the Java Community Process as JSR-342. The Expert Group work for this specification was conducted by means of the http://javaee-spec.java.net project in order to provide transparency to the Java community. The specification leads for the JSR-342 Expert Group were Bill Shannon (Oracle) and Linda DeMichiel (Oracle). The expert group included the following members: Deepak Anupalli (Pramati Technologies), Anton Arhipov (ZeroTurnaround), Florent Benoit (OW2), Adam Bien (Individual), David Blevins (Individual), Markus Eisele (Individual), Jeff Genender (Individual), Antonio Goncalves (Individual), Jason Greene (Red Hat, Inc.), Alex Heneveld (Individual), Minehiko Iida (Fujitsu), Jevgeni Kabanov (Individual), Ingyu Kang (Tmax Soft, Inc.), Werner Keil (Individual), Jim Knutson (IBM), Ming Li (TongTech Ltd.), Pete Muir (Red Hat, Inc.), Minoru Nitta (Fujitsu), Reza Rahman (Caucho Technology, Inc), Kristoffer Sjogren (Ericsson AB), Kevin Sutter (IBM), Spike Washburn (Individual), Kyung Koo Yoon (TmaxSoft).

1.7. Acknowledgements for Java EE Version 8

Version 8 of this specification was created under the Java Community Process as JSR-366. The Expert Group work for this specification was conducted by means of the http://javaee-spec.java.net and https:javaee.github.io/javaee-spec projects in order to provide transparency to the Java community. The specification leads for the JSR-366 Expert Group were Bill Shannon (Oracle) and Linda DeMichiel (Oracle). The expert group included the following members: Florent Benoit (OW2), David Blevins (Tomitribe), Jeff Genender (Savoir Technologies), Antonio Goncalves (Individual), Jason Greene (Red Hat), Werner Keil (Individual), Moon Namkoong (TmaxSoft, Inc.) Antoine Sabot-Durand (Red Hat), Kevin Sutter (IBM), Ruslan Synytsky (Jelastic, Inc.), Markus Winkler (oparco - open architectures & consulting). Reza Rahman (Individual) participated as a contributor.

1.8. Acknowledgements for Jakarta EE 8

The Jakarta EE 8 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).

1.9. Acknowledgements for Jakarta EE 9

The Jakarta EE 9 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).

1.10. Acknowledgements for Jakarta EE 9.1

The Jakarta EE 9.1 specification was created by the Jakarta EE Platform Specification Project with guidance provided by the Jakarta EE Working Group (https://jakarta.ee/).

2. Platform Overview

This chapter provides an overview of the Jakarta™ EE Platform.

2.1. Architecture

The required relationships of architectural elements of the Jakarta EE platform are shown in Jakarta EE Architecture Diagram. Note that this figure shows the logical relationships of the elements; it is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.

The Containers, denoted by the separate rectangles, are Jakarta EE runtime environments that provide required services to the application components represented in the upper half of the rectangle. The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Jakarta Messaging APIs to Application Clients, as well as the other services represented. All these services are explained below. See Jakarta EE Standard Services.

The arrows represent required access to other parts of the Jakarta EE platform. The Application Client Container provides Application Clients with direct access to the Jakarta EE required Database through the Java API for connectivity with database systems, the JDBC™ API. Similar access to databases is provided to server pages, server faces applications, and servlets by the Web Container, and to enterprise beans by the Enterprise Beans Container.

As indicated, the APIs of the Java™ Platform, Standard Edition (Java SE), are supported by Java SE runtime environments for each type of application component.

JakartaEEarchitecture

Figure 1. Jakarta EE Architecture Diagram

The following sections describe the Jakarta EE Platform requirements for each kind of Jakarta EE platform element.

2.2. Profiles

The Java EE 6 specification introduced the notion of “profiles” (see Profiles”).

A profile is a configuration of the Jakarta EE platform targeted at a specific class of applications.

Profiles are not a new concept, nor are they unique to the Jakarta EE platform. The Jakarta EE Specification process: “A Specification that includes by reference a collection of Specifications and possibly additional requirements. APIs from the referenced Platform Edition must be included according to the referencing rules set out in that Platform Edition Specification. Other referenced specifications must be referenced in their entirety.”

All Jakarta EE profiles share a set of common features, such as naming and resource injection, packaging rules, security requirements, etc. This guarantees a degree of uniformity across all products and, indirectly, applications that fall under the “Jakarta EE platform” umbrella. This also ensures that developers who are familiar with a certain profile, or with the full platform, can move easily to other profiles, avoiding excessive compartmentalization of skills and experience.

Beyond the basic functionality outlined above, profiles are free to include any set of technologies that are part of the platform, provided that all rules in the present specification that pertain to the included technologies—either alone or in combination with others—are followed.

This last point is worth stressing. If profiles only included pointwise technologies, they would be little more than bundles of APIs with few or no tie-ins. Instead, the definition of profiles adopted here guarantees that whenever this specification defines requirements on combinations of technologies, these requirements will be honored in all products based on Jakarta EE profiles.

As a concrete example, consider the use of transactions in a servlet container. In isolation, neither the Jakarta Servlet specification nor the Jakarta Transactions specification defines a complete programming model for portable applications. This specification fills that gap by introducing its own set of requirements that pertain to the combination of servlets and Jakarta Transactions. These requirements must be satisfied by any Jakarta EE profile-based product that includes those two technologies, thus offering application developers a more complete programming model shared across all relevant Jakarta EE profiles.

A separate specification, the Jakarta EE Web Profile Specification, defines the Jakarta EE Web Profile, the first profile of the Jakarta EE platform.

Additional profiles may be defined in accordance with the rules of the Jakarta EE Specification Process and those contained in the present specification. In particular, profiles are initiated by submitting a Project Proposal to the Jakarta EE Specification Process and are released at completion on their own schedule, independently of any concurrent revision of the platform itself or of other profiles. This ensures maximum flexibility in defining and releasing a new profile or an updated version of an existing one.

In accordance with the definition of profiles given above, a profile may end up being either a proper subset or a proper superset of the platform, or it may overlap with it to a certain extent. This flexibility guarantees that future profiles will be able to cover uses well beyond those originally envisioned by the platform specification.

As the previous paragraphs made clear, creating a new profile is a significant undertaking. The decision to create a profile should take into account its potential drawbacks, especially in terms of fragmentation and developer confusion. In general, a profile should be created only when there is a natural developer constituency and a well-understood class of applications that can benefit from it. It is also recommended that a profile cast a comprehensive net on its area of interest, to minimize the occurrence of overlapping or competing profiles. Jakarta EE platform features such as optional components and extensibility can be used by profiles to achieve a better fit to their intended target.

2.3. Application Components

The Jakarta EE runtime environment defines four application component types that a Jakarta EE product must support:

  • Application clients are Java programming language programs that are typically GUI programs that execute on a desktop computer. Application clients offer a user experience similar to that of native applications and have access to all of the facilities of the Jakarta EE middle tier.

  • Applets are GUI components that typically execute in a web browser, but can execute in a variety of other applications or devices that support the applet programming model. Applets can be used to provide a powerful user interface for Jakarta EE applications. (Simple HTML pages can also be used to provide a more limited user interface for Jakarta EE applications.)

  • servlets, server pages, server faces applications, filters, and web event listeners typically execute in a web container and may respond to HTTP requests from web clients. Servlets, server pages, server faces applications, and filters may be used to generate HTML pages that are an application’s user interface. They may also be used to generate XML or other format data that is consumed by other application components. A special kind of servlet may provide support for web services using the SOAP/HTTP protocol. Servlets, pages created with the Jakarta Server Pages technology or Jakarta Server Faces technology, web filters, and web event listeners are referred to collectively in this specification as “web components.” Web applications are composed of web components and other data such as HTML pages. Web components execute in a web container. A web server includes a web container and other protocol support, security support, and so on, as required by Jakarta EE specifications.

  • Jakarta Enterprise Beans components execute in a managed environment that supports transactions. Enterprise beans typically contain the business logic for a Jakarta EE application. Enterprise beans may directly provide web services using the SOAP/HTTP protocol.

2.3.1. Jakarta EE Server Support for Application Components

The Jakarta EE servers provide deployment, management, and execution support for conforming application components. Application components can be divided into three categories according to their dependence on a Jakarta EE server:

  • Components that are deployed, managed, and executed on a Jakarta EE server. These components include web components and Jakarta Enterprise Beans components. See the separate specifications for these components.

  • Components that are deployed and managed on a Jakarta EE server, but are loaded and executed on a client machine. These components include web resources such as HTML pages and applets embedded in HTML pages.

  • Components whose deployment and management is not completely defined by this specification. Application Clients fall into this category.

2.4. Containers

Containers provide the runtime support for Jakarta EE application components. Containers provide a federated view of the underlying Jakarta EE APIs to the application components. Jakarta EE application components never interact directly with other Jakarta EE application components. They use the protocols and methods of the container for interacting with each other and with platform services. Interposing a container between the application components and the Jakarta EE services allows the container to transparently inject the services required by the component, such as declarative transaction management, security checks, resource pooling, and state management.

A typical Jakarta EE product will provide a container for each application component type: application client container, applet container, web component container, and enterprise bean container.

2.4.1. Container Requirements

This specification requires that containers support execution in a Java™ runtime environment, as defined by the Java Platform, Standard Edition specification, v8 or later (Java SE 8 or later).

The container tools must understand the file formats for the packaging of application components for deployment.

The containers are implemented by a Jakarta EE Product Provider. See the description of the Product Provider role in Jakarta EE Product Provider.

This specification defines a set of standard services that each Jakarta EE product must support. These standard services are described below. The Jakarta EE containers provide the APIs that application components use to access these services. This specification also describes standard ways to extend Jakarta EE services with connectors to other non-Jakarta EE application systems, such as mainframe systems and ERP systems.

2.4.2. Jakarta EE Servers

Underlying a Jakarta EE container is the server of which it is a part. A Jakarta EE Product Provider typically implements the Jakarta EE server-side functionality using an existing transaction processing infrastructure in combination with Java Platform, Standard Edition (Java SE) technology. The Jakarta EE client functionality is typically built on Java SE technology.

2.5. Resource Adapters

A resource adapter is a system-level software component that typically implements network connectivity to an external resource manager. A resource adapter can extend the functionality of the Jakarta EE platform either by implementing one of the Java SE service APIs (such as a JDBC™ driver), or by defining and implementing a resource adapter for a connector to an external application system. Resource adapters may also provide services that are entirely local, perhaps interacting with native resources. Resource adapters interface with the Jakarta EE platform through the Jakarta EE service provider interfaces (Jakarta EE SPI). A resource adapter that uses the Jakarta EE SPIs to attach to the Jakarta EE platform will be able to work with all Jakarta EE products.

2.6. Database

The Jakarta EE platform requires a database, accessible through the JDBC API, for the storage of business data. The database is accessible from web components, enterprise beans, and application client components. The database need not be accessible from applets. The Jakarta EE Product Provider must also provide a preconfigured, default data source for use by the application in accessing this database. See Default Data Source.

2.7. Jakarta EE Standard Services

The Jakarta EE standard services include the following (specified in more detail later in this document). Some of these standard services are actually provided by Java SE.

2.7.1. HTTP

The HTTP client-side API is defined by the java.net package. The HTTP server-side API is defined by the Jakarta Servlet, Jakarta Server Pages, and Jakarta Server Faces interfaces and by the web services support that is an optional part of the Jakarta EE platform.

2.7.2. HTTPS

Use of the HTTP protocol over the SSL protocol is supported by the same client and server APIs as HTTP.

2.7.3. Jakarta Transaction API (JTA)

The Jakarta Transactions consists of two parts:

  • An application-level demarcation interface that is used by the container and application components to demarcate transaction boundaries.

  • An interface between the transaction manager and a resource manager used at the Jakarta EE SPI level.

2.7.4. RMI-IIOP (Optional)

Support for CORBA, including use of IIOP and Java IDL, is Optional as of Jakarta EE 9. See Optional Jakarta Technologies.

2.7.5. Java IDL (Optional)

Support for CORBA, including use of IIOP and Java IDL, is Optional as of Jakarta EE 9. See Optional Jakarta Technologies.

2.7.6. JDBC™ API

The JDBC API is the API for connectivity with relational database systems. The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the Jakarta EE platform. Support for the service provider interface is not required in Jakarta EE products. Instead, JDBC drivers should be packaged as resource adapters that use the facilities of the Connector API to interface with a Jakarta EE product. The JDBC API is included in Java SE, but this specification includes additional requirements on JDBC device drivers.

2.7.7. Jakarta Persistence API

Jakarta Persistence is the standard API for the management of persistence and object/relational mapping. It provides an object/relational mapping facility for application developers using a Java domain model to manage a relational database. Jakarta Persistence is required to be supported in Jakarta EE. It can also be used in Java SE environments.

2.7.8. Jakarta™ Messaging

Jakarta Messaging is a standard API for messaging that supports reliable point-to-point messaging as well as the publish-subscribe model. This specification requires a Jakarta Messaging provider that implements both point-to-point messaging as well as publish-subscribe messaging. The Jakarta EE Product Provider must also provide a preconfigured, default Jakarta Messaging connection factory for use by the application in accessing this JMS provider. See Default Jakarta Messaging Connection Factory.

2.7.9. Java Naming and Directory Interface™ (JNDI)

The JNDI API is the standard API for naming and directory access. The JNDI API has two parts: an application-level interface used by the application components to access naming and directory services and a service provider interface to attach a provider of a naming and directory service. The JNDI API is included in Java SE, but this specification defines additional requirements.

2.7.10. Jakarta™ Mail

Many Internet applications require the ability to send email notifications, so the Jakarta EE platform includes the Jakarta Mail API along with a Jakarta Mail service provider that allows an application component to send Internet mail. The Jakarta Mail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface used at the Jakarta EE SPI level.

2.7.11. Jakarta Activation Framework (JAF)

The JAF API provides a framework for handling data in different MIME types, originating in different formats and locations. The Jakarta Mail API makes use of the JAF API. As of Jakarta EE 9, the Jakarta Activation Framework is now part of the Jakarta EE Platform.

2.7.12. XML Processing

The Java™ API for XML Processing (JAXP) provides support for the industry standard SAX and DOM APIs for parsing XML documents, as well as support for XSLT transform engines. The Streaming API for XML (StAX) provides a pull-parsing API for XML. The JAXP and StAX APIs are included in Java SE and so are available to Jakarta EE applications.

2.7.13. Jakarta Connectors

Jakarta Connectors is a Jakarta EE SPI that allows resource adapters that support access to Enterprise Information Systems to be plugged in to any Jakarta EE product. The Connector architecture defines a standard set of system-level contracts between a Jakarta EE server and a resource adapter. The standard contracts include:

  • A connection management contract that lets a Jakarta EE server pool connections to an underlying EIS, and lets application components connect to an EIS. This leads to a scalable application environment that can support a large number of clients requiring access to EIS systems.

  • A transaction management contract between the transaction manager and an EIS that supports transactional access to EIS resource managers. This contract lets a Jakarta EE server use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager.

  • A security contract that enables secure access to an EIS. This contract provides support for a secure application environment, which reduces security threats to the EIS and protects valuable information resources managed by the EIS.

  • A thread management contract that allows a resource adapter to delegate work to other threads and allows the application server to manage a pool of threads. The resource adapter can control the security context and transaction context used by the worker thread.

  • A contract that allows a resource adapter to deliver messages to message driven beans independent of the specific messaging style, messaging semantics, and messaging infrastructure used to deliver messages. This contract also serves as the standard message provider pluggability contract that allows a message provider to be plugged into any Jakarta EE server via a resource adapter.

  • A contract that allows a resource adapter to propagate an imported transaction context to the Jakarta EE server such that its interactions with the server and any application components are part of the imported transaction. This contract preserves the ACID (atomicity, consistency, isolation, durability) properties of the imported transaction.

  • An optional contract providing a generic command interface between an application program and a resource adapter.

2.7.14. Security Services

The Java™ Authentication and Authorization Service (JAAS) enables services to authenticate and enforce access controls upon users. It implements a Java technology version of the standard Pluggable Authentication Module (PAM) framework and supports user-based authorization. Jakarta™ Authorization defines a contract between a Jakarta EE application server and an authorization service provider, allowing custom authorization service providers to be plugged into any Jakarta EE product. Jakarta™ Authentication defines an SPI by which authentication providers implementing message authentication mechanisms may be integrated in client or server message processing containers or runtimes. Jakarta Security leverages Jakarta Authentication, but provides an easier to use SPI for authentication of users of web applications and defines identity store APIs for authentication and authorization.

2.7.15. XML Web Services (Optional)

Jakarta EE optionally provides full support for both clients of web services as well as web service endpoints. Several Jakarta technologies work together to provide support for web services. Jakarta XML Web Services provides support for web service calls using the SOAP/HTTP protocol. XML Web Services is the primary API for web services and is a follow-on to Jakarta XML-based RPC[1]. Jakarta XML Web Services offers extensive web services functionality, with support for multiple bindings/protocols. Support for Jakarta XML-based RPC has been removed from the Platform as of Jakarta EE 9. See Removed Jakarta Technologies.

Jakarta XML Web Services and Jakarta XML Binding define the mapping between Java classes and XML as used in SOAP calls, and provide support for 100% of XML Schema. The Jakarta SOAP with Attachments provides support for manipulating low level SOAP messages. The Web Services for Jakarta EE specification fully defines the deployment of web service clients and web service endpoints in Jakarta EE, as well as the implementation of web service endpoints using enterprise beans. The XML Web Services Metadata specification defines Java language annotations that make it easier to develop web services. The Jakarta XML Registries support has been removed from the Platform as of Jakarta EE 9. See Removed Jakarta Technologies.

2.7.16. Jakarta JSON Processing

Jakarta JSON Processing provides a convenient way to process (parse, generate, transform, and query) JSON text.

2.7.17. Jakarta JSON Binding

Jakarta JSON Binding provides a convenient way to convert between JSON text and Java objects.

2.7.18. Jakarta WebSocket

Jakarta WebSocket is a standard API for creating WebSocket applications.

2.7.19. Jakarta RESTful Web Services

Jakarta RESTful Web Services provides support for web services using the REST style. RESTful web services better match the design style of the web and are often easier to access using a wide variety of programming languages. Jakarta RESTful Web Services provides a simple high-level API for writing such web services as well as a low-level API that can be used to control the details of the web service interaction.

2.7.20. Jakarta Concurrency

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.

2.7.21. Jakarta Batch

The Jakarta Batch API provides a programming model for batch applications and a runtime for scheduling and executing jobs.

2.7.22. Jakarta Management (Removed)

Although the Jakarta Management Specification was removed from the Platform as of Jakarta EE 9 (see Removed Java Technologies), the Java™ Management Extensions (JMX) API can be used to provide some management support.

2.7.23. Jakarta Deployment (Removed)

The Jakarta Deployment Specification was removed from the Platform as of Jakarta EE 9 (see Removed Java Technologies).

2.8. Interoperability

Many of the APIs described above provide interoperability with components that are not a part of the Jakarta EE platform, such as external web or CORBA services.

Jakarta EE Interoperability illustrates the interoperability facilities that may be available in the Jakarta EE platform. (The directions of the arrows indicate the client/server relationships of the components.)

JakartaEEinteroperability

Figure 2. Jakarta EE Interoperability

2.9. Flexibility of Product Requirements

This specification doesn’t require that a Jakarta EE product be implemented by a single program, a single server, or even a single machine. In general, this specification doesn’t describe the partitioning of services or functions between machines, servers, or processes. As long as the requirements in this specification are met, Jakarta EE Product Providers can partition the functionality however they see fit. A Jakarta EE product must be able to deploy application components that execute with the semantics described by this specification.

A typical low end Jakarta EE product will support applets using the Java Plugin in one of the popular browsers, application clients each in their own Java virtual machine, and will provide a single server that supports both web components and enterprise beans. A high end Jakarta EE product might split the server components into multiple servers, each of which can be distributed and load-balanced across a collection of machines. While such machines might exist on-site in an enterprise, they might also reside, for example, in a public cloud. This specification does not prescribe or preclude any of these configurations.

A wide variety of Jakarta EE product configurations and implementations, all of which meet the requirements of this specification, are possible. A portable Jakarta EE application will function correctly when successfully deployed in any of these products.

2.10. Jakarta EE Product Packaging

This specification doesn’t include requirements for the packaging of a Jakarta EE product. A Jakarta EE product might be provided on distribution media, for download on the web, or as a service available only on the web, for example. A Jakarta EE product must include implementations of all the APIs required by this specification. These implementations might depend on other software or services not included in the Jakarta EE product. The customer may be required to combine or configure the product with other software or services that are necessary to meet the requirements of this specification. The documentation for the Jakarta EE product must fully describe all the required software and configuration.

For example, a Jakarta EE product might depend on a database server, a naming service, a mail service, and/or a messaging service. All configurations in which the product is defined to operate must include all the software and services necessary to meet the requirements of this specification.

Whether these services are available (running, accessible on the network, properly configured, operating correctly, etc.) may be controlled independently of the Jakarta EE product — they may be unavailable when the Jakarta EE server is started, or they may fail while the Jakarta EE server is running. This specification does not require the Jakarta EE product to assure the availability of these services. However, if such a service is needed to meet the requirements of this specification, the Jakarta EE product must ensure that the service has been configured for use and will be usable when it is available.

For example, this specification requires that applications can use a database. If the Jakarta EE product requires a database server to be separately installed, and requires the Jakarta EE product to be configured to use that database, such configuration must be done before applications are deployed. This ensures that the operational environment of applications includes all the required services.

2.11. Jakarta EE Product Extensions

This specification describes a minimum set of facilities available to all Jakarta EE products. A Jakarta EE profile may include some or all of these facilities, as described in Profiles. Products implementing the full Jakarta EE platform must provide all of them (see Full Jakarta EE Product Requirements). Most Jakarta EE products will provide facilities beyond the minimum required by this specification. This specification includes only a few limits to the ability of a product to provide extensions. In particular, it includes the same restrictions as Java SE on extensions to Java APIs. A Jakarta EE product must not add classes to the Java programming language packages included in this specification, and must not add methods or otherwise alter the signatures of the specified classes.

However, many other extensions are allowed. A Jakarta EE product may provide additional Java APIs, either other Java optional packages or other (appropriately named) packages. A Jakarta EE product may include support for additional protocols or services not specified here. A Jakarta EE product may support applications written in other languages, or may support connectivity to other platforms or applications.

Of course, portable applications will not make use of any platform extensions. Applications that do make use of facilities not required by this specification will be less portable. Depending on the facility used, the loss of portability may be minor or it may be significant.

We expect Jakarta EE products to vary widely and compete vigorously on various aspects of quality of service. Products will provide different levels of performance, scalability, robustness, availability, and security. In some cases this specification requires minimum levels of service. Future versions of this specification may allow applications to describe their requirements in these areas.

2.12. Platform Roles

This section describes typical Jakarta Enterprise Edition roles. In an actual instance, an organization may divide role functionality differently to match that organization’s application development and deployment workflow.

The roles are described in greater detail in later sections of this specification.

2.12.1. Jakarta EE Product Provider

A Jakarta EE Product Provider is the implementor and supplier of a Jakarta EE product that includes the component containers, Jakarta EE platform APIs, and other features defined in this specification. A Jakarta EE Product Provider is typically an application server vendor, a web server vendor, a database system vendor, or an operating system vendor. A Jakarta EE Product Provider must make available the Jakarta EE APIs to the application components through containers. A Product Provider frequently bases their implementation on an existing infrastructure.

A Jakarta EE Product Provider must provide the mapping of the application components to the network protocols as specified by this specification. A Jakarta EE product is free to implement interfaces that are not specified by this specification in an implementation-specific way.

A Jakarta EE Product Provider must provide application deployment and management tools. Deployment tools enable a Deployer (see Deployer) to deploy application components on the Jakarta EE product. Management tools allow a System Administrator (see System Administrator) to manage the Jakarta EE product and the applications deployed on the Jakarta EE product. The form of these tools is not prescribed by this specification.

2.12.2. Application Component Provider

There are multiple roles for Application Component Providers, including, for example, HTML document designers, document programmers, and enterprise bean developers. These roles use tools to produce Jakarta EE applications and components.

2.12.3. Application Assembler

The Application Assembler takes a set of components developed by Application Component Providers and assembles them into a complete Jakarta EE application delivered in the form of an Enterprise Archive ( .ear ) file. The Application Assembler will generally use GUI tools provided by either a Platform Provider or Tool Provider. The Application Assembler is responsible for providing assembly instructions describing external dependencies of the application that the Deployer must resolve in the deployment process.

2.12.4. Deployer

The Deployer is responsible for deploying application clients, web applications, and Enterprise Beans components into a specific operational environment. The Deployer uses tools supplied by the Jakarta EE Product Provider to carry out deployment tasks. Deployment is typically a three-stage process:

  1. During Installation the Deployer moves application media to the server, generates the additional container-specific classes and interfaces that enable the container to manage the application components at runtime, and installs application components, and additional classes and interfaces, into the appropriate Jakarta EE containers.

  2. During Configuration, external dependencies declared by the Application Component Provider are resolved and application assembly instructions defined by the Application Assembler are followed. For example, the Deployer is responsible for mapping security roles defined by the Application Assembler onto user groups and accounts that exist in the target operational environment.

  3. Finally, the Deployer starts up Execution of the newly installed and configured application.

In some cases, a specially qualified Deployer may customize the business logic of the application’s components at deployment time. For example, using tools provided with a Jakarta EE product, the Deployer may provide simple application code that wraps an enterprise bean’s business methods, or customizes the appearance of a Jakarta Server Pages or Jakarta Server Faces page.

The Deployer’s output is web applications, enterprise beans, applets, and application clients that have been customized for the target operational environment and are deployed in a specific Jakarta EE container.

For example, in the case of cloud deployments, the Deployer would be responsible for configuring the application to run in the cloud environment. The Deployer would install the application into the cloud environment, configure its external dependencies, and might handle aspects of provisioning its required resources.

2.12.5. System Administrator

The System Administrator is responsible for the configuration and administration of the enterprise’s computing and networking infrastructure. The System Administrator is also responsible for overseeing the runtime well-being of the deployed Jakarta EE applications. The System Administrator typically uses runtime monitoring and management tools provided by the Jakarta EE Product Provider to accomplish these tasks.

For example, in a cloud scenario, the System Administrator would be responsible for installing, configuring, managing, and maintaining the cloud environment, including the resources that are made available to applications running in the environment.

2.12.6. Tool Provider

A Tool Provider provides tools used for the development and packaging of application components. A variety of tools are anticipated, corresponding to the types of application components supported by the Jakarta EE platform. Platform independent tools can be used for all phases of development through the deployment of an application and the management and monitoring of an application server.

2.12.7. System Component Provider

A variety of system level components may be provided by System Component Providers. Jakarta Connectors defines the primary APIs used to provide resource adapters of many types. These resource adapters may connect to existing enterprise information systems of many types, including databases and messaging systems. Another type of system component is an authorization policy provider as defined by the Jakarta Authorization specification.

2.13. Platform Contracts

This section describes the Jakarta EE contracts that must be fulfilled by a Jakarta EE Product Provider implementing the full Jakarta EE platform. Jakarta EE profiles may include some or all of these facilities, as described in Profiles.

2.13.1. Jakarta EE APIs

The Jakarta EE APIs define the contract between the Jakarta EE application components and the Jakarta EE platform. The contract specifies both the runtime and deployment interfaces.

The Jakarta EE Product Provider must implement the Jakarta EE APIs in a way that supports the semantics and policies described in this specification. The Application Component Provider provides components that conform to these APIs and policies.

2.13.2. Jakarta EE Service Provider Interfaces (SPIs)

The Jakarta EE Service Provider Interfaces (SPIs) define the contract between the Jakarta EE platform and service providers that may be plugged into a Jakarta EE product. The connector APIs define service provider interfaces for integrating resource adapters with a Jakarta EE application server. Resource adapter components implementing the connector APIs are called Connectors. The Jakarta Authorization APIs define service provider interfaces for integrating security authorization mechanisms with a Jakarta EE application server.

The Jakarta EE Product Provider must implement the Jakarta EE SPIs in a way that supports the semantics and policies described in this specification. A provider of Service Provider components (for example, a Connector Provider) should provide components that conform to these SPIs and policies.

2.13.3. Network Protocols

This specification defines the mapping of application components to industry-standard network protocols. The mapping allows client access to the application components from systems that have not installed Jakarta EE product technology. See Interoperability, for details on the network protocol support required for interoperability.

The Jakarta EE Product Provider is required to publish the installed application components on the industry-standard protocols. This specification defines the mapping of servlets and server pages to the HTTP and HTTPS protocols, and the mapping of Jakarta Enterprise Beans components to IIOP and SOAP protocols.

2.13.4. Deployment Descriptors and Annotations

Deployment descriptors and Java language annotations are used to communicate the needs of application components to the Deployer. The deployment descriptor and class file annotations are a contract between the Application Component Provider or Assembler and the Deployer. The Application Component Provider or Assembler is required to specify the application component’s external resource requirements, security requirements, environment parameters, and so forth in the component’s deployment descriptor or through class file annotations. The Jakarta EE Product Provider is required to provide a deployment tool that interprets the Jakarta EE deployment descriptors and class file annotations and allows the Deployer to map the application component’s requirements to the capabilities of a specific Jakarta EE product and environment.

2.14. Changes in J2EE 1.3

The J2EE 1.3 specification extends the J2EE platform with additional enterprise integration facilities. The Connector API supports integration with external enterprise information systems. A JMS provider is now required. The JAXP API provides support for processing XML documents. The JAAS API provides security support for the Connector API. The EJB specification now requires support for interoperability using the IIOP protocol.

Significant changes have been made to the EJB specification. The EJB specification has a new container-managed persistence model, support for message driven beans, and support for local enterprise beans.

Other existing J2EE APIs have been updated as well. See the individual API specifications for details. Finally, J2EE 1.3 requires support for J2SE 1.3.

2.15. Changes in J2EE 1.4

The primary focus of J2EE 1.4 is support for web services. The JAX-RPC and SAAJ APIs provide the basic web services interoperability support. The Web Services for J2EE specification describes the packaging and deployment requirements for J2EE applications that provide and use web services. The EJB specification was also extended to support implementing web services using stateless session beans. The JAXR API supports access to registries and repositories.

Several other APIs have been added to J2EE 1.4. The J2EE Management and J2EE Deployment APIs enable enhanced tool support for J2EE products. The JMX API supports the J2EE Management API. The J2EE Authorization Contract for Containers provides an SPI for security providers.

Many of the existing J2EE APIs have been enhanced in J2EE 1.4. J2EE 1.4 builds on J2SE 1.4. The JSP specification has been enhanced to simplify the development of web applications. The Connector API now supports integration with asynchronous messaging systems, including the ability to plug in JMS providers.

Changes in this J2EE platform specification include support for deploying class libraries independently of any application and the conversion of deployment descriptor DTDs to XML Schemas.

Other J2EE APIs have been enhanced as well. For additional details, see each of the referenced specifications.

2.16. Changes in Java EE 5

With this release, the platform has a new name – Java Platform, Enterprise Edition, or Java EE for short. This new name gets rid of the confusing “2” while emphasizing even in the short name that this is a Java platform. Previous versions are still referred to using the old name “J2EE”.

The focus of Java EE 5 is ease of development. To simplify the development process for programmers just starting with Java EE, or developing small to medium applications, Java EE 5 makes extensive use of Java language annotations, which were introduced by J2SE 5.0. Annotations reduce or eliminate the need to deal with Java EE deployment descriptors in many cases. Even large applications can benefit from the simplifications provided by annotations.

One of the major uses of annotations is to specify injection of resources and other dependencies into Java EE components. Injection augments the existing JNDI lookup capability to provide a new simplified model for applications to gain access to the resources needed from the operational environment. Injection also works with deployment descriptors to allow the deployer to customize or override resource settings specified in the application’s source code.

The use of annotations is made even more effective by providing better defaults. Better default behavior and better default configuration allows most applications to get the behavior they want most of the time, without the use of either annotations or deployment descriptors in many cases. When the default is not what the application wants, a simple annotation can be used to specify the required behavior or configuration.

The combination of annotations and better defaults has greatly simplified the development of applications using Enterprise JavaBeans technology and applications defining or using web services. Enterprise beans are now dramatically simpler to develop. Web services are much easier to develop using the annotations defined by the Web Services Metadata specification.

The area of web services continues to evolve at a rapid pace. To provide the latest web services support, the JAX-RPC technology has evolved into the JAX-WS technology, which makes heavy use of the JAXB technology to bind Java objects to XML data. Both JAX-WS and JAXB are new to this version of the platform.

Major additions to Java EE 5 include the JSTL and JSF technologies that simplify development of web applications, and the Java Persistence API developed by the EJB 3.0 expert group, which greatly simplifies mapping Java objects to databases.

Minor additions include the StAX API for XML parsing. Most APIs from previous versions have been updated with small to medium improvements.

2.17. Changes in Java EE 6

Java EE 6 continues the “ease of development” focus of Java EE 5.

One of the major improvements introduced in Java EE 6 is the Contexts and Dependency Injection (CDI) technology, which provides a uniform framework for the dependency injection and lifecycle management of “managed beans”.

The Java EE 6 Managed Bean specification defines the commonalities across the spectrum of Java EE managed objects, extending from basic managed beans through EJB components.

The Bean Validation specification, introduced in this release, provides a facility for validation of managed objects. Bean Validation is integrated into the Java Persistence API, where it provides an automated facility for the validation of JPA entities.

Java EE 6 adds the JAX-RS API as a required technology of the Java EE Platform. JAX-RS is the API for the development of Web services built according to the Representational State Transfer (REST) architectural style.

Java EE 6 also introduces the Java EE Web Profile, the first new profile of the Java EE Platform.

2.18. Changes in Java EE 7

Since its inception, the Java EE platform has been targeted at offloading the developer from common infrastructure tasks through its container-based model and abstraction of resource access. In recent releases the platform has considerably simplified the APIs for access to container services while broadening the range of the services available. In this release we continue the direction of improved simplification, while extending the range of the Java EE platform to encompass emerging technologies in the web space.

The Java EE 7 platform adds first-class support for recent developments in web standards, including Web Sockets and JSON, which provide the underpinnings for HTML 5 support in Java EE. Java EE 7 also adds a modern HTTP client API as defined by JAX-RS 2.0.

Also new in the Java EE 7 platform is the Batch API, which provides a programming model for batch applications and a runtime for scheduling and executing jobs, and the Concurrency Utilities API, which provides asynchronous capabilities by means of managed executor service, managed scheduled executor service, managed thread factory, and context service.

The CDI dependency injection facility introduced in Java EE 6 is enhanced as well as more broadly utilized by the Java EE 7 platform technologies, and the managed bean model is further aligned to remove inconsistencies among Java EE component classes in aspects of CDI injection and interceptor support. The declarative transaction functionality introduced by EJB is been made available in a more general way through CDI interceptors, so that it may be leveraged by other managed beans. The Bean Validation facility is extended to the automatic validation of method invocations and likewise made available via CDI interceptors.

Java EE 7 also continues the "ease of development" focus of Java EE 5 and Java EE 6. Most notably, Java EE 7 includes a revised and greatly simplified JMS 2.0 API. Ease of development encompasses ease of configuration as well. To that end, Java EE 7 broadens the resource definition facilities introduced in Java EE 6 to encompass more of the standard platform resource types, and also provides default database and JMS connection factory resources. It also improves the configuration of application security, including new descriptors for security permissions. Java EE 7 further simplifies the platform by making optional the technologies that were identified as candidates for pruning in Java EE 6, namely: EJB Entity Beans, JAX-RPC 1.1, JAXR 1.0, and JSR-88 1.2.

Finally, Java EE 7 lays groundwork for enhancements to the platform for use in cloud environments in a future release. Such features include resource definition metadata, improved security configuration, and support for database schema generation via the Java Persistence API.

2.19. Changes in Java EE 8

Java EE 8 continues the focus on modern web applications of Java EE 7 and broadening the range of such applications. Java EE 8 introduces the JSON Binding API (JSON-B) for mapping between JSON text and Java objects, building on the JSON Processing API (JSON-P) introduced in Java EE 7. The JSON Processing API itself is updated to reflect additional JSON standards. Servlet undergoes major enhancement with the addition of support for the new HTTP/2 protocol. JAX-RS adds support for server-sent events and, building on concurrency facilities added in Java SE 8, a reactive client API. The new Java EE Security API provides enhanced support for authentication and authorization in web modules, and also introduces APIs for access to identity stores. The Bean Validation facility is updated to reflect enhancements made in Java SE 8 and to extend the range of validated objects. While the focus of CDI in this release is to extend its scope beyond Java EE with the introduction of a bootstrapping API, CDI also includes enhancements for event processing and alignment on Java SE 8 features.

2.20. Changes in Jakarta EE 8

Jakarta EE 8 is the migration of Java EE 8 from the JCP to the Eclipse Foundation. Reference the "Specification Comparison" and “Revision History" appendices for more information.

2.21. Changes in Jakarta EE 9

The goal of the Jakarta EE 9 release is to deliver a set of specifications functionally similar to Jakarta EE 8 but in the new Jakarta EE 9 namespace jakarta.*.

In addition, the Jakarta EE 9 release removes a small set of specifications from Jakarta EE 8 that were old, optional, or deprecated in order to reduce the surface area of the APIs to ensure that it is easier for new vendors to enter the ecosystem – as well as reduce the burden on implementation, migration, and maintenance of these old APIs.

Predominantly, Jakarta EE 9 is a tooling release:

  • A platform from which tooling vendors can create and update their tools to support the new jakarta.* namespace.

  • A platform that development teams can use as a stable target for testing migration of their applications to the new namespace.

  • A platform that runtime vendors can use to test and deliver options and capabilities that support migration and backwards compatibility with Jakarta EE 8.

  • A foundation for innovation that Jakarta EE specification projects can use to drive new features for release in Jakarta EE 10 and beyond.

2.22. Changes in Jakarta EE 9.1

The goal of the Jakarta EE 9.1 release is to deliver a set of specifications functionally equivalent to Jakarta EE 9 and adding the support for the Java SE 11 runtime.

Jakarta EE 9.1 is an extension to the foundational Jakarta EE 9 release. No API updates are expected in Jakarta EE 9.1. Only the Platform and Web Profile Specifications along with the TCKs and Compatible Implementations should be affected by Jakarta EE 9.1.

3. Security

This chapter describes the security requirements for the Jakarta™ Enterprise Edition (Jakarta EE) that must be satisfied by Jakarta EE products.

In addition to the Jakarta EE requirements, each Jakarta EE Product Provider will determine the level of security and security assurances that will be provided by their implementation.

3.1. Introduction

Almost every enterprise has security requirements and specific mechanisms and infrastructure to meet them. Sensitive resources that can be accessed by many users or that often traverse unprotected open networks (such as the Internet) need to be protected.

Although the quality assurances and implementation details may vary, they all share some of the following characteristics:

  • Authentication : The means by which communicating entities (for example, client and server) prove to one another that they are acting on behalf of specific identities that are authorized for access.

  • Access control for resources : The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints.

  • Data integrity : The means used to prove that information has not been modified by a third party (some entity other than the source of the information). For example, a recipient of data sent over an open network must be able to detect and discard messages that were modified after they were sent.

  • Confidentiality or Data Privacy : The means used to ensure that information is made available only to users who are authorized to access it.

  • Non-repudiation : The means used to prove that a user performed some action such that the user cannot reasonably deny having done so.

  • Auditing : The means used to capture a tamper-resistant record of security related events for the purpose of being able to evaluate the effectiveness of security policies and mechanisms.

This chapter specifies how Jakarta EE platform requirements address security requirements, and identifies requirements that may be addressed by Jakarta EE Product Providers. Finally, issues being considered for future versions of this specification are briefly mentioned in Future Directions.

3.2. A Simple Example

The security behavior of a Jakarta EE environment may be better understood by examining what happens in a simple application with a web client, a JSP user interface, and enterprise bean business logic. (The example is not meant to specify requirements.)

In this example, the web client relies on the web server to act as its authentication proxy by collecting user authentication data from the client and using it to establish an authenticated session.

Initial Request

The web client requests the main application URL, shown in Initial Request .

Platform Spec 3

Figure 3. Initial Request

Since the client has not yet authenticated itself to the application environment, the server responsible for delivering the web portion of the application (hereafter referred to as “web server”) detects this and invokes the appropriate authentication mechanism for this resource.

Initial Authentication

The web server returns a form that the web client uses to collect authentication data (for example, username and password) from the user. The web client forwards the authentication data to the web server, where it is validated by the web server, as shown in Initial Authentication .

Platform Spec 4

Figure 4. Initial Authentication

The validation mechanism may be local to the server, or it may leverage the underlying security services. On the basis of the validation, the web server sets a credential for the user.

URL Authorization

The credential is used for future determinations of whether the user is authorized to access restricted resources it may request. The web server consults the security policy (derived from the deployment descriptor) associated with the web resource to determine the security roles that are permitted access to the resource. The web container then tests the user’s credential against each role to determine if it can map the user to the role. URL Authorization shows this process.

Platform Spec 5

Figure 5. URL Authorization

The web server’s evaluation stops with an “is authorized” outcome when the web server is able to map the user to a role. A “not authorized” outcome is reached if the web server is unable to map the user to any of the permitted roles.

Fulfilling the Original Request

If the user is authorized, the web server returns the result of the original URLrequest, as shown in Fulfilling the Original Request .

"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABSQAAAHrCAMAAADhQGM9AAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAA5FBMVEX/////////25A6AAAAAAAAOpDb////tmbbkDpmtv//27aQkGY6OjoAOjo6OmaQkLb//7ZmAAAAAGa2//+2ZgD//9uQOgAAADqQ2/9mOgA6ZpC22/86kNsAZraQkDq229v/29vbtpBmOjoAOmaQZjo6OgC2kGaQtts6ZmZmttu2/9tmZmZmZgDb27bbtmZmkNtmkLZmkJDb/9u2/7Y6kLa2kDrb29vb2/86Zra2ZjpmZjqZmZlmZpDbkGaQZpC2ttuQtv+QtpCQtra2kJCQZgCQZmbb/7a2tpCQ29tmtrbb25CQ27bPokIeAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAHdElNRQfjBxMGBhIN5k2RAAA2AElEQVR42u2dfX/ctrlg70i0ZqTIauJwMrEs13qLHbeV4t7bxHaTbG+btnt39/t/nyX4+gAEQHKGbyLO+SM/C0OAfDCYE4AAwf/4DwAAAAAAAAAAAAAAAAAAgNmzAgAAJ0gSAMADkgSYI0fHUfTsRCSso8hI2SQJp+4S1v6PK86+OE9OFj2/+N1Jm8ODA0kCzJEvv4qiF1+LhFhJUqZsv4mi3bfuElpK8uxlVHH5auq4ZwiSBJglsa5AJU3deirlmafv106Sm0hj16rvGRZIEmCWKMddVX+q4XfCa+cB1gIalbeOIizZAJIEmCXKikKJSY/vxe+1rmPDLclWkkz7p7vLN6rU65tbc0QPCiQJMEvULcdKieqv12s5AlcpXqG1kaQS7V11HzLtrl6tQANJAswT7aak0teV6veVClN/vPblbyHJ2tzPOvLf5wwSJAkwTzTJZZ3IWHix6ZZkG0nWRNvYPQ0RJAkwT7SbknHaw9sIhW30TuDZ/XdqraNYw5NJcvtWpV+8s3YP671Ro1RLsUmeF19v3x4bk+3mXHs9o8j5/HvP0qXZgSQB5om8KZnbTHnztP6pttjxWaGlVJL5pHiivveOU/g6jrZiler+8E2eWnVl9X6rLaPMuUOSAHAwcWWwXEHipqTWCSxVKAWk8vxRpNvG5mri5rXzHqS1WKW6P5UGLPPGUrfWjDLnk7rviSQBZoronBXj7Lj0i+y5pU66eJP86+G+stK6eojm7N5YiF6QLwGyP2djLzZb1Z70D7exLkDD2bWMIufjD1PXbReQJMBMqfqN6QIg9Y9qEZC4Pak+jYrR9GP5zHcmyTz90dF9W+d9vosPb8yPHMWmqkv/mc64F+UICTsyipxPCyQJMFNKNVY6Km9KyluS+jx3qau1NsZ2LT0/qu4ePv+z1qN0FJuq7lS/Pn207cgocj4tkCTAXCl7i+Wcc+klcXdSn8LRep0i3bmsspiozu4fftCWr9uKFTtvVL1ZWborY33PjicCkgSYK8XgWminuCm51m/1yUmZQl3GQsrYbaizL74rNXknZrGtxYq1PtVku+ynujI27sgxV5AkwFwpdCO0U8ixPvNdUhxipG/8C28e3t7WJ8dtxYpOY9lJ1DqProzNzwjNFCQJMFcKCQnt5L6UtwNrG/lUkpRWbPEATjYJLqbPbcXKjuLGMoXjzFjrYj4VkCTAbMklFOsz2fqqcnNHyPJJmO6SzBeBn3qLlapLLiM9hdZLdWVEkgDQN5mEtGFqdodPCnB/SVrGv9WzkG0kqZR9ZU7VIEkAGAullVOt25h7MxZWct1sbCdJYyal8p2rWE11m7JfW9nPefMTSQJA38RKK5p1Um/mPbgM1zi6eeLG8pacSpKuYjXVJXpM+rV60c5xPZIEgL5RNyX/U193qLxp9i2tk8YtlgClj25rKVXn0lWspjrl1FNjYaQrI5IEgN5RPbX/0t2ivPkohWdu5ROLdZINi8nTh6y17YHiUpuuYnXVqfG2pmx3RiQJAL2TeGX3hT4mVt78vfn6G/Fn2ZFba5taxNZBsEqN/lI9ZfOjWCjpKFZXXZL87Eejj+rIiCQBoH8Si53XXre9+06zTfpMdPH32VeF5taRYTzL0y7Zxjz5m8B+yh5QfO0vVldd/qbb17VC6xmRJAD0z7ruoFjKrzroTm0+fv22epXXOn8a++Nq9XAbuabA5c6PKZWQ7cUaqoujqNZHtWdEkgDQP9n2tZqD1lGtV/ioqe5Tedzui+oDxzOJR4YlxbsT7cUaqlvrYvVkRJIA0D/p3oy6g1KtGXMw4nUJu2JD23SdZNlTvHvlOsNn4TOxC5CrWEN16di6NiNky4gkAWAA4lq3MfVmbQ7mIX3x1k688StbTJ6+CCxJ9pxie/PXc6Wz55f1o+rFmqqzzwhZMiJJAIAlgiQBADwgSQAAD0gSAMADkgQA8IAkAQA8IEkAAA9IEgDAA5IEAPCAJAEAPCBJAAAPSBIAwAOSBADwgCQBADwgSQAAD0gSQiQCMHE1FiQJITL17xFmiKuxIEkIkal/jzBDXI0FSUKITP17hBniaixIEkJk6t8jzBBXY0GSECJT/x5hhrgaC5KEEPH/KiA0kCSAAZIECZIEMECSIEGSAAZIEiRIEsAASYIESQIYIEmQIEkAAyQJEiQJYIAkQYIkAQyQJEiQJIABkgQJkgQwQJIgQZIABkgSBD+nzeHnGtmnSBJCBEmCAEkCmCBJECBJABMkCQIkCWCCJEGAJAFMkCQIkCSACZIEQU2SKyQJoYMkQYAkAUyQJAiQJIAJkgQBkgQwQZIgQJIAJkgSBEgSwARJggBJApggSRAgSQATJAkCJAlggiRBgCQBTJAkCJAkgAmSBAGSBDBBkiBAkgAmSBIESBLABEmCAEkCmCBJECBJABMkCQIkCWCCJEGAJAFMkCQIkCSACZIEQVdJHh1H0bMTkbBW+bWUTZJw6j7j2v+xxs39uSr+/Jc3IjEuzrf9xjhzaz6OULPwdEGSIOgqyS+/iqIXX4uEWOWXKUpdu2/dZ2wtyevPUcXdO3nGwyR5dv96xBqGpweSBEHn4XasK1BJU7eeSvGpq60kH48jjU9FmYdK8tfjCEmCDyQJgs6SVI67qv48ylT22nmAtYAWkvwcmRQ+PFCSSuJIEnwgSRB0lqSyonDMJhlr/15zVcMtyZaSzBz5/MNPyb+3D/fHwsTxvnciM5AkNBGsJKMAaa6VzpLUu2/qr9drOQJXKdpNS5NWkkyng3bvtbMW2ZAkDAySDIjmWum+BCiWSlT9yiulnXKA3eigNpJM73S+eCVStslpczciSRgYJBkQzbXSXZKa5LJOZCy003RLspUk1ZDdmCFXbsuSkCQMDJIMiOZa6S5J7aZkJqyNGGFvdL2d3X+XlP/8suoVZpLcvlXpF++stksH16ZpN0VabJu4qZ8nuc7kQrY3t0n67rJYaBmXddN2rSaER9tfz+KYWlhT0Fwr3SUp1ZT3ypQ3T+ufJup6WV7Ks0JfqSSPivU94r5jhfq0dl/zy//1t6zcuC5J23lSSVbriC7LzDlIEly0/fUsjrACH06SyjOFwfKhs7gpqQ1mj+RSx6J/qfL8UaRbxuaq0+geEdclaT2PkuRfRXp5QxNJQgNhuSLYwAeUpLipWIyzS29pdxxTd12oge7DfWWvdd6ze6XGyHZbxV6H1SRpP09uzk8fi2d38hK5JwlNhOWKYAMfUJJVvzFdAKT+US0CErcn0zuLxWj6sXzmO5Nknv4YWWZhGh5sNCXpOE8qyaKYTXUeJAlNhOWKYAMfUJKlGrMFQMU/TovPCunp89xlF3OtjbFtS8+riWwrpiQd50klWRQtVm8iSWgiLFcEG/iAkqx6i+VMdulNcXfSeGhQ9jpFuk1ZtU00dAxJus6jz/7EpXeRJDQRliuCDXxISRaDa6GnQlzi4RttifmqUquxkDKuC7GbJF3n0Z+f3CBJaE1Yrgg28CElWWhJ6KmQY33mu6Q4xEjf1IfW3e5Jus5T3gswToMkoYmwXBFs4ENKshjRCj3lvqxuV5az2JJCktKAlgdwukvSdh4kCfsSliuCDXxISSrjKE3F+ky2vqo8nZIxUZ81SzJdAuR+tNGQpOs8SBL2JSxXBBv4oJLMnvjTbJPdCZQCPECSKq3usfXFh/S1C0gSBiYsVwQb+KCSVJ451bqNuTdjMdG8cYyZW0jS+lhiOUFdl6T1PEgS9iUsVwQb+KCSVJ660i2YelNZq/SSa7ef5okb+wYX5SvIGiZu5PFIEvYhLFcEG3hkyk+6T7CfJNVNyf/U1ycqb5p9S6uMmpcAZccY6qzEaUjSdR4kCfsSliuCDXxYSSYCevFf+vpE5c1HKTxzi/JYrJP0Lya3bbqbvs8hKy6uLya3nQdJwr6E5YpgAx9Wkolodl/onT3lzd+br78Rf5YdvnUkx8exfbBsvr7hLH19w1WRRXss0XEeJAn7EpYrgg18WEkqUZ3XXre9+07rW6bdweLvs/J57HW5knGlbTxRO4E6rHgRWPrXM/t+ko7zuCS579u6IRzCckWwgQ8syWwFt9Yhi6X8qoPu1Obj12+PS5Gtc/19XK0ebiPXsvHszV8ad1+XJ9K3SrOfxyfJ3bvV9uPUXxHMlrBcEWzgA0sy26xRGyevRWcv51Fuhht9Ko/bfVF94Hq0Zmu+eLssuiZJ+3lckiwWcHpfxANBE5Yrgg18YEmmHT19Vjr1pnGzT7xWYfdDnpauk1wXWrt75TrF6ualMJ+4Pxl7X99QnscpyXR4zn1JcBOWK4INfGBJpoNrvduYerM2B/OQvqBrJ974lS0mT18EliR7g7h+e6tyR+e/vBGpFknazuOUZNJJVYr+xH1JcBCWK4INfGhJAiyXsFwRbOBIEmBfwnJFsIEjSYB9CcsVwQaOJAH2JSxXBBs4kgTYl7BcEWzgSBJgX8JyRbCBI0mAfQnLFcEGjiQB9iUsVwQbOJIE2JewXBFs4EgSYF/CckWwgSPJORFHOs/zd5r1Vbh8QLRbwQ+36hHN8/+euoYMJt6iKSxXBBs4kpwTpiSjPp8d1yR5dt9p4458RyTPW86noGMQ/ROWK4INHEnOCZske9v5V0ry1+NOuxut80upv2VoSjoGMQBhuSLYwJHknLBKsi8TCEl2fTVF3GePti9m8H6NsFwRbOA9STJaGtN8G0pGYhe5/H0UPQ1y95ek+Q61eYAkCXzMaJHkLCW5yrco7mdz9MMkOb/X/SBJAh8zWiQ5V0m6X4G2T+EHSHJ+G7QjSQIfM1okOVtJKhX0M9RFkr0TliuCDRxJPilJnqVvn3h+qb/xJ3snxfPvs5dcuN5HUUoyLqO0vMm8KOyXV+ICcvQebfLBi6+36r2Tz7//1n1x27fnSer5+xN1Yf63+LaNsDmIkQjLFcEGjiRnLkkllEKS4j1mzyqJyLebvVsdKMmj2im8kvxD9kZfdQb7xal1Ohl3r1pIsl2ETUGMxpRtZVLCCjyLtidJTh1MjzUyzbktkhT3JI/kG3FLrwiJZbkPkeQmqp3CK8k/lR/YL24lXvi7+3ujJFtG2BDEeBz4f+L50S3w6Sp+XLJokaRZI9OcO6795h/VxWRCSQ1yod4Hma4MKhyi8lyq1GslpKTT2ShJ9+281JGqsG36nt7iFPZ7kpm7kg7f9vEH18WpAnefPiapWWfQL8m2EfqDGJGpnYYkRwFJ2mtkmnMbkvwpe6V4Jov0VbzFW8UfjwvjKbEUqtik2feXZCqp/BRbJaT8eI8kxRGOi5O+9EuydYTeIMZkaqchyVFAkvYamebcsbXlZj5ZR9Is68IW5T9WhTb2l2SsnSIuS/ZI8rS6HMvFSael5Xkl2TpCbxBjMrXTeqdb4NNW/nhk0SJJs0amOXdsa7if0o+MBd2lt3SzKPaWpEoVpzgq+3JuSeZjX8fF6QWqv3ySbB+hL4hRmdppSHIUkKS9RqY5t0WSu3z8qZQgVbHJDZWOaN/LQvaWpJ4xzZBJ0C3JvEDHxRkFxn5Jto/QF8SoTO00JDkKSNJeI9Oc25TkLp2vSJGDzvzvsv+VcPGPsg+2tyQ3xmPi2s1CuyRfey/OSF77Jdk+Ql8QoxJss19Q4K2jRZJmjfRRUPcsceWJdM5G7LyzjmpUxsn+/HO2srA3SZbWckvyyntxRoEtJNkuQl8QoxJss19Q4K2jRZJmjfRQzB6ZhCRX2ziSjtnUFZIfKpdafzg5QJKx8QBke0k6Ls6QZMNi8vYR+oIYlWCb/YICbx0tkjRr5PBC9skmJZkNM0vJuBWiHuUrF2HfHbBOcraSNCP0BTEqwTb7BQXeOlokadbIwUXslVGTZLbGptCWORY2uP7tNrvwZycTDLcdF9dZki0j9AUxKsE2+wUF3jpaJGnWyKEF7JdVl2R2My53gjmtYeEhtcjpmBM34p6k5eIOm7hxR+gLYlSCbfYLCrx1tEiye414s/cjyWwEWj2U2KgEdfyVrqB40CVAV1VOxxM8osCNXZLFFbaP0BfEqCy52YcSeAuQ5L414sm8d02YkhS3Jc1XKBQGi+UK7NQ+mjyqFdyDLCa/qq7TcnH68nD1V7VnRv0K20foC2JUltzsQwm8BUhy3xpxZu1RknLArfpQr7UPXufJ1RhZpZ5qrltHgz6WWBztvriqwOpSHFfYOkJvEGOy5GYfSuAtQJL71ogj40EVUZOkGHCn0ziFcc60R/wK4eR9NeG6VLJ1STpeWtN9g4sr8W/LxcktK9b6pViusH2EviDGZMnNPpTAW4Ak960Ra7beJSkG3Oli67t3iRau34rXg6k8u/cf1bsVX2ZdsfRAtT/Z2X16NXZJ7t6tth+N86c5u2yVpnUTLReXKlDtMn79WV6K4wpbR+gNYkSW3OxDCbwFSHLfGrFkOtSRrp3Jc7k9yi1p830vyqf2ctSRMqXa6Va7t5evSaztG6FvunsqTtEgScfFZf3HvLjz0oaOK2wdoT+I8Vhysw8l8BYgycYaWTW2mchg73NbJClnuOWTJz+UB2zvhVeyiZZyP3DxzgRNkvlm33Xz3VSnqF4z00aSjourknffipuL9itsH6E/iNFYZrNvbvBLCrwFSLKxRprajKnIA6rBJkntwZvshVi7i3favbizL9S7tqLzD+XIM32dVnKYWMGtzxJvPx/rxim5SU9xLh+TbiVJ18Wtbm7Vu8I+nOgzMLYr7BKhP4iRWGazR5LWaJGkp0b8bSaKepTksml4pOYJsqDvG0k2RYskPTXiazMRjmwPkpwxSLIpWiTpqRF3m4kiJNkBJDljkGRTtEjSUyOuNhPhyG4gyRmDJJuiRZKeGrG3mShCkh1BkjMGSTZFiyQ9NWJrMxGO7A6SnDFIsilaJOmpkXqbiSIkuQdIcsYgyaZokaSnRsw2E+HI/UCSMwZJNkWLJD01oreZKEKSkLOg7xxJNkWLJD01IttMhCOhYkFfOpJsihZJemqkajNNilxIDUBbFvSlI8mmaJGkp0aKNtOsyGVUALRmQd86kmyKFkl6aiSLtIUiF1IB0JoFfetIsilaJOmpkfaSnPrSYWQW9LUjyaZokaSnRpAkOFjQ144km6JFkp4a6TDchhCZusX23eyRpDVaJOmpESQJXqZusX03eyRpjRZJemoESYKXqVts380eSVqjRZKeGkGS4GXqFtt3s0eS1miRpKdGkCR4mbrF9t3skaQ1WiTpqREkCV6mbrF9N3skaY0WSXpqpJMkp756GJMFfedIsilaJOmpkW49yakvH0ZkQV85kmyKFkl6aiRvM1gSTBb0jSPJpmiRpKdGyjaDJEFnQd84kmyKFkl6aqTLfpKLqQVow4K+cCTZFC2S9NSI0WawJBQs6PtGkk3RIklPjdTaDJKEjAV930iyKVok6amRbq+UXUw9QDML+rr7luSXX0Uvvi7+2P52e5wc//z7dyf6UWv5szm/fCM/i6NnJw3Zu5Fc0n4vokOSjTXiaDNYEhb0bQ8oye3n6pex+0E7am38cO5eyQKumrJ3o0mSN7eOT5FkY4042wySDJ0FfdvDSXL7jfbbeCZ7g6YkRe/z6Dgzmi97N/ySTM6zQ5ItaS/JlduTUwcBo7CgL3s4ScbJkRfpQPn65mXy7ytx1Fpa70F9+rr4a5Pn92Xvhl+Snk+RZGONNLQZLBkuC/quB5Pk0bEQ2zZRnlSRJsm001h8mvz7dWP2biDJ3ugqSbsmp44CxmBB3/VgktzUPCj6grokUyOelv88bczeDSTZG90lubJ5cuowYAQW9FUPKUmptY0YUdckmWQqDt60yd4NJNkbe0lyVfPk1GHACCzoqx5Skm6tGZIUHcU4z+XOfnaf9Dt3l6+0xOTw0+3n42gnb2+q+5pXNQ1q+VUfVmH1JJJsrJGWkjQ1OXUcMDwL+qYHk6SawH7vOsrZkywXALmyVwuDPsn5biXJOP+gnCnP7ahJ0siPJDuxvyRXmienjgOGZ0Hf9GCSTJfw3DmWgRuSVEY8zf+V68qRXS4Mkj3NRJLnaeKzf5a3N4uzSEma+ZFkJw6S5Ep4cupAYHAW9EUPJsm0e6j08/0/PtaOqs9ul+uGinR79o3qAiYJ16pDeKWnR385WV1/XFf2jDNfSknW83NPsgOHSrLU5NSBwOAs6IseTpKr7X3Zcbh8px8lJXn99jiqjbYd2ZU5T8siqhXoqfzKInLpFZciNGjJjyQ7cLgkF/XjAQ8L+p4HlGThv5Q7TZO1J25yZRYLgFzZ5XROHIljN9WIuZwXLw4WGrTkR5Id6EOSWSlTRwJDs8xm378kE7Y3//ouy2U8caNRTMJs9My17FKMa1mkWFaZiDb9pxrEn+aXVGjQkh9JdqAfSablTB0KDMwym/0gklRsb25VNtFHlJLcXXwo7joWj9u4shvPc4uDRRexeBi7kKXQoC0/kuxAX5JMSpo6FBiYZTb7wSSZcPZSm6pZ23es0Efb9eym5Koy5Dg67yJu6ncpbfmRZAf6kyQsnWU2+14laS4GT/wnXOSQZDXatmdvJ8nkEjKhVhM4SLIfkCS0ZahmHx+y2c2q4QE8+4e9SHL79vz4tDxLKjp98tk8u0OS1QIge/byNmONjf6gTXJstRRIl6SZH0l2AElCW2YmyXLX2MkkWT1WmHT5UruJPSssZ7dLUiwAcmR3VpAmyXS8Xc3R6BM3V/WTIsm2IEloy6wkKXaNnUqS6sJzRxX6U96UHtxoXUO7JNf6kzGW7HJvoI0xu11JMsn87N/VvVF9CZCZH0l2AElCW2YlybavcBlSktUyxVKXagL7WbkLxc2xbxegMvwq0Z5d7DKp3+TU72Fuot0XVVWKwC35kWQHkCS0BUkaKPns3qkddqJylBurQy/fnBRreOQ9Rqsk5eM2ruwq9e6Nugt6bGhR/pU+kV0GKwOv5/dsVYkkG2sESYIDJGm58oJyvaJIi4wtJKyS1BcA2bPL+WlpXWM2PJZT364NLsRGHPb5ICTZWCNIEhwgSZNqB7LLSn6Px5WR9P0frZI0H7exZq+e6L57peXVJLmW2tO3Sqvlzxa22+odSTbWCJIEB75mv32rnqO70B5VLreEvUh/rOa2sel4cvfpxJSkdXvZWP3800+efzgx9voqdXBzn76w+oPcQGdQSa5WD9nFaq/QTq4j3cDs/IOxEZBNkpbHbazZ0xMZFWxKUlvSbgRey/+ovrC/OKNFkp4aQZLgwNPsfy26P8bcbLYlrPqx1raNVY+TZB9qknRsL6skWXySFGeTZFFgkipGkQNLcoEgycYaQZLgwN3sN9UIUViy2hL2pL5t7FE5qnzxJ/mGQMf2snFRVlaeRZL5ToxVcgaS7AqSbKwRJAkOnM1eKUvt6rXV94SttoStb/uaylAlpG+XrjK5tpeNi1t0aX/x1NwuMflncsTu/Uk+g1vlRJJdQZKNNYIkwYGz2cdlB3JjPFlc2Kq27avyavYyl1SXYnGffXvZOBIbNxjvuUr/qeesLgJJdgVJNtYIkgQHrmYv/KQpSd8SVt/2Na4SxFJn9/aycaXMLKspSWHGbKuHleWKjFCQpDtaJOmpESQJDlzN3rFvg+xWxsa2r9qeC2LiJnZtLyukurFKUpzXN8mrhYIk3dEiSU+NIElw4JGk9WXRVbewtu2r2eO8chxXlhWbvU2HJLc//e9/HUdI8gCQZGONIElw4Gr2m86SlBsxyC6je+fENpJ8uP+uyIgk9wdJNtYIkgQH85ZktUwSSR4EkmysESQJDg6TpPaYsGe4bd9etlGS+TLJ8+///Ld/c0/yEJBkY40gSXDQZuJGClP8OzYeE/ZM3Ngf426U5CZfJrli4uZAkGRjjSBJcOBq9mIJkCa/jTYjrW/7utFW7EgB2reXbZSkOGDNcPsQkGRjjSBJcOBs9nGpNs1PG+tayGzb1yoh3RzsynWcOIVXkv+jvUoBSR4AkmysESQJDpzNvnws8cfI9XIBZUJt21eVoB4zfNAfS6wdV6XrkhS7xhY9yXS4nT7PiCQPAEk21giSBAfuZu/c4KLUXG3b1yph91fHBhdyn0WrJKNsbJ968Ehswyh3uECSXUGSjTWCJMGBp9k/OrZKE6+pui8Elm/7Wuhwd6rdfHRsL1uTpNg1NvNgKerd//nGtfesEQqSdEeLJD01giTBga/ZOzbdlUuDatu+PqiXuFy80mdoHNvL1iVZ7Rpb7CeZ7n978e5EOzGS7AqSbKwRJAkOltnskaQ1WiTpqREkCQ6W2eyRpDVaJOmpESQJDpbZ7JGkNVok6akRJAkOltnskaQ1WiTpqREkCQ6W2eyRpDVaJOmpESQJDpbZ7JGkNVok6akRJAkOltnskaQ1WiTpqREkCQ6W2eyRpDVaJOmpESQJDpbZ7JGkNVok6akRJAkOltnskaQ1WiTpqREkCQ6W2exHlOT25q/qUcr00UmR6tiOXds7eJq6QZL2GkGS4GCZzX40Saa7vxV8qjTZlyRvbr/tcHSrukGS9hpBkuBgmc1+LElqLyqTm7n1I8mklB2SHAYkCW1ZZrMfSZLpfpe7Dz8l/7xOd0yqXhXufPtZF+y7HR1YN0jSXiNIEhwss9mPI8n0ZY7lGDvdwr1wGpKcO0gS2rLMZj+OJOOkgPfib7VlsOt9u3uBJIcDSUJbltnsR5GkeMFZjtpIPVMjkpw7SBLassxmP4okN5E5CaPG31lXMpOk2qZ9d/lGPyLLk225fvnKKFNuBl+84acPTyLJxhpBkuBgmc1+DEkqD7420kpvppIs3tBzWS0NyiW5/WxZNpTwq3ytEJIcEiQJbVlmsx9DkqrbaI6o14XSlCT/WC4Nqt6klklSvj5SelZ/QSWSHBIkCW1ZZrMfQ5KJw2r6KsWZafDZq3wp5ZU4IJGkkuGnj/n7xK9kidmrzotk7kkOB5KEtiyz2Y8hyXVkl2QqvVSS+e3JWNy7TCUp+qBreV8zLvucm+xfSHI4kCS0ZZnNfhaSLOwnx+WpJOXbcWPts+LfuR2R5HAgSWjLMpv9LCRZjqPj6t+pJIUYVSlX1T+fnZjFIcmBQJLQlmU2+1nckyxFKHqOSpJ/ENM2cupmXZstR5LDgSShLcts9lPNbpfi1LamWPslWXQfN0hyRJAktGWZzX4O6yQrvW2Q5PxAksER7dt8l9nsZ/LETXWgKclTe3lIcjSQZHgU3ZJVxza8zGY/iiQrJRboz277Jm6uLOXJiZtMmEhyOJBkgIjxW/dsU198jzUwniRTJ0rbrauxs5JkYTw5w1MsAZI2FAIteph5RxRJDgeSDJFoL00us9mPI8l0xXj18LVyptxPMref9GUmSbF9kDZFHpcH5mvMkeRwIMkgifbR5DKb/Ug7k5+pXXe1ncmLe43ZY4nq0cObl5G4BZk9lpjYMLp7k78hpxqxl48l/pgbVhu091U3SNJeI0gyCPRJ03ZteZnNfhbvuKk2uKhEV9/gQs796BtcFKrtYWNKJNlcI0gyDAxLtmnNy2z2k7wtcWe+LbFwnugMFlul3ReZ7rQdJR/lVmmr7C5nL51JJNlYI0gyDKI67bJMfeE9Rj+uJBNu7tVA+/n3lvdu39yaG+uWm+4+qE138911ZT6x6a7iUf35l17rBknaawRJBkIUdfXkMpv9mJLsRNf3bg9QN0jSXiNIMhSirppcZrOfrSSPjpHkPECSwRK58GeY+rJ7jB1JNtQNkrTXCJIMhijq5sllNvu5SnL7z9p2aKPXDZK01wiSDIeomyaX2exnKcn8nTX9LHzcv26QpL1GkGQ4RH7sh0990T1GPl9JZut57qYYbSPJ5hpBkgERNWE5eupr7jHw+UpSLYLcfZpisI0kW9QIkgyJRktGtYOnvuQe456vJKcESTbWCJIMiWZJioa+zGaPJK3RIkmzRgC8iLYydYvtsdkjSXe0SNKsEQAvoq1M3WJ7bPZI0h0tkjRrBMCLaCtTt9gemz2SdEeLJM0aAfAi2srULbbHZo8k3dEiSbNGALyItjJ1i+2x2SNJd7RI0qwRAC+irUzdYnts9kjSHS2S9NQIS4CCooMjl+QKJNkULZL01AiSDIkOilyUK5BkU7RI0lMjSDIk2htytShXIMmmaJGkp0aQZEB0MORqUa5Akk3RIklPjSDJcOikyEW5Akk2RYskPTWCJMOhiyFXi3IFkmyKFkl6agRJBkMnQ64W5Qok2RQtkvTUCJIMhY6KXJQrkGRTtEjSUyNIMhS6GXK1KFcgyaZokaSnRpBkIHQ05GpRrkCSTdEiSU+NIMkw6KzIRbkCSTZFiyQ9NYIkw6CrIVeLcgWSbIoWSXpqBEkGQWdDrhblCiTZFC2S9NQIkgyC7opclCuQZFO0SNJTI0gyCDobcrUoVyDJpmiRpKdGkGQQ7OHIJbkCSTZFiyQ9NYIkg2APRy7JFUiyKVok6akRJBkE+zThWp6fnyxIsilaJOmpESQJDqKlgSTd0SJJT40gSXAwtdOQ5CggycYa6SzJ7Tdawzu/+N3JIRf0sVOyzjo5/+mBFaLCeXZQBN2IO59u7CssmdppSHIUkGRjjRwqScWnvX/CZ/evOySbIMlBmdppSHIUkGRjjfQhyb1/w78eR6/bJ9dAkoMytdOQ5CgMJcmfnyzDSLKd02p8+ZU1pyO5DpIclKmdhiRHoVdJLohDJbn7tvzzp7fHkZbQgTlIcmziiYy3BzVXTP1/+F5AktZokeSAklytjpQlr/b5epDkrEGSQYAkR5DkahPt+cNHkrMGSQYBkhxDkqor+eLrPb4eJDlrkGQQIMkxJKmkJiT5cP9dcornv7zSsuWp378rU+LycjTRWZLtJRaS3L5Vn168K9WjpF0N/zficusXoU+LJDmTY7c3t8lRu8s32snOsryX2kXUCrScQaeSpD2q7dvzJPX8/YmKLq3V+sTNzW0S4e7CeY6eQJJB0JMk68cvh74lefSylNyz6ud/VqXuit92W0naS1SkkkxviaYFvy8uwSFJ20VYJPlYFBhdntgCqC6iVqD1DDqFJB1R/VpG861LkjdlzrtXqyFBkkGAJPtoMzr+4fZGdljLw5RGK3L5tZSkvcQUJck/ik+vquuxSNJ6EXVJ/lUcJD+oX0StQPsZdHJJOqL6LBL/aJfkxppxCJBkECDJPtqMjnfiJv0Fq3HqNu3vFMfFeerqWlmg7HW2uSfpKDFlnXf4XqnBcOUlhyTtF2FKUvHpY35Q2ZlV6Rcq78N9dRG1Ah1hamSSdESlkncfTsreokWS6+IC04gHvb2JJIMASfbRZnRqklxXS4BSmeSj3u3n8keskgvrbUQfq4UkHSXmZ06/tvzTR+10dUk6LqIuSWms7JN0/XwxmFej8WzAbBboClMjlaSnnl5kQ+htbJdkeimiKz7kvBWSDAIk2Ueb0dEleZ1OchS9pjiSeip/xGuHGFtI0lFixjqSn5ZeskvScRF1ScqBeBbXWruIoqBagetm/+eSdEQl55hSG9YlKS9FnWPIriSSDAIk2Ueb0bE+lpi5wfjVHhV9Ll0yFc2SdJWYsdZ6lmU2tyQtF1GTZDVKjvOcxk1B9edrW4GuMDWUJP9tj0qvjrVVkrFxgXstvWoJkgwCJNlHm9GxSfJT9pFup+pHrNLLuWdBsyRdJWYYVpKnsw+3LRdRk+TrWk51PfIiNtl5agW6wtRQkvy/9qhU/qqfXK4ZkFfYeglpH9RdMXVj7bHZdwt8ySDJ5tbS3GZ06pIsxbAx7lZuRFdMzXz8wxgbNkvSVWKGsZhc6rAuScdF1CTpH6jnp1XptQJdYWooSf5oj8oINrZI0vyfxqAgySBAks2tpbnN6Jib7v5SLQjcWGafy7uEmU//LJf2dZek7qu1/mnxoWN2234RLSVp/n/hW1uBjjA1bJLML3yjj55dkhztGSMkGQRIsrm1NLcZnfoSoBLzHlmlNLnK+kP9LqKOSHaXmP/VQZL2i2ghyU1dktlF1Aq0h2nW0bN/2qMygt1YJDnqg5hIMgiQZHNraW4zOntJUi3rK9dj37VfJ9mrJK0XcYgkLQXawjTrCElOT8fAlwySbG4tzW1GxyNJ/+B4df3bbfaFNExDDDTctl9EO0l6Hm2pRVVL0PAMt+Pm4TaS7KvZdwt8yQwlyQW1lhZtRqeDJC12ebgV/bBRJ24cF7HHxE0dLSprQkn8lCduAiGswJHkqJL0L9jJUYPX/KBRlgDFtsutLqKFJPWFQXY2kWGvWkJ1Oa4lQLqMWywBGnhBUFiuCDZwJDmqJF1Lv2OZLEQ00GJyrVj1R3q5jotoIcnq0ZuM3Gm1AiNHmBpxj4vJBx58h+WKYANHkqNK0vUQoTaOFKtYenks8bT2oWZWdUz9zmJ1ES0kmfYKq+ssOpa1As8dYZpV5HwsUXZ6WzyWOPoTN6EQVuBIclxJejZuKH7mMrvjPYDmTTj/Bhf1/SikWastKxwX0UaS6RZoRfrZV64C/+4IUyNut8FFtmmafYOLXS7fx2jYx2/CckWwgSPJcSWZacu+Vdru/cck+eGl+GWnRb1bbT9azlAkO0qszhbtPnzMZ0qKD/XtxORWafWLaCPJrMA7tff59dtqz6NagY4wNbJBuiOqcqu0h+at0jzbsfVEWK4INvDBJBkwXkkam8nKDXUqql98fvSVvZArT4kpagnQF9V2uPpQtUj8+3H+gf0iWklyVe1WnjrKEZUrTEls23RXu2WQc/cn+6a7jzLjuJvuhkJYgSPJ/vFLUrxcIBKvg9neC8VUP/h8K2+zy6Un20tUpOsk14W/xMsMtuUO33evjo7LkbXtItpJUnuW5gdnVI4wJbkkXVGV8kxvXFpf33A02esbQiGswJFk/zRIMvn5py+4OjceXz77Qr3gKjr/oI2tt5+PbT4xku0lFovJ0xeBma/FSl/blSZWkrReREtJFu/t2okXjtkKtIcpiMvT2aO6zl9rVh05nxeBhUJYgSNJeKoU21ZOR1iuCDZwJAlPB70fa+5iOT5huSLYwJEkPB30lfOjPqZtJSxXBBs4koSng/a+Mf1NEpMQliuCDRxJwhOiXD25+unz8eQdycBcEWzgSBKeEmKZZDT1HcnQXBFs4EgSnhS/VovW74Ze4dNIWK4INnAkCU+L7W9qDWT0/HJyRYbmimADR5IA+xKWK4INHEkC7EtYrgg2cCQJsC9huSLYwJEkwL6E5YpgA0eSAPsSliuCDRxJAuxLWK4INnAkCbAvYbki2MCRJMC+hOWKYANHkgD7EpYrgg0cSQLsS1iuCDZwJAmwL2G5ItjAkSTAvoTlimADR5IA+xKWK4INHEkC7EtYrgg2cCQJsC9huSLYwJEkwL6E5YpgA0eSAPsSliuCDRxJAuxLWK4INnAkCbAvYbmiFnhYIEmA7iDJgECSAN1BkgGBJAG6gyQDAkkCdAdJBgSSBOgOkgwIJAnQnWAlKfk5VOo1gSQBDLpJcvvb7XFy+PPv350cfuovv4p2304df8rUrpqMek0gSQCDLpLcfq5GbrsfDj41kpycek0gSQCDDpLcfqPd4Hp2aGcSSU5OvSaQJIBBB0nGyYEX6Tj7+uZl8u+rqa+9N6Z21WTUawJJAhi0l+TRsfDiNjHmTLqBPTC1qyajXhNIEsCgvSQ32ghbjb0X05Wc2lWTUa8JJAlg0EmSV/qfr6e++L6Y2lWTUa8JJAlg0EmSLiue3SdD8d3lq+rv79RCocs35mFacjlx83CrZ09JxvOnWcHPP/Sw3sjL1K6ajHpNIEkAg/aSXCfHvbd9UK0M+nSi/x3dvbIdlifnkqwmzT9JGSpJFjmGvvs5tasmo14TSBLAoL0kU5nd1VeRy5VBaVczFuuEXnxdHldLziSZ/Ne6qig5/Ly/5UZ+pnbVZNRrAkkCGHRYApTrbPf9Pz7K5I3qAyYp15+zZUFqFlz9vbr+Ua4TqidnklTuVCPtB2NVUepU9cGZ+uB00EpwGGPJIEmAlnR64ua+7NpdvisSlTpzha3TLqK4dylvY9aTU0lWC4vUqiKj43lVnmHYifSpO3STUa8JJAlg0O3Z7eu3x+V9xVyTUoTpZEuScPd1PWs9OZVkXI2lhW6zsgplxkNPpE/tqsmo1wSSBDDovAvQ9uZf32WZst5dLMy2VolqgicyhuTZZ0aykuT/fCOyazKM7R3SQZjaVZNRrwkkCWCw11Zp25vbKL9RaDzQndisTLn4nZxuqScrSf4/+fz2Ws7QxNUYG0kORb0mkCSAwV6SXGXTKcpopiSTNJF0967KUUtGkpNTrwkkCWDQWpKmqY6OjVWOYrHOWTXDI2dcjOT5SBIKkCSASWtJrrW5Z20puG19znW2Pa+5Dlwm1yS5Me5JIsnRQZIAJq0lqdbqSBsWDxXG7vU52x8j24dFcuPEDZIcHSQJYNJakqrLKB982eQ9S7k5kNoDY2to76rKbiSnmt14lgAhydFBkgAm7Sdu1BqeZ+Wz2DfHubnENpPZbUqhPbmfWj25cTE5khwdJAlg0mF2O3tQ8M1JsQQoN5pKvnuTJL7NvKm0lz3irZ40LLVXT258LBFJjg6SBDDpIMltrM1jFxMucn67GIBXVNqrJTducIEkRwdJAph0Wif5eFwJrdr+sXqkO98Z7dfysJ3cW81Mzqd+vnxZJJtbpSHJ0UGSACYdF5Pf3Kf7l51/0J46fFB740YX5crx67fpURfGvmpGcrnp7o1aFvS8vukukhwdJAlgsu8TN7BIkCSACZIEAZIEMEGSIECSACZIEgRIEsAESYIASQKYIEkQIEkAEyQJAiQJYIIkQYAkAUyQJAiQJIAJkgQBkgQwQZIgQJIAJkgSBEgSwARJggBJApggSRAgSQATJAkCJAlggiRBgCQBTJAkCJAkgAmSBAGSBDBBkiBAkgAmSBIESBLABEmCAEkCmHSV5DZ9tWH0/PLN1FcOA4AkAUy6SXL7uXrx9t2rtrkKbm6/7Xx9++SBvUGSACadJHl0HAl2p53OtP0mf832wHngAJAkgEkXSaaOvHv3Mfnnw73K1smSX37VXXj75IEDQJIAJh0kmRgr2r0v/jpL/nrxdYczIcknAJIEMOkgyTjSjKX6lVcdzoQknwBIEsCkvSRrUtxE0bOT9mdCkk8AJAlg0l6SG3N4fXT7y9+yfz2oZUG7S226O1a3LM/ukw+efzip5nxK56UfaXnUIa+rf57W88DQIEkAk9aS3H5TKszyScYn0bFUkiwWDCWWM4RXrSUSeTbFx/m5kOToIEkAk9aSVNM2V64PCsTwO5HkuUjXhVd5VZpXpaYl5J1WJDk6SBLApLUksxGwhcSGkRo1P7yMpEZVcpp+9jJbLCTvL25UF/LjanX9WcuT3/asTsU9yZFBkgAmrSW5dvToqvmcbS

Read the original on jakarta.ee ↗