Home > Chapter 1 - Terminologies > Spring Framework Terminologies

Spring Framework Terminologies


Chapter 1: Terminologies


Design Patterns:

A design pattern is a conceptual general reusable solution to a commonly occurring problem in software design. A design pattern can’t be transformed directly into code. It is a template for how to solve a problem that can be used in many different situations. Design patterns such as Factory, Builder, Decorator, and Service Locator (to name a few) have widespread recognition and acceptance within the software industry. Design patterns are best practices given a name that describe what the pattern does, where the pattern is best applied and the problems that the pattern addresses etc.



Framework is a step ahead of design patterns. It is basically a conceptually organized structure based on best practices and design patterns to address complex issues. A software framework is an abstraction in which generic functionality can be selectively overridden, specialized or extensible by user code. Frameworks are similar to software libraries in way that they are reusable code wrapped in a well-defined API. However unlike libraries, the overall program’s flow of control is not dictated by the caller, but by the framework. This inversion of control is the distinguishing feature of software frameworks.


Object-Oriented Frameworks:

An object-oriented framework is a semi-finished object-oriented application laid out on OOPS concepts such as Inheritance, Polymorphism, Abstraction and Encapsulation.   Object-oriented design patterns typically show relationships and interactions between classes or objects. It encapsulates common features that can be used across the same application or even different applications. Common examples of such frameworks include Apache Struts, JSF, and Spring etc. A framework-driven approach to application development usually involves integration of multiple object-oriented frameworks and creation of specific functionalities as extensions to these frameworks.

Every framework provides its own extension points called hotspots. Hotspots are specific to a framework, usually pertaining to integration (application programming/service provider interfaces) and configuration (external metadata). For example, the EJB 2.0 specifications define hotspots for Java bean objects to be deployed in an EJB container.


Inversion of Control:

Inversion of control is a generic principle and not a design pattern. Rather, it is a broad concept that is implemented by several design patterns.

Inversion of control is applied during communication between a framework and custom application logic. A common feature of frameworks is to maintain control of all communication activities within an application because of which the primary objective of an application module will only be to provide functionalities that can be invoked by the framework. Compare this to a scenario without frameworks, in which there is a significant effort on how the modules can invoke and manage each other.


Application modules won’t have to directly access each other’s capabilities when deployed on top of a framework. The same is also true for invocations from external entities. Instead, every request must be routed through the framework. The framework, in turn, can make multiple calls across more than one module in a controlled fashion before returning a result back to the caller.

In the light of what has been said so far, inversion of control can be summed up as:

“Don’t call us (framework); we’ll call you (application)”


Service Locator pattern:

In a framework-driven scenario, modules access each other’s capabilities indirectly through the framework. Typically, this involves querying the framework to first obtain a reference to the target module. To reduce the lookup complexity of application components, you can apply one of Sun’s core Java EE design patterns, called Service Locator. The idea behind this pattern is as simple, i.e., to use a Java Class as a service locator to encapsulate the lookup logic, while exposing simple methods for lookup. Then, any component can delegate lookup requests to this service locator.



Problems with Service Locator pattern:

  • The query information must be hand-coded in each module that originates a call by performing extra logic to look up for the target module.
  • The query information and operations are specific to the framework. This makes the modules less portable across frameworks.

This is where dependency injection comes in handy.


Dependency Injection:

In early 2004, Martin Fowler on Inversion of control asked “the question is, what aspect of control [they] are inverting?” Fowler then suggested renaming the principle and started to use the term Dependency Injection. Since then, both IoC and DI are used interchangeably but otherwise there is a notifiable difference between them.

Dependency injection is a design pattern that builds on top of the IoC principle. Inversion of control is used by most of the object-oriented frameworks, but not all object-oriented frameworks provide the features of dependency injection.



In many respects, dependency injection is opposite to the service locator pattern. With dependency injection, modules no longer have to look up for each other to invoke functionalities. Instead, each module just declares their preferences to the framework and the framework injects the dependencies based on the preferences declared when necessary.

You can think of DI as JNDI in reverse — instead of an object looking up for dependencies from a container, the container gives the dependencies to the object at its instantiation without waiting to be asked. 



The basic idea of object-oriented design is to break the system into a group of reusable objects. Without a central module to manage the objects, they have to create and manage the dependencies by their own. As a result, the objects are tightly coupled. A container centralizes the creation of objects and acts as a registry to provide lookup services. A container is also responsible for managing the life cycle of objects and providing a platform for the objects to run on. Objects running inside a container are called components. They must conform to the specification defined by the container.

Using a container to manage the components can reduce coupling between different components because a component can look up other components through the container. Active lookup (e.g. ejb container) is a direct and sensible approach for resource retrieval. However, it requires your components to know about resource retrieval.


EJB Container:

  • The EJB specification clearly defines the contract between EJB components and EJB containers. By running in an EJB container, EJB components can get the benefits of life cycle management, transaction management, and security services. However, in EJB versions prior to 3.0, a single EJB component requires a remote/local interface, a home interface, and a bean implementation class. Hence EJBs are called heavyweight components.
  • Moreover, in those EJB versions, an EJB component can only run within an EJB container and must look up other EJBs with JNDI (Java Naming and Directory Interface). So EJB components are technology dependent because they cannot be reused and tested outside the scope of an EJB container.

When using the IoC principle, your component has only to choose a way of accepting resources and the container will deliver resources to your components. This is also called passive look up. (eg: Spring container)


Spring Container:

Spring container uses dependency injection (DI) to manage the components that make up an application. This includes creating associations between components. As such, these objects are cleaner and easier to understand, support reuse, and are easy to unit-test.


Plain Old Java Object (POJO):

The term POJO means an ordinary Java object without any specific requirements, such as to implement a specific interface or to extend a specific base class. This term is used to distinguish lightweight Java components from heavyweight components in other complex component models (e.g., EJB components in versions prior to 3.0).


Spring Beans:

In Spring, components are also called “beans”. Note that this is a different concept from the JavaBeans specification defined by Sun. The beans declared in the Spring IoC container are not necessarily required to be JavaBeans. They can also be POJOs (Plain Old Java Objects).






  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: