Ben Wilcock

Ben Wilcock

Spring Technical Marketing

Glastonbury, United Kingdom

Ben has been helping people deliver better software all his working life. He's achieved this through listening, learning, and leading software developers in large and small organizations spanning many industries and sectors. Ben's current focus is Spring. Ben helps VMware build stronger developer relationships with the millions of developers who use Spring every day. He's technical, often writing code, but also helps to shape products, build websites, and write & produce blogs, videos, and other digital content. You may even hear him speak at conferences such as Devoxx, MS Build, GOTO, and AxonIQ. He's known for sharing his insights with developers, supporting salespeople, talking to clients, helping with events and hosting, and getting stuck in on social media. In the past, he's specialized in software design, software development, service orientation, event-driven architecture, microservices, and cloud computing. He's occupied a variety of technical roles including, developer, architect, manager, and consultant. Amongst the many techniques he's applied are XP and agile, test-driven development, pairing, mobbing, domain-driven design, event-sourcing, event-storming, and more. He's also helped other technology leaders — from CEO and CTO to lead developer — get to grips with challenges surrounding cloud migration and transformation. You can follow Ben on twitter for regular updates, insights, and opinions on technology today and the world we live in at (
Blog Posts by Ben Wilcock

You spoke, we listened: State of Spring 2020 report is here!


Back in July the Spring team asked for your input on a range of Spring-related topics. And wow! What a response!

Thank you to the 1024 developers, architects, and managers across the globe that took time out of their day to complete the survey. We’ve crunched the numbers, filtered & mashed up the results to distill the most compelling insights into the State of Spring 2020 report.


Thanks to everyone that completed the survey. We look forward to making this report an annual event, following the growth, success, and evolution of our community.


The Spring team wants to hear from you!

The “State of Spring 2020” report will be published soon, based on the views and experiences of Spring Boot development experts across the globe. In exchange for 15 minutes of your time to complete the survey, you’ll be among the first to receive the survey report and the insights included in it. Please feel free to share this email with your Spring development colleagues. The survey will close at the end of July.

Take the survey now.

Thanks for sharing your thoughts and experiences with us!
The Spring Team


Getting Started With RSocket: Spring Security

Reading time: about 6 minutes
Coding time: about 20 minutes

If you’ve been following my series on RSocket, you’ve already learned how to build client-server applications with Spring Boot. In today’s exercise, you’re going to learn how to add security to your RSocket applications.

The task of securing RSocket applications is greatly simplified when you use Spring Security. Spring Security is a must-have module for any production application. It allows you to easily plugin many different authentication providers and restricts each user’s access to your application based on their identity and their role.


Getting Started With RSocket: Testing Spring Boot Responders

Reading time: about 6 minutes
Coding time: about 15 minutes

If you’ve been following this series, by now, you’ll have built a Spring Boot prototype that illustrates many of the features present in RSocket. This code isn’t production code, though; it’s a prototype, a stepping stone on your RSocket journey. For production code, I’d expect all the usual quality assurance and testing rules to apply. So in this exercise, I’ll show you how to write integration tests for RSocket responders, so you can get one step closer to production.


Getting Started With RSocket: Servers Calling Clients

Reading Time: about 7 minutes.
Coding Time: about 20 minutes.

If you’ve been following my series on RSocket, you’ve heard me refer to “clients and servers” many times. But, with RSocket, the line between client and server is blurry. With Rsocket, servers can send messages to clients, and clients can respond to these requests in the same way a server would.

In fact, the RSocket docs don’t use the terms ‘client’ or ‘server.’ The docs use the terms ‘requester’ and ‘responder’ instead. In RSocket, any component can act as a requester, and any component can act as a responder or even both at the same time. In RSocket, all this back-and-forth communication between requesters and responders takes place over a single ‘bi-directional’ connection.


Getting Started With RSocket: Spring Boot Channels

Reading Time: about 6 minutes.
Practice Time: about 20 minutes.

If, like me, you’re still at the beginning of your RSocket journey, check out the motivations behind the RSocket protocol. This short but insightful document includes one message that resonates very strongly with me — ‘a mismatched abstraction increases the cost of developing a system.’

From a software design point of view, RSocket’s four interaction models offer a significant benefit. It means we can model our component-to-component communications using the correct interaction model for each use case. This more productive model could save you lots of time and energy when coding!


Getting Started With RSocket: Spring Boot Request-Stream

Time: about 15 minutes.

Previously in this series, you experimented with request-response and fire-and-forget messaging in Spring Boot with RSocket. This time you’ll try another of RSocket’s fresh new messaging models — request-stream.

In this exercise, you’ll learn how to stream data using the conventional ‘client-requests-a-server-stream’ approach.

One thing that I haven’t mentioned until now is that RSocket lets you use its messaging models in either direction. Therefore, if you wanted to use the less common ‘server-requests-a-client-stream’ model, that’s no problem for RSocket. Plus, there are lots of non-java RSocket implementations to choose from, including Go, Javascript, and .Net—ideal if your architecture includes platforms where Java isn’t perhaps the best fit.


Getting Started With RSocket: Spring Boot Fire-And-Forget

Time: about 15 minutes.

Some developers reading this post will have been using HTTP for many years by now. Most of them will also know that if you want to use HTTP with other messaging models — like fire-and-forget, for example — you must sometimes use clever workarounds like this one posted on Stackoverflow. That’s because HTTP is a request-response protocol. It requires a request to be sent and a response to be received. It has no concept of a one-way message without any form of response.

RSocket takes a different approach. RSocket defines a new protocol layer on top of transports like TCP and WebSockets. This new protocol offers greater choice to developers, with built-in support for four distinct interaction models:


Getting Started With RSocket: Spring Boot Client

Time: approximately 15 mins.

In the previous article, you saw how Spring Boot simplifies the task of writing RSocket servers. But what about RSocket clients? In this article, you’ll learn how to write your own RSocket client and then use this new client to send request-response messages to your RSocket-server. Let’s get started!

This tutorial uses the Linux shell. For details on how to run a Linux shell on Windows, see this Microsoft tutorial.

Step 1: Create A New Spring Boot Project For Your Client


Getting Started With RSocket: Spring Boot Server

Time: approximately 15 mins.

In the diverse world of microservices, HTTP is the undisputed leader in agent-to-agent communications. It’s mature, well established, and everywhere. But in some cases, HTTP request-response can be cumbersome. What if you need communication patterns beyond traditional request-response, such as fire-and-forget or streaming? And what if you want to send messages in either direction?

With HTTP, there are ways to achieve this but it’s not what the protocol was built for. Many of the solutions come with additional tradeoffs or shortcomings. Plus, here’s no rulebook that says “thou shalt always use HTTP”, messaging protocols like AMQP proved that already. So, it’s good to know what your options are, and healthy to add a few new technologies to your list every once in a while. This post is about one such alternative—RSocket.