Beginning Spring

Mert Caliskan, Kenan Sevindik

• Publisher: Wrox
• Year: 2015
• Print ISBN: 9781118892923
• eBook ISBN: 9781118893111
• Edition: 1
• Topic: Computer Science
• Subtopic: Object Oriented Programming
• Index: Computer Science

Get up to speed quickly with this comprehensive guide to Spring

Beginning Spring is the complete beginner's guide to Java's most popular framework. Written with an eye toward real-world enterprises, the book covers all aspects of application development within the Spring Framework. Extensive samples within each chapter allow developers to get up to speed quickly by providing concrete references for experimentation, building a skillset that drives successful application development by exploiting the full capabilities of Java's latest advances.

Spring provides the exact toolset required to build an enterprise application, and has become the standard within the field. This book covers Spring 4.0, which contains support for Java 8 and Java EE 7. Readers begin with the basics of the framework, then go on to master the most commonly used tools and fundamental concepts inherent in any Spring project. The book emphasizes practicality and real-world application by addressing needs such as meeting customer demand and boosting productivity, and by providing actionable information that helps developers get the most out of the framework. Topics include:

• Dependency Injection and Inversion of Control
• Unit testing Spring enabled Web Applications
• Data Access using Spring JDBC and ORM support along with Transaction Management
• Building Web Applications and RESTful Web Services with Spring MVC
• Securing Web Applications using Spring Security
• Spring Expression Language with its Extensive Features
• Aspect Oriented Programming Facilities Provided by Spring AOP
• Caching with 3rd Party Cache Providers' Support
• The Best of the Breed: Spring 4.0

The information is organized and structured an ideal way for students and corporate training programs, and explanations about inner workings of the framework make it a handy desk reference even for experienced developers. For novices, Beginning Spring is invaluable as a comprehensive guide to the real-world functionality of Spring.

1
POJO Programming Model, Lightweight Containers, and Inversion of Control

WHAT YOU WILL LEARN IN THIS CHAPTER:

• Problems of the old EJB programming model that triggered the birth of POJO movement
• Advantages of the POJO programming model
• What a container is and what services it provides to its deployed applications
• Lightweight containers and what makes a container lightweight
• What Inversion of Control (IoC) means and its importance for applications
• Relationship between IoC and dependency injection
• Dependency injection methods, setter and constructor injection
• Advantages and disadvantages of those different dependency injection methods

The Plain Old Java Object (POJO) movement started around the beginning of the 2000s and quickly became mainstream in the enterprise Java world. This quick popularity is certainly closely related with the open source movement during that time. Lots of projects appeared, and most of them helped the POJO programming model become mature over time. This chapter first closely examines how things were before the POJO programming model existed in the enterprise Java community and discusses the problems of the old Enterprise JavaBeans (EJB) programming model. It's important that you understand the characteristics of the POJO programming model and what it provides to developers.

The second half of the chapter focuses on containers and the inversion of control patterns that are at the heart of the lightweight containers we use today. You learn what a container is, what services it offers, and what makes a container lightweight. You also learn how the inversion of control pattern arises and its close relationship with dependency injection terms. The chapter concludes with an examination of two different dependency injection methods and their pros and cons.

POJO PROGRAMMING MODEL

POJO means Plain Old Java Objects. The name was first coined by Martin Fowler, Rebecca Parsons, and Josh MacKenzie to give regular Java objects an exciting-sounding name. It represents a programming trend that aims to simplify the coding, testing, and deployment phases of Java applications—especially enterprise Java applications.

You'll have a better understanding of what problems the POJO programming model solves if you first understand what problems the old EJB programming model had.

Problems of the Old EJB Programming Model

The Enterprise JavaBeans (EJB) technology was first announced around 1997. It offered a distributed business component model combined with a runtime platform that provided all the necessary middleware services those EJB components needed for their execution. It was a main specification under the J2EE specification umbrella at the time.

Many people were really excited by the promise of the EJB technology and J2EE platform. EJBs were offering a component model that would let developers focus only on the business side of the system while ignoring the middleware requirements, such as wiring of components, transaction management, persistence operations, security, resource pooling, threading, distribution, remoting, and so on. Developers were told that services for middleware requirements could be easily added into the system whenever there was any need of them. Everything seemed good and very promising on paper, but things didn't go well in practice.

The EJB 2.x specification required that the component interface and business logic implementation class extend interfaces from the EJB framework package. These requirements created a tight coupling between the developer-written code and the interface classes from the EJB framework package. It also required the implementation of several unnecessary callback methods, such as ejbCreate, ejbPassivate, and ejbActivate, which are not directly related to the main design goal of EJB.

To develop an EJB component, developers had to write at least three different classes—one for home, one for remote interfaces, and one for business objects, as shown here:

 public interface PetClinicService extends EJBObject { public void saveOwner(Owner owner) throws RemoteException; } public interface PetClinicServiceHome extends EJBHome { public PetClinicService create() throws RemoteException, CreateException; } public class PetClinicServiceBean implements SessionBean { private SessionContext sessionContext; public void ejbCreate() { } public void ejbRemove() { } public void ejbActivate() { } public void ejbPassivate() { } public void setSessionContext(SessionContext sessionContext) { this.sessionContext = sessionContext; } public void saveOwner() throws java.rmi.RemoteException { //implementation of saving owner instance... } } 

The preceding code snippet shows the minimum amount of code that needs to be written in order to create an EJB component with only one method using the EJB2 application programming interface (API). Although the remote interface defined the public API of the business object class to the outside world, a non-mandatory requirement in the specification asked that the business object class implementation not depend on the remote interface directly. When developers obeyed this warning, however, they were opening up a possibility that business object class implementation and its public API remote interface would become unsynchronized whenever the method declarations were modified in one of those classes. The solution was to introduce a fourth interface, which was implemented by the business object class and extended by the remote interface to keep the remote interface and the business object class implementation synchronized while not violating this non-mandatory requirement.

There were actually two interfaces that defined the public API of the business object class: the remote and local interfaces. Local interfaces were introduced to the EJB specification when people realized that remote interfaces were causing unnecessary performance overheads in systems in which there were no physically separated layers, and there was no direct access to the EJB layer from another client in the architecture, except through servlets. However, when developers needed to make EJB components remotely available they had to create a remote interface for them. Although there was no direct dependency between the business object class and its remote interface, all public methods of the business object implementation class had to throw RemoteException, causing the business object implementation class to depend on EJB and remoting technologies.

Testability was one of the biggest problems of the old EJB programming model. It was almost impossible to test session and entity beans outside the EJB container; for example, inside an integrated development environment (IDE) using JUnit. This is because dependencies of those session beans were satisfied through local or remote interfaces, and it was very hard—but not impossible—to test session beans in a standalone environment. When it came time to run or test entity beans outside the container, things were more difficult because the entity bean classes had to be abstract and their concrete implementations were provided by the EJB container at deployment time. Because of such difficulties, people tried to access the EJBs deployed in the container and test them using in-container test frameworks, such as Cactus. Nevertheless, such solutions were far from the simplicity and speed of running tests within a standalone environment by right-clicking and selecting Run As JUnit Test.

The deployment process was another time-consuming and error-prone phase of the EJB programming model. Developers used deployment descriptor files in XML format to deploy developed EJB components, but configuring their middleware requirements, such as transaction semantics, security requirements, and so on, caused those files to become several hundred lines long. Developers usually were trying to maintain the files by hand, and it was quite easy to make simple typos in package or class names, and those errors wouldn't be noticed until deployment time.

The following code snippet contains two EJB definitions, one depending on the other, and it includes a container-managed transaction configuration as well. Imagine how things can go wrong when you have dozens of other EJB definitions, each having its own dependencies, transaction management, security configurations, and so on:

 <ejb-jar> <display-name>PetClinicEJB2</display-name> <enterprise-beans> <session> <ejb-name>PetClinicService</ejb-name> <home>com.example.PetClinicServiceHome</home> <remote>com.example.PetClinicService</remote> <ejb-class>com.example.PetClinicServiceImpl</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <resource-ref> <res-ref-name>jdbc/ds</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> </session> <message-driven> <ejb-name>MessageSubscriber...

Table of contents

• Cover
• Foreword
• Introduction
• Chapter 1: POJO Programming Model, Lightweight Containers, and Inversion of Control
• Chapter 2: Dependency Injection with Spring
• Chapter 3: Building Web Applications Using Spring MVC
• Chapter 4: JDBC Data Access with Spring
• Chapter 5: Data Access with JPA Using Spring
• Chapter 6: Managing Transactions with Spring
• Chapter 7: Test-Driven Development with Spring
• Chapter 8: Aspect-Oriented Programming with Spring
• Chapter 9: Spring Expression Language
• Chapter 10: Caching
• Chapter 11: RESTful Web Services with Spring
• Chapter 12: Securing Web Applications with Spring Security
• Chapter 13: Next Stop: Spring 4.0
• Appendix: Solutions to Exercises
• Title Page
• Copyright
• Dedication
• About the Authors
• About the Technical Editor
• Credits
• Acknowledgments
• Index
• End User License Agreement