Monday, March 28, 2016

Running Node.JS Apps and "Fat-JAR" Apps on Application Container Cloud Service


With the trend of container technologies going on it is great to see Oracle is providing the so called Application Container Cloud Service. Its current architecture is based on Docker and allows to run Java SE and Node.js applications in its current version. See the the following diagram


The Load Balancing, dockerizing and scaling is fully transparent. From developer perspective you are deploying a ZIP containing a manifest.json with a command property that states what should be executed once the deployment has been installed on the specific container.

In the following figure you see the overview screen of Application Container Cloud service (ACC).


Next lets create an app and deploy it to ACC. For Java SE lets see how that manifest.json looks like

Java SE App

The important properties are runtime / majorVersion and command. It states that the deployment needs Java 8. The application is started with the given "java -jar ..." command. Currently two working samples are provided, one works with embedded Tomcat the other works with Grizzly Http Server. Here is how a typical Main.java class would look like


The PORT and HOSTNAME are given from the environment. So it is in control of the application container cloud service.

Node.js App
For a Node.js app that manifest.json looks like

It expects a file server.js as the main entry point. There is an official Node.js sample application (together with a Tutorial). In my example I am going to create a connection to Oracle Database Cloud Service (via oracle nodedb driver) and expose DEPARTMENTS as a read online REST Resource.

The most interesting part here is how to retrieve the CONNECT String to the Database.

For testing on local machine defaults are used. Once deployed the CONNECT String is given as an environment property (beyond PORT, USER, etc).

Hint: All the JavaScript modules except native add-ons like node-oracledb should be included in the ZIP bundle.

Deployment
The deployment is quite straightforward from the ACC UI using the "upload application archive" option. Further you can provide initial values for number of "Instances" and Memory.

After about 5 min. the application is available through the Load balancer. For automated deployment a REST API exists.

To connect to other cloud services a service binding needs to be created first. The service binding creates environment variables that are available to every application instance.

Custom environment variables can be created. For example the schema user / password you want to connect with. Unfortunately just clear text values are accepted at the moment. Would be great to have a "secret type" for passwords. Further  # characters are not allowed (although my schema name is c##hr  ;) ).  Anyway it is no major show stopper.


See the sample service running in Postman


Logging / Diagnostics
Logs are stored on the Oracle Storage Cloud Service as a zip file. To look into the log files you have to download those ZIP files on your local disc first

For Java SE Apps a Flight Recording is possible.

Summary

The first public release of ACC looks quite promising. For the next versions my wishlist would contain
- Online Log Viewer
- Monitoring RAM / CPU Usage / Requests online
- Automatic Scaling
- Service discovery
- Security ?
- Adding environment variables of type "secret". (Currently you can only provide variables in clear text)
- Packaging improvements, maybe some mvn acc:install or CLI Tooling


Looking forward to new features in the future versions. There is potential for a modern microservice platform.

Samples Code
Explore the Node.JS sample code on https://github.com/enpit/enpit.sample.acc-node-hrapi
The Java SE jersey based code is available from Oracle.

Further Information

Tuesday, February 9, 2016

ADF Spotlight: REST in ADF 12.2.1

In the recent ADF Spotlight Webconference I have given a presentation and live demo on some of the new REST features in ADF 12.2.1. The recording (in german) is on youtube: https://www.youtube.com/watch?v=SmrINlqVNPs

The new REST features (to create REST resources) are implemented on top of Application Module (WebServices > REST). Here you can choose a Root View Instance, assign it to a release version and further configure the defined REST resource in a new Overview Editor.

Following summarizes some of the new REST features in ADF:

Resource Versioning

Versioning is the first thing need to be configured before you can start creating REST resources. It is supported at the level of the adf-config.xml file. Here you can define different versions. Each version can be configured as  active, deprecated or desupported. To keep things simple I recommend to use same name for internal and release name.


Versions marked as desupported will reply with HTTP 500  and corresponding message. They will not serve any REST Data.


Versions marked as deprecated will work. If you invoke the URL for v2 metadata you will get information that there is a successor-version:


It implements the HATEOAS principle and therefore is very developer friendly.

Read, Create, Update, Delete Out-of-the-box

By default all REST HTTP Methods are exposed on a resource. GET for read, POST for Create, DELETE for Delete. To partially update a resource (only some attributes e.g.)  the PATCH method is exposed.  For PUT you need to provide all attributes (It will do kind of a replace).

Important: When working with the REST API it is important to set the Content-Type to application/vnd.oracle.adf.description+json otherwise there will be the following exception:

oracle.adf.internal.model.rest.core.exception.CannotParseContentException: The PayloadParser could not be found in the ResourceProcessingContext.

See the following Postman PATCH sample:

Pagination for collections by default

Having a REST collection ADF automatically exposes parameters for pagination. Just append limit und offset as URL parameters and your good to go. see next pic to get a feeling how the parameters affect the response:

Children and LOVs as sub-resource

This is also a pretty great feature. 

By a simple configuration child view object instance will be exposed a sub-resources.



Configured LOVs on specific attributes will by default be exposed as sub-resources too. See example in postman:

Attribute Shaping

By default all attributes of a View Object will be exposed in the REST resource. If you want to expose only a subset of the attributes you can define "Service Shapes" on the View Object

and use those to customize the REST resource (Tab: Attributes)


Security

Securing ADF REST Resources is quite powerful. It works just like with Pages / Taskflow Permission. You just need to run the ADF Security Wizard on the RESTWebService project.

More features

Canonical Link

The canonical link is used to link to a resource that represents the full representation (of REST resource). This can be an "internal" defined View Object or an external (by pointing to the corresponding) ADF Connection.

See details in the Dev Guide: How to expose canonical Resources

RowFinder Key

With RowFinder configuration it is possible to change the URL of a resource from e.g. /employees/100 to /employees/SKING

Expose Custom Methods in the ADF REST Resource

To be evaluated ;) The ADF Documentation is not very clear about that topic.


--
Sample Code: https://github.com/enpit/enpit.sample.adf1221.restsandbox

Further information