The world is moving to containerized workflows. As a result, tools to handle containerization become more and more important.
Kubernetes is the most widely used platform for managing and orchestrating containers. But since it contains only the basic building blocks, you need additional tools if you want to set up your environment for running applications on it.
In this blog, we take a closer look at Red Hat OpenShift and the comparison with Kubernetes.
In this last blog of the Getting Started with Jakarta EE 9 blog and video series, we have a look at the Bean Validation specification. Using this specification, you can define some validation rules, from some simple ones on a single field to very complex ones on a business entity, that are reusable depending on the input frameworks you are using within your application.
JDK 17 is the latest Long Term Supported (LTS) version of the Java platform, released in September 2021. LTS versions will have regular releases for the coming years and you don't need to switch to a newer version after 6 months as you do with those 'interim' JDK versions.
The features in an LTS version are kept stable so it is ideal for running your enterprise applications. Once you switch to an LTS, you can safely update to any minor release to accommodate for security issues and bug fixes of the JDK platform, but without needing to perform a migration.
With the release of the November 2021 version of the Payara Platform Community Edition, Payara Server, Payara Micro, and the Web Profile run on JDK 17 platform.
Before your application can respond to any request from the user, Payara Server needs to be started as a process on a machine. The Payara Server Domain instance or a Payara instance can be started using the Asadmin CLI tool.
But in many cases when you run Payara Server on an on-premise machine or in a virtual machine, you want to start the Payara process automatically when the machine is booted. You can do this by defining Payara as a Service on the machine.
A realm is the security policy domain within an application server. It defines how the authentication and authorization for your application is performed. Most of the time, your application is used by a person that can provide username and passwords as credentials (directly or indirectly through providers like an OpenId Connect provider) but some use cases exist where another process needs to use your endpoints.
Data is sent to and received from the endpoints within Payara Platform. When large chunks of data are sent to the client in response to a request, it might be an option to compress the data when the bandwidth is limited. This speeds up the transfer, but requires more CPU on the server and the client to perform the compression and handle the response.
With the October 2021 release, the Payara Platform allows configuring the compression level and the compression algorithm so you can better tune your environment for your requirements.
Co Authored with Nicolas Frankel (Hazelcast Developer Advocate), this article is also available as a PDF.
The Hazelcast In-Memory Data Grid (IMDG) is an efficient method of storing data in a distributed way within the memory of the different processes of the cluster. Because it is distributed, searching the data locally requires 'moving' the data to your instance so it can be accessed, which is not overly efficient. Hazelcast SQL allows distributed queries which perform the search where the data is, and then transfers only the results to your process. Since the Payara products already use Hazelcast IMDG, using the Hazelcast SQL capabilities is straightforward: just add the additional JAR library to start using it.