Spring Remoting has been edited by James Strachan (Aug 11, 2008).

(View changes)

Content:

Spring Remoting

We support Spring Remoting in Camel. The implementing of Spring Remoting uses Camel as the underlying transport mechanism. The nice thing about this approach is we can use any of the Camel transport Components to communicate between beans.

It also means we can use Content Based Router and the other Enterprise Integration Patterns in between the beans; in particular we can use Message Translator to be able to convert what the on-the-wire messages look like in addition to adding various headers and so forth.

Using Camel Spring Remoting

In your Spring XML just use the CamelProxyFactoryBean to create a client side proxy implementing some interface which then sends messages to some remote Camel Endpoint such as ActiveMQ, JMS, File, HTTP, XMPP etc.

Then to implement the service you use CamelServiceExporter

The following example shows how to create a proxy which when invoked with fire a message to the direct:say endpoint

<!--  Creates a proxy to the direct:say endpoint. -->
<bean id="sayProxy" class="org.apache.camel.spring.remoting.CamelProxyFactoryBean">
  <property name="serviceUrl" value="direct:say"/>
  <property name="serviceInterface" value="org.apache.camel.spring.remoting.ISay"/>
</bean>

Then we expose the service on an endpoint so that messages from direct:sayImpl will be dispatched to the service (note that we have a route in between these two endpoints).

<!--  Exposes the above bean as via the pojo:say endpoint -->
<bean id="say" class="org.apache.camel.spring.remoting.CamelServiceExporter">
  <property name="uri" value="direct:sayImpl"/>
  <property name="service">
    <bean class="org.apache.camel.spring.remoting.SayService"/>
  </property>
  <property name="serviceInterface" value="org.apache.camel.spring.remoting.ISay"/>
</bean>

Using Custom Namespaces

In this example we use the Camel custom namespaces to make the XML much more concise. First, create a proxy via the proxy element

<!--  Creates a proxy to the direct:say endpoint. -->
<camel:proxy id="sayProxy" serviceUrl="direct:say"
                    serviceInterface="org.apache.camel.spring.remoting.ISay"/>

Then we expose the service via the export element

<bean id="sayService" class="org.apache.camel.spring.remoting.SayService"/>

<camel:export id="say" uri="direct:sayImpl" serviceRef="sayService"
                       serviceInterface="org.apache.camel.spring.remoting.ISay"/>

Its much cleaner - use whichever approach you prefer as they are both equivalent.

ServiceExporter is Optional

Note that the service is not mandatory; since the Bean component and the various other forms of Bean Integration can be used to route any message exchange to a bean, so you can miss out the serviceExporter if you prefer. The main value of the service exporter is its a single XML element to bind a URI to a bean and it allows the full API of the bean to be restricted by a serviceInterface.

Bean binding

The binding of a Camel Message to a bean method call can occur in different ways

  • if the bean can be converted to a Processor using the Type Converter mechanism then this is used to process the message. This mechanism is used by the ActiveMQ component to allow any MessageListener to be invoked by the Bean component
  • if the body of the message can be converted to a BeanInvocation (the default payload used by the ProxyHelper) - then that its used to invoke the method and pass the arguments
  • if the message contains the header org.apache.camel.MethodName then that method is invoked, converting the body to whatever the argument is to the method
  • otherwise the type of the method body is used to try find a method which matches; an error is thrown if a single method cannot be chosen unambiguously.
  • you can also use Exchange as the parameter itself, but then the return type must be void.

By default the return value is set on the outbound message body.

For example a POJO such as:

public class Bar {

    public String doSomething(String body) {
      // process the in body and return whatever you want
      return "Bye World";
   }

Or the Exchange example. Notice that the return type must be void:

public class Bar {

    public void doSomething(Exchange exchange) {
      // process the exchange
      exchange.getIn().setBody("Bye World");
   }

For example you could write a method like this (showing also a feature in Camel, the @MessageDrive annotation):

public class Foo {

    @MessageDriven(uri = "activemq:my.queue")
    public void doSomething(String body) {
		// process the inbound message here
    }

}

Here Camel with subscribe to an ActiveMQ queue, then convert the message payload to a String (so dealing with TextMessage, ObjectMessage and BytesMessage in JMS), then process this method.

Using Annotations to bind parameters to the Exchange

The annotations can be used to bind in situations where traditional methods would result in ambiguous methods. So by adding annotations you can decorate your bean to help Camel invoke the correct method.

You can also use the following annotations to bind parameters to different kinds of _expression_

Annotation Meaning
@Body To bind to an inbound message body
@Header To bind to an inbound message header
@Headers To bind to the Map of the inbound message headers
@OutHeaders To bind to the Map of the outbound message headers
@Property To bind to a named property on the exchange
@Properties To bind to the property map on the exchange

For example

public class Foo {
	
    @MessageDriven(uri = "activemq:my.queue")
    public void doSomething(@Header('JMSCorrelationID') String correlationID, @Body String body) {
		// process the inbound message here
    }

}

In the above you can now pass the Message.getJMSCorrelationID() as a parameter to the method (using the Type Converter to adapt the value to the type of the parameter).

Finally you don't need the @MessageDriven annotation; as the Camel route could describe which method to invoke.

e.g. a route could look like

from("activemq:someQueue").
  to("bean:myBean");

Here myBean would be looked up in the Registry (such as JNDI or the Spring ApplicationContext), then the body of the message would be used to try figure out what method to call.

If you want to be explicit you can use

from("activemq:someQueue").
  to("bean:myBean?methodName=doSomething");

And here we have a nifty example for you to show some great power in Camel. You can mix and match the annotations with the normal parameters, so we can have this example with annotations and the Exchange also:

public void doSomething(@Header(name = "user") String user, @Body String body, Exchange exchange) {
        exchange.getIn().setBody(body + "MyBean");
    }

Using _expression_ Languages

You can also use any of the Languages supported in Camel to bind expressions to method parameters when using bean integration. For example you can use any of these annotations...

Annotation Description
@BeanShell Inject a BeanShell _expression_
@Constant Inject a Constant _expression_
@EL Inject an EL _expression_
@Groovy Inject a Groovy _expression_
@_javascript_ Inject a _javascript_ _expression_
@OGNL Inject an OGNL _expression_
@PHP Inject a PHP _expression_
@Python Inject a Python _expression_
@Ruby Inject a Ruby _expression_
@Simple Inject an Simple _expression_
@XPath Inject an XPath _expression_
@XQuery Inject an XQuery _expression_

For example

public class Foo {
	
    @MessageDriven(uri = "activemq:my.queue")
    public void doSomething(@Path("/foo/bar/text()") String correlationID, @Body String body) {
		// process the inbound message here
    }
}

Reply via email to