Archive

Posts Tagged ‘framework’

Spring Framework Introduction

November 20, 2009 Leave a comment

 

Chapter 2: Introduction to Spring

 

Spring Framework:

The Spring framework is a comprehensive layered Java/Java EE application platform. It was created to address the complexity of enterprise application development. The Spring Framework takes best practices and design patterns that have been proven over the years, codifies these patterns as first class objects that can be integrated into applications. Spring makes it possible to use plain-vanilla Java Beans (POJOs) to achieve things that were previously only possible with EJBs.

 

Spring includes:

  • An IOC lightweight container
  • AOP functionality
  • Abstraction layer for JDBC / transaction management                    
  • ORM integration layer
  • Web integration layer
  • A flexible MVC web application framework 

 

Spring is not only an application framework, it also serves as a platform for several open source projects that are based on the core Spring Framework project such as Spring IDE, Spring Security, Spring Web Flow, Spring Web Services, Spring Rich Client,  Spring Batch, Spring Modules, Spring Dynamic Modules, Spring Integration, Spring LDAP, Spring JavaConfig, Spring .NET, Spring BeanDoc.

 

Spring’s features:

Framework:

Spring makes it possible to develop and maintain complex applications using simple components. In Spring, application objects are configured declaratively typically in an XML file. Spring also provides much infrastructure functionality (transaction management, integration, etc.), leaving only the development of application logic to you.

 

Lightweight:

Spring is lightweight in terms of both size and overhead. Spring Framework can be distributed in a single JAR file that weighs just over 2.5 MB and the processing overhead required by Spring is negligible. Spring is non intrusive in a way that the objects in a Spring-enabled application often have no dependencies on Spring-specific classes.

 

Container:

Spring provides a container which contains and manages the lifecycle and configuration of application objects. In Spring, you can declare how each of application objects should be created, how they should be configured, and how they should be associated with each other.

 

Dependency Injection:

Spring promotes loose coupling through dependency injection (DI). When DI is applied, objects are passively given their dependencies instead of looking for dependencies themselves. 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.

 

Aspect-oriented:

Spring comes with rich support for aspect-oriented programming (AOP) that enables separating application business logic from system services (such as auditing, transaction management, logging etc). Application objects do what they’re supposed to do i.e., perform business logic — and nothing more. They are not responsible for or even be aware of other system concerns, such as logging or transactional support.

 

Spring Framework Architecture: Read more…

Spring Framework Terminologies

November 19, 2009 Leave a comment

 

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:

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: Read more…