Apache Camel + Spring Boot: Different components to expose HTTP endpoints

Apache Camel is an open source integration framework that allows you to integrate technologically diverse systems using a large library of components. A common use-case is to service HTTP based endpoints. Those of course come in several flavors and there is quite a choice in components to use.

In this blog post I'll take a look at what is available and how they differ with respect to flexibility to define multiple hosts, ports and URLs to host from using a single CamelContext. Depending on your use-case you will probably be using one of these. You can find my sample project here.

A transparent Spring Boot REST service to expose Oracle Database logic

Sometimes you have an Oracle database which contains a lot of logic and you want to expose specific logic as REST services. There are a variety of ways to do this. The most obvious one to consider might be Oracle REST Data Services. It is quite powerful and supports multiple authentication mechanisms like OAuth. Another option might be using the database embedded PL/SQL gateway This gateway however is deprecated for APEX and difficult to tune (believe me, I know).

Sometimes there are specific requirements which make the above solutions not viable. For example if you have complex custom authentication logic implemented elsewhere which might be difficult to translate to ORDS or the embedded PL/SQL gateway. ORDS also runs in stand-alone in a Docker container but this is not so easy for the PL/SQL gateway. Also if you are looking for a product or framework which can be used for multiple flavors of database, these solutions might be too Oracle specific.

You can consider creating your own custom service in for example Java. The problem here however is that it is often tightly coupled with the implementation. If for example parameters of a database procedure are mapped to Java objects or a translation from a view to JSON takes place in the service, there is often a tight coupling between the database code and the service.

In this blog post I'll provide a solution for a transparent Spring Boot REST service which forwards everything it receives to the database for further processing without this tight coupling, only to to a generic database procedure to handle all REST requests. The general flow of the solution is as follows:

• The service receives an HTTP request from a client
• Service translates the HTTP request to an Oracle database REST_REQUEST_TYPE object type
• Service calls the Oracle database over JDBC with this Object
• The database processes the REST_REQUEST_TYPE and creates a REST_RESPONSE_TYPE Object
• The database returns the REST_RESPONSE_TYPE Object to the service
• The service translates the REST_RESPONSE_TYPE Object to an HTTP response
• The HTTP response is returned to the client

A simple dashboard to monitor HTTP endpoints

To monitor different environments, it is not unusual to use a monitoring dashboard to obtain information about the status of different servers. This blog describes some considerations for implementing a simple monitoring dashboard and some of the challenges I encountered. The simple-dashboard I've used in this blog runs solely from a browser and does not have a server side component.

Node.js: A simple pattern to increase perceived performance

The asynchronous nature of code running on Node.js provides many interesting options for service orchestration. In this example I will call two translation services (Google and SYSTRAN). I will call both of them quickly after each other (milliseconds). The first answer to be returned, will be the answer returned to the caller. The second answer will be ignored. I've used a minimal set of Node modules for this; http, url, request. Also I wrapped the translation API's to provide a similar interface which allows me to call them with the same request objects. You can download the code here. In the below picture this simple scenario is illustrated. I'm not going to talk about the event loop and the call stack. Watch this presentation for a nice elaboration on those.

A first look at Splunk. Monitor Oracle SOA Suite service response times

Measuring performance of services can be done in various ways. In this blog I will describe a method of measuring Oracle SOA service response times with Splunk a popular monitoring tool. In order to monitor service response times with Splunk, Splunk needs to obtain its data from somewhere. In this example I'll use the HTTP access log which I expand with a time-taken field. Disclaimer; my experience with Splunk is something like 2 hours. This might also be an indication of what can quickly be achieved with Splunk with little knowledge.

What is REST?

REST (Representational State Transfer) is a term often used in software engineering when talking about services or other API's. A lot of these so-called RESTful services or interfaces are not RESTful at all. Even the author of REST gets frustrated by the common misuse; http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven: "I am getting frustrated by the number of people calling any HTTP-based interface a REST API.". REST is often confused with an application of REST to HTTP and URI (uniform resource identifier). An URI is a unique identifier to identify a web resource. HTTP is a transport protocol used to interact with the web resource. REST however is a bit more then just that. The division between resource identification and resource interaction is important. The application of REST uses the URI to identify a concept. In this blog post I will elaborate a bit more on REST while trying to avoid literally repeating other sources like Wikipedia. I will also provide some background and examples I found during my short study of the concept. In addition, this post will be introductory to other more (Oracle) implementation focused articles.