Why Spring, Benefits using Spring Framework?

Following are the several reasons why I prefer Spring Framework:1. It addresses important areas that other popular frameworks don't. Spring

focuses around providing a way to manage your business objects.2. Spring is comprehensive and modular. Spring has a layered architecture,

meaning that you can choose to use just about any part of it in isolation, yet its architecture is internally consistent. So you get maximum value from your learning curve. You might choose to use Spring only to simplify use of JDBC, for example, or you might choose to use Spring to manage all your business objects. And it's easy to introduce Spring incrementally into existing projects.

3. Spring is designed from the ground up to help you write code that's easy to test. Spring is an ideal framework for test driven projects.

4. Spring is an increasingly important integration technology, its role recognized by vendors large and small.

5. The Spring Framework is the core of the Spring Portfolio , an increasingly complete solution for enterprise Java development, exhibiting the same consistency of approach developed in the Spring Framework itself.

  #3  

25-04-2009

pancham Member

 Join Date: Dec 2008Posts: 144

Re: Why Spring, Benefits using spring framework?

Architectural benefits of Spring Spring can effectively organize your middle tier objects. Spring takes care of

plumbing that would be left up to you if you use only Struts or other frameworks geared to particular J2EE APIs. And Spring's configuration management services can be used in any architectural layer, in whatever runtime environment.

Spring can eliminate the proliferation of Singletons seen on many projects. In my experience, this is a major problem, reducing testability and object orientation.

Spring eliminates the need to use a variety of custom properties file formats, by handling configuration in a consistent way throughout applications and projects. Ever wondered what magic property keys or system properties a particular class looks for, and had to read the Javadoc or even source code? With Spring you simply look at the class's JavaBean properties or constructor arguments. The use of Inversion of Control and Dependency Injection (discussed below) helps achieve this simplification.

Spring facilitates good programming practice by reducing the cost of programming to interfaces, rather than classes, almost to zero.

Spring is designed so that applications built with it depend on as few of its APIs as possible. Most business objects in Spring applications have no dependency on Spring.

Applications built using Spring are very easy to test. For certain unit testing scenarios, the Spring Framework provides mock objects and testing support classes. Spring also provides unique “integration testing” functionality in the form of the Spring TestContext Framework and legacy JUnit 3.8 support

Classification: GE Internal

classes that enable you to test your code quickly and easily, even while accessing a staging database.

Spring helps you solve problems with the most lightweight possible infrastructure. Spring provides an alternative to EJB that's appropriate for many applications. For example, Spring can use AOP to deliver declarative transaction management without using an EJB container; even without a JTA implementation, if you only need to work with a single database, or want to avoid two phase commit.

Spring provides a consistent framework for data access, whether using JDBC or an O/R mapping product such as TopLink, Hibernate or a JPA or JDO implementation.

Spring provides a consistent, simple programming model in many areas, making it ideal architectural "glue." You can see this consistency in the Spring approach to JDBC, JMS, JavaMail, JNDI and many other important APIs.

  #4  

25-04-2009

Adley Member

 Join Date: Oct 2008Posts: 132

Re: Why Spring, Benefits using spring framework?

If you use Spring you can scale up in power a bit. Some of the benefits are: Declarative transactions. More testable code. Promotes good OO design Removes boilerplate code Great lightweight remoting support Good documentation and samples.

Spring MVC also has advantages over Stuts:- No ActionForms. Bind directly to domain objects- More testable code (validation has no dependency on Servlet API)- Well defined interface to business layer

For example of Spring reducing the boilerplate code, it can turn:

Code:

public List findAllEmployees() {SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();Session session = sessionFactory.getSession();try {return session.find("from Employee order by surname, firstname");} finally {try {session.close()} catch(HibernateException he) {throw new CustomRuntimeDAOException(he);}

Classification: GE Internal

}}intopublic List findAllEmployees() {return getHibernateTemplate().find("from Employee order by surname, firstname");}

In 1990, I discovered white water. I thought I was completely in control. Whenever my friends and I ran the smallest rapid, we'd leave one boater at the end of the rapid and put two boaters on the banks with throw ropes. We thought we could prevent anything bad from ever happening. While it was nice to have that illusion of perfect control, it just wasn't practical. We learned to scout the easier rapids from the cockpit of the boat and take steps to look out for each other. We took more time to set up good safety measures for the most dangerous rapids. And in a few instances, that extra time made all the difference in the world.

In kayaking, a lightweight strategy born on southeastern steep creeks saved me time so I could paddle longer rivers and have more fun without compromising safety. In business, lightweight development lets you finish on time and react to your customers, saving you time and money.

In this series of articles, I focus on the basics of lightweight development -- an overloaded term if ever there was one. This first article sets the groundwork and defines lightweight development. Future articles will move freely from process to principles to tools. I'll also focus on implementation philosophy and architecture at a higher level, and provide actual implementation details in code.

This series is for developers who haven't done much lightweight development. If you've used the Spring lightweight container for two years with an agile process, you might not gain much. However, if you've worked with Enterprise JavaBeans™ (EJBs) in a traditional development process, but want to move to lightweight development, this series may be just the thing for you.

More than anything, I want to shed some light on this impressive movement sweeping through the Java™ technology community. The lightweight buzzword graces containers like Spring and Pico. And techniques from lightweight processes, such as automated unit testing, now infiltrate many, if not most, development shops.

Debunking the myths of lightweight development

Classification: GE Internal

"Lightweight development" is usually attached to a set of development methods, frameworks, and design philosophies that go well together.

Lightweight methodologies include agile processes like extreme programming (XP) and Scrum. They emphasize test-first development, heavy customer involvement, and refactoring.

Lightweight frameworks usually encourage programming with plain old Java objects (POJOs) over heavier component-oriented models like EJB.

Lightweight design patterns let you loosen coupling between objects and integrate services without forcing code into business logic or the domain model.

As we investigate these ideas and technologies, you'll learn more about each one. But first, let's clear up a few myths.

Myth: Lightweight developers play with toy technologies

Some development tools, like Microsoft® Visual Basic or PHP, often don't scale or manage complexity well enough for large enterprise projects, so they earn the toy label. Lightweight technologies like Spring and Hibernate are often dismissed as such. In fact, most lightweight techniques evolved in enterprise development because other techniques let us down. The Spring framework evolved as a lightweight alternative to EJB. Similarly, the XP method evolved based on some failures in an enterprise setting. The principles in my Jolt-winning book Better, Faster, Lighter Java provide information about tools successfully deployed at my customer sites, including some Fortune 500 companies. Lightweight technologies thrive in the enterprise realm.

Myth: Lightweight development strategies build toys

Likewise, you might be tempted to believe that lightweight development is useful only for building toy applications. Your goal is to deliver precisely what your customers want and need. Let me be clear: Lightweight technologies can build things that scale. In fact, the most impressive scaling usually happens because simple, elegant, stateless designs let the infrastructure do its job.

Myth: A lightweight process lets you ignore discipline

In lightweight development, you need to carefully plan and negotiate requirements, and you have to build rigorous automated unit tests to enable better refactoring. You fully integrate when you drop changes, and the automated build notifies you when a test case fails or a change induces errors. Lightweight development must be more disciplined than other techniques, but the discipline comes from different sources.

I'm suggesting that this development style goes beyond a single technology or process. If you want to lighten up, you need to select principles, processes, and technologies that make it easy to work that way.

Classification: GE Internal

Back to top

Principles

When all is said and done, you need to decide what you value and make decisions based on those values. If I feel that clients are misguided or unfocused, I'll often help them establish some core principles first. The following list is a good starting point:

Strive for simplicity. This value should permeate all that you do. Your process should produce only enough artifacts to get the job done. Developers should always try the simplest approach that can solve a problem. Your tools should let you build clear, simple solutions.

Fix what's broken. Some development methods may discourage refactoring or changes in a process because those activities do not directly contribute to generating customer code. Lightweight development demands the freedom to fix code that gets too complex or bug-ridden. Budget for it. Demand it.

Automate unit tests. Preferably, you should code test cases first. You may not have success with test-first development, but accumulating test collateral gives you the freedom to refactor your code. I'll go even further: Extensive unit testing improves your customer experience and the design in your code because it forces you to decouple code that's bound too tightly together.

Use short cycles and active customer participation. Many of the best programming shops simplify by eliminating unnecessary artifacts. If you've got great customer participation, massive functional specifications become increasingly unnecessary. Customers will enjoy the interaction and appreciate your short cycle times because you'll be delivering business value at regular increments.

These principles don't completely encompass your technology choices and development process, but they go a long way toward defining your development experience. When managers know and follow these principles as well, developers have some ammunition when combating an ineffective technology choice or unnecessary bureaucracy. After you establish principles, it's time to carve out an effective process.

Back to top

Process

A tighter, faster development process usually takes ideas from a family of methods known as agile development methods. These methods aren't for everyone, though. If you have a large team and no real access to the customer or a suitable surrogate, you're better off with a more traditional method. But many projects have small enough teams -- no

Classification: GE Internal

more than about a dozen people -- and sufficient access to a customer to make such methods fly. Usually, agility embraces principles like these:

Focus on an on-site customer and code, rather than other design artifacts. You can use other artifacts, but only if they help you do your job. The process doesn't require it.

Simplify the documentation that you need. For requirements, prefer a line in a spreadsheet to a fancy use-case diagram.

Do only enough design work to get the job done. Don't anticipate design or performance problems, and don't back yourself into a corner.

For development, strive for simplicity, integrate your build at least daily, and refactor when necessary.

Automate your testing.

Even if you work in a traditional organization, you can take advantage of a trimmed-down development process. The trick is to sell principles rather than methodologies. While selling your manager on extreme programming -- or anything else with extreme in the title -- can be tough, selling principles like improved unit testing often makes more sense. In fact, many of my customers use this technique to work an agile development process into their conservative organizations, but their bosses have no idea that anything is different.

Think of this technique in terms of rhetoric. Principles are lightweight ideas that pack a punch. A process is heavyweight rhetoric, and you'll have a much bigger problem implementing it.

Back to top

Technologies

I've provided an overview of the design philosophies that most lightweight developers need to know and the important open source technologies out there that leverage these philosophies.

Dependency injection

The new breed of containers, called lightweight containers, all use a common design philosophy: dependency injection. It's a complicated term for a simple idea. Dependency injection lets you give an object and its dependencies to a third party. The third party then creates all the objects and wires them together. For example, say a data access object called myDao needs a data source called ds. The container creates them both and sets a property:

Classification: GE Internal

Listing 1. Creating a third-party assembler

myDao = new Dao();ds = new DataSource();myDao.setDataSource(ds);

Of course, instead of creating a third-party assembler like this one, you could rely on a framework to do it for you and to do additional work like providing configuration support. The Spring framework, Pico, and HiveMind take on this role. Other frameworks, like JavaServer Faces (JSF), also leverage dependency injection.

Aspect-oriented programming

With aspect-oriented programming (AOP), you can code common blocks of functionality (called aspects) -- such as logging, transactions, security, or persistence -- in one place. AOP lets you attach these aspects to POJOs, then specify a point in time (like the beginning of a method or exception generation) and another aspect to attach. For example, you might want to make a facade object-transactional. You would attach a TransactionBegin aspect to the facade's methods when the method fired. Then you attach a RollBack aspect to the facade's exception when an exception fired. Finally, you attach a Commit aspect to the facade's method when the method ended. You do this work in configuration, rather than in code. With this ability, you can make a simple POJO transactional, secure, or remote-accessible.

You've essentially got declarative transactions on a POJO, an extremely useful capability for enterprise applications. With these tools at your disposal, you might decide to forgo EJB altogether or at least minimize its role. And that's precisely what lightweight containers let you do.

Transparent persistence

Persistence, too, is settling on a simpler programming model. Transparent persistence frameworks let you add persistence to applications through configuration rather than code. Because most of the applications written these days are object-oriented and access a relational database, some experts assert that the time for object-relational mapping is finally upon us. The top persistence solutions that I have found are SolarMetric's Kodo JDO and Hibernate (see Resources). I'll compare these solutions in detail later in this series. Other lightweight solutions, such as iBATIS and the Active Record design pattern, don't try to do object-relational mapping at all.

Back to top

Summary

Classification: GE Internal

Basically, in lightweight development, you:

Incorporate process, technology, and philosophy. Prefer simpler technologies. Build on a solid, lightweight foundation. Strive for the best possible transparency. Use ideas that give you leverage, like dependency injection and AOP.

It's important to understand that neither technologies nor processes can completely define lightweight development. It's an all-encompassing philosophy. As this series progresses, you'll see different types of discussions about lightweight technologies and philosophies. I'll focus first on open source frameworks with an emphasis on lightweight containers. In future articles, I'll talk about implementing lightweight methods in conservative companies and even some alternatives that go beyond Java technology. I'm excited about this series, and hope you enjoy it.

Resources

Learn

Read Better, Faster, Lighter Java by Bruce Tate and Justin Gehtland for a good overview of lightweight development.

Spring: A Developer's Notebook by Bruce Tate and Justin Gehtland can help you get started quickly on Spring.

Pro Spring provides a more comprehensive treatment of Spring. Heavyweight architectures, such as Enterprise Java Beans can be overkill for

everyday problems. "Secrets of lightweight development success, Part 2: How to lighten up your containers" introduces lightweight containers and explains how they can provide the services your business needs without tying you to a given programming model.

Learn the basics of lightweight containers in "Secrets of lightweight development success, Part 3: The emergence of Spring."

In Part 4 of the series, three popular containers are compared: Spring, HiveMind, and PicoContainer.

Lightweight development works best with a lightweight process, but it can be tough to get a conservative company to adopt agile methodologies. Learn how you can propose and promote lightweight processes in your organization in Part 5 of this series.

The developerWorks article "Object-relation mapping without the container" shows you how to use Spring persistence with Hibernate.

Read the developerWorks article "AOP@Work: AOP tools comparison, Part 1" for a treatment of AOP, a lightweight technique that can give you much better transparency.

Classification: GE Internal

Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.

Get products and technologies

Innovate your next open source development project with IBM trial software, available for download or on DVD.

Discuss

Get involved in the developerWorks community by participating in developerWorks blogs.

I'm an avid mountain biker. Some mountain bikers love hardcore equipment -- behemoths that are fully suspended (with huge shocks in the front and back) -- and push them to unnatural limits. I ride in the hill country around Austin, Texas, where the many rocky ledges mean I've got to have a suspended bike, but a behemoth won't work for me. I can't make it up the grueling climbs with a lot of extra weight. I've got to have a light bike.

The Java industry has gone through a few similar fads. EJB technology provided hardcore enterprise services. If you programmed to a complex component-based model, you could put your business components into a container that would provide services such as transactions, remoting, security, and persistence.

There was a cost, though. The heavyweight architectures were overkill for many problems. For example, entity beans made you code up to seven files for each entity. EJB technology just wasn't worth all the extra effort it took to solve everyday problems. Today, businesses still need the enterprise services, but they're looking in a new direction to get them. They're using lightweight containers. In fact, the new EJB V3.0 standard uses the lightweight container model.

What are lightweight containers?

Most container APIs, like EJB APIs, force you to code to some interface or a component model. You put your component into the container, and the container does something for you. EJB containers provide enterprise services. Servlet containers, such as Apache Jakarta Tomcat, implement the Servlet API, letting you build dynamic content into pages on the server that can then be sent to a Web browser.

Where traditional containers force a given programming model, lightweight containers do not. They let you insert plain old Java objects (POJOs). The container can then wire the POJOs together and attach services to them. Common characteristics of lightweight containers include:

Classification: GE Internal

POJO-based programming -- Lightweight containers are not invasive. The containers do not enforce any API.

Life-cycle management -- Lightweight containers manage the life cycle of the objects you put into them. Minimally, they instantiate and destroy objects.

Dependency resolution -- Lightweight containers provide a common dependency-resolution strategy. Major containers today support a strategy called dependency injection. Some support a Java 2 Platform, Enterprise Edition (J2EE)-style strategy called service locators, as well.

Consistent configuration -- Lightweight containers are a convenient place to provide consistent configuration services.

Service attachment -- Lightweight containers provide a way to attach services to the objects in the container.

The advantages

Lightweight containers have many advantages over other container architectures. For example, you get to use a simpler programming model based on POJOs. Because you're programming with POJOs, your applications are easier to test. Your objects can also run outside the container -- for example, in a test case. Through dependency injection, lightweight containers reduce dependencies between components. They also protect your investment in code because you can move more of your application between containers.

Back to top

Core design patterns

A rapid wave of innovation fuels the lightweight container movement. Dependency management drove the movement in the beginning. Early lightweight containers, such as Apache's Avalon, used the service locator strategy to manage dependencies. All the major modern containers now manage dependencies with dependency injection.

However, resolving dependencies is only part of the problem. You also need to be able to attach services to the POJOs in the container. EJB containers handled this problem with code generation. Modern containers use aspect-oriented programming (AOP) and interceptors.

Dependency injection

In Java technology, dependency injection is rapidly changing the way we build applications. The concept is relatively simple: A consumer (like the Consumer class below) needs a service. You add a property to the consumer that points to the service (like the Speaker class below). Listing 1 shows an example of this concept.

Classification: GE Internal

Listing 1. Example of dependency injectionclass Speaker { void speak(String words) { System.out.println(words); }}

class Consumer { Speaker mySpeaker; void saySomething() { mySpeaker.speak("something"); }}

Notice the Consumer class. It doesn't instantiate the Speaker class. With dependency injection, that job goes to a third party -- call it the Container class (see Listing 2).

Listing 2. The Container classclass Container { public static void main(String[] args) { Speaker speaker=new Speaker(); Consumer consumer=new Consumer(); consumer.speaker = speaker; consumer.saySomething(); }}

The Container class instantiates the Speaker and Consumer classes. Then the Container class sets the speaker property to the new Speaker class. This last step represents the dependency injection.

Back to top

The power of interfaces

Let's refactor this code a bit. Build an interface called Speaker, then a couple of different implementations: a Canadian speaker and a Californian speaker. So, you now have the Speaker interface:

interface Speaker { void speak(String words);}

Classification: GE Internal

the CanadianSpeaker and CalifornianSpeaker:

class CanadianSpeaker implements Speaker { public void speak(String words) { System.out.println(words + ", ay?"); }}

class CalifornianSpeaker implements Speaker { public void speak(String words) { System.out.println("Like, " + words); }}

and the one-line change in the container:

... Speaker speaker=new CalifornianSpeaker();

Notice that you can now change between implementations of the speaker, and the only code that needs to change is the container. More to the point, you could easily inject a mock object instead of a real Speaker implementation, and you could do a test without affecting the rest of your code base.

Of course, your ultimate goal is to replace this handwritten container with one written for you. Take, for example, the Spring container. In this case, it replaces your Container class, and you can use a simple XML file that looks like the code in Listing 3.

Listing 3. XML file for the Spring container<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN""http://www.springframework.org/dtd/spring-beans.dtd">

<beans>

<bean id="mySpeaker" class="CanadianSpeaker"> </bean>

<bean id="consumer" class="Consumer"> <property name="speaker"><ref local= "mySpeaker"/></property> </bean>

</beans> </code>

Now you can load the context, get the Consumer bean, and run it like this:

Classification: GE Internal

ApplicationContext ac = new FileSystemXmlApplicationContext("context.xml");Consumer c=(HelloWorld)ac.getBean("consumer");c.saySomething();

The Spring container does the same thing yours did. It instantiated the beans and wired them together by setting the properties. Notice that the two pieces of code are completely decoupled; the interface and the container make sure that's true. You can use dependency injection to satisfy the many dependencies you run across when you're doing enterprise development, like data sources or transaction managers.

You can also see that the natural layers of an application naturally depend on each other. You might have a Web user interface (UI) view that's called by a controller, which calls a facade layer, which calls a data access object, which calls an object-relational mapper, which calls a database. These relationships are dependencies. If you can decouple them, you can more easily code, test, and maintain them.

Back to top

Interceptors

Dependency injection lets you weave together the main layers of your application, which, in turn, lets you produce a loosely coupled application with view, model, and controller layers. But lightweight containers solve another problem. You often have concerns -- such as logging, remoting, or security -- that hit many parts of your application. EJB technology solved this problem with code generation and a container/component interface. We can do better.

You can code your crosscutting concern in one place, then use a technique called the interceptor to tie that code to methods that might need it. Say, for example, a caller wants to invoke a method called speak(). Using the interceptor strategy (see Figure 1), you create a proxy in front of the target object with the speak() method. The proxy should have a speak() method with the same interface that the original target object has. When the caller invokes the proxy, you're free to add any custom features you may require before invoking the real method.

Figure 1. Staple interceptor strategy for lightweight containers

Classification: GE Internal

Using interceptors, you can effectively add custom services like security, declarative transactions, and remoting to methods on your POJOs. Here's the kicker: Neither the calling code nor the invoked method needs to change at all. Further, containers like Spring come with prepackaged interceptors to perform these tasks and more.

Back to top

Aspect-oriented programming

AOP takes things one step further. With AOP, you can quickly specify all the methods that require a given service at once, often using regular expressions. AOP programmers call this collection of methods a point cut. For example, you may want to attach declarative transactions to all the methods in a facade. For methods starting with insert or update, you may want full transaction propagation; but for other methods, you may want lightweight read-only propagation. (The EJB specification defines types of transaction propagation. You just need to know that full propagation is more expensive than read-only propagation, but it's also safer and necessary for certain types of updates.)

You get the right transactional behavior, in the right place, without modifying any code in the caller, or the target method. Listing 4 shows part of a Spring context that specifies the point cuts for such an application.

Listing 4. Code to specify point cuts in a Spring container <property name="transactionAttributes"> <props> <prop key="insert*">PROPAGATION_REQUIRED</prop> <prop key="update*">PROPAGATION_REQUIRED</prop> <prop key="*">PROPAGATION_REQUIRED,readOnly</prop> </props> </property>

Back to top

The players

You can well imagine that many people would try to build lightweight containers. The lightweight container space is rapidly consolidating around a few players: Spring, Pico, HiveMind, and EJB technology.

Spring

Classification: GE Internal

Leading the charge is the Spring Framework. Spring uses XML configuration and relies on setters for dependency injection. It can also use constructors or factory methods, but most examples you'll see -- and the Spring code base itself -- focus on setters.

Spring goes beyond its lightweight container by adding a whole host of beans with glue code. With the beans and code, you can drop in hundreds of different kinds of components that let you use J2EE APIs, persistence engines from JDO to Hibernate, workflow engines, view technologies, and dozens of other things. Spring is rapidly maturing and has the critical mass to be a player for the foreseeable future.

Pico

The Pico container is the smallest available. The primary differences between Pico and Spring relate to style. Pico programmers rely first on constructors to do injection. Instead of XML, Pico uses Java code to register beans in the container. Like Spring, Pico also supports setter injection, but the emphasis is strongly on constructors. Pico doesn't have nearly the amount of support that Spring has. It's primarily a dependency injection container. However, Pico is an excellent choice when you don't need all the enterprise services Spring provides.

HiveMind

HiveMind is the newest of the open source lightweight containers. HiveMind has more supporting modules than Pico does, but not nearly as many as Spring has. HiveMind does, however, let you use Spring beans and services. It can manage dependencies with both setters and constructors. HiveMind's primary contributions are two important ideas:

A packaging concept called modules, loosely based on the Eclipse plug-in model, lets you manage dependencies at a coarse-grained level.

A documentation facility called HiveDoc lets you generate reference documentation for the modules in the container, much like Javadoc lets you generate documentation for your Java code.

It's too early to tell whether HiveMind will have a major impact.

EJB technology

Think about the things you do with EJB technology today, such as declarative transactions, remoting, and security. If you could do most of what you do in EJB environments with a lightweight container instead, why wouldn't you? That question is compelling enough to force a massive redesign of the core EJB architecture, and the EJB V3.0 expert group decided to do exactly that. EJB V3.0 will effectively implement a lightweight container strategy. The primary differences between the current EJB architecture and the new V3.0 architecture: The container will provide the primary services you use and you'll be able to use XML to configure the container, but EJB technology will also rely heavily on annotations for configuration.

Classification: GE Internal

Some good consultants have expressed concern about what they call overuse of annotations in EJB technology. I also have my reservations, but EJB technology has bigger problems. The EJB group must deliver something soon, or the lightweight containers may render EJB technology irrelevant. Customers can already do most of what they need to do with Spring. By the time EJB technology is used in volume, it may be too late.

Back to top

Wrapping up

So, now you've seen an overview of lightweight containers. You know the basic design philosophies:

Build a container that accepts POJOs, rather than restricted components Use dependency injection to loosen and resolve dependencies Use interception and AOP to attach services to POJOs

In the next couple of articles, I'll take a more exhaustive look at the major lightweight containers and indicate where you might use each. Then I'll take a fuller look at Spring, the most popular container. I told you at the beginning of this article that I needed to lighten up my bike without sacrificing my suspension. Now you know how to lighten up your container without sacrificing enterprise services.

Happy trails!

In 2003, three mountain bikers and I screamed down the ledge-filled trail called Forrest Ridge. It had just reopened, without fanfare, so most of Austin, Texas, didn't know. Throughout that autumn, we had been running this gem alone. On this day, we had to dodge more than 20 other bikers on a short stretch of trail. The secret was out.

Although the public discovery of our wonderful trail wasn't a good thing for my friends and me, it is a good thing when your open source trail gets discovered. You can find resources more easily, get fixes more quickly, and in general take advantage of the additional community. Now, Spring has now been discovered. It's among the most important open source projects, and it's well on its way to achieving Hibernate-like success as a major player both in and out of enterprise environments. This article shows you why Spring is so significant to lightweight development.

What is Spring?

If you're an enterprise developer, Spring can make your life easier. But what is it? With a framework this comprehensive, that's not an easy question to answer. Basically, Spring is a lightweight container. With Spring, you can program with plain old Java™ objects

Classification: GE Internal

(POJOs), resolve dependencies between them with dependency injection, and attach services to them with aspect-oriented programming (AOP).

Spring also provides some glue code that makes it easier to use Java 2 Platform, Enterprise Edition (J2EE) services, such as Java Transaction API (JTA), for transactions, Remote Method Invocation (RMI) for remoting, Java Management Extensions (JMX) for management, or Java Data Objects (JDO) for persistence. Spring also provides glue code for open source frameworks, such as Hibernate, Tapestry, Struts, and JavaServer Faces (JSF). Notice that some of the frameworks compete, and that's OK: Spring doesn't try to pick a winner.

Some services are available with Spring. For example, Web Flow makes handling the flow between Web pages easier. Similarly, Web MVC provides a Model-View-Controller (MVC) architecture for Web-based applications that is similar to Struts.

So, Spring casts a broad shadow. Like Enterprise JavaBean (EJB) technology, Spring's container lets you consume enterprise services. Unlike EJB 1.x and 2.x, however, you put JavaBeans -- not some proprietary component -- into the container. In another separation from EJB, Spring doesn't lock you into just a few standardized services. Instead, it lets you choose from hundreds of services, or even build your own.

To me, Spring is the most important open source project in the Java community. It's helping redefine J2EE. Partially as a result of the pressure from innovations in Spring, the EJB 3 expert group built a specification describing an interface more like Spring's than EJB 2.x. I can easily imagine a scenario in which Spring becomes as ubiquitous as Struts for enterprise development. To help you understand why Spring is so important, let's peel back the layers.

Back to top

The core container

First, look at how Spring works. I won't post full examples because you can find dozens of Spring tutorials. Instead, I point you to the sample application for my latest book and post snippets of that example to show what Spring can do for you.

The application simply maintains a list of bikes for an operation called RentaBike. Spring serves as the backbone for the application. Spring's main container, the context, holds references to all the main layers of the application and services. The main layers of the application are a database, a persistence framework, a database access object, and user interface (UI) controller and view layers.

The Spring context for the application is simply a list of beans the application uses. The beans don't have to rely on any Spring interfaces, but sometimes, I choose to rely on

Classification: GE Internal

Spring to provide some of the repetitive glue code that holds the application together. In the context, you'll find at least five types of metadata:

Configuration -- Because the container already has to do some configuration to handle dependency injection (covered in Secrets of lightweight development success, Part 2: How to lighten up your containers), it makes sense to handle other configuration here, too, so that you have a convenient, consistent strategy.

Major layers of the application -- In the RentaBike application, I expose a Data Access Object (DAO) layer, a controller layer, and a view layer (see Listing 1). I choose to wrap the DAO in an interface, so I can switch my data access layer to use different persistence strategies.

External dependencies -- For instance, my DAO needs a data source. Spring injects the resources my DAO needs, such as data sources, and platform-specific configuration, such as Hibernate's session factory.

Transparent services -- One of the biggest benefits of EJB technology was declarative transactions. You had to pay a lot to get them because you were forced to use an EJB interface and heavyweight EJB containers. Spring lets you configure only the services you need and apply them to POJOs. In Spring, you can make any method transactional.

Data -- Often, message data, information about application flow, and test data might also be placed in the application context.

Listing 1. A partial context for RentaBike<beans> <bean id="rentaBike" class="com.springbook.JDBCRentABike"> <property name="storeName"> <value>Bruce's Bikes</value> </property> <property name="dataSource"> <ref bean="dataSource" /> </property> </bean>

<bean id="bikesController" class="com.springbook.BikesController"> <property name="facade"> <ref bean="rentaBike" /> </property>

</bean> <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName"> <value>com.mysql.jdbc.Driver</value> </property>

Classification: GE Internal

<property name="url"> <value>jdbc:mysql://localhost/bikestore</value> </property> <property name="username"> <value>bikestore</value> </property> </bean> </beans>

If you look closely at a context, you'll notice that it's made up of beans. That's important because earlier J2EE containers forced you to use a given API, especially EJB. Each bean has a set of properties. Some are strings and other primitive values. Some are beans, like the data source required by the rentaBikebean. You don't have to implement an API, like the interface for EJB session beans. You just list beans and their properties. Some of the properties satisfy dependencies. You've got better transparency, so you can run your beans outside the container or move your application to other containers, should the need arise.

Contexts for testing

You may wind up putting other types of beans in the context, too. For example, it often makes sense to use the context to populate simple test data, or application flow, in the context. In Spring: A Developer's Notebook, we drive the first implementations of our UI with a stub that uses an array list instead of a database. Say I've got a database table with names and e-mail addresses. I can build a simple stub that has an array list as a property, then implement some simple data access methods quickly, as Listing 2 shows.

Listing 2. A testing stub to replace a databasepublic class StubEmailDirectory { private List people; public List getPeople() { return people; } public void setPeople(List people) { this.people = people; } public String findEmail(String name) { Person p = findPerson(name); if (p==null) { return null; } return p.getEmail(); }.public Person findPerson(String name) { if (people==null) { return null;

Classification: GE Internal

} int size = people.size(); for(int i=0;i<size;i++) { Person p=(Person)people.get(i); if(p.getName().equals(name)) { return p; } } return null; }}

I can then populate it from the context, as Listing 3 shows.

Listing 3. Test data in a context<beans> <bean id="bruce" class="j2life.bus.Person"> <property name="name"> <value>Bruce</value> </property> <property name="email"> <value>bruce.t@j2life.com </value> </property> </bean> <bean id="maggie" class="j2life.bus.Person"> <property name="name"> <value>Maggie</value> </property> <property name="email"> <value>maggie.t@j2life.com </value> </property> </bean> <bean id="emails" class="j2life.bus.StubEmailDirectory"> <property name="people"> <list> <ref bean="bruce"/> <ref bean="maggie"/> </list> </property> </bean></beans>

When you think about it, drawing test data from a context often makes sense. To make test cases repeatable and verifiable, you can draw unpredictable data, such as system times and random numbers, from a context instead of from the services. Spring's context

Classification: GE Internal

makes testing much easier because you can configure applications in different ways for production and testing.

The foundation of Spring is the container, and it's important. But the container doesn't even come close to telling the whole story.

Back to top

Leverage

Like me, world-champion cyclist Lance Armstrong is from Austin, Texas. I've enjoyed watching him bike through the years, in part because he gets more leverage out of each turn of the pedals than anyone else in the world. I look for opportunities for additional leverage with everything I do. Spring gives me better leverage by providing glue code that takes away the cumbersome repetitive resource management, configuration, and grunt work similar across my applications.

Take persistence. Hibernate is a beautiful persistence alternative. But like all persistence frameworks, it forces you to manage some low-level details I'd prefer to do without. Listing 4 shows an example of a Hibernate application without Spring.

Listing 4. Hibernate without Spring// Configuration codeConfiguration config = new Configuration( );config.addClass(Bike.class).addClass(Customer.class).addClass(Reservation.class);SessionFactory mySessionFactory = Configuration.buildSessionFactory( );

public List getBikesOldWay( ) throws Exception { List bikes = null; Session s = null; try { s = mySessionFactory.openSession( ); bikes = s.find("from Bike"); }catch (Exception ex) { //handle exception gracefully }finally { s.close( ); } return bikes;}

Listing 5 shows a similar example, but with Spring.

Classification: GE Internal

Listing 5. Hibernate with Springpublic List getBikes( ) { return getHibernateTemplate( ).find("from Bike");}

Look at the Hibernate template as the methods that implement things you'd want to do to a session. Notice especially what you don't see. You don't have to worry about transactions because Spring lets you configure them declaratively. You don't have to worry about managing resources because that code is in the template. Spring always closes the session, so you don't have to. You don't have to handle exceptions at this level because Spring translates them to a common set of unchecked exceptions. I like unchecked exceptions because I can choose to expose them at the appropriate level of the architecture. You provide only the bare minimum needed to tell Hibernate what to do. Spring handles the rest. That's leverage.

Spring provides leverage in other ways, too. By providing the same kind of glue code for other services, Spring eases my burden as an application programmer. I don't have to repeat myself nearly as often. I can use remoting, transactions, security, persistence, and MVC code much more easily because Spring does the heavy lifting.

I'd like to point out that there is a down side here. When I decide to use Spring's glue code instead of my own, I do build a dependency on the Spring framework. Most of the time, I'm willing to pay that price.

Back to top

AOP

In Part 2 in this series, you learned that AOP can let you attach services to a POJO, giving you much better transparency. With AOP, you can strip many cross-cutting concerns right out of your code. So, why wouldn't you just download an AOP framework and use it directly?

In reality, some teams do. It's been my experience that technologies are ready far before we have the wisdom to use them. When I see AOP in the hands of intermediate and novice programmers, I imagine kids with power tools. Face it: When it comes to AOP, most of us are still kids. As it was with object-oriented programming, we've got to spend a little time accumulating the wisdom it takes to use AOP effectively.

Spring gives me the ability to use AOP with training wheels. I can take some prepackaged aspects and look at examples that show well-defined scenarios, thereby getting much of the benefit of AOP without all the risk. In fact, you've often seen similar strategies in the past. The Ada programming language allowed encapsulation, but only

Classification: GE Internal

limited inheritance. Early windowing environments like the Microsoft® Windows® programming model internally had Window objects, events that looked like Smalltalk messages, and even hierarchies, but exposed a procedural programming model. I believe the same strategy is important for AOP.

Back to top

Spring's significance

For those who use it, Spring is revolutionary. These simple ideas lead to huge consequences:

Spring effectively opens up the enterprise services container. You no longer have to be a slave to the API or services a container provides. You can use the Spring context to manage prepackaged services, snap in third-party services, or write your own.

Spring represents a huge step forward in testability. With Spring, you can use dependency injection to work mock objects into hard-to-reach places, run objects outside the container (because they are POJOs), and even use the container to serve unpredictable data.

Spring's glue code makes it much easier to plug in enterprise services with very little programming. You write less code, so you have to read less code for maintenance or extension.

Spring represents an open source project that's redefining the way in which Java's commercial groups build their software. The influence of Spring on the latest EJB specification is undeniable, and it's important.

Spring has become one of the pillars of enterprise lightweight development. The resources below can show you how to get started or dig deeper into Spring. In the next article in this series, I'll introduce you to a few persistence alternatives for lightweight development.

May your favorite open source trail be discovered, too.

In a trip through Colorado in 2002, I caught the Arkansas River at a perfect level. The river showcased stunning diversity across three different runs. The laid-back Brown's Canyon run had wide open rapids with huge, fun wave trains. The characteristic cliffs of the Royal Gorge channeled the power of the river beneath a massive vertical canyon, in which little mistakes in the straightforward lines were punished with long swims. The Numbers had nice drops requiring precise maneuvering among restricted boulder gardens. In one river, I had three vastly different experiences.

Classification: GE Internal

In my last article, "Secrets of lightweight development success, Part 3: The emergence of Spring," you learned the basics of lightweight containers. In this article, I walk you through the three most popular containers:

Spring Framework has a full-featured container, an aspect-oriented programming (AOP) model, and integration code for just about anything you need for enterprise development.

HiveMind , from the creator of Jakarta Tapestry, lets you perform dependency injection for beans or larger components, called modules.

PicoContainer is the smallest of the lightweight containers and uniquely supports a Java™ technology-style configuration, rather than an XML configuration.

All these containers flow from dependency injection, but each has a vastly different character. As I walk through a high-level description of each, you'll see each framework in action, as well as where you can apply each framework.

Core philosophies

All of these containers accept plain old Java objects (POJOs), all have hooks for object life cycles (so they can call your code when they create or destroy a bean), and they all perform dependency injection. You might think these central themes would lead to similar containers, but that's not at all the case. While the code that goes into each container may be similar, the containers themselves reflect different capabilities, styles, and overall philosophies. All in all, the authors of each container stay true to their philosophies.

Spring Framework

The Geneva of open source frameworks, Spring Framework provides a lightweight container and glue code for hundreds of Java 2 Platform, Enterprise Edition (J2EE) APIs and open source frameworks. Spring has one overriding vision: to make J2EE easier to use. After reading through some examples and books, you'll see some common themes:

Spring supports three types of dependency injection -- setter, constructor, and method injection -- but overall, the prevailing model is setter injection.

Spring's XML-style configuration values flexibility over simplicity. You can do just about anything, but the configuration files are hard to read and difficult for novices to understand.

Spring's founders believe that the container is a only small part of the overall framework. Most of Spring's value comes from the thousands of lines of glue code supporting the framework. It's easy to plug in just about anything.

The Spring framework is the most complete and well polished of the three container implementations. In particular, the excellent documentation is complete and well written.

Classification: GE Internal

Spring has an autowire mode, but most examples fail to use it. I don't quite understand this decision, but at times, it's nice to see dependencies explicitly listed.

Spring provides a full AOP framework to make it easier to attach services. You can use Spring's own framework or rely on the rich AspectJ integration (see Resources).

If I were to characterize Spring with a phrase, I'd say, hardened for the enterprise.

HiveMind

Howard Lewis Ship, the creator of the Jakarta Tapestry Web framework, also created HiveMind. As a container, HiveMind is clever, clean, and a joy to use. Like many of the other, better, open source frameworks, Ship created HiveMind to help him solve real problems. However, HiveMind adds a couple of new wrinkles to traditional lightweight containers:

The most important HiveMind innovation is the module. According to Ship, the Eclipse plug-in inspired the HiveMind module.

HiveMind forces you to program to interfaces. (Like all lightweight containers, it doesn't impose an interface; you provide your own.)

HiveMind is user-friendly, providing items like a documentation tool called HiveDoc, a friendly and concise XML configuration, and line-precise error reporting.

HiveMind users typically prefer setter injection, but the container also supports constructor injection.

If I were to characterize HiveMind with one phrase, I'd say it's conceptually sound.

PicoContainer

By far, the biggest overriding characteristic of PicoContainer is its size. It won't give you a lot of extras, but it has a complete dependency injection container. PicoContainer also has some unique properties:

PicoContainer is small, so it doesn't have interceptors, AOP, or similar types of services, preferring instead to let other frameworks create them.

PicoContainer supports Java technology for configuration, rather than XML, like the other containers.

PicoContainer's prevailing usage model is constructor injection, although it also supports setter injection.

PicoContainer doesn't give you much documentation, and some of the existing documentation is incomplete, although you don't need much.

PicoContainer has one autowire mode, and it's nice. PicoContainer's development seems to have stagnated somewhat.

Classification: GE Internal

If I were to characterize PicoContainer with a phrase, I'd pick theoretically pure, but not as practical as Spring or HiveMind.

Back to top

Programming model

Now I'll point you to programming examples prevalent in the community to help you better understand how the authors of the containers would like you to use them. I use the Kiss example from PicoContainer to showcase autowiring and Java technology-style configuration, the HiveMind adder example to showcase the module capability, and the Spring PetClinic application to showcase Hibernate integration.

The Kiss example (PicoContainer)

Of the three containers, PicoContainer has the simplest programming model. To see the Kiss example, download it from PicoContainer.org. Install the example, browse to docs\Two+minute+tutorial.htm, and you should see two components:

Listing 1. Two Kiss components

public class Boy { public void kiss(Object kisser) { System.out.println("I was kissed by " + kisser); }}public class Girl { Boy boy;

public Girl(Boy boy) { this.boy = boy; }

public void kissSomeone() { boy.kiss(this); }}

These two classes are self-explanatory. Girl has a dependency on Boy. The dependency will be injected through the constructor. You instantiate a container:

MutablePicoContainer pico = new DefaultPicoContainer();

Then you register the two components:

Classification: GE Internal

pico.registerComponentImplementation(Boy.class);pico.registerComponentImplementation(Girl.class);

Later, you can ask PicoContainer for an object, then exercise it:

Girl girl = (Girl) pico.getComponentInstance(Girl.class);girl.kissSomeone();

That's pretty much it. The programming model is elegant, and the constructor-based style means you don't have to include a constructor without arguments. Calling such an instructor on the Girl in this example would leave the object in an inconsistent state because the kiss method would throw an exception.

The adder example (HiveMind)

Now, let's take a look at HiveMind's programming example. Download HiveMind from The Apache Jakarta Project, then look at the adder example. You should see an interface and an implementation. (Remember: HiveMind enforces interfaces.)

Listing 2. Adder example interface and implementation

public interface Adder{ public double add(double arg0, double arg1);}

public class AdderImpl implements Adder{ public double add(double arg0, double arg1) { return arg0 + arg1; }}

You expose the service in an XML file, like this:

Listing 3. Expose the service in an XML file

<module id="examples" version="1.0.0">

<service-point id="Adder" interface="org.apache.hivemind.examples.Adder">

<create-instance class="org.apache.hivemind.examples.impl.AdderImpl"/>

Classification: GE Internal

</service-point></module>

Other applications could then use the service, like this:

Listing 4. Other applications can use the service

Registry registry = RegistryBuilder.constructDefaultRegistry(); Adder adder = (Adder) registry.getService("examples.Adder", Adder.class);

... adder.add(arg0, arg1)

Notice that HiveMind's module lets you group together multiple services. If you needed to add functionality to services in the container, you could use an interceptor:

Listing 5. Use an interceptor to add functionality

<module id="examples" version="1.0.0"> <service-point id="Adder" interface="org.apache.hivemind.examples.Adder">

<create-instance class="org.apache.hivemind.examples.impl.AdderImpl"/>

<interceptor service-id="hivemind.LoggingInterceptor"/> </service-point></module>

The PetClinic application (Spring)

Spring approaches things just a little differently. Because the Spring framework doesn't come with a simple application, I'm choosing one from my book, Spring: A Developer's Notebook. You can get the sample code from O'Reilly Media. Crack open example 4, which shows a CommandLineView object with a property for a RentaBike store, which eventually becomes the data access object for this application.

Listing 6. CommandLineView object

public class CommandLineView { private RentABike rentaBike; public CommandLineView() {} public void setRentABike(RentABike rentaBike) {this.rentaBike = rentaBike;}

Classification: GE Internal

public RentABike getRentaBike() { return this.rentaBike; }...}

RentaBike is an interface with the types of methods you'd expect to see on a bike store object:

Listing 7. Interface methods

public interface RentABike { List getBikes(); Bike getBike(String serialNo); void setStoreName(String name); String getStoreName();}

Not shown is ArrayListBikeStore, which is a stub implementation of the BikeStore interface. Note that Spring allows interfaces, but doesn't enforce them. Here's the XML configuration file, describing the beans in the application:

Listing 8. XML configuration file describing application beans

<beans> <bean id="rentaBike" class="com.springbook.ArrayListRentABike"> <property name="storeName"><value>Bruce's Bikes</value></property> </bean> <bean id="commandLineView" class="com.springbook.CommandLineView"> <property name="rentaBike"> <ref bean="rentaBike" /> </property> </bean></beans>

This context has two beans in it. The commandLineView bean depends on the rentaBike bean. This application resolves the dependency explicitly by specifying the rentaBike name for the rentaBike property. Note that PicoContainer automatically wires obvious relationships like these, and Spring can, too, but most users don't use the autowire option. Spring can also let you add services to any method of the façade through interceptors or AOP.

Back to top

Classification: GE Internal

Comparisons

Now that you have seen the overall philosophies for each container, here's a more detailed comparison of the intangibles of each environment, such as market share, fit and finish, and the overall feature list. After all, even if the programming model is perfect, it's not going to be a good container with no documentation or you have to support it yourself because of a lack of community.

Active community

Spring has a vibrant community, as well as a professional services company called Interface21 that supports the framework. That's important because you know you can get excellent support, and the company is motivated to support the Spring framework. My experience with the community has been nothing short of sensational. Spring contributors, authors, and users alike pack the message board with outstanding content.

The HiveMind framework is an Apache Jakarta project, so it's on firm footing. It has a budding community growing in activity. The framework's founder, Howard Lewis Ship, is an independent consultant, an excellent instructor, and a tireless promoter. However, it's still much more difficult to hire quality help for HiveMind or find content beyond a few articles and what's on the Web site. Still, the online support seems good, and the community seems to be growing. Hibernate scored an interesting victory when it was chosen -- or, more likely, Ship was chosen -- to form the foundation of the new infrastructure for TheServerSide.com, one of the most important online Java technology communities.

PicoContainer, also an Apache Jakarta project, seems to be winding down. As of this writing, the last major code drop for PicoContainer was in November 2004. You don't see many new articles about PicoContainer, which is a shame because I like some of PicoContainer's philosophies. In fact, I'm not sure that there's room for three open source lightweight containers, especially since a fourth lightweight container project called Avalon recently shut down.

As far as the activity generated in each community, Spring is far and away the winner. The support of Interface21, fantastic forums, active mailing lists, and the track record of the community are unrivaled.

Fit and finish

The size and strength of a community often drives fit and finish within open source projects. Vibrant communities demand better documentation and examples, and they lend more hands to do the finishing details.

The Spring team writes documentation that rivals some of the better commercial products I've seen. If that's not enough, you can find at least five major Spring books and many other publications with some Spring content. (I've written two books with some Spring

Classification: GE Internal

myself, including one chapter of the Jolt-winning Better, Faster, Lighter Java and the quick start book called Spring: A Developer's Notebook.) The error messages are professional and descriptive. The integration with third-party frameworks and APIs is among the best of any Java technology framework. The packaging is thoughtful, if a bit on the excessive side. (It makes sense to me to begin breaking out some of the more minor projects as modules.) The examples are good and instructive.

Like Tapestry, HiveMind also has good fit and finish. Ship prides himself on the features that make HiveMind easy to use, like line-precise error reporting; a friendly, concise XML syntax; and an excellent documentation tool called HiveDoc. In combination with JavaDoc documentation for low-level details, you have the excellent capability to describe the high-level features of your application (HiveMind modules), complete with the dependencies between them.

The PicoContainer programming model feels natural, but the documentation is incomplete in places (with many to-do markers that look many months old), and there aren't many real-world examples of what you can do with the container. At times, I felt like I was walking alone through an abandoned haunted house.

You do get one major advantage with PicoContainer, though. Because you're configuring real-world objects, you get some compile time error checking. In reality, the container is so small and light that there's not much that can go wrong, other than basic configuration. PicoContainer does a reasonable job.

Features

I don't need to talk about features much. Spring wins hands down if you're looking for a lot of glue code to ease the integration of your open source favorites or that certain J2EE API. HiveMind doesn't try to compete. Instead, it's compatible with Spring's services. PicoContainer doesn't build the extras and doesn't try, preferring to let open source projects provide the services for them. So far, it's not working very well.

Back to top

Which one is best?

Right now, there's only one real solution. HiveMind has interesting innovations, and PicoContainer has an easy-to-use model (in theory), but the community seems to have voted on Spring Framework. Over time, a new container may develop, or HiveMind could continue to garner market share, but right now, Spring's your best bet.

If you're willing to take on some risk and use a container with less popularity or maturity, you may decide to implement HiveMind (if you need the module-level configuration) or PicoContainer (if you want a tiny container). If you need a lot of glue code to integrate

Classification: GE Internal

aspects such as persistence engines, transaction strategies, and security, Spring has the most complete component stack. Remember, though: You can use Spring components in the HiveMind container.

Classification: GE Internal