lightweight container (LWC)
Generally speaking, containers as a special form of frameworks implement runtime environments in which objects are managed. In addition, basic services are made available to these objects. A central feature of lightweight containers is the use of the Dependency Injection methodology - a special form of the Inversion of Control principle. Here, the relationships between components are only established at runtime, making it possible to provide different implementations of a component.
Inversion OF Control( IoC) is one of the most important concepts of Frameworks for the development of maintainable as well as testable code, which is besides still small coupled. Lightweight containers assist in configuring applications. Instead of through various configuration files, dynamically at runtime all configurations can be done centrally in one place. A well-known example of a lightweight container is the Springframework, in which the domain-oriented classes are implemented as so-called POJOs - this is an acronym for simple Java classes. Other examples of lightweight containers are the frameworks Avalon, Keel, Pico or HiveMind, which are available as open source and all offer functionalities that can be used as an alternative to Enterprise JavaBeans (EJBs).
The term container in the context of lightweight containers often refers to a meta- framework. This provides generic mechanisms for locating and loading an object using a symbolic name, as well as managing the lifecycles of objects. By including other frameworks - which is why a lightweight container is also referred to as a meta-framework - additional services such as persistence services can be provided. Lightweight containers can thus offer similar functionality to application servers - the objective, however, is to remove the binding to application servers themselves.
Characteristics of lightweight containers
Lightweight containers (LWC) can be characterized in terms of their properties as follows:
- An LWC should manage the code of an application or its objects, but not create any additional dependencies. For example, it should be possible to execute legacy code without any further adaptations.
- An LWC can be started very quickly.
- No complex deployment process needs to be started in order to place objects in the LWC.
- An LWC should fundamentally require minimal resources and have minimal dependency on interfaces. This then allows the code to run in a variety of environments such as J2SE, J2ME or J2EE
- An LWC should fundamentally minimize the effort required to deploy managed objects so that it can be used for objects regardless of their granularity. Granularity defines the degree of aggregation.
This inevitably leads to the reasons why, for example, EJB containers are not assigned to lightweight containers:
- Code written for the EJB model basically does not run outside the EJB container. Thus, the code is always dependent on the container.
- EJB containers are relatively slow to start up.
A central aspect in the decision for a lightweight container is the requirement for the greatest possible independence of the application code from the container. Here it is worth remembering the great dependency of the code before the introduction of EJB 3.0. However, since objects cannot work in isolation from each other, appropriate mechanisms for interobject communication are required. Without creating additional dependencies on the container, the principle of Inversion of Control (IoC) is often used for interobject association, and there Dependency Injection as its special manifestation.
For a detailed explanation of the principle, please refer to the corresponding main article; in this context, the figure illustrates the different types of Inversion of Control.
The following advantages speak for the use of a lightweight container:
- It is not a monolithic container.
- The reusability of the code is given.
- Better object orientation.
- Larger productivity due to which code can be written more simply in each development environment.
- Better testability of the components.
The following lightweight container implementations are known and available as open source:
Avalon Framework Was 1999 one of the first containers after the inversion of control principle. Is also called invasive framework, because the code must be adapted, so that the Avalon-specific interfaces are considered. The Avalon framework was further developed under the name Excalibur.
Spring Framework Is a comprehensive implementation of a lightweight container. Offers among other things also the inclusion of a framework for aspect-oriented programming. Furthermore, the integration of various persistence technologies, a transparent transaction management and more are offered.
Keel Framework Is a meta-framework and integrates the functionality of several frameworks. Similar goals are pursued as by Spring, without Keel being able to establish itself on the market.
Pico Container Realizes a container, which offers however no further features like Spring. Likewise, no frameworks can be integrated from the external side.
HiveMind is also an IoC container. The integration of aspect-oriented programming is also possible here. Also does not have the powerful range of functions as the Spring Framework.