Tijs Rademakers

Subscribe to Tijs Rademakers: eMailAlertsEmail Alerts
Get Tijs Rademakers: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, Java Developer Magazine

J2EE Journal: Article

Using Spring as an Object Container

Enhancing ESB functionality

One of the most important things to know is the POJO-based programming model that Spring uses. In other words, your applications can be completely coded using just POJOs. When you're working with Spring, you don't need to worry about implementing specific interfaces or having to conform to a strict programming model (for instance, EJB2). You are able to create your business logic with basic Java classes.

This, however, doesn't mean that you can't work together with these models. Spring has a number of utilities, templates, and more that can be used together with your POJO to create advanced configurations and allow you to apply enterprise services (transaction, security, exposing for management, etc.) to your POJOs. All this, however, is done non-intrusively, without tying your business logic to a certain technology. For instance if you look at the Mule architecture, you see something similar. The Mule components, the place where we put our integration logic, are just simple POJOs without a dependency to Mule.

Inversion of Control and Dependency Injection
Spring implements the Inversion of Control (IoC) and Dependency Injection (DI) paradigms to provide the flexibility we just described. Since this book isn't about design patterns, we won't spend too much time on these concepts; we'll just give you a quick overview. Let's first look at IoC. The analogy people most often make when talking about IoC is called the Hollywood principle: "Don't call me, I'll call you." What this means is that you don't call the framework code, but the framework calls certain methods on your components. This isn't something new, for instance, when you look at the servlet interface, you can see that you must implement the init and destroy methods. These methods are called from the servlet container on startup and shutdown of your servlet. This concept is also used in Spring, among other things, for specifying which methods to call on construction and destruction of your POJO.

Besides IoC, another important concept to understand is Dependency Injection (DI). This term was coined by Martin Fowler and describes a pattern of how to perform wiring between beans. This means that any dependencies your POJO might have are injected into your component, instead of you having to retrieve them. In J2EE (at least until 1.5) when you required a resource (a data source, another bean, etc.) you had to use JNDI to pull that resource in. With DI you don't have to do that anymore. With DI your container will make sure you have the dependency pushed into your POJO using getters and setters. In the new J2EE specs much of the same concepts are used.

Enough theory, let's now look at how Spring is used as a component framework, and after that we'll show you how you can use Spring in combination with Mule and ServiceMix.

How Do You Use Spring
We'll show how you can use Spring to create a POJO-based application. The first thing we do is to show a couple of simple beans that we will use in this example. The first one, Listing 1, shows a simple service implementation.

The CustomerServiceImpl implementation is a good example of a service bean implementation that we typically use together with Spring. This service has two references, first to the CustomerDAO (#1), which we will discuss in Listing 2, and a second reference to a String property value (#2). In Listing 3 we will see how these references are injected into this class.

In Listing 2 you can see the CustomerDAO implementation that is used in the CustomerServiceImpl service bean.

This is not a real-life example of a Data Access Object (DAO); this is just used to show the functionality of Spring. The CustomerDAOImpl implementation defines a number of class attributes and a save method to persist a customer.

We will configure Spring in such a way that this second bean will be injected in the CustomerServiceImpl as is shown in Figure 1.

Figure 1: A schematic overview of a customer service bean and a customer Data Access Object (DAO) class implementation. The customer DAO class is injected into the customerDAO property of the customer service bean.

Now that we have implemented two Java classes, a service bean, and a DAO class, we can use Spring to inject the property values and a bean reference. To implement the dependency injection functionality we need to define a Spring configuration file. Listing 3 shows the implementation of this Spring configuration file.

In this example we configure two Spring beans: a customer bean (#1), which is the implementation of the CustomerServiceImpl class, and a customerDAO (#3), which points to the CustomerDAOImpl. The customer bean defines two properties. One property points to the customerDAO bean (#2) and the other one is a simple String property. These two properties will map to the setters we've defined in our implementations. The customerDAO property maps to the setCustomerDAO method and the anotherProperty property maps to the setAnotherProperty method.

When the customer bean is retrieved (we will show you how later), Spring will make sure that an instance of the customerDAO is injected and that the other properties (#4) are set as well. We as component developers don't need to worry about retrieving all kinds of dependencies using factories, singletons, etc.; we just configure how everything is tied together and let Spring inject the dependencies.

Using Spring with Mule and ServiceMix
If we need to make extensions to Mule or ServiceMix-like custom components, transformers, or anything else, we can easily create those using standard POJOs and then define and configure these components with Spring as we've seen in the previous samples.

Let's first look at how you can use Spring with Mule. As we've already mentioned, everything configured in Mule 2 is configured in Spring. Whenever you configure Mule you're actually already using Spring. Let's start by looking at Listing 4, which shows how you can create a Mule service that specifies a component directly by using a class name.

•   •   •

This article is based on the book Open Source ESBs in Action: Implementation Examples in Mule and ServiceMix scheduled to print September 30, 2008. This article is courtesy of Manning Publications. The ebook is available and sold exclusively through Manning Publications.

More Stories By Tijs Rademakers

Tijs Rademakers is a software architect with more than six years of experience in designing and developing Java and EE applications. He works for Atos Origin, a large European system integrator, where he is responsible for SOA and BPM services and knowledge development. He has designed and implemented large process- and application-integration solutions, primarily focused on open standards. Tijs is a regular speaker at Java conferences, where he talks about open source integration topics like Mule and ServiceMix.

More Stories By Jos Dirksen

Jos Dirksen has been working with Java and J2EE applications for more than six years as a software architect. The last couple of years, his focus topics have been open source, security, and quality. He has worked with various open source and commercial integration solutions, mostly in the government and the health care areas. Jos has a lot of project experience working with Mule, Apache Synapse, and Apache Axis2 and has also completed projects based on the integration tooling from IBM. Jos regularly gives presentations on open source, Mule, and other related topics.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.