Mule

Mule ESB 3 and HornetQ Final 2.2.2

Currently i spend most of my nights coding for my own personal project.While i am creating my own platform i have the need for and E.S.B.(i.e. Enterprise Service Bus). The need is clear if you consider creating an application/platform that will be able to connect with various protocols and will be able to digest a huge amounts  of information. So Enterprise Application Integration was the pattern to follow.Doing my digging i was facing the delema: Apache ServiceMix or Mule ESB. Both of them are open source ESB’s based on Java programming language and support several connectors and protocols. To be honest i must admit that Apache ServiceMix has more connectors that Mule ESB. This post won’t go into details about how to configure extensively both ESB’s but will provide a short how to on how to setup Mule ESB to work with HornetQ 2.2.2 , which is the JMS 1.1 implementation by  JBoss.

Why Mule ESB? Clearly i preferred the verbosity of the configuration mechanism over the Apache ServiceMix. Also the fact that the team support a plugin for Eclipse helps a lot the development cycle. Currently writing the new Mule Studio is out there grab it and ride the ESB world easily. Also the smooth integration with the Spring 3.0 framework was another factor for selecting Mule ESB,nevertheless  Apache ServiceMix also is a Spring based ESB. The fact that Spring is used extensively on both ESB makes them really popular in the Java/Integration world. Let’s move on now. Prerequisites for the small howto

  1. Mule ESB. Get it from here.
  2. HornetQ 2.2.2 Final. Get if from here.
  3. Eclipse with Mule Plugin or Mule Studio.
  4. Java 5 or Java 6 SDK.

Mule and HornetQ Configuration

Let’s now dive into the Mule things. Lets assume that you have successfully unzipped the Mule ESB in some directory in your linux machine.Let’s say /foo/bar/mule/. You should be already familiar with the fact that Mule deployments are zip files. Your project will be deployed in the mule app directory as a zip file. So after you have successfully installed the mule plugin for eclipse, fire up your IDE and go and create a new Mule Project.A mule project is an ordinary Java project with an extra mule-config.xml file inside the project.Once you have created the project generate a new mule-config.xml file and add all the necessary namespaces in the  xml file in order to use them with the editor for auto completion.

Go on now to the directory of your hornetq installation and from the lib directory copy the following jars in the lib/user directory inside your mule installation:

  1. hornetq-core-client.jar
  2. hornetq-jms-client.jar
  3. netty.jar
  4. jnp-client.jar
  5. hornetq-logging.jar
The you need to refresh your configuration of Mule plugin because it doesn’t see the new jars added. So go in the setup of Mule in the Preferences tab of your eclipse and reconfigure the Mule environment, by adding the newly inserted jars, or else you will have a pain in the neck to figure out why the jar’s aren’t there in the classpath when you want to run your project. After finishing with these administrative tasks add the following lines of xml in your mule-config.xml file in order to use a ConnectionFactory to connector to your Message Broker:
<!-- JMS Connector -->
<jms:connector name="hornetq-connector"  jndiInitialFactory="org.jnp.interfaces.NamingContextFactory"
               connectionFactoryJndiName="java:/ConnectionFactory" jndiProviderUrl="jnp://localhost:1199" jndiDestinations="true" specification="1.1" acknowledgementMode="AUTO_ACKNOWLEDGE" >
 </jms:connector>
The above configuration implies that we have enabled the JNDI lookup in the HornetQ Message broker and the JNDI is configured to accept connections for lookup of resources on port 1199. I prefere this configuration over injecting the connection factory through ta spring bean because i think is more clear to have configuration parameters to change in the client side and let all the other administration configuration to live on the side of the broker.Now fire up your hornetq message broker but before doing that download and install in your linux system the libaio library. Using a debian based distribution this can be done really easily by invoking the apt-get command from the command line or terminal. Once your server is up and running and has the JNDI configured to listen on port 1199(this can be configured if you enter in the conf directory of your message broker and go to the standalone configuration non clustered mode and edit the hornetq-configuration.xml file).Also in the same folder in the file hornetq-jms.xml you can define the queue you want to create and the name that it will be bind in the JNDI to lookup for.Once the above configuration is done fire up the run.sh in the bin directory of your hornetq installation.
Go back to your Eclipse IDE and on the mule-config.xml file add the following lines of xml:
<service name="jms">
 <inbound>
   <jms:inbound-endpoint connector-ref="hornetq-connector"  queue="queue/mHighInOne" />
 </inbound>
 <outbound>
   <pass-through-router>
	<file:outbound-endpoint path="OUT"/> 
   </pass-through-router>
  </outbound>
</service>
Java client to test:
package com.pack.mule.component.jms;

import java.util.Calendar;
import java.util.Properties;

import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author cirix
 *
 */
public class JMSQueueTest {
	private InitialContext ctx = null;
	private Session session = null;
	private Connection connection = null;
	/**
	 * @throws java.lang.Exception
	 */
	@Before
	public void setUp() throws Exception {
		Properties properties = new Properties();
		try{
			properties.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
			properties.setProperty("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
			properties.setProperty("java.naming.provider.url" , "jnp://localhost:1199");
			properties.setProperty(InitialContext.SECURITY_PRINCIPAL,"guest");
			properties.setProperty(InitialContext.SECURITY_CREDENTIALS, "guest");
			ctx = new InitialContext(properties);
		}catch(NamingException ne){
			ne.printStackTrace(System.err);
		}
	}

	@Test
	public void burnTestApplication(){
		try{
			ConnectionFactory cf = (ConnectionFactory)ctx.lookup("ConnectionFactory");
			Queue queueToSend = (Queue)ctx.lookup("queue/mHighInOne");
			this.connection = cf.createConnection();
			session = this.connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
			MessageProducer producer = session.createProducer(queueToSend);
			this.connection.start();
			for(int i = 0 ; i < 1000 ; i ++){
				TextMessage message = session.createTextMessage();
				message.setText("Message["+i+"] send to queue in :"+Calendar.getInstance().getTime());
				producer.send(message);
			}
		}catch(NamingException nnfe){
			nnfe.printStackTrace(System.err);
		}catch(JMSException jmse){
			jmse.printStackTrace(System.err);
		}catch(Exception e){
			e.printStackTrace(System.err);
		}
	}

	/**
	 * @throws java.lang.Exception
	 */
	@After
	public void tearDown() throws Exception {
		try{
			this.connection.close();
			this.session.close();
			this.ctx.close();
		}catch(Exception e){
			e.printStackTrace(System.err);
		}
	}

Now run the unitest and see that inside your home directory of the project a folder will be created where the load of the text message( a file containing a string) will have been created.

Why hornetq and mule? The answer is dead simple. Scalability and scalability made easy. The way hornetq implements persistence allows us to scale  in a clustered environment only by the limitations of the file system since there is no RDBMS that we have to persist the messages. In high transactional systems going back and forth in the database sometimes if not most of the times is killing the application.Given the fact that you can configure your production environment have a really great implementation of a journaling file system and then tune the hornetq accordingly then you have a powerful combination over E.A.I.

Point to take under consideration: A small problem with the Mule plugin in eclipse that can cause a lot of headaches, is the fact that if you add new jars in the lib/user directory the path isn’t updated even if you restart your favorite IDE. You have to go manually and remove and add again the environment and then add the new jars that will be available there.

Advertisements

One thought on “Mule ESB 3 and HornetQ Final 2.2.2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s