Oleg Zhurakousky

We are pleased to announce the release of the Spring Cloud Stream Horsham.SR2 (3.0.2.RELEASE) release train which is available as part of Spring Cloud Hoxton.SR2 (just released) and builds on Spring Boot 2.2.4 and Spring Cloud Function 3.0.2.RELEASE which was also just released.

Spring Cloud Stream Horsham.SR2 modules are available for use in the Maven Central repository.

This release contains several fixes and enhancements primarily driven by user’s feedback, so thank you.
For more details please follow these links:
- Spring Cloud Stream Core
- Spring Cloud Stream Core Rabbit Binder
- Spring Cloud Stream Core Kafka Binder
- Spring Cloud Function

We are pleased to announce the release of the Spring Cloud Stream Horsham (3.0.0.RELEASE) release train which is available as part of Spring Cloud Hoxton.RELEASE (imminent) and builds on Spring Boot 2.2.x and Spring Cloud Function 3.0.0.RELEASE which was also just released.

Spring Cloud Stream Horsham.RELEASE modules are available for use in the Maven Central repository.

Quick highlights:

As mentioned in these posts (demystified and simplified, functional and reactive, stream and spring Integration and event routing) preceding this announcement, the core theme of this release is functions!.

We are pleased to announce the release of the Spring Cloud Function 3.0.0.RELEASE, which is available as part of Spring Cloud Hoxton.RELEASE (imminent) and builds on Spring Boot 2.2.x.

Spring Cloud Function 3.0.0.RELEASE modules are available for use in the Maven Central repository.

Quick highlights:

Transparent type conversion

This release introduces a refactored implementation of FunctionCatalog which amongst features such as function composition, support for reactive and non-reactive functions and more introduces transparent type conversion via MessageConverters provided by Spring Messaging.

In preparation for the upcoming releases of Spring Cloud Stream (SCSt) 3.0.0 - Horsham and Spring Cloud Function (SCF) 3.0.0, we’ve been publishing a series of posts discussing and showcasing new features and enhancements.
We provided motivation and justification for moving away from the annotation-based programming model to the functional model, and then we provided more details on the functional approach, as well as reactive functions.
In another post, which is relevant to what we’re going to be discussing here, Artem demonstrated the benefits of combining functional approaches with the Spring Integration project. We also talked about event routing in our last post.

Welcome to another post in a series of posts showcasing the new features of Spring Cloud Stream (SCSt).
In previous posts (available here, here and here), we tried to provide justification for our shift to a functional programming model in Spring Cloud Stream (SCSt). It is less code and less configuration, and your code remains completely decoupled from the internals of SCSt.

Today, we’ll talk about routing with functions.
Routing, in the context of SCSt, is the ability to either a) route events to a particular event subscriber or b) route an event produced by an event subscriber to a particular destination. To help more with the context, let’s quickly look at how things work in the annotation-based programming model. In this post, we’ll refer to it as route ‘TO’ and route ‘FROM’.

We are pleased to announce the first Release Candidate of the Spring Cloud Stream Horsham.RC1 (3.0.0.RC1).

Spring Cloud Stream Horsham.RC1 (3.0.0.RC1) modules are available for use in the Spring Milestone repository.

Quick highlights:

• Spring Boot 2.2.x
• Spring Cloud Function 3.0.0.RC1

Notable features and enhancements for this milestone:

Emphasis on functional programming model

As mentioned in the previous release blogs, with this release we are shifting to a simpler functional programming model.

In the nutshell a simple spring-boot application with at least one function bean is also a spring-cloud-stream application (as shown below).

In the previous post, I tried to provide justification for our shift to a functional programming model in Spring Cloud Stream (SCSt). It’s less code, less configuration. Most importantly, though, your code is completely decoupled and independent from the internals of SCSt.

In this post, I’ll dig a little deeper and summarize the core features of our functional support, specifically around its reactive features.

IMPORTANT: Anything you can do with @StreamListener/@EnableBinding you can also do without it. In other words, the functional support is now feature-compatible with the annotation-based support.

This is the first post in a series of blog posts meant to clarify and preview what’s coming in the upcoming releases of spring-cloud-stream and spring-cloud-function (both 3.0.0).

Recently, I had a discussion with a user and heard something that prompted me to begin a series of blog posts (starting with this one) with the goal of both demystifying the true goals of Spring Cloud Stream and Spring Cloud Function projects as well as demonstrating their new features.

Spring Integration Wrapper?

The specific phrase that prompted all this was - "Spring Cloud Stream, being a light Spring Integration input/output router…”. That’s an interesting perception, but I have to disagree. While it may have been inspired by Enterprise Integration Patterns (EIP) and builds on top of Spring Integration (SI), that last part is really just an implementation detail. Spring Cloud Stream (SCSt) as a framework was never about “being a light Spring Integration input/output router”. In fact, this statement shows part of the problem, where SI (the framework of choice to support some of the internal requirements of SCSt) was somehow perceived to be the core of SCSt in such way that many perceive SCSt to be an extension or a wrapper to SI. It is not. It has always been about pure microservices and binding them to sources and targets of data (i.e., messaging systems) . Simple as that.
If you abstract yourself far enough from knowing the internals of SCSt, you quickly realize that it is really a binding and activation framework. It binds a piece of code (provided by the user) to source/target of data exposed by the binder and activates such code according to binder implementation (for example, message arrival and so on). That is pretty much it.

We are pleased to announce the third Milestone of the Spring Cloud Stream Horsham.M3 (3.0.0.M3).

NOTE: Spring Cloud Stream 3.0.0.M1/M2 was primarily to establish compatibility with Spring Boot 2.2.x. and therefore went unannounced.

Spring Cloud Stream Horsham.M3 (3.0.0.M3) modules are available for use in the Spring Milestone repository.

Quick highlights:

• Spring Boot 2.2.x
• Spring Cloud Function 3.0.0.M2

Notable features and enhancements for this milestone:

Emphasis on functional programming model

While we’re not (yet) deprecating @StreamListener and/or @EnableBinding, we are moving toward a simpler and more natural auto-configuration driven programming model.

We are pleased to announce the second Milestone of the Spring Cloud Function 3.0.0.M2.

NOTE: Spring Cloud Function 3.0.0.M1 was primarily to establish compatibility with Spring Boot 2.2.x. and therefore went unannounced.

Spring Cloud Function 3.0.0.M2 modules are available for use in the Spring Milestone repository.

Quick highlights:

• Spring Boot 2.2.x
• Enhanced deployer (requires a separate blog)

Notable features and enhancements:

Function arity (multiple inputs/outputs)

One of the biggest features introduced with this milestone is support for functions with multiple inputs and outputs. Important thing to point out is that this feature only makes sense in reactive world where you may want to pass several streams to a function for purposes of doing some type of aggregate/merge operation on such streams. For conventional cases you can always send multiple arguments using a Collection of some type.