Deploy WildFly Connected to an Autonomous Database
WildFly supports the latest standards for REST-based data access, including JAX-RS 2, and JSON-P. B
WildFly, previously known as the JBoss application server, is an open-source application server compliant with Jakarta EE 8/9 and Java EE 8 specifications. It includes a Web server component called Undertow. The application server can be configured to run and manage a multi-server topology or as a standalone server. WildFly supports the latest standards for REST-based data access, including JAX-RS 2, and JSON-P. It provides efficient memory management that is based on pluggable subsystems. WildFly enables a faster development cycle with the easy-to-use Arquillian framework.
Architecture
This reference architecture contains a load balancer, an application tier with WildFly multi-server architecture, a database tier with Oracle Autonomous Transaction Processing, and a bastion host for secure access to the WildFly admin console.
The components are located in different subnets. The load balancer and bastion host are in a public subnet. The WildFly servers share a private subnet and are distributed across availability domains in regions that permit it, and across fault domains, for high availability.
The database is in its own private subnet. External access to the application servers is through the load balancer via an Internet gateway, while access to the administration console is through a bastion host.
The following diagram illustrates this reference architecture.
Description of the illustration architecture-wildfly-oci.png
architecture-wildfly-oci-oracle.zip
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnets
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- Internet gateway
The internet gateway allows traffic between the public subnets in a VCN and the public internet.
- WildFly servers
The WildFly servers host your applications.
- Autonomous Database System
WildFly can connect to any database that offers Java Database Connectivity (JDBC). This architecture offers the option to provision an Oracle Autonomous Database.
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- VCN
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Load balancer bandwidth
While creating the load balancer, you can either select a predefined shape that provides a fixed bandwidth, or specify a custom (flexible) shape where you set a bandwidth range and let the service scale the bandwidth automatically based on traffic patterns. With either approach, you can change the shape at any time after creating the load balancer.
- Compute instances
All tenancies get two Always Free Compute virtual machine (VM) instances, which this architecture can use.
If more processing power is required, you can select different shapes.
- Database systems
All tenancies get two Always Free Oracle Autonomous Databases. Autonomous Databases use shared Exadata infrastructure, where Oracle handles provisioning and maintaining the infrastructure.
If more than two databases are required, use a non-free Oracle Autonomous Database. - Block storage
The instances in this architecture use regular block storage; no extra performance is required.
- Network connectivity
You can manage the environment by connecting to your existing on-premises infrastructure by using a site-to-site VPN or a dedicated connection with FastConnect.
If the environment needs to be segregated from the existing infrastructure or accessed externally, a bastion host can secure the management connections. The bastion host is typically provisioned in a demilitarized zone (DMZ). It protects sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. You can avoid exposing the more sensitive components of the architecture without compromising access to them.
Considerations
Consider the following points when deploying this reference architecture.
- Performance
This architecture can use Oracle Cloud Infrastructure's Always Free resources. Due to the limitations of processing power in the Always Free tier, it is not intended for production. For more intense workloads, the regular shapes of instances, load balancers, and databases should be used.
- Security
Except for the bastion host and load balancers, all the components should be placed in private subnets.
- Availability
The load balancers and the databases are redundant, not requiring any intervention to take advantage of these features. The WildFly servers are deployed as a pair and balanced by the load balancer. More nodes can be added, but they’re not included in the Always Free Tier.
- Cost
This architecture can use the Always Free tier. However, the free tier resources might not be adequate for production workloads, in which case you will need to provision computing resources and services at the regular rates.
Deploy
The Terraform code for this reference architecture is available as a sample stack in Oracle Cloud Infrastructure Resource Manager. You can also download the code from GitHub, and customize it to suit your specific requirements.
- Deploy by using Oracle Cloud Infrastructure Resource
Manager:
- Click
If you aren't already signed in, enter the tenancy and user credentials.
- Review and accept the terms and conditions.
- Select the region where you want to deploy the stack.
- Follow the on-screen prompts and instructions to create the stack.
- After creating the stack, click Terraform Actions, and select Plan.
- Wait for the job to be completed, and review the plan.
To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.
- If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
- Click
- Deploy using the Terraform code in GitHub:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
READMEdocument.
Explore More
Links to additional information that can help you learn about, modify, use, or implement this architecture.
-
Technical articles, white papers, code samples, FAQs, and more that describe how to use JDBC, the Universal Connection Pool, and the embedded JVM to connect to Oracle Database.
-
A repository on GitHub that has code samples for a Java Servlet that connects to Oracle Database using the Oracle JDBC driver.