Using Spring as an Object Container

This service is already defined using Spring. You'll probably notice that this configuration looks very different from the beans we defined in the previous section. The reason for this is that with Spring 2 you can easily define your own custom XML configuration. We won't go into the details of this, but it's enough to know that even though it doesn't look like Spring, under the covers Spring is still used.

If we want to use our own Spring beans from this configuration, instead of using the <component> tag with a class attribute, we first need to make our Spring beans available to Mule. To do this, we simply add them to this file or import them from an external file, which is a nice way to keep your configuration files organized. To import them from an external configuration file we can use the following statement.

<import resource="components.xml"/>

This will import the Spring beans you've defined in that file into the context of Mule. Note that if we copied all the Spring bean definitions from that file to the Mule configuration, the result would be the same. You can now reference those beans directly from Mule by using the <spring-object> child element of the <component> element. This is shown in Listing 5.

Now that we've shown you how Spring is used and how it can be referenced from Mule, let's also quickly look at how to use Spring beans from ServiceMix

In ServiceMix you have a number of components to which you can deploy artifacts (in the form of Service Units). Those artifacts will then run inside the Service Engine or Binding Component. One of the JBI components to which you can deploy Service Units is the servicemix-bean Service Engine. This JBI component provides functionality to directly run POJOs using Spring inside ServiceMix, without having to create components following the complete JBI spec. This is a simple way to add custom integration functionality.

POJO Beans with ServiceMix BeanAlthough the container is called a bean container and we talked about POJOs here, we do have to implement a specific interface for the bean implement to work with the servicemix-bean Service Engine. In JBI we work with message exchanges. A JBI component doesn't just receive the message content, it receives additional information about the message exchange. If we want to create a simple component using Spring, we have to tell the JBI container how our JBI component can receive these message exchanges. We have two options for this. We can either annotate a specific method with the @operation annotation, or we have to implement the MessageExchangeListener interface. In the latter chapters we will show you how to do this.

Besides the bean component, there is another way of using POJOs in ServiceMix. In chapter 6 we'll show you how you can use the JSR 181 service engine to expose POJOs in ServiceMix to be consumed by other services. However, with the servicemix-bean Service Engine, you have easy access to the JBI context, which in the JSR 181 service engine is more difficult. Summarizing, it's easier to use the JSR 181 service engine when you already have functionality that doesn't need to know anything about JBI, and it's easier to use the servicemix-bean component when you require access to the JBI environment.

To use the servicemix-bean Service Engine, you need to configure a specific ServiceMix configuration, the xbean.xml. This configuration is shown in Listing 6.

The one thing to notice here is the bean attribute (#1). The bean attribute points to the #listenerbean Spring bean. Notice that the bean endpoint that we defined here also defines service and endpoint names. The combination of the service and endpoint names uniquely identifies this bean in the JBI container.

We can also define the Spring bean in an external file to keep the servicemix-bean and the Spring bean configuration separated. To use this external file we have to import it, just like we did for Mule. You can do this by adding the following to the XML configuration of Listing 6.

<import resource="components.xml"/>

This will import the beans you've defined into the context of ServiceMix. The components.xml file can be implemented with the following code snippet:

That's all there is to it. We've shown how Spring can be used together with Mule and ServiceMix. As you can see, both Mule and ServiceMix make working with Spring very easy, since both already use a Spring-based configuration.

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.

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.

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.

Cloud Expo

Cloud Computing & All That
It Touches In One Location Cloud Computing - Big Data - Internet of Things
SDDC - WebRTC - DevOps
Cloud computing is become a norm within enterprise IT.

The competition among public cloud providers is red hot, private cloud continues to grab increasing shares of IT budgets, and hybrid cloud strategies are beginning to conquer the enterprise IT world.

Big Data is driving dramatic leaps in resource requirements and capabilities, and now the Internet of Things promises an exponential leap in the size of the Internet and Worldwide Web.

The world of SDX now encompasses Software-Defined Data Centers (SDDCs) as the technology world prepares for the Zettabyte Age.

Add the key topics of WebRTC and DevOps into the mix, and you have three days of pure cloud computing that you simply cannot miss.

Delegates will leave Cloud Expo with dramatically increased understanding the entire scope of the entire cloud computing spectrum from storage to security.

Cloud Expo - the world's most established event - offers a vast selection of 130+ technical and strategic Industry Keynotes, General Sessions, Breakout Sessions, and signature Power Panels. The exhibition floor features 100+ exhibitors offering specific solutions and comprehensive strategies. The floor also features two Demo Theaters that give delegates the opportunity to get even closer to the technology they want to see and the people who offer it.

Attend Cloud Expo. Craft your own custom experience. Learn the latest from the world's best technologists. Find the vendors you want and put them to the test.