Spring Boot 1.4.0 is now available. Among the enhancements are new mechanisms to build and test RestTemplates used to make calls to RESTful web services.
Stuart 'Stevie' Leitch on Software Development, Java Technologies, Security and Testing
Spring Boot 1.4.0 is now available. Among the enhancements are new mechanisms to build and test RestTemplates used to make calls to RESTful web services.
CRUD REST services are the backbone of a microservice architecture. If we want to use microservices rather than monolithic applications, it’s essential that we can create a basic service with a minimum of effort. Spring Boot can be used to quickly create and deploy a new web service. Spring Data REST can be used to build out the REST interface based on a database entity model. Using both together allows us to create a running RESTful web service with zero custom Java code and no tricky XML.
This article describes how to build a RESTful web service as an executable JAR that provides CRUD operations against a single MySQL database table.
This demo can be downloaded from GitHub in the Spanners Demo Application version 4.0 (spanners-api module). You can run the working example as a docker-compose stack, along with the associated MySQL database and the Spring MVC web app that consumes the service (see the previous post on docker-compose for details on how to run this).
The Node.js website describes it as having “an event-driven, non-blocking I/O model that makes it lightweight and efficient”. Sounds lovely, but what’s it actually for?
Modulus’s excellent blog post – An Absolute Beginner’s Guide to Node.js provides some rather tasty examples. After covering the trivial examples (Hello world! and simple file I/O), it gets to the meat of what we’re about – an HTTP server. The simple example demonstrates a trivial HTTP server in Node.js in 5 lines of code. Not 5 lines of code compiled to an executable or deployed into an existing web server. 5 lines of code that can be run from a simple command. It then goes on to describe the frameworks and libraries that let you do really useful stuff.
This looks just the thing for implementing a new feature in the Spanners demo app: push notifications to all logged-in users when a spanner is changed.
Properly versioning and releasing code can be fiddly if it’s done properly. If you’re not cutting corners, the process involves several steps. If these steps are performed manually the process is error prone and time consuming. I’ve often found it’s easier just to cut a few corners. Why change the version in the Maven pom when you could perform all releases against a single SNAPSHOT version? Why tag the release build when you could probably work out the release version from a Subversion log? Why put release artifacts in a release repo when you can rebuild from a historic version?
I’m not going to argue that you shouldn’t cut corners when creating a release build (all the same, just don’t!). I will argue that the process need not be fiddly. So long as a Maven project is correctly set up, the whole thing can be done with a single command. Wire that single command up to Hudson, Jenkins, CruiseControl or whatever and you can create properly versioned release builds in a single click or (if you’re so inclined) as a scheduled task.
At the heart of this is the powerful – though slightly inflexible – maven release plugin.
In my previous post regarding Spring-WS and Security I didn’t mention anything about testing the resulting SOAP service. Particularly when it comes to secure services, it’s vitally important to test. First, we want to make sure that the service is functionally correct – that it returns the correct results. Second, we want to make sure it is secure – that it refuses service to any request that does not meet our security requirements.
With regard to how we test, it’s simplest to use some SOAP editor tool that lets us fiddle with the request and press a button to retest instantly. But ideally we want some programmatic test that can be included in the test phase of our build.
This post describes testing the now legendary Spanners WS demo with the following requirements:
The updated source of the Spanners WS demo including the tests described here is available to download.
Spring Web Services (Spring-WS) are a neat way of declaratively creating SOAP web services using Spring with a minimum of boilerplate code usually associated with web services. I’d recommend it as the best way to create web services for a Spring application. When it comes to WS-Security (message encryption, authentication, signatures and so on) it is absolutely vital. It simplifies the very complicated business of securing messages to a few lines of declarative code.
I found the documentation provided by Spring on writing Spring-WS services and securing Spring-WS services very in depth and thorough but I’ve not yet found a good simple example app. This demo is about the simplest possible web service with the most standard WS-Security features enabled.
I’ve been looking a lot recently at JUnit (and TestNG) tests on a code base I’m not too familiar with. In many cases I was not convinced that the tests were adequate but it took a fair bit of investigation before I could be satisfied that this was the case. I would need to look at the tests, then look at the code it’s meant to exercise, then try to work out in my head if the test covers everything it should. To make this process a bit easier, I’ve started running code coverage analysis using Emma. While this doesn’t tell me if the test is good or not, it does show me at a glance how much code is covered by the test and exactly which lines, methods and classes are missed. This is usually a good first approximation for the quality of the test case.
I’ve found Emma to be a useful tool to run after I think I’ve written my test cases and got them working. Running the test case tells me if the code being tested works. Running Emma tells me if I’ve tested enough of the code. There’s no point in having 100% test case successes if the tests themselves only exercise 50% of the code.
I’ve decided to revisit the JUnit testing Hibernate and Spring recipe that I posted a while back. A problem with the previous recipe is that it did not provide any means to initialize the test database. This wasn’t too much of a problem as I was mostly testing the data insert operations of the DAOs. I then used the same DAO to retrieve the newly inserted data and tested what came back. However this is no good if I don’t want insert operations on my DAO (if it’s to retrieve read only data from the database) or if I want to test the retrieval operations independently of the insert operations.
This post extends the recipe to include a means of initialising the database using DbUnit.
As preparation for a recent interview, I decided to attempt to download, install and run an example Tapestry web application. I set aside a couple of hours to get this going. I expected to have to download an installation bundle, extract it, run an installer, install some dependencies, install and configure a webserver, start some services, write some code, debug, swear a bit then give up and just read an online tutorial.
As it happens, all you need is Maven 2. Running two goals with no particular config will download Tapestry and all dependencies, build and deploy a sample webapp and then run it in a webserver (which it will install too!).