Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP 7) is an application server that works as a middleware platform. JBoss EAP provides the necessary environment and infrastructure to host and manage Jakarta Enterprise Edition (Jakarta EE) applications.

JBoss EAP 7 is built on open standards, based on the Wildfly open source project, and provides the following features:

JBoss EAP 7 is a cloud-ready application server. It has a very small footprint, fast start-up time, and is automation-friendly. These features are essential enablers for efficiently deploying an application server to a cloud infrastructure.

Red Hat provides offerings for improving JBoss EAP 7 cloud and containerized deployments such as:

Refer to the references section in this lecture for more information about cloud and containerized deployments options.

To better understand the role JBoss EAP 7 plays inside an IT infrastructure, two application scenarios are presented. JBoss EAP 7 subsystems, referred to by the figures, is explained later in this student guide.

The following figure shows an example of how JBoss EAP 7 fits into a simple environment:

Figure 1.1: A single JBoss EAP 7 server instance

In this first example, the JBoss EAP 7 server instance contains two applications. The server instance connects to a database, and to a Kerberos server. The instance handles network requests and directs those requests to the appropriate application. The applications use the APIs exposed by JBoss EAP to connect to the database and Kerberos server, and perform their business logic.

A more complex environment is presented in the next figure:

Figure 1.2: A cluster of three JBoss EAP 7 server instances

In this second example, three JBoss EAP instances are part of a cluster. There is a frontal load balancer. The application state is replicated between the server instances by using the Infinispan subsystem. Thus, any one of the three instances can take over user sessions that belong to a failed instance. All three EAP instances have a web application, a web service, and an Enterprise Java Bean (EJB) deployed, besides having connections to a database and a Lightweight Directory Access Protocol (LDAP) server. One JBoss EAP instance also has a Java Messaging Service (JMS) queue, which connects to an external message broker.

In both example scenarios, JBoss EAP 7 makes developing applications easier because it provides Jakarta EE APIs for accessing databases, authentication, and messaging. Common application functionality is also supported by Jakarta EE APIs and frameworks, provided by JBoss EAP, for developing web user interfaces, exposing web services, implementing cryptography, and other features. JBoss EAP also makes management easier by providing runtime metrics, endpoints for health check, clustering services, and automation tools.

In September, 2017 Oracle, owner of the intellectual property of the Java platforms, made two big announcements:

JBoss EAP 7 implements the Jakarta EE 8 specification. Future versions of JBoss EAP will implement Jakarta EE 10, released on September 13, 2022. Jakarta EE 10 is the first release that includes the javax to jakarta package namespace change. Thus, you do not need to migrate applications code from javax to jakarta package namespace when using JBoss EAP 7.

JBoss EAP 7 is compliant with the two profiles that are defined in Jakarta EE 8. A profile is a collection of Java APIs that target a specific audience. There are currently two profiles defined in Jakarta EE 8:

There are over 30 different technologies that comprise the Full Profile of Jakarta EE. Each of these technologies have their own specification and version number. Combined, they provide an impressive list of capabilities that allow Jakarta EE applications to connect to databases, publish and consume web services, serve up web applications, perform transactions, implement security policies, and connect to a multitude of outside resources for tasks such as messaging, naming, sending emails, and communicating with non-Java applications.

The following figure illustrates the main set of APIs required by Jakarta EE 8.

Figure 1.3: Java and Jakarta EE 8 APIs

The Web Profile contains the web-based technologies of Jakarta EE, which are commonly used by web developers, such as Servlets, Java Server Pages, Java Server Faces, CDI, JPA, JAX-RS, WebSockets, and a slimmed-down version of Enterprise Java Beans (EJBs), known as EJB Lite.

The Java EE standards were defined by the Java Community Process (JCP), a formalized mechanism that allowed interested parties to develop standard technical specifications for Java technology.

Each JCP standard was a Java Specification Request (JSR), identified by a number. A JSR started with a formal specification document that defined how the technology is supposed to work from the perspective of application developers, system administrators, and middleware vendors. Formal public reviews of JSRs took place before JSR became final, and were approved by the JCP Executive Committee. A final JSR provided both a Reference Implementation (RI), that showed how the technology is supposed to work, and a Test Compatibility Kit (TCK), that competing implementations were required to have for a 100% pass score.

Today, the Eclipse Foundation defines the evolution of the Jakarta EE platform through the Jakarta EE Working Group and the Jakarta EE Specification Process.

The JBoss community develops a number of open source projects, ranging from development tools, to middleware platforms and utility libraries. The most used of them is the JBoss Application Server, or simply JBoss AS, later renamed, Wildfly application server, which is the basis of the Red Hat JBoss EAP product. The following non-exhaustive list enumerates other software projects developed by the JBoss.org community, which Red Hat releases as products:

One of the stated goals of the Wildfly project is to be modular, so individual features can be developed and experiments run without impacting the development schedule of other features. Users do not have runtime overhead created by unused features. Because of this, release 9 of the Wildfly application server was split into two main projects:

When Red Hat release a product from an open source project, it assumes contractual responsibilities of providing hardened, stable, and dependable software to its customers. These responsibilities include supporting service-level agreements, timely fixing bugs, and keeping backwards compatibility, among others. Sometimes those responsibilities are at odds with the community goals, which are providing fast innovations and allowing wide participation in software development.

Because the community and the product goals are different, there is no one-to-one correspondence between a community project release and a supported product release. New features are usually developed in the community. When the new features become sufficiently stable and there is enough market demand, they are brought into the product, without bringing together other community features that are not yet considered ready for production environments.

Standalone Server versus Managed Domain

A JBoss EAP 7 installation can be run in two operating modes: the standalone server mode, and the managed domain mode. The following figure illustrates both modes:

Figure 1.4: JBoss EAP 7 standalone server versus managed domain operating modes

Standalone Server

If centralized management capabilities are not needed, then you can provision JBoss EAP as a standalone server. Standalone server mode represents a single server instance, which uses a single standalone.xml configuration file.

Managed Domain

You can manage multiple server instances in multiple hosts from a centralized location, by using a managed domain.

A domain controller process acts as the central management control point. It communicates with the different host controllers in the managed domain. All of the hosts share a common management policy. The domain controller ensures that each server instance is configured according to that policy.

Each host in a domain has a host controller. Exactly one of the host controllers in a domain is designated as the domain controller. That is, the domain controller is also a host controller.

The domain controller is also referred to as the primary, and the other hosts controllers in the domain are referred to as secondaries. Nothings prevents a domain controller having its own server instances, but having it as a dedicated administration host controller, as suggested by the previous figure, is a common practice.

A managed domain can have server instances using different configurations. This is possible because the managed domain configuration defines a number of different profiles, and groups of server instances are assigned to a single profile.

Note

The term profile, when referring to a JBoss EAP 7 managed domain configuration is unrelated to Jakarta EE specification profiles.

You can configure the managed domain in the domain.xml file, which exists only in the domain controller. Each host controller, including the domain controller, also has a specific configuration, which is in the host.xml file. When a host starts, its settings from the host.xml file are combined with the settings from the domain.xml file on the domain controller.

The only difference between the standalone, and managed domain operating modes is the centralized management capability. All JBoss EAP features, such as security, transactions, messaging, clustering, high availability, and other Jakarta EE technologies, are available to JBoss EAP instances running in either the standalone server, or managed domain operating modes.

Host versus Server

A host in JBoss EAP 7 represents a single machine, from an operating system (OS) point of view. The host machine runs application server instances. JBoss EAP runs in the same manner in a virtual machine, or a physical machine.

When deploying JBoss EAP as a managed domain, each host is managed by a single host controller and contains zero or more server instances. The host controller acts as a management agent, and relays commands sent by the domain controller to the affected server instances.

The server instances and the host controllers run as their own OS processes, each one inside a dedicated Java Virtual Machine (JVM). Each host in a managed domain also runs a process controller in another dedicated JVM. The process controller is the OS process that starts new processes for host controllers and server instances.

The domain controller JVM runs the Management Console and Management API. Thus, all administrative requests are sent to the domain controller. Then, the domain controller relays administrative commands to the specific host controllers that manage the affected server instances.

The main difference between server instances in a managed domain and standalone servers, is that managed domain instances only run applications, not management services. The standalone servers run the Management Console and the Management API under the same JVM that runs applications.

References

What is middleware?

For more information about JBoss EAP in Microsoft Azure, refer to the Using JBoss EAP in Microsoft Azure guide in the Red Hat JBoss EAP 7 documentation at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/using_jboss_eap_in_microsoft_azure/index

For more information about JBoss EAP on Amazon Web Services, refer to the Deploying JBoss EAP on Amazon Web Services guide in the Red Hat JBoss EAP 7 documentation at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/deploying_jboss_eap_on_amazon_web_services/index

For more information about JBoss EAP on OpenShift, refer to the Getting Started with JBoss EAP for OpenShift Container Platform guide in the Red Hat JBoss EAP 7 documentation at https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/getting_started_with_jboss_eap_for_openshift_container_platform/index

OpenShift templates for JBoss EAP

Red Hat Application Services Product Update and Support Policy

There’s not a moment to lose! Moving Java Forward Faster

For more information about Red Hat OpenJDK support policies, refer to OpenJDK Life Cycle and Support Policy

Eclipse Foundation - Update on Jakarta EE Rights to Java Trademarks

Jakarta EE 8: The new era of Java EE explained

Red Hat JBoss Enterprise Application Platform (EAP) 7 Supported Configurations

JBoss EAP 7 Product Documentation

The JBoss Community