Showing posts from 2017

Health Checks, Metrics & More with Spring Boot Actuator

I've been working with Spring Boot for a few years now and I'm a big fan. There are lots of things to like about Spring Boot, but one thing that really stands out for me is the emphasis on production readiness.
Production Readiness Production readiness is about looking beyond functional requirements and ensuring your application can be properly managed and monitored in production. Some key things to consider when thinking about production readiness are...
Health checksViewing application configuration - application properties, Environment variables etc. Viewing and altering log configurationViewing application metrics - JVM, classloader, threading and garbage collection. Audibility of key application events Spring provides all of this functionality out of the box via Spring Boot Actuator, a sub project of Spring Boot. A range of RESTful management and monitoring endpoints are provided so you don't have to implement these features each time you build an application. To enable…

REST HATEOAS with Spring

The Richardson maturity model breaks the REST architectural style into various levels of maturity.
Level zero describes a system that uses HTTP as a transport mechanism only (also known as URI tunnelling). A single URI and HTTP verb is typically used for all interactions with POX (plain old XML) being posted over the wire. Old school SOAP-RPC is a good level zero example.Level one describes a system that builds on level zero by introducing the notion of resources. Resources typically represent some business entity and are usually described using nouns. Each resource is addressed via a unique URI and a single HTTP verb is used for all interactions.  Level two builds on level one by using a broader range of HTTP verbs to interact with each resource. Typically GET, POST, PUT and DELETE are used to retrieve, create, update and delete resources, providing consumers with CRUD behaviour for each resource. Level three builds upon level two by introducing HATEOAS - Hypermedia As The Engine Of A…

SOAP Services With MTOM

As you probably know, SOAP is an XML based protocol which means that all data inside a SOAP message must be text based. If you want to include binary data in a SOAP message, it too must be text based. To achieve this you can convert binary data to a base64 encoded string and simply embed that string inside the SOAP message. The diagram below shows a sample SOAP message with binary data embedded as a base64 string.

While this is the simplest approach to dealing with binary data over SOAP, there are a few things to consider. When binary data is base64 encoded it increases in size by approximately 30%. For small amounts of binary data this probably won't be an issue, but for larger volumes of data the increased message size can significantly impact performance.
Another point to consider is the processing overhead for the XML parsers that process the SOAP messages. A large amount of binary data will result in a huge base64 encoded string, and more CPU intensive parsing for the consume…

REST Endpoint Testing With MockMvc

In this post I'm going to show you how to test a Spring MVC Rest endpoint without deploying your application to a server. In the past, full integration tests were the only meaningful way to test a Spring REST endpoint. This involved spinning up a test server like Tomcat or Jetty, deploying the application, calling the test endpoint, running some assertions and then terminating the server. While this is an effective way to test an endpoint, it isn't particularly fast. We're forced to wait while the entire application is stood up, just to test a single endpoint.
An alternative approach is to unit test by manually instantiating the Controller and mocking out any required dependencies.  While such a test will run much faster than a full integration test, its of limited value. The problem is that by manually instantiating the Controller we're bypassing Springs Dispatcher Servlet, and as a result missing out on core features like
request URL mapping request deserialization re…

Java Concurrency - Synchronization

In my last post we looked at running tasks across multiple threads, asynchronously using the ExecutorService. Accessing and manipulating an object from multiple threads simultaneously can pose a problem when the object in question holds state. If multiple threads attempt to modify shared state, behaviour can become unpredictable and result in data being left in an inconsistent state.

Unsynchronized Code Take the simple BankAccount class below. It holds state in the form of a balance, which can be increased and decreased using the credit and debit methods respectively. When used in a single threaded context this object will behave as expected, crediting and debiting the amounts specified.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16publicclassBankAccount { privatedouble balance; publicvoid credit(double amount){ balance = balance +amount; } publicvoid debit(double amount){ balance = balance - amount; } publicdouble getBalance(){ retur…