- Java EE 7 Development with WildFly
- Micha? ?mil Micha? Mat?oka Francesco Marchioni
- 600字
- 2025-02-24 05:34:39
WildFly 8 core concepts
Now that we have downloaded and installed WildFly 8, it is worth spending a few minutes familiarizing ourselves with some basic concepts. The architecture and most of the core ideas are taken straight from JBoss AS 7; although, there are some new mechanisms that were introduced with the newest version (for example, role-based security for the management system, reduced number of used ports, and a new patching system). Just like JBoss AS 7, WildFly can be run in two modes: the standalone mode and domain mode.
In the standalone mode, each WildFly instance is an independent process (similar to the previous JBoss AS versions, such as Version 4, Version 5, Version 6, and the standalone mode in Version 7). The standalone configuration files are located under the standalone/configuration directory of the application server.
In the domain mode, you can run multiple application servers and manage them from a central point. A domain can span multiple physical (or virtual) machines. On each machine, we can install several instances of WildFly that are under the control of a Host Controller process. The configuration files in the domain mode are located under the domain/configuration folder of the application server.
From the process point of view, a domain is made up of three elements:
- Domain Controller: The domain controller is the management control point of your domain. A WildFly instance running in the domain mode will have at the most one process instance acting as a domain controller. The domain controller holds a centralized configuration, which is shared by the node instances that belong to that domain.
- Host Controller: This is the process that is responsible for coordinating the life cycle of server processes and the distribution of deployments from the domain controller to the server instances.
- Application server nodes: These are regular Java processes that map instances of the application server. Each server node, in turn, belongs to a server group. Domain groups are explained in detail when we will discuss the domain configuration file.
Additionally, when starting a domain, you will see another JVM process running on your machine. This is the Process Controller. It is a very lightweight process whose primary function is to spawn server processes and Host Controller processes, and manage their input/output streams. Since Process Controller is not configurable, we will not discuss it any further.
The following diagram depicts a typical domain deployment configuration:
As you can see in the preceding diagram, one host (Host1) acts as a dedicated domain controller. This is a common practice adopted in domain-managed servers in order to logically and physically separate the administration unit from the servers where the applications are hosted.
The other hosts (Host2 and Host3) contain the domain application servers, which are divided into two server groups: main-server-group and other-server-group. A server group is a logical set of server instances that will be managed and configured together. Each server group can, in turn, be configured with different profiles and deployments; for example, in the preceding domain, you can provide some services with main-server-group and other services with other-server-group.
This has some advantages. For example, when you don't want to shut down your application for a new version, you can start by redeploying only one server group at a time. When one server is not fully operational, requests can be handled by the second one.
Getting into the details of the domain configuration is beyond the scope of this book; however, by the end of this chapter, we will see how to deploy application units in a domain using the command-line interface available in WildFly.