How to connect external services and configure orchestrated applications

Learn how to connect external services and configure orchestrated applications in this tutorial by Sebastian Daschner, the author of Architecting Modern Java EE Applications.

The orchestration framework orchestrates and integrates enterprise applications in clustered environments. It takes a lot of work off the used application technology. Container orchestration also greatly simplifies the configuration of orchestrated applications and connection to external services.

Connecting external services

Client controls require URLs to connect against in order to integrate external services. The URLs traditionally have been configured in files, which potentially differed in various environments. In an orchestrated environment, the application can resolve external services using a logical name via DNS. The following code snippet shows how to connect against the cloud processor application:

@ApplicationScoped
public class HelloCloudProcessor {

   private Client client;
   private WebTarget target;

   @PostConstruct
   private void initClient() {
       client = ClientBuilder...
       target = client.target("http://cloud-processor:8080/processor/resources/hello");
   }

   public String processGreeting() {
       ...
   }
}

The same holds true for other URLs (for example datasource definitions). The application server configuration can simply point to the name of the database service and use it to resolve the corresponding instance at runtime.

Configuring orchestrated applications

Resolving services by logical names already eliminates a lot of configuration in the application. Since the same container image is being used in all environments, a potentially different configuration needs to be inserted from the orchestration environment. As shown in the previous example, Kubernetes config maps tackle this situation. The hello-cloud application expects that at runtime a properties file will reside under /opt/config/application.properties. The project code will hence access this location. The following demonstrates the integration of the properties file using a CDI producer:

public class HelloGreeter {

   @Inject
   @Config("hello.greeting")
   String greeting;

   @Inject
   @Config("hello.name")
   String greetingName;

   public String processGreeting() {
       return greeting + ", " + greetingName;
   }
}

The CDI producer is defined similarly to the configuration example shown previously:

@ApplicationScoped
public class ConfigurationExposer {

   private final Properties properties = new Properties();

   @PostConstruct
   private void initProperties() {
       try (InputStream inputStream =
               new FileInputStream("/opt/config/application.properties")) {
           properties.load(inputStream);
       } catch (IOException e) {
           throw new IllegalStateException("Could not init configuration", e);
       }
   }

   @Produces
   @Config("")
   public String exposeConfig(InjectionPoint injectionPoint) {
       Config config = injectionPoint.getAnnotated().getAnnotation(Config.class);
       if (config != null)
           return properties.getProperty(config.value());
       return null;
   }
}

The application loads the contents of the properties file into the properties map and produces the configured values using CDI. All managed beans can inject these values, which emerge from the Kubernetes config map.

In order to realize secret configuration values, Kubernetes includes the concept of secrets. A common practice is to make the contents of the secrets accessible in containers using environment variables.

Java applications use the System.getenv() method to access environment variables. This functionality is used for both secrets and config map values, respectively.

The demonstrated approaches and examples enable an enterprise application to be deployed, managed, and configured in a container orchestration cluster. They are sufficient for a majority of use cases.

You can now connect external services and configure orchestrated applications in Jakarta EE. If you found this tutorial helpful, you can explore Architecting Modern Java EE Applications, an end-to-end guide to designing and developing modern, business-oriented applications using Java EE 8. So if you’re a Java EE developer keen on architecting enterprise-grade applications, this book is a must-read!

Leave a Reply

Your email address will not be published. Required fields are marked *