Anatomy of an app on the Oracle Application Container Cloud

The Oracle Application Container Cloud service is relatively simple to be honest. Here is quick post on how a potential application looks like. Although the service supports Java SE and Node.js runtimes, this post will stick to Java specific examples. Let’s take it from the bottom up…

Packaging the ‘final’ deployable artefact

Just a simple ZIP file with the following contents

The JAR file: this is the runnable Java ‘application’ itself
The manifest.json file: this is another mandatory artefact which contains information on the startup command (e.g. java -jar myapp.jar) as well as other metadata like java version, release details etc.

	{
	"runtime": {
	"majorVersion": "7"
	},
	"command": "java -jar my_fat_jar_app.jar",
	"release": {
	"build": "20160211115959",
	"commit": "abc-def-ghi",
	"version": "0.0.7"
	},
	"notes": "Sample application"
	}

view raw

sample-manifest.json

hosted with ❤ by GitHub

How does the JAR look like ?

Nothing extraordinary about this. Just bear in mind that your dependent libraries (if any) need to be packaged with your application. This can be done via

Good old class path: Place your dependent libraries and specify them using java -cp or set them as CLASSPATH environment variable
Create a Fat JAR: the dependent libraries are pushed into the JAR itself (thereby making it ‘fat’). There are more than ways of achieving this (e.g Maven shade plugin)

In either case, your JAR file needs the manifest.mf file to include the main (bootstrap) class information for the JVM

Deployment

You can choose from either of two options to deploy your application (ZIP archive) [Details are not dealt with]

GUI: use the dedicated administrative console for the App Container Cloud service
Or leverage the REST API

deployment.json – to make things a little easier

This is an optional file which contains ‘deployment’ specific information required by the service. It includes information such as no. of instances or nodes, required memory per instance, custom environment variables (key-value pairs), external service (other cloud services) binding information. Such a pre-defined can be useful while using the REST API where you just point to it instead of specifying all the individual deployment metadata in your REST HTTP request

	{
	"memory": "4G",
	"instances": "3",
	"environment": {
	"SVC_API_KEY": "123-abc-007-bond"
	},
	"services": [
	{
	"identifier": "JavaCloudService",
	"name": "Weblogic JCS",
	"type": "JAAS",
	"username": "user",
	"password": "pwd"
	}
	]
	}

view raw

sample-deployment.json

hosted with ❤ by GitHub

Please note that…

Each node or instance is nothing but a Docker container and that’s where your application will reside and execute within (i.e. the JVM service will be running inside the Docker container)
Since the applications are dynamically deployed to Docker container, the application deployer/developer is not in control of the port and hostname properties. These are automatically made available to you by the service in the form of (implicit) environment variables – HOSTNAME, PORT. You can read these within you Java logic

Cheers !