Why Spring is called a lightweight framework

  • Spring is considered lightweight compared to traditional Java EE applications.
  • It is lightweight because it allows minimally invasive development with POJOs.
  • We consider Spring to be lightweight when we are comparing to normal J2EE container.
  • It is lightweight in the sense of extra memory footprint for the facilities provided (e.g. Transaction Control, Life Cycle, Component dependency management)
  • Spring calls itself ‘lightweight’ because you don’t need all of Spring to use part of it. For example, you can use Spring JDBC without Spring MVC.
  • Spring provides various modules for different purposes; you can just inject dependencies according to your required module. That is, you don’t need to download or inject all dependencies or all JARs to use a particular module.
  • Whether it is “lightweight” or “heavyweight”, it is all about comparison. We consider Spring to be lightweight when we are comparing to normal J2EE container. It is lightweight in the sense of extra memory footprint for the facilities provided (e.g. Transaction Control, Life Cycle, Component dependency management)
  • However, there are sometimes other criteria to compare for the “weight” of a container, e.g. intrusiveness in design and implementation; facilities provided etc.
  • Ironically, Spring is sometimes treated as heavy weight container when compared to other POJO-based container, like Guice and Plexus.
  •  “lightweight” is mostly a buzz-word. It’s meaning is highly subjective and based on context. It can mean “low memory footprint”, it can be low execution overhead, low start-up overhead. People also use it to differentiate between some perceived level of complexity and/or learning-curve. In any case, it’s assuredly relative as there is no defined point on any scale where “light” becomes “heavy” in terms of “weight”.

What is a Lightweight Web Application

For this we need to understand a heavyweight web application.

  • The primary focus of J2EE is for developing distributed and loosely coupled middleware applications
  • Those applications typically have a web front end and a relational database backend. As web applications become popular in recent years, J2EE has gained wide acceptance among developers. In fact, J2EE is one of the few dominant web application platforms today.
  • However, as J2EE is more widely used, developers are also increasingly frustrated by its complexities.
  • The original design of J2EE addresses the distributed computing problems and application scalability problems that only the biggest enterprises encounter.
  • Apart from deviating from the original design reason, Most developers use J2EE to develop small to middle sized web applications.
  • Those “enterprise features” not only are of limited use but also add unnecessary complexity to otherwise simple web applications.
  • The problems have grown as J2EE has evolved and added more features to address a wider range of enterprise use cases.
  • In order to make enterprise Java more appealing to majority of developers who work with small web applications, the Java community has made major efforts to simplify Java web and middleware frameworks.
  • The enterprise Java specification after J2EE 1.4 is called Java EE 5.0. This change highlights the significant changes lightweight frameworks brought to the enterprise Java standards.

The J2EE 1.4 specification, released in 2004, is the last version of heavyweight J2EE.

What is a typical JEE application?

  • A typical J2EE web application has servlets that take in user input and generate the response by displaying JavaServer Pages.
  • The servlet delegates business operations and database-related work to an EJB (Enterprise JavaBeans) module containing session bean objects and entity bean objects.
  • The stateless session bean typically contains transactional methods to perform business operations.
  • Those methods are exposed to the servlet.
  • The session bean makes use of entity beans to access the relational database.
  • In the XML configuration files, we define how to use container services (e.g., transactions and security) from the session beans, as well as how the entity beans are mapped to database tables.
  • Figure 1.1, “Architecture of a J2EE 1.4 web application” shows the above-described architecture
  • Since the EJB managed components cannot be serialized out of the container, we have to use value objects to exchange data across the layers (i.e., method call parameters and return values).

Architecture of a J2EE 1.4 web application

All the J2EE components work together to serve a common purpose”

  • to make the application more scalable.

    Below is a list of key architectural characteristics that makes J2EE great.

    Component-based architecture:

    J2EE components are advanced forms of Java objects. Each component completely encapsulates its own code, configuration, and outward interface. The entire application can be composed from a set of reusable components. Those components can reside on a single computer or on a network of computers to improve application scalability. As we will see in the next several bullet items, components make the application simpler and easier to maintain.

    Loose coupling between components:

    When J2EE components make method calls against another component (e.g., the servlet calls a method in the session bean), the caller component never instantiates the callee component. Instead, the caller requests a reference (or “stub”) to the callee from the container using the callee’s interface. The container manages all the object creation and the components are only coupled by interfaces. The benefit is that when we change a component implementation, the effect of the change would not ripple out of the component itself as long as we keep its published interface stable.

    Shared services provided by the container:

    The J2EE container provides common application services, such as transaction management, network connection pools, access security, data persistence, and logging, to the components. That allows the application to focus on the business logic.

    Declarative configuration:

    In J2EE, you can simply configure how the container service is delivered to your components using XML configuration files. The use of metadata to configure services reduces the clutter in the code and makes J2EE components easier to maintain.

    A complete Object Relational Mapping (ORM) solution:

    You can use J2EE entity beans to model application data stored in a backend relational databases. That allows you to operate on Java objects instead of dealing with the relational model via SQL statements. The details of vendor-dependent SQL statements are generated by the container and are completely transparent to the application developer.

What is a Lightweight Framework

  • The “lightweight” component approach was originally proposed to counter the “heavyweight” approach in EJB 2.1
  •  EJB 2.1 is the core business component framework in J2EE 1.4, and it is notoriously hard to use
  • EJB3 is core to Java EE 5.0, and is an industry-wide effort to standardize a lightweight framework for Java enterprise developers.
  • EJB3 looks almost completely different from EJB 2.1, yet it captures the flexibility and power of the J2EE way.
  • (a)  POJOs as Components
  • (b) Annotation-based Metadata for Services Configuration
  • (c) Dependency Injection
  • (d) Extensible Container Services

Reference:

https://docs.jboss.org/books/lightweight/ch01.html