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.