As Spring states, it focuses on the plumbing of enterprise applications.
The initiative was originated based on the versions of Java EE. Java EE defined a set of standards to work with Java in an Enterprise environment. The strategy was to provide configuration and libraries that are common to most applications, especially huge and distributed applications (no trivial ones).
What are those common features? Things like access to external libraries or systems like persistence engines o databases, management of transactions, communication between components and even localization of components or modules, and so on.
The goal was to let the developers work on specific business functionality of each application having almost all that is not business or functionality defined by configuration or the use of defined libraries. These common blocks of the Java EE Standard were assembled on the final application generating a common architecture or few architecture topologies to most of the apps developed.
The main advantage was that the things beyond functionality had a high probability to be almost equally managed in different companies using Java. Then switching between companies and projects did not have a huge learning curve o cost for new developers.
These “standard blocks” defined in the standard were independent components. Then it was relatively easy to decide to change a component to a third-party one.
One of the most controversial components of the standard is EJB, which encapsulates the pieces of code created by developers, making each of them integrate into the distributed huge application. The main pain points of EJB were the initial complexity and poor optimization in resources and speed. Maybe they were projected to do or to scale much more than was expected for a component. Then Spring Framework mainly provided initially a lighter approach to deal with components, more appropriate to the common use of them on many applications. Then, the industry chose to leave the EJB standard to adopt the lighter way to deal with localization and instantiation of components that were provided by Spring Framework for a wide variety of projects.
The instantiation of components by Spring lets Spring capture information and provide services and features that are cross to all the application.
This is the base of the Spring Framework. After that first approach Spring continued to provide a lot of frameworks, tools, services that encapsulate specific behaviour and functionality that in some cases are alternatives to the Java EE standard and in other cases provide additional features without being invasive. At last, if we look at Spring it finished being a “monster” of similar size than Java EE but it is viewed in such cases as a simpler solution because al those solutions were delivered individually.
Why Spring is helpful
To summarize Spring Framework is helpful because initially provided simpler solutions to the most complex ones provided by the Java EE Standard, primarily on localization, instantiation and scope and the relation between components.
The instantiation makes Spring able to deal with a context where all the components can be easily found making transparent the localization and communication between components. Also, as a side effect, facilitates to instantiate mocks for testings environments.
The instantiation of components is performed by “The Spring container”, the main part of the core of the Spring Framework. The container will create the components, configure them, wire them together, and manage their complete life cycle from creation till destruction.
Spring annotations
In the former versions, Spring worked with XML configuration files, like the Java EE Standard. In later releases, Spring added the annotation syntax to declare the Spring presence in the code, providing additional meaning in the code.
Some of the annotations examples are:
@Configuration, @CoverageIgnore, @Inject, @Bean, @Named, @Path, @POST, @Consumes, @Produces
@Configuration
It’s a class that is not a “Spring Component” itself but contains @Bean definitions inside it, like methods. Then those “beans” are accessible and localizable in the Spring Context.
@CoverageIgnore
There are tools like eclemma to measure the coverage of tests. Commonly, a per cent of coverage be mandatory to be accepted or deployed. With @CoverageIgnore can be marked sections of code on which the per cent of coverage is not required and not measured.
@Inject
Is one of the 3 annotations which provide classes with a way to resolve dependencies. The other 2 are @Resource and @Autowired
@Inject can be applied to a field or a setter. And allows Spring to determine which object of the Spring Context would be instantiated for that property (where @Inject is present)
The default behaviour of the @Inject annotation is to resolve dependencies first by type. Then Spring will instantiate the unique Component whose type matches with the field with the @Inject declaration.
The difference between @Inject and @Autowired is that @Inject is generic and @Autowired is Spring specific.
@Bean
The @Bean is the main Component that is managed by the Spring Context. In some cases, we could consider that @Bean is for Spring almost the same Object is for Java. If we manage such level of abstraction, @Bean is the ingredient, the Spring Context deals with.
@Named
@Named is an annotation by which can be put a name to a Spring Component. This is useful where there is some kind of ambiguity or when it is more explanatory to identify a component with a specific label. For example, when there are more of one Component with the same type, @Inject declaration is not enough to identify which specific object of Spring should be instantiated. Then @Named can help to specify the correct Spring object for the correct field.
@Path
The @Path annotation is used to specify the entry point for an external service (e.g. REST)
@POST
The method annotated with @POST expects to receive a POST Http call. It is a JAX RS annotation
@Consumes, @Produces
Annotations to specify MIME types to be received or delivered respectively.
How Spring Boot is used
Spring Boot is used for creating standalone applications. It embeds Tomcat directly into the app, then there is no need to deploy WAR or EAR files. It also with minimal declaration provides a set of commonly used libraries for any purpose.
In combination with Kubernetes or Spring Cloud can be used to make a microservice Architecture on which each “tiny” Spring Boot Application implements a Service.