When a user needs to access multiple applications in your environment, you should not require authentication for each application. If the user has already been authenticated for one of the applications, he or she should  should not be asked for credentials when he accesses one of the other applications during the same browser session. This concept is called Single Sign-on where the authentication credentials are 'shared' in the environment and can be used by any application in that environment.

When a user needs to access multiple applications in your environment, you should not require authentication for each application. If the user has already been authenticated for one of the applications, he or she should  should not be asked for credentials when he accesses one of the other applications during the same browser session. This concept is called Single Sign-on where the authentication credentials are 'shared' in the environment and can be used by any application in that environment.

In this second blog of the "Getting Started with Jakarta EE 9" series, we show you some basic scenarios using the REST specification. Although most people are using the term REST or RESTful API just to indicate they do data transfer over HTTP, and  ignore the "Hypermedia as the engine of application State (HATEOS)" part of REST. The technology is used a lot lately to connect the front-end with the back-end.

For those who are not familiar with Jakarta EE, this blog should give you an indication how to create such a REST API with Jakarta EE 9.

The Domain Data Grid feature of the Payara products is powered by the Hazelcast library. It provides the necessary functionality for the Deployment Group (clustering functionality), Cache functionality, CDI cluster singleton, and monitoring data storage within Payara to name just a few features.

Since Hazelcast can cluster multiple instances into a data grid, it is possible to create a Hazelcast grid that comprises the Payara instances and some other instances included in other applications running outside of Payara.

Introduction

The release of Jakarta EE 9, at the end of 2020, was in many ways a historic event. The Java Enterprise framework is already 20 years old, having its first release in 1999. It has changed names a few times but the main concepts of the first release can still be found in this new release. During all those years, it has adapted itself to keep it up to date but has always adhered to its main principle of stability and backward compatibility.

Introduction

The Apache Maven Cargo Plugin allows you to deploy your application to a Payara Server, running locally or remotely. Using Maven as a build tool is an easy way to immediately deploy the application during the build to a test or production server.

We have created a custom version of the Cargo Plugin which also supports the Deployment Group feature of the Payara Server.

The JBatch Jakarta EE specification describes the process of how background jobs can be executed on a Jakarta EE compatible runtime. Using the Batch Specification, the runtime can execute some jobs that don't require any user input. Most of the time they are scheduled to execute at a certain moment of the day, but they can be triggered on-demand.

This blog describes the issue we currently have within the Payara Platform products when you try to combine the MicroProfile Rest Client specification and MicroProfile Fault Tolerance and provides a solution.

Introduction

When performing the configuration of the Payara Server for your application, you often need to supply a password. The password to connect to the database is a classic example, but there are many situations where you need to enter this kind of sensitive data.

With Payara Server, you have the option to hide this kind of sensitive data from the user, so that this information is much better secured.

Creating a Docker image is not that difficult. The Dockerfile script contains a few commands that define and prepare your image that will be run by the engine as a container.