Posts

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

Image
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…

Java Concurrency - Multi Threading with ExecutorService

In this post I'll look how the ExeutorService can be used to perform multi threaded asynchronous tasks. I'll begin by looking at the traditional approach of creating threads directly and then move on to examine the ExecutorService and how it can be used to simplify things.

Instantiating Threads Directly Prior to the Executor API developers were responsible for instantiating and managing threads directly. Lets look at a simple example below.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 /** * Call 2 expensive methods on separate threads * * @throws InterruptedException */publicvoid doMultiThreadedWork() throws InterruptedException { /* create Runnable using anonymous inner class */ Thread t1 = new Thread(new Runnable() { publicvoid run() { System.out.println("starting expensive task thread t1"); doSomethingExpensive(); System.out.println("fi…