DZone and Manning Publications have partnered to bring you an exclusive chapter from 'Mule in Action' (by Dave Dossot and John D'Emic). This chapter covers the major transports the Mule Enterprise Service Bus (ESB) supports and provides working configurations of them in action. It covers specific transports, such as SOAP or email, and examines how you can use them to send and receive data.
Sending and Receiving Messages with Mule ESB
Can you remember the last trip you took? You probably used more than one means of transportation to get to where you were going. You may have taken a passenger jet somewhere first, then hopped in a taxi. Or you may have ridden a bike somewhere, locked it up, and then walked across the street. Perhaps you parachuted out of a plane, then drove home. In any case, you likely weren’t teleported from one place to another.
Transporting data isn’t much different than transporting people. While it would be nice if systems could magically move data between themselves, this isn’t often the case. One system might only support SOAP, while your system may only supports REST. Perhaps you need to get data from an FTP site into a database. Or maybe you need to receive JMS messages and save their payloads to a file.
We introduced Clood, Inc., at the end of the last chapter. In this chapter, and throughout the rest of this book, we’ll be using Clood’s integration activities as a reference point for some of our discussions and examples. Being a modern, cloud-based service provider, Clood is forced to integrate with a variety of disparate systems and services as part of its daily business. Clood also makes extensive internal use of open source technologies and tools. Let’s start off by considering an integration scenario recently faced by Clood.
Clood, Inc., uses Nagios, a popular open source monitoring tool, to perform URL monitoring of its customers’ cloud-hosted applications. When a URL check fails, Nagios sends an email to the Clood call center where subsequent action is taken. You’ve been tasked to store these alerts in a database so management can run reports on the data—with the stipulation that you can’t modify the Nagios installation. Since the reports will only be run once a day, you decide your best approach is to periodically download messages from the mail server, perform some analysis on them, and save the results into a relational database. Without using Mule, you might consider the following strategy:
- Implement an IMAP client using the Java Mail API.
- Schedule the client to download the messages at some interval.
- Write code to parse the email message.
- Use JDBC to insert the data into the database.
approach will work, but an awful amount of effort is spent
“plumbing”—writing things such as IMAP clients, JDBC clients, and
schedulers. Wouldn’t it be nice to worry about the business problem at
hand—parsing the email data—and let Mule handle the details of moving
the data around?
We’ll see in this chapter how Mule reduces this plumbing work to a few lines of XML. We’ll cover the major transports Mule supports and provide working configurations of them in action. In each section, we’ll discuss a specific transport, such as SOAP or email, and examine how you can use it to send and receive data.
As moving data around is such an important part of using Mule, expect to make heavy use of the techniques in this chapter. After all, you’ll need to get data into and out of Mule before you can do anything useful with it!
The above introductory excerpt was taken from Mule in Action, published in July 2009. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.