...

TODOs

• Embellish the turorial tutorial with more detail, explaining at each stage what is happening.
• Link to specific sections of Camel documentation when referring to components.
• Attach completed example project.
• Explain in more detail what is happening when the JMS component is being defined in camel-server.xml
• Show how logging can be introduced to monitor exchange body contents.
• Detail how time-outs can be configured.
• Show how to catch lost messages.
• Show how to use a wiretap.
• Can we make this ActiveMQ embedded so that it does not require the reader to download and start it manually?

...

We will initially create a client by directly using CamelTemplate. We will later create a client which uses Spring remoting to hide the fact that messaging is being used.

...

The client will not use the Camel Maven Plugin so the Spring XML has been placed in src/main/resources so not to conflict with the server configs.

public class CamelClient {

  public static void main(final String[] args) {

    ApplicationContext context = new ClassPathXmlApplicationContext("camel-client.xml");
    CamelTemplate<JmsExchange> camelTemplate = (CamelTemplate) context.getBean("camelTemplate");

    int response = (Integer)camelTemplate.sendBody("jms:queue:numbers",
      ExchangePattern.InOut,
      22
    );

    Assert.assertEquals(66, response);
    System.out.println(response);

  }
}

The CamelTemplate is retrieved from a Spring ApplicationContext and used to manually place a message on the "numbers" JMS queue. The exchange pattern (ExchangePattern.InOut) states that the call should be synchronous, and that we will recieve receive a response. We then assert that the response is three times the value of the original.

Before running the client be sure that both the ActiveMQ broker and the CamelServer are running.

Using Spring Remoting

...

First we create a new Spring config file. This has a few changes made from camel-client.xml. Firstly the Camel template has been removed, as it will not be used. Secondly a proxy is defined. This will create a proxy service bean for you to use to make the remote invokationsinvocations. The serviceInterface property details which Java interface is to be implemented by the proxy. serviceUrl defines where messages sent to this proxy bean will be directed. Here we define the JMS endpoint with the "numbers" queue we used when working with Camel template directly. The value of the id property is the name that will be the given to the bean when it is exposed through the Spring ApplicationContext. We will use this name to retrieve the service in our client. I have named the bean multiplierProxy simply to highlight that it is not the same multiplier bean as is being used by CamelServer. They are in completly completely independent contexts and have no knowledge of each other. As you are trying to mask the fact that remoting is being used in a real application you would generally not include proxy in the name.

public class CamelClientRemoting {

  public static void main(final String[] args) {

    ApplicationContext context = new ClassPathXmlApplicationContext("camel-client-remoting.xml");
    Multiplier multiplier = (Multiplier) context.getBean("multiplierProxy");

    int response = multiplier.multiply(22);

    Assert.assertEquals(66, response);
    System.out.println(response);
  }

}

Again, the client is similar to the original client, but with some important differences.

1. The Spring context is created with the new camel-client-remoting.xml
2. We retrieve the proxy bean instead of a CamelTemplate. In a non-trivial example you would have the bean injected as in the standard Spring manner.
3. The multiply method is then called directydirectly. In the client we are now working to an interface. There is no mention of Camel or JMS inside our Java code.

...

TODO: Detail how to use the Maven plugin as an alternative to CamelServer

TODO: Testing

TODO: Detail how to unit and integration test this example.