Spring-Boot Microservice Communication in Oracle Application Container Cloud

Oracle ACC and Spring-Boot

In my last post I gave an introduction to Oracle Application Container Cloud (ACC) and how to develop Spring-Boot applications such that they can be hosted within Oracle ACC. At the end of the post some questions still had to be answered. Within this post we are going to tackle the first one, how is Microservice Communication in Oracle Application Container Cloud achieved? The following figure shows what a simple architecture, within the context of a Spring-Boot Microservice application, might look like.

Basic Microservice Architecture

Basic Microservice Architecture

As one can see within the architecture diagram the deployment consists of three services. The first service is a simple Spring-Boot service registry. The service registry can be easily implemented using Spring-Cloud Eureka integration. Eureka is a service registry provided within Netflix OSS. All other services should be able to register themselves with the registry server and retrieve all information required for calling other services. Secondly, Microservice 1 could be a simple service publishing its data and only interacting with the service registry. Lastly, Microservice 2 would be another service which provides data but enhances it by retrieving additional information from Microservice 1.

Unfortunately, within Oracle ACC using a simple service registry is not that simple. When using Eureka as registry, clients only seem to have access to their local hostname configuration (see listing below).

Normally this is not a problem when running multiple services in several containers as they can be bound together to enable inter container communication. However, Oracle ACC does not provide the possibility to bind several of its container applications together. Only bindings to Oracle Java Cloud Service, Oracle Database Cloud Service, MySQL Cloud Service, Oracle Event Hub Cloud Service or an application cache are available. As result microservices registering with Eureka using their container internal URLs cannot communicate with each other. Only their public HTTPS-Service-URLs can be used.

Although it might be possible to provide a working Eureka configuration for all microservices, it requires setting many configuration values properly and passing HTTPS-Service-URLs as parameters to microservices during deployment. As explicitly passing concrete service URLs into each service renders the use of a service registry useless, it was decided to adopt a direct integration scenario for this blog post (see figure below).


Microservice Communication in Oracle Application Container Cloud

Oracle ACC Amended Architecture

All service implementations are based on Spring-Boot. For service calls Spring’s Feign-Client integration is used. As concrete implementations are not within the focus of this blog post, they will not be explained. If you would like to learn more about service implementation, follow the links below or leave a comment.

Assembling the services in Oracle ACC

First of all, we want to deploy Microservice 1. In general, the approach described in my last blog post can be applied. Here is the manifest.json file:

After creating the deployment ready archive and creating the application in Oracle ACC, we need to retrieve the service URL from ACC service console. This URL is required by other services to call Microservice 1. Therefore, we must provide it to Microservice 2 when creating the ACC application. As one can see below the service name follows a simple naming schema containing Oracle ACC application name, identity domain and Oracle Cloud hostname.

Retrieve Microservice 1 URL

Retrieve Microservice 1 URL

So, how does the metadata for Microservice 2 look like?

Within its implementation our microservice uses endpoint.microservice-one configuration property as service endpoint within the service client configuration. Just like server.port and server.address we can set the correct value using a parameter within manifest.json launch command. We are going to use the following manifest.json for Microservice 2:

As one can see, we are setting the value using $MICROSERVICE_ONE_ENDPOINT environment variable. As this is a custom environment variable, we are going to define it next. In order to define custom environment variables either ACC service console can be used (after application deployment) or a deployment.json metadata file can be added. As we want the environment variable to be available to the service during deployment, we create the deployment.json file below. <MICROSERVICE_ONE_URL> must be substituted with the concrete Microservice 1 service URL retrieved as described above.

Afterwards the deployment ready archive can be created using the following command:

Note that deployment.json is not part of the deployment ready archive. It is provided during deployment within the Oracle ACC console wizard or the API REST call (see figure below).

Deploying Microservice 2

Deploying Microservice 2

When Microservice 2 is deployed successfully, it can be called and is able to retrieve additional data from Microservice 1. The additional configuration can be inspected during runtime using the Oracle ACC application’s Deployments tab within service console.

Microservice 2 Configuration

Microservice 2 Configuration


As one can see, we were able to assemble a Spring-Boot based Microservice application using Oracle’s Application Container Cloud Service. For inter container communication an application’s public HTTPS-Service-URL must be used. Using Eureka as a service registry was not possible out of the box and requires much additional configuration to work. Therefore, a direct service integration was implemented.

From our point of view manually assembling and deploying extensive Microservice architectures to Oracle Application Container Cloud Service becomes unfeasible quite fast. The following options might be able to overcome these shortcomings:

  • Use of central service registry provided by Oracle Cloud Platform (currently not existing for Oracle ACC) to determine service URLs at runtime
  • Using Oracle Database Cloud Service, Oracle Event Hub Cloud Service or an application cache to coordinate inter application communication (event driven architecture)
  • Automate metadata creation using build tools (e.g. Maven, Gradle)
  • Retrieve service registry URL from identity domain during automated build using REST APIs
  • Automate ACC packaging

Still, Oracle ACC seems to be a perfect fit to run small and simple services on a scalable platform. Starting off with a couple of microservices is cheap in terms of required knowledge and setup cost. As Oracle ACC is a Docker based platform, transitioning to a more sophisticated Docker based Microservice architecture running on Oracle Container Cloud Service is quite easy.


Oracle ACC Metadata –

Oracle ACC Service Bindings –

Spring Cloud Eureka Server –

Spring Cloud Feign Clients –