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.