Sometimes there is an urgent need popping up in the middle of an investigation of what is happening with your application server – e.g., a process is showing up, but refuses to serve network connections. There could be thousands of reasons why it is stuck, but one of the most common and a classic problem is deadlocked threads, i.e. threads that didn't share some of the resources on start-up correctly.

On one of my recent projects I’ve been asked to describe how our Restful API can be consumed by a third party service. In a SOAP world this task usually boils down to providing a WSDL, which can simplify understanding of exposed API, and can also be used for generating API clients in a most standardized manner.

Java supports a lot of scripting languages, and since Java 6 it supports JavaScript out of the box. JDK 6 and JDK 7 both have embedded Rhino JavaScript engine that was developed by Mozilla. In JDK 8 though, the Rhino engine was replaced with Nashorn. Being the Rhino successor that was rewritten from scratch to meet modern script engine expectations, it offers a better performance, but since Java 8 is still not so widely adopted in the enterprise environments, let us focus on Rhino for now.

It seems rather obvious that modern applications should be structured in a way that permits an easy deployment to existing cloud infrastructure, such as Amazon Web Services (AWS). In this article I will cover the Amazon solution, which is quite popular nowadays; there is, of course, also Google Computing Platform, which goes hand in hand with Amazon and offers more or less comparable core services, but let us focus on AWS for starters.

As the web evolves, more and more businesses are shifting their applications and data from internally hosted to the cloud. They provide publicly available APIs to expose valuable data (resources) and business functionality. To provide controlled access to exposed resources, API should be secured somehow, and that is where OAuth comes into play.